Bug 127445 - Installer incorrectly configures /etc/hosts when static IP assigned
Summary: Installer incorrectly configures /etc/hosts when static IP assigned
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda   
(Show other bugs)
Version: 2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2004-07-08 11:25 UTC by Greg Ercolano
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-07-09 03:21:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Greg Ercolano 2004-07-08 11:25:22 UTC
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 instead of the host's own IP address. 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):

How reproducible:
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 instead of host's own IP
Actual results:
/etc/hosts: tahoe localhost 

Expected results:
/etc/hosts:   localhost tahoe

Additional info:

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

Comment 1 Jeremy Katz 2004-07-09 03:21:43 UTC
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.

Comment 2 Greg Ercolano 2004-07-09 13:11:15 UTC
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
to initialize. 

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

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