-
Bug
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
False
-
None
-
None
-
None
-
None
Description of problem:
When I provision a (bare metal in my case) host through Satellite, with domain and subnet set and the IP assigned by the Satellite itself when creating the host, Satellite can't resolve that very hostname (so remote execution fails, for example).
On the Satellite:
# dig +short host2.lhellebr.com # dig +short host2.lhellebr.com @127.0.0.1 <HOST_IP>
So the DNS record exists but Satellite doesn't use its DNS by default for lhellebr.com.
Installer parameters:
# satellite-installer --help | grep foreman-proxy-dns
--foreman-proxy-dns Enable DNS feature (current: true)
--foreman-proxy-dns-forwarders DNS forwarders (current: ["<IP1>", "<IP2>"])
--foreman-proxy-dns-interface DNS interface (current: "eth1")
--foreman-proxy-dns-listen-on DNS proxy to listen on https, http, or both (current: "https")
--foreman-proxy-dns-managed The DNS daemon is managed by this module. Only supported for the nsupdate and nsupdate_gss DNS providers. (current: true)
--foreman-proxy-dns-provider DNS provider (current: "nsupdate")
--foreman-proxy-dns-reverse DNS reverse zone name (current: UNDEF)
--foreman-proxy-dns-server Address of DNS server to manage (current: "127.0.0.1")
--foreman-proxy-dns-tsig-keytab Kerberos keytab for DNS updates using GSS-TSIG authentication (current: "/etc/foreman-proxy/dns.keytab")
--foreman-proxy-dns-tsig-principal Kerberos principal for DNS updates using GSS-TSIG authentication (current: "foremanproxy/<PRINCIPAL>")
--foreman-proxy-dns-ttl DNS default TTL override (current: 86400)
--foreman-proxy-dns-zone DNS zone name (current: "lhellebr.com")
Help says:
--foreman-proxy-dns-server: Sets the address of the DNS server to manage
So Satellite manages its own DNS, according to the description of the parameter, but does not actually use it.
There is a workaround for REX: set "Connect by IP" setting to "Yes". But should that be necessary?
Putting
nameserver 127.0.0.1
to /etc/resolv.conf fixes the issue.
Satellite is its own DHCP and DNS for that network, it assigned that IP to that hostname... shouldn't it then be able to resolve it, automatically by default? Especially given it's easy to set it up manually.
How reproducible:
Deterministic
Is this issue a regression from an earlier version:
Tested on stream snap 147.0 and I have no reason to think it's a regression.
Steps to Reproduce:
1. Have a Satellite set up for provisioning, with content, subnet, domain, AK...
2. Hosts -> Create host, fill in everything including interface and MAC
3. Let the host provision
4. Attempt to run a remote execution job on that host, it fails
5. Try "dig +short <HOST>", it doesn't resolve
Actual behavior:
The hostname can't be resolved by the Satellite
Expected behavior:
Unless there is a reason for this not to be set up, Satellite should be able to resolve hostnames that it assigned IPs to