From: mh+debian-devel@zugschlus.de 
  
 Hi, 
  
 the way hostnames and FQDNs are determined on unixoid systems has been 
 a source of "fun" for decades. Debian has an ok-ish solution for that 
 which seems to have been recently influenced by a new (?) systemd 
 feature that of course changes things. 
  
 I have tried discussing this on debian-user-german and the 
 german-language Usenet and got even more confused. Hence, this seems 
 complicated enough to pester debian-devel with it. 
  
 As usual when I don't understand something, I have written down what I 
 know in a wiki page. This time, it is https://wiki.debian.org/Hostname 
  
 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. But why 127.0.1.1? Arch Linux does it 
 the same way, but they don't explain why, either. 
  
 And why do we handle systems that get installed with IP 
 autoconfiguration in a different way than we do for systems with their 
 IP statically set. Should we not generate the 127.0.1.1 line even in 
 the latter case? Do we, maybe? 
  
 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". 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. 
  
 This influences mail delivery. When libnss-myhostname is installed, exim 
 does not longer consider the FQDN to be a local domain€€. Having been on 
 the exim team for a decade, this triggers me. I don't think this change 
 is acceptable. 
  
 Deinstalling libnss-myhostname solved the issue on my trixie systems. 
  
 Why did libnss-myhostname get installed? What does it do, what is its 
 purpose? Are we aware that installing this package will break our 
 default MTA? 
  
 Other people solves this by putting the FQDN in /etc/hostname. I am not 
 sure whether this is a viable solution. For me, it's enough proof that 
 the Debian Installer does it differently. 
  
 In a side node, the pymilter upstream has a - in my opinion - rather 
 strange way of seeing a short host name, saying that it actually should 
 be a FQDN: 
 https://gathman.org/pipermail/pymilter/2025-March/000527.html. Do we 
 have an opinion about that? Python people in my bubble say that pymilter 
 should be calling socket.getfqdn() instead socket.gethostname() to fix 
 its behavior on a default Debian install. 
  
 How much our current behavior is standard Unix, how much are Debianisms? 
  
 Greetings 
 Marc 
  
 €€ quoting from exim's spec.txt: 
 |    This variable contains the value set by primary_hostname in the 
 |    configuration file, or read by the uname() function. If uname() 
 returns a 
 |    single-component name, Exim calls gethostbyname() (or getipnodebyname() 
 |    where available) in an attempt to acquire a fully qualified host name. 
 See 
 |    also $smtp_active_hostname. 
  
 -- 
 - 
 ---------------------------------------------------------------------------- 
 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 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)