European Bob's Hula Hoopla!

I will start by saying that I think getting someone's installed configuration upgraded is something key Hula needs before being releasable - we can't ask people to blow their config every time something needs to change. Also, keeping an old schema about because we have no useful tools to change things is fairly undesirable too. This is something I'm looking at as part of the packages I put out for people to try, but is driven by my need to use Hula and keep up with the latest versions.

So, let's look at the latest schema updates in r244, which is the first time I've had to do this "for real", as it were. First, part of a diff of two /var/lib/hula/mdb/ directories - one clean r240, one clean r244:

diff -Nadru hula240/mdb/schema/classes/hulacmrdnsmodule/name hula244/mdb/schema/classes/hulacmrdnsmodule/name
--- hula240/mdb/schema/classes/hulacmrdnsmodule/name    1970-01-01 01:00:00.000000000 +0100
+++ hula244/mdb/schema/classes/hulacmrdnsmodule/name    2005-06-19 22:52:02.000000000 +0100
@@ -0,0 +1 @@
+HulaCMRDNSModule

This is basically the mdb-file representation, which is the only one I care about right now :) This is just one attribute added - there are lots of attributes added to new objects, and new schema to go along with them.

Now, what I don't want to do is go about applying arbitrary diffs to configurations - what I want to do is be able to take two written schema, diff the schema, and then process that change. So the first thing I wrote was something which extracted the schema from hulasetup, and wrote it out in a simple text format. The results of diff'ing r240 and r244 in this way looks like this:

> class:HulaCMRDNSModule
>       name:HulaCMRDNSModule
>       asn1:NULL
>       flags:0
>       class: 0
>       class:262144
>       superclass:HulaConnMgrModule
>       naming:CN
>       containment:NIMS:ConnMgr Agent
>       containment:NULL
>       mandatory: NULL
>       type:standard

So, before doing this properly via the mdb library itself, I wanted to translate that into action we could take to update the configuration - we know that there is a new class, so we at least need to add that class to the schema. What I want to do is turn the above into this:

'classes/hulacmrdnsmodule' => {
	containedby     => 'NIMS:ConnMgr Agent',
	flags           => '0',
	name            => 'HulaCMRDNSModule',
	naming          => 'CN',
	superclass      => 'HulaConnMgrModule',
},

And this is where I'm currently running into trouble. The code above is a fragment from my perl schema update script, based on a diff of two clean directories setup by different versions of hulasetup. But, I don't want to diff directories and figure it out by hand (virtually), I want to extract the schema and diff that - it's much easier. But, I haven't figured out how to do that :).

There is then the secondary problem of figuring which objects are actually instatiated by hulasetup - something that the embedded schema doesn't/can't encode. So, we really need two schema - the first defining objects and their attributes, the second defining a clean initial tree in terms of the first. This might take a few days :/

So, my r244 package is finally here. This took longer, for a couple of reasons:

• this is the first time the MDB store has been upgraded to take account of a new schema. I'm not sure how well this will work, but it works for me and it's better than nothing - the alternative is still nuking the config;
• some of the patches needed updating, in particular, one seems to have bitrotted badly :(

Please backup your /var/lib/hula before you install this package.

I would post the link but I can't be bothered to find it again :)

And gasman is also on there. It seems that lugradio have been interviewing Novell employees every episode for ages. But then, I don't listen to them that often :)

campd is talking about the CalDav backend, and how the web thing will talk caldav at Hula. Apparently code gets out in just over a week or something.

The one innovative feature I want in Hula is some weapon to point at the useless, useless cretins whose out-of-office messages take no regard of bulk mail flags (not just looking at the Groupwise subscribers on hula-*, but also people on local LUG lists). I didn't hear Dave mention that though.