Univention Bugzilla – Bug 25990
Sekundäre S4 Connectoren auf UCS@School Standort-Servern starten
Last modified: 2012-06-11 06:30:08 CEST
Um Selektive Replikation per OpenLDAP unabhängig von DRS zu ermöglichen, sollten auf UCS@School Standort-Servern sekundäre S4-Connectoren gestartet werden.
Created attachment 4134 [details] Patch für das Joinscript des S4 Connectors Der angehängte Patch ermöglicht die Installation weiterer S4-Connectoren: Durch setzen einer UCR-Variable lässt sich die Suche nach vorhandenen "S4 Connector"-Service LDAP-Einträgen deaktivieren.
Änderungen sind commited, Tests stehen noch aus.
Durch die Änderung funktioniert das Joinscript nicht mehr richtig, da es ohne die Kenntnis des ersten S4 Connector Hosts die Datei /etc/samba4.secret nicht kopiert und damit beim (erneuten) Anlegen des Benutzers ucs-s4sync interaktiv nach einem neuen Passwort fragt. Meiner Einschätzung nach ist dieser Account ein Relikt aus dem Preview-Release von UCS 3.0, inzwischen verwenden wir die LDAPI-Schnittstelle im S4 Connector, die keine Bind-Credentials erfordert. Dieser Account wird in der UCR-Variable connector/s4/ldap/binddn gesetzt und dadurch in univention-s4search. Wenn man Bug 24989 umsetzt, könnte man /etc/machine.secret und Samba-Account der lokalen Maschine für die Authentifikation in univention-s4search verwenden.
Bug #26197 wurde jetzt auch in UCS@school portiert. Dadurch wird der ucs-sync Benutzer nicht mehr benötigt.
Derzeit wird das Objekt objectClass=univentionDefault nicht auf die Slaves synchronisiert. Solange das Objekt nicht synchronisiert wird, können keine Benutzer über den Connector angelegt werden. Die Frage ist, ob der Connector grundsätzlich in den Modus write (nur Änderungen von LDAP nach S4) gesetzt werden soll. Problematisch ist, wenn der Benutzer einen Client oder einen Benutzer anlegt, dann kann das potentiell dazu führen, dass doppelte Benutzernamen oder UIDs auftauchen. Hier würde Bug #26383 helfen. Da Passwörter usw. synchronisiert werden sollen, könnte nur das Anlegen von Objekten über den Connector verhindert werden. Besser wäre es, wenn das dann direkt auf S4 Ebene deaktiviert wird.
Alternative: Für jeden S4 Slave DC wird ein Sync Account angelegt, der die Schreibrechte des Rechner Accounts hat und die Leserechte über das komplette LDAP hat. Dann würde das Anlegen von Konflikt Objetken im Master LDAP direkt verhindert.
(In reply to comment #6) > Alternative: Für jeden S4 Slave DC wird ein Sync Account angelegt, der die > Schreibrechte des Rechner Accounts hat und die Leserechte über das komplette > LDAP hat. Dann würde das Anlegen von Konflikt Objetken im Master LDAP direkt > verhindert. Das funktioniert nicht, da das UDM Objekt gegen den lokalen LDAP Server zusammengebaut wird.
(In reply to comment #5) > Derzeit wird das Objekt objectClass=univentionDefault nicht auf die Slaves > synchronisiert. Solange das Objekt nicht synchronisiert wird, können keine > Benutzer über den Connector angelegt werden. > > Die Frage ist, ob der Connector grundsätzlich in den Modus write (nur > Änderungen von LDAP nach S4) gesetzt werden soll. Problematisch ist, wenn der > Benutzer einen Client oder einen Benutzer anlegt, dann kann das potentiell dazu > führen, dass doppelte Benutzernamen oder UIDs auftauchen. Hier würde Bug #26383 > helfen. > > Da Passwörter usw. synchronisiert werden sollen, könnte nur das Anlegen von > Objekten über den Connector verhindert werden. Besser wäre es, wenn das dann > direkt auf S4 Ebene deaktiviert wird. Das ist jetzt ausgelagert an Bug #26509.
13.03.2012 12:12:20,385 LDAP (PROCESS): sync to ucs: [ user] [ modify] uid=ines12,cn=schueler,cn=users,ou=school1,dc=dedlock10,dc=local 13.03.2012 12:12:20,589 LDAP (ERROR ): failed in post_con_modify_functions 13.03.2012 12:12:20,590 LDAP (ERROR ): Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 1303, in sync_to_ucs f(self, property_type, object) File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 67, in object_memberships_sync_to_ucs return s4connector.object_memberships_sync_to_ucs(key, object) File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 1453, in object_memberships_sync_to_ucs self.one_group_member_sync_to_ucs( ucs_group_object, object ) File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 1481, in one_group_member_sync_to_ucs self.lo.lo.modify_s(ucs_group_object['dn'],compatible_modlist(ml)) File "/usr/lib/pymodules/python2.6/univention/uldap.py", line 517, in modify_s self.lo.modify_s(dn, 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) INSUFFICIENT_ACCESS: {'desc': 'Insufficient access'} Das Referral Handling ist in uldap implementiert. Hier wird direkt python-ldap verwendet.
(In reply to comment #9) > Das Referral Handling ist in uldap implementiert. Hier wird direkt python-ldap > verwendet. Der Connector hatte direkt eine Verbindung zum DC Master aufgebaut, da connector/ldap/server nicht gesetzt war.
Verified: * Sekundärer S4 Connector wird automatisch beim ucs-school-slave/univention-s4-connector Join gestartet * Neue UCR Variable connector/s4/allow/secondary wird im ucs-school-slave Joinscript auf yes gesetzt * Rejects aufgrund von Bug 26514 und Bug 26504 sind bekannt und werden in MS2 behoben. * Changelog OK
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"