From: smcv@debian.org 
  
 On Mon, 13 Oct 2025 at 22:22:45 +0200, Marc Haber wrote: 
 >a new (?) systemd feature 
  
 libnss-myhostname started as an independent NSS module before being 
 absorbed into the systemd codebase for more code-sharing (much like 
 udev). There's nothing *particularly* systemd-specific about it. 
  
 >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", 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. 
  
 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). 
  
 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. 
  
 I'm sure we could write a surprisingly lengthy document similar to the 
 classic "Falsehoods Programmers Believe About Names", but for hostnames. 
  
 >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. 
  
 >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). 
  
 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. But because it's sequenced before "dns", 
 it prevents a non-local DNS server (like the one on the wifi network 
 outside your control that you connected your laptop to) from influencing 
 what the machine thinks its own FQDN is. 
  
 >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()))' 
  
 (It's fine if your answer is redacted to remove the system's real 
 hostname and DNS domain name and instead pretend that it's 
 apollo(.example.com) or something, but please be specific about the 
 number and position of dots, because they can matter. Similarly it's 
 fine to redact the kernel version, etc. which aren't interesting here) 
  
 >How much our current behavior is standard Unix, how much are Debianisms? 
  
 I think we can safely assume that it's all Unix, even (especially?) the 
 contradictory parts, but none of it is standard. 
  
      smcv 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)