udm computers/domaincontroller_slave modify --dn "cn=${HOST1},cn=computers,$ldap_base" --set name="$HOST2" Traceback (most recent call last): File "/usr/share/univention-directory-manager-tools/univention-cli-server", line 233, in doit output = univention.admincli.admin.doit(arglist) File "/usr/lib/python2.4/site-packages/univention/admincli/admin.py", line 916, in doit dn=object.modify() File "/usr/lib/python2.4/site-packages/univention/admin/handlers/__init__.py", line 318, in modify return self._modify(modify_childs,ignore_license=ignore_license) File "/usr/lib/python2.4/site-packages/univention/admin/handlers/__init__.py", line 802, in _modify self._ldap_post_modify() File "/usr/lib/python2.4/site-packages/univention/admin/handlers/computers/domaincontroller_slave.py", line 582, in _ldap_post_modify univention.admin.handlers.simpleComputer._ldap_post_modify( self ) File "/usr/lib/python2.4/site-packages/univention/admin/handlers/__init__.py", line 1717, in _ldap_post_modify self.__rename_dhcp_object( position = None, old_name = self.__changes[ 'name' ][ 0 ], new_name = self.__changes[ 'name' ][ 1 ] ) File "/usr/lib/python2.4/site-packages/univention/admin/handlers/__init__.py", line 1275, in __rename_dhcp_object object = univention.admin.objects.get( univention.admin.modules.get( 'dhcp/host' ), self.co, self.lo, position = self.position, dn = result ) File "/usr/lib/python2.4/site-packages/univention/admin/objects.py", line 69, in get return module.object(co, lo, position, dn, arg=arg, superordinate=superordinate) File "/usr/lib/python2.4/site-packages/univention/admin/handlers/dhcp/host.py", line 133, in __init__ raise univention.admin.uexceptions.insufficientInformation, 'superordinate object not present' insufficientInformation: superordinate object not present
Der Fehler tritt mit 2.4-1 und 2.4-2 sowohl im CLI als auch WebUDM auf. Getestet wurde bisher nur mit einem DC Slave. Vorgehensweise im WebUDM: 1) Rechner → Hinzufügen → Domaincontroller slave → Name=slave2 → Speichern 2) Rechner → Suchen → Slave2 öffnen 3) Name=slave3 → Speichern ==> Fehlermeldung
Nach dem Fix sollte hier unbedingt nochmal geprüft werden, ob der umbenannte Rechner aus als memberuid und uniqueMember an seiner primären Gruppen gesetzt ist (siehe auch Bug #21711)!!!!!!!!!
Die Memberattribute self['mac'], self[ 'dnsEntryZoneForward' ], self[ 'dnsEntryZoneReverse' ] und self[ 'dnsEntryZoneAlias' ] können aus einer Liste mit leeren Zeichenketten bestehen. Leere Zeichenketten werden jetzt übersprungen. Weiterhin war noch ein Typo vorhanden: "dnsentryzonealias" vs. "dnsEntryZoneAlias" @QA: Am besten zusammen mit Bug 21882 durchtesten. Bei der QA sollten mehrere Fälle durchgespielt werden: - mit allen Systemrollen testen - pro Systemrolle ein Rechnerobjekt ohne DNS-Einträge und ohne DHCP-Eintrag - pro Systemrolle ein Rechnerobjekt mit DNS-Einträgen und mit DHCP-Eintrag eval "$(ucr shell)" udm groups/group create --position cn=groups,$ldap_base \ --set name=grp1 udm computers/domaincontroller_slave create \ --position "cn=computers,$ldap_base" \ --set name="testslave1" udm groups/group modify \ --dn "cn=grp1,cn=groups,$ldap_base" \ --set name=grp1 \ --append hosts=cn=testslave1,cn=computers,$ldap_base udm computers/domaincontroller_slave modify \ --dn "cn=testslave1,cn=computers,$ldap_base" \ --set name="neuername1"
Im Zuge von Bug #21882 mitgetestet. Das Umbenennen von Rechnerobjekten funktioniert (cli, web). Changelog Eintrag vorhanden.
UCS 2.4-3 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".