Bug#798625: systemd-networkd: Runs arbitrary inappropriate scripts on network changes

[Josh Triplett]

On Mon, Sep 28, 2015 at 11:22:48PM +0200, Martin Pitt wrote:
> Josh Triplett [2015-09-20 13:37 -0700]:
> > > The missing hook/extension mechanism in networkd is something which is
> > > an issue.
> > 
> > I wouldn't necessarily put it *that* way.  The functionality currently
> > handled by ifupdown hooks needs handling in some way; that doesn't mean
> > networkd needs to run arbitrary hooks.  That needs some very careful
> > thought before creating what amounts to a new API expectation.
> 
> The alternative is to teach all the affected software to listen to
> networkd events, which seems much more intrusive?

No, I don't think the majority of software necessarily needs to listen
directly to networkd events.  In some cases, networkd might provide a
more convenient approach than implementing a check in-process (for
instance, by adding captive portal detection or automatic proxy
handling), but services could also just watch for connectivity (or
whatever they actually need).  But most network-facing daemons should
use native kernel network mechanisms instead.

That said, software that manages network interfaces, such as VPNs or
other network management mechanisms, will probably end up with networkd
integration, yes.  networkd will probably end up with an interface that
lets separate software set up and hand off interfaces like VPNs or wifi,
which will address many things.  And I think that makes more sense than
trying to use a completely generic hook mechanism to integrate things
like openvpn, openconnect, or wpa_supplicant.

> I don't think that
> most sofware will want to do this, but at the same time networkd
> upstream seems to be against adding a hooks mechanism. TBH, I don't
> want to invent a completely new downstream-only hooks mechanism;
> if-*.d/ has been around for a long time, but if we don't want to use
> that, I'd just declare bancrupcy from my POV and say "if you use any
> of this software, then you can't use networkd".

Not quite that; rather, "if you use any of this software, networkd won't
integrate with it".  You could, for instance, manually bring a VPN up or
down and networkd won't mess with it.

This doesn't seem drastically different than NetworkManager, for
instance.  Once upon a time, NM didn't support VPNs.  Or running a
hotspot via dnsmasq.  I still don't quite understand how NM supports
bridges.  And yet people often run it for common cases.  I'd expect a
fair many wired server systems to try networkd; once it gains wifi
support and GNOME/KDE integrate support for it, many people will try it
there as well; ditto for VPN support.  Gradual adoption seems fine here;
people have complained in the past about rapid uptake of systemd
technologies. :)

> > > If we are going to provide a hook mechanism, maybe defining our own is
> > > better then an incomplete/incompatbile ifup.d hooks support.
> > 
> > At the very least, any such mechanism should go through systemd unit
> > files.  That would have several advantages: for instance, units that
> > want to run both periodically and "when the network comes up" can DTRT
> > (see .timer units with OnCalendar and Persistent, or with
> > OnUnitInactiveSec; policies like "once a day but only with the network
> > up" don't seem far-fetched here).  That would also provide the full
> > functionality from "man systemd.exec".
> 
> This is indeed quite obvious, and was discussed with Tom back then.
> But right now there are no plans for integrating networkd with systemd
> units. The only interface that one has are the D-Bus notifications.

*nod*.  But, for instance, if running a VPN involves a separate daemon,
I'd expect to run that via a systemd unit.

> > Done; I've gone throuh the entire set of extracted hooks and documented
> > them all in the titanpad.
> 
> Awesome, thanks for that!

:)

> > And if, in the short term, some users say "I can't migrate to networkd
> > yet, it doesn't support $foo", that seems fine; we certainly don't plan
> > to eliminate all other network configuration systems from Debian, and
> > eventually someone might decide to add support to networkd.
> 
> We seem to be at an impasse here, with a "damned if you do, damned if
> you don't" situation wrt. running if-*.d/ hooks. From the 50 hooks, 24
> are relevant for netword, 26 aren't. A third of them can be fixed with
> IP_FREEBIND, the others would need to grow custom support for
> networkd, or a networkd specific plugin mechanism.

With only 24 hooks relevant for networkd, I'd suggest that (after the
requisite discussion) we file bugs against those packages with a
usertag, with a bit of analysis (and an "upstream" tag), and start
working towards fixing them.  24 seems quite manageable.

Should we set up a titanpad to prepare the template for such bugs?  That
template should include some guidance for common cases (such as
IP_FREEBIND), along with a suggestion for where to discuss or ask for
implementation help.  And then each bug should include some analysis of
the script, and in some cases an explicit note saying that a short-term
fix is not expected.  And for cases like VPN, we should mark them as
blocked on a bug against systemd-networkd about having a VPN interface.

> I'm ok with reverting the hook support then, and adjust README.Debian
> with a big warning about the lack of if*.d/ hook integration instead.

Thank you very much.

- Josh Triplett