Initial conclusions on testing different dice client LDAP technologies
Firstly, we should make a couple of points:
- 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
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
- Approx percentage of queries answered from cache: typically
between about 70% and 80%
- 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
- Successfully configured to use gssapi kerberos authentication.
- Tested client and works OK.
We have a preference for pursuing the openldap proxycaching solution
for the following reasons:
- 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
- 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
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.
The proposed way forward for this project would be for us to
systematically expand the testing of the proxycaching solution, such
that we can continue to monitor its reliability and gauge the
implications and requirements for remote servers.
Toby Blake, November 2007
Please contact us with any
comments or corrections.
Unless explicitly stated otherwise, all material is
copyright The University of Edinburgh