After upgrading from sys-libs/db-4.3.29-r2 to sys-libs/db-4.5.20_p2, openldap slapd won't start anymore. Running slapd manually gives the following error: line 21: (null): incorrect name-value pair It seems that db-4.5 have problems reading the database created by db-4.3. If that is the case, the openldap package should force to build against the 4.3 slot of db. Manually running db4.5_recover and db4.5_upgrade gives the same error. After removing db-4.5 and rebuilding openldap, everything is working again. Reproducible: Always Steps to Reproduce: 1. Upgrade from sys-libs/db-4.3.29-r2 to sys-libs/db-4.5.20_p2. 2. Rebuild openldap. 3. Restart slapd. Actual Results: Slapd won't start. Expected Results: Slapd should start. Portage 2.1.2.12 (default-linux/x86/2006.1, gcc-4.1.2, glibc-2.5-r4, 2.6.13-gentoo-r5 i686) ================================================================= System uname: 2.6.13-gentoo-r5 i686 Intel(R) Pentium(R) 4 CPU 2.53GHz Gentoo Base System release 1.12.9 Timestamp of tree: Thu, 30 Aug 2007 00:50:01 +0000 app-shells/bash: 3.2_p17 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.9-r2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.21 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X afs berkdb bitmap-fonts cli cracklib crypt cups dri firefox fortran gdbm gnome gpm gtk iconv isdnlog jpg kerberos ldap midi milter motif mudflap mysql ncurses nls nptl nptlonly openmp pam pcre pdf perl png ppds pppd python readline reflection samba session spl ssl tcpd tif truetype truetype-fonts type1-fonts unicode usb x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 i810 imstt mach64 mga neomagic nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
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