Bug 48134 - Initial Join in the system-setup fails because the specified server is not used.
Initial Join in the system-setup fails because the specified server is not used.
Product: UCS
Classification: Unclassified
Component: System setup
UCS 4.4
Other Linux
: P5 normal (vote)
: UCS 4.4-0-errata
Assigned To: Florian Best
Erik Damrose
Depends on:
  Show dependency treegraph
Reported: 2018-11-12 12:00 CET by Christina Scheinig
Modified: 2019-03-27 13:29 CET (History)
5 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 6: Setup Problem: Issue for the setup process
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 5: Blocking further progress on the daily work
User Pain: 0.343
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted after Product Owner Review:
Ticket number: 2018110721000402
Bug group (optional):
Max CVSS v3 score:


Note You need to log in before you can comment on or make changes to this bug.
Description Christina Scheinig univentionstaff 2018-11-12 12:00:43 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 ).
Comment 1 Erik Damrose univentionstaff 2018-11-12 12:10:16 CET
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.
Comment 2 Erik Damrose univentionstaff 2018-11-12 14:08:06 CET
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.
Comment 3 Stefan Gohmann univentionstaff 2018-11-12 19:57:52 CET
If it occurs, it is a blocker.
Comment 4 Florian Best univentionstaff 2019-03-12 22:06:49 CET
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.
Comment 5 Florian Best univentionstaff 2019-03-12 22:20:23 CET
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.
Comment 6 Florian Best univentionstaff 2019-03-12 23:28:02 CET
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).

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
Comment 7 Florian Best univentionstaff 2019-03-19 12:12:18 CET
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.
Comment 8 Florian Best univentionstaff 2019-03-20 16:32:42 CET
(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).
Comment 9 Florian Best univentionstaff 2019-03-20 17:09:50 CET
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
Comment 10 Florian Best univentionstaff 2019-03-21 15:52:52 CET
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
Comment 11 Erik Damrose univentionstaff 2019-03-25 17:27:36 CET
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.

Comment 12 Arvid Requate univentionstaff 2019-03-27 13:29:24 CET