On Sat 22 Jan 2022 at 13:57:38 (-0500), gene heskett wrote:
> On Saturday, January 22, 2022 12:14:20 PM EST David Wright wrote:
> > On Sat 22 Jan 2022 at 11:13:59 (+0100), to...@tuxteam.de wrote:
> > > On Sat, Jan 22, 2022 at 04:38:04AM -0500, gene heskett wrote:
> > > > On Saturday, January 22, 2022 2:04:32 AM EST to...@tuxteam.de
> wrote:
> > > [...]
> > >
> > > > > Once that part is flying, tackle names :)
> > >
> > > I stay still by this :)
> > >
> > > > But, I found, quite by serendipity, in the raspios version of
> > > > bullseye, a fix. Look at the bottom of /etc/dhcpdcp.conf,
> > > >
> > > ^^^^^^^
> > >
> > > ...that one looks like a typo to me. On my (not quite standard,
> > > because I avoid systemd) Debian buster, there is a /etc/dhcp
> > > hierarchy, with a dhclient.conf, which gets into action whenever my
> > > machine requests an IP address (typically when I do "ifup foo", for
> > > foo in eth0 or wlan0.
> > >
> > > The host name does figure there: it goes out with the request, in
> > > case
> > > the DHCP server wants to take decisions based on that. No DHCP server
> > > I interact with takes notice, but they might.
> > >
> > > This is the only connection I see.
> > >
> > > That filename directly at top-level looks to me pretty
> > > raspi-specific.
> > > Is it configuring some DHCP server, or your client?
> >
> > It looks like Gene might be talking about /etc/dhcpcd.conf from
> > dhcpcd5_7.1.0-2+b1_amd64.deb (or the appropriate hardware).
> > In any case, it looks like an instance of "make some change in
> > some file until it works", which is fine until any of a reboot,
> > an upgrade, a change somewhere else in the system, etc which
> > causes it to stop working.
> >
> > And when posts starts appearing here again, Gene's system is
> > even more unlike anybody else's than it is today.
> >
> > Cheers,
> > David.
>
> Ok David, perhaps you can explain to me why my use of an identical hosts
> file on every machine in my tiny home network to describe my local
> network is bad, to be denigrated at every turn of the screw you can
> manage.
Because the basic /etc/hosts file looks something like:
127.0.0.1 localhost
192.168.1.1 router.corp router
192.168.1.2 cascade.corp cascade
127.0.1.1 acer.corp acer # 192.168.1.10
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
and the hostname, acer, will be different on each host.
> So my resolv.conf says to search coyote.den, and failing that, use my
> isp's nameserver by relaying the request for lookup to my router, which
> in turn querys my isp after NATing the request, to look up the name.
So you're using some local DNS server to resolve hostnames on your
LAN. Where's it getting that information from? Is it up to date?
> That way the only 2 limitations on local host and domain names is that
> they cannot start with a number, but must be alpha. And they must NOT be
> volatile. Which explains why one of my machines, a 6040 4 axis milliing
> machine, is called sixty40.coyote.den.
I don't know why you tried that corner case. Back then, you wrote:
"Is that a bug? Or is there a specific reason for the silent failure?
In which case, it really ought to be a little mouthier about the failure."
The whole point is that there is no "it". Somewhere—anywhere—there
will be some code that makes a false assumption. Just avoid it by
scanning RFC1178.
> Linux goes out of its way to kill networking by ignoring what I put in a
> file in /etc/network/interfaces.d/anyoldname. And when some coder dinking
> around in dhcp code thinks the whole world is volatile, and changes a
> hostname just because they can boggles my mind. But its the only way to
> have a sane local network with STABLE names and addresses.
No idea what you're talking about here.
> So convince me how I can build a stable local network using dhcp that
> still allows me to "ssh -Y rpi4" and know for 100% certainty that dhcp
> hasn't rerouted my ssh session to tlm.coyote.den.
I can't. You have this wonderful router that contains DHCP and DNS,
where you flashed in the software, and I know nothing about it.
> To me its unnecessary complexity to even run a nameserver of any kind on
> my local network. Makes zero sense to me, I've been doing it this for 25
> years now, how long have you?
I don't run a nameserver, and I don't attempt to. My $35 router has a
list of MACs for every device in the house, and a corresponding IPaddr
for each. It gets sent names by devices but, on the whole, they aren't
useful and best ignored.
All the devices get their addresses by DHCP from the router, except
that my laptops override the wired address with a static IPaddr that
matches their DHCP wireless one. That just means that the laptop will
have the same IPaddr whether wired or wireless.
For resolving these hosts, I use the /etc/hosts file. The master list
resides in /root on my admin/day-to-day machine, and a script edits
the appropriate line as shown above for acer, appends ~13000 fake
127.0.0.1 addresses, and dispatches it to acer in this case. That's
all because my $35 router "unbelievably" doesn't have a DNS server.
BTW,
$ grep hosts /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.1.1
$
I don't specify any domain information in the resolver: names are
either on the LAN or they're passed to 192.168.1.1 and thereby to
the addresses set in the router, currently 8.8.8.8 and 8.8.4.4.
I'm not sure why you have to use coyote.den. My .corp exists solely
to make exim a little happier.
> Unless you can tell me how to get a STABLE, Just Works local network
> using dhcpd, I'll keep on doing it my way. That is a question I've asked
> one way or another on various lists, without ever getting a step by step
> instruction on how to make a far more complex method Just Work. To me
> there has to be a STABLE place to start, and that hostname files contents
> is it IMNSHO.
↑↑↑↑↑↑↑↑↑↑↑↑↑↑
The hostname file is for the machine itself, not for getting to it.
The host has one name, but each interface could have a different name
and address for reaching it.
> Can you understand my anger when I edit /etc/hostname to call a machine
> an "rpi4", reboot it, no network, something has taken upon itself the
> authority to make a cat /etc/hostname return "raspberry" after a reboot.
Not really. I don't have a clue how your machines boot up. It /would/
worry me if it changed on my machines without my knowing why, but
that's a different problem.
> That is bs, usually found on the ground, warm and smelly, behind the male
> of the bovine specie. Its gotten a bit less smelly in recent years, but I
> used to have to chattr +i both the /etc/hostname and /etc/resolv.conf
> files to make it work reliably at every reboot. I think jessie was the
> last time I had to do that.
>
> I was about to revert to doing it again when I found the last 2
> paragraphs in the bottom of the /etc/dhcpdcp.conf file on the rpi4, which
> has the effect of the last word if a dhcpd server can't be found.
Sorry, I don't know why you're having to mess about with a dhcp
configuration file when you're not using DHCP (it that's actually so).
> Since the list seems determined to keep this thread alive, I'll wait for
> an explanation I can print, take around to all my machines and follow to
> implement it YOUR way. But I'm not going on a hunger strike until that
> happens.
I'm not worried about whether you use /my/ way, but it is odd that you
seem to take pride in the fact that you (claim to) set it up the way
you did on an Amiga in the 1980s.
Cheers,
David.
