OpenLDAP

Last updated: Tue, 13 Dec 2005 11:01:00 GMT

New and improved.

I've had a long-term on and off relationship with OpenLDAP. The first time I used it was around the turn of the millennium, I think 1.2 or 1.3 was the current version back then.

I was impressed.

I was back in the sysadmin seat after a couple of years working elsewhere, writing fake C++ for real money. I was impressed because the last time I'd done any sysadmin for money, free software was a bit of a nightmare. A lot of the current big names were around, but getting the stuff to compile was painful. Especially under IRIX. Oh, the unpleasantness in that lonely backwater.

Well, things had changed while I'd been away, and for the better. OpenLDAP was the first free software I'd downloaded that just worked, straight out of the tin. It did everything right, to my Unix-educated eye. It was simple, it didn't do anything unexpected, configuration was a breeze. Fancy knobs and buttons were relatively few and far between, and it didn't come with pretty tools, but by God it did the job. Compared with the Sun/ iPlanet/ Netscape offering of the time, it was a dream. I could get OpenLDAP installed and running in about the time it took to log into the hideous Java control console that came with iPlanet Directory Server.

Sun put the kibosh on the project I was undertaking -- to replace passwd distribution by NIS with an LDAP authentication service -- by doing that Sun thing they do.

They released Solaris 8 a little too early, it was still undercooked. Instead of providing simple instruction on how to configure a Solaris 8 host to resolve naming requests against an LDAP server, they provided some over-complicated mess of binaries to do the job for you. Great, except that in the first release of Solaris 8, on the architecture that I was running it on, they core-dumped. That's why you should use scripts, guys. Moreover, you should just keep it simple enough that you can just describe the file format, and trust that anyone who gets to the '#' prompt can read.

And they had some whacky scheme for keeping client and server configuration information in the LDAP server, in some awesome schema extension that came with their own directory server, naturally.

IRIX took an exemplary line -- two config files, plain text, one told the name service caching daemon which services to use to resolve which naming queries, and one file told the LDAP component where to find an LDAP server, what credentials to bind with, and an LDAP search filter. Couldn't have been easier. Starting with "apropos ldap", the job was done in minutes.

Well, I put a bug report in to Sun and they confirmed their bad, and also confirmed that their documentation was plain wrong. They told me they'd get back to me when they'd released a fix.

Eight months later, I called them to chase up. They'd closed the bug because "they hadn't heard any further from [me]." Slow hand clap, dudes.

Anyway, the project was forgotten. I moved on to other things.

Every once in a while, I decide I'll get it finished, and then I get distracted half way through. I'll be honest with you: LDAP's a bit of a dry subject. Not a lot of fun. It's become a bit of a running gag, me replacing the NIS service. But the only other person to have looked at it decided that it was too much like hard work, and hard work is not his thing. It's not difficult, just dull.

I got half way there, last time I looked at this, at the beginning of 2005. OpenLDAP was a whole major version older. Solaris 8 is mature to the point of decrepitude, Sun are still total bastards. Some things never change. OpenLDAP 2.1 had to be patched to get Solaris to authenticate against it, because the Solaris LDAP client expected out-of-spec behaviour. Strangely, the contemporary iPlanet descendant just happened to display that aberrant behaviour out of the tin. Funny that. And they're using some jive-ass X.509 certificate format, too. Something Netscapey. I forget. I got bored with it before I completed it and left stuff in CVS.

Well, I'm winding down. I want to get this one finished. So I thought it time to dust off the stuff I left in stasis some ten months ago and get cracking. Finish the first job I was handed, just before I leave. I like the circularity in that.

OpenLDAP has matured a further two minor version since I last touched it. It's at 2.3.11 now. It's still the same compile experience, which isn't such a good thing any more. Making me set environment variables is crufty. I want options to the configure script, not command-line magic. And there seem to be a bunch more wacky back-ends, too. Never mind, I don't have to use them. After a couple of iterations through the configure, make, install loop -- with breaks for writing various crap to environment variable, I've got what I want. I haven't applied the "misbehave for Solaris" patch yet.

Overall, the OpenLDAP experience no longer matches up to the other flagships of freedom I'm happy to stand behind -- BIND9, Apache. In the time I've been away from it, OpenLDAP doesn't seem to have come as far as it should. That goes for LDAP, too. Nowhere near the adoption predicted way back then, and no two flavours the same. Probably because it wasn't really fit for task to start with. Using those ropey old X.500 schemas as a basis for something was all well and good, but it was fairly obvious to me that what we got wasn't particularly well suited to holding the data we wanted to hold. I had hoped that by now some of this might have been ironed out. And extensibility is all well and good, but what you end up with there is what we seem to have -- a hundred different schemas for almost the same purpose, and no hope of consensus. So many options, so little sense. Unless you're already balls-deep in LDAP, where are you going to start? You'll start by finding some other way to solve your problem.

I'm rambling again. And I'm obviously not an authoritative source. I have the slightest passing interest in this. But then, if you want people to adopt your sparkly new tech, it's passers-by that you're hoping to persuade. I'm sadly unpersuaded.

Luckily, the schema for holding NIS information is pretty tight. Little variance there, I suppose, and little room for artistic license. So I'm hoping to press ahead and finally get this project finished.

But the reason I began writing this was to bitch about what looks to me to be an actual retrograde step on the part of OpenLDAP. I decided to start again and ditch the config file I'd half-finished with, and I've got everything done but set up my ACLs, defining who can access which objects, what attributes of those objects. At the core of it, this is the only reason to drop NIS in favour of LDAP.

I decided, at this point, that I should probably give the manual a browse, which is when my heart sank.

They've dropped the configuration file, it seems. It's now "fully LDAP-enabled." Fantastic. It can be managed with standard LDAP operations, they say. That's great, because I was having a really hard time using vi(1). Writing a bunch of LDIF and uploading it with the suparfantastic ldapadd command is a whole lot handier. True, config changes can now be made "on the fly" but I've got to say, I've never had a whole heap of trouble issuing a reconfig command to BIND. So it's surely possible to reconfigure a running daemon without stopping it, even if it's '70s enough to keep its configuration in a plain text file.

I really don't see where the advantage lies, especially not for me. I'm sure someone might say that there's some vapourous advantage in distribution of configuration info, or remote manipulation of config info. Newsflash: ssh does these things for me already, and the fact that I have a dozen other core services to maintain across a number of machines that you can guarantee won't be using LDAP to distribute configuration means that I'm already likely to have solved this problem to my own satisfaction.

I can see them now, wandering through the trees, looking for wood. LDAP is good, therefore sticking everything we can possibly get our hands on into it is good. But it doesn't work like that. They should be making this stuff Just Work. They should be making the switches to their tools consistent. They should be actively developing useful interfaces, suites of integration tools. They should be firebombing Sun. What they shouldn't be doing is making their product any uglier.

The most telling thing, I thought, was this, which I quote from the OpenLDAP 2.3.11 manual:

Some of the entries listed above have a numeric index "{X}" in their names. While most configuration settings have an inherent ordering dependency (i.e., one setting must take effect before a subsequent one may be set), LDAP databases are inherently unordered. The numeric index is used to enforce a consistent ordering in the configuration database, so that all ordering dependencies are preserved.

Uh-huh. If you've got to use lube, chances are you're putting it somewhere it isn't meant to be.