Recently, I found a way to make the GlassFish supplied pkg(5) tool run using Debian’s python interpreter and associated libs. I also spent a while trying to package it in a sane way, but I’m afraid I lack the knowledge of Java and Debian package internals to do this properly (I’ve requested the package, though). But in the meantime we still need a nice way to setup GlassFish on a Debian Lenny machine. So I’ve turned to puppet, as usual.
You can find the module here: glassfish.tar.bz2 (12.8kB)
It doesn’t contain everything, though. You still need to download the glassfish ZIP file from here and rename that file to glassfish.zip and add it in the files directory of the module. After that, you can just include glassfish and it gets set-up!
The module does several things, including installing a very small facter Fact. The fact just checks if several important files/directories exist and if so, it deems GlassFish ‘installed’. If not, the module includes the glassfish::initial_setup class, which does the initial setup of GlassFish. You don’t want to include this class on every run, because it adds some crud in your /tmp, including some touchstone files. The glassfish_installed was created for determining this (following an example given to me by Volcane on IRC, thanks man!). The check probably isn’t perfect, but it’s good enough for our purposes.
This module adds the Debian non-free repository to your APT’s sources.list and installs the sun-java6-jdk package. In the process it also agrees with the Sun DLJ License. If you prefer the openjdk package, those should work too. You’ll just have to remove the stuff needed for installing sun-java6-jdk from the module.
Because we’re not fond of the way the GlassFish developers packaged the pkg(5) tool in there, the installer applies the recipe described earlier on this blog. You can see these steps in the glassfish::initial_setup subclass. There are a lot of exec’s in there which do most of the important work.
Due to security concerns, the module creates a glassfish user and group and makes sure all the code is readable by that user and group. It also makes sure the code is writable by the group, so you can easily add the local accounts from developers to the group and give them access to the code. If you want to allow them to do administrative tasks on GlassFish, you can add these rules to your /etc/sudoers:
%glassfish ALL=(glassfish) NOPASSWD: /opt/glassfishv3/bin/asadmin %glassfish ALL=(glassfish) NOPASSWD: /opt/glassfishv3/bin/pkg %glassfish ALL=(glassfish) NOPASSWD: /opt/glassfishv3/glassfish/bin/appclient %glassfish ALL=(glassfish) NOPASSWD: /opt/glassfishv3/glassfish/bin/asadmin %glassfish ALL=(glassfish) NOPASSWD: /opt/glassfishv3/glassfish/bin/asupgrade %glassfish ALL=(glassfish) NOPASSWD: /opt/glassfishv3/glassfish/bin/capture-schema %glassfish ALL=(glassfish) NOPASSWD: /opt/glassfishv3/glassfish/bin/jspc %glassfish ALL=(glassfish) NOPASSWD: /opt/glassfishv3/glassfish/bin/package-appclient %glassfish ALL=(glassfish) NOPASSWD: /opt/glassfishv3/glassfish/bin/schemagen %glassfish ALL=(glassfish) NOPASSWD: /opt/glassfishv3/glassfish/bin/startserv %glassfish ALL=(glassfish) NOPASSWD: /opt/glassfishv3/glassfish/bin/stopserv %glassfish ALL=(glassfish) NOPASSWD: /opt/glassfishv3/glassfish/bin/wscompile %glassfish ALL=(glassfish) NOPASSWD: /opt/glassfishv3/glassfish/bin/wsdeploy %glassfish ALL=(glassfish) NOPASSWD: /opt/glassfishv3/glassfish/bin/wsgen %glassfish ALL=(glassfish) NOPASSWD: /opt/glassfishv3/glassfish/bin/wsimport %glassfish ALL=(glassfish) NOPASSWD: /opt/glassfishv3/glassfish/bin/xjc
For easy reinstall, we symlink the /opt/glassfishv3/glassfish/domains directory to /srv/glassfish/domains. This allows you to completely remove /opt/glassfishv3 to perform a reinstall with the puppet module (because the removal of that directory triggers the inclusion of glassfish::initial_setup without breaking developer code.
The second time you run the script, all the crud is removed, including some .bat files that are part of the distribution of GlassFish. We leave JavaDB and mq in place, even though we don’t use them at all. So you might want to create some customization for those yourself.
Because we prefer to compile a small .so file from source instead of installing the ia32 libs, several developer packages are installed. These are not automatically removed in glassfish::cleanup, because the module cannot know if these packages are needed by another module too. So you might want to manually do a sudo apt-get --purge remove python-dev gcc libc6-dev unzip patch if you’re sure you don’t need these packages anywhere else. (Note: If you install them anywhere else in your puppet modules too, you’ll probably get an error from puppet about duplicate definitions anyway…)
The glassfish::initial_setup class has a lot of ordering added, but we’ve taken care of only requiring those resources that are actually needed, so the install isn’t broken if one thing doesn’t work. You’ll have to take care of the stuff that doesn’t work yourself, though.
Finally, on a second puppet run after the installation, the glassfish::cleanup class is included, which removes the crud we needed for the initial setup.
Some areas still need a little work, for example the initscript. It currently relies on sudo, which is not the nicest solution. That will be fixed eventually and I’ll update the tarball here. For now, enjoy and I hope this helps someone!
Do let us know if you have improvements to this puppet recipe!