Univention Bugzilla – Bug 15517
LDAP-Replikation - Fehler bei Erzeugung des failed.ldif für Modifikationen mit leerem Attributwert
Last modified: 2010-05-18 10:00:36 CEST
Scheitert die LDAP-Replikation und laufen die LDAP-Änderungen in das failed.ldif, so tritt bei Einträgen mit Modifikationen in bestimmten Fällen ein Fehler auf: # Error: Invalid syntax (21), additional info: modifiersName: value #0 invalid per syntax dn: # Hier steht die zu verändernde DN # changetype: modify replace: modifiersName modifiersName: - Dieser Eintrag wurde bei Einspielen des failed.ldif in der neu erzeugten Datei unter /tmp abgelegt. Wie zu erkennen ist, wurde der Bindestrich nicht unter den zu modifizierenden Eintrag gesetzt, sondern als Attributwert des Attributs modifiersName. Workaround: Nach Korrektur der Position des Bindestriches konnte der erzeugte ldif-Eintrag mit ldapmodify korrekt übernommen werden.
Es sieht so aus, als sei das in einer anderen Variante heute auch auf vacker aufgetreten: # Error: Undefined attribute type (17), additional info: replace: attribute type undefined dn: cn=lictemp,cn=license,cn=univention,dc=knut,dc=univentio n,dc=de changetype: modify replace: entryCSN entryCSN: 20091119105923Z#000001#00#000000 - replace: univentionLicenseBaseDN univentionLicenseBaseDN: - replace: entryUUID entryUUID: 571f07f4-6946-102e-913d-d7fcbd1fd1ec - replace: createTimestamp createTimestamp: 20091119105923Z - replace: modifyTimestamp modifyTimestamp: 20091119105923Z -
Bisherige Diagnose ist, dass hier im new Objekt anscheinend ein Attribut mit leerem Wert vom univention-directory-listener an replication.py übergeben wird. Der univention-directory-listener wurde in der Funktion cache_bew_entry_from_ldap so angepasst, dass zusätzlich beim malloc/strdup für die Werte überprüft wird, ob das gut geht (bisher nur bei attribute key und value length array). Zusätzlich wird geprüft ob bv_val NULL ist: falls das der Fall ist wird eine Meldung ausgegeben und rv!=0 zurückgegeben. Falls das dennoch wieder auftritt, wäre es gut, mehr über die Umstände zu protokollieren, insbesondere, ob der Wert des fraglichen Attributs auf dem Master ggf. tatsächlich leer gewesen sein sollte, oder ob der Attribut-key selbst (in der Zwischenzeit?) )auf dem Master gelöscht worden ist.
Es gibt im Skript univention-ldap-server-available einen Block in dem die zusätzlichen LDAP Server getestet werden, aber nur wenn $connection_okay = 0, diese Variable wird aber nicht gesetzt ? /usr/sbin/univention-ldap-server-available: ... if [ -n "$ldap_server_addition" ] && [ $connection_okay = 0 ]; then for h in $ldap_server_addition; ... Auf einem Basissystem kann ich zwar "univention-directory-policy" aus 2.3-2 installieren (und damit das angepasste univention-directory-policy-cron) aber wo auf dem Basissystem kommt "univention-ldap-server-available" her? Auf den anderen Systemrollen ist "univention-ldap-server-available" vorhanden und benutzbar.
comment#3 bitte ignorieren.
Ich kann das mit dem alten und neuen Listener leider nicht reproduzieren. failed.ldif wird benutzt wenn LDAP Server nicht erreichbar oder failed.ldif existiert. Die Daten (250 Benutzer angelegt, diverse Modifikationen vorgenommen) werden auch richtig im failed.ldif gespeichert. Beim Neustart des slapd wird das failed.ldif dann auch eingespielt.
UCS 2.3-2 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".