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.
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?
(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.
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.
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.
(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).
infiniband-diags-1.6.1-4.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/infiniband-diags-1.6.1-4.fc18
Package infiniband-diags-1.6.1-4.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing infiniband-diags-1.6.1-4.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-3682/infiniband-diags-1.6.1-4.fc18 then log in and leave karma (feedback).
infiniband-diags-1.6.1-4.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.