Univention Bugzilla – Bug 41884
modify after remove corrupts pickle file when moving to a non readable location (part2)
Last modified: 2016-09-29 17:31:24 CEST
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.
The problem is simply reproducible in UCS@school environments with at least one slave: 1) create 2 OUs (e.g. gsmitte and gsnord) 2) create at least one user in gsmitte 3) move this user via import script from gsmitte to gsnord. 4) check connector-s4.log of school server for gsmitte (the server should have NO read access for gsnord) 26.07.2016 15:14:31,428 LDAP (ALL ): delete_in_s4: {'dn': u'cn=univention0802a,cn=schueler,cn=users,ou=gsmitte,DC=nstx,DC=local', 'attributes': {u'cn': [u'schueler-gsmitte'], u'objectClass': [u'top', u'univentionGroup', u'posixG… Please note that the dn contains the DN of a user while the attributes contain objectclasses for groups.
You've already fixed it in 4.1-2-errata. I guess the bug can be set to fixed?
Yes, sorry, I didn't hit "Save Changes". Here it is: I applied the patch for the error in the modrdn 'r' (Phase I) handling in the s4-connector.py listener module. For tests I've set up an UCS@school domain and used Advisory: univention-s4-connector.yaml
@Sönke, Arvid, excellent! :) Code review: OK YAML: OK Jenkins tests: OK Manual tests: OK I was able to reproduce the issue in my UCS@school test environment. With the updated packages, the move worked as expected.
<http://errata.software-univention.de/ucs/4.1/224.html>