Revisiting the hostname/FQDN issue, adding libnss-myhostname
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
Reply to: