John | 19 Oct 15:29 2012

systemd inside LXC

Hello, I'm in the middle of a migration from init to systemd. I've 
completed the transition of my host environment and my 6 existing 
containers continue to work as expected (they all use sysvinit 
internally). I've started work on a systemd container and am getting 
some odd effects.

First off, if I use systemd-nspawn to start the container, it starts 
fine. I can log in and halt it and all goes as expected. If, however I 
use lxc-start, it clobbers my desktop, which is running in another 
container.

So I have 2 problems: (a) the container does not boot and (b) it manages 
to effect changes in another container.

I've been searching the 'net for most of this morning looking for 
information on using systemd inside a container.

I'm using Arch Linux (3.6.2-1-ARCH) with LXC 0.8.0-rc2. Arch now uses 
systemd by default.

To try to test this, I created a basic container and this exhibits the 
same problems:

$ mkarchroot test base

Starting with systemd-nspawn works fine:
$  systemd-nspawn -D test/ /sbin/init

Starting with LXC does not:
$ lxc-create -n test -f test.conf
(Continue reading)

Serge Hallyn | 19 Oct 17:51 2012

Re: systemd inside LXC

Quoting John (lxc@...):
> Hello, I'm in the middle of a migration from init to systemd. I've 
> completed the transition of my host environment and my 6 existing 
> containers continue to work as expected (they all use sysvinit 
> internally). I've started work on a systemd container and am getting 
> some odd effects.
> 
> First off, if I use systemd-nspawn to start the container, it starts 
> fine. I can log in and halt it and all goes as expected. If, however I 
> use lxc-start, it clobbers my desktop, which is running in another 
> container.
> 
> So I have 2 problems: (a) the container does not boot and (b) it manages 
> to effect changes in another container.
> 
> I've been searching the 'net for most of this morning looking for 
> information on using systemd inside a container.
> 
> I'm using Arch Linux (3.6.2-1-ARCH) with LXC 0.8.0-rc2. Arch now uses 
> systemd by default.
> 
> To try to test this, I created a basic container and this exhibits the 
> same problems:
> 
> $ mkarchroot test base
> 
> Starting with systemd-nspawn works fine:
> $  systemd-nspawn -D test/ /sbin/init
> 
> Starting with LXC does not:
(Continue reading)

Michael H. Warfield | 21 Oct 01:41 2012

Re: systemd inside LXC

Serge,

I'm going to top post here simply because this is going to go off in a
different direction and bringing in an old thread but it is related...

Back on February 14 you responded to a message about Fedora 16 in a
container, which is something I've been trying to do and I had run into
that posters problems.  You responded with this:

Subject: Re: [Lxc-users] fedora 16 under lxc

On Tue, 2012-02-14 at 09:23 -0600, Serge Hallyn wrote:
> Quoting Ramez Hanna (rhanna@...):

> > now all my efforts have not succeedd to get getty on tty1 to start
> > unmasking udev did something different
> > it created all the /dev devices
> > and made getty start but it started on the hosts's tty not on the container's
> > could someone shed some light here?
> 
> Blind guess:
> 
> lxc-start creates some ptys and bind mounts them onto the guest's
> /dev/{console,tty{1,2,3,4}}.  It sounds like fedora's init is mounting
> over the /dev set up by lxc causing a new /dev/tty to be created as
> chardev 4:{1-4}.  Devices namespaces would help this.  We're hoping to
> discuss design for those at next UDS, but those will come after user
> namespaces.  In the mean time, you'll need to make sure that the guest
> does not mount over /dev, and does not remount /dev/pts.
> 
(Continue reading)

Serge Hallyn | 21 Oct 21:49 2012

Re: systemd inside LXC

Quoting Michael H. Warfield (mhw@...):
> Serge,
> 
> I'm going to top post here simply because this is going to go off in a
> different direction and bringing in an old thread but it is related...
> 
> Back on February 14 you responded to a message about Fedora 16 in a
> container, which is something I've been trying to do and I had run into
> that posters problems.  You responded with this:
> 
> Subject: Re: [Lxc-users] fedora 16 under lxc
> 
> On Tue, 2012-02-14 at 09:23 -0600, Serge Hallyn wrote:
> > Quoting Ramez Hanna (rhanna@...):
> 
> > > now all my efforts have not succeedd to get getty on tty1 to start
> > > unmasking udev did something different
> > > it created all the /dev devices
> > > and made getty start but it started on the hosts's tty not on the container's
> > > could someone shed some light here?
> > 
> > Blind guess:
> > 
> > lxc-start creates some ptys and bind mounts them onto the guest's
> > /dev/{console,tty{1,2,3,4}}.  It sounds like fedora's init is mounting
> > over the /dev set up by lxc causing a new /dev/tty to be created as
> > chardev 4:{1-4}.  Devices namespaces would help this.  We're hoping to
> > discuss design for those at next UDS, but those will come after user
> > namespaces.  In the mean time, you'll need to make sure that the guest
> > does not mount over /dev, and does not remount /dev/pts.
(Continue reading)

Michael H. Warfield | 21 Oct 23:27 2012

Re: systemd inside LXC

On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote:
> Quoting Michael H. Warfield (mhw@...):
> > Serge,
> > 
> > I'm going to top post here simply because this is going to go off in a
> > different direction and bringing in an old thread but it is related...
> > 
> > Back on February 14 you responded to a message about Fedora 16 in a
> > container, which is something I've been trying to do and I had run into
> > that posters problems.  You responded with this:
> > 
> > Subject: Re: [Lxc-users] fedora 16 under lxc
> > 
> > On Tue, 2012-02-14 at 09:23 -0600, Serge Hallyn wrote:
> > > Quoting Ramez Hanna (rhanna@...):
> > 
> > > > now all my efforts have not succeedd to get getty on tty1 to start
> > > > unmasking udev did something different
> > > > it created all the /dev devices
> > > > and made getty start but it started on the hosts's tty not on the container's
> > > > could someone shed some light here?
> > > 
> > > Blind guess:
> > > 
> > > lxc-start creates some ptys and bind mounts them onto the guest's
> > > /dev/{console,tty{1,2,3,4}}.  It sounds like fedora's init is mounting
> > > over the /dev set up by lxc causing a new /dev/tty to be created as
> > > chardev 4:{1-4}.  Devices namespaces would help this.  We're hoping to
> > > discuss design for those at next UDS, but those will come after user
> > > namespaces.  In the mean time, you'll need to make sure that the guest
(Continue reading)

Michael H. Warfield | 22 Oct 04:21 2012

Re: systemd inside LXC

On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote:
> Quoting Michael H. Warfield (mhw@...):
> > Serge,
> > 

...

> > Short of building a custom systemd, I don't know how to fix that problem
> > and I suspect this OP is going to run into this same thing (container
> > taking over host's console) and might explain some of what he's seeing.
> > Several of these look like they could cause problems (like /dev/pts in
> > there).  I've really reached an impasse at getting systemd (at least
> > Fedora 16 and 17) to work in a container without screwing up the host.
> > Prohibiting mounts entirely in the container might work but I suspect
> > (having read some systemd error messages) systemd is going to have some
> > serious heartburn there.
> > 
> > Thoughts?
> 
> IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the
> container should work, i.e. systemd was not going to fail as a result.

Hopefully, you've seen the message from Kay Sievers cc'ed to this list
from my post to the systemd-devel list.  Looks like they have a
mechanism in place to do this...

http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface

First step appears to be to set a container=LXC (or some other short
string) before invoking init in the container.  Is there a mechanism to
(Continue reading)

Michael H. Warfield | 22 Oct 05:29 2012

Re: systemd inside LXC

Serge,

On Sun, 2012-10-21 at 22:21 -0400, Michael H. Warfield wrote:
> On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote:
> > Quoting Michael H. Warfield (mhw@...):
> > > Serge,
> > > 
> 
> ...
> 
> > > Short of building a custom systemd, I don't know how to fix that problem
> > > and I suspect this OP is going to run into this same thing (container
> > > taking over host's console) and might explain some of what he's seeing.
> > > Several of these look like they could cause problems (like /dev/pts in
> > > there).  I've really reached an impasse at getting systemd (at least
> > > Fedora 16 and 17) to work in a container without screwing up the host.
> > > Prohibiting mounts entirely in the container might work but I suspect
> > > (having read some systemd error messages) systemd is going to have some
> > > serious heartburn there.
> > > 
> > > Thoughts?
> > 
> > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the
> > container should work, i.e. systemd was not going to fail as a result.

> Hopefully, you've seen the message from Kay Sievers cc'ed to this list
> from my post to the systemd-devel list.  Looks like they have a
> mechanism in place to do this...

> http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface
(Continue reading)

Serge Hallyn | 22 Oct 15:09 2012

Re: systemd inside LXC

Quoting Michael H. Warfield (mhw@...):
> On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote:
> > Quoting Michael H. Warfield (mhw@...):
> > > Serge,
> > > 
> 
> ...
> 
> > > Short of building a custom systemd, I don't know how to fix that problem
> > > and I suspect this OP is going to run into this same thing (container
> > > taking over host's console) and might explain some of what he's seeing.
> > > Several of these look like they could cause problems (like /dev/pts in
> > > there).  I've really reached an impasse at getting systemd (at least
> > > Fedora 16 and 17) to work in a container without screwing up the host.
> > > Prohibiting mounts entirely in the container might work but I suspect
> > > (having read some systemd error messages) systemd is going to have some
> > > serious heartburn there.
> > > 
> > > Thoughts?
> > 
> > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the
> > container should work, i.e. systemd was not going to fail as a result.
> 
> Hopefully, you've seen the message from Kay Sievers cc'ed to this list
> from my post to the systemd-devel list.  Looks like they have a
> mechanism in place to do this...
> 
> http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface

Saw the email, haven't yet read the page, thanks.
(Continue reading)

Serge Hallyn | 22 Oct 16:12 2012

Re: systemd inside LXC

Quoting Serge Hallyn (serge.hallyn@...):
> Quoting Michael H. Warfield (mhw@...):
> > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote:
> > > Quoting Michael H. Warfield (mhw@...):
> > > > Serge,
> > > > 
> > 
> > ...
> > 
> > > > Short of building a custom systemd, I don't know how to fix that problem
> > > > and I suspect this OP is going to run into this same thing (container
> > > > taking over host's console) and might explain some of what he's seeing.
> > > > Several of these look like they could cause problems (like /dev/pts in
> > > > there).  I've really reached an impasse at getting systemd (at least
> > > > Fedora 16 and 17) to work in a container without screwing up the host.
> > > > Prohibiting mounts entirely in the container might work but I suspect
> > > > (having read some systemd error messages) systemd is going to have some
> > > > serious heartburn there.
> > > > 
> > > > Thoughts?
> > > 
> > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the
> > > container should work, i.e. systemd was not going to fail as a result.
> > 
> > Hopefully, you've seen the message from Kay Sievers cc'ed to this list
> > from my post to the systemd-devel list.  Looks like they have a
> > mechanism in place to do this...
> > 
> > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface
> 
(Continue reading)

Michael H. Warfield | 22 Oct 16:37 2012

Re: systemd inside LXC

On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote:
> Quoting Serge Hallyn (serge.hallyn@...):
> > Quoting Michael H. Warfield (mhw@...):
> > > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote:
> > > > Quoting Michael H. Warfield (mhw@...):
> > > > > Serge,
> > > > > 
> > > 
> > > ...
> > > 
> > > > > Short of building a custom systemd, I don't know how to fix that problem
> > > > > and I suspect this OP is going to run into this same thing (container
> > > > > taking over host's console) and might explain some of what he's seeing.
> > > > > Several of these look like they could cause problems (like /dev/pts in
> > > > > there).  I've really reached an impasse at getting systemd (at least
> > > > > Fedora 16 and 17) to work in a container without screwing up the host.
> > > > > Prohibiting mounts entirely in the container might work but I suspect
> > > > > (having read some systemd error messages) systemd is going to have some
> > > > > serious heartburn there.
> > > > > 
> > > > > Thoughts?
> > > > 
> > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the
> > > > container should work, i.e. systemd was not going to fail as a result.
> > > 
> > > Hopefully, you've seen the message from Kay Sievers cc'ed to this list
> > > from my post to the systemd-devel list.  Looks like they have a
> > > mechanism in place to do this...
> > > 
> > > http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface
(Continue reading)

Michael H. Warfield | 22 Oct 22:05 2012

Re: systemd inside LXC

Serge,

On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote:
> Quoting Serge Hallyn (serge.hallyn@...):
> > Quoting Michael H. Warfield (mhw@...):
> > > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote:
> > > > Quoting Michael H. Warfield (mhw@...):
> > > > > Serge,
> > > > > 
> > > 
> > > ...
> > > 
> > > > > Short of building a custom systemd, I don't know how to fix that problem
> > > > > and I suspect this OP is going to run into this same thing (container
> > > > > taking over host's console) and might explain some of what he's seeing.
> > > > > Several of these look like they could cause problems (like /dev/pts in
> > > > > there).  I've really reached an impasse at getting systemd (at least
> > > > > Fedora 16 and 17) to work in a container without screwing up the host.
> > > > > Prohibiting mounts entirely in the container might work but I suspect
> > > > > (having read some systemd error messages) systemd is going to have some
> > > > > serious heartburn there.
> > > > > 
> > > > > Thoughts?
> > > > 
> > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the
> > > > container should work, i.e. systemd was not going to fail as a result.
> > > 
> > > Hopefully, you've seen the message from Kay Sievers cc'ed to this list
> > > from my post to the systemd-devel list.  Looks like they have a
> > > mechanism in place to do this...
(Continue reading)

Serge Hallyn | 22 Oct 22:14 2012

Re: systemd inside LXC

Quoting Michael H. Warfield (mhw@...):
> Serge,
> 
> On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote:
> > Quoting Serge Hallyn (serge.hallyn@...):
> > > Quoting Michael H. Warfield (mhw@...):
> > > > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote:
> > > > > Quoting Michael H. Warfield (mhw@...):
> > > > > > Serge,
> > > > > > 
> > > > 
> > > > ...
> > > > 
> > > > > > Short of building a custom systemd, I don't know how to fix that problem
> > > > > > and I suspect this OP is going to run into this same thing (container
> > > > > > taking over host's console) and might explain some of what he's seeing.
> > > > > > Several of these look like they could cause problems (like /dev/pts in
> > > > > > there).  I've really reached an impasse at getting systemd (at least
> > > > > > Fedora 16 and 17) to work in a container without screwing up the host.
> > > > > > Prohibiting mounts entirely in the container might work but I suspect
> > > > > > (having read some systemd error messages) systemd is going to have some
> > > > > > serious heartburn there.
> > > > > > 
> > > > > > Thoughts?
> > > > > 
> > > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the
> > > > > container should work, i.e. systemd was not going to fail as a result.
> > > > 
> > > > Hopefully, you've seen the message from Kay Sievers cc'ed to this list
> > > > from my post to the systemd-devel list.  Looks like they have a
(Continue reading)

Michael H. Warfield | 22 Oct 22:48 2012

Re: systemd inside LXC

On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote:
> Quoting Michael H. Warfield (mhw@...):
> > Serge,
> > 
> > On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote:
> > > Quoting Serge Hallyn (serge.hallyn@...):
> > > > Quoting Michael H. Warfield (mhw@...):
> > > > > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote:
> > > > > > Quoting Michael H. Warfield (mhw@...):
> > > > > > > Serge,
> > > > > > > 
> > > > > 
> > > > > ...
> > > > > 
> > > > > > > Short of building a custom systemd, I don't know how to fix that problem
> > > > > > > and I suspect this OP is going to run into this same thing (container
> > > > > > > taking over host's console) and might explain some of what he's seeing.
> > > > > > > Several of these look like they could cause problems (like /dev/pts in
> > > > > > > there).  I've really reached an impasse at getting systemd (at least
> > > > > > > Fedora 16 and 17) to work in a container without screwing up the host.
> > > > > > > Prohibiting mounts entirely in the container might work but I suspect
> > > > > > > (having read some systemd error messages) systemd is going to have some
> > > > > > > serious heartburn there.
> > > > > > > 
> > > > > > > Thoughts?
> > > > > > 
> > > > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the
> > > > > > container should work, i.e. systemd was not going to fail as a result.
> > > > > 
> > > > > Hopefully, you've seen the message from Kay Sievers cc'ed to this list
(Continue reading)

Serge Hallyn | 22 Oct 23:21 2012

Re: systemd inside LXC

Quoting Michael H. Warfield (mhw@...):
> On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote:
> > Quoting Michael H. Warfield (mhw@...):
> > > Serge,
> > > 
> > > On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote:
> > > > Quoting Serge Hallyn (serge.hallyn@...):
> > > > > Quoting Michael H. Warfield (mhw@...):
> > > > > > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote:
> > > > > > > Quoting Michael H. Warfield (mhw@...):
> > > > > > > > Serge,
> > > > > > > > 
> > > > > > 
> > > > > > ...
> > > > > > 
> > > > > > > > Short of building a custom systemd, I don't know how to fix that problem
> > > > > > > > and I suspect this OP is going to run into this same thing (container
> > > > > > > > taking over host's console) and might explain some of what he's seeing.
> > > > > > > > Several of these look like they could cause problems (like /dev/pts in
> > > > > > > > there).  I've really reached an impasse at getting systemd (at least
> > > > > > > > Fedora 16 and 17) to work in a container without screwing up the host.
> > > > > > > > Prohibiting mounts entirely in the container might work but I suspect
> > > > > > > > (having read some systemd error messages) systemd is going to have some
> > > > > > > > serious heartburn there.
> > > > > > > > 
> > > > > > > > Thoughts?
> > > > > > > 
> > > > > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the
> > > > > > > container should work, i.e. systemd was not going to fail as a result.
> > > > > > 
(Continue reading)

Michael H. Warfield | 22 Oct 23:36 2012

Re: systemd inside LXC

On Mon, 2012-10-22 at 16:21 -0500, Serge Hallyn wrote:
> Quoting Michael H. Warfield (mhw@...):
> > On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote:
> > > Quoting Michael H. Warfield (mhw@...):
> > > > Serge,
> > > > 
> > > > On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote:
> > > > > Quoting Serge Hallyn (serge.hallyn@...):
> > > > > > Quoting Michael H. Warfield (mhw@...):
> > > > > > > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote:
> > > > > > > > Quoting Michael H. Warfield (mhw@...):
> > > > > > > > > Serge,
> > > > > > > > > 
> > > > > > > 
> > > > > > > ...
> > > > > > > 
> > > > > > > > > Short of building a custom systemd, I don't know how to fix that problem
> > > > > > > > > and I suspect this OP is going to run into this same thing (container
> > > > > > > > > taking over host's console) and might explain some of what he's seeing.
> > > > > > > > > Several of these look like they could cause problems (like /dev/pts in
> > > > > > > > > there).  I've really reached an impasse at getting systemd (at least
> > > > > > > > > Fedora 16 and 17) to work in a container without screwing up the host.
> > > > > > > > > Prohibiting mounts entirely in the container might work but I suspect
> > > > > > > > > (having read some systemd error messages) systemd is going to have some
> > > > > > > > > serious heartburn there.
> > > > > > > > > 
> > > > > > > > > Thoughts?
> > > > > > > > 
> > > > > > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the
> > > > > > > > container should work, i.e. systemd was not going to fail as a result.
(Continue reading)

Serge Hallyn | 22 Oct 23:58 2012

Re: systemd inside LXC

Quoting Michael H. Warfield (mhw@...):
> On Mon, 2012-10-22 at 16:21 -0500, Serge Hallyn wrote:
> > Quoting Michael H. Warfield (mhw@...):
> > > On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote:
> > > > Quoting Michael H. Warfield (mhw@...):
> > > > > Serge,
> > > > > 
> > > > > On Mon, 2012-10-22 at 09:12 -0500, Serge Hallyn wrote:
> > > > > > Quoting Serge Hallyn (serge.hallyn@...):
> > > > > > > Quoting Michael H. Warfield (mhw@...):
> > > > > > > > On Sun, 2012-10-21 at 14:49 -0500, Serge Hallyn wrote:
> > > > > > > > > Quoting Michael H. Warfield (mhw@...):
> > > > > > > > > > Serge,
> > > > > > > > > > 
> > > > > > > > 
> > > > > > > > ...
> > > > > > > > 
> > > > > > > > > > Short of building a custom systemd, I don't know how to fix that problem
> > > > > > > > > > and I suspect this OP is going to run into this same thing (container
> > > > > > > > > > taking over host's console) and might explain some of what he's seeing.
> > > > > > > > > > Several of these look like they could cause problems (like /dev/pts in
> > > > > > > > > > there).  I've really reached an impasse at getting systemd (at least
> > > > > > > > > > Fedora 16 and 17) to work in a container without screwing up the host.
> > > > > > > > > > Prohibiting mounts entirely in the container might work but I suspect
> > > > > > > > > > (having read some systemd error messages) systemd is going to have some
> > > > > > > > > > serious heartburn there.
> > > > > > > > > > 
> > > > > > > > > > Thoughts?
> > > > > > > > > 
> > > > > > > > > IIRC, simply having apparmor(/selinux) refuse the mount of /dev by the
(Continue reading)

Michael H. Warfield | 23 Oct 00:05 2012

Re: systemd inside LXC

On Mon, 2012-10-22 at 16:21 -0500, Serge Hallyn wrote:
> Quoting Michael H. Warfield (mhw@...):
> > On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote:

<Trimming some overhead we've seen enough of...>

> > > How about just a devtmpfs?  We actually now do this by default (as of very
> > > recently) in ubuntu by adding
> > 
> > > devtmpfs        dev          devtmpfs defaults 0 0
> > 
> > NO!  That's the problem!  That leads to the container connecting to the
> > hosts console and other devices and committing random acts of terrorism.

> No, it shouldn't, because lxc sets up the console after doing the mounts.

Damn, dude!  That worked!  That kludge rang da bell.  Of course, I also
discovered the boneheaded typo I had in attempting the tmpfs mount in
the process.  :-P  I now have a container running systemd up and running
with Fedora 17 in it.

I'm not sure I'm totally happy with it.

Because of doing the devtmpfs thing, the guest can immediately see
things like removable drives coming and going and might, presumably, be
able to mount them.  Not thrilled with that from a security standpoint.
Would also mean the guests could access things like my permanent
forensic CDs that are in the CD drives.  I guess that can be restricted
in the config but still makes me a bit uncomfortable that the guest has
complete visibility into the hosts dev system.
(Continue reading)

Michael H. Warfield | 23 Oct 00:08 2012

Re: systemd inside LXC

On Mon, 2012-10-22 at 18:05 -0400, Michael H. Warfield wrote:
> On Mon, 2012-10-22 at 16:21 -0500, Serge Hallyn wrote:
> > Quoting Michael H. Warfield (mhw@...):
> > > On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote:
> 
> <Trimming some overhead we've seen enough of...>
> 
> > > > How about just a devtmpfs?  We actually now do this by default (as of very
> > > > recently) in ubuntu by adding
> > > 
> > > > devtmpfs        dev          devtmpfs defaults 0 0
> > > 
> > > NO!  That's the problem!  That leads to the container connecting to the
> > > hosts console and other devices and committing random acts of terrorism.
> 
> > No, it shouldn't, because lxc sets up the console after doing the mounts.

> Damn, dude!  That worked!  That kludge rang da bell.  Of course, I also
> discovered the boneheaded typo I had in attempting the tmpfs mount in
> the process.  :-P  I now have a container running systemd up and running
> with Fedora 17 in it.

Forgot to include the entry I added to the config file to make it all
workie...

lxc.mount.entry=devtmpfs /srv/lxc/rootfs/dev devtmpfs defaults 0 0

That /srv/lxc/rootfs is my common bind mount for all my containers.

> I'm not sure I'm totally happy with it.
(Continue reading)

Michael H. Warfield | 23 Oct 00:37 2012

Re: systemd inside LXC

On Mon, 2012-10-22 at 18:05 -0400, Michael H. Warfield wrote:
> On Mon, 2012-10-22 at 16:21 -0500, Serge Hallyn wrote:
> > Quoting Michael H. Warfield (mhw@...):
> > > On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote:
> 
> <Trimming some overhead we've seen enough of...>
> 
> > > > How about just a devtmpfs?  We actually now do this by default (as of very
> > > > recently) in ubuntu by adding
> > > 
> > > > devtmpfs        dev          devtmpfs defaults 0 0
> > > 
> > > NO!  That's the problem!  That leads to the container connecting to the
> > > hosts console and other devices and committing random acts of terrorism.

> > No, it shouldn't, because lxc sets up the console after doing the mounts.

> Damn, dude!  That worked!  That kludge rang da bell.  Of course, I also
> discovered the boneheaded typo I had in attempting the tmpfs mount in
> the process.  :-P  I now have a container running systemd up and running
> with Fedora 17 in it.

> I'm not sure I'm totally happy with it.

> Because of doing the devtmpfs thing, the guest can immediately see
> things like removable drives coming and going and might, presumably, be
> able to mount them.  Not thrilled with that from a security standpoint.
> Would also mean the guests could access things like my permanent
> forensic CDs that are in the CD drives.  I guess that can be restricted
> in the config but still makes me a bit uncomfortable that the guest has
(Continue reading)

Michael H. Warfield | 23 Oct 00:55 2012

Re: systemd inside LXC

On Mon, 2012-10-22 at 18:37 -0400, Michael H. Warfield wrote:
> On Mon, 2012-10-22 at 18:05 -0400, Michael H. Warfield wrote:
> > On Mon, 2012-10-22 at 16:21 -0500, Serge Hallyn wrote:
> > > Quoting Michael H. Warfield (mhw@...):
> > > > On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote:
> > 
> > <Trimming some overhead we've seen enough of...>
> > 
> > > > > How about just a devtmpfs?  We actually now do this by default (as of very
> > > > > recently) in ubuntu by adding
> > > > 
> > > > > devtmpfs        dev          devtmpfs defaults 0 0
> > > > 
> > > > NO!  That's the problem!  That leads to the container connecting to the
> > > > hosts console and other devices and committing random acts of terrorism.
> 
> > > No, it shouldn't, because lxc sets up the console after doing the mounts.
> 
> > Damn, dude!  That worked!  That kludge rang da bell.  Of course, I also
> > discovered the boneheaded typo I had in attempting the tmpfs mount in
> > the process.  :-P  I now have a container running systemd up and running
> > with Fedora 17 in it.
> 
> > I'm not sure I'm totally happy with it.
> 
> > Because of doing the devtmpfs thing, the guest can immediately see
> > things like removable drives coming and going and might, presumably, be
> > able to mount them.  Not thrilled with that from a security standpoint.
> > Would also mean the guests could access things like my permanent
> > forensic CDs that are in the CD drives.  I guess that can be restricted
(Continue reading)

St├ęphane Graber | 23 Oct 17:22 2012

Re: systemd inside LXC

On 10/23/2012 12:05 AM, Michael H. Warfield wrote:
> On Mon, 2012-10-22 at 16:21 -0500, Serge Hallyn wrote:
>> Quoting Michael H. Warfield (mhw@...):
>>> On Mon, 2012-10-22 at 15:14 -0500, Serge Hallyn wrote:
> 
> <Trimming some overhead we've seen enough of...>
> 
>>>> How about just a devtmpfs?  We actually now do this by default (as of very
>>>> recently) in ubuntu by adding
>>>
>>>> devtmpfs        dev          devtmpfs defaults 0 0
>>>
>>> NO!  That's the problem!  That leads to the container connecting to the
>>> hosts console and other devices and committing random acts of terrorism.
> 
>> No, it shouldn't, because lxc sets up the console after doing the mounts.
> 
> Damn, dude!  That worked!  That kludge rang da bell.  Of course, I also
> discovered the boneheaded typo I had in attempting the tmpfs mount in
> the process.  :-P  I now have a container running systemd up and running
> with Fedora 17 in it.
> 
> I'm not sure I'm totally happy with it.
> 
> Because of doing the devtmpfs thing, the guest can immediately see
> things like removable drives coming and going and might, presumably, be
> able to mount them.  Not thrilled with that from a security standpoint.
> Would also mean the guests could access things like my permanent
> forensic CDs that are in the CD drives.  I guess that can be restricted
> in the config but still makes me a bit uncomfortable that the guest has
(Continue reading)

John | 21 Oct 20:56 2012

Re: systemd inside LXC

On 19/10/12 16:51, Serge Hallyn wrote:
>
> Add:
>
> lxc.network.type = empty
>
> If you don't have any lxc.network.type sections, then the container
> shares network with the host, and so the container talks to the host's
> systemd.  (same with upstart)
>
>
Thanks for the reply, I will try that tomorrow. I am sorry I wasn't 
around to check for replies before now. One question though... I 
actually want a separate network in the container (hence using veth) so 
it has its own address distinct from the host. Are you saying that I 
can't do this any more?

I've also read the later replies and they seem to be saying that this 
simply does not work (systemd inside a container). Given its 
proliferation into other distros (I'm on Arch and that's the reason I am 
looking at this now), where does systemd come in the priorities of LXC?

I really hope we can get this working, as LXC has so far worked very 
well for me.

Thanks,
John

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
(Continue reading)

Serge Hallyn | 21 Oct 22:00 2012

Re: systemd inside LXC

Quoting John (lxc@...):
> On 19/10/12 16:51, Serge Hallyn wrote:
> >
> > Add:
> >
> > lxc.network.type = empty
> >
> > If you don't have any lxc.network.type sections, then the container
> > shares network with the host, and so the container talks to the host's
> > systemd.  (same with upstart)
> >
> >
> Thanks for the reply, I will try that tomorrow. I am sorry I wasn't 
> around to check for replies before now. One question though... I 
> actually want a separate network in the container (hence using veth) so 
> it has its own address distinct from the host. Are you saying that I 
> can't do this any more?

Not at all.  But if you're saying you have a 'lxc.network.type = veth'
in your container config, then what I said doesn't apply anyway.  It
sounds like the remount of /dev which Micheal mentioned is in fact your
real problem!

> I've also read the later replies and they seem to be saying that this 
> simply does not work (systemd inside a container). Given its 
> proliferation into other distros (I'm on Arch and that's the reason I am 
> looking at this now), where does systemd come in the priorities of LXC?

Where does LXC come in the priorities of systemd?  :)

(Continue reading)


Gmane