+++ This bug was initially created as a clone of Bug #529898 +++ Description of problem: Apparently on a newly installed F-12 system, anaconda adds the fully qualified domain name to /etc/hosts as 127.0.0.1: # hostname sun-x8450-01.rhts.eng.bos.redhat.com added to /etc/hosts by anaconda 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 sun-x8450-01.rhts.eng.bos.redhat.com ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 sun-x8450-01.rhts.eng.bos.redhat.com This causes getaddrinfo() to fail spectacularly, as it always resolves to localhost, and never gets the fully qualified domain name back. This breaks, among other things, libvirt live migration, which depend on getaddrinfo() to do it's work (see https://bugzilla.redhat.com/show_bug.cgi?id=528793).
There's no need to open duplicates of RHEL6 bugs for Fedora as they're the same code base right now and we are operating under the assumption that all RHEL6 bug fixes need to make it into Fedora. Reassigning to David like the original is, in case he wants to leave both open for some reason.
Ah, OK. I wasn't sure what the procedure was, I just wanted to make sure that this was on the F-12 blocker list. I'll leave it open for now, and dcantrell can close it as a dup of the other one if he wants to. Thanks, Chris Lalancette
We discussed this in the blocker meeting today. Consensus was that this change may be desirable for RHEL 6 but is not for Fedora 12, we have several months of testing based on current behavior and changing /etc/hosts always has unpredictable results. This change will not be made for F12, will be made for F13 branch of Anaconda. Dropping from F12 blocker list. Anaconda devs, please do not change this in F12 branch. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
It is possible to add the actual host-name specified by by the user during install to a separate line in /etc/hosts instead of adding it as an alias to the localhost name, by borrowing another address from the loopback range (this is how Ubuntu does it, by the way): 127.0.0.1 localhost.localdomain localhost 127.0.1.1 myhost.mydomain.tld myhost This way «hostname -f» will correctly return «myhost.mydomain.tld» instead of «localhost.localdomain» as it currently does by default. Since the host's fully-qualifed host name is used for stuff like generating the domain part of outgoing e-mails, it would be quite nice to get this fixed. Another thing: what's up with the «.localdomain» stuff? The canonical name for the localhost should be «localhost», not «localhost.localdomain». At least RFC 2606 specifies «.localhost» as a reserved _TLD_ for this very reason, and this is also the default PTR record for 1.0.0.127.in-addr.arpa. in the bind package. So in my opinion, if I enter «myhost.mydomain.tld» as the host name during install I should have ended up with a /etc/hosts file containing: 127.0.0.1 localhost 127.0.1.1 myhost.mydomain.tld myhost Or, in order to preserve backwards compability with applications/users that have gotten used to this «localhost.localdomain» strangeness it could be kept as an alias, like so: 127.0.0.1 localhost localhost.localdomain 127.0.1.1 myhost.mydomain.tld myhost Tore
This will be fixed in anaconda-13.8-1. Anaconda will no longer modify /etc/hosts. What you get on the system is what the "setup" RPM provides. The /etc/hosts file provided by setup looks like this: 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 If you think those lines need to change, you'll need to open a bug against the setup package. As for using something like 127.0.1.1 for the hostname rather than overloading 127.0.0.1, that's just another form of the same type of hack we've been doing. The main problem we were trying to overcome were programs like sendmail, httpd, and gdm taking a long time to come up on a system with a disconnected network connection but having a hostname (i.e., the hostname is unable to be resolved without an active network connection). The correct fix is to patch the software to behave correctly so you don't even need an /etc/hosts hack. I've tested here with the latest rawhide and see that the problem programs that stood out before no longer exhibit this behavior.
(In reply to comment #5) > This will be fixed in anaconda-13.8-1. Anaconda will no longer modify > /etc/hosts. What you get on the system is what the "setup" RPM provides. > > The /etc/hosts file provided by setup looks like this: > > > 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 > ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 Great, that looks more correct. Thanks! Chris Lalancette
David, admittedly the 127.0.1.1 stuff is a hack, but it's the only way I know to make «localhost» be the fully-qualified hostname for 127.0.0.1 and still have the system hostname resolve properly. Without it you get a new problem - that the system do not have a fully-qualified hostname any longer (if this is an improvement on the earlier incorrect «localhost.localdomain» fully-qualified hostname or not I really don't know): [root@f12beta ~]# hostname f12beta.fud.no [root@f12beta ~]# LC_MESSAGES=C hostname --fqdn hostname: Unknown host This is on a fully updated F12 beta with a /etc/hosts file containing only the two lines you pasted above, by the way. Perhaps this is no problem if there exist no applications that actually wants to figure the fully-qualified hostname of the system, but I'm a bit sceptical if that's actually the case. Tore
(In reply to comment #5) > This will be fixed in anaconda-13.8-1. Anaconda will no longer modify > /etc/hosts. What you get on the system is what the "setup" RPM provides. I'm having problems in Fedora 12 because the hostname is being added to /etc/hosts on systems that should be receiving network information dynamically from DHCP. One consequence of having the hostname in /etc/hosts is that "hostname -f" returns "localhost". This behavior didn't happen in Fedora 11. Is the fix in anaconda-13.8-1 going into Fedora 12? Thanks.
Fedora 12 will not receive this fix. anaconda-13.x-1 will appear in rawhide as we work towards Fedora 13.
Hmm. I guess I'll just rewrite /etc/hosts manually for now. Thanks.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
even if we fixed it 'in f12', it wouldn't _mean_ a lot. the installer you use is always going to be the one that was in the release images, not any updated anaconda package that gets released later. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
In F12, changing the host name with system-config-network also modifies the loopback lines in /etc/hosts. In this case, it appears that only the host name, not the FQDN, is appended to the '127.0.0.1' and '::1' lines. This can cause problems as it also breaks "hostname -f". Whatever the "correct" behaviour at installation time, one would expect system-config-network to behave consistently with that. If I should be raising this issue separately as a bug against system-config-network then please let me know.
(In reply to comment #13) > In F12, changing the host name with system-config-network also modifies the > loopback lines in /etc/hosts. In this case, it appears that only the host > name, not the FQDN, is appended to the '127.0.0.1' and '::1' lines. This can > cause problems as it also breaks "hostname -f". > > Whatever the "correct" behaviour at installation time, one would expect > system-config-network to behave consistently with that. If I should be raising > this issue separately as a bug against system-config-network then please let > me know. Yeah, that's not good. Please file another bug against system-config-network so we can make sure that is fixed for F-13. Thanks, Chris Lalancette
*** Bug 555748 has been marked as a duplicate of this bug. ***