I've had a few dramas with the Open-source software we use at work, and I need to have a slight rant to get some things off my chest.

Our boxes run the long-term support releases of Ubuntu server edition - which has to date been a solid and reliable baseline.

libstdc++5

The biggest drama is that the latest LTS version of Ubuntu (Lucid) does not provide libstdc++5. Apparently the package maintainers for gcc-3.3 decided it was too old to continue supporting (not unreasonable). What they didn't realise (or rather, didn't care about) was that it was the last release to support glibc v2.

Unfortunately nobody picked up on this until after the feature-freeze and release of Lucid, which means that a whole swag of commercial third party applications that have to target wide install bases (including RHEL, etc) - will no longer run on Lucid, which we're stuck with for the next few years.

This isn't such a big deal, except for the fact that this includes MySQL Enterprise - the big important database boxes on our network.

Our systems work smoothly because we only use Ubuntu-provided packages for the system - I'm not about to trust something as important as our database servers on a package I've kludged together. I also refuse to taint the Lucid database boxes with another release's packages.

So for now, those boxes stay on Hardy, until Bug #618666 and Bug #600321 are resolved. But that's ok, fortunately (now, anyway) people have realised it's actually a bit of a big deal for people running production systems.

OpenLDAP's cn=config

Ok, so for anyone who has tried to package configurations for OpenLDAP... you'll know its a bit of a hassle. Actually, it's a PITA - especially with the way OpenLDAP behaves with upgrades and whatnot.

Fortunately, it looks like Ubuntu are running with OpenLDAP's cn=config configuration schema. Hooray, fanfare, etc - managing dot-d style configurations are a heckuva lot easier for managing configurations.

But... it's not a configuration directory - it's a configuration database. Big difference, because you're not supposed to edit databases.

Okay, so to be fair - the OpenLDAP documentation does tell you to use LDIF to inject new configuration data into the system. But it certainly makes no mention that the slapd.d folders aren't user editable - and it does explain in some detail how the folders are parsed by slapd - so it's not suprising that this is a point of confusion.

Not suprisingly, I had some problems when trying to load some schema objects by editing the LDIFs in this directory.