Univention Bugzilla – Bug 48469
demoschool is created first, dhcp daemon start issues
Last modified: 2019-05-28 14:17:41 CEST
Created attachment 9802 [details] listener.log including school setup UCS 4.3 with ucsschool=4.3 v6, i installed a single school setup. My schoolname starts with 'g', which in lexicographical order is higher than 'demoschool'. Symptom: The dhcpd does not start, /v/l/daemon.log says "Not configured to listen on any interfaces!" After some debugging i found that the dhcp server object was created in ou=demoschool, and not in the school i setup in the school installation wizard. In the attached listener.log one can see that the object cn=ucs-9540,cn=demoschool,cn=dhcp,ou=DEMOSCHOOL is added in the demoschool. The schoolou i provided during the installation is created later, and no dhcp server is created in that ou. To fix this i had to delete and recreate the dhcp server object in the correct OU and fix UCR dhcpd/ldap/base
(In reply to Erik Damrose from comment #0) > To fix this i had to delete and recreate the dhcp server object in the > correct OU and fix UCR dhcpd/ldap/base IIRC the UCRV dhcpd/ldap/base is always set to the first school OU created in LDAP. This was done in the old old old original create_ou script. I don't know, if this has been also transferred to the UCS@school lib.
TODO: Add kwargs to schoollib to prevent change of dhcpd/ldap/base to demoschool Repairing: Check if dhcpd/ldap/base is set to demoschool and set to real ou Move/recreate dhcp server in real ou
I just tested it again. The assumption that the lexicograpical order matters is wrong. My testschool is abcd, and the dhcp server object was still created in the demoschool
Really exciting to fix this in a customer environment. Even the subnet with all policies had to be moved
okay, we have now some issues with the policies. I have recommended the customer to reinstall the system and not to install the demoschool
Got Feedback from a user. He really struggled with the DHCP configuration on the first own school. He only fixed it with a snapshot from a point before installing UCS@school. -- die UCR-Variable heißt: ucsschool/join/create_demo Diese setzen Sie am besten unter System -> Univention Configuration Registry -> HINZUFÜGEN -> ucsschool/join/create_demo & no -> SPEICHERN Bitte *vor* der Installation von UCS@school setzen. Ich hoffe das hilft mit der DHCP-Problematik. -- Therefore I raise the User Pain to "3: Will affect average number of installed (UCS@school) domains"
I added a flag to the create_ou script (--not-alter-dhcpd-base) that omits the modification of the UCRV dhcpd/ldap/base on the ucsschool.lib level in singleserver environments, if set. This flag is set during the creation of the demoschool. It can be tested with the Repo: deb [trusted=yes] http://10.200.18.180/debian/ oschwieg4.448469 main The naming of the variable/flag is not very elegant and proposals are very welcome. If the changes are deemed sufficient for the merge into 4.4 please reopen the issue.
Could you change the variable name "not_alter_dhcpd" in ucs-school-import/modules/ucsschool/lib/create_ou.py to "not_alter_dhcpd_base"? I would prefer the variable (and logic) to be changed to "alter_dhcpd_base" to avoid "not not_..." code. A suggestion: juern/bug48469 I'm not sure about the command-line flag. Using "--alter-dhcpd-base={true,false,auto}" would make it possible to force the change of the base as well as preventing it, that might be useful for some future scripts.
Please also add a test which checks that all dhcp objects (including policies) are at the right position after creating two OUs then the first one didn't alter the dhcpd search base.
Package: ucs-school-lib Version: 12.1.1-1A~4.4.0.201904011400 Branch: ucs_4.4-0 Scope: ucs-school-4.4 Package: ucs-school-import Version: 17.0.6-1A~4.4.0.201904011401 Branch: ucs_4.4-0 Scope: ucs-school-4.4 Package: ucs-school-metapackage Version: 12.0.1-1A~4.4.0.201904011404 Branch: ucs_4.4-0 Scope: ucs-school-4.4 Package: ucs-test-ucsschool Version: 6.0.0-39A~4.4.0.201904011406 Branch: ucs_4.4-0 Scope: ucs-school-4.4 The option was reworked as alter-dhcpd-base and can be set to auto, true or false. Auto: Behavior ist just like before True: Override dhcpd/ldap/base False: Do not modify dhcpd/ldap/base This changes should only affect singleserver environments. The test 30_import-create_ou_alter_dhcpd_base was added to check this behavior.
The behaviour for "auto" doesn't seem to be implemented? I would have expected something like: "if alter_dhcpd_base is None: alter_dhcpd_base = not ucr.get('dhcpd/ldap/base')" The test doesn't seem to test the auto option for unset dhcpd/ldap/base either. Or am I missing something? :) Also the description for the command line flag is missing a space "environments.The" Other wise it looks good
Shame on me -- I just skipped the handling of the auto option. This error has been fixed as well as the typo and test coverage. Package: ucs-test-ucsschool Version: 6.0.0-40A~4.4.0.201904020856 Branch: ucs_4.4-0 Scope: ucs-school-4.4 Package: ucs-school-import Version: 17.0.6-2A~4.4.0.201904020858 Branch: ucs_4.4-0 Scope: ucs-school-4.4 Package: ucs-school-lib Version: 12.1.1-2A~4.4.0.201904020901 Branch: ucs_4.4-0 Scope: ucs-school-4.4
Looks good to me: Test is green -> OK dhcpd/ldap/base is set to the "real" school after installation -> OK dhcd server starts -> OK YAML -> OK
UCS@school 4.4 v2 has been released. https://docs.software-univention.de/changelog-ucsschool-4.4v2-de.html If this error occurs again, please clone this bug.