Univention Bugzilla – Bug 41900
modify after remove corrupts pickle file when moving to a non readable location (part2)
Last modified: 2019-02-05 21:43:41 CET
Since the problem is reproducible in school environments, we should add a test case for it. +++ This bug was initially created as a clone of Bug #41884 +++ The fix of bug #32542 introduced a similar problem. Following scenario: Object A is moved within LDAP from position X to position Y. Afterwards object B is modified. Due to LDAP ACLs the local system has no access rights for position Y and therefore only the first of the 2 modrdn actions is passed to the handler() method. The s4-connector.py handles action "r" of object A and created a pickle file of A.dn and A.old. The following action "a" of object A is omitted due to the LDAP access rights. When object B is modified, handler() loads the pickle file and compares the entryUUID of the pickle data and the current data → the entryUUIDs differ, so the handler() method creates a new pickle file for the S4 connector that should contain a "delete" action of object A. But the s4-pickle file written contains A.dn and B.old. This causes some trouble later on in the S4 connector. The entryUUID of B will be added to the "UCS deleted" sqlite table (even if the object B has not been removed). All further changes to object B are therefore no longer synced to Samba4. (In reply to Felix Botner from Bug 32542 comment #6) > 07.10.13 09:58:17.884 LISTENER ( ERROR ) : import of > filename=/usr/lib/univention-directory-listener/system/s4-connector.py failed > File "/usr/lib/univention-directory-listener/system/s4-connector.py", line > 143 > _dump_changes_to_file_and_check_file(directory, dn, new, old, old_dn) This line should be _dump_changes_to_file_and_check_file(directory, dn, new, old_object, old_dn) +++ This bug was initially created as a clone of Bug #32542 +++ If moving a windows client from cn=computers,$ldap_base to cn=computers,cn=schoolou,$ldap_base every school slave which cannot read this schoolou creates the Group "Windows Hosts" in s4 instead. 5607 cn=windowskaputt,cn=computers,dc=schoolmulti-s4,dc=qa r 5608 cn=windowskaputt,cn=computers,ou=schule2,dc=schoolmulti-s4,dc=qa a 5609 cn=Windows Hosts,cn=groups,dc=schoolmulti-s4,dc=qa m #(normal membership update) The pickle file loads itself with 5607 as old_dn (because of the actiontype "r") - it expects the "a" action now, but never "sees" 5608 (selective replication in UCS@School). Instead it uses 5609 and the following happens in the connector: "move group from [cn=windowskaputt,cn=computers,dc=schoolmulti-s4,dc=qa] to [cn=Windows Hosts,cn=groups,dc=schoolmulti-s4,dc=qa]" The attached patch prevents this. This is totally untested for other operations and should only concrete the behaviour a bit more.
There is a Customer ID set so I set the flag "School Customer affected".
This issue has been filled against UCS@school 4.1 (R2). The maintenance with bug and security fixes for UCS@school 4.1 (R2) has ended on 5th of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3 (or later). 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.