Bug 15517 - LDAP-Replikation - Fehler bei Erzeugung des failed.ldif für Modifikationen mit leerem Attributwert
LDAP-Replikation - Fehler bei Erzeugung des failed.ldif für Modifikationen mi...
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: LDAP
UCS 2.1
Other Linux
: P3 normal (vote)
: UCS 2.3-2
Assigned To: Arvid Requate
Felix Botner
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-27 13:07 CEST by Roman Asendorf
Modified: 2010-05-18 10:00 CEST (History)
1 user (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Asendorf univentionstaff 2009-08-27 13:07:26 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.
Comment 1 Arvid Requate univentionstaff 2009-12-21 14:45:33 CET
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
-
Comment 2 Arvid Requate univentionstaff 2010-04-06 15:49:00 CEST
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.
Comment 3 Felix Botner univentionstaff 2010-04-23 11:13:27 CEST
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 4 Felix Botner univentionstaff 2010-04-23 11:51:21 CEST
comment#3 bitte ignorieren.
Comment 5 Felix Botner univentionstaff 2010-04-26 08:55:18 CEST
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.
Comment 6 Stefan Gohmann univentionstaff 2010-05-18 10:00:36 CEST
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".