Greg Wooledge <g...@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