On Sun, 17.05.15 17:30, Michael Biebl (mbi...@gmail.com) wrote: > 2015-05-15 22:16 GMT+02:00 Tom Gundersen <t...@jklm.no>: > > on-demand I agree with Lennart that it makes the most sense to simply > > unconditionally load the modules. If this is undesirable the solution > > should be to teach the kernel to auto-load the modules, not to expect > > the admin to figure out that explicit loading is required, IMHO. > > And now we expect that the admin figures out how to disable loading of > the iptables module, which isn't anymore obvious.
Why would he do that? I generally think we should make things easy if we can, and hence work out of the box. But avoid the iptables module to be loaded is certainly not "making things work", it's the opposite, it is avoiding to make things work. Hence, it's much less interesting to me. > What I was suggesting was, that the iptables modules should only be > loaded on demand, i.e. when the firewalling functionality is actually > used. Lennart did argue, that he didn't want to do that within > networkd, since he didn't want to grant networkd that capability to > load modules and therefor to load the module unconditionally in PID 1. > But moving the modules loading out of networkd doesn't mean, it has to > be done unconditonally, see how we did it for > udev/kmod-static-nodes.service Note that effectively we just changed auto-loading of the iptables module from opt-in to opt-out, to make it behave more like most other modules. Previously it was never auto-loaded. Now it is by default loaded at boot, but you can still blacklist it with modprobe.conf files. This hence ensures behaviour is identical to modules that are auto-loaded via udev or via opening of a device node: for all kinds of modules the blacklist is now where you can turn off or on the module. That's certainly the friendliest way for admins to handle this... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
