# Forking GlassFish Redux: Payara Server

In the time since I last wrote about the need for a fork of Oracle’s GlassFish Server, Oracle have effectively removed the viability of GlassFish as a production system by killing off professional support in favour of their megabucks closed-source WebLogic product. This was a completely unsurprising move, and simply added to the mountain of orphaned and abandoned techhnology inherited from Oracle’s Sun acquisition (to which we can add some more recent additions).

Fortunately, and largely due to the wisdom of Sun to originally open source the product, a new player in the Java app server scene has appeared with what is to all intents and purposes the GlassFish fork we’ve been waiting for: Payara Server.

You can check out their website at: http://www.payara.co.uk/home. As mentioned on their site: “We take GlassFish upstream. We support it, fix it, enhance it. We release it as open source Payara Server.”

Do I have funds or a current use case to pay for professional support for an app server yet? No. Do I want to use the same product I’ll eventually be using in production while I’m in the startup/setup phase, easily and without restriction? Yes. Will I pay for support if the use case requires it, and if it guarantees a healthy product/project down the line in the best spirit of open source? Happily, and especially if it’s from the same vendor offering the product to begin with. Not rocket science, and when a vendor throws too many obstacles in my path I’ll simply switch to an alternative which does afford me these freedoms.

Looking forward to trying this out.

# Configuring a public JSPWiki instance for private use

Been a tad quiet on this blog for a while I realise – time to freshen thing up a bit.

In this blog post we’re going to quickly cover how to configure a JSPWiki instance such that wiki content cannot be viewed without being authenticated with a login account. For example, you may wish to deploy JSPWiki in the cloud for convenient access anywhere, but also use it to host company-sensitive documentation. In this case you probably don’t want the general public even having read-only access to the wiki content.

It turns out this is very straightforward to achieve and merely consists of making the desired changes in the jspwiki.policy file. The function of each policy block within jspwiki.policy is also clearly documented in the same file, so everything is pretty self explanatory.

JSPWiki setup and configuration is outside the scope of this post, so I’m assuming you’ve set up JSPWiki to use container-managed authentication similar to some of my previous articles here. Also note that in recent releases of JSPWiki (certainly v2.10.x) the location of various configurations files has changed – again, outside the scope of this post. All this considered, the following full excerpt of my jspwiki.policy file achieves the following:

• All public users are prevented from being able to view the wiki.
• Anonymous users have no permissions.
• Users authenticated via a browser cookie have no permissions.
• Users authenticated with a JSPWiki login account (configured in our application server, e.g. GlassFish) have a set of standard permissions for viewing, editing, and modifying content.
• Admin users have full permissions.

Note that I’ve left the original policy blocks in place commented out so you can see the exact settings I’ve made.


//  Licensed to the Apache Software Foundation (ASF) under one
//  or more contributor license agreements.  See the NOTICE file
//  distributed with this work for additional information
//  to you under the Apache License, Version 2.0 (the
//  "License"); you may not use this file except in compliance
//  with the License.  You may obtain a copy of the License at
//
//
//  Unless required by applicable law or agreed to in writing,
//  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
//  KIND, either express or implied.  See the License for the
//  specific language governing permissions and limitations

// $Id: jspwiki.policy,v 1.23 2007-07-06 10:36:36 jalkanen Exp$
//
// This file contains the local security policy for JSPWiki.
// It provides the permissions rules for the JSPWiki
// environment, and should be suitable for most purposes.
// JSPWiki will load this policy when the wiki webapp starts.
//
// As noted, this is the 'local' policy for this instance of JSPWiki.
// You can also use the standard Java 2 security policy mechanisms
// to create a consolidated 'global policy' (JVM-wide) that will be checked first,
// before this local policy. This is ideal for situations in which you are
// running multiple instances of JSPWiki in your web container.
// To set a global security policy for all running instances of JSPWiki,
// you will need to specify the location of the global policy by setting the
// JVM system property 'java.security.policy' in the command line script
// you use to start your web container. See the documentation
// pages at http://doc.jspwiki.org/2.4/wiki/InstallingJSPWiki. If you
// don't know what this means, don't worry about it.
//
// Also, if you are running JSPWiki with a security policy, you will probably
// want to copy the contents of the file jspwiki-container.policy into your
// container's policy. See that file for more details.
//
// ------ EVERYTHING THAT FOLLOWS IS THE 'LOCAL' POLICY FOR YOUR WIKI ------

// The first policy block grants privileges that all users need, regardless of
// the roles or groups they belong to. Everyone can register with the wiki and
// Everyone can also view all wiki pages unless otherwise protected by an ACL.
// If that seems too loose for your needs, you can restrict page-viewing
// privileges by moving the PagePermission 'view' grant to one of the other blocks.

//grant principal org.apache.wiki.auth.authorize.Role "All" {
//    permission org.apache.wiki.auth.permissions.PagePermission "*:*", "view";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "editPreferences";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "editProfile";
//};

grant principal org.apache.wiki.auth.authorize.Role "All" {
permission org.apache.wiki.auth.permissions.WikiPermission "*", "editPreferences";
permission org.apache.wiki.auth.permissions.WikiPermission "*", "editProfile";
};

// The second policy block is extremely loose, and unsuited for public-facing wikis.
// Anonymous users are allowed to create, edit and comment on all pages.
//
// Note: For Internet-facing wikis, you are strongly advised to remove the
// lines containing the "modify" and "createPages" permissions; this will make
// the wiki read-only for anonymous users.

// Note that "modify" implies *both* "edit" and "upload", so if you wish to
// allow editing only, then replace "modify" with "edit".

//grant principal org.apache.wiki.auth.authorize.Role "Anonymous" {
//    permission org.apache.wiki.auth.permissions.PagePermission "*:*", "modify";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "createPages";
//};

grant principal org.apache.wiki.auth.authorize.Role "Anonymous" {
};

// This next policy block is also pretty loose. It allows users who claim to
// be someone (via their cookie) to create, edit and comment on all pages,
// as well as upload files.
// They can also view the membership list of groups.

//grant principal org.apache.wiki.auth.authorize.Role "Asserted" {
//    permission org.apache.wiki.auth.permissions.PagePermission "*:*", "modify";
//    permission org.apache.wiki.auth.permissions.WikiPermission "*", "createPages";
//    permission org.apache.wiki.auth.permissions.GroupPermission "*:*", "view";
//};

grant principal org.apache.wiki.auth.authorize.Role "Asserted" {
};

// Authenticated users can do most things: view, create, edit and
// comment on all pages; upload files to existing ones; create and edit
// wiki groups; and rename existing pages. Authenticated users can also
// edit groups they are members of.

grant principal org.apache.wiki.auth.authorize.Role "Authenticated" {
permission org.apache.wiki.auth.permissions.PagePermission "*:*", "modify,rename";
permission org.apache.wiki.auth.permissions.GroupPermission "*:*", "view";
permission org.apache.wiki.auth.permissions.GroupPermission "*:<groupmember>", "edit";
permission org.apache.wiki.auth.permissions.WikiPermission "*", "createPages,createGroups";
};

// 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).

permission org.apache.wiki.auth.permissions.AllPermission "*";
};
permission org.apache.wiki.auth.permissions.AllPermission "*";
};


After applying this and restarting the application server domain, one can now see that we need to authenticate even to view any of the wiki content.

# Creating a GlassFish service on Mac OS X

Quick post – when installing GlassFish 3.1.2.2 on Mac OS X (10.8.3 in my case) a GlassFish service won’t be created by the GlassFish installer (whereas Windows and Solaris platforms do get the ability to manage GlassFish as a service).

I came across a handy blog post by a former Sun Microsystems staffer which takes us most of the way there:

http://lowbittest.wordpress.com/2007/11/06/running-glassfish-on-mac-os-x-using-launchd/

The original blog entry was pertaining to Mac OS 10.4 but applies to 10.8 with one exception (in my case). When attempting to load the service the GlassFish process would immediately be killed by launchd. This is alluded to in the blog comments above.

The solution can be found at https://discussions.apple.com/thread/1744853?start=0&tstart=0 and consists of adding the following entry to your GlassFish plist file:

<key>AbandonProcessGroup</key>
<true/>


My quick procedure for creating a GlassFish service based on the above information follows. Note that I am not covering the details of how services are created and managed for Mac OS, so this is basically to get up and running quickly.

1) Create a plist file

Simlar to Solaris SMF, the plist file is an XML service descriptor file. These are the contents of my file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.sun.glassfish</string>
<key>Disabled</key>
<false/>
<string>davek</string>
<key>GroupName</key>
<string>staff</string>
<key>ProgramArguments</key>
<array>
<string>start-domain</string>
<string>domain1</string>
</array>
<true/>
<key>AbandonProcessGroup</key>
<true/>
</dict>
</plist>


Replace the UserName and GroupName values with the user and group you wish to launch GlassFish as. Also, GlassFish in my case has been installed to /Users/davek/glassfish3 – alter this path in your plist file accordingly.

Save the file for example as GlassFish.plist and copy it to /Library/LaunchDaemons.

2) Set ownership on the GlassFish domain

We are running the GlassFish service as davek:staff so be sure to change ownership on the relevant GlassFish domain (domain1 in this example) to match.

3) Import the service

Run the following command:

sudo launchctl load /Library/LaunchDaemons/GlassFish.plist


The service starts automatically after importing, so you should be able to browse to the administrative interface for the domain. If you reboot the system, the domain should also start on boot automatically.

# Prevent the “List of attachments” from appearing in documents printed from JSPWiki

In a default installation of JSPWiki files attached to a JSPWiki page are printed in a list along with the rest of the document. If one has a large amount of attached files in a wiki page, this leads to needless extra printed pages:

I enquired about this on the JSPWiki users mailing list, and Dirk Frederickx kindly gave me the solution to this:

“Following changes to the jspwiki_print.css file, in the “templates/default” directory, will hide the attachment list:”

/* add this line to hide the List of Attachments */
#attach {display:none;}


And, it works a charm.

# Fun with JSPWiki skins

I really love JSPWiki. It’s super-easy to install, doesn’t require any additional configuration for a back-end database, the native interface is quick and fast to use, and it just runs and runs. Great software.

If there’s one area however where it’s lacking, it’s in a nice selection of bundled good-looking themes. But hey, it’s free and open source software, so one is really in no position to complain – and new skins can be created using entirely standard and familiar HTML and CSS.

It’s worth noting the difference between JSPWiki templates and skins – described at http://www.jspwiki.org/wiki/JSPWikiSkinDesign

After a bit of tinkering with CSS and the bundled “Smart” theme, I came up with this:

Not the stuff of professional web design, but a definite improvement on the default theme, in my humble opinion.

# Enable secure LDAP container based authentication with JSPWiki

A quick follow up on my post here. I will describe below the steps needed to enable secure LDAP authentication (both LDAPS and HTTPS). This is not intended for production use, obviously.

I’m using the same platform and environment described here, and also using this as the starting point for the following.

Verify that the LDAPS connection handler is enabled in OpenDJ

This can be checked using the OpenDJ Control Panel GUI, and modified if necessary using the CLI dsconfig utility.

Switch to the secure LDAP port in the GlassFish JSPWiki security realm

Make sure you are using the ldaps:// URL prefix, and specify the secure port number (1636 in this example):

Enable security for the relevant GlassFish HTTP network listener port

Our JSPWiki application is listening over port 8080, configured in GlassFish under http-listener-1. Enable security for this port:

Enable HTTPS connections to JSPWiki

This is performed via modification of the JSPWiki web.xml file. In a default state, the web.xml file contains the following entries which enable the use of SSL connections:

<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>


Ensure these exist in web.xml under the container managed authentication section.

Export the OpenDJ SSL certificate and import it into the JSPWiki JKS keystore

The keytool CLI utility is used for this step.

First, we export the OpenDJ certificate (which has a default alias of server-cert) to a file:

dave@mymachine:~/OpenDJ/config$pfexec keytool -export -alias "server-cert" -keystore ~/OpenDJ/config/keystore -file /tmp/server-cert.cer Enter keystore password: Certificate stored in file </tmp/server-cert.cer>  Next, we import the certificate file into the keystore of the GlassFish domain running our instance of JSPWiki, which in this example is at /opt/glassfishv3/glassfish/domains/domain1/config/cacerts.jks: dave@mymachine:~/OpenDJ/config$ pfexec keytool -import -v -trustcacerts -alias "server-cert" -keystore /opt/glassfishv3/glassfish/domains/domain1/config/cacerts.jks -file /tmp/server-cert.cer
Owner: CN=mymachine, O=OpenDS Self-Signed Certificate
Issuer: CN=mymachine, O=OpenDS Self-Signed Certificate
Serial number:
Valid from:
Certificate fingerprints:
MD5:
SHA1:
Signature algorithm name: SHA1withRSA
Version: 3
Trust this certificate? [no]:  yes
[Storing /opt/glassfishv3/glassfish/domains/domain1/config/cacerts.jks]


Modify the jspwiki.baseURL value

This is required as the URL prefix will have changed from http:// to https://. This modification is performed in the jspwiki.properties file.

Assuming my existing jspwiki.baseURL value is:

http://192.168.1.1:8080/ITProjects/


This would need to be changed to:

https://192.168.1.1:8080/ITProjects/


Restart the GlassFish domain, and test LDAP logins…

# Container based authentication with JSPWiki, GlassFish and OpenDJ

In this blog entry I am going to describe configuring JSPWiki to use container based authentication to authenticate LDAP users existing in an OpenDJ directory. I am using GlassFish as my web application container, so this can be considered an alternative solution to using Tomcat, for example as described here.

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.

Members 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>
<url-pattern>/Delete.jsp</url-pattern>
</web-resource-collection>
<auth-constraint>
</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>/NewGroup.jsp</url-pattern>
<url-pattern>/Rename.jsp</url-pattern>
<http-method>DELETE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method>
<http-method>PUT</http-method>
</web-resource-collection>

<web-resource-collection>
<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-users</role-name>
</auth-constraint>
</security-constraint>

<auth-method>FORM</auth-method>
<realm-name>JSPWikiUsers</realm-name>

<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>
</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).

permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};
permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};


// 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 "*";
// };
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>
</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 a user that is a member of the wiki-admin group in OpenDJ, I do indeed have full permissions in JSPWiki:

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

# Forking GlassFish

(Update: see https://blog.davekoelmeyer.co.nz/2014/11/22/forking-glassfish-redux-payara-server/)

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.

# Apache Roller 5 problems on GlassFish 3.0.1

I recently installed Apache Roller 5 on GlassFish 3.0.1 (on an OpenIndiana host with JDK 6u26, connecting to a PostgreSQL 8.4 database) and had the rather unusual behaviour of the Roller web app seemingly failing after an arbitrary period of time, followed by the GlassFish domain itself stopping.

I have two GlassFish domains set up on the host in question, one serving up JSPWiki, the other serving Roller. The JSPWiki domain remained stable, so I figured this was possibly either a problem with Roller 5.0 or a port conflict issue between the two domains. Even after recreating the second domain with the –portbase option and ensuring there were no conflicting ports, Roller would still eventually crap out followed by the domain itself, with seemingly nothing of relevance logged.

I upgraded to GlassFish 3.1.1 and so far things are perfectly stable – so I guess this was due to some issue with GlassFish 3.0.1 in the end.

# Oracle WebLogic spam in the GlassFish “community”

Sigh. There seems to have been an entirely unsurprising increase in this of late, for example (the GlassFish group on Facebook is first):

Seriously, I’m not thick: if I wanted to read about WebLogic, then I’d go to Oracle’s godawful website (or the WebLogic twitter or Facebook feeds) and read about it there. The very least Oracle could do is pretend that they aren’t more interested in promoting their own bloated megabucks products above what is ostensibly a community project, but I guess in light of everything that’s transpired post-Sun even that’s too much to expect. Even if it were a thriving product (which given a look at the forums for example should give you a clue that it’s anything but), I would have my doubts anyway about the current engineering talent behind it, and perhaps with good reason.