On Sat, 16 May 2009, Arthur de Jong wrote:
I'm working on integrating a PAM module into nss-ldapd and am looking for input on this. The PAM module was kindly provided by Howard Chu from the OpenLDAP project but I'm still working on the server part.
Interesting, I talked briefly with Howard (on IRC) about this a few times, quite a while ago... talking about possible ways to impliment this.
With this new functionality I'm planning to generate three binary packages (instead of the now one): libnss-ldapd (the NSS module), libpam-ldapd (the PAM module) and nslcd (the daemon). The reason for this split is that some users may want to stick with the other PAM module. Also the OpenLDAP people are working on an overlay that could replace the nslcd part (but it's up to the OpenLDAP maintainers if they want to provide such a package).
This is great news! I've already converted all my boxes and am continually exhorting conversion to libnss-ldapd (mostly on IRC, but also those who report bugs on the libnss-ldap package). It seems to me, as the libnss-ldap maintainer, that libnss-ldapd is functional enough that we should deprecate libnss-ldap. I would also, as the pam-ldap maintainer, recommed similar deprecation for it once you have bind-auth (for auth), and exop (for pw change) going. There is already so many mis-configured machines out there, and the older packages have some significant issues, that I really believe Debian would do well by standardizing/offering only the one, superior, solution.
Also, I'm looking for people who are willing to spend some time on nss-ldapd. I could use some help with the PAM packaging part, I know libpam-runtime was changed recently so if anyone can help to get the the PAM packaging into shape that would be great.
Whilst I'm no pam wizard (by any stretch), we can likely take some information from the extant pam-ldap package.
Since nss-ldapd seems to be used more often now, having a co-maintainer for the package would really help. There is still enough development work to be done but also packaging work with the upcoming split.
Count me in - in whatever way I can be of assistance ... I've moved most of my machines to KRB5 auth, but the LDAP passward are being still kept in sync; so I can easily run tests.
Another important part where I would really welcome suggestions is a better name for the software. I've seen some confusion over the current name (people not noticing the d at the end) and with the integration of PAM functionality the name no longer covers the functionality.
Yes, the name does cause confusion (often an issue on #ldap and #openldap), which is one reason I favour deprecation of the older packages (if not removal), and having one solution for Debian. But even if we don't do that, I think the current name proposals make sense - even if somewhat confusing.
Current work on integrating the PAM functionality can be tracked here: http://arthurenhella.demon.nl/svn/nss-ldapd/nss-pam-ldapd/ http://arthurenhella.demon.nl/viewvc/nss-ldapd/nss-pam-ldapd/
/me makes a note to pull these Tuesday afternoon (this weekend is my 28th anniversary) - and we're still recovering from 3weeks on the road, so I wont have much computer time until then. -- Rick Nelson "We don't do a new version to fix bugs." - Bill Gates "The new version - it's not there to fix bugs." - Bill Gates -- Retranslated from Focus 43/1995, pp. 206-212 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org