Univention Bugzilla – Bug 41765
ucs-school-create_windows_computer picks a random school
Last modified: 2017-07-26 18:06:08 CEST
univention-ldb-modules/modules/univention_samaccountname_ldap_check.c calls ucs-school-create_windows_computer without specifying a school. The scripts makes a UMCP-connection to the DC master and calls selectiveudm/create_windows_computer. If the DC Slave which calls that program has more than one local school it selects the school/OU where to create the windows computer randomly. The C script have to set the school explicitly.
This is unlikely to happen in a multiserver environment as the school DC slaves are directly underneath of a OU there. In a singlemaster environment with multiple schools and a DC outside of an OU one random school is picked. In both multiserver/singleserver environments with multiple schools it currently always picks the school where the DC Slave object lies in. The technical problem is that the request to "selectiveudm/create_windows_computer" doesn't contain the school as parameter. The LDAP_Connection decorator then uses in this case the binddn of the LDAP connection as the hostname to select the school and create the SchoolSearchBase instance. If there is no OU in the binddn it just uses the first school of all found schools.
I don't know if we store a "primary OU" for single master systems in UCR. But there is the UCR variable dhcpd/ldap/base that defines the LDAP base for the DHCP daemon even on single master systems. The DHCP LDAP base is, if UCS@school is installed, usually below one specific OU. Suggestion: We could use the OU found in dhcpd/ldap/base, in conjunction with an override UCR variable (the override UCR variable should be unset by default). Since DHCP entries in other OUs are ignored, I think this would be a reasonable default.
Created attachment 7802 [details] patch Patch without touching the C code.
Created attachment 7803 [details] patch Alternative patch which touches the C code and reads the OU from a UCR variable. We need to create this variable then on each DC Slave/Singlemaster.
At least one customer encountered this problem.
Created attachment 7924 [details] patch We should get rid of the CLI tool "umc-command". It's better to use the univention-lib for this, as done in the patch. The package is somehow in UCS and in UCS@school. Why? Can we add dependencies to UCS@school packages?
(In reply to Florian Best from comment #6) > Created attachment 7924 [details] > patch > > We should get rid of the CLI tool "umc-command". It's better to use the > univention-lib for this, as done in the patch. > The package is somehow in UCS and in UCS@school. Why? Can we add > dependencies to UCS@school packages? Thanks, I've applied the patch. I've also re-enabled the test case 90_ucsschool/95_samba4_client_join_on_slave. Patch: r72193 (4.1-3) + r72194 (4.2-0) Test case: r72191 YAML: r72195
univention-ldb-modules does not depend on python-univention-lib directly but uses it. We should remove the directory dev/branches/ucs-4.1/ucs-school-4.1r2/univention-ldb-modules.
OK - ucs-school-create_windows_computer OK - test with two slaves and two windows clients, both joined in the correct school OK - ucs tests OK - yaml OK - merged to 4.2
<http://errata.software-univention.de/ucs/4.1/264.html>