Univention Bugzilla – Bug 32585
create DHCP subnets and hosts in a subcontainer of the DHCP service
Last modified: 2018-04-13 13:40:03 CEST
In environments with several IP-subnets administrators are often confused about the mix of UDM policy results and the evaluation order of the DHCP server. Example: One has 10 subnets where in 8 of them the same DNS server settings should be applied and 2 should use different settings. Usually, administrators try to attach the default DHCP DNS policy targeting the 8 subnets to the domain root (which is created by default during UCS installation there) and overwrite it with a policy attached to the two subnets. But the evaluation order of the DHCP server is different: it resolves first the settings of the Host Object of queriing client, where the default policy takes effect. Settings at the subnet are not checked further on. In contrast: if an unknown client in the same subnet gets an IP from a pool, the setting of the subnet applies. So two clients in the same subnet get different DNS serves. A workaround for this is to create subcontainers in the LDAP tree of the DHCP service, at least one for subnets, and store the LDAP objects for hosts and subnets separated. The default policy can then be attached to the subnet container and will not affect host objects any more. In current UCS releases the workaround already works for subnets, but would be a source of administrative tasks and possible failures: Each join of a UCS system (and also UCC?) creates its subnet at the products default position. Using the workaround, one would have two subnet objects in his DHCP service -- with unknown effects. Requested i.e. by 2013081421086439
The problem here is that DHCPd has a built-in inheritance mechanism which badly matches with the UCS policy mechanism, which is blindly applied to all levels of the DHCP hierarchy. "host" are on the same level as "(shared) subnets" in the DHCPd configuration and are both children of the "service" entry. So a UMC policy applied to the service also gets applied to all hosts by default. This can be worked-around by adding "univentionDhcpHost" to the list of "prohibited object classes": # udm policies/dhcp_dns list DN: cn=default-settings,cn=dns,cn=dhcp,cn=policies,dc=phahn,dc=pt name: default-settings domain_name_servers: 10.200.17.40 domain_name_servers: 10.0.17.40 domain_name_servers: 10.0.17.45 domain_name: phahn.pt prohibitedObjectClasses: univentionDhcpHost # diff /tmp/dhcp-ldap-startup.log /var/log/dhcp-ldap-startup.log 89,90d88 < option domain-name "phahn.pt"; < option domain-name-servers 10.200.17.40, 10.0.17.40, 10.0.17.45; 105,106d102 < option domain-name "phahn.pt"; < option domain-name-servers 10.200.17.40, 10.0.17.40, 10.0.17.45;
requested by further customer 2013110721002704
Creating a CN-container below dhcp/service works only to some degree, as the UMC computers module only directly lists the dhcp/services and not the containers therein. Hosts can only be added into Sub-containers through the CLI interface and show up as empty lines in UMC afterwards.
Are there customers which use this invalid/broken workaround suggestion from Comment #0:? > A workaround for this is to create subcontainers in the LDAP tree of the DHCP > service, at least one for subnets, and store the LDAP objects for hosts and > subnets separated. The default policy can then be attached to the subnet > container and will not affect host objects any more.
With Bug #36255 fixed policies can be configured to *not* apply to DHCP hosts. As such the workaround with containers is not needed anymore. This is also documented at <http://docs.software-univention.de/manual-4.1.html#networks::dhcp::policies>
1. host in subnets are wrong 2. policies can be restricted to not apply to hosts 3. UMC-DHCP has been improved; e.g. Bug #43048 is fixed, so hosts/subnets can be created/used in containers if that is needed.