$ifs = split($interfaces,",")

define do_this {
	$mule = "ipaddress_${name}"
	$donkey = inline_template("<%= scope.lookupvar(mule) %>")

	notify { "Found interface $donkey":; }
}

do_this { $ifs:; }

This will output:

$ sudo puppet net.pp
notice: Found interface 172.29.121.22
notice: //Do_this[eth0]/Notify[Found interface 172.29.121.22]/message: defined 'message' as 'Found interface 172.29.121.22'
notice: Found interface 213.207.83.56
notice: //Do_this[eth1]/Notify[Found interface 213.207.83.56]/message: defined 'message' as 'Found interface 213.207.83.56'

Hope this helps someone else! Leave a message if it does.

I miss the sysadmins in here http://i.imgur.com/G7WyP.gif #

Powered by Twitter Tools

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!

I’ll remember her as my little bunny-dog, since she could fetch and come sit on my lap when I called out to her. She was always there when I opened her little house, because she wanted some petting. I’ll miss her.

Tags: bunny, fluffy, pets

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!

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!

# Setup additional services for this vhost, if any are required.
# Start with a general check to prevent a lot of work when it's
# not needed.
if $allow != "" {
           # FIXME Ideally we want something that simply does
           #  for i in allow do include $http::allow_$i
           # but that doesn't work (yet?).
           # W00t! That's going to be added in 2.6! #3871
           if inline_template("<%= allow.include?('php5') %>") == "true" {
                     include allow_php5
           }
           if inline_template("<%= allow.include?('rewrite') %>") == "true" {
                     include allow_rewrite
           }
           if inline_template("<%= allow.include?('ruby') %>") == "true" {
                     include allow_ruby
           }
           if inline_template("<%= allow.include?('python') %>") == "true" {
                     include allow_python
           }
}

echo "select procpid,datname,current_query,now() - pg_stat_activity.query_start as duration from pg_stat_activity where pg_stat_activity.current_query <> ''::text and now() - pg_stat_activity.query_start > interval '5 minutes'" | sudo -u postgres psql

Hope this helps someone!

Tags: automatic, fix, funny, lawnmower

Hoe raadt ie het zo!?!?!

Tags: dutch, error, funny