Univention Bugzilla – Bug 45170
Searching for the domain controller master in the system setup returns incorrect results
Last modified: 2017-11-22 16:30:27 CET
During an installation in the system setup the searching for the domain controller master provides incorrect and incomprehensible results. The environment has an external non-UCS DNS Server. The SRV Record _domaincontroller_master._tcp."ldap_base" is set correct to the master. Also the FQDN of the DNS Server provide the correct domain part. But the system setup only set the FQDN of the first DNS server which is configured during the system setup as the proposed domain controller master. There should be a dns lookup of the SRV _domaincontroller_master._tcp."ldap_base" (use function is_ucs_domain from univention-system-setup/umc/python/setup/util.py) Reproducible intern with antilop as DNS server in the system setup of an UCS Backup/Slave or Member.
Instead of the FQDN of the nameserver the FQDN of the _domaincontroller_master._tcp.$domainname SRV system is now used. univention-system-setup (10.0.10-43) 9eda8bd43f05 | Bug #45170: fix name of DC Master if the nameserver is not the DC Master itself univention-systen-setup.yaml 2fd1226363c3 | Bug #43745: Merge branch 'fbest/45253-42918-43683-45170-43745-45246-ad-member-mode-join' into 4.2-2
(In reply to Florian Best from comment #1) > Instead of the FQDN of the nameserver the FQDN of the > _domaincontroller_master._tcp.$domainname SRV system is now used. Would it be possible to check for the DNS record, and if that is not available, use the nameserver1 like it was before the change? I do not have a specific scenario at hand, but i can imagine the change could lead to regressions
(In reply to Erik Damrose from comment #2) > (In reply to Florian Best from comment #1) > > Instead of the FQDN of the nameserver the FQDN of the > > _domaincontroller_master._tcp.$domainname SRV system is now used. > > Would it be possible to check for the DNS record, and if that is not > available, use the nameserver1 like it was before the change? I do not have > a specific scenario at hand, but i can imagine the change could lead to > regressions The diff of the changes is: -» » » fqdn = util.get_fqdn(nameserver) +» » » domain = util.get_ucs_domain(nameserver) +» » » if domain: +» » » » fqdn = util.resolve_domaincontroller_master_srv_record(nameserver, domain) +» » » else: +» » » » fqdn = util.get_fqdn(nameserver) » » » if fqdn: » » » » result['dc_name'] = fqdn I could only imagine to change on top of that: +» » » fqdn = None » » » domain = util.get_ucs_domain(nameserver) » » » if domain: » » » » fqdn = util.resolve_domaincontroller_master_srv_record(nameserver, domain) -» » » else: +» » » if not fqdn: » » » » fqdn = util.get_fqdn(nameserver) » » » if fqdn: » » » » result['dc_name'] = fqdn But I don't really think it's better / more correct. It would find a fqdn of a non UCS server.
OK - external non master UCS master with domaincontroller record as DNS server => finds the UCS master OK - UCS master as DNS server => finds the master OK - Non UCS system without domaincontroller record as DNS server => network settings warning OK - code review OK - YAML
<http://errata.software-univention.de/ucs/4.2/227.html>