Description of problem: The loopback address should always be "localhost" whether it's IPv4 or IPv6. Currently the IPv6 loopback is defined as "localhost6" rather than "localhost." Applications are generally written to use the loopback address as "localhost." They shouldn't have to care whether the IP version is 4 or 6. For example, on an IPv6 remote host, X cannot connect to "localhost:10.0" to tunnel X over ssh if localhost is not ::1. Version-Release number of selected component (if applicable): F11-Alpha How reproducible: Always Steps to Reproduce: 1. Install F11 on a remote X client 2. Configure sshd on client to support IPv6 only (AddressFamily inet6) 3. From a local X server "ssh -X <remote-ipv6-X-client>" 4. xclock (or any X application) Actual results: Error: Can't open display: localhost:10.0 Expected results: xclock (or any other X application) runs on local X server Additional info: Changing /etc/hosts so that both 127.0.0.1 and ::1 are defined as localhost and inserting "multi on" in /etc/host.conf allows X to work as expected. Note that F9 did/does not need the entry in /etc/host.conf for resolution of multiple lines, only the edit to /etc/hosts. I'll file a separate bug/enhancement-request for setup.noarch. Also note that there's an assertion in Bug 211800 that defining both 127.0.0.1 and ::1 as localhost breaks some things, but doesn't say exactly what things. The implication seems to be about programs that _change_ /etc/hosts (e.g., system-config-network) getting confused if there are both defined. Shouldn't that be considered a bug in those programs, not in /etc/hosts? For out-of-the-box IPv6-only (or dual-stacked operation), gethost* functions should return IPv6 (or both IPv6 and IPv4) addresses for "localhost" without having to edit /etc/hosts to make IPv6 networking work.
See Bug 486461 for the /etc/host.conf enhancement.
I'm ok with making this change, but I can't do anything until the setup package changes.
It looks like Bug 483244 has been thrown into the mix as well. In that bug, the poster suggests that setup take over /etc/hosts.
And that's even better, IMHO. Will see what becomes of that.
setup Bug 483244 is going to handle creating /etc/hosts and defining the loopback names (probably minus the unique host name, I'm sure). It's worth taking note that anaconda shouldn't try to create /etc/hosts now. I'm closing this report as duplicate since its handled by a different bug report, even though it's only sort of duplicate since it's also a different package that's implementing the fix for pretty much a different reason. *** This bug has been marked as a duplicate of bug 483244 ***