Univention Bugzilla – Bug 16275
DC Backup slapd Update Fehler
Last modified: 2009-12-21 08:50:07 CET
Betreff: [amd64][domaincontroller_backup][ucs-auto-update] Update failed Von: uild-changes@univention.de An: build-changes@univention.de Datum: Heute 02:44:32 Setting up slapd (2.4.15-1.1.23.200911021558) ... Installing new version of config file /etc/default/slapd ... Installing new version of config file /etc/ldap/schema/openldap.schema ... Installing new version of config file /etc/ldap/schema/inetorgperson.schema ... Installing new version of config file /etc/ldap/schema/dyngroup.schema ... Installing new version of config file /etc/ldap/schema/misc.schema ... Installing new version of config file /etc/ldap/schema/openldap.ldif ... Installing new version of config file /etc/ldap/schema/nis.schema ... Installing new version of config file /etc/ldap/schema/ppolicy.schema ... Installing new version of config file /etc/ldap/schema/core.ldif ... Installing new version of config file /etc/ldap/schema/java.schema ... Installing new version of config file /etc/ldap/schema/README ... Installing new version of config file /etc/ldap/schema/corba.schema ... Installing new version of config file /etc/ldap/schema/core.schema ... Installing new version of config file /etc/ldap/schema/cosine.schema ... 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... failed. Loading the database from the LDIF dump failed with the following error while running slapadd: str2entry: invalid value for attributeType modifyTimestamp #0 (syntax 1.3.6.1.4.1.1466.115.121.1.24) slapadd: could not parse entry (line=4878) dpkg: error processing slapd (--configure): subprocess post-installation script returned error exit status 1
Auf dem schon aktualisierten DC Master wurde das folgende Objekt angelegt: dn: cn=UCS 2.3,cn=desktop,cn=policies,dc=auto,dc=update,dc=test cn: UCS 2.3 objectClass: top objectClass: univentionPolicy objectClass: univentionPolicyDesktop creatorsName: cn=admin,dc=auto,dc=update,dc=test entryUUID: c403316e-6055-102e-86cd-53017b6c4fbd createTimestamp: 20091108015708Z structuralObjectClass: univentionPolicyDesktop entryCSN: 20091108015708.534823Z#000000#000#000000 univentionDesktopProfile: /usr/share/univention-kde-profiles/ucs-23 univentionDesktopProfile: /usr/share/univention-kde-profiles/ucs-23-kde-menu modifiersName: cn=update,dc=auto,dc=update,dc=test modifyTimestamp: 20091108015708.534823 Die modifyTimestamp-Syntax hat sich scheinbar geändert: root@master:~# grep modifyTimestamp dc\=auto\,dc\=update\,dc\=test.ldif | tail modifyTimestamp: 20091108015826Z modifyTimestamp: 20091108015826Z modifyTimestamp: 20091108015826Z modifyTimestamp: 20091108015826Z modifyTimestamp: 20091108015826Z modifyTimestamp: 20091108015827Z modifyTimestamp: 20091108015827Z modifyTimestamp: 20091108015827Z modifyTimestamp: 20091108015827Z modifyTimestamp: 20091108015827Z
Die einfachste Möglichkeit ist wohl das ldif an den entsprechenden Stellen zu modifizieren. Mir ist nicht ganz klar, warum das bei den letzten Autotests nicht aufgefallen ist, sondern erst seit ein paar Tagen. @Arvid, könnte das an den letzten Änderungen im Bereich OpenLDAP/univention-ldap liegen. Bspw. an Bug #16193?
Ber der QA sollte getestet werden, ob ein 2.2 DC Slave oder DC Backup problemlos von einem 2.3 DC Master replizieren kann.
Die Meldung kommt aus dem slapd.postinst vom OpenLDAP 2.3 slapadd. Ich denke hier fehlt die Timezone ('Z' für GMT), die Nachkommastellen ('fractions') sollten ok sein, siehe Abschnitt 3.3.13 in http://www.ietf.org/rfc/rfc4517.txt An der Sytnax von modifyTimestamp hat sich soweit ich sehe im Code Nichts geändert. War der Eintrag auf dem Master per 'ldapsearch -x -s base -b "cn=UCS 2.3,cn=desktop,cn=policies,dc=auto,dc=update,dc=test" modifyTimestamp +' sichtbar (oder per slapcat)? Im Moment sehe ich auf den Autoupdate-Systemen leider keinen derartigen Eintrag. Als Workaround wird vorerst das im slapd.preinst erzeugte ldif auf genau diesen Fall durchsucht (modifyTimestamp mit fractions ohne timezone und ohne 'g-differential' syntax) und dann ein 'Z' angehängt.(36_fix_modifyTimestamp_timezone.patch) Da entryCSN noch korrekt ist und createTimestamp != modifyTimestamp könnte es sein, dass hier ein Problem im neuen modify.c vorliegt, ich finde da aber andererseits derzeit noch keine Reports zu.
Das Replizieren von Master 2.3 auf Backup 2.2 klappt, Update (slapd) des 2.2er System auch, dabei wird an die modifyTimestamps ohne Z am Ende ein Z angehangen Eine Sache ist komisch, der 2.2 slapd vergibt die modifyTimestamp manchmal mit Z und manchmal ohne master2.3-> slapcat -a uid=bond | grep modifyT modifyTimestamp: 20091110111140Z backup2.2-> slapcat -a uid=bond| grep modifyT modifyTimestamp: 20091110111140Z master2.3-> slapcat -a uid=hans | grep modifyT modifyTimestamp: 20091110110907Z backup2.2-> slapcat -a uid=hans| grep modifyT modifyTimestamp: 20091110110907.852430
D.h. hier wurde wieder ein Fall dokumentiert, in dem der OpenLDAP 2.3 Server einen Eintrag mit modifyTimestamp ohne Timezone angelegt hat. Ein kurzer Test ergab, dass dieser slapd bei einem restart keine Probleme damit hat. Somit sollte der 36_fix_modifyTimestamp_timezone.patch (betrifft slapd preinst) ausreichend sein.
Nach dem internen Update des DC-Master haben nun alle DC-Slaves (noch auf 2.2-2) failed.ldifs aufgrund der falschen Syntax von modifyTimestamp. Ich hänge als Beispiel eine Rejects-File sowie die Authentifizieren (als DC-Slave) ldapsearch + Ausgaben der entsprechenden Objekte an.
Created attachment 2001 [details] modifyTimestamp rejects
Created attachment 2002 [details] Zurückgewiesene Objekte
http://archive.netbsd.se/?ml=OpenLDAP-devel&a=2007-02&t=3072903 "In preparation for the upcoming syncrepl changes, I've updated liblutil to generate CSNs with microseconds in the timestamp. Currently slapd copies the entryCSN timestamp to the createTimestamp and modifyTimestamp attributes when generating these attributes. Anyone have any thoughts on whether it would be a too-surprising change for these attributes to now have higher resolution?"
Ich nehme an, dass auf den pre-UCS 2.3 (d.h. OpenLDAP 2.3) Systemen, die von einem ungepatchten OpenLDAP 2.4 Server replizieren, modifyTimestamp wie gehabt aus entryCSN extrahiert wird. Wenn ein entryCSN das neue Format mit Microsekunden hat, dann könnte dabei der fehlerhafte modifyTimestamp entstehen. Ich habe die Änderungen an entryCSN aus dem OpenLDAP CVS extrahiert, die mit folgendem Checkin in Verbindung stehen: Log Message: Add lutil_gettime() returning structured time with microseconds. Use microseconds in CSNs. Omit microseconds from modifyTImestamp... http://markmail.biz/search/?q=microseconds+list%3Aorg.openldap.openldap-commit Die Änderungen betreffen insgesamt 5 Dateien im OpenLDAP Code und sind mit den CVS Logmeldungen in einem Patch zusammengefasst: svn/patches/openldap/2.3-0-0-ucs/2.4.15-1.1/70_revert_microsecond_patches.patch * revert the microseconds changes to entryCSN which in some situations seem to affect modifyTimestamp (Bug #16275) OpenLDAP 2.4-15 ist für i386 neu gebaut.
Die timestamps sehen auf dem Master (2.3) und dem Backup (2.2) gut aus. Aber auf dem Master gibt es wieder "entryCSN" Einträge mit Microsekunden. master2.3 -> slapcat | grep entryCSN ... entryCSN: 20091117095909.000000Z#000003#000#000000 entryCSN: 20091117101352.000000Z#000000#000#000000 entryCSN: 20091117101352.000000Z#000001#000#000000 entryCSN: 20091117101347.000000Z#000002#000#000000 entryCSN: 20091117101347.000000Z#000003#000#000000 entryCSN: 20091117101347.000000Z#000004#000#000000 entryCSN: 20091117101352.000000Z#000002#000#000000 entryCSN: 20091117111617Z#000008#00#000000 entryCSN: 20091117111617Z#000007#00#000000 entryCSN: 20091117111713Z#000001#00#000000 ... Die Sachen, die ich nach dem Update geändert habe, bekommen anscheinend den entryCSN Eintrag ohne Microsekunden. # uid bond nach dem Update auf dem Master angelegt master2.3 -> slapcat -a uid=bond| grep entryCSN entryCSN: 20091117113703Z#00000b#00#000000 Im ldif File, das während des Updates erstellt wird, sind die entryCSN Einträge ohne Microsekunden. Vor dem Update gab es auf dem Master auch kein entryCSN Einträge mit Microsekunden. Auf dem Backup waren nach dem Update des Master und der Replikation die entryCSN Einträge OK (d.h. ohne Microsekunden). Das Replizieren hat funktioniert (es gab kein failed.ldif).
(In reply to comment #12) > Die timestamps sehen auf dem Master (2.3) und dem Backup (2.2) gut aus. Aber > auf dem Master gibt es wieder "entryCSN" Einträge mit Microsekunden. Welche Objekte haben die Microsekunden-Einträge? Wann wurden die modifiziert oder generiert? Die modifyTimestamp Werte sind aber in Ordnung? Kannst du die Objekte mit den entryCSN-Microsekunden-Einträge einmal modifizieren? Wie sieht dann der modifyTimestamp Wert aus?
> > Welche Objekte haben die Microsekunden-Einträge? Wann wurden die modifiziert > oder generiert? Alle, außer die, die ich modifiziert/angelegt habe. > Die modifyTimestamp Werte sind aber in Ordnung? Kannst du die Objekte mit den > entryCSN-Microsekunden-Einträge einmal modifizieren? Wie sieht dann der > modifyTimestamp Wert aus? Bei modifizierten/neu angelegten Objekten sind entryCSN und modifyTimestamp OK.
Dann ist der Status akzeptabel.
Initial sind die entryCSN Einträge mit Microsekunden. Ändert/verschiebt man ein Objekt oder legt ein neues an, sind dessen entryCSN Einträge ohne Microsekunden.
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".