On Sunday 17 August 2014 15:22:02 O. Hartmann wrote: > Am Sun, 17 Aug 2014 13:09:10 +0000 > > "Eggert, Lars" <l...@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 <l...@netapp.com> wrote: > > > [Resending to current@, 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 - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246
Description: This is a digitally signed message part.