Re: systemd effectively mandatory now due to GNOME
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
Reply to: