Bug 919901

+++ This bug was initially created as a clone of Bug #881917 +++

Fedora is migrating away from:
 /etc/sysconfig/network (the HOSTNAME=... setting)
 /etc/sysconfig/keyboard
 /etc/sysconfig/i18n
to:
 /etc/hostname
 /etc/vconsole.conf
 /etc/locale.conf

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
  . /etc/sysconfig/network
  fi

  ib_sysfs="/sys/class/infiniband"
  newname="$HOSTNAME"

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:

   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
       in /etc/hosts.

       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:

http://www.mail-archive.com/linux-rdma@vger.kernel.org/msg13673.html

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
ways here:

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