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)
signature.asc
Description: Digital signature
_______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers