UCS-S4-Rejects nach GPO-Änderung

Hallo,

ich hatte letztens bei einem Kunden folgendes Problem:
Er hat mittels RSAT ein paar Änderungen an GPOs gemacht. (neu verlinkt o.ä.) Danach erschien plötzlich ein S4-Reject im Monitoring:

[code]root@firmas02:~# univention-s4connector-list-rejected

UCS rejected

S4 rejected

1:    S4 DN: OU=UsersWin7,OU=Accounts,DC=firma,DC=local
     UCS DN: ou=userswin7,ou=accounts,dc=firma,dc=local

last synced USN: 270962

[/code]

Dieses LDAP-Objekt ist höchst simpel:

root@firmas02:~# univention-ldapsearch -LLL -b "ou=userswin7,ou=accounts,dc=firma,dc=local" dn: ou=UsersWin7,ou=Accounts,dc=firma,dc=local objectClass: top objectClass: organizationalUnit objectClass: univentionObject ou: UsersWin7 univentionObjectType: container/ou

Was man im Logfile sieht ist folgendes:

06.10.2016 16:29:28,994 LDAP (PROCESS): sync to ucs: Resync rejected dn: OU=UsersWin7,OU=Accounts,DC=firma,DC=local 06.10.2016 16:29:28,998 LDAP (PROCESS): sync to ucs: [ ou] [ add] ou=userswin7,ou=accounts,dc=firma,dc=local 06.10.2016 16:29:29,34 LDAP (ERROR ): Unknown Exception during sync_to_ucs 06.10.2016 16:29:29,35 LDAP (ERROR ): Traceback (most recent call last): File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1441, in sync_to_ucs result = self.add_in_ucs(property_type, object, module, position) File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1223, in add_in_ucs return ucs_object.create() and self.__modify_custom_attributes(property_type, object, ucs_object, module, position) File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 352, in create return self._create() File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 784, in _create self.lo.add(self.dn, al) File "/usr/lib/pymodules/python2.7/univention/admin/uldap.py", line 396, in add raise univention.admin.uexceptions.objectExists, dn objectExists: ou=UsersWin7,ou=accounts,dc=firma,dc=local

Meine Frage ist nun, warum wird hier versucht diese OU neu zu erstellen? Sie existiert schon, das ist auch gut so und sie muss nicht erstellt werden. Hier ist auch keine Modifikation dieses Objekts vonnöten.

Um dem Problem auf die Spur zu kommen, haben wir dann die Gruppe in UsersWin71 im Samba umbenannt. (mit RSAT)
Diese Änderung wurde im Samba sofort übernommen (Gruppe erstellt & User in die neue Gruppe verschoben) - und im LDAP wurde die Gruppe auch gesynct.
Der Reject war dann weg.
Jedoch wurden die Benutzer im LDAP nicht in die neue Gruppe verschoben.
Warum passiert das nicht? bzw. ist das normal?

Wir haben die Benutzer dann manuell in die neue Gruppe verschoben und die alte Gruppe gelöscht.
Rejects waren weiterhin keine vorhanden.

Damit war das Problem vorerst aus der Welt, jedoch hat mich diese Woche der Kunde wieder angerufen: Er hat wieder einen Reject, weil es etwas in den GPOs geändert hat.
Ich würde das gerne nachhaltig auflösen und bin für jeden Ratschlag dankbar …

Moin,

ich habe das Verhalten selber so noch nicht beobachtet — was aber natürlich nicht bedeutet, dass ich bezweifele, dass es bei Ihnen so passiert.

Im Bugtracker gibt’s zwar keinen Eintrag, der ziemlich genau auf Ihr Problem passt, aber es gibt einige Einträge, die sich mit GPOs und Rejects beschäftigen. Das scheinen jeweils Corner-Cases zu sein; ich vermute, so einen Corner-Case haben Sie auch gerade am Wickel.

[quote=“roland.gsell”]Um dem Problem auf die Spur zu kommen, haben wir dann die Gruppe in UsersWin71 im Samba umbenannt. (mit RSAT)
Diese Änderung wurde im Samba sofort übernommen (Gruppe erstellt & User in die neue Gruppe verschoben) - und im LDAP wurde die Gruppe auch gesynct.
Der Reject war dann weg.
Jedoch wurden die Benutzer im LDAP nicht in die neue Gruppe verschoben.
Warum passiert das nicht? bzw. ist das normal?[/quote]

Ich vermute stark, dass das eine Folgeerscheinung des ersten Problems ist. Daher würde ich das nicht zu hoch aufhängen. Generell funktioniert das nämlich — hab ich gerade ausprobiert: auf einem 2012 R2er Terminal Server via »Active Directory users & computers« eine Gruppe umbenannt. Die kam im LDAP mit neuem Namen und mit den richtigen Mitgliedern an. Anschließend erneut umbenannt (zurück zum alten Namen); auch diese zweite Änderung kam richtig im uCS-LDAP an.

Was für ein Reject ist das? Das gleiche Problem? Anderes Problem? Gleiche oder andere Gruppe?

Gruß,
mosu

So, endlich ein bisschen Zeit, um dieses Thema wieder aufzugreifen.

Es sieht so aus als wäre es das gleiche Problem, allerdings mit einer anderen Gruppe.
Der neue Reject sieht so aus:

14.12.2016 09:45:36,323 LDAP        (PROCESS): sync to ucs: Resync rejected dn: OU=Administration,OU=WorkstationsWin7,DC=firma,DC=local
14.12.2016 09:45:36,327 LDAP        (PROCESS): sync to ucs:   [            ou] [       add] ou=administration,ou=workstationswin7,dc=firma,dc=local
14.12.2016 09:45:36,521 LDAP        (ERROR  ): Unknown Exception during sync_to_ucs
14.12.2016 09:45:36,521 LDAP        (ERROR  ): Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1441, in sync_to_ucs
    result = self.add_in_ucs(property_type, object, module, position)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1223, in add_in_ucs
    return ucs_object.create() and self.__modify_custom_attributes(property_type, object, ucs_object, module, position)
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 352, in create
    return self._create()
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 784, in _create
    self.lo.add(self.dn, al)
  File "/usr/lib/pymodules/python2.7/univention/admin/uldap.py", line 396, in add
    raise univention.admin.uexceptions.objectExists, dn
objectExists: ou=Administration,ou=workstationswin7,dc=firma,dc=local

14.12.2016 09:46:33,24 LDAP        (PROCESS): sync to ucs: Resync rejected dn: OU=Administration,OU=WorkstationsWin7,DC=firma,DC=local
14.12.2016 09:46:33,27 LDAP        (PROCESS): sync to ucs:   [            ou] [       add] ou=administration,ou=workstationswin7,dc=firma,dc=local
14.12.2016 09:46:33,116 LDAP        (ERROR  ): Unknown Exception during sync_to_ucs
14.12.2016 09:46:33,116 LDAP        (ERROR  ): Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1441, in sync_to_ucs
    result = self.add_in_ucs(property_type, object, module, position)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1223, in add_in_ucs
    return ucs_object.create() and self.__modify_custom_attributes(property_type, object, ucs_object, module, position)
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 352, in create
    return self._create()
  File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 784, in _create
    self.lo.add(self.dn, al)
  File "/usr/lib/pymodules/python2.7/univention/admin/uldap.py", line 396, in add
    raise univention.admin.uexceptions.objectExists, dn
objectExists: ou=Administration,ou=workstationswin7,dc=firma,dc=local

Das zeigt ja nur den Zustand, in dem das Kind schon in den Brunnen gefallen ist. Können Sie Connector-Log bitte mal nach allen Vorkommnissen von »OU=Administration« suchen und diese hier posten? Das kann ja nicht das erste sein.

Ich habe hier den allerersten Eintrag zu dem Reject gefunden.
Zum Glück werden die Logs lange aufgehoben …

[code]19.10.2016 08:36:05,874 MAIN (------ ): DEBUG_INIT
19.10.2016 08:39:16,994 LDAP (PROCESS): sync to ucs: [ dns] [ modify] relativedomainname=firman6,zonename=firma.local,cn=dns,dc=firma,dc=local
19.10.2016 08:45:06,753 LDAP (PROCESS): sync to ucs: [windowscomputer] [ move] cn=FIRMAD19,ou=administration,ou=workstationswin7,dc=firma,dc=local
19.10.2016 08:45:13,779 LDAP (PROCESS): sync from ucs: [windowscomputer] [ modify] cn=firmad19,ou=administration,ou=workstationswin7,DC=firma,DC=local
19.10.2016 08:45:14,476 LDAP (PROCESS): sync from ucs: [windowscomputer] [ modify] cn=firmad19,ou=administration,ou=workstationswin7,DC=firma,DC=local
19.10.2016 08:46:06,112 MAIN (------ ): DEBUG_INIT
19.10.2016 08:47:19,278 LDAP (PROCESS): sync to ucs: [ msGPO] [ modify] cn={3ef17761-0138-458d-b7c8-4878c83b5593},cn=policies,cn=system,dc=firma,dc=local
19.10.2016 08:47:26,263 LDAP (PROCESS): sync from ucs: [ msGPO] [ modify] cn={3ef17761-0138-458d-b7c8-4878c83b5593},cn=policies,cn=system,DC=firma,DC=local
19.10.2016 08:47:28,37 LDAP (PROCESS): sync to ucs: [ msGPO] [ modify] cn={3ef17761-0138-458d-b7c8-4878c83b5593},cn=policies,cn=system,dc=firma,dc=local
19.10.2016 08:47:40,178 LDAP (PROCESS): sync to ucs: [ msGPO] [ modify] cn={3ef17761-0138-458d-b7c8-4878c83b5593},cn=policies,cn=system,dc=firma,dc=local
19.10.2016 08:47:47,130 LDAP (PROCESS): sync from ucs: [ msGPO] [ modify] cn={3ef17761-0138-458d-b7c8-4878c83b5593},cn=policies,cn=system,DC=firma,DC=local
19.10.2016 08:48:50,471 LDAP (PROCESS): sync to ucs: [ ou] [ add] ou=administration,ou=workstationswin7,dc=firma,dc=local
19.10.2016 08:48:50,508 LDAP (ERROR ): Unknown Exception during sync_to_ucs
19.10.2016 08:48:50,595 LDAP (ERROR ): Traceback (most recent call last):
File “/usr/lib/pymodules/python2.7/univention/s4connector/init.py”, line 1441, in sync_to_ucs
result = self.add_in_ucs(property_type, object, module, position)
File “/usr/lib/pymodules/python2.7/univention/s4connector/init.py”, line 1223, in add_in_ucs
return ucs_object.create() and self.__modify_custom_attributes(property_type, object, ucs_object, module, position)
File “/usr/lib/pymodules/python2.7/univention/admin/handlers/init.py”, line 352, in create
return self._create()
File “/usr/lib/pymodules/python2.7/univention/admin/handlers/init.py”, line 784, in _create
self.lo.add(self.dn, al)
File “/usr/lib/pymodules/python2.7/univention/admin/uldap.py”, line 396, in add
raise univention.admin.uexceptions.objectExists, dn
objectExists: ou=Administration,ou=workstationswin7,dc=firma,dc=local

19.10.2016 08:48:50,595 LDAP (WARNING): sync to ucs was not successfull, save rejected
19.10.2016 08:48:50,596 LDAP (WARNING): object was: OU=Administration,OU=WorkstationsWin7,DC=firma,DC=local
19.10.2016 08:49:36,709 LDAP (PROCESS): sync to ucs: Resync rejected dn: OU=Administration,OU=WorkstationsWin7,DC=firma,DC=local
19.10.2016 08:49:36,712 LDAP (PROCESS): sync to ucs: [ ou] [ add] ou=administration,ou=workstationswin7,dc=firma,dc=local
19.10.2016 08:49:36,748 LDAP (ERROR ): Unknown Exception during sync_to_ucs
19.10.2016 08:49:36,749 LDAP (ERROR ): Traceback (most recent call last):
File “/usr/lib/pymodules/python2.7/univention/s4connector/init.py”, line 1441, in sync_to_ucs
result = self.add_in_ucs(property_type, object, module, position)
File “/usr/lib/pymodules/python2.7/univention/s4connector/init.py”, line 1223, in add_in_ucs
return ucs_object.create() and self.__modify_custom_attributes(property_type, object, ucs_object, module, position)
File “/usr/lib/pymodules/python2.7/univention/admin/handlers/init.py”, line 352, in create
return self._create()
File “/usr/lib/pymodules/python2.7/univention/admin/handlers/init.py”, line 784, in _create
self.lo.add(self.dn, al)
File “/usr/lib/pymodules/python2.7/univention/admin/uldap.py”, line 396, in add
raise univention.admin.uexceptions.objectExists, dn
objectExists: ou=Administration,ou=workstationswin7,dc=firma,dc=local
[/code]

Moin Herr Gsell,

well… das sieht für mich am Ehesten nach einem Bug im Connector aus. Ich kann hier vermutlich keine weitere Hilfestellung geben. Sie sollten das mit dem Univention-Support weiter besprechen.

Gruß
mosu

Hmm, ok.
Die Version ist 4.1-1 … also schon ein bisschen älter. Vielleicht würde ein Update schon was bringen.

Updates sind immer gut :slight_smile:

1 Like

Hallo, gibt es dazu vielleicht ein update?
anscheinend ist mein Monitoring nicht up to date … ich habe ein paar rejects.
ganze 127 x S4 rejected und an die 15.000 x UCS rejected.

der erste fängt auch so an:

  File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/__init__.py", line 2205, in poll
    mapped_object = self._object_mapping(property_key, object)
  File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1762, in _object_mapping
    object = function(self, object, dn_mapping_stored, isUCSobject=(object_type == 'ucs'))
  File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py", line 308, in dns_dn_mapping
    s4connector.lo_s4.lo.search_ext_s(univention.s4connector.s4.compatible_modstring(search_dn), ldap.SCOPE_BASE, s4_RR_filter, [s4_RR_attr])[0][1][s4_RR_attr][0])
KeyError: 'dc'

wie komm ich jetzt aus dem wieder raus?

@lxc: erstellen Sie dazu bitte einen neuen Thread. Ihre Fehlermeldung ist eine ganz andere als die, die Herr Gsell gezeigt hat. Daher sind mit Sicherheit auch die Ursache und zu ergreifende Maßnahmen andere.

musste etwas suchen, das trifft eher auf mich zu: S4 connector sync issues 4.1-4
Update durchgeführt auf 4.1-4 379, dann locks wie im obigen Thread erwähnt entfernt, jetzt macht er weiter.

Mastodon