Description of problem:
When installing on a new machine configured with a static IP address,
the /etc/hosts file is left with the hostname's IP address
still set to 127.0.0.1 instead of the host's own IP address.
127.0.0.1 is the correct value for the 'localhost' entry in /etc/hosts
but not for the machine's own hostname; that should be the static
IP assigned address (when a static IP is assigned).
Version-Release number of selected component (if applicable):
Always. Goes back a long way (redhat 7.x at least)
Steps to Reproduce:
1. install redhat, setting a static IP address
2. 'ping <hostname>' shows 127.0.0.1 instead of host's own IP
127.0.0.1 tahoe localhost
Breaks certain network daemons that try to bind to the network
interface by doing a forward lookup on the host's hostname, using
gethostname() -> gethostbyname() -> host's IP address.
NOTE: 'installer' is not an item in the 'Component' chooser in the bug
form, so I used 'setup'.
This is required to keep other daemons from hanging on startup if you
have a hostname set and yet don't have your network initialization
work for some reason (eg, pcmcia)
Unfortunately there isn't a great answer for this but the current
solution is the one that causes the least problems.
In the interest of possibly resolving the cause of the problem..
Is it known which daemons are the cause of this?
Is it a situation where network daemons are hanging on boot,
preventing the machine from coming up if a network cable isn't plugged
in, or if a PCMCIA card is removed?
I've seen cases where eg. mounts to remote machines hang if networking
is off. The solution is to add the 'bg' flag to the mount, so that the
mount backgrounds itself, allowing the machine to continue booting
I would expect a network oriented daemon like sendmail to hang or fail
if the network isn't running, but in such a case the daemon should
not even be started if the boot scripts determined the network failed
I believe SGI handles this by setting a variable on boot to indicate
whether low level networking has successfully initialized, signaling
all subsequent network oriented daemons whether they should start or
not.. if the network fails to start, SGI prints a warning 'Using
standalone network mode', and cc's this to the syslog as well. In this
case, network oriented daemons are not even started. I believe they
use chkconfig to implement a global 'network' flag that the network
daemon boot scripts check before starting the daemon; if the flag
indicates the network isn't running, the daemon boot script skips
starting the daemon, optionally logging an error.
It just seems like something that should be resolved; using 127.0.0.1
is just wrong, and is something admins have to change, and
subsequently run into the hang-on-boot problem anyway, and will have
ad hoc checks in the boot scripts so they'll do what the default
scripts should probably do already; skip starting network dependent
daemons if networking fails to start.
Or at least, it seems that should be the case.
Possibly the thing to do is wait until a dependency mechanism is
implemented into the boot scripts.. something probably a tool as
simple a chkconfig could help implement cleanly/clearly.
I understand the real life scenarios can be varied, and there are so
many possible network devices all with random boot scripts, it might
be impossible logistically to have the Fedora distro include custom
boot script hacks to implement network checks, but it still leaves the
user to pick up the pieces afterwards.
Just a thought.
I am willing to help arrive at a solution, ie.
investigate/simulate/solve if possible.
Or I'll let sleeping dogs lay, if that's more desireable.