Hello. I have updated my openldap database to version openldap-2.0.27-r4 and at the end of the update, the whole database has been removed. All my users, entries, datas are gone. Reproducible: Always Steps to Reproduce: 1. emerge -u openldap Actual Results: The ldap database is removed Expected Results: The database should be still present System uname: 2.4.20-gentoo-r5 i686 Celeron (Mendocino) GENTOO_MIRRORS="http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo http://mirrors.sunsite.dk/gentoo http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/confi g /usr/kde/3/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/usr/local/tmp" PORTDIR_OVERLAY="/usr/local/portage" USE="x86 oss 3dnow apm arts avi encode foomaticdb imlib libg++ mad mikmod mmx mpeg ncurses nls oggvorbis opengl png quicktime sdl svga truetype xmms xv zlib slang readline tcpd perl python -X -gtk -kde -alsa -qt -motif -gnome -gpm - aalib -flash -java -xml -xml2 -pdflib -snmp -odbc -berkdb -freetds -firebird - spell -pam -gdbm -curl -postgres -libwww -gif -doc -cups -cjk -apache2 crypt tiff gd ldap mysql imap jpeg ssl evms2 aavm" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-O2 -mcpu=i686 -pipe" CXXFLAGS="-O2 -mcpu=i686 -pipe" ACCEPT_KEYWORDS="x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache fixpackages"
Some directories have changed in moving to this new version... are you sure your data just isn't in the wrong place? Was a specific file deteled by the ebuild?
Hi, In fact it delete all data files of openldap in my slapd.conf it is /var/state/openldap/* THanks :)
The location of the data has changed.... from /var/state/openldap/* to /var/lib/openldap-* configuration files were also changed accordingly.
No, I had to use "etc-update" to update them, there haven't been overwritten during the update.
our ldap administrator for gentoo did an update similar to yours... went from 2.0.27-r1 to -r4 which followed the /var/state -> /var/lib upgrade and he had no problems at all... i've asked him for more info on his update procedure but he said it was pretty straightforward.... no real hiccups... If I get more information i will let you know.
I can imagine what is going wrong in openldap-2.0.27 there was always --enable-ldap apended to the configure script. now you have to decide if you want berkleydb or gdbm. The result is, that if you former had a working openldap setup it does not work anymore after the update, if you didn't include either gdbm or berkleydb to your use flag. For that point I have a question. Are both comptaible? I don't know waht api was used in openldap-2.0.27 by default, since both where installed and before reemerging openldap-2.0.27-r4 I want to be sure, that all goes right. So can I just decide for one, or what? What is better, faster more efficient? (Please don't answer Windows 98)
I was wrong, another thing changed before r4 slapd was runed under user root, now it's ldap.ldap. So changing ownership of old database solved the problem of non exist subtrees. All of you with similar problems: chown -R ldap.ldap /var/state/openldap-ldbm /etc/init.d/slapd restart
I will add a comment into postinst regarding the change from running as root to running as user ldap so others don't run into the same headache.
although... # Since moving to running openldap as user ldap there are some # permissions problems with directories and files. # Let's make sure these permissions are correct. chown ldap:ldap /var/run/openldap chmod 0755 /var/run/openldap chown root:ldap /etc/openldap/slapd.conf chmod 0640 /etc/openldap/slapd.conf chown root:ldap /etc/openldap/slapd.conf.default chmod 0640 /etc/openldap/slapd.conf.default chown ldap:ldap /var/lib/openldap-{data,ldbm,slurp} I can see how this wouldn't have made a difference for your case as you probably moved the database post-emerge... anyway... still adding a comment.
