# OpenLDAP: Pure, unadulterated evil

## Dabljuh

This is a rant and a warning.

Don't use OpenLDAP. I don't know a single "crucial" OSS networking packet that has caused me more trouble. 

Its not that OpenLDAP is bad - it is plain evil. By now I am convinced that Microsoft has hired saboteurs to code for OpenLDAP in order to prevent it from ever working right. 

Today, slapd (the OpenLDAP service) refused to boot because it didn't find itself already started. No, I am not making this shit up: This is what actually happened. For some reason slapd was looking for itself already running on the very address it was supposed to bind to - only to time out for an hour, instead of searching the files first like nsswitch.conf was configured to. That is the last straw, I will phase out this "solution" from hell ASAP.

----------

## asommer

I don't get it what exactly is the error message?

I ask because I'm currently learning OpenLDAP for a Direcotry Solution.

----------

## asiobob

this rant should be moved to off the wall.

If you have a detailed error, or you can provide a detailed OBJECTIVE account of whats going on help can be offered.

----------

## dopey

I've been running openldap in both production and development environments for going on 3 or 4 years now.  It requires a significant amount of knowledge to get running right and to maintain in a large scale (proper understanding of slapd.conf files, LDAP schema files, database maintenance depending on which backend you're using).

The bulk of the problems I've seen with slapd failures are usually incorrect custom schemas, incorrect slapd startup options, or poor database maintenance.

----------

## asommer

Hey dopy any advice on a learning path for OpenLDAP?  

Should I start with slapd.conf or schema definitions?

Any recommended reading material?

----------

## dopey

I got by originally by mainly reading the openldap documentation (man pages, openldap.org pages, mailing lists, etc).

For schema stuff, it was largely reading the various RFCs. 

The most difficult part was getting to understand BDB (i.e. how ot recover bdb from crashes, how to properly main bdb) and most of that came from the BDB documentation at:

http://dev.sleepycat.com/documentation/bdb.html

----------

## asommer

Cool, I appreciate the advice.

----------

## sedorox

I can vouch for what he says above with slapd trying to bind to itself. It is actually a problem after a sys-auth/nss_ldap upgrade. As I was installing a box, I upgraded parts of it, to see if I could determine what the problem was. Soon as I upgraded nss_ldap from 239-r1 to 249, everything broke. During boot, udev tries to bind to it, apache tries to bind to it, hell, it tried to bind to itself (see below for logs). I'm not sure exactly which version it broke at... but thats what I upgraded from. I ended up doing a few different things, mainly adding the bind_policy to ldap.conf. It still upsets me that this happened, and hasn't really been fixed yet. And also that openldap is I think second to last to start on my systems. After apache, distcc, email server, etc.

```

Jun 19 16:19:11 Valera apache2: nss_ldap: could not search LDAP server - Server is unavailable

Jun 19 16:19:11 Valera apache2: nss_ldap: could not search LDAP server - Server is unavailable

Jun 19 16:19:12 Valera ntpdate: nss_ldap: could not search LDAP server - Server is unavailable

Jun 19 16:19:12 Valera ntpdate: nss_ldap: could not search LDAP server - Server is unavailable

Jun 19 16:19:15 Valera slapd[5986]: @(#) $OpenLDAP: slapd 2.2.28 (Feb  4 2006 15:33:18) $       root@livecd:/var/tmp/portage/openldap-2.2.28-r4/work/openldap-2.2.28/servers/slapd

Jun 19 16:19:15 Valera slapd[5986]: nss_ldap: could not search LDAP server - Server is unavailable

Jun 19 16:19:15 Valera slapd[5986]: nss_ldap: could not search LDAP server - Server is unavailable

Jun 19 16:19:15 Valera slapd[5987]: slapd starting

```

Once it starts, all is good.. Again, nss_ldap-239-r1 and before didn't have this situation.

----------

## asommer

Was it an issue with OpenLDAP itself or an issue with Gentoo's ebuild of OpenLDAP and nss-ldap?

----------

## sedorox

 *asommer wrote:*   

> Was it an issue with OpenLDAP itself or an issue with Gentoo's ebuild of OpenLDAP and nss-ldap?

   I don't think its openldap itself. I think its more the nss_ldap, as I believe if you remove references to openldap in nsswitch and in the pam system, it doesn't try to bind to it and it works fine, however, then you can't use ldap for system auth. So according to my tests, and what I've read around the net, its just nss_ldap issue. I believe there is a bugzilla bug for it too.

----------

## asommer

Another quick question, does this only happen on the OpenLDAP Server machine, or on clients as well?

Also since you couldn't login did you have to boot to a recovery cd and change those files?

Thanks for your input.

----------

## sedorox

 *asommer wrote:*   

> Another quick question, does this only happen on the OpenLDAP Server machine, or on clients as well?
> 
> Also since you couldn't login did you have to boot to a recovery cd and change those files?
> 
> Thanks for your input.

 

Again, in my experience, it is any machine that has nss_ldap installed, and being used. A server can serve up ldap without having nss_ldap installed. nss_ldap is only made so the system (e.g. login from shell, ssh, etc.) can go against ldap. 

Who said you couldn't login? If you remove ldap out of pam, the system just won't look in ldap for your user, so you will have to use system users at the point, just like you normally do on a linux system without network auth.

----------

## asommer

Ah...no one said it...I just assumed that since it was configured against LDAP that if there wasn't any LDAP it wouldn't login.

I'm just starting with LDAP so I apologize if my questions aren't very knowledgeable.  

I appreciate your posts though.

----------

## sedorox

 *asommer wrote:*   

> Ah...no one said it...I just assumed that since it was configured against LDAP that if there wasn't any LDAP it wouldn't login.
> 
> I'm just starting with LDAP so I apologize if my questions aren't very knowledgeable.  
> 
> I appreciate your posts though.

 

Ah, its fine. No.. it falls in the same situation as if the ldap server was down on the network.. or you weren't connected to a network and tried to log in. Any named solely in ldap would fail, system names would be allowed. I started with ldap not to long ago myself, so I'm still sorting through things, and when this 'bug' popped up.. it didn't help.

----------

## dopey

I played with nss_ldap a while ago, but got rid of it.  I wonder if the problem isn't a misconfigured nsswitch.conf/ldap.conf as you aluded to.  Using LDAP as an nss interface can cause LDAP lookups for user info.  Obviously, here there's a chicken/egg issue with validating the initial root user if nsswith.conf and ldap.conf is misconfigured.  Wonder if maybe nss_ldap 249 isn't doing the various nss lookups properly.

Definitely a problem with nss_ldap and not openldap.  openldap has no choice but to do what the nss interface layers of the system calls do and spit out errors.

----------

## sedorox

 *dopey wrote:*   

> I played with nss_ldap a while ago, but got rid of it.  I wonder if the problem isn't a misconfigured nsswitch.conf/ldap.conf as you aluded to.  Using LDAP as an nss interface can cause LDAP lookups for user info.  Obviously, here there's a chicken/egg issue with validating the initial root user if nsswith.conf and ldap.conf is misconfigured.  Wonder if maybe nss_ldap 249 isn't doing the various nss lookups properly.
> 
> Definitely a problem with nss_ldap and not openldap.  openldap has no choice but to do what the nss interface layers of the system calls do and spit out errors.

 

Yea, but its weird, it even tries to look up users that are in the system, like ldap is listed first, but it isn't, it's listed second.  

Here is the bug that I was reading about on bugs.gentoo.org: https://bugs.gentoo.org/show_bug.cgi?id=99564

The whole udev thing is how I orginally ran into the problem, then general services.  I still think the problem came into play after the upgrade from 239, however since I don't code, and am not a programmer, I have no idea where to start looking to see what changed.

----------

## dopey

Aaah.  Read through that bug.  That makes sense.  User/group tss doesn't exist in files, and thus it looks it up in ldap by udev during boot.  openldap is likely not up by then (I'm assuming this only occurs if nss_ldap is configured to use localhost as the ldap server, or if the ldap server is separate and down or inaccessible).

so it's really a bug in udev and not nss_ldap.  the later version of nss_ldap uses slightly less sane timeouts causing the problem, but with any timeout, the performance problem is still there, just minimized as the bug really is in udev.

----------

## sedorox

 *dopey wrote:*   

> 
> 
> so it's really a bug in udev and not nss_ldap.  the later version of nss_ldap uses slightly less sane timeouts causing the problem, but with any timeout, the performance problem is still there, just minimized as the bug really is in udev.

 

Thats what they say.. but this also doesn't explain why after a certain version of nss_ldap, that apache and slapd itself, tries to bind to ldap before it is up, with a default of a VERY long timeout.  I still personally think its something in nss_ldap, unless they 'corrected' something in it, to be proper, which broke a lot of other things... which wouldn't be the first time.

----------

