Alan's RamblingsWork

Stephen, I wonder if you recognise this?

Sat, 22 May 2010 18:39:00 GMT

I was reminiscing with Stephen about work yesterday, It's very faded after much use, but I wonder if he'll recognise the hat :-)

Upgrading from Nevada to OpenSolaris the easy way

Wed, 21 Oct 2009 11:26:00 GMT

The OpenSolaris installer is simple and quick to use but it has one significant drawback - it gives you no control of how your disk is laid out. I needed to upgrade my Toshiba R500 laptop from Nevada to OpenSolaris and I had the disk set up with 3 VTOC slices - 2 ZFS pools, one for the root pool and one for a data pool - home dirs, installed software and so on. The final slice is a raw swap device. A straightforward install would have overwritten the entire disk, so I wanted to find a way of installing without clobbering everything. Ed Pilatowicz outlined some time back how you could do a hand-crafted OpenSolaris install to work around this, but I wanted to see if there was an easier way of achieving the same result with a more recent build of OpenSolaris.

My first attempt was to use the OpenSolaris 2009.06 livecd to install OpenSolaris onto a 8Gb USB stick so I could boot off that and have a poke around. That was fairly straightforward, but when I tried importing the existing root pool from the disk I hit a problem - the Nevada build I was running was onnv_124, but 2009.06 was based on 111b and the ZFS format has been rev'd since then so the pool wouldn't import. I then tried to update my USB image to build 125, but the stick wasn't big enough for the 125 BE and the 'pkg image-update' failed. Drat.

Third try was to pull a build 125 livecd image from the internal repo, boot off that and do a fresh install onto the USB stick. As before that worked fine so I rebooted off the USB stick. When I originally installed Nevada I had renamed the root pool from 'rpool' to 'solaris', so I typed 'zpool import solaris' and my existing boot pool on the drive appeared - looking good so far. Next thing to try was 'beadm list', and not only did my OpenSolaris BE show up, but the Nevada BEs on the drive also appeared. Ok, so far so good.

Now I needed to try to get an OpenSolaris BE onto the disk root pool. Worst case I could just blow away the existing root pool on the drive and create an OpenSolaris BE in that, but I wanted to see if I could preserve the existing Nevada BEs if possible. As Nevada and OpenSolaris are very similar and as I was using Nevada 124 and OpenSolaris 125 I figured there was a reasonable chance that if I could just get an OpenSolaris BE into the existing root pool I'd be able to get it into the grub config so I could boot it, even if that meant some hand-editing of menu.lst.

The easiest way to get an OpenSolaris BE onto the disk was to use 'beadm create'. Normally that creates the new BE on the same volume as the source BE, but there's a '-p' flag that allows you to specify an alternate pool to do the install into, which in my case was the existing 'solaris' pool on my disk - so, 'beadm create -p solaris on_125'. That seemed to work OK, so with everything appropriately crossed I typed 'beadm activate on_125' and rebooted. When Grub appeared, my new OpenSolaris BE was listed along with my existing Nevada ones, and both the OpenSolaris and Nevada BEs work just fine. Huzzah!

So, to summarise, here are the steps:

Make sure you are running a recent Nevada release
Obtain an OpenSolaris LiveCD image that is close to or the same as your Nevada release
Install OpenSolaris onto a spare disk - a 8Gb or larger USB memory stick or a USB disk will do fine
Boot into the OpenSolaris image
Import your existing root zpool - see below why this many not be as easy for you as it was for me
Create a new OpenSolaris BE on the imported pool with 'beadm' using the '-p' flag to specify the imported pool
Activate the new BE
Reboot, and you should see your existing Nevada BEs along with the OpenSolaris one which will be booted by default

Some caveats - this is clearly unsupported, don't be surprised if it doesn't work with a different mix of OpenSolaris and Nevada builds and don't blame me if it fries your machine. Also, this isn't a true upgrade in that you end up with a new OpenSolaris install and you'll have to manually migrate the necessary config from your Nevada BE into the OpenSolaris one - but at least you'll still have your Nevada BE :-) The final thing is I definitely got lucky - When I originally installed I'd renamed my Nevada root pool from 'rpool' to 'solaris'. That meant I could import it without it conflicting with the name of the root pool on the USB stick. If I hadn't done so I'd have to have imported it using the pool identifier and a new name. That would almost certainly have invalidated the contents of the menu.lst on that drive, so unless beadm fixed it up for me I'd have had to do some surgery to fix it up. If you try this yourself and figure out what's needed, please drop me a comment to let me know what you did :-)

The new opensolaris.org user management webapp moves into the light

Fri, 28 Sep 2007 15:48:25 GMT

As outlined here I've been working away on providing the infrastructure needed to break up the current monolithic J2EE application used to host opensolaris.org. I've just released the source code of the existing portal, a large J2EE application. As detailed in the restructuring document, the intention is to split the functionality of the current webapp into smaller, more manageable parts. As I was releasing the portal code, I thought it was a good time to move my development repository outside as well. Accordingly, you can browse the source at:

http://src.opensolaris.org/source/xref/website/auth/trunk/

and the source can be accessed via anonymous SVN at:

svn+ssh://anon@opensolaris.org/svn/website/auth

It is *very* rudimentary and is *far* from being finished. What I've put on opensolaris.org is just a snapshot of my development workspace as of today. However the database schema is available, along with a small set of dummy data which is used to populate the Derby database currently used by the prototype webapp.If you have any questions, I encourage you to subscribe to the website-discuss mailing list and ask them there.

Source code for the opensolaris.org portal released

Fri, 28 Sep 2007 15:41:22 GMT

After a long haul, I've finally released the source code of the J2EE web application that runs the opensolaris.org website. If you are interested, the source can be browsed online at:

http://src.opensolaris.org/source/xref/website/portal/trunk/

and the source can be accessed via anonymous SVN at:

svn+ssh://anon@opensolaris.org/svn/website/portal

If you have any questions, I encourage you to subscribe to the website-discuss mailing list and ask them there.

Enjoy!

Why I hate XML configuration files

Thu, 05 Apr 2007 14:38:44 GMT

I'm working on a reasonably large (1000+ source files) J2EE application that makes extensive (some might say utterly excessive) use of external components - it requires in the order of 50 JAR libraries to run, over and above the standard J2EE ones.

And of course many of those JAR files have their own unique XML files to configure them.

And of course many bits information related to the configuration of the application (URLs, database details etc) have to be repeated in more than one of those XML files.

And there's no global way of doing this.

So the people who originally wrote the application came up with a scheme - they'd store the configuration values in property files.

But that only helped for things that got the values dynamically, for example by using the J2SE Properties class. All those external components they'd used didn't know anything about the application's property files, they only knew about their own unique little XML files.

So the people writing the application came up with another scheme - they'd embed tokens in all those little XML files, then use the Ant Filter task to replace them at build-time with the values from the property files.

"Job's a good 'un!" they doubtless exclaimed, flushed with their extreme cleverness.

Then I came along and had to maintain the beast, when I found:

There are in excess of 50 of these properties, which makes configuring the application more than a little tedious and more than a little error-prone.
The names of the tokens processed by the Ant Filter task and the names of the properties used to set their values mostly bear very little relationship to each other.
There is no consistently-applied property naming scheme. There are in fact several inconsistently-applied naming schemes.
Some of the properties are just renamed versions of other properties. Sometimes they are inconsistently renamed versions of other properties. Sometimes they don't appear to be used at all.
It isn't clear when reading a property file which properties are only used at compile time by the Ant Filter task, and which properties are only used at run time. It's also unclear which ones are used at both compile and run time.
The compile-time use of properties is a killer because it means the application can't realistically be reconfigured without recompiling it - because the use of the Ant Filter task means the compile-time property file values end up hard-coded in many different places. It's therefore pretty much impossible to produce a version of the application that can be deployed on more than one machine - for example for development or test purposes.

All this means that there's a whole series of bear traps set for anyone who innocently changes any of the properties files of the application, in the mistaken assumption that the application will actually take any notice of them.

I'm sure I'm not the only person to have been hit by this problem - how to configure multiple external components which all have their own XML configuration files - without having to hand-edit each of the XML files each time every time something changes, and without hard-coding the configuration at build time. However I'm damned if I know of a good way of doing it - although I can easily think up several not-very-good ways of doing it.

If you know, please let me know!