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.
Arvid, ist das kritisch?
Vermutlich nicht so kritisch, weil wir genau das Empfohlene ("run database recovery") kurze Zeit später tun, sobald univention-ldap-server das aktualisierte Template für /etc/init.d/slapd commited hat. Da univention-ldap-server anscheinend schon von dem slapd.postinst ausgepackt ist, machen wir jetzt einfach kurz in slapd.postinst ein commit auf das init Script bevor es gestartet wird. Gepatches openldap Paket baut gerade für i386.
Die Meldungen kommen immer noch. Richte xutils ein (1:7.3+18.27.200909190753) ... Richte univention-ldap-config ein (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. Richte univention-ldap-acl-master ein (5.0.7-1.331.200909301131) ... Installiere neue Version der Konfigurationsdatei /etc/univenti Wahrscheinlich läuft der commit auf /etc/init.d/slapd ins Leere, da das Paket univention-ldap-server (aus dem das init Skript kommt) zu diesem Zeitpunkt noch nicht konfiguriert ist.
Ja, ich denke auch: Soweit ich weiss werden die Config-Files beim Auspacken zunächst mit einer Endung .dpkg-irendwas abgelegt, daher hat der workaround hier wohl nicht das neue template committed. Erstmal wontfix, da die DB gerade frisch angelegt worden ist und im postinst von univention-ldap-server wenig später der db check korrekt durchgeführt wird.
Ja, kurz nach dem "fehlerhaften" Neustart wird univention-ldap-server und damit /etc/init.d/slapd konfiguriert und der slapd ohne Fehler neu gestartet.
UCS 2.3 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".