Re: How to avoid systemd/udev unpredictable NIC names
Greg Wooledge <greg@wooledge.org> writes:
> On Tue, Aug 31, 2021 at 12:27:57AM +0300, IL Ka wrote:
> > >
> > > This gives unpredictable results if the system has more than one
> > > ethernet interface, or more than one wireless interface.
> > >
> > > It's fine on systems that have 0-1 ethernet and 0-1 wireless NICs.
> > >
> >
> > Isn't that what the topic starter asked about?:)
>
> I sincerely hope that the OP will tell us how many ethernet interfaces
> their "server" has, so we can stop the hypothetical tennis match.
One interface is on the mainboard (eth0), the other is a PCI card
(eth1). BTW, PCI really, not PCIe other something like that. It's a
really old machine.
> I advocated creating the .link files in my original message. I even
> gave examples.
>
> I do *not* advocate "letting systemd-udevd do its job", because it's
> absolutely unqualified for duty. The names it chooses are *not*
> predictable. The OP knew this. I can tell by their wording.
Actually, I don't know this. When I wrote unpredictable new naming
scheme I meant systemd's enp<pci-bus>s<slot> scheme, since it's
unpredictable for me as long as I don't learn these numbers for my
mainboard and PCI card config.
Why is systemd-udevd unqualified for this jobs? As far as I
understand, systemd implements this new "predictavle" scheme by
calling udevd. No? Well, this is exactly what I dislike with systemd
& co. I've read lots of docs & man pages, still I don't know the
exact process of how the interfaces are renamed after the kernel names
the eth<n>. Does udevd run first, does systemd call udev, does
systemd do the renaming itself or is it done by "net_setup_link udev
builtin" as systemd.link(5) states? And is this udev builtin a part
of udev or part of systemd or part of systemd-udevd? At least there
is no man page for net_setup_link. So the admin has to guess.
This is the same picture with other systemd, udev, avahi, ... stuff.
In newer clients, I don't understand DNS lookup anymore. In
/etc/resolv.conf you cannot find the DNS server used. A rndc reload
on the server is ignored for quite a long time. I recently had that
problem and couldn't figure out how to make the client (Ubuntu 20.04)
get the DNS entry from the server as it was told by DHCP, instead of
its local cache. Even restarting several systemd service on the
client didn't help. Since the man pages are very incomplete I
could only poke in the dark, trial and error until it somehow
magically worked again.
NFS with systemd is a nightmare.
20 years ago until about 10 years ago I knew every single daemon on my
system and I knew exactly what each one did do. Now there are dozens
of daemons, interacing in obscure ways, poorly documented, so I don't
know much of a current system anymore. I consider this a major
security problem since any malicous new daemon would probably go
unrecognized quite a long time.
Steve
Reply to: