Red Hat Bugzilla – Bug 1280529
Document incorrectly suggests using FQDN in /etc/hostname
Last modified: 2017-12-07 19:13:24 EST
Description of problem:
This section of the documentation recommends using a FQDN for the static hostname, which is stored in /etc/hostname. However if one does that, uname -n (to find the node name) will always return the FQDN. This has impact on subsystems like python when determining the short name of the host. A better solution is to use the shortname in /etc/hostname and supply a FQDN in /etc/hosts.
Version-Release number of selected component (if applicable):
devel (shown as 23)
Steps to Reproduce:
1. Follow directions leading to FQDN in /etc/hostname
2. uname -n
3. hostname -s
FQDN shown as nodename, which does not match hostname -s
uname -n and hostname -s would both report the same short name, as defined in /etc/hostname
The RHEL7 documentation also suffers from this defect.
Thank you for raising this bug. I have recently been caught out by this myself when testing something.
I will ask Petr Spacek for advice.
Hello Petr, any opinion on this?
first of all, I admit that this is a mess. Main problem is that short names are by definition not unique and thus their use for identification purposes is inherently broken.
One of side-effects of using short names in /etc/hostname are typically various cryptic failures while using Kerberos libraries, which was main motivation why I added recommendation to use FQDN everywhere.
Could you describe you use-case? Why it hurts to display FQDN instead of short name?
Some software we use, namely OpenStack, determines names for database entries based on "nodename", uname -n. We prefer to have this the short name in the database rather than the FQDN. This makes things easier when our cloud can span multiple locations, where the location comes into the domain part.
More to the point, I want there to be the distinction between node name and fqdn. The documentation doesn't lend itself to there being a distinction.
Could you be more specific, please? What would be the technical advantage to use non-unique 'node name'?
I can see potential conflicts caused by this (imagine two machines named 'node1' in 'location1' and 'location2', too) and no real advantage, except shorter strings which seems as a corner case to me.
I dug into standards and found following specification for uname utility:
Write the name of this node within an implementation-defined communications network.
The standard guarantees nothing. It may not even be a DNS name.
Definition of structure utsname is even more interesting, see http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_utsname.h.html :
char nodename Name of this node within the communications
network to which this node is attached, if any.
My understanding of 'if any' is that the value could be even empty.
Also please see man 2 uname (also available from http://linux.die.net/man/2/uname):
This is a system call, and the operating system presumably knows its
name, release and version. It also knows what hardware it runs on.
So, four of the fields of the struct are meaningful. On the other
hand, the field nodename is meaningless: it gives the name of the
present machine in some undefined network, but typically machines are
in more than one network and have several names. Moreover, the kernel
has no way of knowing about such things, so it has to be told what to
answer here. The same holds for the additional domainname field.
To this end, Linux uses the system calls sethostname(2) and setdomain‐
name(2). Note that there is no standard that says that the hostname
set by sethostname(2) is the same string as the nodename field of the
struct returned by uname() (indeed, some systems allow a 256-byte host‐
name and an 8-byte nodename), but this is true on Linux. The same
holds for setdomainname(2) and the domainname field.
The part 'the field nodename is meaningless' matches what POSIX says. So in general, any attempt to depend on particular format of nodename is going in the wrong direction.
Having said that, I strongly prefer unique meaningless values over non-unique meaningless values :-)
To conclude, I'm proposing to keep curent behavior and use FQDN everywhere as it is at least unique.