Host name woes

I am running multiple machines, all connected to a LAN. The LAN has a DNS server (BIND) that is set up to resolve the names of all connected hosts. There are also DHCP servers for IPv4 and IPv6 addresses, it is a dual stack setup.

One day I noticed that hostname and hostname -f both returned the unadorned host name without a domain part. The dnsdomain command returned nothing at all. I then googled around and found several recommendations to add a line to /etc/hosts, but that’s clearly not an option for a host with a dynamic address. However, it made me inspect my nsswitch configuration, and I could finally get the desired effect by rearranging the the entries in /etc/nsswitch.conf in this way:

#hosts:      files myhostname resolve [!UNAVAIL=return] dns
# Important: prefer dns over myhostname for correct domain name resolution.
# This is required for ssh hostbased authentication using the FQDN.
hosts:      files resolve [!UNAVAIL=return] dns myhostname

Now, while this fixed the problem for me, it is certainly not a general solution to the problem. I wonder if there should be another nss library addressing this problem specifically by resolving the host and domain names of the local system, perhaps by reading the kernel’s sysctl variables, or via some other magic. Any thoughts, anyone?

sudo hostnamectl hostname

hostnamectl: Control the system hostname | systemd Commands | Man Pages | ManKier

1 Like

Sorry, that does not appear to be the solution. If I pass the fqdn to the hostnamectl hostname, or even hostnamectl hostname --static command, it is just written to /etc/hostname. I could do that directly, without using hostnamectl at all, but having the fqdn in /etc/hostname is considered bad practice. The host may be multihomed or otherwise be a member of multiple domains.

You’ll want to use sudo hostnamectl set-hostname <hostname>.<domainname>. Note that you might not see the updated hostname until existing services and logins are restarted, so while not strictly necessary, rebooting after running this is probably wise.

Nah, this is actually required by old school tech (eg, Citrix) that sometimes grabs the first entry on /etc/hosts whether or not /etc/hostname, etc., are set. There’s nothing wrong with setting the FQDN for localhost in /etc/hosts. Still do the hostnamectl set-hostname command above though in any case. It can be difficult otherwise to cover all the necessary bases.

The example in the man page for /etc/hosts includes FQDN as the first entry:

1 Like

As I wrote, creating /etc/hosts entries is not an option for me, as the IP addresses are dynamically assigned via DHCP. And the hostnamectl set-hostname command you suggest does not seem to exist:

[thomas@sarkovy ~]$ hostnamectl --help
hostnamectl [OPTIONS...] COMMAND ...

Query or change system hostname.

  status                 Show current hostname settings
  hostname [NAME]        Get/set system hostname
  icon-name [NAME]       Get/set icon name for host
  chassis [NAME]         Get/set chassis type for host
  deployment [NAME]      Get/set deployment environment for host
  location [NAME]        Get/set location for host

  -h --help              Show this help
     --version           Show package version
     --no-ask-password   Do not prompt for password
  -H --host=[USER@]HOST  Operate on remote host
  -M --machine=CONTAINER Operate on local container
     --transient         Only set transient hostname
     --static            Only set static hostname
     --pretty            Only set pretty hostname
                         Generate JSON output

See the hostnamectl(1) man page for details.

The command hostnamectl hostname will display the current hostname.
The command sudo hostnamectl hostname NEWHOSTNAME will set the hostname to that given (at least on F37, F38, and F39).

I know, that’s what I wrote above here. But it does not give me what I want.

I’m afraid that not configuring a static hostname FQDN, makes it unreliable in a dynamic environment.

It becomes dependent on too many factors, such as the settings provided with DHCP and DHCPv6 for wired and wireless connections, settings advertised by the VPN servers on tunneled protocols, local overrides for each connection, so any one of those can alter your hostname and its domain part, unless explicitly configured otherwise.

In addition, dynamic environment makes you vulnerable to all sorts of race conditions and deadlocks, including transient and permanent network-related issues, timing issues on connection and service activation, etc.

I am aware that people are divided on this topic. To me, the distinction between the hostname and hostname -f commands seems to hint at the original intention. I am willing to deal with any complexities this may bring about.