>>>>> "BJ" == Brian K Jones <jonesy@CS.Princeton.EDU> writes:
BJ> This is discouraging, as I had planned to put OpenLDAP into
BJ> production, after evaluating eDir and, to a lesser extent, the Sun
BJ> product. Aside from GUI tools and docs (which I don't have a
BJ> particularly dire need for), where is OpenLDAP lacking compared to
BJ> eDir and Sun? Why shouldn't I put this into production?
Rather than argue why you might *not* want to put OpenLDAP into production
I put forward some datapoints that might help dispel what looks to me like
FUD in the book you read.
In the Computing Services at the University of Oxford we are currently
running OpenLDAP to support a user database of approx 30000 users for a
mailstore cluster called Herald. This is a critical core service and
might be considered the equivalent of a 'business application'.
We replicate the user database across three OpenLDAP instances which
supports queries from the MTAs for
- intercluster routing
- forwarding
- vacation autoresponse
- a primitive filtering flag
Queries from IMAP and POP servers for
- login authentication (via pam_ldap)
We recently added an interactive shell service using additional machines
in another cluster and were able to get user management 'for free' again
via pam_ldap making LDAP binds against the Herald cluster OpenLDAP
servers. [We also wrote a PAM module to create homedirs on the fly at
first login - pam_mkhomedir was insufficient for our particular needs.]
We had some initial teething problems and certainly saw some index
corruption that would result in user entries not getting returned in
searches even though the search predicate for that entry was true (by
inspection). Unfortunately I was never able to reproduce or figure out
exactly what triggered the corruption. It occurred during the time we
were doing bulk updates via ldapadd rather than slapadd. We never lost
data. Stopping slapd and running slapindex was insufficient; instead we
had to stop slapd, slapcat and then slapadd.
The Herald mailstore was an existing running service. We switched it to
use this OpenLDAP based setup and have been running without problems since
since end Sep 2002.
BJ> Interestingly, the author doesn't give an opinion on Linux, and
BJ> the first chapter in the book was 'Active Directory', IIRC.
We do all the above on running Debian GNU/Linux on x86 hardware.