Ich habe folgende Umgebung: - DC Master 2.4-0 - DC Backup 2.3-2 - DC Slave 2.3-2 - Memberserver 2.3-2 Auf dem DC Slave ist irgendwann die LDAP-Replikation gescheitert und es wurde ein failed.ldif erstellt. Das erste Objekt, dass nicht eingespielt werden konnte hatte einen modifyTimestamp mit Microsekunden: # Error: Invalid syntax (21), additional info: modifyTimestamp: value #0 invalid per syntax dn: cn=nextUnixId,cn=idmap,cn=univention,dc=nagios3,dc=local changetype: modify replace: entryCSN entryCSN: 20100706114250.352726Z#000000#000#000000 - replace: modifiersName modifiersName: cn=update,dc=nagios3,dc=local - replace: gidNumber gidNumber: 55005 - replace: modifyTimestamp modifyTimestamp: 20100706114250.352726 Auf dem DC Backup hat die Replikation geklappt.
Unter utby:/mnt/utby/md0/crunchy/bug-18927 liegt eine Kopie der Umgebung
*** Bug 18928 has been marked as a duplicate of this bug. ***
1. Wenn modifizierte Records mit einer entryCSN im OL24 Microsekundenformat repliziert werden, generiert der Zielserver den modifyTimestamp aus dem entryCSN. Bei diesem Schritt macht etwas dadurch die Syntax kaputt dass das abschliessende 'Z' weggelassen wird. Wahrscheinlich sind es zwei der für UCS 2.3-0 zurückportierten Patch-hunks, die Teil des Patch-sets 70_revert_microsecond_patches.patch sind und eine Änderung von Howard Chu zurücknehmen, die im Zuge der Umstellung auf das OL24 Microsekundenformat entwickelt worden sind. Ziel von Chu's Anpassungen war zu verhindern, dass der Mikrosekunden-Teil aus dem entryCSN in den modifyTimestamp kopiert wird. Die beiden zurückportierten Patch-hunks entfernen leider diese Vorsichtsmassnahme. Um das Problem an diesem Bug zu lösen, wirden sie aus dem Patch-set 70_revert_microsecond_patches.patch entfernt, um die Erzeugung defekter modifyTimestamps wenigstens ab ucs_2.4-0 zu vermeiden: servers/slapd/add.c servers/slapd/modify.c ---------------------------- revision 1.288 date: 2007/02/02 22:10:30; author: hyc; state: Exp; lines: +3 -5 [...]. Omit microseconds from modifyTImestamp... ---------------------------- 2. Alle OpenLDAP Versionen vor der UCS_2.4-0 Version enthalten nicht Howard Chu's Anpassung und werden daher wahrscheinlich einfach nur (LDAP_LUTIL_GENTIME_BUFSIZE - 1) Zeichen aus entryCSN nach modifyTimestamp kopieren - was 22-1=21 Zeichen sind (Länge von "YYYYmmddHHMMSS.uuuuuu", d.h. ohne abschliessendes 'Z', überprüft am openldap2 Code aus ucs_2.0-0 / OL21). Solange wir daher nicht garantieren können, dass keine Replikation neuer entryCSNs in Server mit patch-Stand vor UCS 2.4-0 passiert, dürfen wir keine entryCSNs im neuen OL24 Microsekundenformat erzeugen. Das ist der Grund, warum wir die folgenden zwei Patch-sets wohl wieder aktivieren müssen: * 70_revert_microsecond_patches.patch (Erzeugung neuer entryCSNs in lutil_csnstr) * 71_OL23_entryCSN_validation.patch (entryCSN Syntax Verifikation und stille Konvertierung in das OL24 format) Da der 70_revert_microsecond_patches.patch sich nicht mehr ohne Modifikation auf openldap-2.4.22 anwenden liess, habe ich ihn mal testweise auf das Minimum reduziert, d.h. auf die Anpassung der Funktion lutil_csnstr. Die Funktion ldap_pvt_gettime erzeugt jetzt erstmal weiter ein zusätzliches tm_usub ("submicro") Datenfeld in der Zeitstruktur lutil_tm. Ich denke das ist aus zwei Gründen unkritisch, da erstens für die (neuen) entryCSNs nur tm_usec ("microseconds") ausgewertet würde und da zweitens tm_usec schon vor OL23 existiert hat.
Ich habe einen UCS 2.4-0 Master, einen UCS 2.3 Master und Slave. Der Slave repliziert gegen den Backup: slave-> grep conne /var/log/univention/listener.log 13.08.10 10:49:13 LISTENER ( ERROR ) : connection okay to host qabackup.ldap Auf dem Master wird folgendes ausgeführt. while true; do for i in $(seq 1 100); do udm users/user create --set password=univention --set lastname=a \ --set username=testuser$i done sleep 10 for i in $(seq 1 100); do udm users/user remove --dn "uid=testuser$i,dc=ldap" done done Auch nach mehreren Stunden wurden kein failed.ldif wegen eines falschen modifyTimestamp erzeugt. Zur Info: Auf dem Slave hatte ich einmal ein failed.ldif wegen eines doppelten uniqueMember Eintrag. Auf Master und Backup war alles OK. Aber, kein Changlog Entrag.
Die alten Patches wurden reaktiviert, deshalb ist der Changelog-Eintrag nicht zwingend. Ich habe die Bugnummer jetzt beim OpenLDAP-Update Changelog-Eintrag hinzugefügt.
ok
UCS 2.4 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".