Bug 26515
| Summary: | Rejected DNs sollten geblockt werden | ||
|---|---|---|---|
| Product: | UCS | Reporter: | Stefan Gohmann <gohmann> |
| Component: | S4 Connector | Assignee: | Stefan Gohmann <gohmann> |
| Status: | CLOSED WONTFIX | QA Contact: | Arvid Requate <requate> |
| Severity: | normal | ||
| Priority: | P5 | Keywords: | interim-2 |
| Version: | UCS 3.0 | ||
| Target Milestone: | UCS 3.0-2 | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| See Also: | https://forge.univention.org/bugzilla/show_bug.cgi?id=38450 | ||
| 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: | bug_26515.patch | ||
|
Description
Stefan Gohmann
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". |