[Bug 234543] Re: /etc/hosts: hostname alias of loopback

[Thomas Hood]

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
Foundations Bugs, which is subscribed to netcfg in Ubuntu.
https://bugs.launchpad.net/bugs/234543

Title:
  /etc/hosts: hostname alias of loopback

Status in “netcfg” package in Ubuntu:
  Opinion
Status in “ubiquity” package in Ubuntu:
  Opinion

Bug description:
  There is a bug in /etc/hosts. Your hostname is NO alias of 127.0.1.1.
  Only "localhost" is an alias for the loopback. 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!

  This is not right:
  127.0.1.1	HOSTNAME

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/234543/+subscriptions