Univention Bugzilla – Bug 25772
Samba 4 in UCS@school
Last modified: 2012-06-11 06:29:34 CEST
Samba 4 soll in UCS@school verfügbar sein.
Neben der selektiven Replikation sollte auch die Berechtigung geprüft werden, damit nicht einfach auf den Schul-DCs neue Benutzer angelegt werden.
Die Metapakete sollten so angepasst werden, dass S3 oder S4 installiert werden kann.
Ich kann über den Connector aktuell keinen auf dem Salve anlegen: 13.03.2012 07:39:26,22 LDAP (PROCESS): sync from ucs: [ user] [ modify] cn=daniel,cn=schueler,cn=users,ou=testschule1,dc=dedlock10,dc=local 13.03.2012 07:39:26,33 LDAP (WARNING): sync failed, saved as rejected 13.03.2012 07:39:26,33 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 2083, in sync_from_ucs self.lo_s4.lo.add_s(compatible_modstring(object['dn']), compatible_addlist(addlist)) #FIXME encoding File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 194, in add_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'} Ebenso wenig per samba-tool direkt auf dem Slave: root@slave102:~# samba-tool user add test1 univention ERROR(ldb): Failed to add user 'test1': - ../source4/dsdb/samdb/ldb_modules/ridalloc.c:494: No RID Set DN - Remote RID Set allocation needs refresh root@slave102:~#
ucs-school-slave depended jetzt auf univention-samba | univention-samba4 und univention-slave-pdc | univention-s4-connector
Das Problem in Comment 3 geht darauf zurück, dass auf dem UCS@School Slave die DRS-Replikation deaktiviert ist. Dadurch legt weder der (RID-)Master noch der DC Slave ein "RID Set" Objekt an. Hier gibt es zwei Möglichkeiten: 1. Man legt das entsprechende "RID Set" Objekt lokal an. 2. In den früheren Tests hatte ich den DC Slave per Samba4-provision aufgesetzt, also so wie den DC Master selbst auch, statt ihn per samba-tool zu Joinen. Im Joinscript von univention-samba4 ist jetzt erstmal die Variante 1 umgesetzt, damit konnte ich jetzt nach dem Join Benutzer anlegen. Es wird ein statischer Pool von 3000 RIDs angelegt. Diese vom DC Slave bei einem lokalen Client-Join vergebenen RIDs sind temporärer Natur und werden vom S4-Connector mit den UDM-Werten überschrieben. Um RID-Kollisionen im Samba4 des DC Slave vermeiden werden diese RIDs nicht dynamisch aus dem RID-Pool des RID-Master alloziert: Die vom UDM vergebenen RIDs sind initial höher (>5000) als die von Samba4 vergebenen (erster RID-Pool statet bei 1100). Irgendwann würden die sich also überschneiden. Wenn man dann am Standort ein Client Joinen will, könnte Samba4 sonst bei dem Versuch scheitern eine eindeutige objectSid aus dem lokalen RID-Pool zu vergeben.
Beim Joinen werden alle (?) ous/Schulen übertragen. Folgendes Vorgehen: - UCS@school Master mit 2 Schulen - UCS@school Slave in einer Schule angelegt und gejoint - Beide Schulen sind im S4 LDAP auf dem Slave vorhanden: root@slave102:~# ldbsearch -H /var/lib/samba/private/sam.ldb ou=* ou # record 1 dn: OU=Domain Controllers,DC=dedlock10,DC=local ou: Domain Controllers # record 2 dn: OU=school1,DC=dedlock10,DC=local ou: school1 # record 3 dn: OU=school2,DC=dedlock10,DC=local ou: school2 # Referral ref: ldap://dedlock10.local/CN=Configuration,DC=dedlock10,DC=local # returned 4 records # 3 entries # 1 referrals root@slave102:~# univention-ldapsearch ou=* ou -LLL dn: ou=school1,dc=dedlock10,dc=local ou: school1 root@slave102:~#
Im ucs-school-slave Postinst/Joinscript wird jetzt samba4/join/essentialonly=yes und samba4/join/site gesetzt. Falls beide Variablen entsprechend gesetzt sind wird im univention-samba4 Joinscript mit der Option --domain-critical-only gejoined. Dabei werden dann nur zusätzlich auch die an Bug 26504 notierte Objekte aus anderen OUs repliziert. Es wird lokal ein statischer RID-Pool angelegt, bestehend aus 2000 RIDs beginnend mit 2100.
Soweit funktionierte es in meinen Tests. Der Rest erfolgt über die neuen Bugs.
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"