Bug 40078 - slave DC with wrong DNS Domain after installation
slave DC with wrong DNS Domain after installation
Status: RESOLVED WONTFIX
Product: UCS
Classification: Unclassified
Component: System setup
UCS 4.1
All All
: P5 normal (vote)
: UCS 4.1-x
Assigned To: UCS maintainers
:
Depends on:
Blocks: 33114
  Show dependency treegraph
 
Reported: 2015-11-24 11:34 CET by Marcus
Modified: 2019-01-03 07:22 CET (History)
1 user (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 3: Simply Wrong: The implementation doesn't match the docu
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.017
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus 2015-11-24 11:34:59 CET
Hallo,

ich habe hier folgendes DNS Problem.

ich habe 2 Netze.

1. Netz: lan.example.net (192.168.6.x/24)
         Hier läuft das Active Directory mit Samba4.
2. Netz: dmz.example.net (192.168.7.x/24)
         Hier läuft ein Slave DC mit Mailserver der durch einen ipsec Tunnel   mit einem Rechenzentrum verbunden wurde.

Bei der Installation habe ich explizit als Hostname die fqdn angegeben und diese ist beim Slave DC in diesem Beispiel servername.dmz.example.net.

Somit habe ich - um es noch einmal zu wiederholen - für das:
1. Netz: ad_servername.lan.example.net im Subnet 192.168.6.x/24
2. Netz: slave_servername.dmz.example.net im Subnet 192.168.7.x/24.

Die Installation verläuft sehr flüssig und zufriedenstellend.
Allerdings habe ich nach dem reboot (der somit abgeschlossenen Installation) am slave dc die DNS slave_servername.lan.example.net und nicht wie angegeben slave_servername.dmz.example.net.

Vielleicht können Sie das mal nachvollziehen. Ich jedenfalls dachte zuerst, daß ich die Installation falsch gemacht habe und konnte das Ganze beim 2. mal wieder feststellen.

Grüße

Marcus

P.S. if you need this bug report in english please let me know.
Comment 1 Philipp Hahn univentionstaff 2017-04-10 19:02:17 CEST
"univention-join" always explicitly passes the "UCRV domainname" to "univention-server-join -domainname".
But "univention-join" also uses "$domainname" to check for the DNS-SRV-RR '_domaincontroller_master._tcp.$domain". So either use

  univention-join -dcname "$master.$my_tld"

or add a SRV record to your sub-domain:

  udm dns/srv_record create \
  --superordinate zoneName="${my_sub_dom},cn=dns,$(ucr get ldap/base)" \
  --set name="domaincontroller_master tcp" \
  --set location="0 0 0 ${my_master}."

With Univention-System-Setup (USS) "-dcname ${my_master}" cannot be specified
So the host is created in the DNS domain of the DC Master, even when a FQDN in another domain was used during network configuration.

usr/lib/univention-system-setup/scripts/setup-join.sh:272-


USS asks for a *FQDN*, but my /var/cache/univention-system-setup/profile only has
  domainname="${domain}"
so, the sub-domain "${my_sub_domain}" gets lost somewhere.


BTW: The variables and messages should be changes to "Fully Qualified *Host* Name" (FQHN), which is fqhn := hostname + fqdn, while fqdn := domain + ... + tld
Comment 2 Stefan Gohmann univentionstaff 2019-01-03 07:22:08 CET
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018.

Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact
your partner or Univention for any questions.

If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.