[Devel] vzmigrate for PermitRootLogin=no
i wasn't willing to enable PermitRootLogin, so i added a sudo feature to my copy of vzmigrate, to gain root on the target server via sudo. is this of any interest to others? ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/3] cgroup : add clone_children control file
On 09/07/2010 11:22 PM, Paul Menage wrote: > On Tue, Sep 7, 2010 at 2:13 PM, Daniel Lezcano wrote: > >> The clone_children option behaves like the release-agent mount option no ? >> > Not quite, since it can be controlled on a per-cgroup basis. > > >> We can mount with a specific release agent and change it at runtime. IMHO it >> would be better to give a chance to the administrator to set its system with >> the mount option instead of force him to write post mount scripts. An >> alternative would be to set this cgroup option *only* via the mount option, >> but I am not sure it is good as it may be an unresolvable constraint for a >> system wanting to use the cgroups with and without this option (same kind of >> constraint we have with the ns_cgroup). >> >> I am favorable to keep the mount option and the ability to change it for >> another cgroup. >> > OK, lets mostly keep the current patch, but lose the flag stored at > mount-time and just report the mount option based on the current value > of the root cgroup's flag. > Ok, will resend a new version. Thanks for reviewing the patchset. -- Daniel ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/3] cgroup : add clone_children control file
On Tue, Sep 7, 2010 at 2:13 PM, Daniel Lezcano wrote: > > The clone_children option behaves like the release-agent mount option no ? Not quite, since it can be controlled on a per-cgroup basis. > We can mount with a specific release agent and change it at runtime. IMHO it > would be better to give a chance to the administrator to set its system with > the mount option instead of force him to write post mount scripts. An > alternative would be to set this cgroup option *only* via the mount option, > but I am not sure it is good as it may be an unresolvable constraint for a > system wanting to use the cgroups with and without this option (same kind of > constraint we have with the ns_cgroup). > > I am favorable to keep the mount option and the ability to change it for > another cgroup. OK, lets mostly keep the current patch, but lose the flag stored at mount-time and just report the mount option based on the current value of the root cgroup's flag. Paul ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/3] cgroup : add clone_children control file
On 09/07/2010 10:26 PM, Paul Menage wrote: > On Tue, Sep 7, 2010 at 1:23 PM, Daniel Lezcano wrote: > >>> This bit is awkward - you're storing the original value of the >>> clone_children flag to report in the mount options, but this isn't >>> necessarily the current state. Might it be better to not store this >>> and just report the current value of the root cgroup's >>> CGRP_CLONE_CHILDREN flag? >>> >>> >> Sure. Shall I do the same as the release agent mount option ? >> > I think so - the slight problem with this new flag is that it's > possible for the root cgroup to have one setting for clone_children > and all its children to have a different setting. But I guess we can > live with that. (Or maybe simply not make the default clone_children > value a mount option, but require it to be set on the root cgroup > after mounting?) > The clone_children option behaves like the release-agent mount option no ? We can mount with a specific release agent and change it at runtime. IMHO it would be better to give a chance to the administrator to set its system with the mount option instead of force him to write post mount scripts. An alternative would be to set this cgroup option *only* via the mount option, but I am not sure it is good as it may be an unresolvable constraint for a system wanting to use the cgroups with and without this option (same kind of constraint we have with the ns_cgroup). I am favorable to keep the mount option and the ability to change it for another cgroup. -- Daniel ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/3] cgroup : add clone_children control file
On Tue, Sep 7, 2010 at 1:23 PM, Daniel Lezcano wrote: >> This bit is awkward - you're storing the original value of the >> clone_children flag to report in the mount options, but this isn't >> necessarily the current state. Might it be better to not store this >> and just report the current value of the root cgroup's >> CGRP_CLONE_CHILDREN flag? >> > > Sure. Shall I do the same as the release agent mount option ? I think so - the slight problem with this new flag is that it's possible for the root cgroup to have one setting for clone_children and all its children to have a different setting. But I guess we can live with that. (Or maybe simply not make the default clone_children value a mount option, but require it to be set on the root cgroup after mounting?) Paul ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 2/3] cgroup : make the mount options parsing more accurate
On 09/07/2010 09:38 PM, Paul Menage wrote: > On Sat, Sep 4, 2010 at 12:31 AM, Daniel Lezcano > wrote: > >> The actual code does not detect 'all' with one subsystem name, which >> is IMHO mutually exclusive and when an option is specified even if it >> is not a subsystem name, we have to specify the 'all' option with the >> other option. >> eg: >> not detected : mount -t cgroup -o all,freezer cgroup /cgroup >> not flexible : mount -t cgroup -o noprefix,all cgroup /cgroup >> >> This patch fix this and makes the code a bit more clear by replacing >> 'else if' indentation by 'continue' blocks in the loop. >> > Can you fix this description to be clearer about the new behaviour of the > code? > > Reviewed-by: Paul Menage > Sure no problem. Thanks for the review. -- Daniel ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/3] cgroup : add clone_children control file
On 09/07/2010 09:34 PM, Paul Menage wrote:
> On Sat, Sep 4, 2010 at 12:31 AM, Daniel Lezcano
> wrote:
>
>> @@ -229,6 +229,7 @@ inline int cgroup_is_removed(const struct cgroup *cgrp)
>> /* bits in struct cgroupfs_root flags field */
>> enum {
>> ROOT_NOPREFIX, /* mounted subsystems have no named prefix */
>> + ROOT_CLONE_CHILDREN, /* mounted subsystems will inherit from parent
>> */
>> };
>>
> This bit is awkward - you're storing the original value of the
> clone_children flag to report in the mount options, but this isn't
> necessarily the current state. Might it be better to not store this
> and just report the current value of the root cgroup's
> CGRP_CLONE_CHILDREN flag?
>
Sure. Shall I do the same as the release agent mount option ?
Thanks
-- Daniel
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
[Devel] C/R and stdio redirection
Suppose we create a container and redirect its stdout/stderr as follows: lxc-execute -name foo -- /path/to/app > /tmp/xyz.out 2>&1 If we attempt to checkpoint the container 'foo', we fail bc one of the fds in the application refers to /tmp/xyz.out, which is also in use outside the container (specifically sys_checkpoint() fails due to the "alien mount ns" check in ckpt_fill_fname()). It can be argued, 'foo' is not a strict container (since it shares the fd with another container). For this reason, we currently need the CHECKPOINT_SUBTREE flag in lxc-checkpoint. We initially thought that solving mount-namespaces will solve this, but realized that they are both separate problems. Mount-namespace C/R addresses preserving the mounts within the container and /tmp/xyz.out is outside the container. So if an application container needs to redirect stdio as above, we should either a) disable/ignore the alien-mount-ns check or b) try and start the application something like: $ cat /tmp/wrapper /path/to/app > /tmp/xyz.out 2>&1 $ lxc-execute --name foo -- /tmp/wrapper with the difference being /tmp/xyz.out is now inside the container's /tmp filesystem rather than in the parent container. Maybe we can go with approach 'a' above only if CHECKPOINT_SUBTREE is also set - we had discussed this before and considered it hacky. Or are there other solutions to this stdio redirection issue ? Thanks, Sukadev ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 2/3] cgroup : make the mount options parsing more accurate
On Sat, Sep 4, 2010 at 12:31 AM, Daniel Lezcano wrote: > The actual code does not detect 'all' with one subsystem name, which > is IMHO mutually exclusive and when an option is specified even if it > is not a subsystem name, we have to specify the 'all' option with the > other option. > eg: > not detected : mount -t cgroup -o all,freezer cgroup /cgroup > not flexible : mount -t cgroup -o noprefix,all cgroup /cgroup > > This patch fix this and makes the code a bit more clear by replacing > 'else if' indentation by 'continue' blocks in the loop. Can you fix this description to be clearer about the new behaviour of the code? Reviewed-by: Paul Menage ___ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers ___ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
[Devel] Re: [PATCH 1/3] cgroup : add clone_children control file
On Sat, Sep 4, 2010 at 12:31 AM, Daniel Lezcano wrote:
> @@ -229,6 +229,7 @@ inline int cgroup_is_removed(const struct cgroup *cgrp)
> /* bits in struct cgroupfs_root flags field */
> enum {
> ROOT_NOPREFIX, /* mounted subsystems have no named prefix */
> + ROOT_CLONE_CHILDREN, /* mounted subsystems will inherit from parent */
> };
This bit is awkward - you're storing the original value of the
clone_children flag to report in the mount options, but this isn't
necessarily the current state. Might it be better to not store this
and just report the current value of the root cgroup's
CGRP_CLONE_CHILDREN flag?
Paul
___
Containers mailing list
contain...@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
