In /etc/init.d/slapd wird seit UCS 2.3-0 überprüft, gegen welche BDB-Version ldap/back_bdb.so gebaut ist, um dynamisch zu ermitteln, mit welcher bdbX.Y_recover Version die BDB-Dateien des LDAP Datenbank-Backends geprüft werden sollen. Bei BDB-Updates ist diese dynamische Anpassung wohl noch nicht ausreichend, da das db_recover nicht gestartet wird, wenn die Versionen nicht zueinander passen (weil db4.7_recover in einem Test ein 4.2 Environment in einen defekten Zustand gebracht hatte). Es sollte überprüft werden, ob ein Aufruf von dbX.Y_upgrade diese Lücke schließen kann (entweder in slapd.postinst oder in init.d/slapd). +++ This bug was initially created as a clone of Bug #16193 +++ Es sollte geprüft werden, ob diese Meldungen aus der updater.log ein Problem darstellen: Setting up slapd (2.4.15-1.1.19.200910291738) ... Backing up /etc/ldap/slapd.conf in /var/backups/slapd-2.3.30-8.42.200907081544... done. Upgrading BDB 'checkpoint' options... . Moving old database directories to /var/backups: - directory dc=auto,dc=update,dc=test... done. Loading from /var/backups/slapd-2.3.30-8.42.200907081544: - directory dc=auto,dc=update,dc=test... done. - chowning database directory (openldap:openldap)... done Check database: db_recover: Program version 4.2 doesn't match environment version done Starting ldap server(s): slapd. Setting up univention-ldap-config (5.0.7-1.331.200909301131) ... Restarting ldap server(s): Stopping ldap server(s): slapd. Check database: db_recover: Program version 4.2 doesn't match environment version db_recover: Ignoring log file: log.0000000002: unsupported log version 14 db_recover: Invalid log file: log.0000000002: Invalid argument db_recover: PANIC: Invalid argument db_recover: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database recovery done Starting ldap server(s): slapd.
Laut einschlägiger OpenLDAP-Literatur sollte db_upgrade niemals auf die bdb-Dateien des slapd angewendet werden. Ausserdem sollte beim Update auf UCS 2.3-0 (slapd 2.4.15-1.1.30.200911301011) in pre/postinst über die Funktion database_format_changed ein slapcat/move_incompatible_databases_away/slapadd durchgeführt worden sein, und somit die BDB-Dateien des LDAP Datenbank-Backends mit der neuen BDB-Library Version erzeugt worden sein. Sonst wäre das den Debian-Maintainern wohl auch schon früher mal aufgefallen..
Der Versionstest in der bdbrecover Funktion in /etc/init.d/slapd funktioniert nicht zuverlässig, weil die /var/lib/univention-ldap/ldap/log.* Dateien nicht immer verfügbar sind. Die Meldung --------------------------------------------------------------------------- Check database: od: /var/lib/univention-ldap/ldap/log.*: No such file or directory /var/lib/univention-ldap/ldap BDB Version does not seem to match the one back-bdb uses Skipping /usr/bin/db4.7_recover to avoid damage --------------------------------------------------------------------------- ist nicht kritisch, aber auch nicht schön, weil dann das db4.7_recover nicht ausgeführt wird. Gut wäre wohl, statt des aktuellen Tests der log.* Dateien ein dbX.Y_stat mit der Version X.Y aufzurufen, gegen die das OpenLDAP Backend (back_bdb.so) gebaut ist: db4.6_stat -e -h /var/lib/univention-ldap/ldap/ | grep -q 'Environment version' Nur wenn das exit status != 0 liefert (und auf stderr "Program version X.Y doesn't match environment version"), dann sollte man von einem dbX.Y_recover absehen. Sonst sollte man dbX.Y_recover ausführen. Hinweis: Wenn man die falsche db_recover Version auf eine BDB anwendet, dann hinterlässt es im BDB-Environment log.*-Dateien, die auf die Version X.Y passen, aber mit denen die alte BDB-Version nicht klarkommt. Dann startet slapd nicht. Workaround: log.* Dateien löschen.
Ist jetzt bei der Bearbeitung von Bug 22468 mit umgesetzt.
Wie besprochen, es macht vermutlich mehr Sinn, wenn wir die Dependency auf die db-utils direkt hinzufügen, da so der Nutzen für den Administrator nicht klar wird.
Das Binärpaket slapd zieht jetzt db4.8-util.
OK
UCS 3.0-0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"