Red Hat Bugzilla – Bug 919901
infiniband-diags: migration to /etc/hostname, /etc/vconsole.conf, /etc/locale.conf
Last modified: 2013-03-10 17:31:39 EDT
+++ This bug was initially created as a clone of Bug #881917 +++
Fedora is migrating away from:
/etc/sysconfig/network (the HOSTNAME=... setting)
See the tracker bug 881785 for details.
We found in infiniband-diags-1.5.12/scripts/set_nodedesc.sh:
if [ -f /etc/sysconfig/network ]; then
Since HOSTNAME will no longer be set in /etc/sysconfig/network, this may need to be changed. On the other hand, bash implicitly sets $HOSTNAME, so maybe it's alright as it is.
Please check and update the package if necessary.
--- Additional comment from Jon Stanley on 2012-11-30 00:27:50 EST ---
Perhaps I don't get this. As an old-school sysadmin type, growing up in Red Hat-land, the HOSTNAME= line in /etc/sysconfig/network was the full FQDN of the host. Looking at http://0pointer.de/public/systemd-man/hostname.html, we're dropping the HOSTNAME= part, so that the variable can't be sourced in a shell script like we do today (not a *huge* deal, just means that we have to fork again to read the file from a subshell), and we actually lose the data of the FQDN.
Where is that set? Am I completely missing the boat here?
--- Additional comment from Michal Schmidt on 2012-11-30 17:25:02 EST ---
(In reply to comment #1)
> in Red Hat-land, the HOSTNAME= line in /etc/sysconfig/network was the full
> FQDN of the host.
I don't think this could ever be relied on.
Looking at the nearest RHEL6 installation I have at hand, here the HOSTNAME= line specifies only the short hostname.
On RHEL6, /etc/sysconfig/network is read by /etc/rc.d/rc.sysinit and it simply gives it to the hostname(1) command as argument:
action $"Setting hostname $(HOSTNAME): " hostname $(HOSTNAME)
And here's what "man 1 hostname" says about the FQDN:
You can't change the FQDN (as returned by hostname --fqdn)
or the DNS domain name (as returned by dnsdomainname) with
this command. The FQDN of the system is the name that the
resolver(3) returns for the host name.
Technically: The FQDN is the name gethostbyname(2) returns
for the host name returned by gethostname(2). The DNS
domain name is the part after the first dot.
Therefore it depends on the configuration (usually in
/etc/host.conf) how you can change it. Usually (if the
hosts file is parsed before DNS or NIS) you can change it
If a machine has multiple network interfaces/addresses or
is used in a mobile environment, then it may either have
multiple FQDNs/domain names or none at all. Therefore
avoid using hostname --fqdn, hostname --domain and dnsdo-
mainname. hostname --ip-address is subject to the same
limitations so it should be avoided as well.
--- Additional comment from Jon Stanley on 2012-12-03 16:34:56 EST ---
Posted patch upstream:
I don't think we need anything other than what the shell provides here.
--- Additional comment from Jon Stanley on 2012-12-04 08:45:33 EST ---
The conversation upstream is that setting $HOSTNAME in the shell is a bash-ism that we likely don't want. Per POSIX, shells don't have to set $HOSTNAME, and in fact dash (for example) does not.
Here's what I posted upstream, and would like comments here too....
> This looks like it is a bashism (ie dash does not do this), so you
> should update the #! to use /bin/bash not /bin/sh...
But Garrett just committed something a few days ago to remove
bash-isms, and I'd hate to reintroduce one for this trivial thing.
More specifically, here's what's going to happen in Fedora-land, and
isn't in RHEL6:
The /etc/sysconfig/network file goes away, and is replaced (for our
purposes) with /etc/hostname ,which contains the short name of the
hostname. The way I figure it, we can get the hostname one of a few
1) Blindly trust that the set hostname is correct (i.e. what the
hostname(1) command returns is what we should be using)
2) Read /etc/hostname in a subshell (the HOSTNAME= no longer exists,
so it can't be sourced)
3) Fall back on /etc/sysconfig/network if we don't find /etc/hostname
if we go with 2.
--- Additional comment from Michal Schmidt on 2012-12-04 09:10:36 EST ---
(In reply to comment #4)
> 1) Blindly trust that the set hostname is correct (i.e. what the
> hostname(1) command returns is what we should be using)
Yes, I would trust hostname(1).