Re: Revisiting the hostname/FQDN issue, adding libnss-myhostname
Hi Simon,
On Mon, Oct 13, 2025 at 11:51:58PM +0100, Simon McVittie wrote:
On Mon, 13 Oct 2025 at 22:22:45 +0200, Marc Haber wrote:
The biggest question that I still have is why we are writing an
/etc/hosts with "127.0.1.1 apollo.example.com apollo". Without that,
the FQDN of the system is incorrect.
For some value of "incorrect",
The value is that hostname --fqdn returns "hostname: Name or·↲
service not known" after waiting for a timeout. ltrace reveals that
getaddrinfo("toe-sid-buildd-amd64-a1gg", nil, 0x7ffef1933eb0, 0x7ffef1933ea8) = 0
times out when the 127.0.1.1 entry is not there.
anyway: a large part of the problem
here is that there's no formal specification I'm aware of for what is
considered "correct" or "incorrect", only Unix folklore and some
strong opinions (some of which might be contradictory). Some software,
especially if it has decades of history, assumes that the hostname (as
in gethostname(2)) is resolvable in DNS, but that isn't something that
can generally be guaranteed, especially for a portable machine on a
network not under your control. Typically[citation needed] laptop
owners expect the laptop "apollo" to remain named "apollo" when they
connect it to someone else's LAN, even if the network owner has
decided that the IP address allocated to "apollo" by their DHCP will
be associated with something like "guest01.internal" in their local
DNS.
I would expect that for a stationary machine with a static IP both
hostname and hostname --fqdn return the correct values.
The hostname(1) man page defines the FQDN as the name that the
resolver returns when asked for information about the hostname (as in
gethostname(2)), and notes that by this definition there might be
zero, one or many FQDNs. If the FQDN isn't forced via /etc/hosts, then
it might also vary according to the LAN(s) that the machine happens to
be connected to right this moment (especially for mobile computers).
So it is a good idea to have the 127.0.1.1 entry (or one using the
static IP address) in place if you want ONE FQDN returned.
One way to describe the purpose of libnss-myhostname is: we know that
some software assumes that the result of gethostname(2) is resolvable;
and we know that this can't be guaranteed to be true in the global DNS
system because mobile computers are a thing that exists; so let's
force that assumption to be true at least locally, by having a
last-resort mechanism to ensure that the local hostname always
resolves to a locally-available IP address at any given time, to try
to maximize the amount of software that has its assumptions met and
continues to work as designed.
With libnss-myhostname installed, getent hosts hostname returns the
short host name while without libnss-myhostname it returns the 127.0.1.1
entry that contains an FQDN.
I find the variant that libnss-myhostname returns significantly less
informative. The short host name is also available in the kernel.
But why 127.0.1.1? Arch Linux does it the same way, but they don't
explain why, either.
127.0.1.1 is one of the 256**3 loopback addresses (the whole 127.x
block). I believe the reasoning for using that, and not 127.0.0.1, is
that it means a reverse-DNS lookup for 127.0.0.1 (for example in the
output of netstat, to label a service listening on only the loopback
interface) will yield the expected "localhost", and not
"apollo.example.com" which would be surprising.
libnss-myhostname does this dynamically rather than by writing static
configuration, so it will try to use one of the machine's reachable IP
addresses (192.0.2.123 or something), falling back to 127.0.0.2 if
there's nothing better available. 127.0.0.2 is conceptually similar to
127.0.1.1, just a slightly different implementation choice.
Should libnss-myhostname and the Installer not use the same loop back
address? Considering that there are efforts on the way to reduce the
loopback range to 127.0.0.0/24, should the installer change to
127.0.0.2?
On some of my trixie systems (but not on all of them),
libnss-myhostname got installed. This changed the nsswitch.conf
"hosts: files dns" to "hosts: files myhostname dns".
libnss-myhostname is meant to be conceptually equivalent to putting
something similar to the conventional "$ipaddress apollo" into
/etc/hosts, hence its position close to "files" (which is the plugin
that actually implements /etc/hosts lookup).
the conventional thing in Debian would be "$ipaddress fqdn shortname".
Because it's sequenced after "files" in nsswitch.conf, whatever is
manually configured in /etc/hosts should usually take precedence, but
small details can matter here.
That does not seem to work. See below.
On those systems, getent hosts hostname returns the short hostname,
while on the systems that don't have myhostname installed the same
call returns the FQDN.
On a typical affected system, what is in /etc/hostname and what is the
result of uname(2)? An easy way to query this interactively is:
cat /etc/hostname
python3 -c 'import os; print(repr(os.uname()))'
7/1402]mh@rasp:~ $ hostname --fqdn
rasp.zugschlus.de
[8/1403]mh@rasp:~ $ hostname
rasp
[9/1404]mh@rasp:~ $ cat /etc/hostname
rasp
[10/1404]mh@rasp:~ $ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 rasp.zugschlus.de rasp
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
[12/1405]mh@rasp:~ $ getent hosts rasp
2001:16b8:a99e:89fe:e65f:1ff:fe29:6448 rasp
2a01:238:43fa:bc82::12:100 rasp
fe80::e65f:1ff:fe29:6448 rasp
[13/1405]mh@rasp:~ $ python3 -c 'import os; print(repr(os.uname()))'
posix.uname_result(sysname='Linux', nodename='rasp', release='6.17.3-zgrpi4', version='#5 SMP PREEMPT_DYNAMIC Wed Oct 15 16:05:36 UTC 2025', machine='aarch64')
[14/1406]mh@rasp:~ $
On a comparable system without libnss-myhostname installed, the output
is the same, just that getent hosts rasp would return
127.0.1.1 rasp.zugschlus.de rasp
The output of os.uname() doesn't change with the library present or not
present.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Reply to: