Sorry I'm a bit late contributing to this discussion.
Christoph Anton Mitterer wrote:
> The eventual result[1] was that Debian nowadays ships
> /etc/hosts like these per default:
>
> 127.0.0.1 localhost
> 127.0.1.1 <host_name>.<domain_name> <host_name>
>
> As also described in the Debian reference[2].
That's not entirely accurate. Wheezy and Ubuntu Desktop install
an /etc/hosts like the following, without a domain_name.
127.0.0.1 localhost
127.0.1.1 <host_name>
The Debian Reference is out of date.
Some years ago it was the case that if a machine had a static
external IP address then this was listed instead of '127.0.1.1'.
I presume that this is still the case but I haven't checked
(and I am on the road, so can't easily check, sorry).
> The hostname is not necessarily a domain name, at least not
> de jure.
Right. Ideally nothing would blindly treat the system hostname
as a domain name. I don't know how that practice ever got
started, but it overlooked the fact that machines can have
multiple domain names and multiple IP addresses, any of
which can be externally administered and any of which can
be changed at any time. The machine itself doesn't even know
when its domain names change.
> But in reality, many programs and people rely or are at least
> used to the hostname being resolvable.
> That practise won't change and we cannot do much about it.
That seems too pessimistic to me. If there are broken programs
we can patch them.
> - Most applications that listen to the loopback actually
> only listen to 127.0.0.1 (and perhaps ::1) but often not
> to 127.0.0.0/8.
Last time I checked, most applications that listen on 127.0.0.1
listen on all addresses, thus including 127.0.0.0/8. This is why
resolving the hostname to 127.0.1.1 actually causes few if any
problems in practice.
> => so the overall proposal (I) is:
> If no one has any technical reasons against, can we stop using
> 127.0.1.1 and let the hostname point to 127.0.0.1 as in:
> 127.0.0.1 localhost
> 127.0.0.1 foobar[.bar.net foobar]
Strictly speaking, each IP address in /etc/hosts should be
represented by no more than one line.
Your proposal has the consequence that 'localhost' is the
canonical name for 'foobar'. Please don't do this. I don't
want to return to the days of 'localhost' appearing in log
files and command line prompts.
Simon McVittie wrote:
> libnss-myhostname is basically this, and is packaged. It tries
> to return a public address if possible, only falling back to
> 127.0.0.2 (upstream), 127.0.1.1 (as patched in Debian) or ::1
> (IPv6) if there's nothing more suitable.
This is exactly what you need if you need the system hostname
to be resolvable to an IP address. (And I am prepared to believe
that we still need that, even though I haven't tested it recently.)
With the nsswitch configuration
hosts: files ... dns ... myhostname
myhostname resolves the system hostname if nothing else does
so first. So it can be overridden either by DNS or by /etc/hosts.
If the system hostname changes, no file has to be edited. Nice.
Also nice is the fact that myhostname resolves the system hostname
to an external address if there is one, increasing the chances that
the result is similar to what would be obtained from DNS.
Wouter Verhelst wrote:
> The right way, in my opinion, is that /etc/hosts should
> look like this:
>
> 127.0.0.1 localhost
> 127.0.0.1 hostname.domain hostname
Strictly speaking there should be no more than one line per
IP address, so that would be
127.0.0.1 localhost hostname.domain hostname
in which case 'localhost' is the canonical name for alias 'hostname'.
> or, alternatively:
>
> 127.0.0.1 hostname.domain hostname localhost
In that case 'hostname.domain' is the canonical name for alias 'localhost'.
Before any move is made to conflate the system hostname with
'localhost' in this way I'd like to see some proof that this no longer
causes any malfunction, or if it does cause malfunction (e.g.,
'localhost' appearing in log files) then I'd like to see the
malfunctioning packages fixed in advance of the transition from
127.0.1.1 to 127.0.0.1. And before making this potentially disruptive
change, I'd like to see evidence that the current practice actually
causes problems --- problems that can't easily be solved by patching
individual packages either to make them listen on 127.0.1.1 on the one
hand or to make them talk to localhost on the other.
--
Thomas Hood
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/cajn8kfcqbzh6scduqya1udjn397xo3wwvaj1mbfvzhvghkk...@mail.gmail.com
