Univention Bugzilla – Bug 23054
Update 2.4-2 auf 3.0 - slapd postinst Fehler da ucr kaputt
Last modified: 2012-01-02 15:38:37 CET
Das Postinst von slapd hat beim Update einen Fehler erzeugt. Im Script wird ucr verwendet und dies scheint an dieser Stelle noch nicht zu funktionieren. locale: Kann LC_ALL nicht auf die Standard-Lokale einstellen: Datei oder Verzeichnis nicht gefunden Backing up /etc/ldap/slapd.conf in /var/backups/slapd-2.4.25-1.55.201107131436... done. Traceback (most recent call last): File "/usr/sbin/univention-config-registry", line 39, in ? import univention_baseconfig as ub File "/usr/lib/python2.4/site-packages/univention_baseconfig.py", line 6, in ? from univention.config_registry import * File "/usr/lib/python2.4/site-packages/univention/config_registry.py", line 43, in ? from debhelper import parseRfc822 ImportError: No module named debhelper dpkg: error while cleaning up: subprocess installed post-installation script returned error exit status 1 Wenn man usr auf der Kommandozeile starte, sieht es ähnlich aus: -> ucr Traceback (most recent call last): File "/usr/sbin/ucr", line 39, in ? import univention_baseconfig as ub File "/usr/lib/python2.4/site-packages/univention_baseconfig.py", line 6, in ? from univention.config_registry import * File "/usr/lib/python2.4/site-packages/univention/config_registry.py", line 43, in ? from debhelper import parseRfc822 ImportError: No module named debhelper
Bei verschiedenen Versuchen wurden die Pakete jeweils in leicht unterschiedlicher Reihenfolge ausgepackt und konfiguriert. U.a. bring das Paket "python" einen neuen Symlink /usr/bin/python → python2.6 mit, was aber noch nicht installiert war. Daraufhin funktioniert /usr/sbin/update-python-modules nicht mehr (wegen #!/usr/bin/python), was u.a. dafür verantwortlich ist, die Python-Dateien von /usr/share/pyshared/ nach /usr/lib/python2.[45]/site-packages/ bzw. /usr/lib/pymodules/python2.[56]/ verlinkt und vorübersetzt. Weiterhin hat im Paket python-univention die univention/__init__.py Datei gefehlt, so daß das Modul univention nicht mehr importiert werden konnte. Durch die Umstellung des Pakets "univention-python" von "dh_PyCentral" auf "dh_PySupport" tritt weiterhin das Problem auf, das im alten UCS-2.x-postinst die von PyCentral erzeugten Links in /usr/lib/python2.4/site-packages/univention/ bestehen bleiben, weil diese nur bei einem "remove", nicht aber bei einem "upgrade" entfernt werden. Dadurch werden die alten Links von dort vor den neuen Dateien unter /usr/lib/pymodules/python2.4/univention/ verwendet. svn25536, svn25540, svn25541, python-univention_6.0.9-3.101.201107211646q svn25537, svn25540, python-univention-debug_5.0.9-1.63.201107211629 svn25538, svn25540, python-univention-config-registry_7.0.14-1.346.201107211638 Das Upgrade funktioniert allerdings anschließend immer noch nicht, weil sich "slapd" nicht aktualisieren lässt: Irgendwie wird wohl während des Updates eine inkompatible BDB-Datenbank erzeugt, die dann anschließend dazu führt, das sich slapd weigert, die alten Daten wieder einzulesen: # /usr/sbin/PMH/slapcat -d 65535 -g -f /etc/ldap/slapd.conf -b dc=univention,dc=qa slapcat startup: initiated. backend_startup_one: starting "dc=univention,dc=qa" bdb_db_open: "dc=univention,dc=qa" bdb_db_open: database "dc=univention,dc=qa": dbenv_open(/var/lib/univention-ldap/ldap). bdb(dc=univention,dc=qa): Build signature doesn't match environment bdb_db_open: database "dc=univention,dc=qa" cannot be opened, err -30971. Restore from backup! ====> bdb_cache_release_all backend_startup_one (type=bdb, suffix="dc=univention,dc=qa"): bi_db_open failed! (-30971) slap_startup failed Auf "albert" ist noch meine Test-Instanz "phahn_241upgrade300" (IP: .17.97) vorhanden, die genau in dem Zustand ist, wo dieser Fehler auftritt. Auf Text-Konsole 1 läuft der per ^Z getoppte updater, aus Text-Konsole 2 ist die Fehlermeldung zu sehen. Auf dem System wurde /usr/sbin/slapcat durch ein Shell-Skript ersetzt, das solange in einer Endlos-Schleife wartet, bis die Datei /root/slapcat.wait entfernt wird. # cat /usr/sbin/slapcat #!/bin/sh while test -f /root/slapcat.wait do echo "=== $0 $@ ===" >&2 sleep 10 done exec /usr/sbin/PMH/slapcat "$@" # egrep --color 'slapd|\S*ldap\S*|libdb4\S*' /var/log/dpkg.log 2011-07-19 17:32:04 upgrade libdb4.7 4.7.25-6.7.201101311721 4.7.25-9.3.201105022022 2011-07-19 17:32:04 status half-configured libdb4.7 4.7.25-6.7.201101311721 2011-07-19 17:32:04 status unpacked libdb4.7 4.7.25-6.7.201101311721 2011-07-19 17:32:04 status half-installed libdb4.7 4.7.25-6.7.201101311721 2011-07-19 17:32:05 status half-installed libdb4.7 4.7.25-6.7.201101311721 2011-07-19 17:32:05 status unpacked libdb4.7 4.7.25-9.3.201105022022 2011-07-19 17:32:05 status unpacked libdb4.7 4.7.25-9.3.201105022022 2011-07-19 17:36:42 install libdb4.8 <none> 4.8.30-2.6.201107211546 2011-07-19 17:36:43 status half-installed libdb4.8 4.8.30-2.6.201107211546 2011-07-19 17:36:46 status unpacked libdb4.8 4.8.30-2.6.201107211546 2011-07-19 17:36:46 status unpacked libdb4.8 4.8.30-2.6.201107211546 2011-07-19 17:36:47 configure libdb4.8 4.8.30-2.6.201107211546 4.8.30-2.6.201107211546 2011-07-19 17:36:47 status unpacked libdb4.8 4.8.30-2.6.201107211546 2011-07-19 17:36:47 status half-configured libdb4.8 4.8.30-2.6.201107211546 2011-07-19 17:36:48 status installed libdb4.8 4.8.30-2.6.201107211546 2011-07-19 17:38:06 upgrade python-ldap 2.3.5-1.28.201007231750 2.3.11-1.30.201104182306 2011-07-19 17:38:06 status half-configured python-ldap 2.3.5-1.28.201007231750 2011-07-19 17:38:06 status unpacked python-ldap 2.3.5-1.28.201007231750 2011-07-19 17:38:06 status half-installed python-ldap 2.3.5-1.28.201007231750 2011-07-19 17:38:06 status half-installed python-ldap 2.3.5-1.28.201007231750 2011-07-19 17:38:06 status unpacked python-ldap 2.3.11-1.30.201104182306 2011-07-19 17:38:06 status unpacked python-ldap 2.3.11-1.30.201104182306 2011-07-19 17:39:08 upgrade slapd 2.4.23-1.47.201102221221 2.4.25-1.56.201107211639 2011-07-19 17:39:08 status half-configured slapd 2.4.23-1.47.201102221221 2011-07-19 17:39:10 status unpacked slapd 2.4.23-1.47.201102221221 2011-07-19 17:39:10 status half-installed slapd 2.4.23-1.47.201102221221 # ldd /usr/sbin/PMH/slapcat linux-gate.so.1 => (0xb7823000) libldap_r-2.4.so.2 => /usr/lib/libldap_r-2.4.so.2 (0xb77c9000) liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0xb77bd000) libdb-4.7.so => /usr/lib/libdb-4.7.so (0xb7664000) libodbc.so.1 => /usr/lib/libodbc.so.1 (0xb75fd000) libslp.so.1 => /usr/lib/libslp.so.1 (0xb75ed000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb75d6000) libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb758c000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7433000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7401000) libresolv.so.2 => /lib/libresolv.so.2 (0xb73ed000) libltdl.so.3 => /usr/lib/libltdl.so.3 (0xb73e6000) libwrap.so.0 => /lib/libwrap.so.0 (0xb73de000) libpthread.so.0 => /lib/libpthread.so.0 (0xb73c5000) libc.so.6 => /lib/libc.so.6 (0xb727f000) libltdl.so.7 => /usr/lib/libltdl.so.7 (0xb7277000) libnsl.so.1 => /lib/libnsl.so.1 (0xb7260000) libdl.so.2 => /lib/libdl.so.2 (0xb725c000) libz.so.1 => /usr/lib/libz.so.1 (0xb7248000) /lib/ld-linux.so.2 (0xb7824000) # file /var/lib/univention-ldap/ldap/* /var/lib/univention-ldap/ldap/DB_CONFIG: ASCII English text /var/lib/univention-ldap/ldap/__db.001: Applesoft BASIC program data /var/lib/univention-ldap/ldap/__db.002: data /var/lib/univention-ldap/ldap/__db.003: data /var/lib/univention-ldap/ldap/__db.004: data /var/lib/univention-ldap/ldap/__db.005: data /var/lib/univention-ldap/ldap/__db.006: data /var/lib/univention-ldap/ldap/aRecord.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/alock: data /var/lib/univention-ldap/ldap/cNAMERecord.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/cn.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/description.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/dhcpHWAddress.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/displayName.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/dn2id.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/gidNumber.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/homeDirectory.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/id2entry.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/kolabHomeServer.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/krb5PrincipalName.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/log.0000000004: Berkeley DB (Log, version 14, native byte-order) /var/lib/univention-ldap/ldap/log.0000000005: Berkeley DB (Log, version 14, native byte-order) /var/lib/univention-ldap/ldap/mail.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/mailAlternativeAddress.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/mailPrimaryAddress.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/memberUid.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/objectClass.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/pTRRecord.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/relativeDomainName.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/sambaAcctFlags.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/sambaDomainName.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/sambaGroupType.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/sambaPrimaryGroupSID.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/sambaSID.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/secretary.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/sn.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/uid.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/uidNumber.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/uniqueMember.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/univentionLicenseModule.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/univentionLicenseObject.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/univentionNagiosHostname.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/univentionPolicyReference.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/univentionServerRole.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/univentionService.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/univentionShareGid.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/univentionShareSambaName.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/univentionShareWriteable.bdb: Berkeley DB (Btree, version 9, native byte-order) /var/lib/univention-ldap/ldap/zoneName.bdb: Berkeley DB (Btree, version 9, native byte-order) # grep ^debug /etc/dpkg/dpkg.cfg debug 3 # tail/var/log/univention/updater.log Preparing to replace slapd 2.4.23-1.47.201102221221 (using .../slapd_2.4.25-1.56.201107211639_i386.deb) ... D000001: process_archive oldversionstatus=installed D000002: fork/exec /var/lib/dpkg/info/slapd.prerm ( upgrade 2.4.25-1.56.201107211639 ) * Stopping ldap server(s): slapd ...done. D000002: fork/exec /var/lib/dpkg/tmp.ci/preinst ( upgrade 2.4.23-1.47.201102221221 ) D000001: cmpversions a=`0:2.4.23-1.47.201102221221' b=`0:2.4.23-4' r=-3 D000001: cmpversions a=`0:2.4.23-1.47.201102221221' b=`0:2.4.23-4' r=-3 Dumping to /var/backups/slapd-2.4.23-1.47.201102221221: - directory dc=univention,dc=qa... === /usr/sbin/slapcat -g -f /etc/ldap/slapd.conf -b dc=univention,dc=qa === # uname -a Linux update231300 2.6.32-ucs44-686-bigmem #1 SMP Fri Jul 1 17:38:51 UTC 2011 i686 GNU/Linux
bdb(dc=univention,dc=qa): Build signature doesn't match environment sollte mit Bug 22750 gefixt worden sein, d.h. mit neu gebauten db4.8
Das Upgrade von 2.4 auf 3.0 funktioniert jetzt seit Bug #22878 nicht mehr, da normalerweise die TC-Umgebung installiert ist, die vom PreUp.sh-Skript erkannt wird, dafür die "current"-Komponete TCS einträgt, die aber nicht vorhanden ist, womit das gesamte Upgrade derzeit scheitert. Vor einem Upgrade muß man deshalb "apt-get remove univention-thin-client-basepackage" ausführen. Das Upgrade-Problem zwischen "python-minimal" und "python-support" ist ein Debian-Problem: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610978>. Leider dort derzeit ohne Lösung. Das Debian-Policy-Manual sagt folgendes dazu <http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps>: Depends: A `Depends' field takes effect _only_ when a package is to be configured. It does not prevent a package being on the system in an unconfigured state while its dependencies are unsatisfied,... Pre-Depends: Pre-Depends should be used sparingly, preferably only by packages whose premature upgrade or installation would hamper the ability of the system to continue with any upgrade that might be in progress. Ursache ist hier, das das neue python-minimal entpackt wird und dabei /usr/bin/python überschreibt. Das Paket wird allerdings noch nicht konfiguriert, weil python2.6-minimal noch nicht entpackt und konfiguriert wurde; der Link zeigt also ins Leere. Ein anderes Paket ruft python-support auf, was den kaputten Link verwendet und den Upgrade-Vorgang abbricht. Vor einem Upgrade habe ich jetzt per Hand folgende Pakete aktualisiert: apt-get install libssl0.9.8 python-central python2.6-minimal Damit lief es dann erstmal. Das LDAP-Upgrade besteht weiterhin. Ursache ist ein Unterschied in libdb4.7, welches seine Signatur ändert, die man mit <http://anonscm.debian.org/gitweb/?p=pkg-db/db.git;a=blob_plain;f=debian/db_signature.c;hb=HEAD> auslesen kann: # for l in /usr/lib/libdb-4.?.so;do gcc debian_db_signature.c -l${l:12:6}&&echo -n "$l "&&./a.out;done UCS-2.4-2: /usr/lib/libdb-4.7.so e4702a89 ←←← /usr/lib/libdb-4.8.so 7523bc5e UCS-3.0-0 /usr/lib/libdb-4.7.so 876ea0c1 /usr/lib/libdb-4.8.so 7523bc5e Debian Squeeze: /usr/lib/libdb-4.7.so 876ea0c1 /usr/lib/libdb-4.8.so 7523bc5e # apt-cache policy libdb4.7 Installiert: 4.7.25-6.7.201101311721 Kandidat: 4.7.25-6.7.201101311721 Versions-Tabelle: *** 4.7.25-6.7.201101311721 0 500 http://univention-repository.knut.univention.de 2.4-2/amd64/ Packages 100 /var/lib/dpkg/status # apt-cache rdepends libdb4.7 Reverse Depends: slapd # apt-cache policy slapd Installiert: 2.4.23-1.47.201102221221 Kandidat: 2.4.23-1.47.201102221221 Versions-Tabelle: *** 2.4.23-1.47.201102221221 0 500 http://univention-repository.knut.univention.de 2.4-2/amd64/ Packages 100 /var/lib/dpkg/status
Created attachment 3435 [details] Dump DB Signature Gegen das libdb4.7-Upgrade-Problem hilft ein vorzeitiges Anstoßen des Upgrades von "slapd", ohne (vorher) "libdb4.7" zu aktualisieren. Dadurch werden dann folgende Pakete aktualisiert: ldap-utils libcompress-raw-zlib-perl libcompress-zlib-perl libio-compress-base-perl libio-compress-zlib-perl libldap-2.4-2 libperl5.10 perl perl-base perl-modules slapd slapd moniert beim Start anschließend das Fehlen des Pakets "db4.8" für seinen Datenbankcheck, von daher sollte man das mit installieren.
Das Update danach scheiterte weiterhin daran, da die .../univention/__init__.py-Datei vom Paket python-univention-config-registry nach python-univention verschoben wurde. Letzteres hat die Datei durch ein Replaces: ordnungsgemäß übernommen, allerdings haben beide Pakete im PreInst-Skript die python-central-Altlasten per "pycentral pkgremove ..." entfernt, was intern ein "dpkg -L" verwendet, um die zum Paket gehörigen Python-Dateien aufzulisten. Bei folgender Reihenfolge blieb die Datei dabei bestehen: 1. PreInst python-univention → pycentral pkgremove python-univention 2. Unpack python-univention → __init__.py gehört jetzt p-u 3. PreInst python-univention-c-r → pycentral pkgremove python-univention-c-r → __init__.py wird hier bereits nicht mehr bei "dpkg -L p-u-c-r" aufgelistet, weshalb /usr/lib/python2.4/site-packages/univention/__init__.py bestehen blieb Installiert man zuerst p-u-c-r und danach p-u, wird die Datei entfernt. Um das zu erzwingen wurde jetzt in p-u ein "Breaks: p-u-c-r (<< 7)" ergänzt, um zuerst ein Upgrade von p-u-c-r zu erzwingen. Ggf. ist hier auch ein Breaks: p-u-debug und p-u-license sinnvoll, aber diese beiden Pakete benötigen ihrerseits eine Shared-Objekt-Bibliothek, die speziell für Python2.4 übersetzt werden muß. Dies ist nicht mehr Bestandteil von Debian-Squeeze und damit auch nicht mehr von UCS-3.0. Das führt jetzt am Ende des Upgrade zu folgendem Fehler: Am Ende führt der der ALTE Updater (der noch Python2.4 verwendet) das interne Äquivalent zu "ucr set version/version=3.0" aus. Dieses ruft univention.config_registry.handler_set() auf, was über die configHandler*-Aufruft irgendwann auch filter() aufruft, das (noch) den fest kodierten Pfad zu /usr/bin/python2.4 enthält. Der Interpreter existiert zwar noch, allerdings funktioniert das nachfolgende "import univention.config_registry" dort nicht mehr, was zu unschönen Fehlern führt. Ansonsten läuft das Update jetzt erstmal durch, weshalb ich diesen Bug damit schließe. Für die Probleme im Updater bei der Umstellung von Python2.4 auf Python2.6 mache ich einen neuen Bug auf. svn25984, univention-python_6.0.11-1.103.201108081935 Kein ChangeLog-Eintrag notwendig, da Upgrade Problem.
Update mit univention-updater net von 2.4-3 auf 3.0-0 hat funktioniert.
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"
*** Bug 23227 has been marked as a duplicate of this bug. ***