Ensure the domain name is set before installing the server

[cbosdo]

Of course this is all due to my network configuration not setting the domain name part of the hostname to the libvirt VMs, but the issue may be worth looking at.

In such a case the hostname -f at the time of the server installation has no domain name. This results in the server certificate to be generated for the incomplete hostname, leading to further errors when running the testsuite for instance.

After the sumaform Salt state apply the hostname -f returns the FQDN... We surely want to ensure this part of the Salt state is run before the server installation.

[moio]

In general, we do not have very robust ways to check input variables apart from a bit of type checks.

Terraform 0.13 introduced a way to validate input variables and my hope is that it could be used for this and many other "UX" problems in future.

https://www.terraform.io/docs/configuration/variables.html#custom-validation-rules

[cbosdo]

The issue there is that the input variable was set properly, the domain name was also set nicely... but too late. The one we had at the server installation time was the one set using the DHCP... which config is outside the terraform scope.

[moio]

I guess that the name set via the DHCP did not correspond to the configured one in that case?

[cbosdo]

the DHCP was only setting the hostname part like test-srv instead of test-srv.tf.local and the domain variable in the main.tf was set to tf.local

[moio]

How would you solve it from the sumaform side? For proper resolution (network) DHCP/DNS name and (host) internal configuration must be equal.

[cbosdo]

I'm not a hostname expert, but I ran a hostname -F /etc/HOSTNAME before the server was installed to fix it. I wonder if such a thing could be done in the default Salt state.

[moio]

That's a hairy subject, welcome to the world who has opened the hostname-specific Pandora's Box! :wink:

I have been researching for a long time on the topic, and could not find very conclusive evidence, so I am all ears in case you can, but, AFAIK:

• /etc/HOSTNAME is a SLE-11 era backwards compatibility file. Back in the day it was a SUSE-specific way to set the hostname, and it might still be referenced by some code, so sumaform's posture is to keep it around, albeit not needed strictly speaking in any modern environment. That is supposed to contain the fully-qualified domain name - despite the name being, in fact, HOSTNAME
• it is debated whether the hostname (as set by the hostname command) should actually be the FQDN or just the "short name" - distros opinions vary and none seem to be really set in stone. This comment describes what I know about the subject:

https://github.com/uyuni-project/sumaform/blob/master/salt/default/hostname.sls#L8

• strictly speaking, there is no relationship between the hostname and a fully-qualified domain name conceptually. In fact, the hostname is just an internal name the machine uses to refer to itself, while the FQDN is the name other machines use to refer to it. Basically the former is a system-local concept, while the latter is a network-wise concept. The hostname exists even without any network, and can be whatever. The FQDN is tied to the naming restrictions of DNS, among other things. It is just out of common practice (and common sense) to keep the two aligned to avoid confusion
• that very last point brings us where we are: from one perspective, the hostname has nothing to do with the network, so it makes sense to set it to a name without a domain, and set the FQDN as the hostname with proper domain ending. It's just an elegant way to bridge the two worlds. OTOH this creates a bit of confusion, so some people prefer to just stick to the FQDN everywhere

At the end of the day sumaform's posture as of today, and for lack of better options, is to use the short name as hostname and FQDN for anything network related. We also try to set it as early as possible in Salt - but applying the Salt state requires network connectivity, so the DHCP will always be first and there is no easy way around that.

Does that match your experience? I might still be missing something...

Thanks for the patience :angel:

[cbosdo]

indeed, I read those comments in the state file... not sure if there is another way to get hostname -f to return the FQDN and not just the hostname. man 1 hostname suggests to set something like this in the /etc/hosts:

127.0.1.1    ursula.example.com ursula

I don't think that would harm to have a 127.0.0.1, but I haven't tried it.

[moio]

127.0.1.1    ursula.example.com ursula

I don't think that would harm to have a 127.0.0.1, but I haven't tried it.

We do that: https://github.com/uyuni-project/sumaform/blob/master/salt/default/set_ip_in_etc_hosts.py#L56