OpenDS - YALDAPS and a look at the current playing field

OpenDS.org. Yip. Yet Another LDAP Server. And no, it’s not what you think. OpenDS is not Sun open sourcing their Netscape/iPlanet-derived Directory Server. It’s a brand new LDAP server implementation, written in Java. Unlike Java System Directory Server Enterprise Edition (yes, it just changed names again), which isn’t.

Confused? You should be. It is LDAP, afterall!

Requisite LDAP confusion jokes aside, is there room for another LDAP server in the market? I think there probably is, but only because the current landscape sucks. The level of effort required to get the equivalent of Microsoft’s Active Directory up and running on Linux/UNIX is embarrisingly high. To get a better idea of where OpenDS might fit in, I think we have to survey the DS landscape today…

Some history. There are basically two LDAP servers out there today in common use on UNIX systems: The Netscape one (sold under different names by different vendors, including Sun, IBM, HP, and Red Hat) and OpenLDAP. They’re both complicated, confusing, and frustrating to setup and use, especially for sysadmins with no prior directory services experience under their belts.

OpenLDAP is the default on most Linux systems, and is used by Apple in OS X Server (where they call it OpenDirectory). It’s open source and always has been, and since it’s inception has been the only LDAP server in that category. Netscape is the default in the UNIX space and was traditionally closed source and expensive. I won’t get into which one is “better”, but I think it’s fair to say that the enterprise crowd (the ones with most of the LDAP experience, and, well, the money) largely chose Netscape (usually via their UNIX vendor) and the free software / web crowd largely chose OpenLDAP. In both camps, but especially in the “we’re not a big enterprise” camp, a lot of people chose neither and walked away from LDAP altogether. Too complicated, couldn’t get it working, ran out of time and just stuck with NIS and a MySQL database, wrote a script to push passwd files around, whatever. The bottom line is that LDAP hasn’t been nearly as successful as a generic directory service mechanism as it should have been.

Sidenote: Now that Red Hat has bought up the Netscape/iPlanet suite and open sourced it (Fedora DS is the free one, Red Hat DS is the paid-support version, mirroring the Fedora / RHEL split Red Hat has embarked on for its Linux distros) we can assume that Red Hat will probably default to using the Netscape DS in the future instead of OpenLDAP.

If I had to summarize the differences between Netscape DS and OpenLDAP, it would be this: One is well documented, and one isn’t. In case you didn’t guess, the Netscape LDAP server is the one that’s leaps and bounds better in this regard and now that Fedora DS is out there for free, it’s the one I recommend any sysadmins starting with LDAP take a look at first. Even if you don’t deploy Fedora DS, or Red hat DS, or Sun DS (on 64-bit Solaris — stay far, far away from Sun DS on Linux or 32-bit Solaris) you need to start with the Netscape docs. Because only they actually have chapters about general concepts, systems architecture, and deployment scenarios. The OpenLDAP docs will tell you how to use OpenLDAP, but they won’t tell you how to build directory services. Which means you’ll probably give up and walk away from OpenLDAP before you make it do anything useful for you.

So what’s really painful today? Once you get over the knowledge hump (and it’s not a small one) you’ll find that the Netscape-derived products and OpenLDAP are actually quite good servers. They’re fast, they’re solid. They do replication, they do all sorts of fancy shit. The clients, however, are a completely different situation. They’re largely undocumented, or even worse (I’m looking at you, Red Hat) misdocumented. The clients are dogged by a decade (or more) of legacy config baggage. Legacy crap that will be complete nonsense to you if you didn’t live through the original NIS implementations. Basically, using LDAP is a never ending fight of wrangling various clients (Linux, Solaris, Apache, some random Java software, a PHP app, etc.) into a). fitting into the LDAP directory model b) figuring out how to config them c) fixing and/or reporting the bugs in their implementations.

It’s not pretty. And then you try to integrate Kerberos. And you go insane and quit the industry to pursue a career in lanscaping. (No, I’m not making that up).

So what we really need isn’t a new directory server. What we need is a whole new look at the problem. It needs to be end-to-end. Microsoft and Apple have taken what was already out there and made it workable, why can’t the rest of the UNIX communities? Let’s be better even! Let’s treat the directory server as a web server! Deploy it like a java app server, maybe? Talk to it via a super, super simple REST API that we just cook up in the OpenDS / web communities, perhaps? It will speak LDAP and DSML of course! Let’s work on getting superb client integration, and for heaven’s sake we need to have an integrated Kerberos from day one.

Directory services could be so much better. The fact that all the building blocks are already there is what makes the current state of affairs so frustrating. So I’m glad to see OpenDS. Sometimes all it takes is a fresh look at things for great things to happen.

I’ll keep my list of reasons about why it might fail to myself, because at this point I think the project deserves nothing but good vibes.