Re: integrating PAM module into nss-ldapd (RFH)
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
Reply to: