Ralf Haferkamp wrote:
Am Dienstag 03 November 2009 19:17:55 schrieb Joachim Schrod:
Ralf, big thanks for your concise answer to my question. It helps a lot and shines quite some light on the intented architecture.
In 11.0 or 11.1 the new package nss-ldapd was introduced, with the daemon nslcd. It is supposed to be used for LDAP connection pooling when one wants to have LDAP being a nameservice source, like passwd or group. Connection pooling wasn't the only reason for introducing nss-ldapd. See http://arthurdejong.org/nss-pam-ldapd/design.html for some more details (nss-ldapd has been renamed to nss-pam-ldapd recently). One additional point that is not mentioned there is that with nss-ldapd you can finally use authentication between nss_ldap and the LDAP server in a senseful way.
Very good point. There is even yet-another-advantage that isn't listed: This way libnss_ldap.so does not reference libssl.so any more -- which caused havroc if one has an old app lying around that is compiled against an older libssl.so version.
With a plain (old-style) nss_ldap setup the configuration file (and with it the LDAP password used by nss_ldap) needed to be world readable which made setting up binddn and bindpw for nss_ldap kind of useless.
Yes, and now one would actually would like to get an include mechanism in all those *ldap*.conf files, to be able to share common configuration options, like the LDAP server and base DNs. For now, I'm planning to use M4 to create the config files, to have *one* master source that has the relevant site information.
PS: It's quite irritating that nss_ldap [and nss-ldapd] include the same /lib/libnss_ldap.so.2. [...] :-( I also don't know if one should install both nss_ldap and
Only one of that. The dependency issues should be fixed in 11.2. nss_ldap and nss-ldapd do conflict now.
Ah, good to know. On my 11.1 test installation, both packages were installed by default. Since rpm -V didn't report any inconsistencies, I thought they contain the same shared lib. Learned something new again -- rpm doesn't record a file's MD5 from the rpm, but from the last install.
BTW, if you are considering to use nss-ldapd you might be interested in sssd as well. sssd is yet another approach to tackle LDAP NSS and PAM issues. It has some additional features compared to nss-ldapd (like build in kerberos support and offline caching).
The description you posted on factory sounds very interesting. I'll have a look at it and see if I'll find the time to set up a VMware team that utilizes it. For now, I'm still experimenting -- our workstations still use NIS and I'm looking in the consequences of moving user management to LDAP (performance, backup servers/fail-over, manageability, installation complexity, etc.) Again, thanks for your explanations; they helped a lot. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org