Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[solved] openldap upgrade problems (open database failed)
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
bobcatt
n00b
n00b


Joined: 21 Jan 2006
Posts: 6

PostPosted: Sun Nov 11, 2007 2:52 pm    Post subject: [solved] openldap upgrade problems (open database failed) Reply with quote

Hello All

I had the same problem like many other people on the forum.
After upgrading my openldap, berkdb package and (maybe) glibc, openldap refuse to starts anymore.
And the main problem was i didn't have any recent ldif backup file.

Code:

Nov 11 12:30:00 lune slapd[22421]: backend_startup_one: starting "dc=foo,dc=bar"
Nov 11 12:30:00 lune slapd[22421]: bdb_db_open: dc=foo,dc=bar
Nov 11 12:30:00 lune slapd[22421]: bdb_db_open: dbenv_open(/var/lib/openldap-data)
Nov 11 12:30:00 lune slapd[22421]: bdb_db_open: Database cannot be opened, err 22. Restore from backup!
Nov 11 12:30:00 lune slapd[22421]: ====> bdb_cache_release_all
Nov 11 12:30:00 lune slapd[22421]: bdb(dc=foo,dc=bar): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem
Nov 11 12:30:00 lune slapd[22421]: bdb(dc=foo,dc=bar): txn_checkpoint interface requires an environment configured for the transaction subsystem
Nov 11 12:30:00 lune slapd[22421]: bdb_db_close: txn_checkpoint failed: Invalid argument (22)
Nov 11 12:30:00 lune slapd[22421]: backend_startup_one: bi_db_open failed! (22)
Nov 11 12:30:00 lune slapd[22421]: slapd shutdown: initiated
Nov 11 12:30:00 lune slapd[22421]: ====> bdb_cache_release_all
Nov 11 12:30:00 lune slapd[22421]: bdb_db_close: alock_close failed
Nov 11 12:30:00 lune slapd[22421]: slapd destroy: freeing system resources.
Nov 11 12:30:00 lune slapd[22421]: slapd stopped.
Nov 11 12:30:00 lune slapd[22421]: connections_destroy: nothing to destroy.



This problem was also described here and the proposed solution (restore from ldif backup) was not very interesting.

I've decided to investigate around berkeyDB backup and restore to understand where the problem comes from but google didn't gave me a lot of answer.

I've looked at berkleyDB tools and found two good command line utilities db4.5_dump and db4.5_load.
I've also constated that slapd with and empty database dir recreate all needed files.

After this, all worked successfully.

Here is a script to automate the procedure :
Code:
#!/bin/bash

#stop slapd to be sure
/etc/init.d/slapd stop
cd /var/lib/openldap-data/
# backup everything
mkdir backup
cp -p * backup
for x in *.bdb
do
        echo "dumping: $x to backup/$x.txt"
        db4.5_dump -k -f backup/${x}.txt ${x} && rm -f ${x}
done
rm alock __db.* log.*

# let slapd recreate needed files
/etc/init.d/slapd start
sleep 5

# stop slapd to have clean files
/etc/init.d/slapd stop
for x in *.bdb
do
        echo "restoring: $x with backup/$x.txt"
        db4.5_load -f backup/${x}.txt ${x}
done

echo "you can start slapd now"


All original datas are stored in /var/lib/openldap-data/backup just un case something goes wrong.

This procedure worked very fine for me. objectClass.bdb can be safely ignored from restoration as it is used to index database.
Back to top
View user's profile Send private message
dahoste
Tux's lil' helper
Tux's lil' helper


Joined: 01 Dec 2005
Posts: 138
Location: Maryland, USA

PostPosted: Sun Nov 11, 2007 4:37 pm    Post subject: Reply with quote

Restoring from an ldif backup may not be 'interesting', but it's effective, nearly foolproof, and more importantly, is just about the only appropriate method if the berkeley files themselves have gotten corrupted.

Ultimately, I wouldn't eschew a regular ldif-based backup policy just because a means exists of potentially recovering from the *.dbd files themselves.

It's nice to know that the db4.5_dump and _load tools are available, but it's been the case in the past that an update to some part of the ldap stack (openldap, glibc, sys-libs/db, etc..) broke things in such a way that left my bdb files orphaned and unusable. Having the db contents available in an essentially version-agnostic form (ldif) provides tremendous peace of mind.

But as you say, if for whatever reason you *don't* have an ldif dump available, at least some sort of recovery attempt can be made using the native berkdb tools. The next time ldap breaks (which I'm sure won't be long from now) I imagine a nice recovery method would be to use your script, immediately do a slapcat, and then diff the results with the most recent ldif backup.

Cheers, and thanks for providing the recovery script. That's a keeper.
Back to top
View user's profile Send private message
fmouse
Tux's lil' helper
Tux's lil' helper


Joined: 28 Jul 2003
Posts: 101

PostPosted: Mon Nov 19, 2007 5:30 pm    Post subject: Reply with quote

dahoste wrote:

Cheers, and thanks for providing the recovery script. That's a keeper.


It should be noted that if slapd is having problems as described here, then db4.5_dump will probably have the same problem, as I discovered. I had to use db4.2_dump to dump my data. The script will need to be modified to accordingly.
Code:
locate db4.|grep bin|grep dump

will locate available versions.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum