On Mon, Apr 07, 2025 at 10:28:12PM -0500, David Wright wrote:
On Thu 03 Apr 2025 at 06:55:10 (-0400), Greg Wooledge wrote:
I disagree with you here. The 127.0.1.1 address is a placeholder put
there by the installer for the more common case where a machine doesn't
have a fixed LAN IP address. Most home or workplace computers these
days will get their addresses from DHCP without a reservation, so their
internal addresses may vary.
And that means that two machines can't find each other unless the DHCP
server is also a DNS server. Or you set up and run your own.
Or you use mdns, which is the standard way of dealing with dynamic
resources on an unmanaged network. (That doesn't mean you have to use
mdns, it just means that if you instead decide to do something like copy
hosts files around the network you're choosing to make up your own
solution to the inherent problems that led to dns in the first place.)
But one disadvantage of your preferred approach is that the hostname
and domain won't resolve unless the network is up.
Nope, the stuff in /etc/hosts will resolve regardless of the state of
the network. You won't be able to connect to the address associated with
the local hostname until that address is configured on the host. For
various reasons I'd much rather configure a static IP in this situation
than set up a reservation on the dhcp server. Among other things, in a
small network the bespoke dhcp configuration is likely going to cause
pain that can't possibly outweigh the need to reconfigure a static IP if
for some strange reason it needs to change. And a static IP is always
going to be there (eliminating the issue of the hostname resolving to an
unreachable IP). If I were using any sort of dhcp, including with a
static reservation, I'd probably use 127.0.1.1 for the local hostname
rather than any non-local IP. Mostly, to me, this falls into a weird
place in wanting to use a complex solution (static dhcp reservations)
without taking the relatively small additional step of just providing
dns. Either go all the way and provide all the normal facilities (which
these days are often baked into the router) instead of a mash-up, or go
the easy route and use dynamic dhcp and mdns.
I don't know
whether that's why Gene installs/ed libnss-myhostname: I find the
documentation rather heavy going, and would have to experiment with
it a bit to make sense of it. I also don't know whether it would be
at all relevant to explaining Gene's following statement:
✄✄
$ grep hosts: /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns
because files doesn't work in bookworm, I had to:
grep hosts: /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
to make the hosts file work
✄✄
It's not productive to try to guess what his problem is. As a general
matter /etc/hosts works fine on bookworm, as anyone can easily verify.
There's also no reason why adding anything to the end of a line would
change the use of files at all, because the modules are tried in order.
There's probably something wrong with the hosts file, but there's no
reliable data so the problem could be almost anything. It doesn't help
that he's gotten bogus advice about changing the local hostname to
resolve to 127.0.1.1, setting off another wild goose chase. I'd
personally debug by looking really closely at the hosts file to try to
see the bogus element. Assuming I can't see the issue I'd get rid of mdns4
and myhostname in nsswitch.conf (to simplify) and 'getent hosts
somenameinthefile' to confirm that works, then try a couple of different
entries to identify any differences (e.g., both the fqdn and the bare
hostname). Until there's a better understanding of what the actual
problem is, there's no point in leaping to solutions.
