[lxc-devel] lxc-clone outputs some logs
Hi, After applying commit edf7734 overlay and aufs clone_paths: be more robust, clone was completed successfully but lxc-clone on unpriv env is now output the following log: $ lxc-clone -o ct02 -n test -s -B overlayfs lxc_container: conf.c: chown_mapped_root: 3649 Error stat /home/karma/.local/share/lxc/test/delta0 Created container test as snapshot of ct02 lxc_container: lxccontainer.c: copy_file: 2303 copy destination /home/karma/.local/share/lxc/test/lxc_rdepends exists Created container test as snapshot of ct02 Clone was completed successfully. (on Plamo Linux 5.2, Kernel 3.14.4) The above was just a quick report. Thanks, KATOH Yasufumi ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] lxc-clone outputs some logs
On Thu, 30 Oct 2014 18:34:39 +0900 in message [lxc-devel] lxc-clone outputs some logs KATOH Yasufumi-san wrote: Hi, After applying commit edf7734 overlay and aufs clone_paths: be more robust, clone was completed successfully but lxc-clone on unpriv env is now output the following log: $ lxc-clone -o ct02 -n test -s -B overlayfs lxc_container: conf.c: chown_mapped_root: 3649 Error stat /home/karma/.local/share/lxc/test/delta0 Created container test as snapshot of ct02 lxc_container: lxccontainer.c: copy_file: 2303 copy destination /home/karma/.local/share/lxc/test/lxc_rdepends exists Created container test as snapshot of ct02 ct02 is the cloned container with overlayfs. ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] 答复: ask for Android building script
X Le 13 oct. 2014 11:38, 朱敏(寻龙) albert...@alibaba-inc.com a écrit : Thank you, dude! -邮件原件- 发件人: lxc-devel [mailto:lxc-devel-boun...@lists.linuxcontainers.org] 代表 Stéphane Graber 发送时间: 2014年10月13日 17:36 收件人: LXC development mailing-list 主题: Re: [lxc-devel] ask for Android building script On Mon, Oct 13, 2014 at 04:30:12PM +0800, 朱敏(寻龙) wrote: Dear all, Anyone can kindly send me the android building script? I want to integrate lxc into android for some experiment test. The current build script can be found in github.com/lxc/lxc-ci Thanks a lot ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel -- Stéphane Graber Ubuntu developer http://www.ubuntu.com ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] lxc-clone outputs some logs
On Thu, 30 Oct 2014 19:07:58 +0900 in message Re: [lxc-devel] lxc-clone outputs some logs: Hi, After applying commit edf7734 overlay and aufs clone_paths: be more robust, clone was completed successfully but lxc-clone on unpriv env is now output the following log: $ lxc-clone -o ct02 -n test -s -B overlayfs lxc_container: conf.c: chown_mapped_root: 3649 Error stat /home/karma/.local/share/lxc/test/delta0 Created container test as snapshot of ct02 lxc_container: lxccontainer.c: copy_file: 2303 copy destination /home/karma/.local/share/lxc/test/lxc_rdepends exists Created container test as snapshot of ct02 ct02 is the cloned container with overlayfs. I find out other problem. After applying that patch, in part of the beginning of overlayfs_clonepath function, new-dest variable is, for example: overlayfs:/home/karma/.local/share/lxc/ct01/rootfs:/home/karma/.local/share/lxc/ct02/delta0 So, as the result, run mkdir_p(new-dest, 0755), and create dir in current dir. $ lxc-clone -o ct02 -n test -s -B overlayfs lxc_container: conf.c: chown_mapped_root: 3649 Error stat /home/karma/.local/share/lxc/test/delta0 Created container test as snapshot of ct02 lxc_container: lxccontainer.c: copy_file: 2303 copy destination /home/karma/.local/share/lxc/test/lxc_rdepends exists Created container test as snapshot of ct02 $ find overlayfs\:/ overlayfs:/ overlayfs:/home overlayfs:/home/karma overlayfs:/home/karma/.local overlayfs:/home/karma/.local/share overlayfs:/home/karma/.local/share/lxc overlayfs:/home/karma/.local/share/lxc/ct01 overlayfs:/home/karma/.local/share/lxc/ct01/rootfs: overlayfs:/home/karma/.local/share/lxc/ct01/rootfs:/home overlayfs:/home/karma/.local/share/lxc/ct01/rootfs:/home/karma overlayfs:/home/karma/.local/share/lxc/ct01/rootfs:/home/karma/.local overlayfs:/home/karma/.local/share/lxc/ct01/rootfs:/home/karma/.local/share overlayfs:/home/karma/.local/share/lxc/ct01/rootfs:/home/karma/.local/share/lxc overlayfs:/home/karma/.local/share/lxc/ct01/rootfs:/home/karma/.local/share/lxc/test overlayfs:/home/karma/.local/share/lxc/ct01/rootfs:/home/karma/.local/share/lxc/test/delta0 -- KATOH Yasufumi ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH RFC] overlayfs: overlayfs.v22 or higher needs workdir option
Hi,
Thank you for your comment. I will send fixed patch.
On Wed, 29 Oct 2014 13:56:45 +
in message Re: [lxc-devel] [PATCH RFC] overlayfs: overlayfs.v22 or
higherneeds workdir option
Serge Hallyn-san wrote:
Quoting KATOH Yasufumi (ka...@jazz.email.ne.jp):
Hi,
I made changes.
On Sat, 18 Oct 2014 01:24:55 +0900
in message Re: [lxc-devel] [PATCH RFC] overlayfs: overlayfs.v22 or
higher needs workdir option
I wrote:
Mostly ok, just a few cmments below. If you like I'll make the
changes as I apply, or you can send a new version.
Thanks for your comment! I have some questions.
Sorry. I did not read your patch:
https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-October/010687.html
I will check it and resend this patch.
* I assume that upperdir is delta0. Is this right?
* This patch can apply after applying the patch:
https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-October/010687.html
* Add some comments.
---
src/lxc/bdev.c | 88
++
1 file changed, 82 insertions(+), 6 deletions(-)
diff --git a/src/lxc/bdev.c b/src/lxc/bdev.c
index 8a819ab..2253a1b 100644
--- a/src/lxc/bdev.c
+++ b/src/lxc/bdev.c
@@ -2154,10 +2154,12 @@ static int overlayfs_detect(const char *path)
static int overlayfs_mount(struct bdev *bdev)
{
char *options, *dup, *lower, *upper;
- int len;
+ char *options_work, *work, *lastslash;
+ int lastslashidx;
+ int len, len2;
unsigned long mntflags;
char *mntdata;
- int ret;
+ int ret, ret2;
if (strcmp(bdev-type, overlayfs))
return -22;
@@ -2175,6 +2177,21 @@ static int overlayfs_mount(struct bdev *bdev)
*upper = '\0';
upper++;
+ // overlayfs.v22 or higher needs workdir option
+ // if upper is /var/lib/lxc/c2/delta0,
+ // then workdir is /var/lib/lxc/c2/olwork
+ lastslash = strrchr(upper, '/');
+ if (!lastslash)
+ return -22;
+ if (strlen(lastslash) 7)
+ return -22;
I don't think you want to do this here. We don't know for
sure that upper ends in /delta0. And actually you don't need
to do it here, since you are allocating lastslashidx+7 below.
Or am i misreading?
+ lastslash++;
+ lastslashidx = lastslash - upper;
+
+ work = alloca(lastslashidx + 7);
+ strncpy(work, upper, lastslashidx+7);
+ strcpy(work+lastslashidx, olwork);
+
if (parse_mntopts(bdev-mntopts, mntflags, mntdata) 0) {
free(mntdata);
return -22;
@@ -2187,21 +2204,44 @@ static int overlayfs_mount(struct bdev *bdev)
len = strlen(lower) + strlen(upper) +
strlen(upperdir=,lowerdir=,) + strlen(mntdata) + 1;
options = alloca(len);
ret = snprintf(options, len, upperdir=%s,lowerdir=%s,%s,
upper, lower, mntdata);
+
+ len2 = strlen(lower) + strlen(upper) + strlen(work)
+ + strlen(upperdir=,lowerdir=,workdir=) +
strlen(mntdata) + 1;
+ options_work = alloca(len2);
+ ret2 = snprintf(options, len2,
upperdir=%s,lowerdir=%s,workdir=%s,%s,
+ upper, lower, work, mntdata);
}
else {
len = strlen(lower) + strlen(upper) +
strlen(upperdir=,lowerdir=) + 1;
options = alloca(len);
ret = snprintf(options, len, upperdir=%s,lowerdir=%s, upper,
lower);
+
+ len2 = strlen(lower) + strlen(upper) + strlen(work)
+ + strlen(upperdir=,lowerdir=,workdir=) + 1;
+ options_work = alloca(len2);
+ ret2 = snprintf(options_work, len2,
upperdir=%s,lowerdir=%s,workdir=%s,
+ upper, lower, work);
}
- if (ret 0 || ret = len) {
+ if (ret 0 || ret = len || ret2 0 || ret2 = len2) {
free(mntdata);
return -1;
}
+ // mount without workdir option for overlayfs before v21
ret = mount(lower, bdev-dest, overlayfs, MS_MGC_VAL | mntflags,
options);
- if (ret 0)
- SYSERROR(overlayfs: error mounting %s onto %s options %s,
+ if (ret 0) {
+ INFO(overlayfs: error mounting %s onto %s options %s. retry
with workdir,
lower, bdev-dest, options);
+
+ // retry with workdir option for overlayfs v22 and higher
+ ret = mount(lower, bdev-dest, overlayfs, MS_MGC_VAL |
mntflags, options_work);
+ if (ret 0)
+ SYSERROR(overlayfs: error mounting %s onto %s options
%s,
+ lower, bdev-dest, options_work);
+ else
+ INFO(overlayfs: mounted %s onto %s options %s,
+ lower, bdev-dest, options_work);
+ }
else
[lxc-devel] [PATCH] overlayfs: overlayfs.v22 or higher needs workdir option
This patch creates workdir as olwork, and retry mount with workdir
option when mount is failed.
It is used to prepare files before atomically swithing with
destination, and needs to be on the same filesystem as upperdir. It's
OK for it to be empty.
Signed-off-by: KATOH Yasufumi ka...@jazz.email.ne.jp
---
src/lxc/bdev.c | 96 +-
1 file changed, 89 insertions(+), 7 deletions(-)
diff --git a/src/lxc/bdev.c b/src/lxc/bdev.c
index 8a819ab..ae5c77c 100644
--- a/src/lxc/bdev.c
+++ b/src/lxc/bdev.c
@@ -2154,10 +2154,12 @@ static int overlayfs_detect(const char *path)
static int overlayfs_mount(struct bdev *bdev)
{
char *options, *dup, *lower, *upper;
- int len;
+ char *options_work, *work, *lastslash;
+ int lastslashidx;
+ int len, len2;
unsigned long mntflags;
char *mntdata;
- int ret;
+ int ret, ret2;
if (strcmp(bdev-type, overlayfs))
return -22;
@@ -2175,6 +2177,19 @@ static int overlayfs_mount(struct bdev *bdev)
*upper = '\0';
upper++;
+ // overlayfs.v22 or higher needs workdir option
+ // if upper is /var/lib/lxc/c2/delta0,
+ // then workdir is /var/lib/lxc/c2/olwork
+ lastslash = strrchr(upper, '/');
+ if (!lastslash)
+ return -22;
+ lastslash++;
+ lastslashidx = lastslash - upper;
+
+ work = alloca(lastslashidx + 7);
+ strncpy(work, upper, lastslashidx+7);
+ strcpy(work+lastslashidx, olwork);
+
if (parse_mntopts(bdev-mntopts, mntflags, mntdata) 0) {
free(mntdata);
return -22;
@@ -2187,21 +2202,44 @@ static int overlayfs_mount(struct bdev *bdev)
len = strlen(lower) + strlen(upper) +
strlen(upperdir=,lowerdir=,) + strlen(mntdata) + 1;
options = alloca(len);
ret = snprintf(options, len, upperdir=%s,lowerdir=%s,%s,
upper, lower, mntdata);
+
+ len2 = strlen(lower) + strlen(upper) + strlen(work)
+ + strlen(upperdir=,lowerdir=,workdir=) +
strlen(mntdata) + 1;
+ options_work = alloca(len2);
+ ret2 = snprintf(options, len2,
upperdir=%s,lowerdir=%s,workdir=%s,%s,
+ upper, lower, work, mntdata);
}
else {
len = strlen(lower) + strlen(upper) +
strlen(upperdir=,lowerdir=) + 1;
options = alloca(len);
ret = snprintf(options, len, upperdir=%s,lowerdir=%s, upper,
lower);
+
+ len2 = strlen(lower) + strlen(upper) + strlen(work)
+ + strlen(upperdir=,lowerdir=,workdir=) + 1;
+ options_work = alloca(len2);
+ ret2 = snprintf(options_work, len2,
upperdir=%s,lowerdir=%s,workdir=%s,
+ upper, lower, work);
}
- if (ret 0 || ret = len) {
+ if (ret 0 || ret = len || ret2 0 || ret2 = len2) {
free(mntdata);
return -1;
}
+ // mount without workdir option for overlayfs before v21
ret = mount(lower, bdev-dest, overlayfs, MS_MGC_VAL | mntflags,
options);
- if (ret 0)
- SYSERROR(overlayfs: error mounting %s onto %s options %s,
+ if (ret 0) {
+ INFO(overlayfs: error mounting %s onto %s options %s. retry
with workdir,
lower, bdev-dest, options);
+
+ // retry with workdir option for overlayfs v22 and higher
+ ret = mount(lower, bdev-dest, overlayfs, MS_MGC_VAL |
mntflags, options_work);
+ if (ret 0)
+ SYSERROR(overlayfs: error mounting %s onto %s options
%s,
+ lower, bdev-dest, options_work);
+ else
+ INFO(overlayfs: mounted %s onto %s options %s,
+ lower, bdev-dest, options_work);
+ }
else
INFO(overlayfs: mounted %s onto %s options %s,
lower, bdev-dest, options);
@@ -2266,6 +2304,7 @@ static int overlayfs_clonepaths(struct bdev *orig, struct
bdev *new, const char
if (strcmp(orig-type, dir) == 0) {
char *delta, *lastslash;
+ char *work;
int ret, len, lastslashidx;
// if we have /var/lib/lxc/c2/rootfs, then delta will be
@@ -2291,6 +2330,25 @@ static int overlayfs_clonepaths(struct bdev *orig,
struct bdev *new, const char
if (am_unpriv() chown_mapped_root(delta, conf) 0)
WARN(Failed to update ownership of %s, delta);
+ // make workdir for overlayfs.v22 or higher
+ // workdir is /var/lib/lxc/c2/olwork
+ // it is used to prepare files before atomically swithing with
destination,
+ // and needs to be on the same filesystem as upperdir,
+
Re: [lxc-devel] Upstart job /etc/init/lxc-net.conf doesn't allow re-loading dnsmasq' configuration.
Quoting Adam Ryczkowski (adam.ryczkow...@statystyka.net): Hi, There is a subtle bug in the upstart job /etc/init/lxc-net.conf. The part that is invoked when you start the service first checks for the presence of the lxcbr0 bridge: if it exists it simply exits, without touching the dnsmasq deamon. And the part that gets called on lxc-net stop doesn't remove the bridge (the bridge may be in use by existing containers). tl,dr: issuing sudo service lxc-net restart **doesn't reload dnsmasq configuration**. This is a major nuisance if you want to assign static IP to the containers via dnsmasq. -- I have contacted Serge Hallyn who is the original author of the script on that matter; we both agree that the proper resolution would be to split the lxc-net.conf into two jobs: one which prepares the bridge, and second that governs the dnsmasq service. Is this job already done? Where is the bug tracker? If I submit a patch, would someone took a time and inspect it - I have started to learn how to use upstart specifically for this task and have exactly no experience. Yours, It can be counter-intuitive at times - more so when you just start out, but upstart can be very elegant. Upstart is event-based. Jobs - or instances of jobs - can start when other jobs are starting, stopping, or sending events. Looks like we have (at least) two requirements: 1. the lxc-net job should be running so long as the lxc bridge is up and available. So we want a lxc-net job the way we have now, where the bridge is created in pre-start and destroyed on post-stop. We just want to yank some of the work out 2. the dnsmasq process on the bridge should be a separate job with dnsmasq running in the script section. It should start on 'started lxc-net' and stop on 'stopping lxc-net'. If it has a failure, it should perhaps emit a signal that will stop lxc-net. 3. The firewall rules should probably be a third job, which gets started either on started lxc-dnsmasq or on started lxc-net, and stopped symetrically. So long as we're going this route, we might want to make these jobs work as instances, so that we can start lxc-net BRIDGE=lxcbr0 start lxc-net BRIDGE=lxcovs1 and have the same jobs work for all instances. Stéphane is more versed in upstart jobs than I am, so hopefully he can sanity check what I'm writing here. -serge ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] lxc-clone outputs some logs
Quoting KATOH Yasufumi (ka...@jazz.email.ne.jp): On Thu, 30 Oct 2014 19:07:58 +0900 in message Re: [lxc-devel] lxc-clone outputs some logs: Hi, After applying commit edf7734 overlay and aufs clone_paths: be more robust, clone was completed successfully but lxc-clone on unpriv env is now output the following log: $ lxc-clone -o ct02 -n test -s -B overlayfs lxc_container: conf.c: chown_mapped_root: 3649 Error stat /home/karma/.local/share/lxc/test/delta0 Created container test as snapshot of ct02 lxc_container: lxccontainer.c: copy_file: 2303 copy destination /home/karma/.local/share/lxc/test/lxc_rdepends exists Created container test as snapshot of ct02 ct02 is the cloned container with overlayfs. I find out other problem. After applying that patch, in part of the beginning of overlayfs_clonepath function, new-dest variable is, for example: overlayfs:/home/karma/.local/share/lxc/ct01/rootfs:/home/karma/.local/share/lxc/ct02/delta0 So, as the result, run mkdir_p(new-dest, 0755), and create dir in current dir. $ lxc-clone -o ct02 -n test -s -B overlayfs lxc_container: conf.c: chown_mapped_root: 3649 Error stat /home/karma/.local/share/lxc/test/delta0 Created container test as snapshot of ct02 lxc_container: lxccontainer.c: copy_file: 2303 copy destination /home/karma/.local/share/lxc/test/lxc_rdepends exists Created container test as snapshot of ct02 $ find overlayfs\:/ overlayfs:/ overlayfs:/home overlayfs:/home/karma overlayfs:/home/karma/.local overlayfs:/home/karma/.local/share overlayfs:/home/karma/.local/share/lxc overlayfs:/home/karma/.local/share/lxc/ct01 overlayfs:/home/karma/.local/share/lxc/ct01/rootfs: overlayfs:/home/karma/.local/share/lxc/ct01/rootfs:/home overlayfs:/home/karma/.local/share/lxc/ct01/rootfs:/home/karma overlayfs:/home/karma/.local/share/lxc/ct01/rootfs:/home/karma/.local overlayfs:/home/karma/.local/share/lxc/ct01/rootfs:/home/karma/.local/share overlayfs:/home/karma/.local/share/lxc/ct01/rootfs:/home/karma/.local/share/lxc overlayfs:/home/karma/.local/share/lxc/ct01/rootfs:/home/karma/.local/share/lxc/test overlayfs:/home/karma/.local/share/lxc/ct01/rootfs:/home/karma/.local/share/lxc/test/delta0 Sorry, I'm not really following, and I guess I haven't been using overlayfs clones much lately. Do you how to fix it, and can you send a patch? thanks much, -serge ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] time
Hi everyone, just wanted to give a heads-up. As the end of the year approaches, I'm going to be doing a lot of travel - some for work/conferences, where I'll be checking emails at night but have less time than usual, and some where I'm entirely afk. As I get a few thousand emails per day, I may end up missing a few patches during this period. If there's anything pertaining to the C code which I should really review, please ... well, i'm not sure how to say to proceed :) How about, please propose them as a merge request against github.com/hallyn/lxc? I normally don't like pull requests but in this case it may be the best way to proceed. -serge ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] time
Quoting Stéphane Graber (stgra...@ubuntu.com): On Thu, Oct 30, 2014 at 02:44:00PM +, Serge Hallyn wrote: Hi everyone, just wanted to give a heads-up. As the end of the year approaches, I'm going to be doing a lot of travel - some for work/conferences, where I'll be checking emails at night but have less time than usual, and some where I'm entirely afk. As I get a few thousand emails per day, I may end up missing a few patches during this period. If there's anything pertaining to the C code which I should really review, please ... well, i'm not sure how to say to proceed :) How about, please propose them as a merge request against github.com/hallyn/lxc? I normally don't like pull requests but in this case it may be the best way to proceed. -serge I'll be around so I'll make sure to keep track of things which I'd like you to review. I think I'd still prefer people send their patches to the mailing-list and I'll just tag them appropriately here so I've got a list of stuff waiting for your review (and can bounce them back to you if you loose them somehow). Absolutely send them to the list first. I was thinking you and Dwight could use my github tree pull requests as your way to bounce them to me. If people prefer pull requests on github, then please file them against github.com/lxc/lxc and I'll just assign them to hallyn when needed. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] Download template images default password
On Wed, 2014-10-29 at 19:51 +0900, TAMUKI Shoichi wrote: Hello, From: Stephane Graber stgra...@ubuntu.com Subject: [lxc-devel] Download template images default password Date: Tue, 28 Oct 2014 10:56:50 -0400 Just wanted to give a heads up to everyone that I'm now working on changing all the download template generated images to stop shipping with default user accounts and passwords. That means that all the download images will now be much more similar. No distro-specific user accounts and no root password (as in !, not an empty string). The post-create message will recommend using lxc-attach or changing the password using chroot. Thank you for your work. I am looking forward to that. There is one point that I would like the password treatment to have the same behavior between the following cases: - using the distro-specific template with '-t' option to lxc-create - using download template (for non-privileged users) This is possible with some templates now (Fedora, CentOS) and will be incorporated into a few others (SuSE and a few others) before long. I've been very tardy in updating some submitted patches that needed to be revised and resubmitted. The very fact that we have two separate bugzilla security bugs (one at Debian and one at Fedora) over this very issue should be the pressure to fix the other templates. I've volunteered to do some of that, once we have some functions abstracted. I'm not particularly opposed to having distro specific users (ubuntu, fedora, etc) but all of them should be either locked or configurably driven by templates (Fedora and CentOS) which allows for locking, expiration, and rule based generation. What Stéphane has done now is great and I applaud that. The download template is the one I was going to steer clear of just because it's his baby and involved user space containers which is outside of my normal realm. Regards, TAMUKI Shoichi Expect some improvements in this area before too long. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH v2 3/3] Improve setting the default password in a new container
On Wed, 2014-10-29 at 19:29 +0900, TAMUKI Shoichi wrote:
Hello,
From: Michael H. Warfield m...@wittsend.com
Subject: Re: [lxc-devel] [PATCH v2 3/3] Improve setting the default password
in a new container
Date: Sat, 11 Oct 2014 13:24:10 -0400
The default password in a new container is now auto-generated using
phoneme rules and (good) random numbers.
Even if the default random password is set in a distribution-specific
template and you use the download template to pull a pre-built rootfs
image, you will get the same password every time unless the pre-built
rootfs image is updated.
So, the default random password in a new container is to be set after
container creation. The user names whose passwords to be changed are
stored in *.chpasswd file which is located at /usr/share/lxc/config.
Each line of the file specifies a user name whose password is to be
changed. If the target *.chpasswd file does not exist, no password is
changed in a new container.
This is obviously a festering problem and one that has already been
addressed in the Fedora and CentOS templates in a different manner and
additional patches have been submitted and under discussion. Did you
even bother to read the code in the Fedora and CentOS templates?
At first, I intended to use the code in the Fedora/CentOS templates,
but I became aware that the method was available only when using the
template with '-t' option to lxc-create. It can not be used by non-
priv users.
That would then be handled by the download template and, iirc, it was
Stephane's intention to have those containers start with locked
accounts and require lxc-attach or something similar to set up.
I spent time to look into the Fedora template about the password
treatment. In summary, the Fedora template works as following specs:
--
root_password=[password]
If the root_password is non-blank, use it, else set a default.
This can be passed to the script as an environment variable and is
set by a shell conditional assignment. Looks weird but it is what it is.
If the root password contains a ding ($) then try to expand it.
That will pick up things like ${name} and ${RANDOM}.
If the root password contains more than 3 consecutive X's, pass it as
a template to mktemp and take the result.
These are conditional assignments. They can be overridden from the
pre-existing environment variables.
root_display_password=[yes|no]
If root_display_password=yes, display the temporary root password at
exit. Default to no.
root_store_password=[yes|no]
If root_store_password=yes, store it in the configuration directory.
Default to yes.
root_prompt_password=[yes|no]
If root_prompt_password=yes, invoke passwd to force the user to change
the root password after the container is created. Default to no.
root_expire_password=[yes|no]
If root_expire_password=yes, you will be prompted to change the root
password at the first login. Default to yes.
--
Currently, it seems not to take multi-user accounts into account, and
it does not support with locked accounts. So, I tried rewriting the
code:
Yeah, that was addressed in a patch that I sent in over a month ago that
raised some tangential questions with Stéphane. The intent was to split
that off into a more generalized functions file that had code to address
those issues. I have reworked a lot of that and haven't resubmitted it
yet.
Could you look at the patch posted to the list on 09/14..
Subject: [PATCH] Various fixes for Fedora/CentOS/OpenSUSE templates and
systemd.
Look at the code in the new functions file and the revisions to the
CentOS and Fedora templates to utilize it (ignore the mac address code
generation that was one of the things Stéphane was objecting too as
redundant). That code is going to be largely unchanged although I would
welcome any input from you on it.
--
#!/bin/bash
:
:
:
# Some combinations of the tuning knobs below do not exactly make sense.
# but that's ok.
#
# If the LXC_PASSWORD is non-blank, use it, else set a default.
# This can be passed to the script as an environment variable and is
# set by a shell conditional assignment. Looks weird but it is what it is.
#
# If the password is PROMPT, invoke passwd to force the user to
# change the password after the container is created.
# Prompting for something interactive has potential for mayhem with
# users running under the API... Don't default to PROMPT.
# If the password contains one of 3 common disabled conventions, or
# a hash indicator for a real password hash, assume in encrypted form.
# If the password contains a ding ($) then try to expand it.
# That
[lxc-devel] openSUSE template still at 12.3?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, are there so few openSUSE users, or is there another reason why the openSUSE template still installs 12.3, although 13.1 is available for so long (and 13.2 is around the corner)? If I find some minutes, I'd like to see if I can get the template to choose which version should be installed. Is there any docu on this, or should I just have a look at the ubuntu one (which allows version selection IIRC)? Regards, Johannes - -- Sex is like hacking. You get in, you get out, and you hope you didnt leave something behind that can be traced back to you. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlRSeqIACgkQzi3gQ/xETbIRMQCdG9LKC+mdY+BG86dkrLScXvMM oUEAnilYPb+tM2bvAesDpyFiC3LGd4YY =UGyy -END PGP SIGNATURE- ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] openSUSE template still at 12.3?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again, On 30.10.14 Johannes Kastl wrote: are there so few openSUSE users, or is there another reason why the openSUSE template still installs 12.3, although 13.1 is available for so long (and 13.2 is around the corner)? I just read what I wrote, and it sounds to harsh and accusing. That was not my intention, so please excuse my error... Johannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlRSfxEACgkQzi3gQ/xETbIbNQCfUcdF12FLNt7EXugO/UPSuPMN MTMAoJUrCjxyz8XapjFgK56A6dHri4bH =YFbG -END PGP SIGNATURE- ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] openSUSE template still at 12.3?
On Thu, 2014-10-30 at 18:51 +0100, Johannes Kastl wrote: Hi everyone, are there so few openSUSE users, or is there another reason why the openSUSE template still installs 12.3, although 13.1 is available for so long (and 13.2 is around the corner)? I can't speak to how many openSUSE users there are. The users are not the ones that direct drive this process though (all philosophical debates aside). They can express demand but it's still the developers and the template owners that drive the changes. I can speak to my own efforts. I have some zSeries mainframe experience with zOS Enterprise SuSE and my desire to work test scenarios using openSUSE on x86_64 containers. Consequently, I've been in contact with the SuSE developers and they've been quite happy and appreciative to have me do editing on the openSuSE template while I keep them up to date and in the loop. They do seem to be somewhat occupied by their day jobs. :-) If I find some minutes, I'd like to see if I can get the template to choose which version should be installed. Is there any docu on this, or should I just have a look at the ubuntu one (which allows version selection IIRC)? Most of the templates (Ubuntu, Debian, Fedora, CentOS, Oracle) allow for version selection. If OpenSuSE does not (which it apparently does not - I just looked), that is something that needs to be addressed. I think they all suffer from the problem that they, by default, install a fixed version and don't track the latest or the latest supported, which can be an indeterminant value. There are several other things which need to go into the openSuSE template wrt user and passwords. Regards, Johannes Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] Upstart job /etc/init/lxc-net.conf doesn't allow re-loading dnsmasq' configuration.
Hi, There is a subtle bug in the upstart job /etc/init/lxc-net.conf. The part that is invoked when you start the service first checks for the presence of the lxcbr0 bridge: if it exists it simply exits, without touching the dnsmasq deamon. And the part that gets called on lxc-net stop doesn't remove the bridge (the bridge may be in use by existing containers). tl,dr: issuing sudo service lxc-net restart **doesn't reload dnsmasq configuration**. This is a major nuisance if you want to assign static IP to the containers via dnsmasq. -- I have contacted Serge Hallyn who is the original author of the script on that matter; we both agree that the proper resolution would be to split the lxc-net.conf into two jobs: one which prepares the bridge, and second that governs the dnsmasq service. Is this job already done? Where is the bug tracker? If I submit a patch, would someone took a time and inspect it - I have started to learn how to use upstart specifically for this task and have exactly no experience. Yours, Adam Ryczkowski +48505919892 callto:+48505919892 Skype:sisteczko skype:sisteczko ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH] openwrt: add common configuration file
This adds OpenWrt common config file.
Signed-off-by: Petar Koretic petar.kore...@sartura.hr
CC: Luka Perkov luka.per...@sartura.hr
---
OpenWrt templates are working using 'lxc-create -t download' command. We are
running that over our server on http://virtualwrt.org/containers/. There is
only support for x86, x86_64 and ar71xx as of now. We plan to add all other
architectures supported by OpenWrt in the future. The build scripts used to
generate images can be found here:
https://github.com/VirtualWrt/misc
Note that index files on virtualwrt.org/containers are not validated.
OpenWrt now supports containers but due to platform specifics there are some
limitations:
* 'tar --anchored' doesn't come with busybox's tar version, lxc is patched in
OpenWrt packages feed to ignore this functionality.
* .xz extraction is very expensive on most OpenWrt supported devices, -0 level
is used for rootfs compression to mitigate that to some extent.
* Priviliged containers are not supported at the moment since default user
is root on this platform.
I'm looking forward for your comments and suggestions to get OpenWrt images
hosted on official lxc servers.
config/templates/Makefile.am| 1 +
config/templates/openwrt.common.conf.in | 56 +
configure.ac| 1 +
3 files changed, 58 insertions(+)
create mode 100644 config/templates/openwrt.common.conf.in
diff --git a/config/templates/Makefile.am b/config/templates/Makefile.am
index 82ca8be..fdbf9d2 100644
--- a/config/templates/Makefile.am
+++ b/config/templates/Makefile.am
@@ -28,4 +28,5 @@ templatesconfig_DATA = \
ubuntu.common.conf \
ubuntu.lucid.conf \
ubuntu.userns.conf \
+ openwrt.common.conf \
userns.conf
diff --git a/config/templates/openwrt.common.conf.in
b/config/templates/openwrt.common.conf.in
new file mode 100644
index 000..05918f0
--- /dev/null
+++ b/config/templates/openwrt.common.conf.in
@@ -0,0 +1,56 @@
+# Default mount entries
+lxc.mount.entry = proc proc proc nodev,noexec,nosuid 0 0
+lxc.mount.entry = sysfs sys sysfs defaults 0 0
+
+# Default console settings
+lxc.devttydir = lxc
+lxc.tty = 4
+lxc.pts = 1024
+
+# Default capabilities
+lxc.cap.drop = mac_admin
+lxc.cap.drop = mac_override
+lxc.cap.drop = sys_admin
+lxc.cap.drop = sys_module
+lxc.cap.drop = sys_nice
+lxc.cap.drop = sys_pacct
+lxc.cap.drop = sys_ptrace
+lxc.cap.drop = sys_rawio
+lxc.cap.drop = sys_resource
+lxc.cap.drop = sys_time
+lxc.cap.drop = sys_tty_config
+lxc.cap.drop = syslog
+lxc.cap.drop = wake_alarm
+
+# Default cgroups - all denied except those whitelisted
+lxc.cgroup.devices.deny = a
+## /dev/null and zero
+lxc.cgroup.devices.allow = c 1:3 rwm
+lxc.cgroup.devices.allow = c 1:5 rwm
+## consoles
+lxc.cgroup.devices.allow = c 5:0 rwm
+lxc.cgroup.devices.allow = c 5:1 rwm
+## /dev/{,u}random
+lxc.cgroup.devices.allow = c 1:8 rwm
+lxc.cgroup.devices.allow = c 1:9 rwm
+## /dev/pts/*
+lxc.cgroup.devices.allow = c 5:2 rwm
+lxc.cgroup.devices.allow = c 136:* rwm
+## rtc
+lxc.cgroup.devices.allow = c 254:0 rm
+## fuse
+lxc.cgroup.devices.allow = c 10:229 rwm
+## tun
+lxc.cgroup.devices.allow = c 10:200 rwm
+## dev/tty0
+lxc.cgroup.devices.allow = c 4:0 rwm
+## dev/tty1
+lxc.cgroup.devices.allow = c 4:1 rwm
+
+## To use loop devices, copy the following line to the container's
+## configuration file (uncommented).
+#lxc.cgroup.devices.allow = b 7:* rwm
+
+# Blacklist some syscalls which are not safe in privileged
+# containers
+lxc.seccomp = /usr/share/lxc/config/common.seccomp
diff --git a/configure.ac b/configure.ac
index 5f9774b..1d9634e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -646,6 +646,7 @@ AC_CONFIG_FILES([
config/templates/ubuntu.common.conf
config/templates/ubuntu.lucid.conf
config/templates/ubuntu.userns.conf
+ config/templates/openwrt.common.conf
config/templates/userns.conf
config/yum/Makefile
config/sysconfig/Makefile
--
2.1.2
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH] lxc-cirros: support creating+running unprivileged
Support creation and use of lxc-cirros by unprivileged users.
If we detect we are an unprivileged user, then insist that we
be in a userns with a id mapping.
If we are in a userns, then don't extract /dev when extracting
the rootfs.
If we are not root, then save the tarball to ~/.cache/lxc/cirros
instead of /var/cache/lxc/cirros.
If we are not roo, then include entries to auto-mount proc and sys,
as well as bind-mount devices.
Cc: smo...@ubuntu.com
Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
---
templates/lxc-cirros.in | 62 +
1 file changed, 37 insertions(+), 25 deletions(-)
diff --git a/templates/lxc-cirros.in b/templates/lxc-cirros.in
index 24b9210..c8a8b36 100644
--- a/templates/lxc-cirros.in
+++ b/templates/lxc-cirros.in
@@ -22,27 +22,21 @@
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
# Detect use under userns (unsupported)
-for arg in $@; do
-[ $arg = -- ] break
-if [ $arg = --mapped-uid -o $arg = --mapped-gid ]; then
-echo This template can't be used for unprivileged containers. 12
-echo You may want to try the \download\ template instead. 12
-exit 1
-fi
-done
-
# Make sure the usual locations are in PATH
export PATH=$PATH:/usr/sbin:/usr/bin:/sbin:/bin
VERBOSITY=0
DOWNLOAD_URL=http://download.cirros-cloud.net/;
-CACHE_D=@LOCALSTATEDIR@/cache/lxc/cirros
UNAME_M=$(uname -m)
ARCHES=( i386 x86_64 amd64 arm )
STREAMS=( released devel )
SOURCES=( nocloud none )
BUILD=standard
+LXC_TEMPLATE_CONFIG=@LXCTEMPLATECONFIG@
+
+LXC_MAPPED_GID=
+LXC_MAPPED_UID=
DEF_VERSION=released
DEF_SOURCE=nocloud
@@ -53,6 +47,23 @@ case ${UNAME_M} in
*) DEF_ARCH=i386;;
esac
+am_in_userns() {
+[ -e /proc/self/uid_map ] || { echo no; return; }
+[ $(wc -l /proc/self/uid_map | awk '{ print $1 }') -eq 1 ] || { echo
yes; return; }
+line=$(awk '{ print $1 $2 $3 }' /proc/self/uid_map)
+[ $line = 0 0 4294967295 ] { echo no; return; }
+echo yes
+}
+
+in_userns=0
+[ $(am_in_userns) = yes ] in_userns=1
+
+if [ $(id -u) -eq 0 ]; then
+CACHE_D=@LOCALSTATEDIR@/cache/lxc/cirros
+else
+CACHE_D=$HOME/.cache/lxc/cirros
+fi
+
error() { echo $@ 12; }
inargs() {
local needle=$1 x=
@@ -151,6 +162,12 @@ lxc.cgroup.devices.allow = c 10:228 rwm
# kvm
lxc.cgroup.devices.allow = c 10:232 rwm
EOF
+
+if [ $in_userns -eq 1 ] [ -e
${LXC_TEMPLATE_CONFIG}/ubuntu-cloud.userns.conf ]; then
+echo lxc.include = ${LXC_TEMPLATE_CONFIG}/ubuntu.userns.conf
$path/config
+echo lxc.mount.auto = cgroup:mixed proc:mixed sys:ro $path/config
+fi
+
}
insert_ds_nocloud() {
@@ -187,8 +204,13 @@ extract_rootfs() {
mkdir -p ${rootfs_d} ||
{ error failed to make rootfs dir ${rootfs_d}; return 1; }
-tar -C ${rootfs_d} -Sxzf ${tarball} ||
-{ error failed to populate ${rootfs_d}; return 1; }
+if [ $in_userns -eq 1 ]; then
+tar -C ${rootfs_d} --anchored --exclude=dev/* -Sxzf ${tarball} ||
+{ error failed to populate ${rootfs_d}; return 1; }
+else
+tar -C ${rootfs_d} -Sxzf ${tarball} ||
+{ error failed to populate ${rootfs_d}; return 1; }
+fi
return 0
}
@@ -218,7 +240,7 @@ download_tarball() {
create_main() {
local short_opts=a:hn:p:S:uvV
-local
long_opts=arch:,auth-key:,name:,path:,tarball:,userdata:,verbose,version:,rootfs:
+local
long_opts=arch:,auth-key:,name:,path:,tarball:,userdata:,verbose,version:,rootfs:,mapped-uid:,mapped-gid:
local getopt_out=
getopt_out=$(getopt --name ${0##*/} \
--options ${short_opts} --long ${long_opts} -- $@)
@@ -244,6 +266,8 @@ create_main() {
--tarball) tarball=$next; shift;;
--source) dsource=$next; shift;;
--rootfs) rootfs_d=$next; shift;;
+--mapped-uid) LXC_MAPPED_UID=$next; shift;;
+--mapped-gid) LXC_MAPPED_GID=$next; shift;;
--) shift; break;;
esac
shift;
@@ -300,18 +324,6 @@ create_main() {
extract_rootfs ${tarball} ${rootfs_d} || return
-# cirros 0.3.1 was broken for /dev/random and /dev/urandom
-if [ -b $rootfs_d/dev/random ]; then
-rm -f $rootfs_d/dev/random
-mknod --mode=666 $rootfs_d/dev/random c 1 8 ||
- { error failed to fix /dev/random; return 1; }
-fi
-if [ -b $rootfs_d/dev/urandom ]; then
-rm -f $rootfs_d/dev/urandom
-mknod --mode=666 $rootfs_d/dev/urandom c 1 9 ||
- { error failed to fix /dev/urandom; return 1; }
-fi
-
if [ $version = 0.3.2~pre1 ]; then
debug 1 fixing console for lxc and '$version'
sed -i 's,^\(#console.* 115200 \)# /dev/console,\1 console,g' \
--
2.1.0
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
