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?
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:
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.
Commands:
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
Options:
-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
--json=pretty|short|off
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’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.
