From: mh+debian-devel@zugschlus.de 
  
 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', m 
 chine='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 
  
 [continued in next message] 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)