On 7/9/24 13:31, Simon McVittie wrote:
I would tend to count "execute arbitrary user-supplied code on
networking changes" as a specialized requirement - by definition,
for this to happen, someone (the sysadmin) needs to have written and
installed the user-supplied hook script. If the sysadmin has made the
decision to do that, then they can equally well make the decision to
install networkd-dispatcher, or ifupdown{,-ng,2} or any other networking
management framework of their choice that supports the feature they need.
Things aren't as easy as you describe. Some packages (like openvswitch)
are currently working out-of-the-box in Debian. I certainly wouldn't
like it to stop working by default. (note: I haven't looked at it yet...
hopefully, it can also work with sd-networkd. but this was just an example)
(Because non-trivial networking is dynamic and can be shared between
multiple components, and in practice this has been the case for years,
I would personally say that if you want arbitrary actions to happen
as a side-effect of networking state changes, a better way to achieve
that is for long-running processes to monitor the network interfaces
via e.g. netlink, and trigger those arbitrary actions whenever there is
a state change, regardless of whether the state change was initiated
by the ifupdown family, NM, networkd, Docker, libvirtd, VPN services, or
something else. But I realise opinions might vary.)
Nice wishful thinking, but that's not the current state of things.
Such a simple thing as sshd isn't even binding properly when the IP of a
server is missing, and in some cases, needs restart (for example if
non-local-ip bind isn't set in sysctl). And there's lower profile
packages we need to address too...
Cheers,
Thomas Goirand (zigo)
