Bug 1280529 - Document incorrectly suggests using FQDN in /etc/hostname
Document incorrectly suggests using FQDN in /etc/hostname
Status: NEW
Product: Fedora Documentation
Classification: Fedora
Component: networking-guide (Show other bugs)
devel
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Stephen Wadeley
Fedora Docs QA
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-11 20:43 EST by Jesse Keating
Modified: 2017-12-07 19:13 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jesse Keating 2015-11-11 20:43:10 EST
Description of problem:
https://docs.fedoraproject.org/en-US/Fedora/23/html/Networking_Guide/ch-Configure_Host_Names.html#sec_Understanding_Host_Names

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.
Comment 1 Stephen Wadeley 2015-12-11 06:25:54 EST
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?
Comment 2 Petr Spacek 2015-12-15 05:12:15 EST
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?
Comment 3 Jesse Keating 2016-01-04 13:46:30 EST
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.
Comment 4 Petr Spacek 2016-01-05 05:03:32 EST
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.

Note You need to log in before you can comment on or make changes to this bug.