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

[Martin Pitt]

Hey Josh,

Josh Triplett [2015-09-10 23:54 -0700]:
>   * Make networkd call if-up.d/ scripts when it brings up interfaces, to
>     become compatible with ifupdown and NetworkManager for packages shipping
>     hooks. (LP: #1492129)
> 
> (Along with various other changes related to these hooks.)
> 
> This is an *extremely* bad idea; please revert it before any package
> incorrectly starts to rely on it.  And this should have been discussed
> on at least pkg-systemd-maintainers, if not systemd-devel, before being
> implemented.

FTR, this was discussed a few months ago with Tom Gundersen (the
author of networkd) at the UOS discussion for this:

  https://blueprints.launchpad.net/ubuntu/+spec/foundations-w-networkd-vs-ifupdown

> Several reasons why this is a bad idea:
> 
> - networkd is intended to bring up interfaces *quickly*, on the order of
>   microseconds (not milliseconds) even with DHCP, let alone without.
>   Spawning arbitrary processes, and especially shell scripts, is not and
>   will never be compatible with networkd's performance requirements.

The hooks are run asynchronously and don't block networkd.

> - These hooks don't exist upstream.  Packages shipping if-up.d hooks are
>   thus still broken anywhere other than Debian, and even *in* Debian
>   they're broken with dynamic network configuration.  Those package need
>   fixing (upstream) to handle dynamic network configuration, and once
>   they do, the Debian-specific hooks become obsolete.  Allowing these
>   hooks makes it less obvious that the packages themselves need fixing.

I do agree that it would be better to fix openssh, postfix, ntpdate,
avahi-autoipd, and the zillion other packages that ship if-up.d hooks
(and other if-*.d/ hooks,  but these are much less important).
However, IMHO this shouldn't be a blocker for adopting networkd -- I'd
like networkd to work in Debian as well as ifupdown and
NetworkManager; providing if* hook and resolvconf integration should
bring it up to par with NetworkManager, and thus I believe people can
now actually use this. Without these, a lot of things would suddenly
not work as expected any more, like openssh not listening to newly
brought up interfaces or postfix not flushing the mail queue when the
system gets online (in a hotplug environment).

> - Network configuration can change at any time, and networkd is not
>   stateful; state lives in the kernel, not in networkd.  These hooks
>   break that assumption.

Can you please explain this? How is this different from ifupdown and NM?

> (This will also likely break with future
>   changes to networkd and other packages integrating with it, as well as
>   with other types of interfaces or virtual networks networkd can
>   configure.)  Among other things, as the systemd-networkd manpage
>   documents, "Network configurations applied before networkd is started
>   are not removed, and static configuration applied by networkd is not
>   removed when networkd exits. Dynamic configuration applied by networkd
>   may also optionally be left in place on shutdown. This ensures
>   restarting networkd does not cut the network connection, and, in
>   particular, that it is safe to transition between the initrd and the
>   real root, and back."

Right, and consequently it won't call if-post-down.d/ when you stop
networkd.

> - Several of the existing if-up.d and if-post-down.d hooks should not
>   run under networkd.  Among others: wpasupplicant's hooks shouldn't run
>   at all under anything but ifupdown

Why not? If it's not meant to run under NM or other mechanisms, it
should check $METHOD. But right now the hook doesn't do anything under
!ifupdown anyway as none of the $WPA_* and $IF_* vars is supplied.

That said, as networkd doesn't have wifi support by itself, it would
certainly be *nice* to make wpa_supplicant work OOTB with networkd :-)

> , mountnfs's hooks shouldn't run (because they conflict with several
> other approaches to nfs handling that integrate properly with
> systemd)

That sounds like a real issue indeed, do you have some details? Again,
how is that not affecting NetworkManager?

> , avahi-daemon's hook is responsible for numerous problems and
> slowdowns even under ifupdown

This just disables avahi if there is a "real" .local domain. This
seems rather independent of the mechanism used to bring up networking?

> and wireless-tools' hook shouldn't run under anything but
>   ifupdown.

Same question/issues as for wpasupplicant?

> - Calling if-up.d and if-post-down.d, but not calling if-down.d or
>   if-pre-up.d, may well break assumptions that a family of scripts in
>   those directories have about when they'll be called and what state
>   machine they'll go through.

NetworkManager has done just that for many years. if-pre-up.d/ is
rather specific to ifupdown indeed (configuring device drivers and
stuff), and if-down.d/ has been a promise which we've never been able
to keep anyway since we have hotplugging and wifi.

(FTR, I consider NM now calling if-pre-up.d/ and down.d/ not an
improvement; but that's another story)

> Packages shipping if-up.d or if-post-down.d scripts are not compatible
> with networkd.  Primarily because they aren't compatible with
> dynamically changing network configurations, and secondarily because
> they tend to do the kind of really silly things that happen with
> arbitrary shell-script hooks available.  This is not the right way to
> fix that problem.

Well, we have two options: Make networkd work with Debian packages
today, or wait an infinite time until all packages listen to dynamic
network changes by themselves. For some this totally should be done
(openssh), for others it's impractical as they don't have a
permanently running daemon.

Declaring "it's not the right way" is a valid option too, but it would
degrade networkd to this "separate thing incompatible with the distro"
again, and thus make it much less useful for users.

> What specific problem is this trying to solve?

See above -- making use of Debian's integration logic for a lot of
packages, to be on par with ifupdown and NetworkManager.

That said: If Michael, or a majority on debian-devel@ or the TC or
whatever disagree with this, I'm okay with dropping this from Debian
again (and just keep it in the Ubuntu package for now). I don't feel
like having a big fight over this. :-)

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150911/5d0892f0/attachment-0002.sig>