Quoting Patrick Toomey (patrick.too...@github.com):
Sounds like a stackable filesystem that remaps file uids would give
you what you need. (I'm not working on one, but several people have
expressed a desire for it)
I'm not sure I would even need something that elaborate. It seems like
On 26.02.2015 20:53, Serge Hallyn wrote:
I've opened https://github.com/lxc/lxc/issues/453 .
I may implement it at some point, but it should be a pretty easy one so
I'm going to see if someone else is interested in doing so.
Serge,
i'm very sorry for my bad English, but i wasn't able work out
Le 26/02/2015 16:41, Jäkel, Guido a écrit :
Dear Anthony, Dear Fajar,
On may unit letters like 'G' while setting the values of the memory cgroup
controller.
But note that memsw stands for the sum of memory and swap. Therefore, can't
set memory.memsw.limit_in_bytes to a value *lower*
Dear Serge,
Might be worth having lxc order the rules so that it'll always just work.
The order of execution needed depends on the actual and desired values
crossover the items.
The setters of the Memory Controller should be act like
Set_MemSwap(Limit) {
Mem :=
? If host uid 10-165536 maps to container uid 0-65536, then host
uid 1000 is not mapped.
Yup, I totally get that now. I was totally misunderstanding how subordinate
IDs worked. Thanks!
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
Dear Anthony, Dear Fajar,
On may unit letters like 'G' while setting the values of the memory cgroup
controller.
But note that memsw stands for the sum of memory and swap. Therefore, can't
set memory.memsw.limit_in_bytes to a value *lower* than the actual value of
Quoting Patrick Toomey (patrick.too...@github.com):
Does that at least explain the technical aspect?
Yeah, that makes total sense. I actually came to the same understanding a
few minutes after I sent my original email. I think drafting the question
ended up forcing my brain to understand
Quoting Patrick Toomey (patrick.too...@github.com):
I was wanting to experiment with the idea of running throw away processes
in a low privilege container. In general, I'd want to run something like
this
lxc-execute -n test1 -f test.conf --lxcpath=/home/my_user/containers
/bin/bash
Quoting Jäkel, Guido (g.jae...@dnb.de):
Dear Anthony, Dear Fajar,
On may unit letters like 'G' while setting the values of the memory cgroup
controller.
But note that memsw stands for the sum of memory and swap. Therefore,
can't set memory.memsw.limit_in_bytes to a value *lower*
Does that at least explain the technical aspect?
Yeah, that makes total sense. I actually came to the same understanding a
few minutes after I sent my original email. I think drafting the question
ended up forcing my brain to understand what was happening :-). Now that I
at least understand what
On Thu, Feb 26, 2015 at 6:51 PM, PONCET Anthony ff...@msn.com wrote:
Hello,
I'm trying to used the memory.memsw.limit_in_bytes, and I have this error
when I trying to set this : lxc-cgroup -n c_name
memory.memsw.limit_in_bytes 2G
The name does say limit_in_bytes, not
It should work with 2G. The rest a bad excuse. It has become a standard in
the software industry.
On Thu, Feb 26, 2015 at 8:49 AM, Fajar A. Nugraha l...@fajar.net wrote:
On Thu, Feb 26, 2015 at 6:51 PM, PONCET Anthony ff...@msn.com wrote:
Hello,
I'm trying to used the
You're apprently right. 2G is not the cause. Rather, it should be this (I
didn't test it):
http://cateee.net/lkddb/web-lkddb/MEMCG_SWAP_ENABLED.html
at least ubuntu's 3.16.0-28-generic has # CONFIG_MEMCG_SWAP_ENABLED is not
set
On Thu, Feb 26, 2015 at 9:19 PM, CDR vene...@gmail.com wrote:
It
If you want the container to have access to your host uid 1000's
files, then add a second mapping,
Yup. this is what I eventually figured out. Is there a way to get
lxc-execute to not exec the passed in executable as uid 0? This is all just
a total proof of concept, but I was aiming to:
* Map
Quoting Patrick Toomey (patrick.too...@github.com):
If you want the container to have access to your host uid 1000's
files, then add a second mapping,
Yup. this is what I eventually figured out. Is there a way to get
lxc-execute to not exec the passed in executable as uid 0? This is all
Hm, yes, because 'lxc-execute' starts the container with lxc-init as
the pid 1, which then executes the program you requested. You could
1. do something like lxc-execute -- sudo --user \#1000 bash
I thought of that, but it seems sudo won't work since sudo/suid root
binaries won't work from
Quoting Patrick Toomey (patrick.too...@github.com):
Hm, yes, because 'lxc-execute' starts the container with lxc-init as
the pid 1, which then executes the program you requested. You could
1. do something like lxc-execute -- sudo --user \#1000 bash
I thought of that, but it seems
Hello,
I'm trying to used the memory.memsw.limit_in_bytes, and I have this
error when I trying to set this : lxc-cgroup -n c_name
memory.memsw.limit_in_bytes 2G
lxc_container: cgmanager.c: do_cgm_set: 1013 Error setting cgroup value
memory.memsw.limit_in_bytes for
Sounds like a stackable filesystem that remaps file uids would give
you what you need. (I'm not working on one, but several people have
expressed a desire for it)
I'm not sure I would even need something that elaborate. It seems like
this is happening mostly because it makes sense for
/ Ubuntu Utopic 14.10 - comes with LXC 1.1 - Doesn't work
/
Where did you find that?
An out-of-the box install using vagrant.
/ Ubuntu Vivid - 15.04 - comes with LXC 1.1 - Works
//
// From information gathered from the Web it seems that the Utopic systemd
/
which web, exactly?
I
Quoting Patrick Toomey (patrick.too...@github.com):
Why is that? Are you bind-mounting /usr or / from the host? Generally
if you've created a full container, the rootfs should be uid-shifted so that
/usr/lib/sudo/sudoers.so should be owned by uid 0 in the container
Yeah, I was using
21 matches
Mail list logo