I had been developing Python code against an LDAP backend, using python-ldap and slapd. Unfortunately, today the backend Berkely database become corrupt (luckily, it’s only my test environment).
If this happens, something like the following appears in /var/log/debug when trying to start slapd:
slapd[7380]: @(#) $OpenLDAP: slapd 2.4.15 (Mar 19 2009 10:07:59) $ ^Ibuildd@yellow:/build/buildd/openldap-2.4.15/debian/build/servers/slapd slapd[7381]: hdb_db_open: database "dc=nodomain" cannot be opened, err 13. Restore from backup! slapd[7381]: bdb(dc=nodomain): txn_checkpoint interface requires an environment configured for the transaction subsystem slapd[7381]: bdb_db_close: database "dc=nodomain": txn_checkpoint failed: Invalid argument (22). slapd[7381]: backend_startup_one: bi_db_open failed! (13) slapd[7381]: bdb_db_close: database "dc=nodomain": alock_close failed slapd[7381]: slapd stopped.
The fix:
$ apt-get install db4.7-util ... $ cd /var/lib/ldap $ db4.7_recover -v $ /etc/init.d/slapd start
Any idea what caused the corruption in the first place?
Did the recovery tool recover all of the slapd database, or just put it back in a workable state?
I wish this was new information but sadly I did this many times on production openldap.
Move to 389 directory server its just like OpenLDAP but its good.
Colin: It was simply typical use. The recovery tool restored everything to a workable state.
Joel: Never heard of “389 directory server”. I’ll have to take a look. Thanks.
It used to be called Fedora Directory Server. Originally a netscape product. Supports all the bells and whistles like multi-master replication and the like.