Univention Bugzilla – Bug 27027
Samba 4 Migration
Last modified: 2023-03-25 06:54:29 CET
Derzeit fehlt eine Dokumentation, wie eine UCS@school Samba 3 Domäne auf UCS@school Samba 4 aktualisiert werden kann.
Vorschlag für die URL: * http://wiki.univention.de/index.php?title=Update_to_UCS@school_3.0_Samba_4 Die Seite kann dann in die allgemeine Seite verlinkt werden, Vorschlag: http://wiki.univention.de/index.php?title=UCS@school_3.0_Services_for_Windows#Migration_from_UCS.40school_3.0_Samba_3_to_Samba_4
Eine erste Version ist jetzt online aber noch nirgendwo verlinkt und mit einer starken Warnung versehen, dass dies noch work in progress ist.
Voraussetzung für die Migration sind die beiden kommenden errata Updates, deren Advisories schon als * ucsschool-2012-06-07-univention-samba4.yaml (QA für Bug #27512 steht noch aus) * ucsschool-2012-06-07-univention-s4-connector.yaml abgelegt sind.
Test gemäß Anleitung war erfolgreich (zwei Slaves, ein Master). Bug 27548 ist dabei aufgefallen.
Auf einem aktualisierten UCS 2.4 Schul-DC tritt der folgende Traceback auf: S4 rejected 1: S4 DN: CN=Information,CN=Virtual Machine Manager,DC=deadlock174,DC=local UCS DN: cn=information,cn=virtual machine manager,dc=deadlock174,dc=local 2: S4 DN: CN=Virtual Machine Manager,DC=deadlock174,DC=local UCS DN: cn=virtual machine manager,dc=deadlock174,dc=local 19.06.2012 12:51:10,328 LDAP (ERROR ): Unknown Exception during sync_to_ucs 19.06.2012 12:51:10,328 LDAP (ERROR ): Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 1284, 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 1160, 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 332, in create return self._create() File "/usr/lib/pymodules/python2.6/univention/admin/handlers/__init__.py", line 701, in _create self.lo.add(self.dn, al) File "/usr/lib/pymodules/python2.6/univention/admin/uldap.py", line 358, in add raise univention.admin.uexceptions.objectExists, dn objectExists: cn=Virtual Machine Manager,dc=deadlock174,dc=local 19.06.2012 12:51:23,63 LDAP (PROCESS): sync to ucs: [ container] [ add] cn= information,cn=virtual machine manager,dc=deadlock174,dc=local 19.06.2012 12:51:23,80 LDAP (ERROR ): Unknown Exception during sync_to_ucs 19.06.2012 12:51:23,81 LDAP (ERROR ): Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 1284, in sync_t o_ucs result = self.add_in_ucs(property_type, object, module, position) File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 1160, 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 332, in crea te return self._create() File "/usr/lib/pymodules/python2.6/univention/admin/handlers/__init__.py", line 701, in _cre ate self.lo.add(self.dn, al) File "/usr/lib/pymodules/python2.6/univention/admin/uldap.py", line 358, in add raise univention.admin.uexceptions.objectExists, dn objectExists: cn=Information,cn=virtual machine manager,dc=deadlock174,dc=local Ursache ist, dass der Container seit UCS 3.0 von dem Slave gelesen werden kann. Durch die Initialisierung des Listener-Moduls s4-connector liest der Listener einmal alle LDAP Einträge vom Master und übergibt diese an den Connector. Der Connector legt das Objekt im S4 an und versucht dann das Objekt im Slave LDAP anzulegen. Der Slave bekommt einen LDAP Referral und versucht das Objekt auf dem Master anzulegen. Dort gibt es das Objekt aber bereits. Ganz einfacher Workaround ist die Beschreibung zu ändern: eval "$(ucr shell)" udm container/cn modify --dn \ "cn=Information,cn=Virtual Machine Manager,$ldap_base" \ --set description=Test1 udm container/cn modify --dn \ "cn=Information,cn=Virtual Machine Manager,$ldap_base" \ --remove description=Test1
(In reply to comment #5) > Auf einem aktualisierten UCS 2.4 Schul-DC tritt der folgende Traceback auf: > > S4 rejected > > 1: S4 DN: CN=Information,CN=Virtual Machine > Manager,DC=deadlock174,DC=local > UCS DN: cn=information,cn=virtual machine > manager,dc=deadlock174,dc=local > 2: S4 DN: CN=Virtual Machine Manager,DC=deadlock174,DC=local > UCS DN: cn=virtual machine manager,dc=deadlock174,dc=local > > 19.06.2012 12:51:10,328 LDAP (ERROR ): Unknown Exception during > sync_to_ucs > 19.06.2012 12:51:10,328 LDAP (ERROR ): Traceback (most recent call > last): > File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line > 1284, 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 > 1160, 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 332, in create > return self._create() > File "/usr/lib/pymodules/python2.6/univention/admin/handlers/__init__.py", > line 701, in _create > self.lo.add(self.dn, al) > File "/usr/lib/pymodules/python2.6/univention/admin/uldap.py", line 358, in > add > raise univention.admin.uexceptions.objectExists, dn > objectExists: cn=Virtual Machine Manager,dc=deadlock174,dc=local > > 19.06.2012 12:51:23,63 LDAP (PROCESS): sync to ucs: [ container] [ > add] cn= > information,cn=virtual machine manager,dc=deadlock174,dc=local > 19.06.2012 12:51:23,80 LDAP (ERROR ): Unknown Exception during > sync_to_ucs > 19.06.2012 12:51:23,81 LDAP (ERROR ): Traceback (most recent call > last): > File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line > 1284, in sync_t > o_ucs > result = self.add_in_ucs(property_type, object, module, position) > File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line > 1160, 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 332, in crea > te > return self._create() > File "/usr/lib/pymodules/python2.6/univention/admin/handlers/__init__.py", > line 701, in _cre > ate > self.lo.add(self.dn, al) > File "/usr/lib/pymodules/python2.6/univention/admin/uldap.py", line 358, in > add > raise univention.admin.uexceptions.objectExists, dn > objectExists: cn=Information,cn=virtual machine manager,dc=deadlock174,dc=local > > > Ursache ist, dass der Container seit UCS 3.0 von dem Slave gelesen werden kann. > Durch die Initialisierung des Listener-Moduls s4-connector liest der Listener > einmal alle LDAP Einträge vom Master und übergibt diese an den Connector. > > Der Connector legt das Objekt im S4 an und versucht dann das Objekt im Slave > LDAP anzulegen. Der Slave bekommt einen LDAP Referral und versucht das Objekt > auf dem Master anzulegen. > > Dort gibt es das Objekt aber bereits. > > Ganz einfacher Workaround ist die Beschreibung zu ändern: > eval "$(ucr shell)" > udm container/cn modify --dn \ > "cn=Information,cn=Virtual Machine Manager,$ldap_base" \ > --set description=Test1 > udm container/cn modify --dn \ > "cn=Information,cn=Virtual Machine Manager,$ldap_base" \ > --remove description=Test1 Das ist ausgelagert an Bug #27626.
Wenn ich nur eine Schule umgestellt habe, dann funktioniert die Anmeldung für neue Benutzer am XP Client nicht. Ursache ist vermutlich, dass die DNS SRV Records noch alle DCs zurück liefern.
> If the UCS Master does not offer Samba 3 DC services, a Samba 3 DC of the UCS > server role Backup should be selected instead. Eigentlich ist es doch egal welche Systemrolle das System hat. Wichtig ist, dass alle UCS Systeme mit Samba 4 in der Zentrale umgestellt werden müssen. Am sinnvollsten in dieser Reihenfolge: Master, Backup, Slave, Member. Restliche Kommentare im Ausdruck.
Bisherige kommentare sind eingearbeitet.
Beim Update des Backups auf Samba 4 wird das Objekt gelöscht und neu angelegt. Dadurch bekommt der Backup im S4 eine neue SID, allerdings wird diese SID nicht ins UCS LDAP übertragen. Später wird dann die SID vom UCS ins S4 synchronisiert, allerdings liegt die SID dann noch unter Deleted Objects: https://forge.univention.org/bugzilla/show_bug.cgi?id=26647
Created attachment 4523 [details] Upstream dcpromo Patch, angepasst auf die aktuelle UCS Codebasis Upstream wurde jetzt der Code so angepasst, dass 1. "samba-tool domain classicupgrade" BDCs in Memberserver umwandelt 2. "samba-tool domain dcpromo" aufgerufen werden muss, um einen Memberserver in einen DC hochzustufen (unter Beibehaltung seiner SID). https://git.samba.org/?p=samba.git;a=commitdiff;h=1c86ab9c5056c457a40dc4c8e3b39c9b940c077b Der auf unsere aktuelle Codebasis angepasste Patch hängt an. Das Problem bei diesem Ansatz ist, dass wir aktuell nicht den Domänen-Zustand "samba3upgrade" z.B. über das LDAP für die anderen DCs erkennbar machen, sodass diese nicht im joinscript entsprechend von "join" auf "dcpromo" umschalten können. Man lernt andererseits an dem Patch, dass es der Client (DC) selbst ist, der sein Objekt beim normalen Join löscht.
Created attachment 4524 [details] promote_existing_option_for_domain_join.patch Angehängt ein Vorschlag für eine entsprechend auf dem upstream Patch aufbauende Erweiterung von "domain join" durch eine Option --promote-existing.
Created attachment 4525 [details] keep_existing_option_for_domain_join.patch Angepasster Patch als Ersatz für Comment 12: Option --keep-existing für "samba-tool domain join $ucsdomain DC". Die Option wird für MEMBER ignoriert. Wenn das DC-Objekt nicht existiert, wird normal gejoined, sonst wird der "promote_existing" Code aktiviert.
Das univention-samba4 Joinscript verwendet jetzt die neue Option --keep-existing und im Test hat das auch funktioniert. Changelog ucs3.0-2 ist angepasst.
Die Anpassungen ab Comment 10 sind jetzt für ucs3.0-2 als Bug 27886 ausgelagert.
Die Anleitung kann aus meiner Sicht aktiviert werden, sobald das errata Update für Bug #27395 raus ist.
ucsschool-errata6 ist veröffentlicht und die Warnhinweise in dem Update-Leitfaden wurden entfernt.
OK