Date: Tue, 19 Aug 2014 09:39:28 -0400 From: Eric van Gyzen <eric@vangyzen.net> To: Harald Schmalzbauer <h.schmalzbauer@omnilan.de>, Peter Wemm <peter@wemm.org> Cc: "Eggert, Lars" <lars@netapp.com>, freebsd-current@freebsd.org, "O. Hartmann" <ohartman@zedat.fu-berlin.de>, "current@freebsd.org" <current@freebsd.org> Subject: Re: nscd not caching Message-ID: <53F35390.2060503@vangyzen.net> In-Reply-To: <53F34DA3.70609@omnilan.de> References: <FA0C5D1E-780A-4B01-8513-5A4B77DA051D@netapp.com> <D86D34C6-B5E8-4141-BD9F-FF88B056DF6B@netapp.com> <20140817152202.6ec8e374.ohartman@zedat.fu-berlin.de> <2295097.hWnAh3kd1o@overcee.wemm.org> <53F34DA3.70609@omnilan.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/19/2014 09:14, Harald Schmalzbauer wrote: > Bezüglich Peter Wemm's Nachricht vom 17.08.2014 19:18 (localtime): >> On Sunday 17 August 2014 15:22:02 O. Hartmann wrote: >>> Am Sun, 17 Aug 2014 13:09:10 +0000 >>> >>> "Eggert, Lars" <lars@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. > 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. Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53F35390.2060503>