Univention Bugzilla – Bug 25818
S4 Connector Test Fehlermeldungen
Last modified: 2012-12-12 21:09:55 CET
Bei den Tests zu Bug #25709 sind die folgenden automatisierten Tests für den S4 Connector fehlgeschlagen. Es ist aktuell unklar, ob das Probleme in Testskripten oder im Connector sind: * Synchronize ucs-user that has another group than Domain Users as primary group in sync mode * Synchronize ucs-user that has another group than Domain Users as primary group in write mode * Synchronize ad-user that has another group than Domain Users as primary group in read mode * Synchronize ad-user that has another group than Domain Users as primary group in sync mode * Move an UCS-user out of the User-Ignore-Subtree in sync-mode * Move an UCS-user in sync-mode * Move an UCS-user in write-mode * Create an UCS-User and change its name in sync-mode * Check whether container can be recursively moved on ad-side in read-mode * Check whether container can be recursively removed on ad-side in read-mode * Check whether container can be recursively moved on ad-side in sync-mode * Check whether container can be recursively removed on ad-side in sync-mode * Check whether ou can be recursively moved on ad-side in read-mode * Check whether ou can be recursively removed on ad-side in read-mode * Check whether ou can be recursively moved on ad-side in sync-mode * Check whether ou can be recursively removed on ad-side in sync-mode * Check whether ou can be recursively removed on ad-side in write-mode
folgende Tests (AD/S4) schlagen immer fehl 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 Bei den 3.0-0 Produkttest habe ich das dann einzeln nochmal getestet und wenn nötig Bugs angelegt. Diese Test-Scripte müssen aber nochmal "repariert" werden.
UCS 3.1 will be the next release.
Bug #28689 (Gruppensynchronisation bei unterschiedlicher Basis-DN) kam noch hinzu.
(In reply to comment #1) > folgende Tests (AD/S4) schlagen immer fehl > > 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 Ursache scheinen mindestens zwei Punkte zu sein: 1. Die Reihenfolge im Connector kann so sein, dass zunächst cn=cn2,cn=c1,$ldap_base versucht wird anzulegen und danach erst cn=c1,$ldap_base. Das funktioniert natürlich nicht direkt. cn=cn2 wird rejected und später erfolgreich angelegt. In der Default Einstellung wird dies aber erst beim 10. Versuch gemacht also nach ca. 50 Sekunden, dann hat aber der Timeout schon zugeschlagen und der Test schlägt fehl. → Die Tests werden so angepasst, dass retryrejected auf 2 gesetzt wird. 2. lastKnownParent wird an den rekursiv gelöschten Untercontainern nicht gesetzt. Wir könnten im Connector einfach ein remove_childs übergeben. Es kann sein, dass das ein Samba 4 Bug ist, hier müsste nochmal das AD Verhalten geprüft werden.
(In reply to comment #4) > (In reply to comment #1) > > folgende Tests (AD/S4) schlagen immer fehl > > > > 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 > > Ursache scheinen mindestens zwei Punkte zu sein: > > 1. Die Reihenfolge im Connector kann so sein, dass zunächst > cn=cn2,cn=c1,$ldap_base versucht wird anzulegen und danach erst > cn=c1,$ldap_base. Das funktioniert natürlich nicht direkt. cn=cn2 wird rejected > und später erfolgreich angelegt. In der Default Einstellung wird dies aber erst > beim 10. Versuch gemacht also nach ca. 50 Sekunden, dann hat aber der Timeout > schon zugeschlagen und der Test schlägt fehl. > → Die Tests werden so angepasst, dass retryrejected auf 2 gesetzt wird. > > 2. lastKnownParent wird an den rekursiv gelöschten Untercontainern nicht > gesetzt. Wir könnten im Connector einfach ein remove_childs übergeben. Es kann > sein, dass das ein Samba 4 Bug ist, hier müsste nochmal das AD Verhalten > geprüft werden. 3. Temporäres Objekt wird nicht entfernt: Im ersten Schritt kann der Benutzer nicht angelegt werden, da der Container noch nicht vorhanden ist. Anschließend gibt es eine Exception, weil der Benutzer nicht angelegt werden kann: 25.09.2012 18:15:01,399 LDAP (ERROR ): Unknown Exception during sync_to_ucs 25.09.2012 18:15:01,401 LDAP (ERROR ): Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 1290, in sync_to_ucs result = self.add_in_ucs(property_type, object, module, position) File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 1162, 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.6/univention/admin/handlers/__init__.py", line 331, in create return self._create() File "/usr/lib/pymodules/python2.6/univention/admin/handlers/__init__.py", line 628, in _create al=self._ldap_addlist() File "/usr/lib/pymodules/python2.6/univention/admin/handlers/users/user.py", line 1827, in _ldap_addlist raise univention.admin.uexceptions.uidAlreadyUsed, ': %s' % username uidAlreadyUsed: : rccygumg
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #1) > > > folgende Tests (AD/S4) schlagen immer fehl > > > > > > 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 > > > > Ursache scheinen mindestens zwei Punkte zu sein: > > > > 1. Die Reihenfolge im Connector kann so sein, dass zunächst > > cn=cn2,cn=c1,$ldap_base versucht wird anzulegen und danach erst > > cn=c1,$ldap_base. Das funktioniert natürlich nicht direkt. cn=cn2 wird rejected > > und später erfolgreich angelegt. In der Default Einstellung wird dies aber erst > > beim 10. Versuch gemacht also nach ca. 50 Sekunden, dann hat aber der Timeout > > schon zugeschlagen und der Test schlägt fehl. > > → Die Tests werden so angepasst, dass retryrejected auf 2 gesetzt wird. > > > > 2. lastKnownParent wird an den rekursiv gelöschten Untercontainern nicht > > gesetzt. Wir könnten im Connector einfach ein remove_childs übergeben. Es kann > > sein, dass das ein Samba 4 Bug ist, hier müsste nochmal das AD Verhalten > > geprüft werden. Im AD (Windows 2008 R2) wird lastKnownParent gespeichert, allerdings auch das DeletedObject, damit kann der Connector nicht umgehen: root@master711:~# cat container.ldif DN: CN=t1,DC=ad,DC=local cn: t1 name: t1 objectClass: top objectClass: container DN: CN=t2,CN=t1,DC=ad,DC=local cn: t2 name: t2 objectClass: top objectClass: container root@master711:~# univention-adsearch cn=t1* lastKnownParent # # univention-adsearch # filter: cn=t1* # DN: CN=t1\0ADEL:8f59bd2d-fdbd-4224-9db3-2d0ffeae6b0b,CN=Deleted Objects,DC=ad,DC=local lastKnownParent: DC=ad,DC=local # # results: 1 # root@master711:~# univention-adsearch cn=t2* lastKnownParent # # univention-adsearch # filter: cn=t2* # DN: CN=t2\0ADEL:4ba585e7-b11f-4e3c-97a8-27fa5b88f3c4,CN=Deleted Objects,DC=ad,DC=local lastKnownParent: CN=t1\0ADEL:8f59bd2d-fdbd-4224-9db3-2d0ffeae6b0b,CN=Deleted Objects,DC=ad,DC=local # # results: 1 # root@master711:~#
(In reply to comment #0) > * Move an UCS-user out of the User-Ignore-Subtree in sync-mode > > * Move an UCS-user in sync-mode > > * Move an UCS-user in write-mode Dieses Punkte wurden nach Bug #28700 ausgelagert.
Die Testsuite läuft jetzt durch. Es gibt noch einige Probleme, die in späteren Versionen behoben werden. Diese sind in den Tests und in Bugzilla dokumentiert.
Created attachment 4724 [details] test_1350604324.log.gz Bei den S4 Connector Test ist noch eine schief gegangen Move an UCS-user in sync-mode .... Test failed AD läuft noch.
(In reply to comment #9) > Created an attachment (id=4724) [details] > test_1350604324.log.gz > > Bei den S4 Connector Test ist noch eine schief gegangen > > Move an UCS-user in sync-mode .... Test failed > > > AD läuft noch. Ich habe noch eine Änderung an 63sync_ad_remove_capital_user_from_group gemacht, da der Test aufgrund von Bug #18433 schief geht. 70sync_ucs_move_user habe ich jetzt mehrfach getestet, immer ohne Probleme. Könntest du debug level 4 für den Connector setzen und versuchen das Verhalten zu reproduzieren?
Wieder zu.
OK, nun sind alle Test erfolgreich durchgelaufen (S4 und AD). Changelog Eintrag vorhanden.
UCS 3.1-0 has been released: http://forum.univention.de/viewtopic.php?f=54&t=2125 If this error occurs again, please use "Clone This Bug".