[systemd-devel] nspawn dependencies

[Richard Weinberger]

Lennart,

Am 11.06.2015 um 12:08 schrieb Lennart Poettering:
> On Thu, 11.06.15 09:40, Richard Weinberger (richard.weinberger at gmail.com) wrote:
> 
>> Hi!
>>
>> Recent systemd-nspawn seems to support unprivileged containers (user
>> namespaces). That's awesome, thank you guys for working on that!
> 
> Well, the name "unprivileged containers" usually is used for the
> concept where you don't need any privs to start and run a
> container. We don't support that, and that's turned off in the kernel
> of Fedora at least, for good reasons.

Depends. Container stuff is that much hyped these days that namings change
all the time. :-)
I understand "unprivileged containers" as containers which do not run as root.
While I don't care whether you have to be root to spawn them.

> We do support user namespaces now, but we require privs on the host to
> set them up. I doubt though that UID namespacing as it is now is
> really that useful though: you have to prep your images first, apply a
> uid shift to all file ownership and ACLs of your tree, and this needs
> to be done manually. This makes it pretty hard to deploy since you
> cannot boot unmodified container images this way you download from the
> internet. Also, since there is no sane, established scheme for
> allocating UID ranges for the containers automatically. So far uid
> namespaces hence appear mostly like an useless excercise, far from
> being deployable in real life hence.

What I care about is that root within the container is not the real root.
Hence, what user namespaces do.

>> Maybe you can help me so sort this out, can I run any systemd enabled
>> distribution
>> using the most current systemd-nspawn?
>> Say, my host is FC22 using systemd-nspawn from git, can it spawn an
>> openSUSE 13.2 container which has only systemd v210?
>>
>> Or has the systemd version on the container side to match the systemd
>> version on the host side?
> 
> It generally does not have to match. We try to maintain compatibility
> there (though we make no guarantees -- the stuff is too new). That
> said, newer systemd versions work much better in nspawn than older
> ones, and v210 is pretty old already.

Okay. Thanks for the clarification.

>From reading the source it seems like you mount the whole cgroup hierarchy into the
container's mount namespace, rebind /sys/fs/cgroup/systemd/yadda/.../yadda/ to /sys/fs/cgroup/systemd
and remount some parts read only.
Does this play well with the cgroup release_agent/notify_on_release mechanism?
Some time ago I've played with that and found that always only systemd on the
host side receives the notify.
Mostly due to the broken design of cgroups. ;-\

One more question, how does systemd-nspawn depend on the host systemd?
On this machine runs openSUSE with systemd v210. I build current systemd-nswpan
and gave it a try wit no luck.

rw at sandpuppy:~/work/systemd (master)> sudo ./systemd-nspawn -bD /fc22
Spawning container fc22 on /fc22.
Press ^] three times within 1s to kill container.
Failed to register machine: Unknown method 'CreateMachineWithNetwork' or interface 'org.freedesktop.machine1.Manager'

I suspect I was too naive to think it would work out. :-)

Thanks,
//richard