# Usefulness of nscd in combination with nss_ldap

## glauche

For many years now, I had been used to think of glibc's name service cache daemon (nscd) as a piece of software that would only make passwd/group/hosts database lookup less reliable and more difficult to maintain.

However, I've encountered some facts that made me revisit this decision:

Our user and group database is stored in LDAP, and we use nss_ldap/pam_ldap/OpenLDAP to do identity lookup and account management. Without nscd, this means that

about each and every program/service on a client computer wants to open a connection to the LDAP server for user/group lookup. In a default nss_ldap configuration, this quickly leads to a denial of service on the LDAP server, because all of those connections are kept open until the client program exits.

there is a longstanding incompatibility between mozilla/firefox/thunderbird's LDAP implementation and OpenLDAP - see e.g. https://bugs.gentoo.org/show_bug.cgi?id=391807.

There is a nss_ldap configuration option oneshot to close connections after each request. However this also has drawbacks:

A bug in nss_ldap, which leads to incomplete enumeration of group membership for users. See e.g. https://bugs.gentoo.org/show_bug.cgi?id=449940.

This does not close all connections, so LDAP servers might still deny service because of too many open connections.

If one forces the LDAP server to close idle connections, the cluster job management system sys-cluster/torque fails to look up users properly.

It does not solve the thunderbird problem.

Now, enter nscd. If started early enough in the boot process (i.e. right after basic networking has been set up), nscd is the only program on a client computer that makes a direct connection to the LDAP server. This has the following effects:

Only one connection per client to the LDAP server. This is fine, and there is no need to make this connection oneshot on the client or force it to close on the server.

No need to patch nss_ldap.

thunderbird does no longer link dynamically to libnss_ldap (and thus not to OpenLDAP). This makes thunderbird work without removing its own LDAP capabilities (e.g. Addressbook lookups).

sys-cluster/torque is happy as well.

Although I believe that all of the issues listed above are kind of bugs in the software packages mentioned, re-introducing nscd seems to avoid these problems all at the same time. I'll have to look at long-term stability effects of nscd, but so far it seems to be a workaround to my problems. What are others experiences with nscd/LDAP?

----------

## hika

I totally agree, but I just found out that nss_ldap won't merge against glibc-2.16.0. So keep an older stage3 around with glibc-2.15-r3.

I know stage3-amd64-20131010 does! Merging before the glibc update keeps it working, but do not remerge after the glibc update. Your system will be broken for nss ldap. And nscd or unscd won't help.

Hika

----------

