Univention Bugzilla – Bug 41711
Fix UDM locking/unlocking
Last modified: 2024-01-07 23:16:04 CET
UDM locking and unlocking of specific attributes follow the same structure everywhere. But the implementation is broken in very much situations. The structure is: Ask to lock attribute when creating, or raise AlreadyUsed if lock exists. Confirm lock after successful creation. Revert(Release) locks if creation failed. Ask to lock attribute when modifying (the attribute), or raise AlreadyUsed if lock exists. Confirm lock of the previous old value if the modification was successful. Confirm lock after successful modification. Revert(Release) locks if modification failed. Release (value) lock when removing a object was successful. This must work when using the same UDM object for all operations and if all operations are done with a new object. E.g: o = object() o[uid] = 1; o.create(); o[uid] = 2; o.modify() o.delete() o[uid] = 1; o.create() A generic implementation should handle this. My idea is to add an flag 'requires_lock' to the property()-description.
Created attachment 7779 [details] patch (needs rebase with svn r74405) The patch makes the above things generic. TODO: implement the idea with the generic property flag TODO: also cleanup a little bit more the releasing of changed values in _ldap_modlist The patch fixes Bug #41294 and Bug #31414.
*** Bug 31414 has been marked as a duplicate of this bug. ***
*** Bug 41294 has been marked as a duplicate of this bug. ***
*** Bug 23338 has been marked as a duplicate of this bug. ***
*** Bug 14798 has been marked as a duplicate of this bug. ***
At Ticket #2016081821000428 a partner reported a similar problem as described at Bug #23338.
I observed a similar issue during one of my talks: -------- 8< ---------- root@ucs:~# last_id=$(cat /var/lib/univention-ldap/last_id) root@ucs:~# udm computers/linux create \ --position "cn=computers,$ldap_base" \ --set name=mylinux \ --set mac=52:54:00:9b:e5:01 \ --set network="cn=default,cn=networks,$ldap_base" Object created: cn=mylinux,cn=computers,dc=univention-gmbh,dc=intranet root@ucs:~# sed -n "/^$((last_id+1))/,\$ p" \ /var/lib/univention-ldap/notify/transaction 956 cn=default,cn=networks,dc=univention-gmbh,dc=int... m 957 cn=10.200.26.3,cn=aRecord,cn=temporary,cn=univen... a 958 cn=2006,cn=uidNumber,cn=temporary,cn=univention,... a 959 cn=2006,cn=gidNumber,cn=temporary,cn=univention,... a 960 cn=2006,cn=gidNumber,cn=temporary,cn=univention,... d 961 cn=S-1-5-21-2047279768-839456739-1946195436-5012,\ cn=sid,cn=temporary,cn=univention,dc=univention-... a 962 cn=52:54:00:9b:e5:01,cn=mac,cn=temporary,cn=univ... a 963 cn=uidNumber,cn=temporary,cn=univention,dc=unive... m 964 cn=2006,cn=uidNumber,cn=temporary,cn=univention,... d 965 cn=mylinux$,cn=uid,cn=temporary,cn=univention,d.... a 966 cn=mylinux,cn=computers,dc=univention-gmbh,dc=in... a 967 cn=mylinux$,cn=uid,cn=temporary,cn=univention,dc... d 968 cn=mylinux,cn=computers,dc=univention-gmbh,dc=in... m 969 cn=mylinux,cn=computers,dc=univention-gmbh,dc=in... m 970 cn=Computers,cn=groups,dc=univention-gmbh,dc=int... m 971 relativeDomainName=mylinux,zoneName=univention-gmbh.\ intranet,cn=dns,dc=univention-gmbh,dc=intranet m 972 relativeDomainName=3,zoneName=26.200.10.in-addr.arpa,\ cn=dns,dc=univention-gmbh,dc=intranet a 973 zoneName=26.200.10.in-addr.arpa,cn=dns,dc=univen... m 974 cn=10.200.26.3,cn=aRecord,cn=temporary,cn=univen... d 975 cn=52:54:00:9b:e5:01,cn=mac,cn=temporary,cn=univ... d -------- 8< ---------- My observations are: * The removal of temporary should be taken place after the creation of the UDM objects * There is one temporary object which is not deleted
*** Bug 42150 has been marked as a duplicate of this bug. ***
*** Bug 42444 has been marked as a duplicate of this bug. ***
*** Bug 7337 has been marked as a duplicate of this bug. ***
*** Bug 18339 has been marked as a duplicate of this bug. ***
*** Bug 20631 has been marked as a duplicate of this bug. ***
*** Bug 26221 has been marked as a duplicate of this bug. ***
*** Bug 23868 has been marked as a duplicate of this bug. ***
*** Bug 31416 has been marked as a duplicate of this bug. ***
Again reported at Ticket #2017010321002241.
*** Bug 12125 has been marked as a duplicate of this bug. ***
Hi, Is this totally harmless bug or should one clean up those locks manually? or simply let them there and wait for an errata? For example, what will happen if one hast to re-join windows clients? We are also having a growing amount of locks in LDAP (Ticket#2017042421000191), after a migration from Samba3+LDAP to UCS 4.1-current. It's a bit more like in comment 7 (or Bug 31414)
*** Bug 29684 has been marked as a duplicate of this bug. ***
*** Bug 28632 has been marked as a duplicate of this bug. ***
*** Bug 35834 has been marked as a duplicate of this bug. ***
Task #6732 UCS Technical Training Tried to create user with wrong email domain Creation was denied. Seconds attempt failed because of remaining lock objects for UID(?) Third attempt succeeded.
Reported again: """ Randfehler: Wenn wir obigen Befehl wiederholen kommen zwei andere Fehlermeldungen: E: Object exists: (uid) : jsecord The mail address is already in use. bis wir nach dem dritten Aufruf wieder zur ersten kommen. Auch hier würden wir erwarten, dass die Fehlermeldungen konsistent sind. """
Noticed again in UCS@school environments: when creating a user, the lock object for the SID is not being removed after successful creation → lots of lock objects are piling up and making e.g. the UCS join slow
(In reply to Florian Best from comment #1) > Created attachment 7779 [details] > patch > (needs rebase with svn r74405) We should discuss this patch, before applying it.
With UCS 4.3-2 errata305 this is still the case, customer reported the daily creation of new tempory
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 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.
Created attachment 10017 [details] patch (git:fbest/41711-fix-udm-locking) Updated and enhanced the patch for UCS 4.4. Still only some small TODO's.
*** Bug 50891 has been marked as a duplicate of this bug. ***
need issue needs attention customer 57195: 127k user objects 128k remnants in cn=sid,cn=temporary, first entry dated March 2020 increasing
Still an issue with UCS 5.0-0. Those temporary entries also clutter the translog database: Bug #48626
The content of attachment 10017 [details] has been deleted
The content of attachment 7779 [details] has been deleted
Another customer affected 2023120621000198 UCS: 5.0-5 errata907