Bug 869115 - All RH and Fedora documentation for setting the hostname is incomplete
All RH and Fedora documentation for setting the hostname is incomplete
Status: CLOSED CURRENTRELEASE
Product: Fedora Documentation
Classification: Fedora
Component: install-guide (Show other bugs)
devel
Unspecified Linux
unspecified Severity low
: ---
: ---
Assigned To: Petr Bokoc
Ruediger Landmann
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-23 01:31 EDT by Wayne Pollock
Modified: 2015-10-19 16:29 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-19 16:29:35 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Wayne Pollock 2012-10-23 01:31:45 EDT
Description of problem:
The various guides, Anaconda help, GUI network tools, and initscript's sysconfig.txt file, all include contradictory or incorrect information on how to set hostnames on Fedora or Red Hat systems.  Since this problem affects so many components, I wasn't sure how to report it.

The correct way to set hostnames for full functionality was found by reading the source code and init scripts used.  Experiments confirm the problem exists for systemd init as well (as of Fedora 16; haven't tested on F17 or newer, but I have no reason to think this has changed in the last 10 years); however, I haven't personally examined the systemd C code.

In a nutshell, the init scripts that read the hostname from /etc/sysconfig/network (or other files) do not want an FQDN.  On all RH and Fedora systems on which I've examined the init code, the correct way is to set the non-FQDN hostname via the hostname(1) command or hostname(2) systemcall (or set the shortname in the various config files, which is really the same thing).  RH and Fedora do a lookup in /etc/hosts to find the FQDN.  Thus, an entry needs to be manually added to /etc/hosts to enable this lookup; the IP address of the entry doesn't seem to matter and I use 127.0.0.1 if the host doesn't have a static IP.

Unless this undocumented procedure is followed, the output of the hostname command and the hostname -f command is the same, which may have some minor consequences.  (I can't be sure but I feel there may be a security issue with having systems failing to correctly identify their FQDNs; I hope someone smarter than I will think about that.) SysAdmins need to add a line to /etc/hosts to enable the translation, and to set the short hostname.  But this is not what any documentation says to do.

Additionally, the Anaconda default of localhost.localdomain fails, because the localhost lines in /etc/host have incorrectly listed the shortname first and the FQDN afterward:

$ cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6


This default causes the following odd output:
$ hostname
localhost.localdomain
$ hostname -f
localhost

$ dnsdomainname

(no output)

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. NA
2.
3.
  
Actual results:
NA

Expected results:
NA

Additional info:

This has always seemed to be an odd procedure, but it is what RH and then Fedora have always done in the init scripts.  A smarter initscript/systemd module could automatically handle the issue (e.g., detect when a FQDN is given and set the name accordingly), but until that is done someday (if ever), the current procedure should be documented correctly in all places it occurs.

I will add that even if the currently vague directions to set an FQDN are not considered an error, the documentation, man pages, etc., all need clarification at the very least.  Some mention, even if "this is unspecified", should be made regarding the hostname setting of hosts with multiple IP address, and hence, multiple DNS names, at least in sysconfig.txt (part of initscripts package) and in the Fedora System administrator's guide (under network interfaces).

See also the man page uname(2) Notes section.
Comment 1 Jack Reed 2013-04-02 21:07:28 EDT
(In reply to comment #0)
> Unless this undocumented procedure is followed, the output of the hostname
> command and the hostname -f command is the same, which may have some minor
> consequences.  (I can't be sure but I feel there may be a security issue
> with having systems failing to correctly identify their FQDNs; I hope
> someone smarter than I will think about that.) SysAdmins need to add a line
> to /etc/hosts to enable the translation, and to set the short hostname.  But
> this is not what any documentation says to do.

Trevor, can I get your opinion on whether the identical output of hostname and hostname -f is an issue that we need to address? Is there a security concern here?

I need to establish if this is a foundational problem, because in that case changes to the documentation would need to come later once the problem has been remedied.
Comment 3 Trevor Jay 2013-04-02 23:19:14 EDT
Accidentally posted my last comment privately and sans spell-check:

The security issues here are minor. hostnames are not cannocial and should not be trusted. Any security issue arising from the hostname settings are bugs in the related system components (for trusting the hostname settings inappropriately or depending on them superseding other information sources) and not the hostname mechanism/process per-se.

As to the localhost ordering issue, I can confirm that F18 corrects this.

On some scripts expecting /etc/sysconfig/network to be a short-name, it's probably best to consult the related systems teams on their intentions. This is in some sense an "arbitrary" matter. If it's the engineering intention that users only use short names, for example, then the documentation should be changed to reflect that. However, if the intention is to support both but there are issues with the way the current system is implemented then the current problems are the result of implementation bugs that need to be filed against those subsystems.
Comment 4 Jack Reed 2013-04-03 00:12:40 EDT
Thanks, Trevor. Now that we've established there's no security issue, I'll ask Radek for his thoughts on whether this bug poses a problem in light of your other observations.

(In reply to comment #0)
> In a nutshell, the init scripts that read the hostname from
> /etc/sysconfig/network (or other files) do not want an FQDN.  On all RH and
> Fedora systems on which I've examined the init code, the correct way is to
> set the non-FQDN hostname via the hostname(1) command or hostname(2)
> systemcall (or set the shortname in the various config files, which is
> really the same thing).  RH and Fedora do a lookup in /etc/hosts to find the
> FQDN.  Thus, an entry needs to be manually added to /etc/hosts to enable
> this lookup; the IP address of the entry doesn't seem to matter and I use
> 127.0.0.1 if the host doesn't have a static IP.
> 
> Unless this undocumented procedure is followed, the output of the hostname
> command and the hostname -f command is the same, which may have some minor
> consequences.  <snip> SysAdmins need to add a line
> to /etc/hosts to enable the translation, and to set the short hostname.  But
> this is not what any documentation says to do.

Radek, looking at this in conjunction with Trevor's comments, do you see an issue here? I don't think documenting a workaround for edge cases is necessarily the way to proceed if there is a problem with the processes themselves, but the question is whether those processes need to be looked at.

If you agree, could you reassign this bug to the correct networking team? Or if you do feel that documentation is the best approach, let me know.
Comment 6 Petr Bokoc 2015-10-19 16:29:35 EDT
This bug is ancient and I think it's been fixed a long time ago, so I'm going to close it. If the problem persists, please reopen it.

Note You need to log in before you can comment on or make changes to this bug.