Univention Bugzilla – Bug 20605
Verschieben von LDAP-Benutzerobjekten erstellt Objekte neu
Last modified: 2014-04-04 19:19:13 CEST
Wird ein Benutzerobjekt im UCS-LDAP verschoben, so aktualisiert die Synchronisation ucs2scalix nicht das Attribut FOREIGN-ADDR, welches (vermutlich) die DN im UCS-LDAP wiederspiegelt. Damit verbleibt das Benutzerobjekt im Scalix-LDAP an der selben Stelle, weitere Aktionen, wie z.B. das ändern von Gruppenmitgliedschaften führen dann dazu, dass die Änderungen im Scalix-System nicht realisiert werden können. Beispiel: Benutzer A: uid=A,cn=users,ou=030,dc=example,dc=com Verschieben von A in OU 150: uid=A,cn=users,ou=150,dc=example,dc=com Scalix FOREIGN-ADDR vor und nach dem Verschieben: uid=A,cn=users,ou=030,dc=example,dc=com Änderung der Gruppen-Mitgliedschaft im UDM, Meldung sync.log: >>>>>>>>SOAP Request SOAP part: <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header/> <SOAP-ENV:Body> <scalix-caa:CAARequestMessage xmlns:scalix-caa="http://www.scalix.com/caa"> <ServiceType>scalix.res</ServiceType> <Credentials id="12345"> <Identity name="ucsldapimport" passwd="xxxxxxxx"/> </Credentials> <FunctionName>AddMembersToGroup</FunctionName> <AddMembersToGroupParameters id="de695c84-1d65-102c-9acf-ed6b609791a2"> <member fa="uid=A,cn=users,ou=150,dc=example,dc=com"/> </AddMembersToGroupParameters> </scalix-caa:CAARequestMessage> </SOAP-ENV:Body> </SOAP-ENV:Envelope> >>>>>>>>SOAP Response SOAP part: <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Server</faultcode> <faultstring>CAA Service Error</faultstring> <detail> <scalix-caa:fault-details xmlns:scalix-caa="http://www.scalix.com/caa"> <message>Failed to obtain CN, MailNode for all the members in the Request SOAP Document from LDAP server scalix.example.com</message> <errorcode>UM-1019</errorcode> </scalix-caa:fault-details> </detail> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 0 entries passed 1 entries failed 0 entries warned Die Scalix-Synchronisation bekommt vom UCS-LDAP die neue DN und versucht diese im Scalix-LDAP aufzulösen, was zu dem obigen Fehler führt: <member fa="uid=A,cn=users,ou=150,dc=example,dc=com"/> ... <message>Failed to obtain CN, MailNode for all the members in the Request SOAP Document from LDAP server scalix.example.com</message>
Dieser Fehler wird durch die Umsetzung von Bug #20317 hervorgerufen. Weitere Informationen finden sich an Bug #16287 und Ticket 2010101410000971. An dem Ticket wird auch ein Workaround beschrieben, der omldapsync -u ucs2scalix (-P, -L, -S) verwendet, jedoch funktioniert dieser nicht, da die FOREIGN-ADDR im Scalix-LDAP falsch ist.
Der Scalix-LDAP ist grundsätzlich eine flache Abbildung des X.400-Verzeichnisses. Im Sinne der Scalix-Architektur wäre ein "Verschieben" eine Änderung des Mailnodes, also der Kombination der OU1-OU4 in Scalix. Dies ist aber eine Funktion, die die Scalix Management Services nicht bereitstellen. Dieser Aspekt kann hier also außer Acht gelassen werden. Es ist richtig, dass das Attribut FOREIGN-ADDR den dn des UCS-LDAP enthält. Dieses Mapping erfolgt über die Zeile "dn|FOREIGN-ADDR|*,1,512|*" in /var/opt/scalix/??/s/ldapsync/ucs2scalix/sync.cfg. Das Attribut ist aber rein informativ und wird nicht benutzt, um eine Referenz auf das Objekt im führenden LDAP herzustellen. Diese Referenz erfolgt beim omldapsync immer über das LDAP-Attribut, welches der Variablen EX_GUID in o.g. sync.cfg zugewiesen wird. Im Falle der UCS-Integration wäre das also entryUUID. Wenn es also zutrifft, dass wie in Bug #20317 beschrieben, beim Verschieben eines User-Objektes in einen anderen LDAP-Container die Mailbox gelöscht wird, sollte zunächst geprüft werden, ob sich beim Verschieben evtl. die entryUUID geändert hat. Eigentlich sollte so etwas nicht passieren. Bei Tests in einem reinen UCS 2.2 konnte ich weder das hier noch das in Bug #20317 (Ausnahme: Objekt entfernen) beschriebene Verhalten reproduzieren. Ich habe aber auch aus Zeitgründen nicht zwischen verschiedenen organisational units verschoben. Der in #20317 beschriebene Workaround in einem solchen Fall ungeeignet. Er hat zur Folge, dass die Mailboxdaten zwar erhalten bleiben, das Mailboxobjekt an sich aber nachfolgend nicht mehr durch omldapsync aktualisiert wird. Weitere Veruche, ein Mailboxobjekt mit denselben Attributen - relevant wären uid, sn, g, displayname, scalixMailnode und mail* - über die Integration einzurichten, werden scheitern, da ein deratiges Objekt bereits existiert.
Die Pflege von Scalix4UCS soll direkt durch Scalix erfolgen: http://www.univention.de/univention/presse/pressemitteilungen/univention-und-scalix-definieren-kooperation-neu/ Hier ist von uns keine weitere Aktion notwendig, deshalb WONTFIX.
Dieser Bug ist aus meiner Sicht nie ein "Scalix for UCS" Problem gewesen. Die Beschreibung lässt den Schluss zu, dass aus bisher nicht bekannten Gründen beim Verschieben eine neue entryUUID erzeugt wird. Siehe comment #2 So etwas könnte auch in anderen Fällen zu Problemen führen.
(In reply to comment #4) > Die Beschreibung lässt den Schluss zu, dass aus bisher nicht bekannten Gründen > beim Verschieben eine neue entryUUID erzeugt wird. Siehe comment #2 > > So etwas könnte auch in anderen Fällen zu Problemen führen. Beim normalen Umbenennen wird das Objekt nicht neu erzeugt. Ich könnte mir nur vorstellen, dass es durch unsere LDAP Replikation neu generiert wird. Wenn dem so ist, dann ist das ein Listener Problem. Der Bug ist jetzt entsprechend verschoben.
Eine mögliche Ursache für das ursprünglich beschriebene Problem (und das, was ich nun wieder bei einem anderen Scalix/UCS-Kunden gesehen habe) wäre die Behandlung des Attributs "entryUUID" durch UCS selbst. In #c2 habe ich bereits erwähnt, dass zumindest für den omldapsync von Scalix "entryUUID" das Attribut ist, anhand dessen ein Objekt eindeutig identifiziert wird. In UCS 2.4 (ich habe nicht auf 3.0 getestet) liefert ldapsearch das Attribut entryUUID nur, wenn es explizit angefordert wird. Bei der Ausgabe von "slapcat" ist es dabei. Wenn sich also Prozesse zur Manipulation von LDAP-Objekten auf die Ausgabe von ldapsearch verlassen und dabei nicht alle wirklich existierenden Informationen erhalten, wird es zwangsläufig immer wieder zu Problemen kommen. Aus meiner Sicht ist das insofern kritisch, da "univention-ldap-backup" eben ldapsearch benutzt und die Dumps in /var/univention-backup zumindest hinsichtlich des Attributes entryUUID unvollständig sind.
(In reply to comment #6) > Aus meiner Sicht ist das insofern kritisch, da "univention-ldap-backup" eben > ldapsearch benutzt und die Dumps in /var/univention-backup zumindest > hinsichtlich des Attributes entryUUID unvollständig sind. Ab UCS 3.0 verwendet univention-ldap-backup das Tool slapcat.
1. Bei einer modrdn Operation schreibt translog zusätzlich zum rename-Eintrag ('r') auch einen add-Eintrag. 2. replication.py könnte modrdn='y' deklarieren, damit der handler als viertes Argument das command übergeben bekommt. Vielleicht reicht es 2. anzupassen, weil dann die zusätzliche add-Operation wahrscheinlich intern in replication.py wegen "new and old" als Modifikation des existierenden Objekts mit dem neuen DN behandelt wird (also vermutlich nichts zu tun ist). Sonst scheint es in cyrus-shared-folder.py einen workaround zu geben, der bei 'r' das alte Objekt pickled und dann bei der nachfolgenden Operation restauriert. Diese Anpassung macht allerdings nur die Replikation transparent für die modrdn Operation. Komponenten-spezifische Listener-Module müssten separat analog angepasst werden.
Siehe auch Bug 24482
(In reply to comment #8) > 2. replication.py könnte modrdn='y' deklarieren, damit der handler als viertes > Argument das command übergeben bekommt. Das muß unbedingt „modrnd='1'” sein, der Listener akzeptiert nur die Zeichenekette '1'. Vgl. <http://wiki.univention.de/index.php?title=Entwicklung_von_Univention_Directory_Listener-Modulen#Header-Informationen>
(In reply to comment #10) > (In reply to comment #8) > > 2. replication.py könnte modrdn='y' deklarieren, damit der handler als viertes > > Argument das command übergeben bekommt. > > Das muß unbedingt „modrnd='1'” sein Natürlich war „modrdn='1'” gemeint
replication.py behandelt jetzt modrdn speziell: Während der 'r' Operation (old and not new) wird die dn des zu verschiebenden Objekts in eine neue Datei geschrieben, deren Dateiname sich aus der entryUUID ergibt. In der nachfolgenden 'a' Operation (new and not old) wird geprüft, ob für die aktuelle entryUUID eine Datei vorliegt; falls ja, dann wird die alte DN aus der Datei gelesen, die Datei gelöscht und eine python-ldap rename_s Operation ausgeführt. Falls sich die Datei in Phase 1 unerwartet nicht anlegen lässt, wird eine Fehlermeldung ausgegeben und dann ein normaler Delete ausgeführt, sodass das Verfahren dann wie bisher läuft.
Folgendes Replikationsszenario: Master → Backup → Slave Auf dem Master habe ich eine Gruppe angelegt: udm groups/group create --set name=gp1 Diese wurde auf Backup und Slave repliziert. Anschließend habe ich die Gruppe verschoben: udm groups/group move --dn cn=gp1,"$ldap_base" \ --position cn=groups,"$ldap_base" Danach war die Gruppe auf Master und Backup einmal vorhanden, auf dem Slave hingegen doppelt: root@slave593:~# univention-ldapsearch cn=gp1 -LLL dn dn: cn=gp1,dc=deadlock59,dc=local dn: cn=gp1,cn=groups,dc=deadlock59,dc=local root@slave593:~#
Guter Punkt, im Listener selbst war der Code für die 'r' Operation nicht ganz korrekt: Der Patch für Bug 26069 hat zwar den Cache-Eintrag entfernt, aber die handler wurden zuvor mit handlers_update ausgeführt und wurden in diesem Fall als "up-to-date" erkannt (Objekt hat sich nicht geändert..). Bei der Operation 'r' sollte statt dessen handlers_delete aufgerufen werden. Die Behandlung der 'r' Operation wurde jetzt von change_update_entry direkt nach change_update_dn verschoben und wird dort jetzt als change_delete_dn umgesetzt. Mit der Anpassung wurde in meiner Testumgebung die "modrdn"-Operation korrekt über den Backup auch auf dem Slave umgesetzt. Der Slave war zuvor per ucr notifier/server auf den Backup verwiesen. Zusätzlich habe ich noch Logmeldungen in replication.py angepasst.
Funktioniert, die UUID bleibt gleich. Auch das rekursive Verschieben von cn=users war erfolgreich.
UCS 3.1-0 has been released: http://forum.univention.de/viewtopic.php?f=54&t=2125 If this error occurs again, please use "Clone This Bug".