Those interested in this topic might want to read Debian bug report
#267321 which documents the introduction of the "127.0.1.1 <hostname>"
line in /etc/hosts.
"Typo" drew our attention in #14 to nss-myhostname. That reminded me of
comment #96[0] in Debian bug report #267321 in which I said:
> A better solution would be as follows. It requires writing
> a new nss-providor database named "files2" which works
> like "files" but consults /etc/hosts2 instead of /etc/hosts.
[...]
> And set up /etc/nsswitch.conf:
>
> hosts: files dns files2
That was in 2004. The problem that this was meant to solve was the fact that
/etc/hosts is needed to play two different and mutually incompatible roles. It
is needed to provide a _default_ address for the UNIX hostname (or other name)
in case that name can't be resolved in any other way. And it is needed as a
way of _overriding_ the results of other name resolution mechanisms. But
according to the current design of glibc it is only possible for /etc/hosts to
play one role or the other, not both. That is, with
hosts: files <other stuff>
/etc/hosts overrides, but with
hosts: <other stuff> files
it provides defaults.
Now, normally nsswitch.conf contains "hosts: files <other stuff>", so
some other solution is needed for providing default addresses. And
that's why I suggested that a "files2" nss provider be coded up. Lennart
Poettering understood this problem and, supercoder as he is, pounded out
a new nss provider, nss-myhostname, in 2005 to perform the providing-
defaults function. It is used this way:
> hosts: files dns myhostname
He decided to hard-code the default addresses rather than support a
second configuration file. He happened to choose 127.0.0.2 as the
alternative loopback address instead of 127.0.1.1 but if we were to
adopt this for Ubuntu we could easily change it.
OK, Lennart, cool. Should Ubuntu adopt this? I think so, but the
urgency is not very high given that the current configuration, with
127.0.0.1 localhost
127.0.1.1 <UNIX-hostname>
in /etc/hosts works very well on many thousands of systems.
One reason it works well is that most services that listen on lo listen
on all addresses, including 127.0.1.1. Another reason is the following.
Suppose the machine with name N is about to connect to a LAN and get an
IP address via DHCP. /etc/hosts provides address 127.0.0.1 for the UNIX
hostname, N, without qualification. Once the machine is connected to
the LAN the name ⌜N.S⌝ resolves to the machine's external IP address.
In practice the two don't conflict.
The original submitter wrote:
> When an application want to know your ip adresss, it will get 127.0.1.1. But
> this is not your ip adress in your local network!
He seems to be under the impression that the UNIX hostname should always
resolve to an external IP address. But mobile systems don't always have
an external IP address and the address can change as the machine moves
from one LAN to another. The assumption underlying the original
complaint is incorrect.
[0]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267321#96
** Bug watch added: Debian Bug tracker #267321
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267321
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/234543
Title:
/etc/hosts: hostname alias of loopback
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/234543/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
