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.