UNIX System Administration Handbook - Evi Nemeth [316]
LDAP was originally designed as a simple gateway protocol that would allow TCP/IP clients to talk to the X.500 directory servers that ran on OSI systems. Over time, it became apparent both that X.500 was going to die out and that UNIX really needed a standard directory of some sort. These factors have led to LDAP being developed as a full-fledged directory system in its own right (and perhaps to its no longer being quite so deserving of the L).
At this point (in the year 2000), we are still somewhere in the middle of the development process. The most widely implemented version of LDAP, version 2, lacks many features that will be needed to get LDAP to the same level of functionality and reliability as, say, DNS. Even version 3 of the protocol, which is not yet standardized, appears to have some substantial gaps. Outside of a few specific domains (Internet phone books, sendmail alias configuration, some calendaring applications), real-world experience with LDAP has been limited.
Unfortunately, LDAP has become chum for an industry-wide feeding frenzy of sorts, with everybody and their dog pledging undying support for the protocol. Like Java technology in the mid-1990s, the swirling waters have thrown off a lot of press releases but relatively little actual software. We will just have to wait and see if a beautiful Venus eventually rises from the waves.
Our sense of LDAP is that it may or may not develop further in the direction of helping sysadmins. LDAP hasn’t really found its niche yet. We advise a policy of “watchful waiting” for now.
LDAP documentation and specifications
Currently, the best introduction to LDAP is a booklet called Understanding LDAP written by Heinz Johner et al. for IBM’s International Technical Support Organization. It’s available for download as an Acrobat file from www.redbooks.ibm.com. The parts about the C language programming API can be ignored; all the rest is useful information for system administrators. And don’t say IBM never did anything for you.
The LDAP-related RFCs are many and varied. Some of the high points are listed in Table 18.5. Most of the listed RFCs have version 2 equivalents that are not shown. As this table suggests, most LDAP objects and transactions can be represented in plaintext, which is one of the protocol’s nicer features. It’s easy to generate queries from a script or to set up gateways to other protocols, such as HTTP.
Table 18.5 LDAP-related RFCs
RFC2307 suggests ways of mapping traditional UNIX data sets such as the passwd and group files into the LDAP namespace. This RFC is still classified as “experimental,” which suggests, perhaps, how far we have yet to go before LDAP will really be a viable replacement for systems such as NIS.
Hands-on LDAP
LDAP has been implemented by the University of Michigan, by Netscape, and by others. The best source today is the OpenLDAP group at www.openldap.org, which took over and enhanced the University of Michigan code base. As of mid-2000, there is still very little documentation for setting up OpenLDAP. The “quick start” guide on the web will get you up and running, but the documentation does not provide any information on how to customize or debug the package.
See page 560 for more information about using LDAP with sendmail.
In the OpenLDAP distribution, slapd is the standard server daemon and slarpd handles replication, sort of like an NIS slave server. This scheme adds hierarchy to the server network independently of whether the data is truly hierarchical. When version 3 of the LDAP protocol is fully deployed, we will have true hierarchy in both the data and the infrastructure.
If you want to use LDAP to distribute configuration information