Summary: | Upgrade from db-4.3.29-r2 to db-4.5.20_p2 broke openldap database | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Johan Ymerson <johan> |
Component: | Current packages | Assignee: | Gentoo LDAP project <ldap-bugs> |
Status: | RESOLVED LATER | ||
Severity: | normal | CC: | fmouse-gentoo, gentoobugs |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Johan Ymerson
2007-08-30 06:22:56 UTC
The following set of instructions should upgrade the database properly (based on the BerkDB docs). # cd /var/lib/openldap-data # /etc/init.d/openldap stop # db4.3_recover # db4.3_archive -s # db4.3_archive -l # (make backup #1 of /var/lib/openldap-data/) # db4.5_upgrade -v # db4.5_archive -s # db4.5_archive -l # (make backup #2 of /var/lib/openldap-data/) # db4.5_checkpoint # /etc/init.d/openldap start If the above does NOT work. go to the backup #1, build openldap against db4.3, use slapcat to backup, upgrade db4.5, rebuild openldap, slapadd the data back. I'd like to hear back from you in either case. > # db4.5_upgrade -v
I guess you mean db4.5_upgrade -v *.dbd?
When I run that, I get:
db4.5_upgrade: line 21: (null): incorrect name-value pair
db4.5_upgrade: line 21: (null): incorrect name-value pair
db4.5_upgrade: DB_ENV->open: Invalid argument
> I guess you mean db4.5_upgrade -v *.dbd?
^^^^ .bdb of course...
on a crazy idea, could you try to upgrade to db4.4 and thence to 4.5? failing that, slapcat/slapadd is the only option, and i'll add a recompile check into LDAP to make sure people do that. (In reply to comment #4) > on a crazy idea, could you try to upgrade to db4.4 and thence to 4.5? > failing that, slapcat/slapadd is the only option, and i'll add a recompile > check into LDAP to make sure people do that. > Upgrade to db4.4 went well, but still the same problem upgrading to db4.5. I'll do slapcat upgrade now. slapcat/slapadd did work. This must be an upstream bug, and the only way to avoid it seems to be slapcat+slapadd. So a check for this in the ebuild would be good. This seems kind of known issue @upstream.. saw a comment about it on upstreams mailinglist where they simulated and update from 2.3 to 2.4 without slapcat/slapadd So IMHO we should get a note added to sys-libs/db about it as we can't do anything about the real issue this has been a long standing issue. I use to run nightlight slapcats to backup the LDAP database. Eventually I just gave up and took all my server off of LDAP. MySQL warns the user when an incompatible upgrade is about to occur, but because of the separation of the berkley DB libraries from openldap, this seems impracticable in Gentoo I note that there's code in openldap-2.3.38.ebuild which will display a step by step solution (basically slapcat + slapadd) to this problem, but it's apparently not always being properly triggered when it's needed. I recently did an openldap/bdb upgrade and had the same problem (see http://forums.gentoo.org/viewtopic.php?t=598106 for the description of a problem similar to mine). Display of the the openldap_upgrade_howto contained in the ebuild did not happen, and it would have been very helpful if it had! Since this seems to be a thorny problem, perhaps it would be best if the ebuild didn't try to second-guess the upgrade and displayed this howto unconditionally, prefixed with something like "if you are unable to start slapd after this upgrade, here's what you can do ...". I'm not sure if the openldap upgrade triggered the db upgrade, or if it simply sensed and used a later version already present on the system, or something else altogether. In any event, this seems to be a common problem and there are several solutions out there. I managed to use db4.2_dump to successfully dump my dbs and reloaded them using db4.5_load. db4.5_dump complained about an "environment version 0.22" problem, as did slapd when I tried to run it. It's possible that slapcat would have the same problem and hence the instructions in the ebuild may need to be revisited. For OpenLDAP 2.4 I fixed this by using a proper slot dependency to db 4.5 and made configure look for that version by default. So once that is in effect, we're safe. As it's a new version marking it LATER as it will take a while until it's in effect |