Univention Bugzilla – Bug 27272
Über Import Skript auf dem Master angelegter Rechner führt zu Traceback im S4 Connector auf dem Slave
Last modified: 2012-07-20 15:25:02 CEST
+++ This bug was initially created as a clone of Bug #27270 +++ Ich habe ein school Master nund einen Slave mit Samba4 (ou=s01). Auf dem Master wurde über import_computer ein Windows Host angelegt: windows WIN7PRO 52:52:00:f2:2a:6a s01 10.200.7.22 Daraufhin gab es auf dem Slave im Connector einen Traceback: 24.05.2012 08:49:25,571 LDAP (PROCESS): sync to ucs: Resync rejected dn: CN=win7pro,CN=computers,OU=s01,DC=ee,DC=rr 24.05.2012 08:49:25,578 LDAP (PROCESS): sync to ucs: [windowscomputer] [ modify] cn=win7pro,cn=computers,ou=s01,dc=ee,dc=rr 24.05.2012 08:49:25,630 LDAP (ERROR ): Unknown Exception during sync_to_ucs 24.05.2012 08:49:25,631 LDAP (ERROR ): Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 1299, in sync_to_ucs result = self.modify_in_ucs(property_type, object, module, position) File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 1169, in modify_in_ucs return ucs_object.modify() and self.__modify_custom_attributes(property_type, object, ucs_object, module, position) File "/usr/lib/pymodules/python2.6/univention/admin/handlers/__init__.py", line 344, in modify return self._modify(modify_childs,ignore_license=ignore_license) File "/usr/lib/pymodules/python2.6/univention/admin/handlers/__init__.py", line 866, in _modify self._ldap_post_modify() File "/usr/lib/pymodules/python2.6/univention/admin/handlers/computers/windows.py", line 548, in _ldap_post_modify univention.admin.handlers.simpleComputer._ldap_post_modify( self ) File "/usr/lib/pymodules/python2.6/univention/admin/handlers/__init__.py", line 1912, in _ldap_post_modify univention.admin.allocators.confirm( self.lo, self.position, 'mac', macAddress ) File "/usr/lib/pymodules/python2.6/univention/admin/allocators.py", line 166, in confirm univention.admin.locking.unlock(lo, position, type, value, _type2scope[type]) File "/usr/lib/pymodules/python2.6/univention/admin/locking.py", line 122, in unlock lo.delete(dn, exceptions=1) File "/usr/lib/pymodules/python2.6/univention/admin/uldap.py", line 414, in delete raise univention.admin.uexceptions.permissionDenied permissionDenied -> univention-s4connector-list-rejected UCS rejected S4 rejected 1: S4 DN: CN=win7pro,CN=computers,OU=s01,DC=ee,DC=rr UCS DN: cn=win7pro,cn=computers,ou=s01,dc=ee,dc=rr last synced USN: 3831 Wenn ich einen Rechner ohne MAC anlege, funktioniert es. In der Funktion _ldap_post_modify in der Klasse simpleComputer wird folgendes gemacht, das sieht nicht korrekt aus. if self[ 'mac' ]: for macAddress in self[ 'mac' ]: if macAddress: univention.admin.allocators.confirm( self.lo, self.position, 'mac', macAddress )
folgende Änderung in modules/univention/admin/handlers/__init__.py: * ähnlich wir für die IP Adresse wird nun auch bei der Mac Adresse vor dem univention.admin.allocators.confirm ob diese wirklich geändert wurde -> in einer Samba4 Umgebung sollten die auf dem Master angelegten Rechner in einer OU auf dessen Samba4 Slave vom Connector ordentlich synchronisiert werden ===> Sinnvoll testen kann man das wohl nur in einer UCS@School Umgebung mit Samba4 * univention.admin.allocators.confirm auf ip und mac wird nun in _ldap_post_create und _ldap_post_modify() aufgerufen -> die temp. Objekte wurden bisher nur bei der Modifikation gelöscht, nun auch beim Anlegen * für mac und ip wird nun ein univention.admin.allocators.release aufgerufen, wenn der vorherige request() eine univention.admin.uexceptions.noLock exception geworfen hat -> die temp. Objekte werden nun auch gelöscht, wenn kein LOCK geholt werden konnte (es also schon einen Rechner mit dieser ip/mac gab)
Das ursprüngliche Problem (Traceback auf dem Slave) kann mit UCS 3.0-2 nicht reproduziert werden, weil dies so nur mit UCS@school möglich ist. In diesem Bug soll deshalb geprüft werden, ob sich die Änderungen aus UCS@school in UCS 3.0-2 so auswirken, dass die Begleitumstände des Problems ordentlich bearbeitet werden. Um dies zu testen, reicht es aus, einen Master mit 3.0-1 anzulegen und dort die beschriebenen Begleitumstände der Fehler zu provozieren. In 3.0-1 werden die Fehler noch auftreten. Anschließend soll der Master auf 3.0-2 upgraded werden, um zu zeigen, dass die Probleme oder ihre Begleitumstände nun nicht mehr auftreten. Felix legt vor allem auf folgende Tests wert: - In der UMC im Module Navigation dürfen keine UDM-Objekte im LDAP unter univention/temporary/mac liegenbleiben, die sind temporär und müssen wieder verschwinden (UCS 3.0-2) - die Synchronisation zwischen Master und Slave in Samba4 kann in UCS 3.0-2 nicht getestet werden, soll aber durch code review der geänderten Teile überprüft werden - der korrekte Aufruf von univention.admin.allocators.confirm (nur bei Änderungen) soll am Quellkode überprüft werden, entscheidend ist das Abräumen temporärer Objekte - temporäre Objekte müssen im Quellkode in jedem Fall (auch wenn der Lock nicht geklappt hat, weil die IP/MAC schon existierte) wieder abgeräumt werden
Ich konnte die liegengebliebenen temporären MAC Objekte mit UCS 3.0-1 nachvollziehen. Dieses Problem trat auf UCS 3.0-1 errata update 83 nicht mehr auf. Im UMC Module Navigation bleiben also keine UDM-Objekte im LDAP unter univention/temporary/mac liegen. Nach einem code review sind die von Felix beschriebenen Änderungen in der Datei management/univention-directory-manager-modules/modules/univention/admin/handlers/__init__.py tatsächlich vorhanden. Temporäre MAC-Objekte werden nun (wie temporäre IP-Objekte bisher auch schon) nur angelegt, wenn es eine Änderung gab. Durch try .. except ist sichergestellt, dass fehlgeschlagenes Anlegen von IP und MAC Adressen zum Abräumen der temporären Objekte führt. Durch weitere Test im browser mit UCM in der UDM-Navigation konnte ich keine fehlerhaften temporären Objekte provozieren.
UCS 3.0-2 has been released: http://forum.univention.de/viewtopic.php?f=54&t=1905 If this error occurs again, please use "Clone This Bug".