European Bob's Hula Hoopla!

A while ago I posted about updating the Hula schema when upgrading packages, but haven't really had time to look at the various issues since then.

My first problem of translating a diff of the schemas into actual actions is still there, but looks doable. Thing is, it's semi-obvious what to do - but you end up throwing away some of the information that's available to you, which makes me think it might be wrong. I guess the thing to do is try it and see.

The second problem - what information is instantiated by default? Well, I wrote another script to figure that out. Rather than try and work it out from the code, this just looks inside a directory structure that has been created. This isn't necessarily right either, but seems close enough for now. The output looks something like this:

name:root
        object%032class:Top
        t:Tree

name:root/context
        object%032class:Organization
        o:Context

name:root/context/admin
        object%032class:User
        cn:admin
        surname:Admin
        private%032key:aHVsyQ==

These are the first three objects output, in an ldif-ish format with some of my own naming convention :o).

So, I now have a textual version of the schema, and the initial tree. Theoretically, it should now be possible to write a hulasetup which takes those two files and does roughly the same as our current hulasetup (albeit in vastly less code, I suspect). There are three attributes that cannot be stored in the files (they're auto-generated random pads), which I'm not sure what to do with, but although it will be a hack it won't be too bad.

Once we have this new version of hulasetup, it should be possible to do a number of cool things:

• run a tool to repair a directory - fills in the missing parts of the schema and objects, checks the values for validity;
• the "repair" tool would also be pretty good at updating directories to newer schema (there is a potential for dataloss here - e.g., a new attribute semantically replaces another, the latter is an attribute configured by the local admin: blindly putting the new attr in place and deleting the old loses the old configuration. That's not a generally solvable problem IMHO, though);
• opens up the possibility of having hulasetup be made aware of third-party schemas (since the knowledge is no longer programmed in), maybe if we installed stuff into /etc/hula/schemas/ or something (keeping the textual versions around is plainly a good idea);

Next steps: first, see if I can normalise the output formats of these various scripts (maybe even proper LDIF; this would fit in with Pat Felt's ldap plans). Second, write a tool to diff them (diff itself won't cut it for various reasons). Then, write a tool which "actions" the diff via the MDB library, to replace my hulaupdateschema program. Technically, this latter tool could also replace hulasetup (in the special case of comparing a new schema with an empty file). I have a kind-of cunning idea for this last bit too, but we'll see if it's workable.

If you'd like to take a peek at my scripts, they're here (this is a .tar.bz2), including my "hulaupdateschema". Beware with the latter - it was written with my Debian packages in mind, and is a bit hackish - it's certainly not a long-term solution.