nscd not caching

[Eric van Gyzen]

On 08/19/2014 09:14, Harald Schmalzbauer wrote:
>  Bezüglich Peter Wemm's Nachricht vom 17.08.2014 19:18 (localtime):
>> On Sunday 17 August 2014 15:22:02 O. Hartmann wrote:
>>> Am Sun, 17 Aug 2014 13:09:10 +0000
>>>
>>> "Eggert, Lars" <lars at netapp.com> schrieb:
>>>> Nobody using nscd? Really?
>>> I can only speak for myself and I stopped using nscd since the support is
>>> crap.
>>>
>>> A while ago (t > 1 1/2 years) I realised within a OpenLDAP environment, that
>>> when nscd is running, sometimes the system simple "forgets" about root -
>>> this is painful while installing/updating ports and getting interrupted
>>> with a weird error "unknown user root".
>>>
>>> nscd is supposed to be used in large environments where the cost for a user
>>> lookup, like in OpenLDAP, is worse. But obviously FreeBSD isn't used in
>>> that large environments with OpenLDAP and I'm wondering what the purpose of
>>> nscd is.
>> The other problem is that net/nss_ldap and security/pam_ldap have kind of been 
>> left behind for performance and robustness.  People who use this seriousy tend 
>> to discover net/nss-pam-ldapd fairly quickly which has its own caching proxy 
>> and eliminates the need for nscd.
>>
>> With nss_ldap and pam_ldap, the openldap client libraries and startup cost is 
>> linked into every single binary that uses it.
>>
>> WIth pam-nss-ldapd, it's a simple unix domain socket (with peercred 
>> authentication) and no heavy-weight libraries in the consumers. The proxy on 
>> the other end of the socket keeps a ldap connection open (with an idle 
>> timeout).  The whole thing was vastly more robust and efficient.
>>
>> At least that's what we found in the freebsd.org cluster.  nss-pam-ldapd was 
>> two or three orders of magnitude more usable and got rid of nscd in the 
>> process.
>>
>> For us, nscd "worked", but it just didn't save much effort because it was a 
>> per-uid cache.  ie: if "jkh" had just caused a ldap search, and "peter" 
>> repeated it, it had to be done again from scratch.
>>
>> The downside for nss-pam-ldapd was that it uses a non-extensible wire protocol 
>> and didn't have room for bsd-style login classes.
> This exactly refelcts my experiences too, which is why I'm wondering if
> net/nss-pam-ldapd is a serious base candidate.
> When nscd showed up (arround 7.0-Release if I remember correctly), it
> was a big and highly appreciated improovement for me, reducing
> interactivity lags of gnome e.g. by at least a factor of 4 for usual
> desktop user tasks when user database was LDAP driven.
> At that time there were rumors that FreeBSD needs LDAP user-database
> support, but with the glitches of net/nss_ldap, it seemed that there's
> no ready-to-implement solution at that time.
> Things changed completely with net/nss-pam-ldapd. Haven't had any
> negative experiences with single-LDAP backend networks. Haven't had big
> environments yet either, but I think it's time to think about
> base-LDAP-support again. net/nss-pam-ldapd is GPL licensed, so I guess
> it won't get into base, but it was a great template, is it?

+1 for nss-pam-ldapd.  We were using nss_ldap+pam_ldap, but switched to
nss-pam-ldapd.  It's much faster and very reliable.  We have several
multi-user FreeBSD systems (build servers, doing lots of lookups),
dozens of concurrent users and hundreds of total users, and Active
Directory servers.

The way nss_ldap links the LDAP libraries into every process is not just
inefficient: it can be fatal.  Thunderbird includes (or formerly
included?) its own private LDAP libraries.  These conflicted with those
used by nss_ldap, so that Thunderbird would often crash.  I don't know
if this is still a problem, but it's not /my/ problem anymore.

As for the base system, "pkg install nss-pam-ldapd" is embarrassingly
easy and /much/ easier than adding to the base system.

Eric