Univention Bugzilla – Bug 25709
Performance Gruppensynchronisation
Last modified: 2018-08-23 12:06:01 CEST
Die Performance des S4 Connectors lässt deutlich nach, wenn es sehr viele Gruppen mit sehr vielen Mitgliedern gibt. Testumgebung mit 5000 Benutzern und 1000 Gruppen, wobei in mehr als 10 Gruppen mehr als 4000 Mitglieder sind. Das Anlegen eines Benutzers kann bis zu 40 Sekunden dauern, wenn dieser in den 10 betroffenen Gruppen ist.
Aktuell wird bei der Benutzersynchronisation im S4 geprüft, in welchen Gruppen (memberOf) der Benutzer ist. Anschließend werden die Gruppen normal über den Connector neu synchronisiert. Es ist dann so, dass bei dieser normalen Gruppensynchronisation alle Mitglieder überprüft werden. Das ist aber unnötig, da lediglich überprüft werden muss, ob der modifizierte Benutzer korrekt in der Gruppe ist. Dabei muss berücksichtigt werden, dass der Benutzer ggf. umbenannt oder verschoben wurde.
(In reply to comment #1) > Das ist aber unnötig, da lediglich überprüft werden muss, ob der modifizierte > Benutzer korrekt in der Gruppe ist. Dabei muss berücksichtigt werden, dass der > Benutzer ggf. umbenannt oder verschoben wurde. Dennoch bringt das in großen Umgebungen nicht viel. Aufwendig ist es, dass bei der Änderung einer Gruppe jedes Gruppenmitglied geprüft wird. Wenn beispielsweise ein Benutzer in 10 Gruppen mit je 4000 Benutzern hinzugefügt wird, so werden 40000 LDAP Abfragen (pro Synchronisationsrichtung) gestellt. Es sollte für die Gruppensynchronisation ein Diff-Modus implementiert werden. Dazu müssen im Speicher (oder auf der Festplatte) die aktuellen Gruppenmitglieder gespeichert werden. Wenn eine Gruppe geändert wird, so sollte nur der Diff betrachtet werden. Alle anderen Mitglieder sollten ignoriert werden.
Es ist jetzt soweit umgesetzt, dass ein interner Cache im Connector aufgebaut wird. Aktuell schlagen noch diese beiden Tests fehl: Verify user-group-membership synchronisation after changes from ad-s ide in read mode Test failed Verify user-group-membership synchronisation after changes from ad-s ide in sync mode Test failed
Es wurden unterschiedliche Anpassungen durchgeführt: - DN Caching (S4 DN <-> UCS DN) - Gruppenmitglieder Caching (das verhindert, dass ein Mitglied gelöscht wird, welches auf der anderen Seite gerade hinzugefügt wird) - Beim Ändern eines Benutzers wird nur dessen Gruppenmitgliedschaft aktualisiert und nicht rekursiv alle. Da die Änderungen sehr umfangreich sind, müssen die kompletten Produkttests für AD Connector und S4 Connector wiederholt werden.
Ich habe 15 Gruppen (testgroup1-15) und 500 Benutzer (testuser1-500) angelegt, wobei alle Benutzer Mitglieder in allen Gruppen sind. S4: Auf S4 Seite fehlen dann in allen Gruppen die letzen 30 Benutzer. Merkwürdig ist, dass man für alle Benutzer, die in den S4 Gruppen aufgenommen wurden, folgende Meldung im Log findet: -> grep "Found uid=testuser470,dc=as,dc=df in group cache ucs" /var/log/univention/connector-s4.log ... 21.02.2012 16:24:26,692 LDAP (INFO ): Found CN=ttestuser250,DC=ww,DC=ee in group cache ad: DN: uid=ttestuser250,dc=ff,dc=gg ... Für alle Benutzer die in den S4 Gruppen fehlen, gibt es keine solche Meldung: -> grep "Found uid=testuser480,dc=as,dc=df in group cache ucs" /var/log/univention/connector-s4.log AD: Hier verhält es sich ähnlich, jedoch ist der Fehler erst aufgetreten, als ich zusätzlich zu den bereits angelegten 500 Benutzern (Gruppenmitgliedschaften korrekt) weitere 500 Benutzer (ttestuser1-500) angelegt habe, die alle Mitglieder der vorhandenen 15 Gruppen sein sollten. Alle Gruppen haben dann die Mitglieder bis Benutzer ttestuser369, ab dann fehlen die sie. Auch hier gibt es für die "fehlenden" Benutzer keinen "cache" Eintrag im Log File: grep "Found CN=ttestuser370,DC=ww.* in group cache" /var/log/univention/connector.log root@master:/var/lib/univention-connector/ad# grep "Found CN=ttestuser369,DC=ww.* in group cache" /var/log/univention/connector.log 21.02.2012 16:23:45,418 LDAP (INFO ): Found CN=ttestuser369,DC=ww,DC=ee in group cache ad: DN: uid=ttestuser369,dc=ff,dc=gg ... Wenn man nachträglich einen Benutzer angelegt, der in einer der Gruppen, in denen Mitglieder fehlen, aufgenommen wird, werden die Gruppenmitgliedschaften der Gruppe "korrigiert" und stimmen dann für alle Benutzer. Log File von AD/S4 Connector im Anhang, ebenso das python Script, mit dem die Benutzer/Gruppen angelegt wurden. Die System sind (S4) 10.200.7.16 - fbotner_3.0-ms4-16 auf isala (AD) 10.200.7.70 - fbotner_master-70 auf boskel 10.200.7.72 - fbotner_w2k8r2-64-72 auf isala
Created attachment 4202 [details] connector-s4.log.gz
Created attachment 4203 [details] connector.log.gz
Created attachment 4204 [details] Script zum Anlegen der Gruppen/Benutzer
Wird der Benutzer auf UCS angelegt, so wurde der Benutzer nicht direkt in seine Gruppen hinzugefügt. Das wird jetzt gemacht. Das macht diesen Testfall deutlich langsamer, da jetzt der Benutzer einzeln zu jeder Gruppe hinzugefügt wird.
Die Synchronisation der Gruppenmitgliedschaften funktioniert jetzt. Getestet wurde folgendes: * 15 Gruppen angelegt * 1 Benutzer in je 15 Gruppen angelegt * 500 Benutzer in je 15 Gruppen angelegt * 1 Benutzer in je 15 Gruppen angelegt * 500 Benutzer in je 15 Gruppen angelegt * 1 Benutzer in je 15 Gruppen angelegt Die Benutzer wurden direkt beim Anlegen in die (gleiche) 15 Gruppen aufgenommen. Anschließend gab es also 15 Gruppen mit je 1003 Mitgliedern. Die Zeiten wurden gemessen vom Ausführen des UDM (Python) Kommandos bis der Connector wirklich mit Allem durch war (22.02.2012 12:14:39,421 LDAP (INFO ): _set_lastUSN: new lastUSN is: 4775 im Log file) | AD | S4 -------------------------------|----------|---------------------- 1 Benutzer in je 15 Gruppen | 7s | -------------------------------|----------|---------------------- 500 Benutzer in je 15 Gruppen | 25min | 30min -------------------------------|----------|---------------------- 1 Benutzer in je 15 Gruppen | 1min 10s | 1min 30min -------------------------------|----------|---------------------- 500 Benutzer in je 15 Gruppen | 40min | 1h 37min -------------------------------|----------|---------------------- 1 Benutzer in je 15 Gruppen | 2min 30s | 1min 10s Das ist im Vergleich zu 3.0-0, wo die Gruppensynchronisation in meinen Test teilweise gar nicht funktioniert hat bzw. das Anlegen eines Benutzers mit 15 Gruppen (in denen bereits 1000 Mitglieder waren) über 10min dauerte, schon deutlich besser. Auffällig: Beim Anlegen eines Benutzers in 15 Gruppen (mit 1000 Mitgliedern) is es im S4 Szenario deutlich schneller (mehrmals getestet). TODO Produkttests.
Created attachment 4210 [details] connector-s4.log Wenn über S4/AD an einer Gruppen eine Benutzer hinzugefügt wird, wird am UCS Objekt zwar uniqueMember aber nicht "memberUid" gesetzt. Mit S4 aus 3.0-0 hat das noch funktioniert. -> samba-tool group add s4group -> samba-tool group addmembers s4group testuser1 -> univention-ldapsearch -LLLL cn=s4group dn: cn=s4group,cn=users,dc=as,dc=df sambaGroupType: 2 cn: s4group objectClass: top objectClass: posixGroup objectClass: univentionGroup objectClass: sambaGroupMapping objectClass: univentionObject univentionObjectType: groups/group gidNumber: 5058 sambaSID: S-1-5-21-2552508822-3878602903-2957377927-251147 uniqueMember: uid=testuser1,dc=as,dc=df uniqueMember: uid=testuser2,dc=as,dc=df -> univention-s4search cn=s4group dn: CN=s4group,CN=Users,DC=as,DC=df objectClass: top objectClass: group cn: s4group instanceType: 4 whenCreated: 20120222140512.0Z uSNCreated: 23999 name: s4group objectGUID: 18a13dc2-5d7d-406a-b11c-15b02a8f0568 objectSid: S-1-5-21-2552508822-3878602903-2957377927-251147 sAMAccountName: s4group sAMAccountType: 268435456 groupType: -2147483646 objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=as,DC=df member: CN=testuser1,DC=as,DC=df member: CN=testuser2,DC=as,DC=df whenChanged: 20120222143030.0Z uSNChanged: 24001 distinguishedName: CN=s4group,CN=Users,DC=as,DC=df
Ich mache jetzt trotzdem mit den AD Produkttests weiter.
Created attachment 4211 [details] connector.log Wenn ich im AD den Administrator zu einer Gruppe hinzufüge, wird das am UCS Object anscheinend nicht gemacht. -> univention-adsearch cn=adgroup1 DN: CN=adgroup1,CN=Users,DC=ww,DC=ee distinguishedName: CN=adgroup1,CN=Users,DC=ww,DC=ee sAMAccountType: 268435456 cn: adgroup1 objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=ww,DC=ee objectClass: top objectClass: group objectGUID: ['\xe6f\x05-\x9c\x1b\xf7I\xab\xd36\x07\xed\xd2\x04\x8e'] sAMAccountName: adgroup1 whenChanged: 20120221130540.0Z member: CN=join-backup,CN=Users,DC=ww,DC=ee member: CN=Administrator,CN=Users,DC=ww,DC=ee objectSid: S-1-5-21-1950644492-691169364-2646992570-1109 whenCreated: 20120221130103.0Z uSNCreated: 20596 groupType: -2147483646 uSNChanged: 20616 instanceType: 4 dSCorePropagationData: 16010101000000.0Z name: adgroup1 -> univention-ldapsearch cn=adgroup1 dn: cn=adgroup1,cn=users,dc=ff,dc=gg sambaGroupType: 2 cn: adgroup1 objectClass: top objectClass: posixGroup objectClass: univentionGroup objectClass: sambaGroupMapping objectClass: univentionObject univentionObjectType: groups/group gidNumber: 5037 sambaSID: S-1-5-21-3924820788-952401084-2473915625-11075 uniqueMember: uid=join-backup,cn=users,dc=ff,dc=gg Im Log sieht man folgendes: samaccount_dn_mapping: newdn for key dn: samaccount_dn_mapping: olddn: CN=Administrator,CN=Users,DC=ww,DC=ee samaccount_dn_mapping: newdn: cn=Administrator,CN=Users,DC=ww,DC=ee samaccount_dn_mapping: check newdn for key olddn: group_members_sync_to_ucs: mapped ad member to ucs DN cn=Administrator,cn=users,dc=ff,dc=gg Failed to find cn=Administrator,cn=users,dc=ff,dc=gg via self.lo.get group_members_sync_to_ucs: ucs_members: ['uid=join-backup,cn=users,dc=ff,dc=gg'] group_members_sync_to_ucs: ucs_members_from_ad: {'group': [u'uid=join- backup,cn=users,dc=ff,dc=gg'], 'user': []}
(In reply to comment #13) > Created an attachment (id=4211) [details] > connector.log > > Wenn ich im AD den Administrator zu einer Gruppe hinzufüge, wird das am UCS > Object anscheinend nicht gemacht. Der Benutzer Administrator steht in dem AD Mapping im ignore-Filter. Deshalb wird dieser nicht synchronisiert. (In reply to comment #11) > Created an attachment (id=4210) [details] > connector-s4.log > > Wenn über S4/AD an einer Gruppen eine Benutzer hinzugefügt wird, wird am UCS > Objekt zwar uniqueMember aber nicht "memberUid" gesetzt. > > Mit S4 aus 3.0-0 hat das noch funktioniert. Das ist jetzt für S4 und AD angepasst.
(In reply to comment #14) > (In reply to comment #13) > > Created an attachment (id=4211) [details] [details] > > connector.log > > > > Wenn ich im AD den Administrator zu einer Gruppe hinzufüge, wird das am UCS > > Object anscheinend nicht gemacht. > > Der Benutzer Administrator steht in dem AD Mapping im ignore-Filter. Deshalb > wird dieser nicht synchronisiert. OK > > (In reply to comment #11) > > Created an attachment (id=4210) [details] [details] > > connector-s4.log > > > > Wenn über S4/AD an einer Gruppen eine Benutzer hinzugefügt wird, wird am UCS > > Objekt zwar uniqueMember aber nicht "memberUid" gesetzt. > > > > Mit S4 aus 3.0-0 hat das noch funktioniert. > > Das ist jetzt für S4 und AD angepasst. Funktioniert
ucs-test: Für AD und S4 wurden die ucs-test ausgeführt. In beiden Fällen sind folgende Test fehlgeschlagen: 89read_ad_move_container 89read_ad_remove_container 89sync_ad_move_container 89sync_ad_remove_container 99read_ad_move_ou 99read_ad_remove_ou 99sync_ad_move_ou 99sync_ad_remove_ou 72sync_ad_change_username (nur S4) Das hat aber nichts mit den Gruppen zu tun (siehe Bug #25818 und Bug #26226) Händische Tests S4: UCS 3.0-1 amd64 mit S4 Connector und Win7-amd64 mit AD Tools * Installation (keine Rejects) - OK * Benutzer auf S4 anlegen - OK * Benutzer auf UCS anlegen - OK * Passwort auf S4 ändern - OK * Passwort auf UCS ändern - OK * Benutzer auf S4 löschen - OK * Benutzer auf UCS löschen - OK * Gruppen auf S4 anlegen - OK * Gruppen auf UCS anlegen - OK * Gruppenmitglieder auf S4 ändern - OK * Gruppenmitglieder auf UCS ändern - OK * Gruppen auf S4 löschen - OK * Gruppen auf UCS löschen - OK * Gejointe Windows Clients im UMC - OK * Gejointe UCS DC's im S4 - OK * Gejointe UCS DC's mit S4 im S4 - OK * DNS Zonen auf UCS anlegen - OK * Host Einträge in S4 - OK Händische Tests AD: Die Test wurden nur mit einer Umgebung gemacht, UCS 3.0-1 i386 mit AD Connector und deutsches W2K8R2-amd64 SP1 (unterschiedliche LDAP Basis) Nur Sync Mode AD-Seite / UCS-Seite * Gruppe anlegen - OK * Attribute - OK * Gruppenmitgliedschaften nachträglich (primaryGroup) - OK * Gruppe mit Umlauten - OK * Gruppe löschen - OK * Gruppe verschieben - OK * Gruppen umbenennen - OK * primaryMail - OK Initial-Sync der Gruppenmitgliedschaften * AD -> UCS - OK * UCS -> AD - OK Verschachtelte Gruppen * verschachtelte Gruppen in AD - OK * Benutzermitgliedschaften - OK * verschachtelte Gruppen in UCS - OK * Samba Gruppentypen - OK * memberOf an Gruppen entfernen, UCS/AD - FAILED Bug #18680 * Gruppe A Mitglied von GruppeB - OK * Gruppen mit Benutzern, Gruppen und Rechnern - OK * Verschieben von Gruppen bzw. Gruppenmitgliedern - OK
Ich mache den nochmal auf. In einer Umgebung tritt direkt nach dem Update von Samba3 auf Samba4 folgender Traceback bei einem Teil der User auf: 23.02.2012 20:37:40,586 LDAP (WARNING): Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 747, in __sync_file_from_ucs or (not old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, old_dn, old))): File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 2168, in sync_from_ucs f(self, property_type, object) File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 61, in object_memberships_sync_from_ucs return s4connector.object_memberships_sync_from_ucs(key, object) File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 1230, in object_memberships_sync_from_ucs self.one_group_member_sync_from_ucs(s4_group_object, object ) File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 1496, in one_group_member_sync_from_ucs self.lo_s4.lo.modify_s(s4_group_object['dn'],compatible_modlist(ml)) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 322, in modify_s return self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 422, in result res_type,res_data,res_msgid = self.result2(msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 426, in result2 res_type, res_data, res_msgid, srv_ctrls = self.result3(msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 432, in result3 ldap_result = self._ldap_call(self._l.result3,msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) ALREADY_EXISTS: {'info': '00002071: Entry already exists - samldb: member <S4-DN-des-Users> already set via primaryGroupID 513', 'desc': 'Already exists'} In dieser Umgebung betrifft das 49 der 76 Mitglieder der Gruppe RID 513. Ablauf: - nach dem Update von Samba3 auf Samba4 rejecten diese User mit dem Traceback aus Bug #26228 (Achtung: nur an wenig Stichproben geprüft) - beim Versuch den Reject einzuspielen tritt der Traceback an diesem Bug auf Zwischenzeitlich wurden die Positionen im Samba4 korrigiert (Script aus Bug #26120), das ändert aber nichts an dem Traceback.
(In reply to comment #17) > Ich mache den nochmal auf. In einer Umgebung tritt direkt nach dem Update von > Samba3 auf Samba4 folgender Traceback bei einem Teil der User auf: > > 23.02.2012 20:37:40,586 LDAP (WARNING): Traceback (most recent call > last): > File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line > 747, in __sync_file_from_ucs > or (not old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, > old_dn, old))): > File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", > line 2168, in sync_from_ucs > f(self, property_type, object) > File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", > line 61, in object_memberships_sync_from_ucs > return s4connector.object_memberships_sync_from_ucs(key, object) > File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", > line 1230, in object_memberships_sync_from_ucs > self.one_group_member_sync_from_ucs(s4_group_object, object ) > File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", > line 1496, in one_group_member_sync_from_ucs > self.lo_s4.lo.modify_s(s4_group_object['dn'],compatible_modlist(ml)) > File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 322, in > modify_s > return self.result(msgid,all=1,timeout=self.timeout) > File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 422, in > result > res_type,res_data,res_msgid = self.result2(msgid,all,timeout) > File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 426, in > result2 > res_type, res_data, res_msgid, srv_ctrls = self.result3(msgid,all,timeout) > File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 432, in > result3 > ldap_result = self._ldap_call(self._l.result3,msgid,all,timeout) > File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 96, in > _ldap_call > result = func(*args,**kwargs) > ALREADY_EXISTS: {'info': '00002071: Entry already exists - samldb: member > <S4-DN-des-Users> already set via primaryGroupID 513', 'desc': 'Already > exists'} Welche Connector Version ist das?
(In reply to comment #18) > > Welche Connector Version ist das? cherrypick-build: 6.0.110-1.135.201202231048
(In reply to comment #17) > Ich mache den nochmal auf. In einer Umgebung tritt direkt nach dem Update von > Samba3 auf Samba4 folgender Traceback bei einem Teil der User auf: > > 23.02.2012 20:37:40,586 LDAP (WARNING): Traceback (most recent call > last): > File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line > 747, in __sync_file_from_ucs > or (not old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, > old_dn, old))): > File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", > line 2168, in sync_from_ucs > f(self, property_type, object) > File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", > line 61, in object_memberships_sync_from_ucs > return s4connector.object_memberships_sync_from_ucs(key, object) > File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", > line 1230, in object_memberships_sync_from_ucs > self.one_group_member_sync_from_ucs(s4_group_object, object ) > File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", > line 1496, in one_group_member_sync_from_ucs > self.lo_s4.lo.modify_s(s4_group_object['dn'],compatible_modlist(ml)) > File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 322, in > modify_s > return self.result(msgid,all=1,timeout=self.timeout) > File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 422, in > result > res_type,res_data,res_msgid = self.result2(msgid,all,timeout) > File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 426, in > result2 > res_type, res_data, res_msgid, srv_ctrls = self.result3(msgid,all,timeout) > File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 432, in > result3 > ldap_result = self._ldap_call(self._l.result3,msgid,all,timeout) > File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 96, in > _ldap_call > result = func(*args,**kwargs) > ALREADY_EXISTS: {'info': '00002071: Entry already exists - samldb: member > <S4-DN-des-Users> already set via primaryGroupID 513', 'desc': 'Already > exists'} > Vor dem Synchronisieren der Gruppenmitgliedschaften werden die primären Gruppen herausgefiltert. In diesem Fall stand im Reject File noch eine andere primäre Gruppe, weshalb diese nicht herausgefiltert wurde. In dem Fix wird dieser Fehler jetzt ignoriert. Das ist besser, als eine erneute Suche im LDAP durchzuführen.
Konnte das Problem wie folgt nachvollziehen: -> univention-s4search cn=test1 | grep primaryGroupID primaryGroupID: 1308 -> univention-ldapsearch uid=test1 | grep sambaPrimaryGroupSID sambaPrimaryGroupSID: S-1-5-21-2552508822-3878602903-2957377927-1308 # connector gestoppt # primäre Gruppe von test1 in UCS geändert # pickle File angepasst (sambaPrimaryGroupSID gidNumber geändert) -> grep Primary -A 3 /var/lib/univention-connector/s4/1330084561.793757 asS'sambaPrimaryGroupSID' p95 (lp96 S'S-1-5-21-2552508822-3878602903-2957377927-513' -- asS'sambaPrimaryGroupSID' p223 (lp224 S'S-1-5-21-2552508822-3878602903-2957377927-1306' Der "alte" Connector gab dann folgenden Traceback aus S4: File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) ALREADY_EXISTS: {'info': '00002071: Entry already exists - samldb: member CN=test1,DC=as,DC=df already set via primaryGroupID 1308', 'desc': 'Already exists'} AD: ALREADY_EXISTS: {'info': '00000528: UpdErr: DSID-031A119B, problem 6005 (ENTRY_EXISTS), data 0\n', 'desc': 'Already exists'} Nach dem Update mit S4/AD OK w24.02.2012 13:11:13,328 LDAP (INFO ): one_group_member_sync_from_ucs: User is already member of the group: cn=testgroup2,dc=as,dc=df modlist: [(0, 'member', [u'cn=test1,dc=as,dc=df'])] Ich habe noch einmal kurz (!!) die Gruppensynchr. getestet (AD/S4). Gruppen anlegen (UCS, CON) Mitglieder (UCS, CON) primäre Gruppe ändern (UCS, CON) Gruppen, Mitglieder verschieben (UCS, CON) Mitglieder, Gruppen löschen (UCS, CON)
UCS 3.0-1 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"
*** Bug 24011 has been marked as a duplicate of this bug. ***