|
|
At the Purdue University Computer Society, we maintain a small network of machines. To simplify administration, we have an OpenLDAP server which implements LDAP, or Lightweight Directory Access Protocol. There are many implementations of methods to access an LDAP database. For example, there are:
We are currently using pam_ldap for authentication purposes. However, we'd like to be able to use a set of tools which allow us to manipulate elements in the LDAP database without needing to know the internal details of LDAP and without needing to use pam_ldap. The usual tools like adduser would then be comprised by a combination of these tools. Currently, we have a cheap hack which allows us to add new users to our LDAP server. We'd like to change that by having a clean set of tools, and as we like all things Open Source, we'd probably release the tools to the world providing they are clean enough. Pursuant to this, we will probably implement the tools using Perl's Net::LDAP or Python's LDAP module. Blake Matheny committed a script called cpu.pl which attempts to imitiate the FreeBSD pw(8) utility using an LDAP backend in October 2001. He later moved it to SourceForge and rewrote it in C. Check it out here. One particularly interesting idea has been about how to handle machines running operating systems that don't have very good nsswitch support, in particular FreeBSD, NetBSD, and OpenBSD. The implementations available in NetBSD, OpenBSD, and FreeBSD -current do not support LDAP due to the lack of being able to support dynamic nsswitch modules. So we have to find an alternative means of figuring out who the users are when they are done logging in through pam_ldap. In the FreeBSD case, we've written a perl script to automatically sync the local password and group databases from an LDAP server. This performs as an effective replacement for nsswitch+nss_ldap. However, it currently has one major drawback: It syncs the whole database rather than just whatever changes at a particular point in time. The major problem with that is the client needs access somehow to LDAP database change logs. In any case, the script works fine for us, but suggestions are welcome! Check out our ldap_update script's cvs logs. |
|