tl;dr: What does the Rocky 9.1 GUI installer do to set the system hostname that’s different from running hostnamectl set-hostname sub.domain.tld after installation?
Background: I’m trying to work with Nethserver 8 on a Contabo VPS instance. As is probably typical in that kind of environment, I tell them to install Rocky 9, and they clone an image for me–I don’t step through the installer myself. And the machine is assigned a hostname of vmiXXXX.contaboserver.net. I can change that, of course, with hostnamectl and edits to /etc/hosts. I’ve also edited /etc/sysconfig/network as stated in the docs. But even after doing this, various places in Nethserver 8 read the system hostname as localhost.localdomain.
This doesn’t happen if I run through the installer myself. If I install Rocky 9.1 from the ISO in a VM I’m hosting, go through the installer, and assign a hostname using the installer, those places in Nethserver 8 read the system hostname as the one I assigned in the installer. So, apparently, the installer’s doing something different to set the hostname than running hostnamectl, editing /etc/hosts (which doesn’t contain the specified hostname at all), and editing /etc/sysconfig/network (which doesn’t contain either of the lines that the docs say are mandatory). But I haven’t been able to figure out what it’s doing that the other isn’t–any ideas?
Was used by (network) initscripts that are not in el9 at all. They were gradually deprecated in earlier major versions as NetworkManager became able to do the job.
Is not about hostname. It is about name resolution. The /etc/nsswitch.conf probably has
hosts: files dns myhostname
and it is usually sufficient that the /etc/hosts can resolve the addresses 127.0.0.1 and ::1 – DNS should take care of the rest.
Look at man hostnamectl. It does mention man systemd-hostnamed.service because hostnamectl is just a utility to talk to the service.
The service does use, according to its man-page:
The static hostname is stored in /etc/hostname, see hostname(5) for more information. The pretty hostname, chassis type, and icon name are stored in /etc/machine-info, see machine-info(5).
If you don’t set any hostname, then a transient name is used. NetworkManager receives a name from DHCP server (or resolves Ip address via DNS) and sets that name. It is not stored in files.
You have a VM. It is common to use cloud-init on VM’s. The cloud-init gets parts of config from virtualization platform when VM instances are created from pre-made image, rather than by running the installer. The cloud-init service can set the hostname on boot.
Thanks. It would be nice if the docs reflected this; currently, they say:
It is therefore essential to fill in these two files [i.e., `/etc/sysconfig/network` and `/etc/hosts`] before any configuration of network services.
…but the hosts file does affect how the system reads its hostname. Specifically, the output of hostname -f is affected, if not outright controlled, by the contents of the hosts file.
True, and I’m sure the Contabo VPS does. But the VMs I’m using for local testing don’t. And if I run through the installer in a local VM and don’t set a hostname in the installer, it behaves the same as the Contabo VPS.
The resolution for Nethserver 8 has been to use the desired FQDN as the first entry in /etc/hosts: have it read 127.0.0.1 <fqdn> localhost localhost.localdomain localhost4 localhost4.localdomain4. This may be a bug in that software, which wouldn’t be surprising as it’s in Alpha status. But that still leaves the question of what the installer’s doing differently, because it doesn’t put the specified hostname there.
Lets say that we have machine A. It has two IP addresses: 127.0.0.1 (the lo) and 10.20.32.5.
On A there is service B that does listen port tcp/X on both addresses.
On A, you do run program that tries to access fqdn:X.
If first match on the name resolution is 127.0.0.1 fqdn localhost.localdomain
then the program connects to 127.0.0.1:X and talks to B.
If first match on the name resolution is 10.20.32.5 fqdn
then the program connects to 10.20.32.5:X and talks to B.
In both cases the “network traffic” is within A; both addresses are “local”.
On some other machine you do run program that tries to access fqdn:X.
The name resolution (usually DNS) has 10.20.32.5 fqdn and
the program connects to 10.20.32.5:X and talks to B.
The difference in A talking to 10.20.32.5 and others talking to 10.20.32.5 is probably in the firewall rules of A.
Nowhere in the above was hostname used.
If the B does not listen on both 127.0.0.1:X and 10.20.32.5:X, or if the payload (e.g. HTTP URL) has name that is meaningful to B – for example “I only answer to requests that contain fqdn” then B must pick that name from somewhere.
The man-page I quoted earlier said that the name that machine shows for user on prompts or GUI is in /etc/hostname and/or /etc/machine-info. They are not used for name resolution.