Bug 26571 - S4 connector: endloser Sync zw. S4 und UCS
S4 connector: endloser Sync zw. S4 und UCS
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: S4 Connector
UCS 3.0
Other Linux
: P5 normal (vote)
: UCS 3.0-1-errata
Assigned To: Stefan Gohmann
Arvid Requate
:
Depends on: 25921 26466
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-21 20:22 CET by Stefan Gohmann
Modified: 2012-11-09 16:19 CET (History)
4 users (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 Stefan Gohmann univentionstaff 2012-03-21 20:22:01 CET
Das ist in einem Testsetup bei mir nochmal aufgetreten. Für UCS@school wurde das bereits verifiziert. Es sollte ein errata-Update für den Connector veröffentlicht werden.

+++ This bug was initially created as a clone of Bug #26466 +++

+++ This bug was initially created as a clone of Bug #25921 +++

Created an attachment (id=4110)
connector.log 

Auf meinem UCS 3.0 (ucs-school) Master mit Samba4 habe ich gerade einen
Zustand, wo der S4 Connector ständig Änderungen an Rechnerobjekten in einzelnen
Schul-OU vornimmt. 

sync to ucs:   ...  modify] cn=dca3v-01,cn=dc...
sync to ucs:   ...  modify] cn=dca1-01,cn=dc,...
sync to ucs:   ...  modify] cn=dca1v-01,cn=dc...
sync from ucs: ...  modify] cn=dca3-01,cn=dc,...
sync from ucs: ...  modify] cn=dca4-01,cn=dc,...
sync from ucs: ...  modify] cn=dca8v-01,cn=dc...
sync to ucs:   ...  modify] cn=dca3-01,cn=dc,...
sync to ucs:   ...  modify] cn=dca4-01,cn=dc,...
sync to ucs:   ...  modify] cn=dca8v-01,cn=dc...
sync from ucs: ...  modify] cn=dca3-01,cn=dc,...
sync from ucs: ...  modify] cn=dca4-01,cn=dc,...
sync from ucs: ...  modify] cn=dca8v-01,cn=dc...
sync from ucs: ...  modify] cn=dca1v-01,cn=dc...
sync to ucs:   ...  modify] cn=dca3-01,cn=dc,...
sync to ucs:   ...  modify] cn=dca4-01,cn=dc,...
sync to ucs:   ...  modify] cn=dca8v-01,cn=dc...
sync to ucs:   ...  modify] cn=dca1v-01,cn=dc...
sync from ucs: ...  modify] cn=dca3-01,cn=dc,...
sync from ucs: ...  modify] cn=dca4-01,cn=dc,...
sync from ucs: ...  modify] cn=dca1v-01,cn=dc...
sync to ucs:   ...  modify] cn=dca3-01,cn=dc,...
sync to ucs:   ...  modify] cn=dca8v-01,cn=dc...
sync to ucs:   ...  modify] cn=dca7v-01,cn=dc...

Das führt dann unter anderen dazu, dass das Listener Modul gencertificate.py
ständig die Berechtigungen für die Zertifikatsverzeichnisse der Rechner setzt.

Aufgetreten ist das Problem heute nachdem eine Vielzahl von Schul-OUs angelegt
bzw. gelöscht wurden. Also etwas in der Art:

-> /usr/share/ucs-school-import/scripts/import_user /opt/users.txt
-> /usr/share/ucs-school-import/scripts/import_networks /opt/network.txt
-> /usr/share/ucs-school-import/scripts/create_ou a1
-> /usr/share/ucs-school-import/scripts/create_ou a2
-> /usr/share/ucs-school-import/scripts/create_ou a3
-> /usr/share/ucs-school-import/scripts/create_ou a4
-> /usr/share/ucs-school-import/scripts/create_ou a5
-> udm container/ou remove --db ou=a5,dc=school,dc=test
-> udm container/ou remove --dn ou=a5,dc=school,dc=test
-> /usr/share/ucs-school-import/scripts/create_ou a5
-> udm container/ou remove --dn ou=a5,dc=school,dc=test
-> /usr/share/ucs-school-import/scripts/create_ou a5
-> /usr/share/ucs-school-import/scripts/create_ou a6
-> udm container/ou remove --dn ou=a5,dc=school,dc=test
-> /usr/share/ucs-school-import/scripts/create_ou a7
-> udm container/ou remove --dn ou=a5,dc=school,dc=test
-> udm container/ou remove --dn ou=a2,dc=school,dc=test
-> /usr/share/ucs-school-import/scripts/create_ou a5
-> udm container/ou remove --dn ou=a2,dc=school,dc=test
-> udm container/ou remove --dn ou=a5,dc=school,dc=test
-> /usr/share/ucs-school-import/scripts/create_ou a5
-> udm container/ou remove --dn ou=a5,dc=school,dc=test
-> /usr/share/ucs-school-import/scripts/create_ou a5
-> udm container/ou remove --dn ou=a5,dc=school,dc=test

Dann habe ich den connector irgendwann gestoppt und die interal.cfg gelöscht.
Nach dem Start des Connectors hat er erst einmal wieder angefangen alle Objekte
zu synchronisieren, irgendwann hing er dann aber in dieser Schleife. Gestern
hatte ich das Problem auch schon einmal bemerkt. Da hatte ich aber nur ou's
etc. über die ucs-school Importskript angelegt bzw über den UMC UDM gelöscht,
die interal.cfg hatte ich nicht angefasst.

Im Anhang ist das connector log file (debug/level=4) und auf utby liegt die VM
fbotner_3.0-10 mit einem Snapshot s4-sync als das Problem auftrat (den listener
habe ich vor dem Snapshot gestoppt).
Comment 1 Stefan Gohmann univentionstaff 2012-03-22 07:21:08 CET
Paket ist gebaut und YAML Datei ist ebenfalls erstellt.

Das Update wird auf einem 3.0-0 System zurückgehalten. Das ist gut, da sehr viele Änderungen in dem 3.0-1 S4 Connector waren.
Comment 2 Arvid Requate univentionstaff 2012-03-22 12:48:58 CET
Verified:
 * Der Patch für Bug #26466 ist als 6.0.111-1-errata3.0-1/10_Bug_26571.patch extrahiert und wurde beim Paketbau erfolgreich angewendet
 * Installation unter ucs3.0-1 OK
 * Blockierung unter ucs3.0-0 OK durch Abhängigkeit auf python-univention-directory-manager (>=7.0.214).
 * Advisory OK
Comment 3 Janek Walkenhorst univentionstaff 2012-11-09 16:19:45 CET
http://errata.univention.de/errata40.html