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): 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 127.0.0.1 instead of host's own IP Actual results: /etc/hosts: 127.0.0.1 tahoe localhost Expected results: /etc/hosts: 127.0.0.1 localhost 192.168.1.2 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'.
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 normally. 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 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.