62ucs-school-slave.inst adds the nameserver to all found DHCP DNS policies: > for oudn in $(univention-ldapsearch -xLLL -b "$ldap_base" 'objectClass=ucsschoolOrganizationalUnit' dn | ldapsearch-wrapper | sed -nre 's/^dn: //p') ; do > ouname="$(echo "$oudn" | sed -nre 's/ou=([^,]*),(ou=|dc=).*/\1/p')" > [...] > # modify dhcp dns policy if missing > udm policies/dhcp_dns modify "$@" \ > --dn "cn=dhcp-dns-${ouname},cn=policies,$oudn" \ > --set domain_name_servers="$(get_default_ip_address)" > # assign dhcp dns policy to dhcp container if missing > udm container/cn modify "$@" \ > --dn "cn=dhcp,$oudn" \ > --policy-reference "cn=dhcp-dns-${ouname},cn=policies,$oudn" > done Problem: If (for some reason, e.g. Bug 40123) the LDAP ACLs are not present on the Master/Backup, the Slave will replicate more than its own OU. In this case, running the joinscript will modify _all_ DHCP DNS policies. This sets the nameserver of one OU also as the nameserver on the policies of all other OUs and breaks DNS there. Possible solution: univention-ldapsearch should not use '-b "$ldap_base"' but something like '-b ou=$OU,"$ldap_base"' to only show the policies of its own OU in every case. Not sure about Single-Server environments with more than one OU, though ...
2016010421000341
Is it still relevant? We are now distributing the LDAP ACLs via LDAP?
> Not sure about Single-Server environments with more than one OU, though ... The DHCP service on UCS@school slaves uses the DHCP container within the OU subtree. The DHCP DNS policies are also attached to that OU-specific DHCP container. In single server environments, the same applies. But the DHCP server on the DC master uses the DHCP container of the first school OU that has been created. Since the policy defines the DC master as DNS server, there should be no problem in that scenario. (In reply to Stefan Gohmann from comment #2) > Is it still relevant? We are now distributing the LDAP ACLs via LDAP? Should be no longer relevant since bugs 40123 and 40124 are closed and LDAP ACLs are registered in LDAP → WORKSFORME @Michael: please reopen, if still relevant.