Univention Bugzilla – Bug 26504
Selektive Replikation der Schulserver
Last modified: 2012-06-11 06:29:41 CEST
In der aktuellen MS1 Konfiguration werden die bereits angelegten DCs auch an andere Schulen synchronisiert, da diese per Default criticalSystem Objekte sind. +++ This bug was initially created as a clone of Bug #23920 +++ UCS@school verwendet die Selektive Replikation für die Schulserver. Mit Samba 4 ist das Out-of-the-Box nicht möglich. Siehe auch Bug #22864. Das Verhalten sollte mit UCS@school 3.0 geprüft werden.
(In reply to comment #0) > In der aktuellen MS1 Konfiguration werden die bereits angelegten DCs auch an > andere Schulen synchronisiert, da diese per Default criticalSystem Objekte > sind. Wenn S4 nicht auf dem Master installiert ist, müsste S4 auf dem Slave unterstützt werden. Das kann vermutlich über das Provision-Verfahren umgesetzt werden.
Created attachment 4272 [details] Samba4-Patch, der das provision-Skript um die Option --sitname erweitert > Wenn S4 nicht auf dem Master installiert ist, müsste S4 auf dem Slave > unterstützt werden. Das kann vermutlich über das Provision-Verfahren umgesetzt > werden. Im Moment wird im univention-samba4 Joinscript auch ldap/master verwendet, um dort vor dem Slave-Join die Site-Objekte anzulegen. Das könnte bei Slave-Provision entfallen.
Created attachment 4273 [details] Patch für univention-samba4, der für DCs den samba4/join/essentialonly Code durch Code für samba4/provision/secondary ersetzt
Wenn auf dem Master ein Schüler für die Schule angelegt wird, dann erhalte ich folgende Meldung im Connector auf dem Schul DC: 13.03.2012 07:51:54,508 LDAP (PROCESS): sync from ucs: [ user] [ add] cn=schue ler1,cn=schueler,cn=users,ou=school1,dc=dedlock10,dc=local 13.03.2012 07:51:54,518 LDAP (WARNING): sync failed, saved as rejected 13.03.2012 07:51:54,518 LDAP (WARNING): Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 749, in __sync_file_f rom_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 2104, in sync_from _ucs self.lo_s4.lo.add_ext_s(compatible_modstring(object['dn']), compatible_addlist(addlist), serverc trls=self.serverctrls_for_add_and_modify) #FIXME encoding File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 180, in add_ext_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) UNWILLING_TO_PERFORM: {'info': '00002035: Unwilling to perform - ../source4/dsdb/samdb/ldb_modules/ridalloc.c:494: No RID Set DN - Remote RID Set allocation needs refresh', 'desc': 'Server is unwilling to perform'}
ucs-school-slave setzt jetzt im postinst die UCR-Variable samba4/provision/secondary=yes ## nicht '?yes' Falls diese Variable gesetzt ist, ruft das Joinscript von univention-samba4 auch auf sekundären Samba4 DCs das Samba4 provision Script auf. Im join.log sieht man, dass beim Provision die Domain SID des Master übergeben wurde: Server Role: domain controller Hostname: qaslave NetBIOS Domain: ARSCHOOL3I1 DNS Domain: arschool3i1.qa DOMAIN SID: S-1-5-21-3249565516-167943855-79951987 Admin password: ZaAb5v87G8YFzXMv Diese wurde in setup-s4.sh aus dem sambadomain Objekt im UCS LDAP ausgelesen: root@qaslave:~# univention-ldapsearch objectclass=sambadomain sambaSID | grep ^sambaSID sambaSID: S-1-5-21-3249565516-167943855-79951987 root@qamaster:~# univention-s4search -b DC=arschool3i1,DC=qa -s base objectSid # record 1 dn: DC=arschool3i1,DC=qa objectSid: S-1-5-21-3249565516-167943855-79951987
Die SID aus dem LDAP wird aktuell nicht übernommen, wenn auf dem Master kein Samba 4 installiert wird. In diesem Fall wird das Provision mit einer neuen SID durchgeführt.
Ich habe jetzt folgende Testumgebung aufgesetzt, Master mit S4 und Schul DC mit S4. Beim Join wird folgendes aufgerufen: /usr/share/univention-samba4/scripts/setup-s4.sh --binddn uid=Administrator,cn=users,dc=deadlock32,dc=local --bindpwd univention --sitename school1 Die Meldungen sind auch soweit erfolgreich. Der Connector kann anschließend auf dem System keine Benutzer, Gruppen oder Rechner anlegen: 25.04.2012 21:02:53,349 LDAP (PROCESS): sync from ucs: [ group] [ add] cn=OUschool1-Member-Edukativnetz,cn=ucsschool,cn=groups,dc=deadlock32,dc=local 25.04.2012 21:02:53,358 LDAP (WARNING): sync failed, saved as rejected 25.04.2012 21:02:53,359 LDAP (WARNING): Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 749, 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 2104, in sync_from_ucs self.lo_s4.lo.add_ext_s(compatible_modstring(object['dn']), compatible_addlist(addlist), serverctrls=self.serverctrls_for_add_and_modify) #FIXME encoding File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 180, in add_ext_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 - ../ldb_tdb/ldb_index.c:1189: Failed to re-index objectSid in CN=OUschool1-Member-Edukativnetz,CN=ucsschool,CN=Groups,DC=deadlock32,DC=local - ../ldb_tdb/ldb_index.c:1121: unique index violation on objectSid in CN=OUschool1-Member-Edukativnetz,CN=ucsschool,CN=Groups,DC=deadlock32,DC=local', 'desc': 'Already exists'} Das Problem tritt auch auf, wenn ich das LDB Modul deaktiviere.
(In reply to comment #7) > 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 - > ../ldb_tdb/ldb_index.c:1189: Failed to re-index objectSid in > CN=OUschool1-Member-Edukativnetz,CN=ucsschool,CN=Groups,DC=deadlock32,DC=local > - ../ldb_tdb/ldb_index.c:1121: unique index violation on objectSid in > CN=OUschool1-Member-Edukativnetz,CN=ucsschool,CN=Groups,DC=deadlock32,DC=local', > 'desc': 'Already exists'} > > Das Problem tritt auch auf, wenn ich das LDB Modul deaktiviere. Das Problem tritt nicht mehr auf, wenn das Attribut rIDNextRID (cn=RID SET,cn=SLAVE,...) auf eine RID gesetzt wird, die noch nicht vorhanden ist. Aktuell ist der RID Bereich auf dem Slave genauso gesetzt wie auf auf dem Master. Ich denke mindestens das sollte auf dem Slave anders sein.
(In reply to comment #8) > Das Problem tritt nicht mehr auf, wenn das Attribut rIDNextRID (cn=RID > SET,cn=SLAVE,...) auf eine RID gesetzt wird, die noch nicht vorhanden ist. > > Aktuell ist der RID Bereich auf dem Slave genauso gesetzt wie auf auf dem > Master. Ich denke mindestens das sollte auf dem Slave anders sein. Der RID Pool wird auf einem Slave jetzt auf 2100 - 2500 gesetzt. Eine generische Lösung wäre besser.
Siehe Bug #26532, samba4/rpc/endpoint/drsuapi sollte auf den S4 DCs aktiviert werden. Es müsste dann sichergestellt werden, dass keine Replikation durchgeführt wird. Der Aufruf von "samba-tool drs showrepl" zeigt, dass jetzt zumindest eine Kommunikation stattfindet: root@slave323:~# samba-tool drs showrepl GSS client Update(krb5)(1) Update failed: Miscellaneous failure (see text): Key version is not available SPNEGO(gssapi_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_LOGON_FAILURE SPNEGO(gssapi_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_INVALID_PARAMETER school1\SLAVE323 DSA Options: 0x00000001 DSA object GUID: 6415069d-312e-4051-bc8d-2c911ccc6ae2 DSA invocationId: 6cf3bc0c-34da-45f1-889d-22498570713f ==== INBOUND NEIGHBORS ==== ==== OUTBOUND NEIGHBORS ==== ==== KCC CONNECTION OBJECTS ==== So sieht die Ausgabe aus, wenn drsuapi abgeschaltet ist: root@slave323:~# samba-tool drs showrepl ERROR(runtime): DRS connection to slave323.deadlock32.local failed - (-1073741249, 'NT_STATUS_PORT_UNREACHABLE')
*** Bug 26532 has been marked as a duplicate of this bug. ***
Zu Comment 10: ucs-school-slave setzt jetzt nicht mehr samba4/rpc/endpoint/drsuapi=false, d.h. der DRSUAPI Endpoint ist jetzt wieder aktiviert. Damit hat der samba-tool client dann Zugriff auf diesen RPC Endpoint und kann die lokale invocationId etc. darüber abrufen. Da der drepl-Service weiterhin deaktiviert ist, werden keine inbound oder outbound connections angezeigt.
Zu Comment 7: Der S4 Connector legt samAccounts bisher immer ohne Angabe der objectSid an, weil AD/Samba4 normalerweise eine Angabe der objectSid nicht erlauben. Um das trotzdem tun zu können bietet Samba4 das "provision" control, das wir über Bug 26051 zu diesem Zweck über LDAPI exponiert haben. Für die entsprechende Anpassung des S4 Connectors gibt es Bug 26055.
(In reply to comment #13) > Zu Comment 7: > > Der S4 Connector legt samAccounts bisher immer ohne Angabe der objectSid an, > weil AD/Samba4 normalerweise eine Angabe der objectSid nicht erlauben. Um das > trotzdem tun zu können bietet Samba4 das "provision" control, das wir über Bug > 26051 zu diesem Zweck über LDAPI exponiert haben. Für die entsprechende > Anpassung des S4 Connectors gibt es Bug 26055. Ich habe den Bug für UCS@school 3.0 und UCS 3.0-2 vorgesehen, damit sollte die Performance in grossen Umgebungen auch direkt besser werden.
(In reply to comment #6) > Die SID aus dem LDAP wird aktuell nicht übernommen, wenn auf dem Master kein > Samba 4 installiert wird. > > In diesem Fall wird das Provision mit einer neuen SID durchgeführt. Das könnte an meiner Testumgebung liegen, ich hatte mich auf dem Slave beim Domänennamen vertippt.
Das univention-samba4 Joinscript wurde so angepasst, dass auch auf dem ersten Samba 4 DC in der Domäne der Wert von samba4/join/site beim Provision und DNS Setup als Option übergeben wird.
Zwei Fehlermeldungen im Joinscript wurden noch korrigiert: * samba4/ldap/base muss vor dem create_site gesetzt sein * operatingSystem_attribute muss beim secondary provision replaced werden, "add" funktioniert in diesem Fall nicht.
Umgebung ohne zentrales S4 und S4 in der Schule: OK - S4 Join: OK - Replikation: OK - Join XP: OK - Join Win7: OK - Anmeldung: OK - Passwort ändern XP: OK - Passwort ändern Win7: OK Es fehlt noch der Test mit einem zentralen S4.
Der Join in die Umgebung mit zentralem S4 war auch erfolgreich, sowohl in die Schule, als auch in Zentrale. Offen ist noch, ob die GPOs funktionieren.
GPOs funktionieren ebenfalls für Umgebungen mit S4 nur an der Schule und für Umgebungen mit S4 in der Zentrale.
UCS@school 3.0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS@school erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"