Re: nscd not caching

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.

> > On 2014-8-14, at 13:26, Eggert, Lars <lars_at_netapp.com> wrote:
> > > [Resending to current_at_, since I can't get it to work on -CURRENT
> > > either.]
> > > 
> > > Hi,
> > > 
> > > anyone have an idea why nscd would not be caching NIS lookups?
> > > 
> > > My nsswitch.conf looks as follows:
> > > 
> > > group: cache files nis
> > > hosts: cache files dns
> > > networks: cache files
> > > passwd: cache files nis
> > > shells: files
> > > services: cache files nis
> > > protocols: cache files
> > > rpc: cache files
> > > 
> > > nisdomain is set and ypbind is started, and I see lots of NIS traffic
> > > going in and out.
> > > 
> > > But nothing is cached; running nscd with -t just prints this and then
> > > then nothing, ever:
> > > 
> > > M1 from main: successfully daemonized
> > > M1 from main: request agents registered successfully
> > > M2 from cache: cache was successfully initialized
> > > M2 from runtime environment: using socket /var/run/nscd
> > > M2 from runtime environment: successfully initialized
> > > M1 from main: thread #0 was successfully created
> > > M1 from main: thread #1 was successfully created
> > > M1 from main: thread #2 was successfully created
> > > M1 from main: thread #3 was successfully created
> > > M1 from main: thread #4 was successfully created
> > > M1 from main: thread #5 was successfully created
> > > M1 from main: thread #6 was successfully created
> > > M1 from main: thread #7 was successfully created
> > > 
> > > Lars

-- 
Peter Wemm - peter_at_wemm.org; peter_at_FreeBSD.org; peter_at_yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246