Bug 27272 - Über Import Skript auf dem Master angelegter Rechner führt zu Traceback im S4 Connector auf dem Slave
Über Import Skript auf dem Master angelegter Rechner führt zu Traceback im S4...
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UMC - Computers
UCS 3.0
Other Linux
: P5 normal (vote)
: UCS 3.0-2
Assigned To: Felix Botner
Jürgen Kahrs
: interim-1
Depends on: 27270
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-24 10:49 CEST by Felix Botner
Modified: 2012-07-20 15:25 CEST (History)
1 user (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Botner univentionstaff 2012-05-24 10:49:36 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 )
Comment 1 Felix Botner univentionstaff 2012-05-24 14:55:51 CEST
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)
Comment 2 Jürgen Kahrs univentionstaff 2012-06-20 13:16:01 CEST
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
Comment 3 Jürgen Kahrs univentionstaff 2012-06-20 15:07:23 CEST
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.
Comment 4 Stefan Gohmann univentionstaff 2012-07-20 15:25:02 CEST
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".