MyHair's Journal: LDAP Fun For Geeks

I wrote this in response to this post and decided to move the bulk of it here to not be quite so obnoxiously off topic.

Oh, what the heck, might as well quote the parent here:
-----

(This from a guy who is migrating his address book to OpenLDAP because he doesn't want to sync between two PCs.)

Hey, how's that working out for you? I've been thinking of doing exactly that for a couple years now, but people have told me OpenLDAP is kind of a pain to set up for such a simple task and I really know nothing about it. Mac OS X's Address Book LDAP preferences include options like "Search Base" (for example, ou=people, o=company) and "Scope" (base, one level, or subtree); is this more complicated than I want to mess with?

-----

Reading through OpenLDAP manuals can make it sound confusing, but Debian actually did most of the setup via Q & A. I'm not sure if Fink will make it as easy or not. Probably will, though.

The point of confusion is that LDAP can be used for so doggone many things. If you're using it for an address book just think of it as a hash-style database (which it really is on the backend) organized in a tree.

The traditional layout of the tree has the root level of your LDAP server as "o=company" or "o=company,c=country". (o is organization, c is country, ou is orgazational unit, dc is domain component, cn is common name, dn is distinguished name; dn's are the unique keys.) The vogue now is apparently to follow your domain name structure and have your root as "dc=slashdot,dc=org" for example. (I think in theory all LDAPs everywhere should be mergeable and have unique bases, but I'm not sure.) It's common to put the contact info under ou=people, so your LDAP settings in the client will look like "ou=people,dc=slashdot,dc=org" maybe or the old style "ou=people,ou=slashdot,o=osdn,c=us".

If you export your local address book to LDIF and look at it in a text editor you'll see all sorts of cn's, dn's, objectclasses and such. Look them up for fun, but basically each entry needs a dn which can be the cn followed by the ou's and base or it can be uid (user id) or probably many other things depending on what you want to key on. dn's need to be unique.

Here's where I'm hung up because I've been to lazy to fix it: My exported addresses from Mozilla have dn's like "dn: cn=Name,mail=[e-mail]", and I have to change all those dn's to fit into my LDAP base like "dn: uid=(uniquenumber), ou=people, dc=mysubdomain, dc=gotdns, dc=com". (Like I said you can key on things other than uid if you want. Also I'm not required to put them in ou=people, but what the hey, why not.) I didn't see a utility anywhere that would fix that for me automatically, so I'll have to either hand-edit or script the changes before I can use slapadd to bulk load them into my directory.

I did hand-load a couple of address entries and it works great!

Oh, and scope is the type of query. Set your search base to match your LDAP setup and either base or subtree would work fine I think. If you get really curious there are a couple of RFC's on LDAP queries that are neat reads. Then if you get really crazy like I might then you might integrate Kerberos and get your MS boxen to authenticate to your Unix box ;-).

P.S. Phroggy, I just noticed your user number and web page. Heck, you ought to do it just for the tinkering fun. I'll add a couple of technical things: the backend db can be Berkeley DB or ldbm or a couple of other things; they are library/file-based db's. slapd is the server daemon; slapadd will load the db while slapd is offline, or you can use ldapadd or other ldap clients to update while it's online. But the Debian package installed the db libraries and configured slapd.conf for me based on curses-based config screens. It was amusingly simple after I spent all that time reading up on OpenLDAP. But as usual the "simple thing" threw me: export to LDIF, import to LDAP, right? Uh-oh, gotta edit the dn's first.