Bug 1280529

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?

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?

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:
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.

I'm closing this bug as part of a Bugzilla cleanup effort. The most likely reason is that the bug has been opened either against a component we no longer publish, or against Release Notes for an EOL release.