Attachment 6942 Details for Bug 37259

produce_a_unresolvable_conflict_like_bug_37259.sh

produce_a_unresolvable_conflict_like_bug_37259.sh (text/plain), 2.90 KB, created by Arvid Requate on 2015-06-04 16:46 CEST

(hide)

Description:

Filename:

MIME Type:

Creator: Arvid Requate

Created: 2015-06-04 16:46 CEST

Size: 2.90 KB

patch

obsolete

>#!/bin/bash
>
>### Try to break diff mode for multi-value attributes:
>
>### Manipulate OpenLDAP values artificially in such a way, that we have a UCS to S4 changeset that would make S4-Connector want to create
>### a multivalue in Samba4. For this the old OpenLDAP value must differ from the current Samba4 value.
>### Let's create this situation by temporarily stopping the connector and changing the values on both sides to differing values.
>### Then we start the connector again.
>### In case the change gets rejected, e.g. when a Samba4 single-valued attribute is not declared as such in the S4-Connector mapping,
>### the current Samba4 value will non the less synchronized back to OpenLDAP.
>### In that situation OpenLDAP and and Samba4 will be in sync but the pickled "UCS rejected" changeset contains an obsolete modification:
>###
>###      (pickled "old" value)  != (current Samba4 value)    AND  (pickled "new" value) != (current Samba4 value)
>### AND  (current Samba4 value) == (current OpenLDAP value)  AND  (pickled "new" value) != (current OpenLDAP value)
>###
>### In case the reason for the reject gets fixed at some point (e.g. by an errata update), this obsolete modification would roll-back the current Samba4 value.
>###
>### Additionally in this advanced setup we also avoid the current Samba4 value to flow back to OpenLDAP, so we have
>###
>###      (pickled "old" value)  != (current Samba4 value)    AND  (pickled "new" value) != (current Samba4 value)
>### AND  (current Samba4 value) != (current OpenLDAP value)
>###
>### This is a conflict we cannot and must not attempt to resolve automatically.
>###
>### We can fake this setup by temporarily running the connector in "write"-only uni-directional mode:
>
>/etc/init.d/univention-s4-connector stop
>
>ucs_gpo_ldif=$(univention-ldapsearch -xLLL '(&(objectclass=msGPOContainer)(cn={31B2F340-016D-11D2-945F-00C04FB984F9}))' | ldapsearch-wrapper | ldapsearch-decode64)
>ucs_gpo_dn=$(sed -n 's/^dn: //p' <<<"$ucs_gpo_ldif")
>old_version=$(sed -n 's/^msGPOVersionNumber: //p' <<<"$ucs_gpo_ldif")
>
>new_version=$(($old_version + 1))
>udm container/msgpo modify --dn "$ucs_gpo_dn" \
>	--set msGPOVersionNumber="$new_version"
>
>
>## Now the evil part: We also modify the S4-Object, but to a different value:
>
>new_version=$(($new_version + 1))
>s4_gpo_dn=$(univention-s4search '(&(objectClass=groupPolicyContainer)(cn={31B2F340-016D-11D2-945F-00C04FB984F9}))' dn | ldapsearch-wrapper | ldapsearch-decode64 | sed -n 's/^dn: //p')
>
>ldbmodify -H /var/lib/samba/private/sam.ldb <<%EOF
>dn: $s4_gpo_dn
>changetype: modify
>replace: versionNumber
>versionNumber: $new_version
>%EOF
>
>### Now temporarily sync in one direction only to avoid the Samba4 value flowing back to OpenLDAP:
>ucr set connector/s4/mapping/syncmode=write
>/etc/init.d/univention-s4-connector start
>
>sleep 3
>
>### And put in back into sync mode:
>ucr set connector/s4/mapping/syncmode=sync
>/etc/init.d/univention-s4-connector restart
>univention-s4connector-list-rejected

Actions: View

Attachments on bug 37259: 6864 | 6865 | 6866 | 6867 | 6941 | 6942