GlassFish 3.0.1′s pkg tool using Debian’s Python packages

While setting up GlassFish 3.0.1 for a customer on Debian Lenny using 64 bit machines, I ran into the problem that the update tool shipped with GlassFish (OpenSolaris‘s pkg tool) uses a Python interpreter which is part of the package. That Python interpreter however is 32 bit, which requires the ia32 libraries to be installed. Worse, it requires lididn in 32 bit, which is not part of the default Debian packages, so I had to get that one from the (very nice) Debian Multimedia repository. Although that’s a quick fix to get stuff working, we rather not use these repositories on production machines, due to security concerns and the like. Also, upgrades are easier if you only use the standard Debian repositories.

So I decided to see if I could get it working with the Debian supplied Python interpreter. One problem is that there’s a shared object file written in C which is part of the pkg application. That file is a 32 bit ELF too. So we’re going to download that source and recompile it for 64 bit. If you’re on a 32 bit system, you can skip that step (although it doesn’t hurt to do it anyway). First, we need to install the following packages:

apt-get install python2.5 python2.5-dev gcc python-cherrypy python-mako python-openssl python-ply python-pycurl python-simplejson

Now download the source for the _actions.c file from here (link to webpage, press download in the top).

Compile it with the following command:
gcc -I/usr/include/python2.5 -shared -fpic -O2 _actions.c -o _actions.so

Keep the resulting .so file, we’re going to replace it once we’ve downloaded GlassFish. Which is the next step, actually. So download GlassFish and set it up somewhere. I downloaded the tarball and unzipped it into /opt/glassfish.

The resulting directory contains several directories, including a pkg and a glassfish directory. The /opt/glassfish/glassfish directory is the actual GlassFish application. The pkg directory contains the pkg tool which is used to upgrade the GlassFish addons and systems and stuff (don’t ask me about the details, I’m not a Java developer, only a sysadmin). The first time you start it, it installs some stuff. So just run the following:
/opt/glassfish/bin/pkg

Next, mv the file /opt/glassfish/pkg/bin/pkg to /opt/glassfish/pkg/bin/pkg.orig. We do this since this script does all kinds of magic which we do not need. Also, it runs the pkg python code with the python2.4 interpreter that’s part of the package. We don’t want that. Let’s fix it.

Make a simple script to replace the one we moved away. I use the following, which works for me:

#!/bin/sh
python /opt/glassfish/pkg/bin/client.py

If you start it now, you’ll get an error:

$ python /opt/glassfish/pkg/bin/client.py
Traceback (most recent call last):
  File "/opt/glassfish/pkg/bin/client.py", line 60, in 
    import pkg
ImportError: No module named pkg

Ok, let’s fix that! Start with creating a directory called /opt/glassfish/pkg/custom-lib. You can change the name into anything you want, of course, as long as it’s clear that this is where you’re going to put the pkg python module. Actually, let’s do that immediatly: cp -r /opt/glassfish/pkg/vendor-packages/pkg /opt/glassfish/pkg/custom-lib

Change our script which we setup to run pkg into the following:

#!/bin/sh
PYTHONPATH="/opt/glassfish/pkg/custom-lib" python /opt/glassfish/pkg/bin/client.py

You need to have only the pkg module in there, because the PYTHONPATH variable takes precedence over the other modules installed via the Debian packages. Run the script and you’ll get a new error:

Traceback (most recent call last):
  File "/opt/glassfish/pkg/bin/client.py", line 61, in 
    import pkg.actions as actions
  File "/opt/glassfish/pkg/custom-lib/pkg/actions/__init__.py", line 144, in 
    from _actions import _fromstr
ImportError: /opt/glassfish/pkg/custom-lib/pkg/actions/_actions.so: wrong ELF class: ELFCLASS32

If you don’t get this error, you’re on a 32 bit system and you’re done! Congratulations! Otherwise, we’re going to copy the _actions.so file we compiled earlier over the one that’s packaged with GlassFish 3.0.1. Just copy it over the other file, like so: cp _actions.so /opt/glassfish/pkg/custom-lib/pkg/actions/_actions.so

Now we’re really done! You should be able to run /opt/glassfish/bin/pkg image-update now and update your currently installed GlassFish 3.0.1 with the latest modules and stuff. Awesome!

I’m in the process of creating a Debian package for GlassFish 3.0.1 which incorporated this fix. So if you’re not in a hurry or you’re reading this way after it was posted, you might want to check out debian.kumina.nl to see if the package is available.

Hope this helps someone!

WordPress MU and /etc/hosts file

Due to a silly networking problem originating from the LVS installation we’re using, we’re stuck with a setup in which machines in the DMZ cannot access themselves via their external addresses. This is a problem for several scripts which refer to their own URL when doing some maintenance. Especially with a certain WordPress MU installation managed by our friends from Interconnect IT, we ran into trouble when they tried to update their WordPress code.

Puppet to the rescue. Although not something I’m especially proud of, I can imagine other using this as an example to fix other problems. What we do is use the wp-config.php from the WordPress installation to get data from the database that WordPress MU connects to. We use a PHP script to retrieve that data and format it in a comma-separated-value list. We then use this output to create a Facter fact, which we use in puppet to create entries in the /etc/hosts file.

You could eliminate the bash scripting by making sure the PHP script copies the files and outputs in the correct format, but it’s been ages since I’ve written anything remotely PHPish, so I decided to only do the bare minimum in PHP and do the rest in bash. YMMV.

Now without further a-do, here’s the shell script we run:

#!/bin/sh

# We want to change to the directory where this script is installed.
OLDDIR=`pwd`
cd /opt/wp-domain

# Make sure we have an empty wp-settings.php, because wp-config.php includes
# it.
touch wp-settings.php

# Copy wp-config.php from the WordPress MU installation.
# CHANGEME You want to change this path, I'm sure...
cp /srv/www/wordpress-mu/wp-config.php .

# Get the output from the script.
# Some strange stuff to make sure we don't get an error
php output-list.php > /dev/null 2>&1

# FIXME Too lazy to think of a way to do this in one step...
if [ $? -gt 0 ]; then
        cd $OLDDIR
        exit 1
else
        php output-list.php | rev | cut -c 2- | rev
        cd $OLDDIR
        exit 0
fi

This is the (very simple) PHP script we use:

<?

require_once('wp-config.php');

$db = mysql_connect(DB_HOST, DB_USER, DB_PASSWORD);
if (!$db) {
        echo "Could not connect: " . mysql_error();
        die(1);
}

mysql_select_db(DB_NAME, $db);

$query = "select domain from wp_blogs";

$result = mysql_query($query);

if (!$result) {
        echo "Query failed: " . mysql_error();
        die(1);
}

$ret = "";

while ($row = mysql_fetch_assoc($result)) {
        $ret = $ret . $row['domain'] . ";";
}

echo $ret;

?>

This is the very small Fact I’ve written for it:

unless not FileTest.file?("/opt/wp-domain/getdomains.sh")
	Facter.add("wordpressdomains") do
        	setcode do
        	        %x{/opt/wp-domain/getdomains.sh}.chomp
        	end
	end
end

And last but not least, the puppet code:

class kbp-wordpressmu {
	file {
		"/opt/wp-domain":
			ensure => directory;
		"/opt/wp-domain/getdomains.sh":
			source => "puppet://puppet/kbp-wordpressmu/getdomains.sh",
			mode   => "755";
		"/opt/wp-domain/output-list.php":
			source => "puppet://puppet/kbp-wordpressmu/output-list.php";
	}

	$domains = split($wordpressdomains,";")

	if $domains != [] and $domains != "" {
		host { $domains:
			ip => $ipaddress,
		}
	}
}

Do let me know if you think this can be way cleaner!