Re: DHCP and static addresses, nothing to do with Re: Who:Bookwormv.Trixie

[Greg Wooledge <greg@wooledge.org>]

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.