Re: nscd not caching

 Bezüglich Eric van Gyzen's Nachricht vom 19.08.2014 15:39 (localtime):
> On 08/19/2014 09:14, Harald Schmalzbauer wrote:
>>  …
>>> 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.

'pkg install' is incredibly convenient these days, for sure, but in my
world, hosts that don't need internet acces don't have internet access
(4 out of 5).
To make things worse, nfs exports aren't root-mapped (other than the
default nobody:nobody), so I quiet often have the case that I have to
provide net/nss-pam-ldapd via ISO-9660 image (for VMguests) or CD-media.
That's not so convenient.

Another limitation of 'pkg install' is that I can't influence what to
install. Sometimes I want nss_ldap without pam_ldap. Therefore I'd need
a compiler (somthing my production machines don't have) and ports, which
in my case can't be fetched from internet nor from the NFS server (the
latter has to be entered as LDAP user…)

That's why I'd love to see base system LDAP support – I think it's very
important to be able to setup a network computer in networks, which
aren't interconnected with other networks/internet; these days more
important ever since possible…

-Harry