Foreman not properly checking FQDN

Support
1

Problem:
I want to deploy a Foreman installation into an OpenStack based private cloud. The clouds network topology does not allow for instance interfaces to have public IPv4 addresses assigned. Instead, each instance is on an internal 10.x.x.x network, but floating IPv4 addresses can be assigned to gain internet access.

The instance itself however will only ever have interfaces with internal IPv4 addresses.

This poses a bit of a problem, since the error message is something akin to:
Forward DNS points to <IP> which is not configured on this server
which seems to be exactly the issue mentioned in this post:

The error message can be traced back to a Kafo pre-install hook called dns.rb. What happens is that Ruby compares IP addresses fetched from /etc/hosts and compares them to IP addresses of network interfaces that are present. If there is a mismatch the error message above is displayed.

This is unfortunate. Again, the networking configuration I’m working with does not allow for instance interfaces to be assigned public IPv4 addresses directly, so the mismatch will not be resolved.

I have also done the following to ensure the instance has a properly configured FQDN:

  • Created A and PTR records with the corresponding floating IP and DNS Hostname (which is a publically routable FQDN)
  • Double checked that the instance is properly configured with this FQDN, both with dig, nslookup and whois information

The OS itself (Centos 8 Stream) perfectly understands that it has an FQDN, but since Foreman has this rather weird check based on interfaces, I am forced to run the installer with the --skip-checks-i-know-what-im-doing option, which I find suboptimal. Btw, the installer also recognizes the DNS name as the hostname the web ui is served under, so I really don’t get it.

Expected outcome:

Foreman isn’t as uptight about what it considers an FQDN and let’s me install without skipping checks.

Foreman and Proxy versions:

Foreman 3.4 fresh install

Foreman and Proxy plugin versions:
n/a

Distribution and version:
CentOS Stream release 8

2

If you clone the fqdn on your cloud server with a different private ip you have the problem that technically if the server tries to access itself through its fqdn it would go through the public ip address if it is resolved by dns. Of course, you probably have it in /etc/hosts bound to your private address as well thus it goes through the loopback but this means you have two name resolutions with conflicting information: dns and /etc/hosts point to different addresses.

I wouldn’t recommend this kind of setup even if it seems to work fine most of the time. Inconsistencies like this may cause issues at weird places.

Instead, set up the vm with a private, local host name which is bound to your private ip address. Set up the public fqdn as server alias instead, thus your server knows that it serves this host name as well. IMHO that’s the correct way to set this up.

3

Instead, set up the vm with a private, local host name which is bound to your private ip address

I got assigned a private DNS hostname on my private network (in AWS that would be a VPC I think), should I ignore that one as well and just create a hostname that is set locally?

4

It seems that this configuration is not supported officially:

With foreman-installer this can be done in a sort of hacky way by using custom-hiera.yaml. Note that this is untested and there may be typos.

5

It is supposed. You can set up server aliases (and even altnames in certificates if you wanted).

You can set the servername in the virtualhost with --foreman-servername. WIth --foreman-serveraliases you can set an array of additional server aliases in the apache configuration.

Then you tell foreman the correct URL to access the server via --foreman-foreman-url.

It’s all there…