Univention Bugzilla – Bug 48134
Initial Join in the system-setup fails because the specified server is not used.
Last modified: 2019-03-27 13:29:24 CET
A customer cannot join during the initial setup. The dcname seems not to be passed with anymore. Wed Nov 7 12:08:27 CET 2018: starting /usr/sbin/univention-join -dcname ucs-master01.schein.ig -dcaccount cschein -dcpwd /var/cache/univention-system-setup/secret -checkPrerequisites running version check OK: UCS version on master01.schein.ig is higher or equal (4.32) to the local version (4.32). Wed Nov 7 12:08:36 CET 2018: finish /usr/sbin/univention-join Wed Nov 7 12:13:47 CET 2018: starting /usr/share/univention-join/univention-join -dcaccount cschein -dcpwd /tmp/tmp.f4H62WHAiV ************************************************************************** * Join failed! * * Contact your system administrator * ************************************************************************** * Message: Please visit https://help.univention.com/t/8842 for common problems during the join and how to fix them -- The UCS master server "master02.schein.ig" is not reachable, ping failed (ping ipv4: PING master02.schein.ig (xxx.x.x.xx) 56(84) bytes of data. --- master02.schein.ig ping statistics --- 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2043ms pipe 3 , ping ipv6: ping: master02.schein.ig: Der Name oder der Dienst ist nicht bekannt ). **************************************************************************
Is the log from an internal system? Can the problem be reproduced? What is the domain setup and network setup for the machine trying to join? How can the first check to the DC master resolve to ucs-master01, and the real join is tried against master02? Something does not add up here.
To reproduce, one apparently has to configure one DC master explicitly in System setup, while another DC master is configured in DNS. The DNS entry is favored over the manually configured value.
If it occurs, it is a blocker.
I am unsure how I can reproduce this correctly. When I enter 2 IP's from different UCS domains as nameserver, it suggests me the first one. That's fine. When I uncheck "Search DC Master in DNS" and enter my second domain name + password + Next, it tells me: The connection to the DC Master was refused. Please recheck the password. And then I cannot continue.
I found a way: Configure in your first DC Master a dns/forwarder1=$ip_of_another_master and set in system setup the ip of the first master.
During the validation of the values, the domainname is overwritten with what comes from the DNS server. This has been adjusted so that a given domainname is respected. Afaics, this must be broken since before 2014 (prior to Bug #35685). univention-system-setup.yaml f23893e040ff | YAML Bug #48134 univention-system-setup (12.0.2-3) 2bc52367e93c | Bug #48134: fix joining when specifying a domain to join instead of the domain given by the DNS server base/univention-system-setup/umc/python/setup/__init__.py: line 500: -» » » » guessed_domain = guess_domain(obj) +» » » » guessed_domain = values.get('domainname') or guess_domain(obj) TODO: check if this break joining into Active Directory domains
My change causes that when setting up UCS in AD member mode you can select the domainname (by entering a FQDN). After talking with Arvid, this must be prevented and the UCS system must use the domainname from the AD server.
(In reply to Florian Best from comment #7) > My change causes that when setting up UCS in AD member mode you can select > the domainname (by entering a FQDN). This was only a display problem and was not caused by the changes. System setup actually takes the value which it receives from the nameserver but displays the entered values in the summary. (Implemented wrong in Bug #34484 because "_vals" instead of "vals" was used).
My changes doesn't work at all for domains which use the same domain name (as the customer environment has). Necessary adjustments in system setup to support this: * communicate the chosen name to the system setup backend (the frontend currently doens't send it at all but always uses the domainname) * remove all places where curently the hostname is taken from DNS (at least 3 places). * univention-join must be called with -dcname ... * check if univention-join still evaluates -dcname correctly and can handle the DNS setup of the customer (via code review this seems possible) I assuming the following construction of the domain setup of the customer: * There are different domains using the same domainname * There is one non-UCS System which is used as DNS server * This DNS Server has a A/AAA record for each DC master they have * This DNS Server has a _domaincontroller_master._tcp.fqdn.de SRV record * I don't know which of the following is true: ** This SRV record contains one IP address ** This SRC record contains every IP address of all domains
Okay, I added the necessary parameter "-dcname" to the univention-join call. With this I could sucessfully join into a domain with the above described DNS configuration. Also the validation of the domainname has been improoved, but this can only be really triggered if there are javascript errors (or the DNS changes between entering the join credentials and the validation page). Joining will probably still fail if you want to join into a different UCS domain than is configured in your _domaincontroller_master._tcp. SRV record. But this is not the wanted scenario here and needs some more efford. So I didn't touch this. univention-system-setup (12.0.2-5) d50243c76213 | Bug #48134: Fix displaying of chosen domainname; Enhance validation e95a6941a009 | Bug #48134: pass dcname to univention-join
OK: hostname may differ from value given in DNS, domainname may not differ. This bug is a very special use case, so i think it is okay to make the behavior change as small as possible in the frontend. But the backend change opens up the possibility to easily adapt the join process in the future. I adapted the yaml in a38ee029. Please update the YAML file when rebuilding the package in the future. Verified
<http://errata.software-univention.de/ucs/4.4/17.html>