https://bugzilla.redhat.com/show_bug.cgi?id=1280529
--- Comment #4 from Petr Spacek <pspacek(a)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.
--
You are receiving this mail because:
You are the QA Contact for the bug.