hostname is being reset, killing net on reboot

[gene heskett]

Hi all;

System is an rpi4b/bullseye, uptodate.
I had to fix this a year or more ago with buster, but this system has
crashed and burned thanks to a 2T shingled drive. Notes if any were ever
made are gone.

So how do I officially set the hostname so its reboot proof?

Thanks all.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[Andrew M.A. Cater]

On Fri, Jan 21, 2022 at 06:42:38PM -0500, gene heskett wrote:
> Hi all;
>
> System is an rpi4b/bullseye, uptodate.
> I had to fix this a year or more ago with buster, but this system has
> crashed and burned thanks to a 2T shingled drive. Notes if any were ever
> made are gone.
>
> So how do I officially set the hostname so its reboot proof?
>

hostnamectl set hostname [foobar]

Hope that helps - all best, as ever,

Andy Cater

[gene heskett]

On Friday, January 21, 2022 6:45:52 PM EST Andrew M.A. Cater wrote:
> On Fri, Jan 21, 2022 at 06:42:38PM -0500, gene heskett wrote:
> > Hi all;
> >
> > System is an rpi4b/bullseye, uptodate.
> > I had to fix this a year or more ago with buster, but this system has
> > crashed and burned thanks to a 2T shingled drive. Notes if any were
> > ever made are gone.
> >
> > So how do I officially set the hostname so its reboot proof?
>
> hostnamectl set hostname [foobar]
>
> Hope that helps - all best, as ever,
>
> Andy Cater
>

Thank you Andy. IIRC that can set domainname too?

[Greg Wooledge]

On Fri, Jan 21, 2022 at 07:27:11PM -0500, gene heskett wrote:
> On Friday, January 21, 2022 6:45:52 PM EST Andrew M.A. Cater wrote:
> > On Fri, Jan 21, 2022 at 06:42:38PM -0500, gene heskett wrote:
> > > So how do I officially set the hostname so its reboot proof?
> >
> > hostnamectl set hostname [foobar]

The standard Debian way is to put the desired hostname in /etc/hostname.

If I'm reading hostnamectl(1) correctly, the command you wanted should
have a hyphen in it: hostnamectl set-hostname NEWNAME

However, I've never used this command and I'm not sure what it actually
does, or how it interacts with the traditional Debian configuration.

> Thank you Andy. IIRC that can set domainname too?

That depends on what you mean by "domainname". There is a "domainname"
command in the nis package, which sets the NIS domain name. But I
somehow suspect this isn't what you mean. I also suspect you aren't
talking about Kerberos. Or Samba.

Do you mean a DNS domain name of some kind? That's my guess. But even
then, the concept is ambiguous. What are you actually trying to do?

In order for *other* computers to know your system by a fully qualified
domain name, you would need to alter DNS. Either the real live global DNS
that everyone uses, if systems are doing DNS lookups on the public
Internet, or else a local area network DNS server that you maintain
interally. Or else modify the /etc/hosts files on the other computers.

Or perhaps what you mean is something like, "When I type telnet iota,
I want it to act like I had typed telnet iota.gene.local." In this case,
you're probably aiming for a customized /etc/resolv.conf file. Which
in turn means you need to read up on how to avoid having your changes
to /etc/resolv.conf wiped out by roaming bands of daemons. I've covered
this topic so many times that I'm quite tired of it, so just go to
<https://wiki.debian.org/resolv.conf> and read.

Or maybe you mean something else? Please be specific.

[gene heskett]

/etc/resolv.conf has:
search coyote.den
nameserver 192.168.xx.1

the search line says to look in the /etc/hosts file, failing that, the
nameserver line sends the dns lookup query to the router which NAT's me
to my isp assigned address, and fwds it to my isp's dns server. And its
Just Worked much like that way since redhat 5.0 in 1998.

However when I set hostname with hostname, the 169.bs stays out of the
picture and networking works the world until a reboot.
Setting the hostname with hostnamectl to the alias in /etc/hosts for this
machine, gets me exactly the same hostname but then the route reported by
"ip a" is the 169.bs.bs.bs and I can't get out of my shirt pocket to even
ping the router at 192.168.xx.1.

I tried to remove avahi but apt doesn't admit to knowing it. But thats
what I had to do to buster in order to get rid of the bogus routing.
ip route won't kill it, not even to the next reboot, so how do I get rid
of the bogus 169.bs.bs.bs routing forever? That whole avahi thing has
never been anything but a headache for me, whoever wrote it is in search
of a problem I have never had in 24 years.

My whole system here, 7 machines atm, has been as high as a dozen, is
dhcpd-less, all host name based with a common hosts file on all machines.
And until avahi sticks its camel nose in, it Just Works. So how do I get
rid of the 169.xx.xx.xx bs? Forever, with shoot to kill prejudice?

Thank you.

[gene heskett]

Never mind. I found the cure in the bottom of /etc/dhcpcd.conf, define a
static_eth0 and a fallback to it if a dhcpd server can't be found, did
it, rebooted and its fixed. I have a network. Why isn't that in the wiki?
Neither is there any reference to avahi that can be found in the wiki and
I spent around 2 hours search and browsing it.. Frustrating is an
inadequate description. Adequate isn't for mixed audiences.

Anyway, its fixed. How long? Beats me...

[Greg Wooledge]

On Fri, Jan 21, 2022 at 09:34:35PM -0500, gene heskett wrote:
> /etc/resolv.conf has:
> search coyote.den
> nameserver 192.168.xx.1
>
> the search line says to look in the /etc/hosts file, failing that, the
> nameserver line sends the dns lookup query to the router

No, that's not correct.

The config file that says "look in /etc/hosts first, then look in DNS
next" is /etc/nsswitch.conf. Specifically, it's the line that begins
with "hosts:" in that file.

The "search" line in /etc/resolv.conf means "if I type ftp roadrunner,
I want it to act as if I had typed ftp roadrunner.coyote.den".

In other words, it's the default DNS search domain for looking up the
*other computers* on your local area network.

> However when I set hostname with hostname, the 169.bs stays out of the
> picture and networking works the world until a reboot.

Well, yes. The "hostname" command sets the current hostname, which resides
in memory only. It has no permanent effect.

And it has nothing at all to do with IP addresses. Or DNS.

> Setting the hostname with hostnamectl to the alias in /etc/hosts for this
> machine, gets me exactly the same hostname but then the route reported by
> "ip a" is the 169.bs.bs.bs and I can't get out of my shirt pocket to even
> ping the router at 192.168.xx.1.

Routing has nothing to do with your system's hostname. At all.

At the most basic level, your system's default route is set by whatever
mechanism sets up your network interfaces. On Debian, this can be any
of *several* different pieces of software, depending on what's installed
and what you've got in your config files.

In the *most* basic possible configuration, your routing table will be
one automatic entry for your ethernet interface (created from the IP
address and netmask which are assigned to that interface), and then one
"default" route which is assigned for reaching every host that's *not*
part of your LAN.

E.g. in /etc/network/interfaces you'd have something like this:

auto enp2s0

iface enp2s0 inet static
address 192.168.1.21/24
gateway 192.168.1.1

This tells the "ifupdown" software package that you'd like it to manage
the enp2s0 network interface, assigning the IP address 192.168.1.21 with
a 24-bit netmask, which automatically creates a route to the 192.168.1.0/24
network. In addition, it will create a default route via the 192.168.1.1
address.

None of this has *anything* to do with your system's hostname.

None of this has *anything* to do with your /etc/hosts file.

None of this has *anything* to do with DNS.

Of course, there are many other ways to configure network interfaces in
Debian. You might be using Network-Manager, for example. Or systemd's
systemd-networkd(8). Or you might be using /etc/network/interfaces but
telling it to ask for configuration from DHCP.

Also, by the way, "ip a" does not report routes. That's "ip r".

unicorn:~$ ip r
default via 10.0.0.1 dev lan0
10.0.0.0/24 dev lan0 proto kernel scope link src 10.0.0.7

------------------------------------

You're probably still confused. Let's go over everything again, from
the beginning.

Your computer has a *network interface*. This interface has some kind of
name. The names are very complicated and I don't want to introduce that
particular piece of complexity here. Let's say that you've somehow
managed to determine your interface's name. Let's say, for this example,
that your interface's name is enp2s0.

In order for your network interface to *work*, it has to be assigned an
IP address and a netmask. This can come from DHCP, or it can come from
files that you configure on your system.

With an IP address and a netmask, you will be able to communicate with
other computers on your *local area network*, by using their IP addresses.

If you have a default route, then you can potentially talk to computers
*outside* of your LAN. This default route can come from DHCP, or from
local files. E.g. with a properly configured default route, you will be
able to run commands like "ping 8.8.8.8" and get responses.

If you'd like to communicate with other computers by name instead of by
IP addresses, you can either put their names and IP addresses in the
/etc/hosts file (a simple text file), *or* you can configure your
computer to use DNS.

DNS is configured in the /etc/resolv.conf file. The most basic piece
consists of "nameserver" lines which contain the IP addresses of DNS
resolvers which will look up computer names for you. These nameservers
can come from DHCP, or they can be configured in your local files.

Your computer can also have a hostname. This is how your computer
identifies itself when it logs things, so that you can tell which computer
wrote which piece of the logfile. Your computer can be named whatever
you like. Its name has meaning only to you. Other computers do not
know what your hostname is, and they do not care.

If you want other computers to be able to contact you by a name, then
you add that name to DNS, *or* to the /etc/hosts files of those other
computers. The name that you put in DNS or other machines' /etc/hosts
files does *not* have to be the same as your hostname. Your hostname
is private. It's what your computer calls itself. It's not what
other computers call you.

Your computer can also have a *list of search domains* for use in
hostname lookups. This is typically something you'd only care about
if you have a LAN with multiple computers on it, which all want to
talk to each other. If you're just a single computer that's on the
Internet, you *do not care* about this at all.

The main purpose of a list of search domains is to save typing. Let's
say you've got a LAN with hosts that are (publically) called
"cat.coyote.den" and "dog.coyote.den". If you want to log into the
first one, you could type "ssh cat.coyote.den". But that's a lot of
typing. If you have "coyote.den" in your list of search domains, then
you can simply type "ssh cat". The host resolver will try each of the
domains in your search list, one by one, as suffixes, until one of
them works.

This list of search domains is configured in your local /etc/resolv.conf
file. It can be a static entry, or it can come from DHCP.

[gene heskett]

> .
This is all well and good, Greg, but it still does NOT give a clue what
todo when the system picks a fictitious route out of its rear.

And that IS my squawk.

I did find a fix as posted earlier, but I doubt it will work under a pine
tree in Wash State where these two cards will get mailed to once I get a
realtime kernel installed and working. And I've got a v5.16.0-rc6-rt12,
downright bleeding edge to install tomorrow.

Cheers Greg, Gene Heskett.

[to...@tuxteam.de]

On Fri, Jan 21, 2022 at 07:46:40PM -0500, Greg Wooledge wrote:
> On Fri, Jan 21, 2022 at 07:27:11PM -0500, gene heskett wrote:
> > On Friday, January 21, 2022 6:45:52 PM EST Andrew M.A. Cater wrote:
> > > On Fri, Jan 21, 2022 at 06:42:38PM -0500, gene heskett wrote:
> > > > So how do I officially set the hostname so its reboot proof?
> > >
> > > hostnamectl set hostname [foobar]
>
> The standard Debian way is to put the desired hostname in /etc/hostname.
>
> If I'm reading hostnamectl(1) correctly, the command you wanted should
> have a hyphen in it: hostnamectl set-hostname NEWNAME

Clarification: hostnamectl is from the systemd suite. For those using
another init system, put things directly in /etc/hostname.

Reading the source [1], `set-hostname' seems to be obsolete. The magic
word seems to be simply `hostname', these days, at least.

As far as I can see, after making sure the user hasn't made some error,
it passes the buck to some D-Bus service [2], which then does something.
Or not: I stopped my chase there.

For pedestrians (no D-Bus around here), writing to /etc/hostname is
still the way to go. Probably it'll work along with a systemd too.

Cheers

[1] https://sources.debian.org/src/systemd/250.3-1/src/hostname/hostnamectl.c/?hl=655#L655
[2] https://sources.debian.org/src/systemd/250.3-1/src/hostname/hostnamectl.c/?hl=655#L496

--
t

[to...@tuxteam.de]

On Fri, Jan 21, 2022 at 10:46:35PM -0500, Greg Wooledge wrote:

[...]

> Well, yes. The "hostname" command sets the current hostname, which resides
> in memory only. It has no permanent effect.
>
> And it has nothing at all to do with IP addresses. Or DNS.

[...]

> Routing has nothing to do with your system's hostname. At all.

This is so important that it bears repeating. A couple of times :)

Hostname is a host's notion of its own host name. This can be different
from the name (or names) assigned to its IP addresses by the DNS. A
machine can have zero or IP addresses, and each of those can be known by
zero or more names in the DNS. Heck, several parts of a "split" DNS
world can disagree among them as to which names those IP addresses are
known by.

Of course, giving a host a name unrelated to (some of its) DNS names is
a bad idea in general, because it tends to confuse the heck out of
sysadmins (and in some case of applications: notably, SMTP servers
answer with "Hey, I'm patrick" (using the own hostname [1]): the server
at the other end will run away if it thinks it was talking to peter.

Cheers

[1] Unless you go to some lenghts to configure your SMTP server
otherwise.

--
t

[to...@tuxteam.de]

On Fri, Jan 21, 2022 at 11:51:20PM -0500, gene heskett wrote:

[...]

> This is all well and good, Greg, but it still does NOT give a clue what
> todo when the system picks a fictitious route out of its rear.

Start debugging from bottom to top. For the first round, just deal in IP
addresses and routes (those are set in term of IP addresses, not names).
Forget about names.

Once that part is flying, tackle names :)

> And that IS my squawk.
>
> I did find a fix as posted earlier, but I doubt it will work under a pine
> tree in Wash State where these two cards will get mailed to once I get a
> realtime kernel installed and working. And I've got a v5.16.0-rc6-rt12,
> downright bleeding edge to install tomorrow.

Pethaps you'll have to have stern words with your DHCP server. This may
be the one giving your machines their weird IP addresses and (at least
part of the) routes.

Cheers
--
t

[Andrei POPESCU]

On Vi, 21 ian 22, 23:51:20, gene heskett wrote:
> On Friday, January 21, 2022 10:46:35 PM EST Greg Wooledge wrote:

[lots of good stuff]

> This is all well and good, Greg, but it still does NOT give a clue what
> todo when the system picks a fictitious route out of its rear.

In order to even try guessing you must tell us how did you ever
configure the network on this machine.

Non-exhaustive list of possibilities:

1. It was done automatically during installation
2. It was configured manually by you during installation

(if any of these please specify if you installed a Desktop
Environment at the same time)

3. You edited some file after installation

(please provide the full contents of it, preferably as attachment)

4. You installed and configured some software (which one?)

etc.


In any case, please provide:

A. The full contents of /etc/network/interfaces) and any file under
/etc/network/interfaces.d/ (preferably attached)

B. The full outputs of 'networkctl' and 'nmcli'.

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser

[Curt]

On 2022-01-22, Greg Wooledge <gr...@wooledge.org> wrote:
> On Fri, Jan 21, 2022 at 07:27:11PM -0500, gene heskett wrote:
>> On Friday, January 21, 2022 6:45:52 PM EST Andrew M.A. Cater wrote:
>> > On Fri, Jan 21, 2022 at 06:42:38PM -0500, gene heskett wrote:
>> > > So how do I officially set the hostname so its reboot proof?
>> >
>> > hostnamectl set hostname [foobar]
>
> The standard Debian way is to put the desired hostname in /etc/hostname.
>

What about updating /etc/hosts too?

https://wiki.debian.org/Hostname

Core networking
Update /etc/hostname

Update /etc/hosts, so local address(es) resolves with the new system
name.

Reload the network configuration...

[to...@tuxteam.de]

On Sat, Jan 22, 2022 at 09:03:06AM -0000, Curt wrote:
> On 2022-01-22, Greg Wooledge <gr...@wooledge.org> wrote:
> > On Fri, Jan 21, 2022 at 07:27:11PM -0500, gene heskett wrote:
> >> On Friday, January 21, 2022 6:45:52 PM EST Andrew M.A. Cater wrote:
> >> > On Fri, Jan 21, 2022 at 06:42:38PM -0500, gene heskett wrote:
> >> > > So how do I officially set the hostname so its reboot proof?
> >> >
> >> > hostnamectl set hostname [foobar]
> >
> > The standard Debian way is to put the desired hostname in /etc/hostname.
> >
>
> What about updating /etc/hosts too?
>
> https://wiki.debian.org/Hostname

Noooo!

;-)

Now we were getting across that the host name (as in /etc/hostname) has
nothing to do with name resolution (as in resolver, DNS) you come and
mess things up again ;-D

[note the smileys]

Seriously. Of course it is a good idea that name resolution (resolver)
can resolve the name set up in hostname. Ideally to an IP address
pointing to the host in question. Everything else would be... confusing.

But let Gene fix things in the IP layers first, get the host name set,
independently of that, and tackle name resolution after IP routing
works.

Cheers
--
t

[gene heskett]

On Saturday, January 22, 2022 2:04:32 AM EST to...@tuxteam.de wrote:
> On Fri, Jan 21, 2022 at 11:51:20PM -0500, gene heskett wrote:
>
> [...]
>
> > This is all well and good, Greg, but it still does NOT give a clue
> > what todo when the system picks a fictitious route out of its rear.
> Start debugging from bottom to top. For the first round, just deal in
> IP addresses and routes (those are set in term of IP addresses, not
> names). Forget about names.
>
> Once that part is flying, tackle names :)

But, I found, quite by serendipity, in the raspios version of bullseye, a
fix. Look at the bottom of /etc/dhcpdcp.conf, if there is even a copy of
that on your system, this one now that I've looked, doesn't have it,
there is an example of what to do if no dhcpd is to be found locally.
static_eth0 can be defined, and below that, is an if no dhcpd to be
found, fallback to the static_eth0 definition.

Unpublished, not really mentioned in the man pages, but edit to put the
correct for your site data in it, reboot, and its working. So at least on
an rpi4 running bullseye, I found what looks to be the official way to
fix it. That file does NOT exist on an x86-64 debian bullseye install. As
to how you fix it on debian, I've not a clue.

I'd ask on the raspi forum, but I made the mistake of asking about a
realtime kernel a third time, way back in wheezy's time, which they
officially do not support, so my posting rights were turned off. I can
login, but can't post.

However, since this, on closer inspection, seems to be an raspios
problem, this is the last post on this subject.

> > And that IS my squawk.
> >
> > I did find a fix as posted earlier, but I doubt it will work under a
> > pine tree in Wash State where these two cards will get mailed to
> > once I get a realtime kernel installed and working. And I've got a
> > v5.16.0-rc6-rt12, downright bleeding edge to install tomorrow.
>
> Pethaps you'll have to have stern words with your DHCP server. This may
> be the one giving your machines their weird IP addresses and (at least
> part of the) routes.

There first has to be an activated server. And the only one here is
fielding the radio in the router when the radio is on, but its off to
keep the neighbors damned cell phone from using 300gigs a month on my
nickle.

> Cheers

Cheers Tomas, take care and stay well, Gene Heskett.

[to...@tuxteam.de]

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?

Cheers
--
t

[gene heskett]

its for its own eth0 on the rpi4b. And I guess it is raspi specific. It
doesn't exist on this x86-64 bullseye install.

Last post Tomas, we are contaminating the archive and the fix I published
with further discussion.

Cheers, Gene Heskett.

[Charles Curley]

On Sat, 22 Jan 2022 07:47:01 +0100
<to...@tuxteam.de> wrote:

> Reading the source [1], `set-hostname' seems to be obsolete. The magic
> word seems to be simply `hostname', these days, at least.

Interesting.

I have systemd 247.3-6, as provided on Bullseye. The man page mentions
set-hostname only. Looking at your footnote (why do you put footnotes
in an email?), you are looking at a more recent version.

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[to...@tuxteam.de]

On Sat, Jan 22, 2022 at 07:33:56AM -0700, Charles Curley wrote:
> On Sat, 22 Jan 2022 07:47:01 +0100
> <to...@tuxteam.de> wrote:
>
> > Reading the source [1], `set-hostname' seems to be obsolete. The magic
> > word seems to be simply `hostname', these days, at least.
>
> Interesting.
>
> I have systemd 247.3-6, as provided on Bullseye. The man page mentions
> set-hostname only. Looking at your footnote (why do you put footnotes
> in an email?),

Bad habits :)

> you are looking at a more recent version.

Quite possibly. I went with whatever version sources.debian.org threw at
me :-)

Cheers

> Does anybody read signatures any more?

I do. Sometimes.

Cheers
--
t

[David Wright]

On Fri 21 Jan 2022 at 21:34:35 (-0500), gene heskett wrote:

> My whole system here, 7 machines atm, has been as high as a dozen, is
> dhcpd-less, all host name based with a common hosts file on all machines.
> And until avahi sticks its camel nose in, it Just Works. So how do I get
> rid of the 169.xx.xx.xx bs? Forever, with shoot to kill prejudice?

That's presumably a 169.254.n.n address, which AIUI the system will
create if DHCP fails to supply an address when asked.

I think your terminology is normally to "nuke" it rather than "shoot
to kill", but it shows that your approach is the wrong way round:
were your system set up correctly, it would never get created. The
idea is that if your system can't find its own address, then it gives
itself a random 169.254.n.n address so it can communicate with others
in the same boat.

I think we've been here before, as far back as March 2015, and usually
found some out-of-date, or RedHat¹, or just plain wrong entries in some
of your files when you've been persuaded to post them. As you claim
not to run DHCP, then it's particularly important that your
configuration is correct, and happens early enough.

¹ Yesterday, you wrote "And its Just Worked much like that way

since redhat 5.0 in 1998."

Sorry, but things have changed in the meantime.

Cheers,
David.

[David Wright]

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.

[gene heskett]

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

Take care, and stay well, ALL of you.

[Greg Wooledge]

On Sat, Jan 22, 2022 at 01:57:38PM -0500, gene heskett wrote:
> So my resolv.conf says to search coyote.den, and failing that, use my

> isp's nameserver [...]

Again: that is NOT what the resolv.conf file does.

The /etc/nsswitch.conf file *SHOULD* tell your system to use the /etc/hosts
file first, and DNS second. At least, that's the default and the norm.

> 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.

Honestly? I would not try to convince you to do this. It's additional
complexity that you clearly don't need, and perhaps aren't ready to
handle.

For a LAN with no DHCP and no local DNS, here's what you need:

1) Each system must configure its own IP address, netmask, and default
route (gateway). This can be done in /etc/network/interfaces if the
interface name is well defined.

If the interface name is an issue, then you'll also need to set up a
".link" file in /etc/systemd/network/ to assign the interface name.

2) Each system should have an /etc/hosts file which has a unique header
per system (containing something like "127.0.1.1 tlm.coyote.den tlm"),
and then a copy-pasted body that's the same for all systems. In that
body, you'll specify the LAN IP addresses and the LAN hostnames of
all your systems. For example,

127.0.0.1 localhost
192.168.1.1 router.coyote.den router
192.168.1.2 tlm.coyote.den tlm
192.168.1.3 sixty40.coyote.den sixty40
...

Obviously I don't know your LAN IP addresses or most of your hostnames,
so I can only guess. But this is the general form that it should have.

3) Systems that want to contact the Internet will also need an
/etc/resolv.conf file, telling them where the DNS resolvers are. If
your router is also your DNS resolver, then you would use something
like this:

search coyote.den
nameserver 192.168.1.1

The "search" line doesn't actually do much here, because all of your
Internet queries are going to contain dots (like www.debian.org), and
therefore the search domain isn't used. But just in case you ever
try to hand a LAN hostname like "tlm" to a program that wants to
contact the Internet, the search domain will turn it into
"tlm.coyote.den" for you.

Systems that have no business contacting the Internet can omit this
file. Of course, that won't stop them from contacting the Internet
using raw IP addresses.

If one of your computers isn't working correctly, then you can troubleshoot
it. We might even be able to help you, if you provide enough information.

Use "ip a" to see the addresses that are assigned to your interfaces. Are
those correct? If not, then you know there's an issue in step 1.

Use "ip r" to see the routing table. Is the default route set correctly?
If not, then again, it's a step 1 issue.

Can your computer access the Internet, but not the other hosts on the LAN?
Then it's probably a step 2 issue. Check your /etc/hosts file. Also
check /etc/nsswitch.conf for good measure.

Can your computer access the other hosts on the LAN, but not the Internet?
Then it could be a step 3 thing (incorrect /etc/resolv.conf) if DNS is
the issue. If DNS isn't the issue (e.g. if ping 8.8.8.8 fails), then
it could be an incorrect default route. Or it could be a firewall thing.
I'm not covering firewalls here, but if you've got one, it could be set
up incorrectly and cause *all* kinds of havoc.

[gene heskett]

On Saturday, January 22, 2022 9:33:56 AM EST Charles Curley wrote:
> On Sat, 22 Jan 2022 07:47:01 +0100
>
> <to...@tuxteam.de> wrote:
> > Reading the source [1], `set-hostname' seems to be obsolete. The
> > magic
> > word seems to be simply `hostname', these days, at least.
>
> Interesting.
>
> I have systemd 247.3-6, as provided on Bullseye. The man page mentions
> set-hostname only. Looking at your footnote (why do you put footnotes
> in an email?), you are looking at a more recent version.

Same version here on amd64 according to synaptic. I have no clue what
version is installed on the rpi4, but its raspi-os bullseye.
Logged into the pi, synaptic says 247.3-6 with a patch number appended on
the rpi4.

[Andrew M.A. Cater]

On Sat, Jan 22, 2022 at 05:20:49PM -0500, gene heskett wrote:
> On Saturday, January 22, 2022 9:33:56 AM EST Charles Curley wrote:
> > On Sat, 22 Jan 2022 07:47:01 +0100
> >
> > <to...@tuxteam.de> wrote:
> > > Reading the source [1], `set-hostname' seems to be obsolete. The
> > > magic
> > > word seems to be simply `hostname', these days, at least.
> >
> > Interesting.
> >
> > I have systemd 247.3-6, as provided on Bullseye. The man page mentions
> > set-hostname only. Looking at your footnote (why do you put footnotes
> > in an email?), you are looking at a more recent version.
>
> Same version here on amd64 according to synaptic. I have no clue what
> version is installed on the rpi4, but its raspi-os bullseye.
> Logged into the pi, synaptic says 247.3-6 with a patch number appended on
> the rpi4.
>

Hi Gene,

Yes - sorry, I was in a hurry and I goofed.

hostnamectl set-hostname [foobar]

The hyphen is significant.

Raspberry Pi OS? You're more or less completely oon your own.
Raspberry Pi OS is its own creature and I assume you're running the 32 bit
version since the 64 bit version is still very beta.

Ask the Raspberry Pi Foundation. They do things differently there -
as you're discovering.

If you want to know how to run (fairly)
vanilla Debian - but including the non-free raspberry pi firmware
and rpi-eeprom - it's possible using either Gunnar Wolf's images
or Pete Batard's version of UEFI for the Pi 4 and the Debian
arm64 ISO file. _That_ I can help you with.

All the very best, as ever

Andy Cater

[gene heskett]

On Saturday, January 22, 2022 4:20:07 PM EST Greg Wooledge wrote:
> On Sat, Jan 22, 2022 at 01:57:38PM -0500, gene heskett wrote:
> > So my resolv.conf says to search coyote.den, and failing that, use my
> > isp's nameserver [...]
>
> Again: that is NOT what the resolv.conf file does.
>
> The /etc/nsswitch.conf file *SHOULD* tell your system to use the
> /etc/hosts file first, and DNS second. At least, that's the default
> and the norm.

Maybe I'm losing it, but I don't see any such directives in this file,
copy pasted from the miss-behaving machine.
======================
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed,
try:
# `info libc "Name Service Switch"' for information about this file.

passwd: files
group: files
shadow: files
gshadow: files

hosts: files mdns4_minimal [NOTFOUND=return] dns
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis
=======================

I am not all that familiar with this file, is it funkity?

> > 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.
>
> Honestly? I would not try to convince you to do this. It's additional
> complexity that you clearly don't need, and perhaps aren't ready to
> handle.
>
> For a LAN with no DHCP and no local DNS, here's what you need:
>
> 1) Each system must configure its own IP address, netmask, and default
> route (gateway). This can be done in /etc/network/interfaces if the
> interface name is well defined.

It is well defined, but overridden at reboot because something edited the
/etc/hostname file, restoring the installers default in the reboot
process. That name is not in the hosts file.

Which of course resolves to a 192.168.xx.xx number which doesn't get thru
the router without NATing first. The router of course has been reflashed
with dd-wrt.

> Systems that have no business contacting the Internet can omit this
> file. Of course, that won't stop them from contacting the Internet
> using raw IP addresses.

They all have business with the net, updating the stuff they run several
times a week.

> If one of your computers isn't working correctly, then you can
> troubleshoot it. We might even be able to help you, if you provide
> enough information.
>
> Use "ip a" to see the addresses that are assigned to your interfaces.
> Are those correct? If not, then you know there's an issue in step 1.
>
> Use "ip r" to see the routing table. Is the default route set
> correctly? If not, then again, it's a step 1 issue.

yes, my use of ip a for routing was a typu.

> Can your computer access the Internet, but not the other hosts on the
> LAN? Then it's probably a step 2 issue. Check your /etc/hosts file.
> Also check /etc/nsswitch.conf for good measure.
>
> Can your computer access the other hosts on the LAN, but not the
> Internet? Then it could be a step 3 thing (incorrect /etc/resolv.conf)
> if DNS is the issue. If DNS isn't the issue (e.g. if ping 8.8.8.8
> fails), then it could be an incorrect default route. Or it could be a
> firewall thing. I'm not covering firewalls here, but if you've got
> one, it could be set up incorrectly and cause *all* kinds of havoc.

No firewall. I do use iptables to protect my web pages, on this machine
from being mirrored by every bot on the planet, but that is not in series
with the miss-behaving machine, which is wired straight out of an 8 port
switch with the router doing NAT to the address you'll see in a ping
report when you ping the name in my sig.

Thanks.

[The Wanderer]

On 2022-01-22 at 18:38, gene heskett wrote:

> On Saturday, January 22, 2022 4:20:07 PM EST Greg Wooledge wrote:
>
>> On Sat, Jan 22, 2022 at 01:57:38PM -0500, gene heskett wrote:
>
>>> So my resolv.conf says to search coyote.den, and failing that,
>>> use my isp's nameserver [...]
>>
>> Again: that is NOT what the resolv.conf file does.
>>
>> The /etc/nsswitch.conf file *SHOULD* tell your system to use the
>> /etc/hosts file first, and DNS second. At least, that's the
>> default and the norm.
>
> Maybe I'm losing it, but I don't see any such directives in this
> file, copy pasted from the miss-behaving machine.
> ======================
> # /etc/nsswitch.conf

<snip>

> hosts: files mdns4_minimal [NOTFOUND=return] dns

This is the line which contains the directives involved.

The 'files' directive tells your system to check local files first; the
list of files involved is in the FILES section near the end of 'man
nsswitch.conf', and /etc/hosts is in that list.

The 'mdns4_minimal' directive tells your system to check "multicast DNS"
first; I'm not familiar with the details of this, but Google should be
helpful. The [NOTFOUND=return] tag says - I think - that if this check
returns a report that the lookup was successful but that no match was
found, the system should return that result and stop checking.

The 'dns' directive tells your system to check the DNS system proper.
Given that this is after the [NOTFOUND=return] tag, as far as I can see
this should never be reached, but I presume it's there for a reason; my
best guess is that mDNS will usually not be available, so the check will
return UNAVAIL, which (per the man page) will by default tell the system
to continue to the next check (which is this one).

> I am not all that familiar with this file, is it funkity?

I snipped most of the file, but it looks OK to me; at a glance, it looks
roughly identical to the one I've got on my own computer.

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

[Lee]

Hi Gene,

On 1/21/22, gene heskett <ghes...@shentel.net> wrote:
>
> This is all well and good, Greg, but it still does NOT give a clue what
> todo when the system picks a fictitious route out of its rear.

Once you realize that that your machine getting a 169.254.x.x address
https://en.wikipedia.org/wiki/Link-local_address
almost certainly means that DHCP has failed, you have a pretty good
idea of where to start - Why did my machine ask for a DHCP address?
Why didn't it get one?

As for avahi, my notes have
disable multicast DNS (avahi-daemon)
$ sudo systemctl disable avahi-daemon
but I have a DHCP and DNS server at home, so I'd rather have the
zero-conf stuff turned off.

Best Regards,
Lee

[David Wright]

On Sat 22 Jan 2022 at 19:07:35 (-0500), The Wanderer wrote:
> On 2022-01-22 at 18:38, gene heskett wrote:
> <snip>
>
> > hosts: files mdns4_minimal [NOTFOUND=return] dns
>
> This is the line which contains the directives involved.
>
> The 'files' directive tells your system to check local files first; the
> list of files involved is in the FILES section near the end of 'man
> nsswitch.conf', and /etc/hosts is in that list.
>
> The 'mdns4_minimal' directive tells your system to check "multicast DNS"
> first; I'm not familiar with the details of this, but Google should be
> helpful. The [NOTFOUND=return] tag says - I think - that if this check
> returns a report that the lookup was successful but that no match was
> found, the system should return that result and stop checking.
>
> The 'dns' directive tells your system to check the DNS system proper.
> Given that this is after the [NOTFOUND=return] tag, as far as I can see
> this should never be reached, but I presume it's there for a reason; my
> best guess is that mDNS will usually not be available, so the check will
> return UNAVAIL, which (per the man page) will by default tell the system
> to continue to the next check (which is this one).

Rather than its not being available, it shouldn't even try with mDNS
unless the name ends in .local, so it will skip to dns.

This is what catches people out when they think that .local is a good
choice for some random LAN, rather than one from the recommended list:
.corp, .home or .mail.

Cheers,
David.

[David Wright]

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.

[gene heskett]

On Saturday, January 22, 2022 8:52:24 PM EST Lee wrote:
> Hi Gene,
>
> On 1/21/22, gene heskett <ghes...@shentel.net> wrote:
> > This is all well and good, Greg, but it still does NOT give a clue
> > what todo when the system picks a fictitious route out of its rear.
> Once you realize that that your machine getting a 169.254.x.x address
> https://en.wikipedia.org/wiki/Link-local_address
> almost certainly means that DHCP has failed, you have a pretty good
> idea of where to start - Why did my machine ask for a DHCP address?
> Why didn't it get one?
>

Because there is not a running server on my local net, its all in the
hosts file, and changing the hostname torpedo's the hosts file lookups.

zero-conf stuff to me has never been anything but a headache.

> As for avahi, my notes have
> disable multicast DNS (avahi-daemon)
> $ sudo systemctl disable avahi-daemon
> but I have a DHCP and DNS server at home, so I'd rather have the
> zero-conf stuff turned off.
>
> Best Regards,
> Lee

Avahi, now that I do have things working again, has been removed.
Totally.

Thanks Lee, take care and stay well.

Cheers, Gene Heskett.

[gene heskett]

You're changing the subject again.

AFAIK, the only .local is in the users directory, as a subdir. Exactly
NONE of my hostnames contain a .local postfix.
> Cheers,
> David.

[The Wanderer]

On 2022-01-22 at 21:23, gene heskett wrote:

> On Saturday, January 22, 2022 9:08:02 PM EST David Wright wrote:
>
>> On Sat 22 Jan 2022 at 19:07:35 (-0500), The Wanderer wrote:

>> > This is the line which contains the directives involved.
>> >
>> > The 'files' directive tells your system to check local files first;
>> > the list of files involved is in the FILES section near the end of
>> > 'man nsswitch.conf', and /etc/hosts is in that list.
>> >
>> > The 'mdns4_minimal' directive tells your system to check "multicast
>> > DNS" first; I'm not familiar with the details of this, but Google
>> > should be helpful. The [NOTFOUND=return] tag says - I think - that
>> > if this check returns a report that the lookup was successful but
>> > that no match was found, the system should return that result and
>> > stop checking.
>> >
>> > The 'dns' directive tells your system to check the DNS system proper.
>> > Given that this is after the [NOTFOUND=return] tag, as far as I can
>> > see this should never be reached, but I presume it's there for a
>> > reason; my best guess is that mDNS will usually not be available, so
>> > the check will return UNAVAIL, which (per the man page) will by
>> > default tell the system to continue to the next check (which is this
>> > one).
>>
>> Rather than its not being available, it shouldn't even try with mDNS
>> unless the name ends in .local, so it will skip to dns.

Hmm. Looking at nsswitch.conf(5), it seems clear that the mdns4_minimal
module must return *something* in that case, so I wonder what it might
be. The obvious thing to return is NOTFOUND, but this tag turns the
result of that from "continue to try the next thing" to "stop
processing, and report back that no match was found", so that isn't
plausible.

>> This is what catches people out when they think that .local is a good
>> choice for some random LAN, rather than one from the recommended list:
>> .corp, .home or .mail.
>>
> You're changing the subject again.

It doesn't look that way to me; he's explaining something I
misunderstood, which provides more context.

This might be branching out a bit from what your original discussion was
about, but that's neither unexpected (thread drift is a thing, as are
subthreads) nor - so long as your original subject is still being
addressed, which it seems to be - a real problem.

> AFAIK, the only .local is in the users directory, as a subdir. Exactly
> NONE of my hostnames contain a .local postfix.

That's exactly as expected.

For the hostnames which are in /etc/hosts, the lookup process won't ever
get this far, so the question of a '.local' suffix won't even become
relevant.

For the hostnames which aren't in that file, since none of them have
that suffix, the mdns4_minimal entry in nsswitch.conf won't ever
trigger, so any names that get that far will just proceed on for lookup
via standard DNS.

[Andrei POPESCU]

On Sb, 22 ian 22, 20:07:45, David Wright wrote:
>
> 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.

Instead of listing the machine's name with 127.0.1.1 I'm using it's
actual IP (like the one you have in the comment).

Any potential issues I should be aware of?

As far as I can tell (with my limited understanding of DNS) it only
makes it easier to share /etc/hosts with no obvious downside.

[deloptes]

Andrew M.A. Cater wrote:

> If you want to know how to run (fairly)
> vanilla Debian - but including the non-free raspberry pi firmware
> and rpi-eeprom - it's possible using either Gunnar Wolf's images
> or Pete Batard's version of UEFI for the Pi 4 and the Debian
> arm64 ISO file. _That_ I can help you with.

I use the RPi with Debian, but not after I adopted their kernel. So all that
was necessary to do is to copy the few packages.
I find this as good compromise

--
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0

[Andrei POPESCU]

On Sb, 22 ian 22, 07:13:18, gene heskett wrote:
>
> its for its own eth0 on the rpi4b. And I guess it is raspi specific. It
> doesn't exist on this x86-64 bullseye install.

Likely the source of your problems is that Raspberry Pi OS has DHCP
enabled by default.

It might have been done using Debian specific tools (ifupdown, i.e.
/etc/network/interfaces or files under /etc/network/interfaces.d/), some
other known tools (systemd-networkd, Network Manager, etc.), or their
own concoction.

If you intend on keeping the Raspberry Pi OS you have to learn how it's
configured and deal with that.

[Greg Wooledge]

If that actually works, that's great news for Gene. It means he can
duplicate a single /etc/hosts file across all systems without needing
to bolt on a unique per-system header afterward.

In terms of operation, the main difference as far as I understand it
is that a connection to "acer" (or whatever your system's own name is)
will be directed to the ethernet interface instead of the loopback
interface. So, if you've got a daemon that's only bound to loopback,
you would need to contact it via the name "localhost" rather than the
system's name. Whereas in the regular Debian setup that has 127.0.1.1
bound to the system's name, either one works.

[David Wright]

On Sun 23 Jan 2022 at 08:50:56 (+0100), Andrei POPESCU wrote:
> On Sb, 22 ian 22, 20:07:45, David Wright wrote:
> >
> > 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.
>
> Instead of listing the machine's name with 127.0.1.1 I'm using it's
> actual IP (like the one you have in the comment).
>
> Any potential issues I should be aware of?

Yes, and ISTR its being discussed on d-u perhaps 20 years ago.
It means that software can get the hostname resolved to an IP
address a) before DNS is running, and b) before any interfaces
are configured, or when they fail to get configured at all.
Otherwise, you get a response to ping, say, like:
ping: connect: Network is unreachable
instead of a response from the loopback address.

> As far as I can tell (with my limited understanding of DNS) it only
> makes it easier to share /etc/hosts with no obvious downside.

The idea of the script is to make sharing it as trivial as using
scp directly. And if you use sneakernet to transfer the master
file and the script, the latter should still work, because Debian
sets up 127.0.1.1 at installation time.

Cheers,
David.

[Felix Miata]

Greg Wooledge composed on 2022-01-23 08:42 (UTC-0500):

> On Sun, Jan 23, 2022 at 08:50:56AM +0100, Andrei POPESCU wrote:

>> As far as I can tell (with my limited understanding of DNS) it only
>> makes it easier to share /etc/hosts with no obvious downside.

> If that actually works, that's great news for Gene. It means he can
> duplicate a single /etc/hosts file across all systems without needing
> to bolt on a unique per-system header afterward.

I've been sharing the very same hosts file among all my PCs for well over a
decade, probably closer to two.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[gene heskett]

On Sunday, January 23, 2022 1:26:56 PM EST Felix Miata wrote:
> Greg Wooledge composed on 2022-01-23 08:42 (UTC-0500):
> > On Sun, Jan 23, 2022 at 08:50:56AM +0100, Andrei POPESCU wrote:
> >> As far as I can tell (with my limited understanding of DNS) it only
> >> makes it easier to share /etc/hosts with no obvious downside.
> >
> > If that actually works, that's great news for Gene. It means he can
> > duplicate a single /etc/hosts file across all systems without needing
> > to bolt on a unique per-system header afterward.
>
> I've been sharing the very same hosts file among all my PCs for well
> over a decade, probably closer to two.

And I have been for 2 decades and change as it once had an amiga as one
of its clients.

[Brian]

On Sun 23 Jan 2022 at 13:53:01 -0500, gene heskett wrote:

> On Sunday, January 23, 2022 1:26:56 PM EST Felix Miata wrote:
> > Greg Wooledge composed on 2022-01-23 08:42 (UTC-0500):
> > > On Sun, Jan 23, 2022 at 08:50:56AM +0100, Andrei POPESCU wrote:
> > >> As far as I can tell (with my limited understanding of DNS) it only
> > >> makes it easier to share /etc/hosts with no obvious downside.
> > >
> > > If that actually works, that's great news for Gene. It means he can
> > > duplicate a single /etc/hosts file across all systems without needing
> > > to bolt on a unique per-system header afterward.
> >
> > I've been sharing the very same hosts file among all my PCs for well
> > over a decade, probably closer to two.
>
> And I have been for 2 decades and change as it once had an amiga as one
> of its clients.

What advice would you give to a user regarding the benefits of a hosts
file as opposed to more modern techniques?

--
Brian.

[Charles Curley]

On Sun, 23 Jan 2022 19:09:27 +0000
Brian <ad...@cityscape.co.uk> wrote:

> What advice would you give to a user regarding the benefits of a hosts
> file as opposed to more modern techniques?

By "more modern techniques" I will assume you mean DHCP and DNS.

Hosts files are simple, easy to do. They have to be propagated and
maintained, so they are obnoxious from time to time.

With no DHCP, you have to had configure each host's network interface,
usually at installation time, or when you introduce a computer to your
network. This isn't always possible.

Also, you will still need a DNS client on each machine so they can
resolve external host names.

DNS and DHCP require a lot more configuration up front. But once they
are done, that can be all you have to do, and you shouldn't have to do
anything at installation or introduction time. You can use DHCP to
assign fixed IP addresses to some (or all) hosts, but that means some
one-time configuration.

A side benefit of running your own DNS server is that your hosts look
to it, rather than to your ISP's server, which usually means faster
turn-around time for lookups.

Which is easier depends in part on how many hosts you have at any one
time, what they are, and how often new ones arrived. These days, new
arrivals may also mean guests' mobile phones and laptops.

It may also mean "smart" gadgets. I have a pressure cooker on my
network, and I doubt the creators of DNS had those in mind way back
when. I don't think my pressure cooker has any way to manually
configure its IP address, so it pretty well requires DHCP.

If I were running an internet cafe or a computer repair shop, I would
insist on DHCP and DNS. At the other end of the scale, if you only have
a few machines and don't care about your guests' machines or "smart"
gadgets, a hosts file may be simpler.

I hope that provides some guidance.

--

Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[Greg Wooledge]

I'll treat this question as "static interface configuration and hosts
files".

The advantage is that it's conceptually simpler.

The disadvantages are numerous.

* Adding a new host, or changing a host's IP address, requires
platform-specific knowledge on the host in question. On a
heterogeneous network, that means you need knowledge of how to do
this on all the different platforms. This may include devices like
printers, where it's quite difficult, maybe even impossible, to
configure an address without DHCP.

* After a change is made, it has to be replicated across your entire
network. Manually.

* Any "visitor" machines that are temporarily added to your network will
need to be configured manually, and they will have zero knowledge of
the other hosts on the network. Even if you know their names, there
won't be any DNS in which you can look up their addresses.

For anyone setting up a new home network, I'd recommend using DHCP. It
will be a lot simpler in the long run, especially if you start adding
wireless devices (cell phones, tablets, TV streaming devices, etc.).
Your router probably already acts as a DHCP server, so all you need to
do is learn how to configure fixed addresses for specific computers (and
printers) that want to act like servers. The other devices can just get
random addresses. Guest machines can just be connected and start working
without issues.

[Felix Miata]

Greg Wooledge composed on 2022-01-23 15:01 (UTC-0500):

> * After a change is made, it has to be replicated across your entire
> network. Manually.

But trivial.

> * Any "visitor" machines that are temporarily added to your network will
> need to be configured manually, and they will have zero knowledge of
> the other hosts on the network. Even if you know their names, there
> won't be any DNS in which you can look up their addresses.

This can be an advantage. I don't need or want visitors' cell phones accessing my
machines willy nilly.

[gene heskett]

Because every distro has their own way of arriving at a _usually_ works
dhcp setup, the fixed rules for using a hosts file usually results in
less need for esoteric knowledge of how a given distro does it, and a far
more consistently working local net. We've probably in excess of 60
machines by now at the tv station I retired from in 2002, and a common
hosts file similar to my own setup still works fine. The main diff is
that we bought a block of 16 addresses from a registrar in about 1995,
and only those machines are network allowed outside of the buildings
network. Most are sales machines running winderz, so we have had our
share of viri. The heart of the system is linux, mostly centos,
including the inhouse built videoservers, two of which can record 4 hidef
channels each, while playing 4 other programs to air at the same time.

They Just Work, unlike commercial winderz stuff that BSODs every 3 hours.

dhcp is nice, when it works, but to me it needless complexity and yet
anther point of failure. For big systems, its ok, but for under 100
machines, tain't needed. At about 50 machines, a full time tech is
needed, if only to clean up the viri in the sales machines. Gotta keep
the cash cow fresh you know. ;o)

[Brian]

On Sun 23 Jan 2022 at 12:52:27 -0700, Charles Curley wrote:

> On Sun, 23 Jan 2022 19:09:27 +0000
> Brian <ad...@cityscape.co.uk> wrote:
>
> > What advice would you give to a user regarding the benefits of a hosts
> > file as opposed to more modern techniques?
>
> By "more modern techniques" I will assume you mean DHCP and DNS.
>
> Hosts files are simple, easy to do. They have to be propagated and
> maintained, so they are obnoxious from time to time.

I was rather hoping for some mention of the role of Avahi and
libnss-mdns on the local network amd its minimal maintenamce.

--
Brian.

[Brian]

On Sun 23 Jan 2022 at 15:14:54 -0500, Felix Miata wrote:

>
>
> Greg Wooledge composed on 2022-01-23 15:01 (UTC-0500):
>
> > * After a change is made, it has to be replicated across your entire
> > network. Manually.
>
> But trivial.

Manual intervention as opposed to no intervention. What price
libnss-mdns?

>
> > * Any "visitor" machines that are temporarily added to your network will
> > need to be configured manually, and they will have zero knowledge of
> > the other hosts on the network. Even if you know their names, there
> > won't be any DNS in which you can look up their addresses.
>
> This can be an advantage. I don't need or want visitors' cell phones accessing my
> machines willy nilly.

You obviously do not trust your network setup sufficiently to allow
access to it from other devices. Something to be attemded to.

--
Brian.

[Charles Curley]

On Sun, 23 Jan 2022 23:42:33 +0000
Brian <ad...@cityscape.co.uk> wrote:

> I was rather hoping for some mention of the role of Avahi and
> libnss-mdns on the local network amd its minimal maintenamce.

I seem to have it installed, mostly to support an apple Macbook. But I
did not configure it in any way. Apparently, it Just Works™, at least
for the small use I make of it.

Someone else will have to help you there.

[David Wright]

Yes, I'd agree with all those arguments for DHCP, which is why I use
it, hence its inclusion in my post at the top of this subthread, and
why I can't understand Gene's aversion to it. But that's all about
configuration, and the quoted comment at the top of this post is AIUI
about /resolving/ hostnames through /etc/hosts.

Some of us (not including Gene) don't have DNS resolvers built into
our routers, and don't want to have to run 24/7 yet another piece of
hardware (other than the already necessary modem and router
(routers in my case).

So from the list of IP addresses, hostnames and MAC addresses,
configured into and printed out from my master router, I compiled
a master list of the first and second items, which is transformed
into /etc/hosts as already shown. From the length of my list,
I'd estimate an addition or deletion occurs about twice a year—
less frequently really, as often they're paired +-.

(And I did answer Andrei's comment, albeit after you'd posted.
It's no harder to distribute transformed files than identical ones.)

But to get back to Gene's network, and his lack of certainty that,
when "ssh -Y rpi4" is typed, "dhcp hasn't rerouted my ssh session
to tlm.coyote.den." Well, from what we've been told (or it might be
from what's been gleaned over the years), we have a dozen machines
with, we hope, identical lists of hostname≡IPaddress in /etc/hosts,
but instead of a single location for their IPaddress configuration,
we have a dozen /e/n/i files. Just to make it more difficult to check
them, none of the latter will contain a hostname, of course, but only
a static IP address.

That seems a lot less robust than having two lists that can be
compared side by side, as I described in my own setup. If I had
a setup like that, I'd make sure that my /etc/hosts-distribution
script provoked a script on the target to check that the address
in /e/n/i matched the target's entry in /etc/hosts.

A couple of posts further up this subthread:

> > > > >> On Sb, 22 ian 22, 20:07:45, David Wright wrote:

> > > > >> > On Sat 22 Jan 2022 at 13:57:38 (-0500), gene heskett wrote:
> > > > >> > > 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.

It later struck me that there's a clue in Gene writing: "Linux [ignores]

what I put in a file in /etc/network/interfaces.d/anyoldname."

I can only assume that that means Gene has observed a disagreement between:

/etc/hosts on any host containing

IPADDR HOSTNAME

and:

/etc/network/interfaces.d/anyoldname on the host HOSTNAME containing

address IPADDR/24

Unless, of course, Gene has "nuked" /e/n/i (strictly, the file
/etc/network/interfaces itself).

Cheers,
David.

[Brian]

Resolving hostnames on the local network is simple and reliable when
avahi-daemon and linnss-mdns are available.

brian@desktop:~$ getent hosts envy4500.local
192.168.7.235 envy4500.local

Continually and nanually maintain /etc/hosts? Not in 2022!

--
Brian.

[Andrei POPESCU]

On Lu, 24 ian 22, 23:54:41, Brian wrote:
>
> Resolving hostnames on the local network is simple and reliable when
> avahi-daemon and linnss-mdns are available.
>
> brian@desktop:~$ getent hosts envy4500.local
> 192.168.7.235 envy4500.local
>
> Continually and nanually maintain /etc/hosts? Not in 2022!

Ok, I'll bite :)

Could you point to any (reasonably up-to-date) documentation or is it
sufficient to just install avahi-daemon and libnss-mdns?

Can mDNS resolve only hostnames or is it necessary to always mention the
'.local' domain?

Thanks,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser

[Brian]

On Tue 25 Jan 2022 at 09:31:57 +0100, Andrei POPESCU wrote:

> On Lu, 24 ian 22, 23:54:41, Brian wrote:
> >
> > Resolving hostnames on the local network is simple and reliable when
> > avahi-daemon and linnss-mdns are available.
> >
> > brian@desktop:~$ getent hosts envy4500.local
> > 192.168.7.235 envy4500.local
> >
> > Continually and nanually maintain /etc/hosts? Not in 2022!
>
> Ok, I'll bite :)
>
> Could you point to any (reasonably up-to-date) documentation or is it
> sufficient to just install avahi-daemon and libnss-mdns?

'apt install avahi-daemon' is sufficient. libnnss-mdns is a recommended
package of avahi-daemon. Machines with cups installed will already have
both packages. Documentation is at

https://www.avahi.org/
https://github.com/lathiat/nss-mdns

and in /usr/share/doc.

> Can mDNS resolve only hostnames or is it necessary to always mention the
> '.local' domain?

.local is required.

--
Brian.

[Andrei POPESCU]

Less than optimal (yes, I'm lazy), but I might be able to live with it ;)

Is there a way to have "generic" names, e.g. something like "mpd.local",
independent of the system's hostname?

I like to name systems based on their hardware, not based on the
service(s) they provide.

If for some reason I want to move the mpd service from one system to
another, how can I do that without having to reconfigure all clients?

My current solution is to point something like mpd.(mylocaldomain) to
the correct IP address in the router (OpenWrt) and use that in all
clients[1]. If I need to move the service to another system I only need
to adjust the configuration in one place.


(I'm aware mpd might not be the best example here, since as far as I
know it has native zeroconf support, but let's just assume clients are
either buggy or lack zeroconf support completely. Besides, this would
apply also to services without zeroconf support.)


[1] shared /etc/hosts doesn't work for this, because some clients are
running on systems where deploying a custom /etc/hosts would be too
complicated (assuming /etc/hosts or something like it is even
supported).

[Brian]

On Tue 25 Jan 2022 at 13:06:49 +0100, Andrei POPESCU wrote:

> On Ma, 25 ian 22, 11:18:21, Brian wrote:
> > On Tue 25 Jan 2022 at 09:31:57 +0100, Andrei POPESCU wrote:
> > >
> > > Could you point to any (reasonably up-to-date) documentation or is it
> > > sufficient to just install avahi-daemon and libnss-mdns?
> >
> > 'apt install avahi-daemon' is sufficient. libnnss-mdns is a recommended
> > package of avahi-daemon. Machines with cups installed will already have
> > both packages. Documentation is at
> >
> > https://www.avahi.org/
> > https://github.com/lathiat/nss-mdns
> >
> > and in /usr/share/doc.
> >
> > > Can mDNS resolve only hostnames or is it necessary to always mention the
> > > '.local' domain?
> >
> > .local is required.
>
> Less than optimal (yes, I'm lazy), but I might be able to live with it ;)

It grows on you :).

> Is there a way to have "generic" names, e.g. something like "mpd.local",
> independent of the system's hostname?

Let's see if this addresses your question:

Install avahi-utils. For a complete view of the network, do

avahi-browse -art | less

For a spcific service, do

avahi-browse -rt _mpd._tcp

on the same or another machine. _mpd._tcp is a service name and is
"something like "mpd.local"".

(BTW, I had to disable and mask mpd.socket for the commands to give
outputs for mpd).

> I like to name systems based on their hardware, not based on the
> service(s) they provide.
>
> If for some reason I want to move the mpd service from one system to
> another, how can I do that without having to reconfigure all clients?

Relocation on the same network should not need client reconfiguration.

> My current solution is to point something like mpd.(mylocaldomain) to
> the correct IP address in the router (OpenWrt) and use that in all
> clients[1]. If I need to move the service to another system I only need
> to adjust the configuration in one place.
>
>
> (I'm aware mpd might not be the best example here, since as far as I
> know it has native zeroconf support, but let's just assume clients are
> either buggy or lack zeroconf support completely. Besides, this would
> apply also to services without zeroconf support.)

I'm a little lost here. If services or clients lack Avahi integration,
they cannot avail themselves of its services.

--
Brian.

[Brian]

On Tue 25 Jan 2022 at 16:20:49 +0000, Brian wrote:

> on the same or another machine. _mpd._tcp is a service name and is

Correction. _mpd._tcp is a service type.

--
Brian.

[David Wright]

On Tue 25 Jan 2022 at 09:31:57 (+0100), Andrei POPESCU wrote:
> On Lu, 24 ian 22, 23:54:41, Brian wrote:
> >
> > Resolving hostnames on the local network is simple and reliable when
> > avahi-daemon and linnss-mdns are available.
> >
> > brian@desktop:~$ getent hosts envy4500.local
> > 192.168.7.235 envy4500.local
> >
> > Continually and nanually maintain /etc/hosts? Not in 2022!

More like biannually :-)

It's just pointless here, on such a static network. If I'm going to
login to the router to add a MAC, then editing and distributing my
master list is trivial. Last change: 2021-02-04, when I got hold of
a redundant computer.

> Ok, I'll bite :)
>
> Could you point to any (reasonably up-to-date) documentation or is it
> sufficient to just install avahi-daemon and libnss-mdns?

I looked at the Debian wiki: ouch. It seems to have been spammed
a while back, and hasn't been touched in 4½ years. Although the
Arch wiki is far better, I'm not able to judge how much one might
be led astray by the differences between Arch and Debian.

I can't speak to Gene's wanting a static network configured by his
method, but I'm happy to defend my choice.

Cheers,
David.

[gene heskett]

It works fine with no complaints.

Here is the bottom of /etc/dhcpcd.conf:

# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1

# It is possible to fall back to a static IP if DHCP fails:
# define static profile
profile static_eth0
static ip_address=192.168.71.13/24
static routers=192.168.71.1
static domain_name_servers=192.168.71.1

# fallback to static profile on eth0
interface eth0
fallback static_eth0

So if dhcpd fails, it uses the above, and it Just Works.
And I've not found any reference to it in the man page. So I've no clue
why it seems to be such a huge, no one knows about it secret.

Cheers David, and stay well, Gene Heskett.

[Greg Wooledge]

On Tue, Jan 25, 2022 at 09:27:17PM -0500, gene heskett wrote:
> Here is the bottom of /etc/dhcpcd.conf:

WHY do you HAVE a dhcpcd.conf file if you don't use DHCP on your network?

Or... well, you're not using Debian. You're using Raspbian, and Raspbian
installs dhcpcd by default as I understand it. So that's why you HAVE
the file. So I guess the real question is:

WHY are you LOOKING AT this file, when you know that it's not used, because
you don't have DHCP on your network?

Or... if it turns out that it IS being used, even in the absence of a
DHCP server, then go bother a Raspbian mailing list with your questions
about this piece of software and the issues that it's causing you.
Because those of us who run Debian, on the debian-user mailing list,
do not typically install dhcpcd, nor do we know how it works.

Debian uses isc-dhcp-client, which is a VERY different program.

[David Wright]

On Tue 25 Jan 2022 at 21:27:17 (-0500), gene heskett wrote:
> On Tuesday, January 25, 2022 7:35:54 PM EST David Wright wrote:
> > I can't speak to Gene's wanting a static network configured by his
> > method, but I'm happy to defend my choice.
> >

> It works fine with no complaints.

OK. I've already forgotten what you complained in this thread's OP.

> Here is the bottom of /etc/dhcpcd.conf:
>
> # Example static IP configuration:
> #interface eth0
> #static ip_address=192.168.0.10/24
> #static ip6_address=fd51:42f8:caae:d92e::ff/64
> #static routers=192.168.0.1
> #static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1
>
> # It is possible to fall back to a static IP if DHCP fails:
> # define static profile
> profile static_eth0
> static ip_address=192.168.71.13/24
> static routers=192.168.71.1
> static domain_name_servers=192.168.71.1
>
> # fallback to static profile on eth0
> interface eth0
> fallback static_eth0
>
> So if dhcpd fails, it uses the above, and it Just Works.
> And I've not found any reference to it in the man page. So I've no clue
> why it seems to be such a huge, no one knows about it secret.

Drum roll … …

CONTENTS/usr/share/man/man5/dhcpcd.conf.5.gz

DHCPCD.CONF(5) BSD File Formats Manual DHCPCD.CONF(5)

NAME
dhcpcd.conf — dhcpcd configuration file

[ … ]

profile name
Subsequent options are only parsed for this profile name.

[ … ]

static value
Configures a static value. If you set ip_address then dhcpcd
will not attempt to obtain a lease and will just use the value
for the address with an infinite lease time. If you set
ip6_address, dhcpcd will continue auto-configuation as normal.

[ … ]

interface eth0
[ … ]
static ip_address=192.168.0.10/24
[ … ]
static routers=192.168.0.1
static domain_name_servers=192.168.0.1

[ … ]

fallback profile
Fall back to using this profile if DHCP fails. This allows you
to configure a static profile instead of using ZeroConf.

/That/ seems clear enough to me.

But excuse me if I was labouring under the impression that you wanted
to nuke DHCP lest "some coder dinking around in dhcp code thinks the
whole world is volatile".

Cheers,
David.

[gene heskett]

`twould indeed be clear David, but man keeps telling me no such file.

> But excuse me if I was labouring under the impression that you wanted
> to nuke DHCP lest "some coder dinking around in dhcp code thinks the
> whole world is volatile".

The responses I get from this list or any list positively reeks of NIH
syndrome if you want to do something different for a home net that
doesn't depend on dhcp. hosts files existed and ran the internet before
dhcp. I remember using them on both pc's and amiga's 30 years ago. Its
the short term memory that is plaguing me now. Can you remember using
trumpet on a pc? I can. The amiga's had miami for a net driver but I
can't recall if I used it when I wrote our first web page server in ARexx
we used when we went live on the net for news, pulling the text from the
teleprompter. WDTV was in the first 5 tv stations in the country that had
a web page that went live as the live tv news show closed. It also demo'd
the atrocious spelling of our journalists which got rather hilarious at
times. :o)

At 87, I spend a lot of time contemplating the hereafter, I get up to go
get a tool, and when I get to where the tool might be, I have to stop
until I can remember what I'm hereafter. ;-)

> Cheers,
> David.
>
> .
Take care and stay well David.

Cheers, Gene Heskett.

[Brian]

On Tue 25 Jan 2022 at 18:35:54 -0600, David Wright wrote:

> On Tue 25 Jan 2022 at 09:31:57 (+0100), Andrei POPESCU wrote:
> > On Lu, 24 ian 22, 23:54:41, Brian wrote:
> > >
> > > Resolving hostnames on the local network is simple and reliable when
> > > avahi-daemon and linnss-mdns are available.
> > >
> > > brian@desktop:~$ getent hosts envy4500.local
> > > 192.168.7.235 envy4500.local
> > >
> > > Continually and nanually maintain /etc/hosts? Not in 2022!
>
> More like biannually :-)
>
> It's just pointless here, on such a static network. If I'm going to
> login to the router to add a MAC, then editing and distributing my
> master list is trivial. Last change: 2021-02-04, when I got hold of
> a redundant computer.

I am sure sue the use of the dawn of time /etc/hosts is a workabble
solution. However many (most?) users will have libnns-mdns installed
and immediately up to the job of resolving hostnames on a statically
or dynamically configured network and is maintenance-free. Why not use
it?

> > Ok, I'll bite :)
> >
> > Could you point to any (reasonably up-to-date) documentation or is it
> > sufficient to just install avahi-daemon and libnss-mdns?
>
> I looked at the Debian wiki: ouch. It seems to have been spammed
> a while back, and hasn't been touched in 4½ years. Although the
> Arch wiki is far better, I'm not able to judge how much one might
> be led astray by the differences between Arch and Debian.

Ouch indeed! The baisc structure and content of the wiki page was
established in 2006. Its stated purpose is for "...tracking how Debian
supports mdns and zeroconf stuff,...". The Discussion section is (IMO)
inappropriate for a wiki page.

The Arch wiki page is technically more informed and, with care, would
guide a Debian user in the right direcion.

Having said that, 'ssh desktop.local' does not require much guidance.

--
Brian.

[gene heskett]

If a machine is "there" to reply, which one is it?

[Brian]

Sorry, I don't follow.

--
Brian.

[Brian]

On Wed 26 Jan 2022 at 15:54:38 +0000, mick crane wrote:

> On 2022-01-26 15:31, Brian wrote:
>
> > Having said that, 'ssh desktop.local' does not require much guidance.
>

> Is .local mDNS specific ?

Yes.

> I thought we are supposed to not use .local for a home network.

That caveat is for allocating a domain name.

--
Brian.

[David Wright]

On Wed 26 Jan 2022 at 15:31:46 (+0000), Brian wrote:
> On Tue 25 Jan 2022 at 18:35:54 -0600, David Wright wrote:
> > On Tue 25 Jan 2022 at 09:31:57 (+0100), Andrei POPESCU wrote:
> > > On Lu, 24 ian 22, 23:54:41, Brian wrote:
> > > >
> > > > Resolving hostnames on the local network is simple and reliable when
> > > > avahi-daemon and linnss-mdns are available.
> > > >
> > > > brian@desktop:~$ getent hosts envy4500.local
> > > > 192.168.7.235 envy4500.local
> > > >
> > > > Continually and nanually maintain /etc/hosts? Not in 2022!
> >
> > More like biannually :-)
> >
> > It's just pointless here, on such a static network. If I'm going to
> > login to the router to add a MAC, then editing and distributing my
> > master list is trivial. Last change: 2021-02-04, when I got hold of
> > a redundant computer.
>
> I am sure sue the use of the dawn of time /etc/hosts is a workabble
> solution. However many (most?) users will have libnns-mdns installed
> and immediately up to the job of resolving hostnames on a statically
> or dynamically configured network and is maintenance-free. Why not use
> it?

Me personally? Because I want to avoid any complications with
configuring two cooperating routers; because I want to be able to spot
"foreign" interfaces by IP# (my brain doesn't work with either UUIDs
or MACs); because I want to be able to poke a hole into my network,
which raises security concerns; because I want to recognise that
two IP#s point to the same machine (MACs again); because knowing
how it all works is more valuable to me than the effort of lifting
a finger to maintain it once in a while.

Bear in mind that I'm likely installing Debian on something at
the time I'm making said tweak, and perhaps having to relocate
some functionailty to another machine if there's one heading for
recycling at the same time. With running the d-i and configuring
the router, what's to get worked up about with adding a line to
/etc/hosts?

I've worked this way for 15 years and, unlike Gene, I'm not having
to fight any battles over it. I'm sure mDNS is perfect for people
with different demands from mine.

Cheers,
David.

[David Wright]

On Wed 26 Jan 2022 at 05:14:32 (-0500), gene heskett wrote:
> On Tuesday, January 25, 2022 11:36:05 PM EST David Wright wrote:
> > On Tue 25 Jan 2022 at 21:27:17 (-0500), gene heskett wrote:
> > > On Tuesday, January 25, 2022 7:35:54 PM EST David Wright wrote:
> > > > I can't speak to Gene's wanting a static network configured by his
> > > > method, but I'm happy to defend my choice.
> > >
> > > It works fine with no complaints.
> >

> > OK. I've already forgotten what you complained [about] in this thread's OP.

And the first word in "CONTENTS/usr/share/man/man5/dhcpcd.conf.5.gz"
should tell you that I don't have that file either, but I downloaded
dhcpcd5_7.1.0-2+b1_amd64.deb just as I did last time you raised this.
And if I type "man" into google, I get a list of previously sought
man pages as the response, rather than "camera tv".

> > But excuse me if I was labouring under the impression that you wanted
> > to nuke DHCP lest "some coder dinking around in dhcp code thinks the
> > whole world is volatile".
>
> The responses I get from this list or any list positively reeks of NIH
> syndrome if you want to do something different for a home net that
> doesn't depend on dhcp. hosts files existed and ran the internet before
> dhcp.

And when you install Debian, it helpfully writes one for you. I don't
know what is NIH about that. But your response here doesn't state
unambiguously whether you want to run DHCP or not, nor whether you do
or don't. Others have suggested that the OS you're actually dealing
with is one that sets up certain things in a non-Debian manner. If so,
then you need to investigate what those things are, and fit your
changes round them, rather than just fighting it, trying to return to
some "Golden Age" of networking from the 1990s.

Cheers,
David.

[Greg Wooledge]

On Wed, Jan 26, 2022 at 10:42:23AM -0600, David Wright wrote:
> And the first word in "CONTENTS/usr/share/man/man5/dhcpcd.conf.5.gz"
> should tell you that I don't have that file either, but I downloaded
> dhcpcd5_7.1.0-2+b1_amd64.deb just as I did last time you raised this.
> And if I type "man" into google, I get a list of previously sought
> man pages as the response, rather than "camera tv".

Why not just use
<https://manpages.debian.org/bullseye/dhcpcd5/dhcpcd.conf.5.en.html>?
Is it too new? You can replace "bullseye" with "buster" in the URL.
Or "stretch", etc.

[Andrei POPESCU]

On Mi, 26 ian 22, 11:55:36, Greg Wooledge wrote:
> On Wed, Jan 26, 2022 at 10:42:23AM -0600, David Wright wrote:
> > And the first word in "CONTENTS/usr/share/man/man5/dhcpcd.conf.5.gz"
> > should tell you that I don't have that file either, but I downloaded
> > dhcpcd5_7.1.0-2+b1_amd64.deb just as I did last time you raised this.
> > And if I type "man" into google, I get a list of previously sought
> > man pages as the response, rather than "camera tv".
>
> Why not just use
> <https://manpages.debian.org/bullseye/dhcpcd5/dhcpcd.conf.5.en.html>?

+1 for manpages.debian.org, it's even possible to have it as an
additional search engine in browsers that support it.

> Is it too new? You can replace "bullseye" with "buster" in the URL.
> Or "stretch", etc.

I should close #931992 then ;)

[Andrei POPESCU]

On Ma, 25 ian 22, 21:27:17, gene heskett wrote:
>
> It works fine with no complaints.
>
> Here is the bottom of /etc/dhcpcd.conf:
>
> # Example static IP configuration:
> #interface eth0
> #static ip_address=192.168.0.10/24
> #static ip6_address=fd51:42f8:caae:d92e::ff/64
> #static routers=192.168.0.1
> #static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1
>
> # It is possible to fall back to a static IP if DHCP fails:
> # define static profile
> profile static_eth0
> static ip_address=192.168.71.13/24
> static routers=192.168.71.1
> static domain_name_servers=192.168.71.1
>
> # fallback to static profile on eth0
> interface eth0
> fallback static_eth0
>
> So if dhcpd fails, it uses the above, and it Just Works.
> And I've not found any reference to it in the man page. So I've no clue
> why it seems to be such a huge, no one knows about it secret.

This must be the most complicated, round-about, inefficient method I've
ever seen to configure a static IP :)

Is it so difficult to find out what is the canonical method to configure
a static IP on a Raspberry Pi OS? This is such a basic task it should be
somewhere in their documentation, wiki, whatever.

Even if they don't officially support static IPs (which I seriously
doubt), you could still find out what is starting dhcpcd and disable it.

Then it should be possible to configure a static IP with any of Debian's
network management tools you like. You might need to install it first
though, preferably while the network connection is still up ;).

[Reco]

On Wed, Jan 26, 2022 at 07:11:36PM +0100, Andrei POPESCU wrote:
> > # fallback to static profile on eth0
> > interface eth0
> > fallback static_eth0
> >
> > So if dhcpd fails, it uses the above, and it Just Works.
> > And I've not found any reference to it in the man page. So I've no clue
> > why it seems to be such a huge, no one knows about it secret.
>
> This must be the most complicated, round-about, inefficient method I've
> ever seen to configure a static IP :)

I disagree. One can install NetworkManager, and then it will get even
more complicated.

> Is it so difficult to find out what is the canonical method to configure
> a static IP on a Raspberry Pi OS? This is such a basic task it should be
> somewhere in their documentation, wiki, whatever.

Curiously enough, this time Gene used "official" way to configure static
IP on RPi - [1]. Official documentation does not even mention e/n/i.

> Then it should be possible to configure a static IP with any of Debian's
> network management tools you like.

And *that* would be fighting the distribution-approved method, and not
working with it. It's totally possible (I did it), but then again, it's
totally possible to install a real Debian on RPi.


All this once again proves us, folks - RaspberryPi OS is not Debian. It's
Debian-based. Certain list members do not see the difference, let's
refrain from pointing fingers :)

Reco

[1] https://www.raspberrypi.com/documentation/computers/configuration.html#static-ip-addresses

[Brian]

On Wed 26 Jan 2022 at 10:42:38 -0600, David Wright wrote:

[Snipping]

> I've worked this way for 15 years and, unlike Gene, I'm not having
> to fight any battles over it. I'm sure mDNS is perfect for people
> with different demands from mine.

My question was really directed at all users, particularly those who
do not appreciate the existance or basic function of Avahi. I am not
dead set aginst /etc/hosts and the explantion of your successful mode
of working should give pause for thought.

--
Brian.

[Greg Wooledge]

I don't know how many people know *anything* about it at all. I certainly
don't, other than what's been mentioned in this thread.

[gene heskett]

I wasn't aware of that resource, thank you.
> .

[gene heskett]

IDK for sure, but the descriptions I've speed read, seem to indicate a
rather wild card approach, and that spooks me a bit, so I was trying to
be a little facetious. Obviously I failed.

Thanks Brian

[David Wright]

On Wed 26 Jan 2022 at 18:56:17 (+0100), Andrei POPESCU wrote:
> On Mi, 26 ian 22, 11:55:36, Greg Wooledge wrote:
> > On Wed, Jan 26, 2022 at 10:42:23AM -0600, David Wright wrote:
> > > And the first word in "CONTENTS/usr/share/man/man5/dhcpcd.conf.5.gz"
> > > should tell you that I don't have that file either, but I downloaded
> > > dhcpcd5_7.1.0-2+b1_amd64.deb just as I did last time you raised this.
> > > And if I type "man" into google, I get a list of previously sought
> > > man pages as the response, rather than "camera tv".
> >
> > Why not just use
> > <https://manpages.debian.org/bullseye/dhcpcd5/dhcpcd.conf.5.en.html>?

For pasting the manpage extracts? That's simple. In
https://lists.debian.org/debian-user/2022/01/msg01055.html
Gene quoted "the bottom of /etc/dhcpcd.conf" so I needed to
see that file.

$ apt-file find /etc/dhcpcd.conf
dhcpcd5: /etc/dhcpcd.conf
$

Have I got, or ever even seen, package dhcpcd5? Leaving off the
5 in case it's a version number:

$ grep -r dhcpcd /home/debian/packages/ ~/pc/configure/out-of-date/dpkg-l-*
$

No—never installed it, going back as far as hamm. So, off to
https://packages.debian.org/index
to get the link, and wget downloads the package into
/home/debian/bullseye/dhcpcd5_7.1.0-2+b1_amd64.deb
as there's no point in apt-get -d putting it into my cache.
(Besides, I'm here sitting at a buster machine.)

Then mc opens the .deb file as if it were a local directory.
Everything's there: the configuration file itself, and all
the docs, including the manpage(s).

So why use <https://manpages.debian.org/bullseye/dhcpcd5/dhcpcd.conf.5.en.html>?

Cheers,
David.

[Tixy]

On Wed, 2022-01-26 at 19:26 +0000, Brian wrote:
> On Wed 26 Jan 2022 at 10:42:38 -0600, David Wright wrote:
>
> [Snipping]
>
> > I've worked this way for 15 years and, unlike Gene, I'm not having
> > to fight any battles over it. I'm sure mDNS is perfect for people
> > with different demands from mine.
>
> My question was really directed at all users, particularly those who
> do not appreciate the existance or basic function of Avahi.

My experience of it was many years ago when first trying out Linux
seriously and I spotted it amongst the list of services that were
running. After googling the name and realising what it was I hurriedly
uninstalled it, because at that time the zero-conf stuff seemed to be
cropping up regularly in the IT news in a bad way, with malware
exploiting weaknesses in Window and routers implementation of it. I
also have a general aversion to computers tying to doing magic things
behind my back.

I can't see what the problem with DHCP is, if I want to have static IP
addresses or use names to identify machines on the network, I can take
a minute to add a line to dnsmasq.conf on my router. I know some people
say that DHCP is a single point of failure, or they don't want to run
extra hardware 24/7, but I would think most of us already have a router
providing internet access that can do DHCP. And if that fails, have a
spare (even if it's just an old device) that can be pressed into
immediate use. I for one consider internet access sufficiently
important to make fixing it a priority.

--
Tixy

[Dan Ritter]

Tixy wrote:
>
> I can't see what the problem with DHCP is, if I want to have static IP
> addresses or use names to identify machines on the network, I can take
> a minute to add a line to dnsmasq.conf on my router. I know some people
> say that DHCP is a single point of failure, or they don't want to run
> extra hardware 24/7, but I would think most of us already have a router
> providing internet access that can do DHCP. And if that fails, have a
> spare (even if it's just an old device) that can be pressed into
> immediate use. I for one consider internet access sufficiently
> important to make fixing it a priority.

I use ISC dhcpd on two machines at home: my firewall and my
server. The failover system took about twenty minutes of reading
to figure out.

Then the firewall has unbound and the server has bind; unbound
does caching and general name resolution, and looks at bind for
my local names.

This is more complicated than it needs to be but I wanted to
experiment.

-dsr-

[Brian]

On Thu 27 Jan 2022 at 08:21:49 +0000, Tixy wrote:

> On Wed, 2022-01-26 at 19:26 +0000, Brian wrote:
> > On Wed 26 Jan 2022 at 10:42:38 -0600, David Wright wrote:
> >
> > [Snipping]
> >
> > > I've worked this way for 15 years and, unlike Gene, I'm not having
> > > to fight any battles over it. I'm sure mDNS is perfect for people
> > > with different demands from mine.
> >
> > My question was really directed at all users, particularly those who
> > do not appreciate the existance or basic function of Avahi.
>
> My experience of it was many years ago when first trying out Linux
> seriously and I spotted it amongst the list of services that were
> running. After googling the name and realising what it was I hurriedly
> uninstalled it, because at that time the zero-conf stuff seemed to be
> cropping up regularly in the IT news in a bad way, with malware
> exploiting weaknesses in Window and routers implementation of it. I
> also have a general aversion to computers tying to doing magic things
> behind my back.

Three items to take into account:

* Your machine will (AFAIK) only publish services you explicitly
allow. For example, pulseaudio requires the installation of a
specific module and cupsd rquires printer sharing to be explicitly
enabled.

* The services offered by other machines on the network need not be
accessed.

* It is assumed your machine is on a network that is regarded as
trusted. Otherwise, why are you there?

--
Brian.