Why give each address family a name unique to its respective loopback
address? Here's how the question occurs to me:
/etc/hosts on Fedora and Red Hat defines localhost as 127.0.0.1 and
localhost6 as ::1 (at least it has since about FC6, sort of according to
BZ#211800).
"ssh -X" automatically defines DISPLAY as localhost:10.0 on the remote
system.
The port (6010) on the remote system is on ::1 (localhost6, as defined),
not 127.0.0.1 (localhost, as defined) when sshd_config specifies
AddressFamily as inet6.
Without redefining DISPLAY, I get the error "cannot open display:
localhost:10.0" when I try to start an X app. I can redefine DISPLAY as
localhost6:10.0 to work around it, but a better solution seems to be to
change /etc/hosts to something like ...
127.0.0.1 localhost localhost4
::1 localhost localhost6
... which is what Gentoo appears to do. (Those who know Gentoo at all
can feel free to correct me if I'm wrong.) Also I'm not entirely
convinced the localhost6 and localhost4 names are required, but they
might be handy in some cases.
There's an assertion in BZ#211800 that defining both 127.0.0.1 and ::1
as localhost breaks some things, but doesn't say what things. Well,
*not* defining both as localhost breaks things. (Mostly the bugs in
BZ#211800 seem to be about programs that _change_ /etc/hosts getting
confused if there are both defined.)
So the question really is: Is there a reason localhost is not both the
IPv4 loopback and the IPv6 loopback (*other* than hiding some bugs in
some programs)? Or should Fedora (and eventually Red Hat) change the
default /etc/hosts shipped/created with anaconda?
As more people implement IPv6, I'd suspect similar errors to show up.
FWIW, I've tested defining both loopbacks as localhost on a few boxes
with a few things on each (including inet/inet6/any for the sshd
AddressFamily). I haven't found anything that breaks, yet.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
