Uploaded image for project: 'Satellite'
  1. Satellite
  2. SAT-40687

Satellite can't resolve hostname of a provisioned host that Satellite itself has assigned

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • Networking
    • 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

              Unassigned Unassigned
              lhellebr@redhat.com Lukas Hellebrandt
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: