Univention Bugzilla – Bug 23338
Unvollständiges Cleanup nach Fehler bei Rechneranlegen
Last modified: 2018-04-13 13:29:03 CEST
Wird versucht, über den WebUDM ein DC-Slave-Objekt anzulegen, bei dem Forward- und Reverse-DNS-Eintrag angegeben werden, wobei IP-Adresse und Reverse-Zone nicht zueinander passen, wird eine entsprechende Fehlermeldung ausgegeben. Anschließend ist es nicht mehr möglich, das Rechnerobjekt mit diesem Namen anzulegen. In der Gruppe "DC Slave Hosts" ist der neue Rechner als "memberUid" eingetragen, aber nicht als uniqueMember. Beim erneuten Versuch, den Rechner hinzuzufügen (mit korrektem Reverse-DNS-Eintrag), schlägt dies mit einem "Value Exists"-LDAP-Fehler fehl. Das Hinzufügen funktionierte erst, nachdem der fehlerhafte memberUid-Eintrag an der Gruppe per ldapmodify entfernt wurde. Die cleanup()-Funktion sollte hier besser aufräumen. Weiterhin wurde festgestellt, dass der Forward-DNS-Eintrag schon beim ersten Versuch angelegt und nach dem ersten Fehler nicht wieder entfernt wurde: dn: relativeDomainName=foobar,zoneName=univention.qa,cn=dns,dc=univention,dc=qa objectClass: top objectClass: dNSZone aRecord: 10.200.15.61 relativeDomainName: foobar zoneName: univention.qa
Aufgetreten mit 2.4-3. Konnte mit UCS 2.4-2 (auf demo.univeniton.de) ebenfalls nachgestellt werden.
Lässt sich reproduzieren indem man "1.2.3.4" als IP-Adresse einträgt, und dann einen DNS-Reverse-Eintrag aus einem anderen Subnetz (z.B. 10.200.12.0/24) hinzufügt. Fehler identisch bei DCBackup, DCSlave, Member, Managed, Mobile, und Windows Tritt nicht auf bei IPManagedClient und Thinclient. Schein in abgewandelter Form für MacOS-Client aufzutreten? In domaincontroller_slave.py→object→_ldap_post_remove wird der Rechner wieder aus der Gruppe entfernt. Daher die Vermutung, dass es sich um einen Fehler in groups/group.py handelt.
Problem verfolgt: Da der Create-Vorgang im _ldap_post_create abbricht (Exception) wird self.cancel() und dann self.remove() aufgerufen. In dem self.remove() wird dann das Rechnerobjekt gelöscht. _Danach_ wird das self._ldap_post_remove() aufgerufen, wo die Gruppenmitgliedschaft entfernt wird. Beim Entfernen der Gruppenmitgliedschaft wird beim Zusammenbau der Modlist der Gruppe (_ldap_modlist) mit der Funktion getUidList versucht aus den DNs die entsprechende UID zu generieren. Da das Objekt jedoch bereits gelöscht ist, ist dies nicht möglich. Eine mögliche Lösung wäre das Entfernen der Gruppenmitgliedschaften in das _ldap_pre_remove zu bewegen.
Im simpleComputer im _ldap_post_remove wird die Gruppenmitgliedschaft _auch_ entfernt. Vermutlich daher funktioniert das "normale" Löschen eines Rechners. Eventuell sollte die Gruppe eine Exception werfen, wenn die memberUid nicht entfernt werden konnte, weil sonst die Gruppe im LDAP inkonsistent wird/ist.
Der Bug tritt mit UCS 3.1 noch auf (Import eines UCC mit nicht zur DNS-Zone passender IP hinterlässt memberUID-Einträge in der Gruppe Computers)
Workaround: das Skript /usr/share/univention-directory-manager-tools/proof_uniqueMembers entfernt die falschen Einträge an der Gruppe.
Ticket#: 2013052421000972 ] UCS Technikschulung erneut aufgetreten während der Schulung, weil die eigegebene IP-Adresse nicht in ausgewählte Reverse-DNS-Zone passte. Dadurch trat ein Fehler auf, so daß das Object nicht angelegt werden konnte; in der Gruppe "Windows Hosts" war aber schon die memberUid eingetrage, so daß nach der Korrektur der Hosts immer noch nicht angelegt werden konnte. Im Rahmen der Schulung musste ich mit mit einem "ldapmodify" helfen ...
This still is an issue with UCS-3.2: After adding a windows host where the IP address didn't match the reverse DNS zone: 1. he DNS entry had to be removed by hand. 2. the Windows Computers groups was inconsistent and had to be fixed by calling /usr/share/univention-directory-manager-tools/proof_uniqueMembers by hand.
Still broken with UCS-4
*** This bug has been marked as a duplicate of bug 41711 ***