Bug 486457

Summary:	IPv6 loopback definition in /etc/hosts
Product:	[Fedora] Fedora	Reporter:	Allen Kistler <ackistler>
Component:	anaconda	Assignee:	David Cantrell <dcantrell>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	rawhide
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-02-25 17:53:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	486461
Bug Blocks:

Description Allen Kistler 2009-02-19 20:42:26 UTC

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.

Comment 1 Allen Kistler 2009-02-19 21:07:55 UTC

See Bug 486461 for the /etc/host.conf enhancement.

Comment 2 David Cantrell 2009-02-19 22:37:49 UTC

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 14:12:09 UTC

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 22:31:12 UTC

And that's even better, IMHO.  Will see what becomes of that.

Comment 5 Allen Kistler 2009-02-25 17:53:11 UTC

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