https://bugzilla.redhat.com/show_bug.cgi?id=1280529
Bug ID: 1280529 Summary: Document incorrectly suggests using FQDN in /etc/hostname Product: Fedora Documentation Version: devel Component: networking-guide Assignee: swadeley@redhat.com Reporter: jkeating@j2solutions.net QA Contact: docs-qa@lists.fedoraproject.org CC: swadeley@redhat.com
Description of problem: https://docs.fedoraproject.org/en-US/Fedora/23/html/Networking_Guide/ch-Conf...
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)
How reproducible: Very
Steps to Reproduce: 1. Follow directions leading to FQDN in /etc/hostname 2. uname -n 3. hostname -s
Actual results: FQDN shown as nodename, which does not match hostname -s
Expected results: uname -n and hostname -s would both report the same short name, as defined in /etc/hostname
Additional info: The RHEL7 documentation also suffers from this defect.
https://bugzilla.redhat.com/show_bug.cgi?id=1280529
Stephen Wadeley swadeley@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pspacek@redhat.com Flags| |needinfo?(pspacek@redhat.co | |m)
--- Comment #1 from Stephen Wadeley swadeley@redhat.com --- 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?
https://bugzilla.redhat.com/show_bug.cgi?id=1280529
Petr Spacek pspacek@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jkeating@j2solutions.net Flags|needinfo?(pspacek@redhat.co |needinfo?(jkeating@j2soluti |m) |ons.net)
--- Comment #2 from Petr Spacek pspacek@redhat.com --- Hello,
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?
https://bugzilla.redhat.com/show_bug.cgi?id=1280529
Jesse Keating jkeating@j2solutions.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jkeating@j2soluti | |ons.net) |
--- Comment #3 from Jesse Keating jkeating@j2solutions.net --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1280529
--- Comment #4 from Petr Spacek pspacek@redhat.com --- 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: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/uname.html
OPTIONS -n 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): NOTES 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.
docs-qa@lists.fedoraproject.org