Bug 486457 - IPv6 loopback definition in /etc/hosts
IPv6 loopback definition in /etc/hosts
Status: CLOSED DUPLICATE of bug 483244
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
Depends On: 486461
  Show dependency treegraph
Reported: 2009-02-19 15:42 EST by Allen Kistler
Modified: 2009-02-25 12:53 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-02-25 12:53:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Allen Kistler 2009-02-19 15:42:26 EST
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):

How reproducible:

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 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 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.
Comment 1 Allen Kistler 2009-02-19 16:07:55 EST
See Bug 486461 for the /etc/host.conf enhancement.
Comment 2 David Cantrell 2009-02-19 17:37:49 EST
I'm ok with making this change, but I can't do anything until the setup package changes.
Comment 3 Allen Kistler 2009-02-20 09:12:09 EST
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.
Comment 4 David Cantrell 2009-02-20 17:31:12 EST
And that's even better, IMHO.  Will see what becomes of that.
Comment 5 Allen Kistler 2009-02-25 12:53:11 EST
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 ***

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