Univention Bugzilla – Bug 27626
.*,CN=Virtual Machine neu replizieren
Last modified: 2012-11-09 16:04:20 CET
In UCS@school 3.0 wurden die LDAP ACLs so angepasst, dass der Container cn=Virtual Machine auf die Slaves repliziert werden darf. Beim Update werden die Container allerdings nicht automatisch neu repliziert, weshalb diese auf dem Slave nicht verfügbar sind. Im postup.sh von UCS@school sollte der Teilbaum in die transaction aufgenommen werden, so dass die Einträge repliziert werden. (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
Im Paket ucs-school-ldap-acls-master_7.0.6-1.39.201206211042 aus ucsschool-errata werden nun im postinst auf master und backup bei diesem Update alle Objekt in/unterhalb von cn=Virtual Machine Manager,ldap/base modifiziert (cn wird auch auf den Wert aus cn gesetzt). Dies wird gemacht, nachdem der Master die neuen LDAP ACLS eingespielt und aktiviert hat. Slaves bekommen diese Änderung mit und können sie dann replizieren. Nachdem ein ucs@school Master auf 3.0 + errata Update aktualisiert wurde, sollten die Ausgabe für folgenden Befehl auf dem Master und den (2.4) Slaves gleich sein. -> ldapsearch -x -h localhost -LLL \ -b "cn=Virtual Machine Manager,$(ucr get ldap/base)" dn| ldapsearch-wrapper YAML Datei erstellt.
Das sollte zusammen mit Bug #27933 veröffentlicht werden.
Die Bugs #27626 und #27933 wurden in einem errata Update für ucs-school-ldap-acls-master gefixt und können am besten zusammen qaed werden.
Soweit ich das jetzt verstehe sollte 1. UCS@school Master+Slave Domäne aufgesetzt werden 2. Auf einen UCS@school 2.4 Master UVMM installiert werden 3. Master auf UCS@school 3.0 aktualisiert werden 4. Das Errata-Paket eingespielt werden. Bei mir im Test hatte ich hingegen 1. UCS@school Master+Slave Domäne aufgesetzt 2. Master auf UCS@school 3.0 aktualisiert, dabei wurde UVMM mit installiert 3. Waren dann die Container schon direkt für den Slave lesbar sodass dieser sie direkt korrekt repliziert hat. Zum Test habe ich jetzt in diesem Zustand temporär auf dem Master die neue ACL in 65ucsschool herausgenommen, slapd neu gestartet, unter dem Container "cn=Virtual Machine Manager" ein Objekt mit univentionVirtualMachineUUID=111-222-333 angelegt und dann die ACL wieder aktivert und den slapd neu gestartet. Danach habe ich das Errata-Paket installiert. Danach wurde das univentionVirtualMachineUUID Objekt nicht repliziert, vermutlich weil das Objekt kein Attribut cn hat. Wenn ich das richtig verstehe, dann sollten auch diese Objekte repliziert werden? Das Objekt auf dem Master ist jedenfalls für den Slave lesbar: slave32:~# ldapsearch -x -D $ldap_hostdn -w $(cat /etc/machine.secret) \ -h master30.$(dnsdomainname) -p 7389 univentionVirtualMachineUUID=111-222-333
Es wird jetzt ein uldap.rename auf die Objekte cn=mail.* und cn=Virtual Machine Manager.* gemacht. Irgendwelche modrdn Probleme sind nicht zu erwarten, da * sich auf dem Master nichts ändert (listener hat noch ein altes Objekt und das neue ist gleich) * die Objekte auf Slaves ja eh noch nicht da sind
Verified: * UCS 2.4 Master+Slave gejoined * Auf Master univention-virtual-machine-manager-daemon installiert * UCS@school 2.4 installiert gejoined * cn="virtual machine manager" ist nicht auf dem Slave * Auf Master univentionVirtualMachineUUID angelegt * Master auf UCS@school 3.0 upgedated * errata eingespielt * univentionVirtualMachineUUID ist mit den anderen Objekte repliziert. * Advisory OK
http://errata.univention.de/ucsschool-errata9.html