To be honest, I am fed up with OpenLDAP at this point. I did a pretty standard install on Debian (apt-get install etc. , you get it). After a hard time learning how to use this thing (which is not unusual for a LDAP-newbie like me), I managed to get it to run acceptably.

After some weeks, the machine it was running on had a failure and rebooted. Unfortunately, OpenLDAP (or, to be more precise: Berkley Database) did not work correctly anymore with the database currently used for storing information. It began to use 100% CPU time at the first request and the load-factor of the whole machine was ridicouloulsy high as a consequence. Nothing but a killall -9 slapd would help when dealing with such a corrupted database.

Fortunately, I had a LDIF file handy with all the needed data and played it back with slapadd.

The problem resurfaces

This seemed to work - until today, where it would not respond anymore again and eat my CPU alive. First, I ran db_recover to fix the database, but it told me that the format of the logfile of the database was from an incomaptible version and so it did not do anything useful. I tried the old trick consisting of deleting the database, restarting OpenLDAP and slapadding the LDIF. Almost worked, just that now, all data seemed to be in the database again, but no searching was possible. If you knew the precise DN (Distinguished Name) of a record, you would see all info belonging to this record. But what did this help me?

Problem solution strategies

So, I googled a bit and found out that people reported problems with BDB (Berkley DB) in conjunction with ext3 and reiserfs filesystems (see this Debian bug report, this short tuorial from SuSE on how to switch from BDB to LDBM). I use ext3 on all partitions of my machine.

Switch from BDB to LDBM

To switch from BDB (Berkley Database) to LDBM (Lightweight Database Management), you need at least do the following things:

Add moduleload back_ldbm to your slapd.conf:

# Where the dynamically loaded modules are stored
modulepath      /usr/lib/ldap
moduleload      back_bdb
moduleload      back_ldbm

Then, replace backend bdb with backend ldbm:

backend         ldbm

Then, replace database bdb with database ldbm:

database         ldbm

This did the trick for me. It is not optimised at all, so you need to get more information about how to improve preformance (maybe http://www.tldp.org/HOWTO/LDAP-HOWTO/ldbmdirect.html).

Epilogue

I hope this setup works better for me and if not, I will not hesitate and switch to a SQL backend. You get what you deserve.