I am running JSPWiki version 2.8.3, deployed in GlassFish Open Source Edition 3.1.1 (build 12) on OpenIndiana oi_151 x86. OpenDJ is version 2.4.4, and I am using Java 6 update 26.

I am assuming prior basic familiarity with installing, configuring, and managing GlassFish and OpenDJ. Our starting point will be a freshly deployed instance of JSPWiki, for which the initial first-run setup procedure has taken place and without any configuration to the JSPWiki configuration files.

This is an insecure setup intended for testing purposes.

Create user and admin groups for JSPWiki in OpenDJ

I have created the Groups OU under my Base DN, and within it created the groups wiki-admin and wiki-users.

Member of the wiki-admin group will be authorized with full permissions in JSPWiki once authenticated. Members of the wiki-users group however will have a lesser set of permissions, suitable for regular day-to-day use of the wiki. You can use LDIF commands if you wish to create the directory entries, however, I just use OpenDJ’s super-easy GUI to do the work. For example:

Create an LDAP security realm in GlassFish

This can be performed in the GlassFish admin BUI. Note that we perform this step under the Configurations -> server-config node in the BUI (not the Configurations -> default-config node):

I have created the LDAP realm JSPWikiUsers with the following settings:

Some observations on the above can be noted here:

• The search-bind-dn and search-bind-password properties may be optional for your OpenDJ installation: they are required in my case because I have disabled anonymous access to my OpenDJ server
• The port used for access to your OpenDJ server may not necessarily be 1389 – change this as necessary.

Change the JACC provider from default to simple

I found that if this step is not performed, LDAP group lookup from GlassFish to OpenDJ will plain just not work.

Navigate to the Configurations -> server-config -> Security node of the GlassFish admin BUI and make the setting as illustrated:

This should be all the configuration needed in GlassFish using the admin BUI, so we can now proceed to making the required modifications to the following JSPWiki deployment descriptor and policy files:

• web.xml
• jspwiki.policy
• glassfish-web.xml

In the following steps, we are assuming that JSPWiki has been deployed to the domain1 domain, and the path to the deployment descriptor and policy configuration files is:

/opt/glassfishv3/glassfish/domains/domain1/applications/JSPWiki/WEB-INF

(Also, in my case no changes needed to be made at all to the jspwiki.properties file.)

Enable container based authentication in the web.xml file

In the web.xml file (in its unmodified state in JSPWiki v2.8.3), look for the section near the end of the file which begins with the following comment:

<!--  REMOVE ME TO ENABLE CONTAINER-MANAGED AUTH

Simply uncomment the section and replace it with the following:

<security-constraint>
       <web-resource-collection>
           <web-resource-name>Administrative Area</web-resource-name>
           <url-pattern>/Delete.jsp</url-pattern>
       </web-resource-collection>
       <auth-constraint>
           <role-name>wiki-admin</role-name>
       </auth-constraint>
   </security-constraint>
      
   <security-constraint>
       <web-resource-collection>
           <web-resource-name>Authenticated area</web-resource-name>
           <url-pattern>/Edit.jsp</url-pattern>
           <url-pattern>/Comment.jsp</url-pattern>
           <url-pattern>/Login.jsp</url-pattern>
           <url-pattern>/NewGroup.jsp</url-pattern>
           <url-pattern>/Rename.jsp</url-pattern>
           <url-pattern>/Upload.jsp</url-pattern>
           <http-method>DELETE</http-method>
           <http-method>GET</http-method>
           <http-method>HEAD</http-method>
           <http-method>POST</http-method>
           <http-method>PUT</http-method>
       </web-resource-collection>

       <web-resource-collection>
           <web-resource-name>Read-only Area</web-resource-name>
           <url-pattern>/attach</url-pattern>
           <http-method>DELETE</http-method>
           <http-method>POST</http-method>
           <http-method>PUT</http-method>
       </web-resource-collection>

       <auth-constraint>
           <role-name>wiki-admin</role-name>
           <role-name>wiki-users</role-name>
       </auth-constraint>
   </security-constraint>

   <login-config>
       <auth-method>FORM</auth-method>
       <realm-name>JSPWikiUsers</realm-name>
       <form-login-config>
           <form-login-page>/LoginForm.jsp</form-login-page>
           <form-error-page>/LoginForm.jsp</form-error-page>
       </form-login-config>
   </login-config>

   <security-role>
       <description>
           This logical role includes all authenticated users
       </description>
       <role-name>wiki-users</role-name>
   </security-role>

   <security-role>
       <description>
           This logical role includes all administrative users
       </description>
       <role-name>wiki-admin</role-name>
   </security-role>

Modify the jspwiki.policy file

This will allow users in the wiki-admin LDAP group to be granted full permissions upon authenticating to JSPWiki.

Look for the following section at the end of the jspwiki.policy file (in its unmodified state in a JSPWiki v2.8.3 installation):

// Administrators (principals or roles possessing AllPermission)
// are allowed to delete any page, and can edit, rename and delete
// groups. You should match the permission target (here, 'JSPWiki')
// with the value of the 'jspwiki.applicationName' property in
// jspwiki.properties. Two administative groups are set up below:
// the wiki group "Admin" (stored by default in wiki page GroupAdmin)
// and the container role "Admin" (managed by the web container).

grant principal com.ecyrd.jspwiki.auth.GroupPrincipal "Admin" {
    permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};
grant principal com.ecyrd.jspwiki.auth.authorize.Role "Admin" {
    permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};

And modify it to read:

// Administrators (principals or roles possessing AllPermission)
// are allowed to delete any page, and can edit, rename and delete
// groups. You should match the permission target (here, 'JSPWiki')
// with the value of the 'jspwiki.applicationName' property in
// jspwiki.properties. Two administative groups are set up below:
// the wiki group "Admin" (stored by default in wiki page GroupAdmin)
// and the container role "Admin" (managed by the web container).

// grant principal com.ecyrd.jspwiki.auth.GroupPrincipal "Admin" {
//     permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
// };
// grant principal com.ecyrd.jspwiki.auth.authorize.Role "Admin" {
//     permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
// };
grant principal com.ecyrd.jspwiki.auth.authorize.Role "wiki-admin" {
    permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};

Create the glassfish-web.xml file

The primary purpose of this file will be to map the security roles we defined in the web.xml file to the JSPWiki groups we created in OpenDJ. The file should be created at:

/opt/glassfishv3/glassfish/domains/domain1/applications/JSPWiki/WEB-INF

The glassfish-web.xml file should contain the following only:

<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">

<glassfish-web-app>
 <security-role-mapping>
        <role-name>wiki-admin</role-name>
        <group-name>wiki-admin</group-name>
 </security-role-mapping>
 <security-role-mapping>
        <role-name>wiki-users</role-name>
        <group-name>wiki-users</group-name>
 </security-role-mapping>
</glassfish-web-app>

Restart the GlassFish domain, and test LDAP logins to JSPWiki

First, restart the domain either using the asadmin utility or the GlassFish admin BUI. Then test LDAP logins to JSPWiki.

In my case, we can observe that logging in as user that is a member of the wiki-admin group in OpenDJ, I do indeed have full permissions in JSPWiki:

Whereas logging in as user that is a member of the wiki-users group in OpenDJ, I am restricted from certain destructive actions:

So, if you’d like to use Thunderbird with Gmail and be able to do the following:

• deal with a single copy of each mail item
• be able to sort that copy into a folder
• delete mail items and have them go into a Trash folder, which you can then empty
• just generally and basically have it work without it getting in the way…

Then read on!

I am using Thunderbird 9.0 on OpenIndiana oi_151a, and a Google Apps account for my Gmail. I am assuming you have first already enabled IMAP support in Gmail, but have yet to create an IMAP connection to it in Thunderbird.

First, let’s prevent Gmail’s new, “special” folders from appearing in Thunderbird. This a) reduces a great deal of interface confusion for Thunderbird users, and b) prevents a duplicate copy of every single email from being created in Thunderbird thanks to the “All Mail” folder. Don’t think too hard about it, just log into the Gmail web interface, go to Settings -> Labels, and apply the settings as highlighted in the following:

Next, configure an IMAP connection to your Gmail account in Thunderbird. Once the account is visible in your client, make particular note of the set of folders visible under the funny-looking “[Gmail]“ folder – it should look like the following:

Now let’s configure Thunderbird such that when you delete an email, it goes into the Gmail Trash folder, and from there if you empty the Trash folder, the message is permanently deleted. No, don’t ask why I am stating the bloody obvious, just observe the following settings for the Gmail account in Thunderbird (and note that this runs counter to the completely bizarre “recommended IMAP settings” Google would have you use). Make sure that the Trash folder you reference is the one that sits under the [Gmail] folder:

Test this by deleting a message from your Inbox or whatever – it should go into the [Gmail] -> Trash folder, and you should be able to right click on that folder and empty it to permanently delete items.

Disable Thunderbird’s junk email detection for the Gmail account:

Finally, and this is referenced in Google’s documentation, if you are sending mail out through Google’s SMTP server, then make sure that you are not also saving a copy in the Sent Mail folder for the account. Again confusing, because this is naturally what you would want to do for an IMAP account – but as it happens Gmail will save a copy automatically in the [Gmail] -> Sent Mail folder if you use their outbound server (which I do). I use the following settings for copies of sent mail, and any other copies:

Anyway, after have a sniff around I have found an application which on a basic level seems to work well enough – “Mobile Document Viewer”:

https://market.android.com/details?id=de.joergjahnke.documentviewer.android.free&feature=also_installed

Running it on an ASUS Eee Slider tablet, I loaded up one of my ODT files which I could open with no problems:

The application however converts the content to HTML and displays it in a browser window – so the formatting goes somewhat AWOL, but otherwise the content itself loads up fine. As a cute extra there is text-to-speech support, if you fancy having ODF files read aloud to you.

The free version is ad-supported (hence my message from “Elaine”…), but given the paltry fee for the full version this is a no-brainer purchase.

After I made a couple of remarks via Twitter regarding my perceived increase in the amount of Oracle WebLogic marketing material being posted on the GlassFish Twitter, Facebook, and blogs.oracle.com pages – which given recent news I can fully understand a company like Oracle wanting to push at the expense of GlassFish Open Source Edition – I was asked by an Oracle staffer what I would expect from a GlassFish fork.

For me this is less about expectation, and more about what I would hope from a fork, so what follows are some of my feelings in response to this.

Seems like I’m not the first person out there to mull this over, incidentally.

1) Some degree of security that Oracle won’t arbitrarily close the project with no official communication to either the community or customers, because it conflicts with the primary, overriding money-making ethos at the heart of the company.

2) Affordable professional support, with the confidence that support costs won’t unexpectedly and dramatically increase (to use one of many examples), simply to satisfy what any reasonable person would call the disgustingly profligate lifestyle of one man.

3) Knowledge that it’s in the right hands, that is, developed by a company that understands open source, participates in and nurtures a community, doesn’t have its own proprietary products competing for resources, and, doesn’t identify by its own admission open source adoption as one of the key competitive threats to its own business model.

As far as I am concerned, Oracle has also really screwed up with the perception of its own developer talent. Even if I had confidence in Oracle regarding the above points, the increasingly relevant question is, would it be a product anyone would want to use? What other conclusion can a customer reach when the collective ex-Sun/Oracle developer talent responsible for breakthrough OS technologies (for example) are loudly and publicly questioning Oracle’s own competence as a technology provider?

There are other issues to note, but this will do for a start.

First, let’s start with “Labels”. I guess the temptation for Google to resist inventing another cute term with slightly different functionality for a very old concept was too great to resist. Never mind that “Labels” are to all practical purposes the same as mail folders, let’s call them something different and confuse the shit out of people. I now have “Labels” in the Gmail web client, which are presented as standard IMAP folders in my Thunderbird client. Great – two different sets of terminology to have to deal with and explain to clients.

So you can apply “Labels” to more than one conversation – big deal. Why can’t we just stick to folders and search folders? (And talking about “conversation” (i.e. threaded) view mode, let’s make that the default mail view and stick the setting deep into the preferences just to really annoy anyone who’d like to turn it off).

Even worse, Gmail now has “System Labels”, and these get pulled into your IMAP client, sitting under their own curious “Gmail” subfolder:

This is where the whole label/folder distinction really breaks down. At least you can disable these from appearing in your IMAP client via Gmail preferences:

Moving on to mail rules – whoops, sorry, I mean “Filters” as they are known in Gmail. So I set up a mail sorting “Filter” to sort mail addressed to one of the many mailing lists I subscribe to into a “Label”. Seemed straightforward enough, but for some reason I still received a copy as well in my inbox. Well, you have to make a manual setting for that too – and confusingly it’s a setting called “Skip the Inbox (Archive it)”

I can understand the “Skip the Inbox…” bit, but why the reference to archiving it? I just want to move the fucking thing to another folder and that’s all.

So assuming you’ve jumped through these hoops just to get your IMAP client in order, you now have to deal with Gmail’s most perplexing “feature” – the “All Mail” folder. I have absolutely no idea why this is even present, nor what function it is supposed to serve. Straight from the documentation:

“Gmail/All Mail contains all of your messages in Gmail, including your sent and archived messages. Any messages that you see in your inbox will also appear in the Gmail/All Mail folder.”

Um, why?

Anyway, worst of all let’s assume you have some 20,000 mail items (like I do) spread across several “Labels”, or “Folders”, or whatever Google are calling it this year. Assuming you haven’t used the above IMAP settings in Gmail to prevent the “All Mail” label from appearing in your IMAP client, you can expect all 20,000 of those items to be pulled down in duplicate into your IMAP “All Mail” folder. Sheer genius!

So in summary, not a fan at all. I’m using Google Apps mail basically just for the uptime SLA, but otherwise it’s confusing if you aren’t using the Gmail web interface, it looks like it was thought out by a bunch of computer science undergrads for a project of some sort, and in general the whole thing just stinks of an effort to make it as frustrating as possible for IMAP users short of having the whole thing not work at all. Read: “Use our browser, and the native web interface, and you won’t have any problems at all!”. Mmm, I love the smell of lock-in in the morning.

On that last note:

This sort of thing makes Google absolutely no different to Microsoft in this regard.

It’s also not helped by working in a huge institution which secures site licenses for what would otherwise be very expensive applications (or suites of applications) – and the confusion this creates (in creating a false impression that software is generally something that doesn’t cost a lot of money) requires double the effort in explaining to users why they can’t just use the site-licensed application wherever they please (e.g. at home, overseas etc.). Not to mention the sticker shock when you inform a user how much they would expect to pay retail for the same product (“What do you mean it costs $2000? I get it for free here!”)

I therefore thought it would be worth my while to blog something which is more a collection of links and recommended reading on this topic. If you’ve ended up here through means other than a general web search or a link from somewhere else, chances are I’ve directed you here myself – as I believe you are probably in need of some free advice. This entry is pertaining most to those who run small businesses, or contract work to businesses. Let’s start.

I was originally going to open by stating that the first misconception (as far as I am concerned) a lot of people have is that the BSA and other licensing enforcement (i.e. anti-piracy) agencies don’t bother going after small companies, instead focusing on much larger fish – but I realised that for a lot of people the concept that any enforcement at all takes place is probably an alien one (i.e. “What’s the BSA?”).

So, yes – commercial software vendors do have enforcement arms. Here’s one:

http://www.bsa.org/GlobalHome.aspx

And here’s another:

http://www.theesa.com/

Their member companies include every major software vendor whose products you’ve ever heard of and used.

Okay, but surely they would only bother with large businesses, right? Wrongo. Here’s a great article that states that in fact the BSA “…goes after medium, small and tiny businesses…the biggest myth is that small and medium businesses don’t need to worry. But actually they’re at greatest risk…BSA Director of Enforcement Jenny Blank says they’ve gone after companies with ‘a handful’ of computers…“

Read that again – “a handful of computers”. Run a small creative firm and not quite licensed for Adobe CS or Microsoft Office? Well, you should be especially worried.

But how would an agency like the BSA even find out? Well, they’ve figured out one quite nifty way of doing so, and it goes like this:

https://reporting.bsa.org/r/report/add.aspx?src=us&ln=en-us

Know someone using hot software? Earn money now!! (and please, direct your gaze to the table headed “Reward Payment Guidelines”: potential reward payments of up to a million bucks US? Sounds like a no-brainer to me.)

On that note, if you’re a manager, either knowingly or unknowingly using hot software in your operation (the BSA et al don’t care either way) and you’ve pissed off your employees to boot – then you might just have extra cause for concern: “…What motivates people to call the BSA? Blank: ‘It’s hard to know. Often they are the stereotypical disgruntled former employee. But the issue is not what motivated them, but do they have a story to tell us’…”

Right, so when you eventually receive an audit notice from the BSA (for example), you get down to the nitty gritty of proving you’ve paid for a license or licenses for the software you are using (not that you own the software – it doesn’t work like that). Assuming you’ve kept your nose clean, should be a pretty straightforward task, right? Well think again, and read this: “…In my last column I mentioned some of the things you and I would consider proof that we acquired our software legally, such as having the original disks, packing material, and paper or folder with the Registration Key. Answer from the BSA: none of that proves you own your software…”

Finally (for now at least), here’s a fantastically entertaining read on what and what not to do when audited (including why you can’t just ignore an audit letter). This is recommended reading in full:

http://www.baselinemag.com/c/a/Projects-Management/What-to-Do-When-You-Receive-a-BSA-Audit-Letter/

And lest any small business owner think it’s all about the money (as if the astronomical sums involved were not nightmare enough), there is some valuable advice given at the end of the piece, about the additional damage to a brand this sort of thing can cause. I mean, there’s nothing quite like having your company all over the industry press for using illegal software, regardless of whether you are a dentist or a door maker.

My advice:

1) If you knowingly use illegally obtained software, don’t.
2) If you unknowingly use illegally obtained software, then find out stat.
3) Get compliant and stay that way.
4) And perhaps most importantly in my opinion: replace proprietary software with Free and Open Source Software equivalents where possible and practical.

Messages sent via the Facebook Messenger app may not be delivered via Kraken

Endless intermittent errors, a dog-slow web interface that takes an absolute age to start up, and stupid-long wait times just to see the contents of a mail folder. Garbage.

At least the price is right now (i.e. free)…

Here’s an excerpt:

The concert hall at the Syndey Opera House holds 2,700 people. This blog was viewed about 34,000 times in 2011. If it were a concert at Sydney Opera House, it would take about 13 sold-out performances for that many people to see it.

Click here to see the complete report.