/etc/hosts: hostname alias of loopback

[Tim Johnson]

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

[Ralph Janke (txwikinger)]

Thank for reporting this issue.

None of my various ubuntu computers has the hostname assigned to the local address in this file. How did you install and/or configure your computer?

Thanks

[Tim Johnson (tuxim-deactivatedaccount)]

This was the default configuration. I think I used Ubuntu 7.10 Gutsy Desktop CD for Installation and upgraded to 8.04 Hardy.

[Tim Johnson (tuxim-deactivatedaccount)]

Is this a bad fix for bug 94048? Is there real no entry for 127.0.1.1 on your systems?

[Ralph Janke (txwikinger)]

127.0.* addresses are reserved for loopbacks. The name for the loopback address is usually localhost and sometimes localdomain is also used with another loopback address.

It is highly unusual to use the hostname for a loopback address. The issues with the xserver (and maybe also other applications) should IMHO not be fixed with a bandage like locally resolving the hostname to the loopback address.

[Tim Johnson (tuxim-deactivatedaccount)]

jim brown wrote on 2008-03-22: (bug #204824)
>Looked in /etc/hosts and entry
>
>127.0.1.1 brownie.mshome <-- this was the entry generated by the upgrade

[Michael Vogt (mvo)]

Thanks for your bugreport.

The release upgrader does nothing with /etc/hosts on the upgrade, this file is written by the installer. I reassign.

[Thomas Hood (jdthood)]

It is standard Debian and Ubuntu practice to add a line

    127.0.1.1 foo

to /etc/hosts, where foo is the content of /etc/hostname. This ensures that the
system hostname is resolvable to an address for which it is the canonical hostname
and an address, furthermore, where services on the local host can be reached.

If the machine has a permanent IP address (e.g., 123.45.67.89) and fully qualified
domain name (e.g., foo.bar.com) then this IP address and FQDN are listed as the
IP address and canonical hostname for the system hostname which is listed as an
alias.

    123.45.67.89 foo.bar.com foo

The 127.0.0.1 line should always be exactly as follows:

    127.0.0.1 localhost

There is no need to list "localhost.localdomain" here. The system hostname
should not be included on the 127.0.0.1 line as an alias.

[Thomas Hood (jdthood)]

This report can be closed.

[MarianoAbsatz (el-baby)]

Just a question, I usually install and configure my public servers inside my firewall using plain dhcp.

After I have them configured and self-firewalled, I move them to the public net and hand assign them an IP in /etc/network/interfaces.

At this point, IIRC, I should edit /etc/hosts and replace 127.0.1.1 with the public IP I'm giving to the server.

Is this right?

TIA

[Alvin (alvind)]

I just ran into bug 86021 because of the 127.0.1.1 line. XDMCP doesn't like that line. Changing it to an IP address is an acceptable workaround, but it isn't very user-friendly to have this included in every manual about XDMCP (and maybe other services).

[typo (gnomeuser8)]

This bug is fixed in maverick. NetworkManager 0.8.1 automatically sets the /etc/hosts file properly.

$ cat /etc/hosts
192.168.178.33 ubuntu # Added by NetworkManager

[typo (gnomeuser8)]

Your /etc/hosts should look like this:

192.168.178.33 ubuntu # Added by NetworkManager
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

[typo (gnomeuser8)]

You might also like to have a look at:
http://0pointer.de/lennart/projects/nss-myhostname/

nss-myhostname is a plugin for the GNU Name Service Switch (NSS) functionality of the GNU C Library (glibc) providing host name resolution for the locally configured system hostname as returned by gethostname(2). Various software relies on an always resolvable local host name. When using dynamic hostnames this is usually achieved by patching /etc/hosts at the same time as changing the host name. This however is not ideal since it requires a writable /etc file system and is fragile because the file might be edited by the administrator at the same time. nss-myhostname simply returns all locally configure public IP addresses, or -- if none are configured -- the IPv4 address 127.0.0.2 (wich is on the local loopback) and the IPv6 address ::1 (which is the local host) for whatever system hostname is configured locally. Patching /etc/hosts is thus no longer necessary.

[Thomas Hood (jdthood)]

#0. The original report seems to be that

    127.0.1.1 HOSTNAME

is not appropriate when the machine is on a local network.

That is not true. It is correct to resolve the local machine's
hostname to a loopback address.

The reason for choosing 127.0.1.1 as that loopback address
is that 127.0.0.1 is reserved for the special hosthame "localhost".
It is important that there be a one-to-one mapping between
loopback addresses and canonical hostnames, thus

    127.0.0.1 <---> localhost
    127.0.1.1 <---> HOSTNAME

#5. Here is is claimed that "[i]t is highly unusual to use the
hostname for a loopback address." Not true. It is actually
standard in Debian and Ubuntu, for the reason given above.

#10. Here is is asked "I move them to the public net and hand
assign them an IP in /etc/network/interfaces. At this point,
IIRC, I should edit /etc/hosts and replace 127.0.1.1 with the
public IP I'm giving to the server. Is this right?"

If a machine is given a *static* IP address then it is
acceptable, but not necessary, to replace "127.0.1.1" with
that static address in /etc/hosts.

#11. Here it is claimed that the 127.0.1.1. line needs
to be changed because XDMCP doesn't like it. It that is
true then it is, or was, a bug in XDMCP.

#12 claims that in Maverick NetworkManager futzes with
the /etc/hosts file, replacing the "127.0.1.1 HOSTNAME"
line with a "IP_ADDRESS HOSTNAME" line. That is
acceptable and probably introduced to work around bugs
in other applications, but should not be necessary. Local
applications are required to work correctly when
HOSTNAME resolves to 127.0.1.1, for the simple reason
that some computers are not connected to a network
and have no public IP address.

#14 mentions nss-myhostname. This is an alternative to
/etc/hosts futzing which is itself a workaround for bugs
in applications which don't work properly with

   127.0.1.1 <---> HOSTNAME.

But it is better to fix those bugs than to rely upon a
workaround.

This report can be closed.
--
Thomas Hood

[Thomas Hood (jdthood)]

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

[Thomas Hood (jdthood)]

I just wrote:
> 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.

Sorry, I should have said "... provides address 127.0.1.1 for..."

[Thomas Hood (jdthood)]

I have just filed bug #1015030 to suggest that nss-myhostname be used to supply the

    127.0.1.1 <UNIX-hostname>

mapping instead of a line in /etc/hosts.