You are here: Home / Blogs / OpenLDAP to 389 Directory Server in 30 seconds ...

OpenLDAP to 389 Directory Server in 30 seconds ...

by Alan Milligan — last modified Feb 13, 2013 06:55 AM
Filed Under:

and most of that time was doing the yum install ...

OpenLDAP has served us well for over a decade, and whilst there's absolutely nothing wrong with it, 389 Directory Server has some superior features within our operational environment.  I finally bit the bullet and did the migration - in-place, and in no time flat.  Sure, we've only got about a thousand records in our production LDAP, but it is critical infrastructure.

How did I do it?  Easy.  I used our OpsCode/Chef configuration management system against our BastionLinux/AIM software channel/yum repository.

We use RPM to deploy all of our static configuration - I simply copied our custom LDAP schema extensions, converted these to 389 DS format and cut a 389 DS variant of our existing openldap schema RPM.

We've a quite sophisticated Chef cookbook, a variant of which was used in probably the largest public sector LDAP project in Australia last year.  In addition to accepting arbitrary schema RPM's, configuring setup.ini's, TLS certificates, clustering, monitoring etc, we've defined Chef resource/providers for bespoke indexes and loading LDIF files.

It was quite straightforward to compose a slapd2ds recipe which slapcat's the OpenLDAP database to a file, removes slapd from SysV init, does a couple of Perl munges to change a couple of mismatched objectClasses and remove the surplus entryUUID, entryCSN attributes.  After that, it simply calls the above recipe and 389 DS is set up and auto-loaded with the cleaned up LDIF data...

A couple of test runs had been performed bootstrapping a development KVM image with 389 DS and the production data so I was fairly confident that the recipe was producing the desired outcome.  In the event that it had not, it would have been trivial to fall back by restarting the slapd daemon and slinking back to the test server for some more tweaking.

So we're now getting enterprise strength cn=monitor statistics in Zenoss with our ZenPacks.lbn.LDAPMonitor ZenPack, email delivery and authentication and portal SSO continues to function transparently, and all with just a 30 second production outage.

And now that it's been written, this recipe can be used to migrate any customer's OpenLDAP - albeit that it may take slightly longer for an installation of 2M+ records...

Filed under: SSO, Technology, LDAP
Tag Cloud
Weblog Authors

Alan Milligan

Alan Milligan

Alan Milligan

Location: Sydney, Australia
Alan Milligan
Alan is the principal technical architect of Last Bastion Network solutions in Australia. Alan's background is in application development with a number of global titans of retail and investment banking. Alan also has a history of CIO roles for a number of start ups where he delivers business value with open source solutions. Talk to Alan about how you can deliver critical infrastructure while mitigating risk and managing your existing vendor relationships.