Univention Bugzilla – Bug 34166
UCS@school installer should support dc slaves in administration (VerwaltungsDC)
Last modified: 2014-06-12 09:20:51 CEST
Currently there is no way to configure UCS@school on a administration slave (VerwaltungsDC). The UMC installer module should support those systems and let the user choose between an educational dc slave an and administration dc slave and install the corresponding UCS@school meta package.
Frontend changes: Two new pages have been added to the UCS@school installer: "server_type" and "administrativesetup". On the page "server_type" the user has to choose between "educational server" and "administrative server" as server type. The page "administrativesetup" is optional. For detailed function of those pages have a look at bug 34823. The code for starting the installation has been moved into the new function "_start_installation". Backend changes: If defined, the name of the administrative slave is now also passed to the UMCP command "schoolwizards/schools/create". The code for retrieving information about the specified OU has been moved to the functions get_schoolinfo and _get_schoolinfo. The first one is available as UMCP command schoolinstaller/get/schoolinfo and returns the OU name, existence of the given OU, class/home share servers, lists of educational/administrative slaves. If an administrative slave is to be installed, the name of the educational slave has also to be specified (it will be created automatically, otherwise there will be problems with the class/home share server information). The educational slave install the meta package ucs-school-slave and the administrative slave the meta package ucs-school-nonedu-slave. Changelogentry has been committed. QA: Please try to install: - Singlemaster - Multiserver environment with 1 educational slave - Multiserver environment with 1 administrative slave - Multiserver environment with 1 educational and then 1 administrative slave - Multiserver environment with 1 administrative and then 1 educational slave
Failed to setup a new school "grundschule2" with hostname slave202 as admin slave and (a yet to be created) slave203 as edu slave. "grundschule1" already exists with an existing slave201 as edu slave. I got an error message, (note that the error message is not localized - another bug): Validating the LDAP school OU structure failed. It seems that the current slave system has already been assigned to a different school or that the specified school OU name is already in use. After this failure, a quick look at UDM reveils: slave203 is already created (correct position, group memberships) slave202 already has OUgrundschule2-DC-Verwaltungsnet group, still in cn=dc,cn=computers,$ldap_base
From the logs: ERROR: cannot move domaincontroller slave with hostname "slave202" to OU "grundschule2" ERROR: The system has no LDAP access to the OU So this may be a bug in ucs-import
Reason: The slave needs to be member of the Edu group...
Is it correct that you can choose to be the admin slave if ucr.is_false('ucsschool/ldap/noneducational/create/objects')?
(In reply to Dirk Wiesenthal from comment #5) > Is it correct that you can choose to be the admin slave if > ucr.is_false('ucsschool/ldap/noneducational/create/objects')? The UCR variable only controls which default server objects will be created during OU creation.
(In reply to Dirk Wiesenthal from comment #3) > ERROR: cannot move domaincontroller slave with hostname "slave202" to OU > "grundschule2" > ERROR: The system has no LDAP access to the OU > > So this may be a bug in ucs-import Correct. move_domaincontroller_to_ou now also accepts the group membership "OU%(ou)s-DC-Verwaltungsnetz". ucs-school-import (10.0.16-1) unstable; urgency=low
(In reply to Sönke Schwardt-Krummrich from comment #7) > (In reply to Dirk Wiesenthal from comment #3) > > ERROR: cannot move domaincontroller slave with hostname "slave202" to OU > > "grundschule2" > > ERROR: The system has no LDAP access to the OU > > > > So this may be a bug in ucs-import > > Correct. move_domaincontroller_to_ou now also accepts the group membership > "OU%(ou)s-DC-Verwaltungsnetz". The installer also passed a FQDN instead of a hostname to the UMCP command/ucsschool lib which caused also problems while installing an administrative slave via the UCS@school installer. This has been fixed.
1. Configuring DC Slave as Admin Server for "ou=02grundschule,ou=02" 2. Opening UCS@school installer again -> Can be configured once again: Is this correct? 3. Configuring this DC Slave as Admin Server once again for "ou=02grundschule,ou=02" -> Traceback Die Ausführung des Kommandos schoolinstaller/get/schoolinfo ist fehlgeschlagen: Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/management/console/modules/__init__.py", line 204, in execute func( request ) File "/usr/lib/pymodules/python2.6/univention/management/console/modules/decorators.py", line 178, in _response return function(self, request) File "/usr/lib/pymodules/python2.6/univention/management/console/modules/schoolinstaller/__init__.py", line 514, in get_schoolinfo result = self._get_schoolinfo(username, password, master, schoolOU) File "/usr/lib/pymodules/python2.6/univention/management/console/modules/schoolinstaller/__init__.py", line 558, in _get_schoolinfo slaves = udm_modules.lookup('computers/domaincontroller_slave', None, lo, base=searchBase.computers, scope='sub') File "/usr/lib/pymodules/python2.6/univention/admin/modules.py", line 801, in lookup tmpres=module.lookup(co, lo, filter, base=base, superordinate=superordinate, scope=scope, unique=unique, required=required, timeout=timeout, sizelimit=sizelimit) File "/usr/lib/pymodules/python2.6/univention/admin/handlers/computers/domaincontroller_slave.py", line 740, in lookup for dn, attrs in lo.search(unicode(filter), base, scope, [], unique, required, timeout, sizelimit): File "/usr/lib/pymodules/python2.6/univention/admin/uldap.py", line 347, in search raise univention.admin.uexceptions.noObject, _err2str(msg) noObject: No such object
Does is make sense to ask for the school display name of a "Verwaltungs"-Server? (The school have to exists before, right?)
There is a warning on the last page of the installer: The name of the educational server may not be equal to the administrative server! I tested it. Works like a charm. Why is there this warning?
(In reply to Florian Best from comment #10) > Does is make sense to ask for the school display name of a > "Verwaltungs"-Server? (The school have to exists before, right?) The school does not have to exist. You may also install an administrative slave for a new OU. So the installation order may be - edu slave → administrative slave or - administrative slave → edu slave So it makes sense in those cases where the OU does not exist and should also work in those cases where the OU has already been created. Ideally the installer would let the user choose between the following actions: 1) to enter the name of a new school OU 2) to select an existing school OU But I think this does not make the installer simplier.
(In reply to Dirk Wiesenthal from comment #9) > 1. Configuring DC Slave as Admin Server for "ou=02grundschule,ou=02" > 2. Opening UCS@school installer again > -> Can be configured once again: Is this correct? > 3. Configuring this DC Slave as Admin Server once again for > "ou=02grundschule,ou=02" > -> Traceback > > Die Ausführung des Kommandos schoolinstaller/get/schoolinfo ist > fehlgeschlagen: This traceback may only occur if the OU exists in LDAP but the computers container does not. Was the installation running in the first opened installer tab while starting configuration in the second tab? Or has the reconfiguration started after the installation was successful?
(In reply to Dirk Wiesenthal from comment #11) > There is a warning on the last page of the installer: > The name of the educational server may not be equal to the administrative > server! > > I tested it. Works like a charm. Why is there this warning? It's against the concept and may introduce problems later on. I will add a check to the installer.
(In reply to Sönke Schwardt-Krummrich from comment #13) > (In reply to Dirk Wiesenthal from comment #9) > > 1. Configuring DC Slave as Admin Server for "ou=02grundschule,ou=02" > > 2. Opening UCS@school installer again > > -> Can be configured once again: Is this correct? No, this was a bug. The installed package ucs-school-nonedu-slave has not been detected → FIXED > > 3. Configuring this DC Slave as Admin Server once again for > > "ou=02grundschule,ou=02" > > -> Traceback > > > > Die Ausführung des Kommandos schoolinstaller/get/schoolinfo ist > > fehlgeschlagen: > > This traceback may only occur if the OU exists in LDAP but the computers > container does not. Was the installation running in the first opened > installer tab while starting configuration in the second tab? > Or has the reconfiguration started after the installation was successful? The exception is now being fetched and a warning printed to the logfile. Additionally bug 34837 tries to prevent running the UCS@school installer twice.
(In reply to Sönke Schwardt-Krummrich from comment #13) > > Die Ausführung des Kommandos schoolinstaller/get/schoolinfo ist > > fehlgeschlagen: > > This traceback may only occur if the OU exists in LDAP but the computers > container does not. Was the installation running in the first opened > installer tab while starting configuration in the second tab? > Or has the reconfiguration started after the installation was successful? Yes, it was. But district mode was only enabled on the master. So the DN of the OU was wrong on the slave system. Another check does not hurt, though.
Ok, works, changelog exists: VERIFIED Opened Bug#34913, Bug#34914, Bug#34915
UCS@school 3.2 R2 has been released: http://docs.univention.de/release-notes-ucsschool-3.2R2-de.html If this error occurs again, please use "Clone This Bug".