Stuff for Developers

So, your interested in giving a helping hand with this exciting project. Well, I welcome the help! I've put together a list of things that I feel are important steps in getting this project underway (not quite in the order of importance). I'm also including some links to information that should help you get familiarized with the whole LDAP thing. I recomend you get on the mailing list, read up and get familiarized with what this miracle called LDAP does, then download the code and patches I've got on the main page and play around with it. Then jump on one of these projects!

Recomended reading includes..

Development tasks

SSL Implementation

Currently patches are available to enable the UofM LDAP software (and other programs linked to it's libraries) to use SSLeay v 0.8.1. However a new version of the SSLeay library has been released, which now supports TLS. TLS does not use the RSA encryption code, so alot of licensing headaches go away (and I feel better about using a _free_ standard anyhow). The UofM code needs to be updated and tested with this new library

Secondly, some thought should go into using cryptographic authentication when users bind to the server.

Server Development

The UofM server code is merely adequte. It is by no means industrial-strength yet. The code needs to be tweaked to provide better stability, performance, and scaleability. The code should also be updated to include the new LDAPv3 functionality.

There is a team specifically working on the server side of LDAP develpment. Their site can be reached at http://www.is.kiruna.se/~goran/ldap/. They also have a mailing list, to subscribe send mail to linux-ldap-request@bildbasen.se.

User Administration Tool Support

Various standard components of the Linux operating environment need to be made 'LDAP Aware'. These are programs that are ususally used to update or add new entries to the systems databases normally stored in flatfiles or NIS tables. Example programs would be: passwd, chfn, useradd, etc.. Applications that read from the system databases shouldnt need modification, if they are using the standard library calls.

Library Development

The nss_ldap library needs alot of testing, fixing, and improving. The first steps should be to get its core functions working properly, ensuring that any information an application could normally get from NIS or system files will be accessable from LDAP. After this some performance tuning would be in order. I've noticed that doing anything that uses the nss library calls heavily suffers a performance hit (due to the tear-up and tear-down overhead). One possible solution is for the nss_ldap librery to implement an in-memory caching scheme, thus lowering the number of network operations that have to be done.

Getting the NSS library stable is key to alot of these other projects.

Service Integration

Most software will 'just work' once the nss_ldap library is dropped into place. However some software which may use alternative authentication schemes or special tables of data will have to be integrated. One example is samba. Work should be done so that samba can query an LDAP database instead of its local 'smbpasswd' file for password hashes.

Migration Scripts

There are currently migration scripts available to migrate a NIS or 'flat files' system to LDAP. These scripts work, however they could use some changing to allow a system administrator who knows little of LDAP to quickly get his/her network migrated with the minimum of knowledge or effort. Most of these scripts are written in perl.

Cross-Platform portability

One of the biggest promises of LDAP as an information service is that it may unify several, sometimes opposing, networking systems (such as novell, NT, unix, and whoever else is out there). Thus its important that alot of the work done on the Linux side is ported to other flavors, such as Solaris or HPUX.

Testing and Documentation

Even if you dont code you can help this project move forward. We welcome anyone to give the software a whirl and send us feedback on bugs or just experiences with the software in varied environments. We'd also like any documentation you can provide on how you implemented the software and what gotchas or hangups that may have occured. This information will eventually evolve into the HOWTO and FAQ.

Hey you! If you want to assume responsibility for any of these areas, please mail myself or post it on the mailing list