Date: Sun, 17 Aug 2014 10:18:13 -0700 From: Peter Wemm <peter@wemm.org> To: freebsd-current@freebsd.org Cc: "Eggert, Lars" <lars@netapp.com>, "O. Hartmann" <ohartman@zedat.fu-berlin.de>, "current@freebsd.org" <current@freebsd.org> Subject: Re: nscd not caching Message-ID: <2295097.hWnAh3kd1o@overcee.wemm.org> In-Reply-To: <20140817152202.6ec8e374.ohartman@zedat.fu-berlin.de> References: <FA0C5D1E-780A-4B01-8513-5A4B77DA051D@netapp.com> <D86D34C6-B5E8-4141-BD9F-FF88B056DF6B@netapp.com> <20140817152202.6ec8e374.ohartman@zedat.fu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2400597.UVvrdKI6Fg Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Sunday 17 August 2014 15:22:02 O. Hartmann wrote: > Am Sun, 17 Aug 2014 13:09:10 +0000 >=20 > "Eggert, Lars" <lars@netapp.com> schrieb: > > Nobody using nscd? Really? >=20 > I can only speak for myself and I stopped using nscd since the suppor= t is > crap. >=20 > A while ago (t > 1 1/2 years) I realised within a OpenLDAP environmen= t, that > when nscd is running, sometimes the system simple "forgets" about roo= t - > this is painful while installing/updating ports and getting interrupt= ed > with a weird error "unknown user root". >=20 > 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 purp= ose of > nscd is. The other problem is that net/nss_ldap and security/pam_ldap have kind = of been=20 left behind for performance and robustness. People who use this seriou= sy tend=20 to discover net/nss-pam-ldapd fairly quickly which has its own caching = proxy=20 and eliminates the need for nscd. With nss_ldap and pam_ldap, the openldap client libraries and startup c= ost is=20 linked into every single binary that uses it. WIth pam-nss-ldapd, it's a simple unix domain socket (with peercred=20 authentication) and no heavy-weight libraries in the consumers. The pro= xy on=20 the other end of the socket keeps a ldap connection open (with an idle=20= timeout). The whole thing was vastly more robust and efficient. At least that's what we found in the freebsd.org cluster. nss-pam-ldap= d was=20 two or three orders of magnitude more usable and got rid of nscd in the= =20 process. For us, nscd "worked", but it just didn't save much effort because it w= as a=20 per-uid cache. ie: if "jkh" had just caused a ldap search, and "peter"= =20 repeated it, it had to be done again from scratch. The downside for nss-pam-ldapd was that it uses a non-extensible wire p= rotocol=20 and didn't have room for bsd-style login classes. > > On 2014-8-14, at 13:26, Eggert, Lars <lars@netapp.com> wrote: > > > [Resending to current@, since I can't get it to work on -CURRENT > > > either.] > > >=20 > > > Hi, > > >=20 > > > anyone have an idea why nscd would not be caching NIS lookups? > > >=20 > > > My nsswitch.conf looks as follows: > > >=20 > > > 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 > > >=20 > > > nisdomain is set and ypbind is started, and I see lots of NIS tra= ffic > > > going in and out. > > >=20 > > > But nothing is cached; running nscd with -t just prints this and = then > > > then nothing, ever: > > >=20 > > > 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 > > >=20 > > > Lars =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart2400597.UVvrdKI6Fg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJT8OPZAAoJEDXWlwnsgJ4EO4MH/0XpEIY+3weHVVX89iDGo+TV KsVPBqpuaXYjJSA5w9VsYlvTVc3R63lXeiNwFrffDKbIUKswEaJqCn9+j+uViYVJ aFF5CruKLHIxkcptdZvO4RD4bSnVkWSSwz5I5vjNbRfuVhoQz131XpG5wUXi60m7 rmbavKOGkyAqr6AWkLCJuYWGHl1L4G0KWMuFrhzj4xNIPnq95qhX0DCsKaC/EzDB tjpR2cH5zJpFTMsHPRRd40pG/1Soz6oG2SHBKrY1tVm09oNEA17frx6H3kmQOFtz w0UzXES8WGlmjVD2maOOm+odEPgFsxMFLNDjijcmBdQSxxkQtc0BDpweQl/RXKU= =3qF/ -----END PGP SIGNATURE----- --nextPart2400597.UVvrdKI6Fg--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2295097.hWnAh3kd1o>