From owner-freebsd-current@FreeBSD.ORG Sun Aug 17 17:18:26 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E0D4149; Sun, 17 Aug 2014 17:18:26 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [192.203.228.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E45FD2031; Sun, 17 Aug 2014 17:18:25 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 3CF2579B; Sun, 17 Aug 2014 10:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1408295899; bh=HONwKAqGTn2Nr+bmBn4HuvBF8HxbM5JY2qAwn4ThmoI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=YK8iZF0gbsuPx1DnXLuhb/aKK5YTe+VYC35sJfA/zt1u1A6zyqv3russ8MvDqtWPT pzGtb8If3oW2XXLx7Z0FLMWHWHLh8bLHu3DtruZ1O2igmiVg887AumIXGkMwiwesBq g/UKkn5B6LOuAk3dSWFv4JRgHf1WqKuja4KHmAC8= From: Peter Wemm To: freebsd-current@freebsd.org Subject: Re: nscd not caching Date: Sun, 17 Aug 2014 10:18:13 -0700 Message-ID: <2295097.hWnAh3kd1o@overcee.wemm.org> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: <20140817152202.6ec8e374.ohartman@zedat.fu-berlin.de> References: <20140817152202.6ec8e374.ohartman@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2400597.UVvrdKI6Fg"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: "Eggert, Lars" , "O. Hartmann" , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 17:18:26 -0000 --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" 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 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--