On Tue, 09 Jul 2024 at 12:27:58 +0200, Bjørn Mork wrote:
> Matthias Urlichs <matth...@urlichs.de> writes:
> > Somebody could even write a converter. Shouldn't be that difficult,
> > AFAIK there's nothing ifupdown can do that systemd[-networkd] can't.
> 
> Run user scripts on up/down events.  That's a huge blank spot in
> systemd-networkd.  And by design, so it's really not fixable.

If we were considering a migration from ifupdown to sd-networkd on
existing installations, then that would indeed be a reason not to do it
(without someone writing suitable mitigations, for example having the
converter pull in networkd-dispatcher if that's necessary and sufficient
in most cases).

I don't think this is a reason to avoid changing the default for new
installations, though. The purpose of a default is to have something that
does the right thing, reliably, for users who do not have specialized
requirements and do not necessarily know the necessary information to
make decisions like "which network management framework do I want?" yet.

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.

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

    smcv

Reply via email to