Univention Bugzilla – Bug 38450
S4-Connector could check if a rejected changeset is obsolete (and futile)
Last modified: 2020-05-19 14:48:03 CEST
Maybe we can learn a general point for the S4-Connector from Bug #37259: When treating rejects, the S4-Connector (c|sh)ould check if "old" attribute values are still valid in the source directory. If not, then the those attributes may be ignored in the change set. This would avoid cases where the reason for a reject is resolved by a software update but the reject is so old, that it's application results in a roll-back of Changes in the target directory. This idea needs thorough evaluation though. Applying only parts of change sets could possibly result in strange results. And then there is the object caching and diffing logic layer in the S4-Connector... Maybe this would cause more harm than benefit.
Created attachment 6884 [details] skip_attribute_modification_if_current_value_in_sync.patch Patch proposal which fixes the issue of Bug #37259
Created attachment 6885 [details] reproduce_problem_of_bug_37259.sh The attached script can be used to reproduce the problem of Bug #37259.
Created attachment 6886 [details] always_use_current_ldap_values_for_modify.patch This is an alternative, more radical solution: If during sync_from_ucs the connector finds from looking at "old" and "new" that an OpenLDAP object has been modified, it tries to fetch the latest object from OpenLDAP. If the object still can be found under the original DN, then the S4-Connector ignores the "new" object values and uses those "latest" values instead. This way, the S4-Connector would work a bit more like the replication.py listener (only in the modifcation case). Note: When checking with the reproducer script: The reject only disappears after a "resync" (50 sec.), because the latest S4-value has to be synced back to UCS first, before either of the two proposed patches can sort things out.
As far as I can see, this doesn't collide with the "diff mode" changes of Bug 33621. We will only know this if we run ucs-test against a patched version.
After reading Bug 26515 Comment 2 (Case 1.a) again, I played through if the situation in Bug #37259 might actually be "self healing", but I think it's not. This is my reasoning: 0. Initial Situation: OpenLDAP Samba val=1 val=1 1. Manual change in OpenLDAP, S4-Connector traceback (Situation of Bug #37259) OpenLDAP Samba val=2 val=1 sync_from_ucs queue: #1: reject: old: val=1 new: val=2 2. Now assume e.g. two independent manual changes happening in Samba OpenLDAP Samba val=2 val=4 sync_from_ucs queue: #1: reject: old: val=1 new: val=2 3. S4-Connector synchronizes this change to UCS: OpenLDAP Samba val=4 val=4 sync_from_ucs queue: #1: reject: old: val=1 new: val=2 4. s4-connector.py listener records this change for sync to S4: OpenLDAP Samba val=4 val=4 sync_from_ucs queue: #1: reject: old: val=1 new: val=2 #2: old: val=2 new: val=4 5. S4-Connector sync_from_ucs still rejects change #1 but #2 appears trivial (value to remove is not present anyway, value to add is already present), so it "applies" it. OpenLDAP Samba val=4 val=4 sync_from_ucs queue: #1: reject: old: val=1 new: val=2 So the "self healing" changeset is removed from the change queue. 6. If an errata-Update gets installed now in this situation which fixes the cause of the reject by marking the attribute single valued, then this futile change happens: OpenLDAP Samba val=4 val=2 In the next round of sync_from_s4, the OpenLDAP value will get overwritten by val=2 as well, so finally we have a roll-back.
This issue has been filled against UCS 4.0. The maintenance with bug and security fixes for UCS 4.0 has ended on 31st of May 2016. Customers still on UCS 4.0 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.