[systemd-devel] systemd-nspawn trouble

[Lennart Poettering]

On Wed, 22.04.15 15:43, Michael Biebl (mbiebl at gmail.com) wrote:

> 2015-04-22 15:25 GMT+02:00 Lennart Poettering <lennart at poettering.net>:
> > On Wed, 22.04.15 14:36, Michael Biebl (mbiebl at gmail.com) wrote:
> >
> >> >> >> Not everyone is using networkd or nspawn though, so loading this
> >> >> >> module for everyone is a bit excessive.
> >> >> >
> >> >> > Well, then blacklist the module or don't build it at all.
> >> >>
> >> >> That's the wrong way around.
> >> >
> >> > Nah, I disagree. We do this for a number of modules now. I mean, we
> >>
> >> We currently do this static loading for unix, ipv6 and autofs4.
> >>
> >> > load tons of modules automatically, even if you don't use them. For
> >> > example, my laptop always loads the bluetooth modules, even though I
> >> > never used bluetooth.
> >>
> >> Those are all loaded on demand, not statically. I.e. we don't load the
> >> bluetooth module for each and every user.
> >
> > No, things like bluetooth are not loaded on demand, but already when
> > you just have the hw for it.  That's quite a difference.
> >
> 
> Loading the bluetooth module when you have the hardware is something
> different then loading it unconditionally for everyone.
> You are doing the latter with iptables.

I don#t see how this really was any different. I am sure a lot of
people never want to use bluetooth, and I am also sure that a lot of
people don#t want to use iptables (and of both of these, bluetooth is
certainly the more exotic one, even). In both cases we autoload them
now, with an easy way out, via blacklisting.

> And why does this have to be hard-coded in the source instead of
> shipping a /etc/modules-load.d snippet where it would be easily
> discoverable?

Because we generally try to make the system just work, without
configuration. 

There's also another backstory: hopefully we can merge Daniel's
patches soon that add minimal per-service Firewalling to PID 1. In
that case it's not only networkd+nspawn that needs this, but PID 1
too, which makes the modules-load.d path unworkable.

Lennart

-- 
Lennart Poettering, Red Hat