Lennart, Am 11.06.2015 um 12:08 schrieb Lennart Poettering: > On Thu, 11.06.15 09:40, Richard Weinberger (richard.weinber...@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@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel