I've noticed that the "preferred" method of setting the system hostname is fundamentally different between Red Hat/CentOS and Debian/Ubuntu systems.
CentOS documentation and the RHEL deployment guide say the hostname should be the FQDN:
HOSTNAME=<value>
, where<value>
should be the Fully Qualified Domain Name (FQDN), such ashostname.example.com
, but can be whatever hostname is necessary.
The RHEL install guide is slightly more ambiguous:
Setup prompts you to supply a host name for this computer, either as a fully-qualified domain name (FQDN) in the format hostname.domainname or as a short host name in the format hostname.
The Debian reference says the hostname should not use the FQDN:
3.5.5. The hostname
The kernel maintains the system hostname. The init script in runlevel S which is symlinked to "/etc/init.d/hostname.sh" sets the system hostname at boot time (using the hostname command) to the name stored in "/etc/hostname". This file should contain only the system hostname, not a fully qualified domain name.
I haven't seen any specific recommendations from IBM about which to use, but some software seems to have a preference.
My questions:
- In a heterogeneous environment, is it better to use the vendor recommendation, or choose one and be consistent across all hosts?
- What software have you encountered which is sensitive to whether the hostname is set to the FQDN or short name?
I would choose a consistent approach across the entire environment. Both solutions work fine and will remain compatible with most applications. There is a difference in manageability, though.
I go with the short name as the HOSTNAME setting, and set the FQDN as the first column in
/etc/hosts
for the server's IP, followed by the short name.I have not encountered many software packages that enforce or display a preference between the two. I find the short name to be cleaner for some applications, specifically logging. Maybe I've been unlucky in seeing internal domains like
server.northside.chicago.rizzomanufacturing.com
. Who wants to see that in the logs or a shell prompt?Sometimes, I'm involved in company acquisitions or restructuring where internal domains and/or subdomains change. I like using the short hostname in these cases because logging, kickstarts, printing, systems monitoring, etc. do not need full reconfiguration to account for the new domain names.
A typical RHEL/CentOS server setup for a server named "rizzo" with internal domain "ifp.com", would look like:
-
-
-
Pretty much all software is sensitive to correctly setting the hostname. While I was working at Digg I once brought the entire site down for 2 hours due to making a seemingly innocent change in
/etc/hosts
that affected the system's notion of hostname. Tread lightly. That said, you may be slightly confused here. I don't think theHOSTNAME=
setting is directly equivalent to how Debian-based distributions use/etc/hostname
.What works for me in a heterogeneous environment is:
hostname
command to set the hostname used by the kernel, etc.In
/etc/hosts
:This configuration has not failed me yet.
You will certainly have no problem finding references online which will tell you to definitely do it one way or another. It seems to me however that having a short name as the hostname, and have the fully qualified name in /etc/hosts is certainly much more prevalent. It seems like the more sensible way, as then services which need a fully qualified name can be adapted to call
hostname --fqdn
instead.I've only come across one piece of software recently which rigidly requires a fqdn to be returned by
hostname
, which was ganeti. They document this here. I don't see any reason they cannot adapt tohostname --fqdn
, however.Somewhat tangentially, while researching this question, I have been going crazy enough to check the source code of "hostname" and write a script to print investigative results (Fedora 19). What is missing is a look at "/etc/hosts", which in my humble opinion should be kept the hell out of all of this in the first place.
The output on an Amazon EC2 VM running Fedora 19, after manually setting the kernel values and filling
/etc/hostname
, but with no changes to/etc/hosts
might then be like this:The resilient way to get the fully qualified hostname in perl would then be:
and in bash it would be:
Notes
Note 1: HOSTNAME is a shell variable that bash provides ("Automatically set to the name of the current host.") but there is no indication about bash arrives at that value.
Note 2: Never forget /etc/hostname in /boot/initrams-FOO.img ...
Short answer: I generally use the FQDN as the hostname (as recommended on RH6/7 docs). However, the more righteous approach would be to use a single-label name as the hostname, setting the FQDN via
/etc/hosts
. So, pick an approach and stick with it whenever possible.Long answer: The main advantage of using the FQDN as the hostname is that the machine name intrinsically embeds domain information. This is very useful when receiving email alert and/or logs for multiple customers/domains, as it avoid duplicate hostnames (ie: hostnames are more-or-less guaranteed to be unique across multiple sites/customers/domains). For example, SNMP
sysName
show the hostname by default and, by using the FQDN, it simply conveys a more useful information. The same is true forzabbix-agent
(and other monitor tools) or for bash$HOSTNAME
. While you can configure such tools for using FQDNs even on machine with single-label hostname, or configure them in an hierarchical model which clearly shows the domain containing the machine, this is additional work.Some application even require using a FQDN as the hostname, but they are quite the exception. Still, when the exception hits, the homogeneous use of single-label hostname is lost. This probably is the main reason behind RedHat's recommendation to use a FQDN as the hostname on RH6/7. More recent docs are more vague. On "Performing a standard RHEL 8 installation" one can read:
while "Performing an advanced RHEL 8 installation" states:
In the years between the original question, user applications have learned to treat FQDN hostnames without the issue described in the previous answers. For example, bash
PS1
prompt uses\h
(the hostname up to the first '.') by default, andrsyslog
does not preserve FQDN in logfiles by default. In other words, the usability drawback of a FQDN hostname are no more for many common tools. For these reasons, I generally set the system hostname as a FQDN, leaving the shortname on/etc/hosts
as required.The reason to not use a FQDN hostname is that, frankly, this is The Right Thing To Do. As respectively stated in the debian docs and hostname man page:
and
So, while I do feel uneasy to use a FQDN hostname, it is easier using it in my environments.
Please note this is not an appeal against single-label hostname. If they work for you, continue using it. Otherwise, give the FQDN hostname a try.
The /etc/hosts options works well.
But you want to make sure that all the proper files are updated run the setup tool
Hm... In the linux hosts, if you want change HOSTNAME and FQDN, you should solved 3 steps (for example, new host is rizzo.ifp.com):
Step #1 Change HOST value in the NETWORK properties config:
Change or add string:
Step #2 Edit your hosts config
Step #3 Reboot your host Well done, just check new configuration
The order is not right. It has to be:
So the example could like this: