Univention Bugzilla – Bug 26515
Rejected DNs sollten geblockt werden
Last modified: 2015-05-06 16:04:43 CEST
Derzeit kann es vorkommen, dass ein Objekt beispielsweise bei der Synchronisation von UCS nach S4 rejected wird. Der Connector synchronisiert dann das gleiche Objekt aber von S4 nach UCS.
Eine einfache Strategie wäre es, die Objekte dann auch zu rejecten. Allerdings könnte dann nicht mehr erkannt werden, welches Objekt zuerst rejected wurde und das Problem kann nicht mehr gelöst werden. Da das UCS Objekt nicht synchronisiert werden darf, wenn das AD Objekt rejected ist und umgekehrt.
Ich habe nun eine einfache Variante implementiert, die soweit funktioniert. Siehe Patch, diese müsste aber noch aufgeräumt werden. 1. Ohne diesen Patch a) UCS -> S4 - Objekt wird im UCS modifiziert - dies führt aus irgendeinem Grund beim Sync zu S4 zu einem Reject - Objekt wird im S4 modifiziert - Das Objekt wird von S4 nach UCS synchronisiert - der Reject UCS nach S4 bleibt - Sobald der Reject gelöst wird, wird die alte Version eingespielt - Irgendwann ist das ursprüngliche Problem gelöst und das Objekt wird von UCS nach S4 synchronisiert und zwar in dem Status aus dem Diff des Rejects. Die S4 Änderung wird zunächst überschrieben, aber die Änderung, die im S4 gemacht wurde kommt noch, da auch diese Änderung auch rejected wurde b) S4 -> UCS - Object wird in S4 modifiziert - dies führt aus irgendeinem Grund beim Sync zu UCS zu einem Reject - Objekt wird in UCS modifiziert - Das Objekt wird von UCS nach S4 synchronisiert und überschreibt die gemacht Änderung in S4 - der Connector prüft jetzt, ob das geänderte Objekt synchronisiert werden kann (das Objekt ist in S4 ja anders) - wenn ja, dann wird der Reject aufgelöst (UCS Variante ist gültig), wenn nein, dann bliebt dieser weiter bestehen. 2. Mit diesen Patch a) UCS -> S4 - Objekt wird im UCS modifiziert - dies führt aus irgendeinem Grund beim Sync zu S4 zu einem Reject - Objekt wird im S4 modifiziert - Das Objekt wird nicht von S4 nach UCS synchronisiert, sondern rejected (Änderung zu Variante 1) - Sobald der Reject gelöst wird, wird die alte Version von UCS nach S4 eingespielt und die Änderung, die in S4 gemacht wurde, wird überschrieben b) S4 -> UCS - Object wird in S4 modifiziert - dies führt aus irgendeinem Grund beim Sync zu UCS zu einem Reject - Objekt wird in UCS modifiziert - Das Objekt wird rejected und nicht von UCS nach S4 synchronisiert - wenn der ursprüngliche Konflikt gelöst wird, dann wird die Änderung von S4 nach UCS synchronisiert und es wird die Änderung in UCS überschrieben Zumindest in diesen Beispielen ist der Patch nicht von Vorteil, deshalb sollten wir darauf verzichten. Wir benötigen aus meiner Sicht ein paar grundlegende Änderungen um solche Konflikte besser zu lösen: Bug #18501 - Diff-basierte Synchronisation - Timestamp Beachtung
Created attachment 4486 [details] bug_26515.patch
OK.
UCS 3.0-2 has been released: http://forum.univention.de/viewtopic.php?f=54&t=1905 If this error occurs again, please use "Clone This Bug".