[systemd-devel] systemd-nspawn trouble

[Lennart Poettering]

On Sun, 17.05.15 17:30, Michael Biebl (mbiebl at gmail.com) wrote:

> 2015-05-15 22:16 GMT+02:00 Tom Gundersen <teg at 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