/etc/hosts for Debian

Question

I was trying to get a perl script that contacts a PostgreSQL database to work on a server. This script was mysteriously failing. I then realised that localhost was not in the /etc/hosts file.

The file for this machine (currently running Debian lenny) currently looks like

127.0.0.1       machinename.domain   machinename
xxx.xx.x.xxx    machinename.domain   machinename

The xxx.xx.x.xxx is the IP address. The file for my current home machine, which is a slightly older installation (currently running Debian squeeze) is

127.0.0.1       machinename          localhost
127.0.1.1       machinename.domain   machinename

My home machine sits behind a router and is not directly exposed to the internet. In any case, I'm on DSL and have no static IP address.

I've kept /etc under version control for my machines (using etckeeper) for some time, and I see that for this server, the following change was made by some mastermind (possibly myself) on Dec 17th 2009.

-127.0.0.1      localhost
+127.0.0.1      machinename.domain  machinename

I've wondered before why this file is set up the way this is, but the answer is not obvious. Some questions:

1. Why 127.0.1.1? This might be a Debian-specific bit of history. I did a bit of searching on the net, and found some vague mutterings about Gnome, but little of any substance.

2. Where in Debian is the template this file is set from?

3. Is there currently considered to be a correct/best form for this file?

4. Is the order of the names in the line significant? I hope not.

More generally, what is the explanation of why these two lines are structured the way they are?

For now, I think I'll change the server /etc/hosts to

127.0.0.1       machinename.domain  machinename localhost
xxx.xx.x.xxx    machinename.domain  machinename

Comments?

Answer 1

Summary

You should have always have

127.0.0.1    localhost.localdomain localhost

In your case, because you don't have a permanent IP address, you can also have

127.0.1.1    machinename.domain machinename

This line seems to be required for some applications like GNOME, but it might actually cause problems with other applications!

See Proposed new scheme for resolving the system hostname.

---

Effectively your machine has two host names.

localhost.localdomain is the name used for private communications between two TCP/IP-capable processes running on the same machine.

machinename.domain is the name used for communications between your machine and machines connected to your machine.

You always want localhost.localdomain to point to 127.0.0.1 (and ::1 if you are using IPv6). That way, all communication between two TCP/IP processes on the same machine will use the lo (loopback) interface, which is usually allowed by firewalls such as iptables, and nothing has to worry about whether your network is available or whether DNS is working.

Some applications such as GNOME ¹ try to use your machine's public name for everything, even when talking to the same machine. This is so that one part of GNOME can talk to another part of GNOME, even if it's running on a different machine on your network. (The N in GNOME originally stood for "network".)

Ideally, your machine's name is known using DNS or some other shared database that other machines can also use to determine your machine's address, so that applications on other machines can talk to your machine.

But if your machine's name isn't in DNS, or DNS isn't working, programs like GNOME still need a way to talk to itself.

There have been various ways of modifying /etc/hosts to make this work.

The most common used to be

127.0.0.1    localhost.localdomain localhost
w.x.y.z      machinename.domain machinename

where w.x.y.z is the address of your primary network interface, e.g. eth0.

That worked OK if your system used a static IP address and was always connected².

If your system had a dynamic IP address, various scripts were used to edit /etc/hosts to include an entry based on what the DHCP server returned.

But if your system didn't have a permanent network connection, you couldn't add an entry like that because you didn't have a single reliable address.

So then people started doing something like

127.0.0.1    localhost.localdomain localhost machinename.domain machinename

or

127.0.0.1    machinename.domain machinename localhost.localdomain localhost

That way, processes that use TCP/IP could still talk to other processes on the same machine, even if they looked up the IP address using the machine's name.

But it broke other applications.

For example, dnsdomainname.

I also remember there being problems where only people on the same machine could connect to a server because the server was only listening³ for connections on the loopback device.

The program would get the machine's name, then look up the address of name, and use the first address found, and bind to that network interface. If your machine's name resolved to 127.0.0.1⁴ address, that meant the service you thought was running on machinename.domain (and was thus available to the whole network), was really only available to other processes running on the same machine.

As Andy points out, the order of the names shouldn't matter. Something trying to look up the host name for 127.0.0.1 would get the first name as the canonical/official/primary name of the host, but because it would resolve forwards and backwards, I can't think how this would cause any problem, unless there is some automated tool for editing /etc/hosts that expects one format or the other.

But I think you should always have a fully-qualified domain name (i.e. a name that includes a domain name) first as I mentioned in format of /etc/hosts.

There is another similar format that uses two lines instead of one, e.g.

127.0.0.1    localhost.localdomain localhost
127.0.1.1    machinename.domain machinename

This is a neat trick, because lo's address is really 127.0.0.1/8, meaning any address in the 127 network is the loopback device.

I assume this format was used so that tools that need to change the entry for your machinename.domain can do so without touching the 127.0.0.1 localhost... entry.

But note that it still causes machinename.domain to map to lo, so it can still cause the problems I mentioned.

I also just booted up Fedora 15 in a VM and logged into the Gnome desktop, and I couldn't see any TCP/IP connections. They all seem to be using UNIX sockets. So perhaps the 127.0.1.1 entry is no longer needed.

---

Footnotes

1. This used to be the case. On my Fedora 15 test machine, it seems to be using UNIX sockets rather than TCP/IP.
2. Except during system boot before the network has been started.
3. Really "bound" rather than "listening".
4. Or any 127.x.x.x address.

Answer 2

On my system, I have the following in /var/lib/dpkg/info/netbase.postinst:

create_hosts_file() {
  if [ -e /etc/hosts ]; then return 0; fi

  cat > /etc/hosts <<-EOF
        127.0.0.1       localhost
        ::1             localhost ip6-localhost ip6-loopback
        fe00::0         ip6-localnet
        ff00::0         ip6-mcastprefix
        ff02::1         ip6-allnodes
        ff02::2         ip6-allrouters

EOF

My netbase version is 4.45.

I would expect that the first name on the line will be returned for a reverse lookup of the IP address, otherwise I doubt the order matters.

Answer 3

I've wondered before why this file is set up the way this is, but the answer is not obvious.

Adding or removing a line from a text file is pretty easy to script.

Editing a line in a text file to add or remove components is much harder.

So it's really easy to write a script that runs "hostname -s" and "hostname -f", deletes 127.0.1.1 from /etc/hosts and adds a new one with the results of hostname.

But it's a lot harder to write a script that removes whatever the hostname used to be from the line containing 127.0.0.1 (without disturbing entries added manually by the operator) and then add the current hostname to the localhost entry.