SysAdmin Adventures

OpenLDAP Software is an open source implementation of the Lightweight Directory Access Protocol.
The suite includes:

* slapd – stand-alone LDAP daemon (server)
* libraries implementing the LDAP protocol, and
* utilities, tools, and sample clients.

There are a few things I’d like to mention about OpenLDAP in Slackware-13.0 and so I might as well deal with them all in one post.

Running an OpenLDAP Server

I can’t remember why, but Pat made the decision not to provide slapd, the OpenLDAP server daemon in Slackware by default. This has been the case for some time. Instead, what you get is openldap-client which is just the client libraries enabling you to use OpenLDAP code in LDAP client applications and LDAP-dependant software.

If you want to run an OpenLDAP server you are going to need slapd. Thankfully this is incredibly easy to do because all Pat did to remove slapd was to configure the OpenLDAP source with:

If you want slapd (and perhaps slurpd) then you just need to rebuild the openldap sources using the SlackBuild Pat provides in the Slackware source, but with the word disable replaced with enable. However, there is a catch. In Slackware-13.0 OpenLDAP will not build with the source and SlackBuild Pat shipped because the OpenLDAP package has not been rebuilt since 24/07/2008 and since then a change has been made to the C compiler that prevents OpenLDAP from building correctly unless you append the flag -D_GNU_SOURCE. This wasn’t detected early enough for it to be fixed for the 13.0 release. Normally this isn’t an issue because the package still works perfectly, but if you want to rebuild it you have to modify the source or the SlackBuild to do so.

Assuming your Slackware source is located at /mirror/slackware/slackware{64}-13.0:

Working in vim so you can see what you’re doing.. (you could replace however you wanted, e.g. with sed, or manually, or whatever):

Then go and have a sleep for half an hour as it builds and then tests just about every conceivable LDAP operation.
Once it’s done:

Job done.

Using OpenLDAP for User Authentication

In other distributions, setting up LDAP user authentication for the OS is done with Linux-PAM. While, mercifully, Slackware does not have Linux-PAM (and probably never will) it does mean that LDAP user authentication is harder or more impractical.

Note: I do not recommend doing LDAP user authentication for your Operating System. It’s not necessary in most cases. LDAP authentication should be done at the application level for specific services provided to users. The Operating System should only be authenticating users that actually log in to the system and in most cases LDAP is not needed for this. (Don’t argue if it is truly necessary in your case – you’re an exception).

If you are absolutely sure you definitely need LDAP user auth for Slackware, your options are:

Install PAM

This is an epic challenge and few succeed. Since PAM is evil anyway, do not bother. If you choose to take this route and succeed, then document your adventures and link to them.

Use nss_ldap

The resolution of the entities defined in RFC 2307 is generally performed by a set of UNIX C library calls (such as getpwnam() to return the attributes of a user). The nss_ldap module provides the means for Solaris and Linux workstations to this information (such as users, hosts, and groups) from LDAP directories. The module is the reference implementation of RFC 2307, and has been studied by vendors such as Sun (who developed the original Name Service Switch interface).

This basically allows you to use nsswitch.conf to redirect user entry queries to an LDAP server and seems the natural way to do LDAP auth in Slackware, but there is drawback. In normal circumstances LDAP authentication is done with a bind. The user supplies a username and password and the application submits a login request (a bind operation) to the LDAP server and the LDAP server returns success or failure depending on whether the credentials are valid. This is not possible with nss_ldap because nss_ldap doesn’t replace the authentication method, it just redirects it to a different storage back-end. The effect of this is that to use nss_ldap you have to store the users’ passwords in the LDAP server using the same hashing algorithm you would use in the passwd file (crypt()).

I’m not going to go into any further detail on this, you are going to have to do the research yourself, but suffice it to say nss_ldap is not ideal, but it is the cleanest method and probably the one I would use if I had to.

Use NIS and a ypldapd

The NIS/LDAP Gateway, or ypldapd, is a Network Information Service (NIS) server which uses LDAP as its information source. It permits existing NIS clients to transparently use LDAP to resolve user, group and host information. Enterprises can thus realize the benefits of LDAP, such as its distribution and being scalable, without upgrading clients.

I personally haven’t tried this and can give no reasoned opinion on it, but if you are migrating from NIS to LDAP it seems like a reasonable way to get going with it and may also cover the drawbacks of the nss_ldap solution – but it has it’s own drawbacks.

1. You must have or implement a NIS network.
2. It’s not free.

I wish I understood why LDAP support is so unbelievably piss-poor in so many software products. So many organisations use LDAP as their core user directory (whether OpenLDAP, Active Directory or some other LDAP implementation) or have a directory service that will provide its data via an LDAP interface. I see people screaming for LDAP support in everything, but so little support from software coders/vendors; I can only assume because they personally don’t have much LDAP experience. Just about every F/OSS software project claims to have LDAP support, but because someone who didn’t totally understand the application itself wrote some add-on code to make it work. This leaves everyone else following poor instructions for adding-in support to an application that really should be supporting LDAP natively from day one.

For Request Tracker from BestPractical, I ended up re-writing the very limited user-contributed code that already existed into a fully-fledged extension for LDAP support. But it’s still not easy for RT administrators because my extension is not part of the core RT code; it is tacked-on over the top and, while I try to make it as easy as possible, people still run into problems with implementation. Also, when they need new features and I don’t have the time to implement them (which I don’t), they’re left up the creek with no paddle because the core development team didn’t write it and don’t intend to pick it up and code new features into it. In the case of RT, there is the suggestion that the LDAP code will be integrated into the next big version (RT4), but it is literally years too late.

At the moment I am having intense headaches over Foswiki, the fork of TWiki. This is the type of system that was born for use in organisations with existing user databases, but still getting it to take its user information out of LDAP is a NIGHTMARE. The basic principle is simple: have some perl code do an LDAP bind when a user tries to login, and if successful, do a search on their information and then map that information into the application based on a simple variable map. It’s how LDAP works in every app I’ve ever come across. But, to get this working in Foswiki you have to install four extensions (LdapContrib, LdapNgPlugin, GluePlugin & NewUserPlugin), you have to go through activating and configuring each plugin, and telling the login system which one of the three (confusing and not well documented) options it should use for each of the processes, then you have to go into the Wiki pages themselves and start again. You have to write (in a special Wiki code you won’t be familiar with) your own templates for gathering the LDAP information and then code up how you’re going to pass this to the NewUserPlugin so that during auto-registration some magical process can take place to update the user’s information. And I’m willing to bet that if I want the information to stay up to date with the LDAP database I will need a fifth plugin to check for changes during login as Login doesn’t normally handle user information, that’s a registration thing.

It’s the same all over. Pick pretty much any F/OSS web-app you like that requires a user database and you will find that LDAP support is either not-present, tacked on haphazardly, or is available only via user-contributed code of varying quality and documentation.

DEVELOPERS: PLEASE FOR THE LOVE OF GOD GET YOUR ACTS TOGETHER!!


When you design an application like these, your user authentication and information systems need to be able to handle an LDAP (or sql for that matter) back-end. It’s really not difficult. In most languages the template code for the ldap searches and binds has been done for you, you just have to use it. I do what I can to provide good code to help people get LDAP working in their apps but it is not easy and there’s only one of me.

LDAP is easy, but each individual application has its own way of doing user authentication. If I want to put LDAP code into an app, it means I have to understand the nuances of the code and then write around it. In systems such as RT and Foswiki, the authentication systems are so complex it can take weeks to get up to speed with how they work, even with direct input from the developers themselves. I just don’t have the time to learn every authentication system ever written. If the developers themselves took a moment to realise how simple it is to add LDAP support to code they already understand, and then to get off their arses and *do* it, life would be a lot easier for everyone and it wouldn’t be so hard to implement these systems in company networks. That means we could finally start pulling away from “pay someone else to do it” mentality that has companies throwing thousands of pounds at piss-poor software vendors just to save from spending the time working out how to do it themselves.