On Thu, Apr 03, 2025 at 22:15:57 -0400, Jeffrey Walton wrote: > Yeah, I'm going to lookup what Stevens has to say about the hosts file > in TCP/IP Illustrated. I need to figure out where the confusion lies.
Here's what the Debian manual has to say about it: <https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_hostname_resolution> The IP address 127.0.1.1 in the second line of this example may not be found on some other Unix-like systems. The Debian Installer creates this entry for a system without a permanent IP address as a workaround for some software (e.g., GNOME) as documented in the bug #719621. That's the wrong bug number. <https://bugs.debian.org/719621> says: The Debian Installer creates this entry for a system without a permanent IP address as a workaround for some software (e.g., GNOME) as documented in the bug #316099. http://bugs.debian.org/316099 And <https://bugs.debian.org/316099> says: netcfg (1.13) unstable; urgency=low [ Thomas Hood ] * If there is no permanent IP address with which the system hostname (i.e., that which is returned by the "hostname" command) can be associated in /etc/hosts then associate it with address 127.0.1.1 rather than 127.0.0.1. Associating the system hostname with the latter had the unwanted effect of making 'localhost.localdomain' the canonical hostname associated with the system hostname. That is, 'hostname --fqdn' returned 'localhost.localdomain'. (Closes: #316099) Programs that access local services at the IP address obtained by resolving the system hostname SHOULD NOT DO THIS, but those that do so will not be disappointed: most services that listen locally listen on all 127/8 addresses, not just on 127.0.0.1. The word "GNOME" does not actually appear in #316099. Whatever GNOME was doing didn't make it into either of these bug reports. I'm just going to assume that it worked similarly to traditional X sessions (e.g. the ones on HP-UX), where it looked up the system's hostname, and used whatever IP address that returned for connections between the X client and server. In any case, having the system's hostname map to a nonfunctional IP address, or no IP address at all, causes enough problems that the 127.0.1.1 workaround for systems with no permanent address is a good and useful solution. It's been in use for two decades now.
