Re: [systemd-devel] nspawn dependencies
On Thu, 11.06.15 12:48, Richard Weinberger (rich...@nod.at) wrote: > >> 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? No, cgroup notification is fucked in containers, and even on the host it is broken, but not as badly. The new unified hierarchy handles all this *much* much better, as it has a inotify based notification scheme that covers hierchies really nicely. Note that more recent systemd versions can handle non-working cgroup notifications in containers much better than older ones. > 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. v210 is really old. We don't support "half" upgrades. If you do "half" upgrades, where the utilites do not match the daemons then your are on your own. That said, rkt actually uses nspawn and supports that on their own downstream on all distros, even old ones that do not have systemd at all. But that's on them, we don't want to be bothered with that upstream. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nspawn dependencies
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
Re: [systemd-devel] nspawn dependencies
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. 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. > 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. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] nspawn dependencies
Hi! Recent systemd-nspawn seems to support unprivileged containers (user namespaces). That's awesome, thank you guys for working on that! 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? -- Thanks, //richard ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
