Initial conclusions on testing different dice client LDAP technologies

• We're looking to move away from the current situation, whereby each dice client maintains a full local copy of the ldap database, synchronised using locally-written replication technology
• Reliability and stability of the system is paramount - if it stops working on a given machine, that machine is often rendered unusable

Approaches considered

proxycache (and proxy no-cache)

• Initially crashed slapd a lot, bug submitted to openldap project - fixed within about a day. Since then has been stable.
• Running test machines in lab and on other standard desktop machines - both proxycache and proxynocache.
• Also running in hermes beowulf cluster - with caching - seems fine.
• Approx percentage of queries answered from cache: typically between about 70% and 80%

nss_ldapd

• Fork of nss_ldap, not yet officially tested for kerberos - documentation indicates that the existing kerberos code has been moved, unchanged and untested, from nss_ldap.
• This suggests it's not sufficiently mature to consider.
• Should be monitored in future

nss_ldap

• Successfully configured to use gssapi kerberos authentication.
• Tested client and works OK.

Conclusions

• Continuity and evolution - continuing to use an openldap solution is a smaller step away from what we're currently running, so our experiences gained over the years will be useful in debugging any problems.
• We prefer a solution with some form of local caching, for client performance reasons (e.g. ls -l on a directory with a lot of files). nscd (which provides caching for name service requests) has proven problematic for us in the past.
• Community support - openldap has a particularly active and supportive community, as evidenced by the busy mailing list and particularly the quick bug-fix on reporting a problem. nss_ldapd is relatively immature. nss_ldap has a relatively quiet mailing list and I get the impression that the kerberos support isn't particularly widely used.
• We have concerns about the implications of loading the kerberos library for every nss call when using nss_ldap (similar loading of libraries occurs with openldap, but this doesn't seem to be causing problems).

There is a danger that we will continue to see similar ldap problems to those we currently see on systems under load when using the proxy-caching solution, as it still requires maintenance of a bdb database. We will need to monitor this. One useful pre-emptive approach would be for the openldap component to ensure it starts with a new, empty database whenever 'start'ing. We should monitor the effects of running condor jobs on standard desktop machines.

Where Next?

 : Units : Infrastructure : Projects 

Please contact us with any comments or corrections. Unless explicitly stated otherwise, all material is copyright The University of Edinburgh