If a computer object is removed via UMC, remaining NS records for it's FQDN should be cleaned up because DNS server fails to load the zone if it contains NS records without an A/AAAA: Aug 8 12:30:19 ucs named[31910]: zone x-y.de/IN: NS 'opsi.x-y.de' has no address records (A or AAAA) Aug 8 12:30:19 ucs named[31910]: zone x-y.de/IN: NS 'opsi-master.x-y.de' has no address records (A or AAAA) Aug 8 12:30:19 ucs named[31910]: zone x-y.de/IN: not loaded due to errors.
Reported via Ticket#: 2013080621002132
Remaining entry's in service records should be cleaned up as well. At the moment a deleted host is only removed from some "well known" service records like _kerberos._tcp Furthermore I think that if the deleted host is the last entry for a service record, the service record should be removed too.
*** Bug 16600 has been marked as a duplicate of this bug. ***
Found again in customer environment
The whole computer←→DNS consistency is still a mess.
*** Bug 42125 has been marked as a duplicate of this bug. ***
*** Bug 41163 has been marked as a duplicate of this bug. ***
*** Bug 31926 has been marked as a duplicate of this bug. ***
*** Bug 29709 has been marked as a duplicate of this bug. ***
*** Bug 34158 has been marked as a duplicate of this bug. ***
(In reply to Alexander Kläser from comment #3) > *** Bug 16600 has been marked as a duplicate of this bug. *** * Einträge in den Service Records für Kerberos und LDAP * Shares und Share-Container * Spool-Host Einträge an Druckern * Kerberos-Service Objekt(e) unter cn=kerberos,$ldap_base (In reply to Florian Best from comment #6) > *** Bug 42125 has been marked as a duplicate of this bug. *** * When removing or renaming a computer object the MX records aren't correctly updated. (In reply to Florian Best from comment #7) > *** Bug 41163 has been marked as a duplicate of this bug. *** * The ldap principal object underneath of cn=kerberos,$ldap_base should be removed (In reply to Florian Best from comment #8) > *** Bug 31926 has been marked as a duplicate of this bug. *** * Kerberos * NS DNS records * NSCD uid cache (!) → prevents rejoining (In reply to Florian Best from comment #9) > *** Bug 29709 has been marked as a duplicate of this bug. *** * Nagios services
(In reply to Florian Best from comment #10) > *** Bug 34158 has been marked as a duplicate of this bug. *** * PKGDB-Entries
*** Bug 14853 has been marked as a duplicate of this bug. ***
(In reply to Florian Best from comment #13) > *** Bug 14853 has been marked as a duplicate of this bug. *** → Service Records _pkgdb._tcp , kerberos and ldap aren't removed
Bug #28363: if a removed computer is still referenced in the DNS SOA records, the zone transfer will fail. With dns/backend=ldap this results in broken DNS, as the proxy-bind will expire the zone after 1W.
*** Bug 9514 has been marked as a duplicate of this bug. ***
*** Bug 26310 has been marked as a duplicate of this bug. ***
Bug #45108 - Portal entries aren't cleaned up.
*** Bug 20646 has been marked as a duplicate of this bug. ***
*** Bug 26664 has been marked as a duplicate of this bug. ***
Maybe the overlay module can help: Referential Integrity (12.11. in http://www.openldap.org/doc/admin24/overlays.html).
*** Bug 50102 has been marked as a duplicate of this bug. ***
(In reply to Florian Best from comment #22) > *** Bug 50102 has been marked as a duplicate of this bug. *** DHCP object.
Led to DNS failure and thus replication between all servers.
(In reply to Christina Scheinig from comment #25) > Led to DNS failure and thus replication between all servers. The linked ticket is about a failure of Multi Factor Authentication. Can you be more specific what kind of reference object caused what problem? I propose to split this bug in individual reproducable problems as the current description is very unspecific.
Another issue is, that sometimes client users perform cleanup step in the wrong order: The only correct implementer is the UDM CLI. AppCenter: management/univention-appcenter/python/appcenter/udm.py- obj.remove() management/univention-appcenter/python/appcenter/udm.py: udm_objects.performCleanup(obj) Simple UDM API: management/univention-directory-manager-modules/modules/univention/udm/modules/generic.py- self._orig_udm_object.remove(remove_childs=remove_childs) management/univention-directory-manager-modules/modules/univention/udm/modules/generic.py- if univention.admin.objects.wantsCleanup(self._orig_udm_object): management/univention-directory-manager-modules/modules/univention/udm/modules/generic.py: univention.admin.objects.performCleanup(self._orig_udm_object) UDM REST API: management/univention-directory-manager-rest/src/univention/admin/rest/module.py- obj.remove(remove_childs=recursive) management/univention-directory-manager-rest/src/univention/admin/rest/module.py- if cleanup: # and udm_objects.wantsCleanup(obj) management/univention-directory-manager-rest/src/univention/admin/rest/module.py: udm_objects.performCleanup(obj) UMC UDM Module: management/univention-management-console-module-udm/umc/python/udm/udm_ldap.py- obj.remove(remove_childs=recursive) management/univention-management-console-module-udm/umc/python/udm/udm_ldap.py- if cleanup: management/univention-management-console-module-udm/umc/python/udm/udm_ldap.py: udm_objects.performCleanup(obj) S4C script: services/univention-samba4/scripts/purge_s4_computer.py- obj.remove() services/univention-samba4/scripts/purge_s4_computer.py- if univention.admin.objects.wantsCleanup(obj): services/univention-samba4/scripts/purge_s4_computer.py: univention.admin.objects.performCleanup(obj) UCS@school lib: ucs-school-lib/modules/ucsschool/lib/models/base.py- udm_obj.remove(remove_childs=True) ucs-school-lib/modules/ucsschool/lib/models/base.py: udm_objects.performCleanup(udm_obj) Additionally, performCleanup doesn't do any error handling but silently throws away every error: management/univention-directory-manager-modules/modules/univention/admin/objects.py:def performCleanup(object: univention.admin.handlers.simpleLdap) -> None: management/univention-directory-manager-modules/modules/univention/admin/objects.py- try: management/univention-directory-manager-modules/modules/univention/admin/objects.py- object.cleanup() management/univention-directory-manager-modules/modules/univention/admin/objects.py- except Exception: management/univention-directory-manager-modules/modules/univention/admin/objects.py- pass # TODO: add logging And cleanup() performs a open(), which is a duplicated open() then, which will fail if certain extended attributes are set: management/univention-directory-manager-modules/modules/univention/admin/handlers/__init__.py: def cleanup(self) -> None: management/univention-directory-manager-modules/modules/univention/admin/handlers/__init__.py- self.open() Triple open here: management/univention-directory-manager-modules/modules/univention/admin/handlers/computers/__base.py: def cleanup(self) -> None: management/univention-directory-manager-modules/modules/univention/admin/handlers/computers/__base.py- self.open() management/univention-directory-manager-modules/modules/univention/admin/handlers/computers/__base.py- self.nagios_cleanup() management/univention-directory-manager-modules/modules/univention/admin/handlers/computers/__base.py- univention.admin.handlers.simpleComputer.cleanup(self) and here: management/univention-directory-manager-modules/modules/univention/admin/handlers/computers/ipmanagedclient.py: def cleanup(self) -> None: management/univention-directory-manager-modules/modules/univention/admin/handlers/computers/ipmanagedclient.py- self.open() management/univention-directory-manager-modules/modules/univention/admin/handlers/computers/ipmanagedclient.py- self.nagios_cleanup() management/univention-directory-manager-modules/modules/univention/admin/handlers/computers/ipmanagedclient.py- univention.admin.handlers.simpleComputer.cleanup(self) And it is very bad, that the client must perform these steps. We should, as only computer objects use it, remove these functions and integrate it into the remove() method. 923 def remove(self, remove_childs: bool = False) -> None: should be: 923 def remove(self, remove_childs: bool = False, cleanup: bool = True) -> None:
The issue has been examined from different angles in recent days and is not a trivial one to solve. In general, the problems mentioned here can be summarized by the fact that references that point to the computer object to be deleted/moved/renamed are not "adapted". It has been found that it is often quite easy to simply delete (or of course adapt) the reference (often an FQDN) to the computer object, as long as it is not the last reference/entry to the object in question. The **removal** of the last reference often creates invalid objects. For example, an invalid zone object would be created in the NS record of DNS zones, which is no longer loaded by the DNS server. The situation is often similar for other objects. One possible solution to this problem would be to refuse to delete the computer object in the UDM if references still point to the computer object. Florian has already made considerations for UDM that could provide a generic solution for dealing with references that comes into action when deleting/renaming/moving. Properties known to be affected so far: - NS record in DNS forward/reverse zones - DNS-SRV records (including Kerberos + LDAP, but also others) - Shares objects - Share container - Spool host entries on printer objects - Kerberos service objects under cn=kerberos,$LDAPBASE - Portal entries - ... As a short-term solution, Bug#58634 implements diagnostic modules that can identify the problematic objects. (In reply to Florian Best from comment #29) > Another issue is, that sometimes client users perform cleanup step in the > wrong order: > The only correct implementer is the UDM CLI. This topic has been moved to Bug #58635.