# # Environment # UCS: 5.0-10 errata1224 Installed: prometheus-node-exporter=2.0.1 samba4=4.16 self-service=5.0 self-service-backend=5.0 ucsschool=5.0 v6 # # Summary # Deleting computer objects in UCS takes significantly longer when the user executing the deletion has many group memberships. The delay occurs during the cleanup of DNS host records in /usr/lib/python3/dist-packages/univention/admin/handlers/__init__.py. # # Steps to Reproduce # - Use a UCS user with few group memberships to delete a computer and its referring objects. - Use a UCS user with many group memberships to delete a computer and its referring objects. - Compare execution times, particularly in the cleanup of DNS host records. # # Observed Behavior # The deletion process takes significantly longer when executed by a user with many group memberships. Debugging output indicates that most of the delay happens during the lookup() or open() calls in the following code: start = time.time() for irecord in univention.admin.modules.lookup('dns/host_record', self.co, self.lo, base=self.lo.base, scope='sub', superordinate=zoneObj): irecord.open() new_entries = list(set(irecord['a']) - ips) if len(new_entries) != len(irecord['a']): log.debug('Entry found in "%s":\n%s ==> %s', irecord.dn, irecord['a'], new_entries) irecord['a'] = new_entries irecord.modify() end = time.time() duration = end - start log.debug('clean up host records %.4f Sekunden', duration) Log output shows a significant delay: 25.03.25 15:52:25.340 ADMIN ( ALL ) : __init__.cleanup:3450: clean up host records 11.4635 Sekunden No debug message "Entry found in ..." appeared in management-console-module-udm.log, indicating that the code never entered the if block containing irecord.modify(). This strongly suggests that the slowdown is caused by univention.admin.modules.lookup() or irecord.open(), likely due to extensive LDAP permission checks related to group memberships.
Further debugging showed that the number of group memberships is not essential to the cause: Another test with a dedicated admin account with only 4 groups also showed similar slow results. This still indicates a problem with LDAP permission checks, but not primarily related to the number of group memberships.
The behavior was introduced in Bug #26400 git:93ae62a30c3c3d720b6f8dff264f80c008553eca and looks like unnecessary duplicated logic of what is done already a few lines before. We also verified this in the customer environment that the host records for that zone are already removed during that performance problem. Nevertheless we can simply add a LDAP filter which speeds up the search drastically, if there are 12014 host records in that zone.
While we could clean up a lot here, we make a simple fix, which only adds a correct LDAP filter to the dns/host_record search which reduced the time from 12 seconds to under 1 second in the customer environment. univention-directory-manager-modules.yaml 35d6ae98b7e9 | perf(udm): fix performance of computer removal univention-directory-manager-modules (17.0.31) 35d6ae98b7e9 | perf(udm): fix performance of computer removal
errata-yaml ok debian paket ok problem reproduced ok problem fixed ok code-review ok
<https://errata.software-univention.de/#/?erratum=5.2x56>