LDAP Sucks

Posted on by James Cape

Blog Blog Blog Blog Blog.

So at work, I’m filling in an LDAP directory so we can statically map all our computers to IP addresses when we move everything to a new subnet—part of our 5-Year Plan to give everything it’s own hostname, which will go a long way towards offering some slickness for remote management and such. Unfortunately, our firewall guy has decided to drop out of school after everything’s moved over, which really sucks—though I was worried about how we were going to hire and train someone to maintain this ugly, ugly LDAP setup after I’ve left.

See, the problem is that LDAP (like all hierarchical directories) is a broken way to organize information. Information, like everything else, is rarely strictly hierarchical. Often the user may wish to sort their data into different categorizations. So if you keep all your photos in ~/Images, how do you remember that a photo in there the inspiration for a paper you wrote and stored in ~/Documents/School/BlahBlahBlah 475. You can add notes to the files, or create symlinks, or whatever, but those are all hacks, and things like Storage go a long way towards realizing this fundamental problem with hierarchical storage systems.

Basically, there may be broad hierarhic tendencies within information, but at some level of detail, particularly the level which LDAP operates at, it makes next to zero sense. For example, it’d be nice to keep all the information about a particular computer in one place. It’d be nice to have MAC address, IP address, warranty information, serial number, etc. all grouped together. Unfortunately the only way to do that in LDAP is to create whole tree for each item, and then add the extra stuff which uses different objectClasses to sub-items, often with overlapping information. Needless to say, that sucks, since you’ve got the same info with different keys, in multiple places. It’s also extremely aggrivating to know that I could do the same thing in a non-suck fashion with redland, apache, using XML-RPC and RDF fragments, if only DHCP, DNS, PAM, and NSS supported it.

So rather than having (as an LDAP directory tree, thanks to ugly objectClass nonsense):

dc=yoursite,dc=org
    ou=Hosts
        dc=somehost.yoursite.org (DNS, has IP address, MX, and hostname aliases)
            cn=somehost.yoursite.org (DHCP & /etc/hosts, has HW Address, IP address, and hostname aliases)

you’d just have a series of:

<somehost.yoursite.org> <#ipaddress>  <0.0.0.0>
<somehost.yoursite.org> <#ip6address> <::>
<somehost.yoursite.org> <#macaddress> <00:00:00:00:00:00:00:00>
<somehost.yoursite.org> <#hostalias>  <yoursite.org>
<somehost.yoursite.org> <#mxrecord>   <mail.yoursite.org>

statements, then do a query on a particular subject, predicate, or object (as you can do with LDAP). It doesn’t suck, and it more properly represents the fact that information is not hierarchical, it is networked. Using RDF/XML, you even have a standardized format for “links” using (IIRC) “rdf:data”—though the server would probably want to dereference these by default.

But it’s also possible I just don’t understand/appreciate LDAP. As my boss noted, it was every sysadmin’s dream to keep all the info you need in one network-accessible place, too bad LDAP makes it a nightmare.

4 thoughts on “LDAP Sucks”

  1. There shouldn’t be any need to split your LDAP objects up like that. You should be able to put all the required objectClasses into just “dc=somehost.yoursite.org,ou=Hosts,dc=yoursite,dc=org”. A single distinguished name in LDAP can have multiple objectClasses. So instead of adding extra objectClasses as subitems, just add those objectClasses to the item itself and fill in the values with data, and you’re home free.

  2. As Derek mentioned in the comment above – you ‘multiclass’ your items in most LDAP directories.
    Each user object is objectClass=Top & objectClass=inetOrgPerson, for example.
    We actually do what you are apparently looking to do (store host information, etc, in LDAP) with Novell’s eDirectory now.
    Can I suggest a different structure, if you’re going to use the ‘dc’ component for a base structure thought?
    Why not use:
    dc=”yoursite.org”
    host=”www”
    host=”smtp”

    I break things up like that, and have a full tree w/users, etc like so:

    O=”myOrg”
    ou=”some department”
    ou=”another dept”
    dc=”mysite.org”
    cn=”www”

    And simply make cn=www,dc=mysite.org have a ‘host’ class or something.

    Also, with regards to ‘links’ – LDAP supports alias objects and dereferencing on either server or client side (well, not sure if openldap supports either type…eDirectory can do it transparently if you want it to).

  3. Oh, LDAP sucks big time. it doesn’t even have a real command line client. I mean a client that you tell what to do, not submit batch files to which contain excruciatingly exact contents explaining to ldapmodify or ldapadd what to do. There isn’t a decent set of documentation anywhere for it, and the o’reilly book assumes you are already an expert.

  4. I agree that LDAP sucks, but for some altogther different reasons:

    1. DNs are really dumb…
    why do i need to write uid=12345678,ou=people,o=finance,dc=example,dc=com,dc=au?
    Why not just 12345678.people.finance.example.com.au?
    (Certain products, e.g. Sun’s JES suite, tend to make this problem worse…)

    2. Updating schema, ACIs, etc are a pain.
    Why can’t they store the schema hierarchially?
    e.g. cn=person,ou=objectclasses,cn=schema
    and then have MAY,MUST,SUP etc. as attributes?

    Likewise, make acis separate objects…
    aci=helpdesk-write-access,dc=example,dc=com,dc=au

    (Looking at the docs, it APPEARS that Microsoft AD handles this a bit more sanely than Sun or Novell do… although I’ve barely touched AD so it might not be so simple in practice…)

    I could go on…

Comments are closed.