Bug#806949: ifupdown: some tweaks to networking.service

[Martin Pitt]

Hey Guus,

thanks for the quick answer! Nice to see that ifupdown is not
abandoned any more, great work!

Guus Sliepen [2015-12-03 13:44 +0100]:
> >  - Add After=local-fs.target. Depending on a read-only root partition
> >    might not be enough, as there might be actions in /e/n/i which
> >    require a writable root, or other mounted partitions. The current
> >    sysvinit file has "Required-Start: $local_fs" and we should
> >    probably keep that until we are really sure that we can drop it.
> 
> ifupdown itself only writes to /run/network, but indeed any plugins
> might require a writable root.

You are the expert there, so if that's the only assumption that hook
code can make, it's fine to drop. I added local-fs.target to do what
the init.d script does, so it's not a regression in terms of
dependencies.  I don't know which assumptions plugins or if-up.d/
scripts can make about the system, so it might be that this can be
relaxed to just "root fs is writable" or even drop it completely. But
then again, local-fs.target doesn't appear to be an unreasonable
assumption.

> >  - Add After=apparmor.service. Apparmor needs to run very early as it
> >    commonly installs profiles for network-facing software like
> >    dhcp-client. Note that this is a no-op when apparmor isn't being
> >    used, as there is no Wants= (i. e. just ordering, no dependency).
> 
> No problem. Are there other such services that might require loading
> before ifupdown? SELinux?

systemd has native support for loading SELinux profiles, so that
shouldn't be required. At some point it should learn how to natively
load AppArmor profiles during early boot too (the Ubuntu security team
is working on that), but until then we need to rely on the external
apparmor.service.

I'm not aware of other MAC systems that need this.

> >    ExecStartPre=-/bin/sh -c '[ -n "$(ifquery --list --exclude=lo)" ] && udevadm settle'
> 
> Ok, in that case it might be nice to add --read-environment to ifquery
> as well, so EXCLUDE_INTERFACES will be read. Something like this?
> 
> ExecStartPre=-/bin/sh -c '[ "$CONFIGURE_INTERFACES" != no ] && [ -n "$(ifquery --list --read-environment --exclude=lo)" ] && udevadm settle'

Sure!

> >    In the medium term I'd be interested in cleaning this up, though.
> >    IMHO there needs to be a proper ifupdown-wait-online.service which
> >    just starts the virtual interfaces, let all the real ones be
> >    handleld by udev hotplug rules, and just waits until all "auto"
> >    services are up. This avoids the race condition and unnecessary
> >    blocking on udev settle. But this should be discussed in a separate
> >    bug, and I'll also send one for moving the "allow-hotplug" handling
> >    bits into ifupdown (where they fit much better than in the udev
> >    package).
> 
> Yes. The only problem though is that it requires the admin to correctly
> specify which interfaces are "auto" and which are "hotplug", because
> ifupdown cannot really figure that out itself. And there might be some
> cases where a virtual interface depends on one or more hotpluggable
> ones.

A statically configured "auto" bridge depending on allow-hotplug
interfaces sounds weird to me -- what should the semantics of that be?
But indeed the syntax allows doing that. What does ifup -a do if it
encounters this and one of the dependent devices does not exist? I
figure it just writes an error, but there's nothing to re-attempt
stating the composite device once one of its dependencies comes up?

Other things like networkd or NM have an internal understanding of
this hierarchy, but this is harder to do with ifupdown indeed. So for
now, the conditional udevsettle if there are configured interfaces
seems ok.

Just for the record, Ubuntu has a fairly different approach there: It
never supported "allow-hotplug" really, udev rules dynamically bring
up both "auto" and "allow-hotplug" devices, and there is an
implementation of "ifup-wait-all-auto.service" similar to
systemd-networkd-wait-all-auto.service that waits for all "auto"
interfaces in /e/n/i to be up for up to 2 minutes, and then continues
the boot. I don't know the exact reasoning why this was done back then
(this dates back to the upstart work from Scott and Stèphane), but
apparently it was found to be a more robust approach.

I'm not saying that this is necessarily better, just wanted to mention
it that it exists.

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/20151203/30b8f028/attachment-0002.sig>