On Tue, Oct 29, 2013 at 08:47:00PM +0000, Ben Hutchings wrote: > On Tue, Oct 29, 2013 at 12:15:10PM -0700, Steve Langasek wrote: > > On Thu, Oct 24, 2013 at 10:29:10PM +0200, Zbigniew Jędrzejewski-Szmek wrote: > > > On Thu, Oct 24, 2013 at 12:13:34PM -0700, Steve Langasek wrote: > > > > And this is not just an issue because of people not wanting to use > > > > systemd > > > > init, but also because systemd init *can't* run in a container. > > > Whoah, that's not true: > > > > > sudo systemd-nspawn -bD ~/images/fedora-19 > > > > > works just fine :) > > > > My understanding, which may be based on dated information, is that > > systemd-nspawn doesn't fully contain the system in the way most others (e.g. > > users of lxc) talk about when they speak of containers: MAC, cgroups support > > inside the container, and possibly other things. > > Indeed; Lennert has described it as an enhanced chroot rather than a > container. The new process is in the same user namespace and inherits > most capabilities. It can optionally run in a new network namespace. Sure, *systemd-nspawn* doesn't create a secure container, but I'm not sure if that matters here. *systemd* itself will detect that it is running in a container, and disable various stuff, e.g. udev. People run systemd inside containers all the time, and being able to run the same system image inside of a container and on the host is one of the design goals.
> > If you use lxc-start instead of systemd-nspawn, does your Fedora image work? > > Last I knew, the answer was "no". It also works with lxc, if some settings are set, e.g. lxc.cap.drop = mknod, etc. Missing that, systemd configuration can be adapted inside the container. Zbyszek -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131030115050.gp28...@in.waw.pl
