All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org>
Cc: containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org,
	Dietmar Maurer <dietmar-YTcQvvOqK21BDgjK7y7TUQ@public.gmane.org>
Subject: Re: lxc configuration help - only network isolated?
Date: Fri, 27 Mar 2009 08:08:59 -0500	[thread overview]
Message-ID: <20090327130859.GA9643@us.ibm.com> (raw)
In-Reply-To: <49CC9262.40302-GANU6spQydw@public.gmane.org>

Quoting Daniel Lezcano (daniel.lezcano-GANU6spQydw@public.gmane.org):
> Chris R. Jones wrote:
> > I have a couple of basic configuration questions on linux containers.  I'm using lxc-0.6.1.
> >
> > I'm trying to configure a setup where I have two containers, where the only virtualized/isolated resources are network resources, but I can still do IPC between processes in the two containers.
> >
> > The lxc.conf man page indicates that, "by default, the pids, sysv ipc, and mount points are virtualized and isolated. "
> >
> > Is there a way in the configuration to specify that those resources should NOT be isolated?  I'd really like to have communication between two processes running in different containers using sysV IPC and signals.  The only thing I really want to be isolated are two different network namespaces.
> >
> > Is there a setting I use in the lxc.conf file to accomplish this?
> >
> >   
> I thought no one would be interested by less isolation :)
> 
> I see you want to share the signals, that means no pid namespace, right ?
> 
> The design of the lxc is build around the pid namespace, if you kill the 
> first process of the pid namespace, you kill all the process of the 
> container. That allows to implement the 'lxc-stop' command.
> 
> So no pid namespace, no container :)

There has been discussion before about having a 'kill' or 'signal'
cgroup, analogous to the freezer, for sending signals to all tasks
in a cgroup.  We could push that, and have lxc-stop optionally use
that.

If there were interest.

> > Up to now, I've been doing some prototyping using lxc-unshare -n, but that doesn't really create a container, correct?  That mostly accomplishes my goals, but I can't find a way to spawn new processes into that same namespace.  Is there a way, without defining a container?
> >   
> 
> No, except writing a forker and launch it inside the container and have 
> a command outside to tell the forker to spawn a specific program. 
> Dietmar Maurer is working on such component to be integrated in lxc.
> > Any recommendations on how to properly configure a containers to allow IPC between processes in two different containers while still isolating the network resources?
> >   
> 
> If you want to share the ipc to do some testing, you can hack the 
> lxc_start function in start.c and remove the ipc cloning flag.
> 
> - clone_flags = CLONE_NEWPID|CLONE_NEWIPC|CLONE_NEWNS;
> +clone_flags = CLONE_NEWPID|CLONE_NEWNS;
> 
> I hope that helps.

I've heard this request in other places, especially about ipc, so maybe
it's a good idea to work such support into the config.  Maybe something
like:

keep_sharing=CLONE_NEWIPC

in lxc.conf, and mask keep_sharing out of clone_flags at lxc_start?

-serge

  parent reply	other threads:[~2009-03-27 13:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-26 22:45 lxc configuration help - only network isolated? Chris R. Jones
     [not found] ` <20090326224541.GA25769-SqNQQPNds68nxqbYAscKCQ@public.gmane.org>
2009-03-27  8:46   ` Daniel Lezcano
     [not found]     ` <49CC9262.40302-GANU6spQydw@public.gmane.org>
2009-03-27 13:08       ` Serge E. Hallyn [this message]
     [not found]         ` <20090327130859.GA9643-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-03-28  3:27           ` Matt Helsley
  -- strict thread matches above, loose matches on Subject: below --
2009-04-08 22:38 Elwin Stelzer Eliazer
     [not found] ` <638f07d70904081538x6a132466xd0607466487e106e-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-04-08 22:44   ` Serge E. Hallyn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090327130859.GA9643@us.ibm.com \
    --to=serue-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
    --cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
    --cc=daniel.lezcano-GANU6spQydw@public.gmane.org \
    --cc=dietmar-YTcQvvOqK21BDgjK7y7TUQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.