View previous topic :: View next topic |
Author |
Message |
bobcatt n00b
Joined: 21 Jan 2006 Posts: 6
|
Posted: Sun Nov 11, 2007 2:52 pm Post subject: [solved] openldap upgrade problems (open database failed) |
|
|
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 |
|
|
dahoste Tux's lil' helper
Joined: 01 Dec 2005 Posts: 138 Location: Maryland, USA
|
Posted: Sun Nov 11, 2007 4:37 pm Post subject: |
|
|
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 |
|
|
fmouse Tux's lil' helper
Joined: 28 Jul 2003 Posts: 101
|
Posted: Mon Nov 19, 2007 5:30 pm Post subject: |
|
|
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 |
|
|
|
|
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
|
|