Re: ipv6 maybe has arrived.
On Fri, Feb 10, 2023 at 05:58:07AM -0500, gene heskett wrote:
> hosts: files mymachines dns myhostname
This is wrong. I don't know where you got it from, but "mymachines"
and "myhostname" are not valid entries in this file. NOT EVEN IF THEY
ARE FUCKING METASYNTACTIC PLACEHOLDERS for "coyote.den" and "lupus" or
whatever the FUCK your actual file says.
The instructions in nsswitch.conf are there to tell the name server
switch how to proceed. It has a man page -- nsswitch.conf(5). If you
don't want to read that man page, then AT THE VERY LEAST you should
leave the file alone. Let it retain its default settings, which are:
hosts: files mdns4_minimal [NOTFOUND=return] dns
If you don't like that mdns4 thing because it's a cousin of Avahi
(apparently), then you could remove it, which would leave you with:
hosts: files dns
That would be the minimal working configuration.
> And unchanged since the armbian bullseye install back in October of the past
> year. If that is not correct, then point the finger of guilt at the
> installer, not me.
I would imagine that if you were running REAL DEBIAN on these systems
(not Armbian, or Raspbian, or "this one guy's CNC build of something based
on Debian for Raspberry Pis"), and if the installer really did put this
nonsense in nsswitch.conf, other people would also have encountered
this problem by now.
> gene@coyote:~$ ls -l /sshnet/bpi54/etc/nsswitch.conf
> -rw-r--r-- 1 root root 516 Oct 20 14:35 /sshnet/bpi54/etc/nsswitch.conf
> gene@coyote:~$
> and the local network did not work on that machine until I added this to
> resolv.conf, by making it a real file, not a link to some dynamic thing, and
> of coarse added a chattr -i to it so network_mangler couldn't muck it up.
> gene@bpi54:~$ cat /etc/resolv.conf
> # Generated by NetworkManager
> nameserver 192.168.nn.1
> search hosts, nameserver
Your nameserver line is incorrect. It has letters in the middle of the
IPv4 address, where there should only be digits.
YET ANOTHER FUCKING OBFUSCATING METASYNTACTIC PLACEHOLDER, no doubt. Like
we CARE what subnet of 192.168 you used? Like it's a god damned STATE
SECRET? Jesus Christ.
Now, ignoring that and moving on to the more interesting line....
Citing resolv.conf(5):
search Search list for host-name lookup.
By default, the search list contains one entry, the local domain
name. It is determined from the local hostname returned by
gethostname(2); the local domain name is taken to be everything
after the first '.'. Finally, if the hostname does not contain
a '.', the root domain is assumed as the local domain name.
This may be changed by listing the desired domain search path
following the search keyword with spaces or tabs separating the
names. Resolver queries having fewer than ndots dots (default
is 1) in them will be attempted using each component of the
search path in turn until a match is found.
Oh, there's another piece I missed yesterday: we need to know the full
hostname on the "source" system. So, include a paste of the "hostname"
command and its output as well. It wouldn't hurt to add
"cat /etc/hostname" to the mix, too, since that's where Debian normally
defines the hostname.
If the documentation is to be believed, you have created a domain name
search path containing the two elements "hosts," and "nameserver".
Which means that if you were to type
getent hosts gene123
the resolver would perform lookups on "gene123.hosts," and
"gene123.nameserver" -- unless of course the entry with a literal comma
in it is rejected. In that case, the documentation doesn't say what
should happen.
If your system interprets a malformed search line with a comma in it
as a deprecated legacy configuration mimicking what libc5 used to pull
out of /etc/host.conf then this is NOT documented, and you have stumbled
upon something magical by accident.
Sadly, you still haven't shown us the configuration of the system when
it's in the non-working state, which is what we need in order to try to
reproduce your results.
Given the limited information available, the only thing I can try to do
is reproduce your failing configuration using guesswork.
First guess: "mymachines" and "myhostname" are literal, not metasyntactic
obfuscations.
So, let me mangle my /etc/nsswitch.conf in this way and see what happens:
unicorn:~$ cat /etc/resolv.conf
search wooledge.org
nameserver 127.0.0.1
nameserver 10.0.0.1
nameserver 8.8.8.8
unicorn:~$ sudo vi /etc/nsswitch.conf
[sudo] password for greg:
unicorn:~$ grep ^hosts: /etc/nsswitch.conf
hosts: files mymachines dns myhostname
unicorn:~$ sudo vi /etc/hosts
unicorn:~$ grep gene /etc/hosts
11.12.13.14 hi.gene hi
unicorn:~$ getent hosts hi.gene
11.12.13.14 hi.gene hi
unicorn:~$ ping hi.gene
PING hi.gene (11.12.13.14) 56(84) bytes of data.
^C
--- hi.gene ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2040ms
unicorn:~$ ping hi
PING hi.gene (11.12.13.14) 56(84) bytes of data.
^C
--- hi.gene ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2055ms
Funny stuff. It actually *works* somehow, despite the utter nonsense
words stuck in the middle of the hosts: line. And without needing to
add "search hosts, nameserver" to /etc/resolv.conf, either.
Perhaps it only works because "files" is the first item on the list,
so it looks in the local files, finds what it wants, and doesn't have
to process the rest of the list. But that's just another guess.
Well, that was my best effort to reproduce your configuration given the
vague statements you've given us. If at some point you'd care to give
us ALL the puzzle pieces TOGETHER, AT THE SAME TIME then maybe someone
would be able to reproduce what you're seeing.
Until then, I'm glad you got it working somehow, but I would really
appreciate it if you would stop posting misleading or outright wrong
statements all the time.
Reply to: