Re: [lxc-devel] lxc-destroy erased my hard disc
On Tue, Jan 14, 2014 at 04:48:57PM -0600, Serge Hallyn wrote: > Quoting Dan Fandrich (d...@coneharvesters.com): > > On Mon, Jan 13, 2014 at 06:23:24PM -0600, Serge Hallyn wrote: > > > Gah, that really does suck, sorry. The need to run as root has always > > > been annoying. We're finally at the point that some containers can be > > > created and run entirely as non-root, so that your host should be a lot > > > safer. > > > > That's definitely a positive development! > > > > > > This was with lxc 0.8.0 on x86 Linux (the relevant 0.9.0 code looks > > > > substantially similar). It happened shortly after installing lxc for > > > > the first > > > > time to try it out. I believe what must have happened was that the > > > > container I > > > > created wasn't shut down properly and still had its bind mounts for > > > > /lib etc. > > > > > > lxc-start would not have done any mounting in the host's mount > > > namespace, so that scenario shouldn't be possible. > > > > > > So I would actually guess that lxc-create (actually the template) was to > > > blame for leaving the bind mounts. Since it looks like you're not using > > > a stock template I'm not sure how you created the container. > > > > That's quite possible; I'm not completely sure yet how all the lxc > > moving parts fit together yet. I was using the stock busybox template, but > > there were a couple of configuration problems with lxc, so it wasn't a > > single > > perfectly clean create/start/stop. > > > > > > in place. The container must have been down enough to be considered not > > > > running > > > > according to lxc-info, so lxc-destroy helpfully rm -rf'ed it, including > > > > the > > > > contents of the bind mounts which pointed into my host system. > > > > > > > > rm was given the --one-file-system option, but it didn't prevent this > > > > from > > > > occurring, presumably because the device ID of the container location > > > > was the > > > > same as the device ID of the /lib of the host. After looking at the > > > > source to > > > > lxc-destroy, I'm surprised this kind of problem doesn't happen more > > > > often--it > > > > > > We do discourage bind-mounting from the host fs into the container, but > > > historcally it was considered useful (and may again) for > > > checkpoint/restart. > > > > > > > is not at all defensively written (error codes ignored, arguments not > > > > properly > > > > quoted, this problem I'm writing about, etc.), so I was glad to see that > > > > lxc-destroy has since been reimplemented. However, on briefly looking > > > > at the > > > > new source, it seems that the same problem can still occur. There's a > > > > comparison of device IDs before deleting files (presumably, to try to > > > > accomplish the same thing as rm's --one-file-system option), but my > > > > situation > > > > of bind mounts on the same filesystem device means once again that > > > > wouldn't be > > > > effective in preventing this erroneous deletion. > > > > > > > > I strongly suggest improving the checks before deletion to avoid this > > > > kind of > > > > problem in the future. This may be as simple as checking the bind mount > > > > points against /proc/mounts before starting the destroy process. > > > > > > I can see no reason not to add a check against /proc/mounts for any > > > entries under $rootfs (if it is a directory). That should definately be > > > added. > > > > I'm attaching the patch I added to my system to try to stop this from > > happening > > again. The ugly sed to create the grep regex is because rootdev ends up with > > two leading slashes instead of one, which wouldn't otherwise match. I > > suspect > > that's simply a bug in the sed two lines before, but I wasn't sure if there > > were implications for lvdisplay or btrfs in fixing it, so I left it. > > The patch doesn't actually seem to be attached? Whoops--It's attached now. > Note though that lxc-destroy is now a c program. I don't recall whether > someone actually stepped up to Stéphane's call for maintainers for older > versions - it would be a good thing to have. >>> Dan Check that there are no bind mounts set up before destroying a container. Otherwise, the contents of that bind will be destroyed if a container was not properly shut down. --- a/src/lxc/lxc-destroy.in2014-01-13 22:45:22.0 +0100 +++ b/src/lxc/lxc-destroy.in2014-01-13 23:13:40.258095984 +0100 @@ -125,6 +125,11 @@ # else, ignore it. We'll support deletion of others later. rootdev=`grep lxc.rootfs $lxc_path/$lxc_name/config 2>/dev/null | sed -e 's/^[^/]*/\//'` if [ -n "$rootdev" ]; then +if grep -q "$(sed 's@^/\+/@/@' <<<"$rootdev")" /proc/mounts; then + echo "$(basename $0): '$lxc_name' is not properly stopped; aborted" >&2 + exit 1 +fi + if [ -b "$rootdev" -o -h "$rootdev" ]; then lvdisplay $rootdev > /dev/null 2>&1 if [ $? -eq 0 ]; then @@ -137,10 +142,10 @@ btrfs subvolume delete "$r
[lxc-devel] [PATCH] cgroup.c: redefine the valid cgroup name
Signed-off-by: Qiang Huang
---
src/lxc/cgroup.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/lxc/cgroup.c b/src/lxc/cgroup.c
index 6d837f9..69910cc 100644
--- a/src/lxc/cgroup.c
+++ b/src/lxc/cgroup.c
@@ -1669,7 +1669,11 @@ bool is_valid_cgroup(const char *name)
{
const char *p;
for (p = name; *p; p++) {
- if (*p < 32 || *p == 127 || *p == '/')
+ /* Use the ASCII printable characters range(32 - 127)
+* is reasonable, we kick out 32(SPACE) because it'll
+* break legacy lxc-ls
+*/
+ if (*p <= 32 || *p >= 127 || *p == '/')
return false;
}
return strcmp(name, ".") != 0 && strcmp(name, "..") != 0;
--
1.8.3
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] Last minute template addition - universal image based template
On Tue, Jan 14, 2014 at 10:02:39PM -0500, S.Çağlar Onur wrote: > On Tue, Jan 14, 2014 at 9:50 PM, Stéphane Graber wrote: > > On Tue, Jan 14, 2014 at 09:48:13PM -0500, Stéphane Graber wrote: > >> On Tue, Jan 14, 2014 at 09:30:50PM -0500, S.Çağlar Onur wrote: > >> > On Tue, Jan 14, 2014 at 9:24 PM, Stéphane Graber > >> > wrote: > >> > > On Tue, Jan 14, 2014 at 09:12:31PM -0500, S.Çağlar Onur wrote: > >> > >> Hey Stéphane, > >> > >> > >> > >> On Tue, Jan 14, 2014 at 6:52 PM, Stéphane Graber > >> > >> wrote: > >> > >> > On Tue, Jan 14, 2014 at 06:38:43PM -0500, Dwight Engen wrote: > >> > >> >> On Mon, 13 Jan 2014 20:56:23 -0500 > >> > >> >> Stéphane Graber wrote: > >> > >> >> > >> > >> >> [...] > >> > >> >> > > >> > >> >> > Yeah, I did a few last-minute changes. > >> > >> >> > > >> > >> >> > fstab is no longer required (only copied over if it's there). > >> > >> >> > > >> > >> >> > If the expiry file is messing, it's simply assumed that the > >> > >> >> > container > >> > >> >> > won't expire. > >> > >> >> > >> > >> >> Nice, that makes sense. > >> > >> >> > >> > >> >> [...] > >> > >> >> > Now for Oracle, I guess it depends what's most useful for your > >> > >> >> > users. > >> > >> >> > > >> > >> >> > Is there actually still a demand for 4.x? I thought at least > >> > >> >> > RHEL 4.x > >> > >> >> > went out of support last year. > >> > >> >> > > >> > >> >> > In any case, I suspect that starting with the latest of each > >> > >> >> > supported > >> > >> >> > release on i386 and amd64 is probably a good start. > >> > >> >> > We can then expand that to include popular minor releases, > >> > >> >> > possibly > >> > >> >> > the last few 6.x? > >> > >> >> > >> > >> >> Yeah I think it makes sense to start with just x86_64 6.latest, and > >> > >> >> we'll see how it goes from there. > >> > >> >> > >> > >> >> > > One question I have on this is that the rootfs (at least that > >> > >> >> > > the > >> > >> >> > > Oracle template makes, not sure about others) isn't quite right > >> > >> >> > > since the host name will have already been injected into config > >> > >> >> > > files (for example /etc/hosts), but lxc-download wants to > >> > >> >> > > template > >> > >> >> > > them itself. Should we add a switch to the distro template so > >> > >> >> > > it > >> > >> >> > > knows when its being called to create a rootfs for > >> > >> >> > > lxc-download to > >> > >> >> > > put LXC_NAME in there instead the --name it was passed? > >> > >> >> > > >> > >> >> > So currently my build script (Jenkins job) will call the template > >> > >> >> > with: > >> > >> >> > - --rootfs=/build-lxc/container/LXC_NAME/rootfs > >> > >> >> > - --path=/build-lxc/container/LXC_NAME > >> > >> >> > - --name=LXC_NAME > >> > >> >> > >> > >> >> Oh yeah, doh! Clever, that should make it work fine. > >> > >> >> > >> > >> >> [...] > >> > >> >> > > I have not tried from a normal user account yet. Is it > >> > >> >> > > basically > >> > >> >> > > that you expect the template to be run by a normal user, but be > >> > >> >> > > running in a userns? Can you describe how mapped_uid is > >> > >> >> > > supposed to > >> > >> >> > > be set? Thanks! > >> > >> >> > -d oracle -r 6.5 -a x86_64 --server phocis/lxc-images > >> > >> >> > --no-validate > >> > >> >> > Yeah, lxc-create basically does all the magic we need there. > >> > >> >> > When run as a user, it'll run the template in a userns mapped > >> > >> >> > with the > >> > >> >> > container's range. > >> > >> >> > > >> > >> >> > $mapped_uid appears to be set to the uid in the userns which > >> > >> >> > maps back > >> > >> >> > to the user's own uid outside of it and makes it possible to > >> > >> >> > chown > >> > >> >> > files back to the actual user. > >> > >> >> > >> > >> >> So I had to dig into the source to see how I could get this to > >> > >> >> work, > >> > >> >> and tried passing a line like: > >> > >> >> > >> > >> >> lxc-create -P /home/dengen/ct -f > >> > >> >> /home/dengen/ct/dengen_id_map.conf -n ol65 -t download -- -d > >> > >> >> oracle -r 6.5 -a x86_64 --server lxchttp/lxc-images --no-validate > >> > >> >> > >> > >> >> where /home/dengen/ct/dengen_id_map.conf just has: > >> > >> >> lxc.id_map = u 0 10 1 > >> > >> >> lxc.id_map = g 0 10 1 > >> > >> >> > >> > >> >> in order to get mapped_uid in lxc-create to kick in. Sadly this > >> > >> >> didn't > >> > >> >> work because lxc.spec is still installing lxc-create (and a lot > >> > >> >> more) > >> > >> >> setuid, so the geteuid() check in create_run_template() isn't > >> > >> >> firing. > >> > >> >> So my question is: which lxc binaries are supposed to be installed > >> > >> >> setuid these days? Is it just lxc-user-nic? Once I know, I can go > >> > >> >> ahead > >> > >> >> and fixup lxc.spec. Thanks. > >> > >> > > >> > >> > Oh, wow, I didn't realize some distros were still installing > >> > >> > anything > >> > >> > setuid these days, especially after we drop lxc-setuid and > >> > >> > lxc-setcap > >
Re: [lxc-devel] Last minute template addition - universal image based template
On Tue, Jan 14, 2014 at 9:50 PM, Stéphane Graber wrote: > On Tue, Jan 14, 2014 at 09:48:13PM -0500, Stéphane Graber wrote: >> On Tue, Jan 14, 2014 at 09:30:50PM -0500, S.Çağlar Onur wrote: >> > On Tue, Jan 14, 2014 at 9:24 PM, Stéphane Graber >> > wrote: >> > > On Tue, Jan 14, 2014 at 09:12:31PM -0500, S.Çağlar Onur wrote: >> > >> Hey Stéphane, >> > >> >> > >> On Tue, Jan 14, 2014 at 6:52 PM, Stéphane Graber >> > >> wrote: >> > >> > On Tue, Jan 14, 2014 at 06:38:43PM -0500, Dwight Engen wrote: >> > >> >> On Mon, 13 Jan 2014 20:56:23 -0500 >> > >> >> Stéphane Graber wrote: >> > >> >> >> > >> >> [...] >> > >> >> > >> > >> >> > Yeah, I did a few last-minute changes. >> > >> >> > >> > >> >> > fstab is no longer required (only copied over if it's there). >> > >> >> > >> > >> >> > If the expiry file is messing, it's simply assumed that the >> > >> >> > container >> > >> >> > won't expire. >> > >> >> >> > >> >> Nice, that makes sense. >> > >> >> >> > >> >> [...] >> > >> >> > Now for Oracle, I guess it depends what's most useful for your >> > >> >> > users. >> > >> >> > >> > >> >> > Is there actually still a demand for 4.x? I thought at least RHEL >> > >> >> > 4.x >> > >> >> > went out of support last year. >> > >> >> > >> > >> >> > In any case, I suspect that starting with the latest of each >> > >> >> > supported >> > >> >> > release on i386 and amd64 is probably a good start. >> > >> >> > We can then expand that to include popular minor releases, possibly >> > >> >> > the last few 6.x? >> > >> >> >> > >> >> Yeah I think it makes sense to start with just x86_64 6.latest, and >> > >> >> we'll see how it goes from there. >> > >> >> >> > >> >> > > One question I have on this is that the rootfs (at least that the >> > >> >> > > Oracle template makes, not sure about others) isn't quite right >> > >> >> > > since the host name will have already been injected into config >> > >> >> > > files (for example /etc/hosts), but lxc-download wants to >> > >> >> > > template >> > >> >> > > them itself. Should we add a switch to the distro template so it >> > >> >> > > knows when its being called to create a rootfs for lxc-download >> > >> >> > > to >> > >> >> > > put LXC_NAME in there instead the --name it was passed? >> > >> >> > >> > >> >> > So currently my build script (Jenkins job) will call the template >> > >> >> > with: >> > >> >> > - --rootfs=/build-lxc/container/LXC_NAME/rootfs >> > >> >> > - --path=/build-lxc/container/LXC_NAME >> > >> >> > - --name=LXC_NAME >> > >> >> >> > >> >> Oh yeah, doh! Clever, that should make it work fine. >> > >> >> >> > >> >> [...] >> > >> >> > > I have not tried from a normal user account yet. Is it basically >> > >> >> > > that you expect the template to be run by a normal user, but be >> > >> >> > > running in a userns? Can you describe how mapped_uid is supposed >> > >> >> > > to >> > >> >> > > be set? Thanks! >> > >> >> > -d oracle -r 6.5 -a x86_64 --server phocis/lxc-images --no-validate >> > >> >> > Yeah, lxc-create basically does all the magic we need there. >> > >> >> > When run as a user, it'll run the template in a userns mapped with >> > >> >> > the >> > >> >> > container's range. >> > >> >> > >> > >> >> > $mapped_uid appears to be set to the uid in the userns which maps >> > >> >> > back >> > >> >> > to the user's own uid outside of it and makes it possible to chown >> > >> >> > files back to the actual user. >> > >> >> >> > >> >> So I had to dig into the source to see how I could get this to work, >> > >> >> and tried passing a line like: >> > >> >> >> > >> >> lxc-create -P /home/dengen/ct -f /home/dengen/ct/dengen_id_map.conf >> > >> >> -n ol65 -t download -- -d oracle -r 6.5 -a x86_64 --server >> > >> >> lxchttp/lxc-images --no-validate >> > >> >> >> > >> >> where /home/dengen/ct/dengen_id_map.conf just has: >> > >> >> lxc.id_map = u 0 10 1 >> > >> >> lxc.id_map = g 0 10 1 >> > >> >> >> > >> >> in order to get mapped_uid in lxc-create to kick in. Sadly this >> > >> >> didn't >> > >> >> work because lxc.spec is still installing lxc-create (and a lot more) >> > >> >> setuid, so the geteuid() check in create_run_template() isn't firing. >> > >> >> So my question is: which lxc binaries are supposed to be installed >> > >> >> setuid these days? Is it just lxc-user-nic? Once I know, I can go >> > >> >> ahead >> > >> >> and fixup lxc.spec. Thanks. >> > >> > >> > >> > Oh, wow, I didn't realize some distros were still installing anything >> > >> > setuid these days, especially after we drop lxc-setuid and lxc-setcap >> > >> > from the upstream tree. >> > >> > >> > >> > So anyway, nowadays, the recommendation is for only lxc-user-nic to be >> > >> > setuid, everything else should always run as the user. When run as >> > >> > root, >> > >> > you'll end up with system containers, when run as a user, you'll get >> > >> > an >> > >> > unprivileged container. >> > >> >> > >> Should I expect [1] to work on saucy with trusty kernel? Here is what >> >
[lxc-devel] [PATCH] Always try to create lxcpath
Signed-off-by: Stéphane Graber
---
src/lxc/lxc_create.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/lxc/lxc_create.c b/src/lxc/lxc_create.c
index d02dacc..6d94709 100644
--- a/src/lxc/lxc_create.c
+++ b/src/lxc/lxc_create.c
@@ -206,6 +206,9 @@ int main(int argc, char *argv[])
exit(1);
if (geteuid()) {
+ if (mkdir_p(my_args.lxcpath[0], 0755)) {
+ exit(1);
+ }
if (access(my_args.lxcpath[0], O_RDWR) < 0) {
fprintf(stderr, "You lack access to %s\n",
my_args.lxcpath[0]);
exit(1);
--
1.8.5.2
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH] lxc-download: Fix undefined DOWNLOAD_FORCE_CACHE
Signed-off-by: Stéphane Graber --- templates/lxc-download.in | 1 + 1 file changed, 1 insertion(+) diff --git a/templates/lxc-download.in b/templates/lxc-download.in index aa93b59..d1d1e5b 100644 --- a/templates/lxc-download.in +++ b/templates/lxc-download.in @@ -35,6 +35,7 @@ DOWNLOAD_KEYID="0xBAEFF88C22F6E216" DOWNLOAD_KEYSERVER="pool.sks-keyservers.net" DOWNLOAD_VALIDATE="true" DOWNLOAD_FLUSH_CACHE="false" +DOWNLOAD_FORCE_CACHE="false" DOWNLOAD_MODE="system" DOWNLOAD_USE_CACHE="false" DOWNLOAD_URL= -- 1.8.5.2 ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] b02274: lxccontainer.c: check lxc_conf before referance ha...
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: b022744452e07085a6b0fd1d110fee77263a2581 https://github.com/lxc/lxc/commit/b022744452e07085a6b0fd1d110fee77263a2581 Author: Qiang Huang Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M src/lxc/lxccontainer.c Log Message: --- lxccontainer.c: check lxc_conf before referance haltsignal If we start container with rcfile(see comments in lxc_start.c), it is possible that we have no config file in /usr/local/var/lib/lxc. So when we try lxc_stop, lxc_container_new will not load any config so we'll get c->lxc_conf = NULL. In that case, we'll get Segmentation fault in lxcapi_shutdown, a simple check would fix this. Signed-off-by: Qiang Huang Acked-by: Stéphane Graber ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] lxccontainer.c: check lxc_conf before referance haltsignal
On Wed, Jan 15, 2014 at 10:45:18AM +0800, Qiang Huang wrote: > If we start container with rcfile(see comments in lxc_start.c), it > is possible that we have no config file in /usr/local/var/lib/lxc. > So when we try lxc_stop, lxc_container_new will not load any config > so we'll get c->lxc_conf = NULL. > > In that case, we'll get Segmentation fault in lxcapi_shutdown, a > simple check would fix this. > > Signed-off-by: Qiang Huang Good catch. Acked-by: Stéphane Graber > --- > src/lxc/lxccontainer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c > index 8462ba5..0bebdff 100644 > --- a/src/lxc/lxccontainer.c > +++ b/src/lxc/lxccontainer.c > @@ -1313,7 +1313,7 @@ static bool lxcapi_shutdown(struct lxc_container *c, > int timeout) > pid = c->init_pid(c); > if (pid <= 0) > return true; > - if (c->lxc_conf->haltsignal) > + if (c->lxc_conf && c->lxc_conf->haltsignal) > haltsignal = c->lxc_conf->haltsignal; > kill(pid, haltsignal); > retv = c->wait(c, "STOPPED", timeout); > -- > 1.8.3 > -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: Digital signature ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] Last minute template addition - universal image based template
On Tue, Jan 14, 2014 at 09:48:13PM -0500, Stéphane Graber wrote: > On Tue, Jan 14, 2014 at 09:30:50PM -0500, S.Çağlar Onur wrote: > > On Tue, Jan 14, 2014 at 9:24 PM, Stéphane Graber > > wrote: > > > On Tue, Jan 14, 2014 at 09:12:31PM -0500, S.Çağlar Onur wrote: > > >> Hey Stéphane, > > >> > > >> On Tue, Jan 14, 2014 at 6:52 PM, Stéphane Graber > > >> wrote: > > >> > On Tue, Jan 14, 2014 at 06:38:43PM -0500, Dwight Engen wrote: > > >> >> On Mon, 13 Jan 2014 20:56:23 -0500 > > >> >> Stéphane Graber wrote: > > >> >> > > >> >> [...] > > >> >> > > > >> >> > Yeah, I did a few last-minute changes. > > >> >> > > > >> >> > fstab is no longer required (only copied over if it's there). > > >> >> > > > >> >> > If the expiry file is messing, it's simply assumed that the > > >> >> > container > > >> >> > won't expire. > > >> >> > > >> >> Nice, that makes sense. > > >> >> > > >> >> [...] > > >> >> > Now for Oracle, I guess it depends what's most useful for your > > >> >> > users. > > >> >> > > > >> >> > Is there actually still a demand for 4.x? I thought at least RHEL > > >> >> > 4.x > > >> >> > went out of support last year. > > >> >> > > > >> >> > In any case, I suspect that starting with the latest of each > > >> >> > supported > > >> >> > release on i386 and amd64 is probably a good start. > > >> >> > We can then expand that to include popular minor releases, possibly > > >> >> > the last few 6.x? > > >> >> > > >> >> Yeah I think it makes sense to start with just x86_64 6.latest, and > > >> >> we'll see how it goes from there. > > >> >> > > >> >> > > One question I have on this is that the rootfs (at least that the > > >> >> > > Oracle template makes, not sure about others) isn't quite right > > >> >> > > since the host name will have already been injected into config > > >> >> > > files (for example /etc/hosts), but lxc-download wants to template > > >> >> > > them itself. Should we add a switch to the distro template so it > > >> >> > > knows when its being called to create a rootfs for lxc-download to > > >> >> > > put LXC_NAME in there instead the --name it was passed? > > >> >> > > > >> >> > So currently my build script (Jenkins job) will call the template > > >> >> > with: > > >> >> > - --rootfs=/build-lxc/container/LXC_NAME/rootfs > > >> >> > - --path=/build-lxc/container/LXC_NAME > > >> >> > - --name=LXC_NAME > > >> >> > > >> >> Oh yeah, doh! Clever, that should make it work fine. > > >> >> > > >> >> [...] > > >> >> > > I have not tried from a normal user account yet. Is it basically > > >> >> > > that you expect the template to be run by a normal user, but be > > >> >> > > running in a userns? Can you describe how mapped_uid is supposed > > >> >> > > to > > >> >> > > be set? Thanks! > > >> >> > -d oracle -r 6.5 -a x86_64 --server phocis/lxc-images --no-validate > > >> >> > Yeah, lxc-create basically does all the magic we need there. > > >> >> > When run as a user, it'll run the template in a userns mapped with > > >> >> > the > > >> >> > container's range. > > >> >> > > > >> >> > $mapped_uid appears to be set to the uid in the userns which maps > > >> >> > back > > >> >> > to the user's own uid outside of it and makes it possible to chown > > >> >> > files back to the actual user. > > >> >> > > >> >> So I had to dig into the source to see how I could get this to work, > > >> >> and tried passing a line like: > > >> >> > > >> >> lxc-create -P /home/dengen/ct -f /home/dengen/ct/dengen_id_map.conf > > >> >> -n ol65 -t download -- -d oracle -r 6.5 -a x86_64 --server > > >> >> lxchttp/lxc-images --no-validate > > >> >> > > >> >> where /home/dengen/ct/dengen_id_map.conf just has: > > >> >> lxc.id_map = u 0 10 1 > > >> >> lxc.id_map = g 0 10 1 > > >> >> > > >> >> in order to get mapped_uid in lxc-create to kick in. Sadly this didn't > > >> >> work because lxc.spec is still installing lxc-create (and a lot more) > > >> >> setuid, so the geteuid() check in create_run_template() isn't firing. > > >> >> So my question is: which lxc binaries are supposed to be installed > > >> >> setuid these days? Is it just lxc-user-nic? Once I know, I can go > > >> >> ahead > > >> >> and fixup lxc.spec. Thanks. > > >> > > > >> > Oh, wow, I didn't realize some distros were still installing anything > > >> > setuid these days, especially after we drop lxc-setuid and lxc-setcap > > >> > from the upstream tree. > > >> > > > >> > So anyway, nowadays, the recommendation is for only lxc-user-nic to be > > >> > setuid, everything else should always run as the user. When run as > > >> > root, > > >> > you'll end up with system containers, when run as a user, you'll get an > > >> > unprivileged container. > > >> > > >> Should I expect [1] to work on saucy with trusty kernel? Here is what > > >> I'm getting > > >> > > >> [caglar@oOo:~] ./unprivileged.sh > > >> Creating unpriv with dir > > >> Using image from local cache > > >> Unpacking the rootfs > > >> chown: invalid user: ‘-f’ > > > > > > What shell is p
[lxc-devel] [PATCH] lxc-download: Fix wrong option parsing
Signed-off-by: Stéphane Graber --- templates/lxc-download.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/templates/lxc-download.in b/templates/lxc-download.in index 04f5846..aa93b59 100644 --- a/templates/lxc-download.in +++ b/templates/lxc-download.in @@ -172,7 +172,7 @@ EOF } options=$(getopt -o d:r:a:hl -l dist:,release:,arch:,help,list,variant:,\ -server:,keyid:,no-validate,flush-cache,force-cache:,name:,path:,\ +server:,keyid:,no-validate,flush-cache,force-cache,name:,path:,\ rootfs:,mapped-uid: -- "$@") if [ $? -ne 0 ]; then -- 1.8.5.2 ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] Last minute template addition - universal image based template
On Tue, Jan 14, 2014 at 09:30:50PM -0500, S.Çağlar Onur wrote: > On Tue, Jan 14, 2014 at 9:24 PM, Stéphane Graber wrote: > > On Tue, Jan 14, 2014 at 09:12:31PM -0500, S.Çağlar Onur wrote: > >> Hey Stéphane, > >> > >> On Tue, Jan 14, 2014 at 6:52 PM, Stéphane Graber > >> wrote: > >> > On Tue, Jan 14, 2014 at 06:38:43PM -0500, Dwight Engen wrote: > >> >> On Mon, 13 Jan 2014 20:56:23 -0500 > >> >> Stéphane Graber wrote: > >> >> > >> >> [...] > >> >> > > >> >> > Yeah, I did a few last-minute changes. > >> >> > > >> >> > fstab is no longer required (only copied over if it's there). > >> >> > > >> >> > If the expiry file is messing, it's simply assumed that the container > >> >> > won't expire. > >> >> > >> >> Nice, that makes sense. > >> >> > >> >> [...] > >> >> > Now for Oracle, I guess it depends what's most useful for your users. > >> >> > > >> >> > Is there actually still a demand for 4.x? I thought at least RHEL 4.x > >> >> > went out of support last year. > >> >> > > >> >> > In any case, I suspect that starting with the latest of each supported > >> >> > release on i386 and amd64 is probably a good start. > >> >> > We can then expand that to include popular minor releases, possibly > >> >> > the last few 6.x? > >> >> > >> >> Yeah I think it makes sense to start with just x86_64 6.latest, and > >> >> we'll see how it goes from there. > >> >> > >> >> > > One question I have on this is that the rootfs (at least that the > >> >> > > Oracle template makes, not sure about others) isn't quite right > >> >> > > since the host name will have already been injected into config > >> >> > > files (for example /etc/hosts), but lxc-download wants to template > >> >> > > them itself. Should we add a switch to the distro template so it > >> >> > > knows when its being called to create a rootfs for lxc-download to > >> >> > > put LXC_NAME in there instead the --name it was passed? > >> >> > > >> >> > So currently my build script (Jenkins job) will call the template > >> >> > with: > >> >> > - --rootfs=/build-lxc/container/LXC_NAME/rootfs > >> >> > - --path=/build-lxc/container/LXC_NAME > >> >> > - --name=LXC_NAME > >> >> > >> >> Oh yeah, doh! Clever, that should make it work fine. > >> >> > >> >> [...] > >> >> > > I have not tried from a normal user account yet. Is it basically > >> >> > > that you expect the template to be run by a normal user, but be > >> >> > > running in a userns? Can you describe how mapped_uid is supposed to > >> >> > > be set? Thanks! > >> >> > -d oracle -r 6.5 -a x86_64 --server phocis/lxc-images --no-validate > >> >> > Yeah, lxc-create basically does all the magic we need there. > >> >> > When run as a user, it'll run the template in a userns mapped with the > >> >> > container's range. > >> >> > > >> >> > $mapped_uid appears to be set to the uid in the userns which maps back > >> >> > to the user's own uid outside of it and makes it possible to chown > >> >> > files back to the actual user. > >> >> > >> >> So I had to dig into the source to see how I could get this to work, > >> >> and tried passing a line like: > >> >> > >> >> lxc-create -P /home/dengen/ct -f /home/dengen/ct/dengen_id_map.conf -n > >> >> ol65 -t download -- -d oracle -r 6.5 -a x86_64 --server > >> >> lxchttp/lxc-images --no-validate > >> >> > >> >> where /home/dengen/ct/dengen_id_map.conf just has: > >> >> lxc.id_map = u 0 10 1 > >> >> lxc.id_map = g 0 10 1 > >> >> > >> >> in order to get mapped_uid in lxc-create to kick in. Sadly this didn't > >> >> work because lxc.spec is still installing lxc-create (and a lot more) > >> >> setuid, so the geteuid() check in create_run_template() isn't firing. > >> >> So my question is: which lxc binaries are supposed to be installed > >> >> setuid these days? Is it just lxc-user-nic? Once I know, I can go ahead > >> >> and fixup lxc.spec. Thanks. > >> > > >> > Oh, wow, I didn't realize some distros were still installing anything > >> > setuid these days, especially after we drop lxc-setuid and lxc-setcap > >> > from the upstream tree. > >> > > >> > So anyway, nowadays, the recommendation is for only lxc-user-nic to be > >> > setuid, everything else should always run as the user. When run as root, > >> > you'll end up with system containers, when run as a user, you'll get an > >> > unprivileged container. > >> > >> Should I expect [1] to work on saucy with trusty kernel? Here is what > >> I'm getting > >> > >> [caglar@oOo:~] ./unprivileged.sh > >> Creating unpriv with dir > >> Using image from local cache > >> Unpacking the rootfs > >> chown: invalid user: ‘-f’ > > > > What shell is providing /bin/sh on your system? > > > > I confirmed that chown had a -f argument on both busybox, dash and bash, > > but apparently you're using something else. > > > > Anyway, I'll fix that particular failure by using a good old || true then. > > I'm using bash but I think problem is not the -f parameter but wrong > LXC_MAPPED_UID value. Well, turns out -f isn't in POSIX so I sent a
[lxc-devel] [PATCH] lxccontainer.c: check lxc_conf before referance haltsignal
If we start container with rcfile(see comments in lxc_start.c), it is possible that we have no config file in /usr/local/var/lib/lxc. So when we try lxc_stop, lxc_container_new will not load any config so we'll get c->lxc_conf = NULL. In that case, we'll get Segmentation fault in lxcapi_shutdown, a simple check would fix this. Signed-off-by: Qiang Huang --- src/lxc/lxccontainer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c index 8462ba5..0bebdff 100644 --- a/src/lxc/lxccontainer.c +++ b/src/lxc/lxccontainer.c @@ -1313,7 +1313,7 @@ static bool lxcapi_shutdown(struct lxc_container *c, int timeout) pid = c->init_pid(c); if (pid <= 0) return true; - if (c->lxc_conf->haltsignal) + if (c->lxc_conf && c->lxc_conf->haltsignal) haltsignal = c->lxc_conf->haltsignal; kill(pid, haltsignal); retv = c->wait(c, "STOPPED", timeout); -- 1.8.3 ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH] lxc-download: POSIX doesn't specify -f for chown
Signed-off-by: Stéphane Graber --- templates/lxc-download.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/templates/lxc-download.in b/templates/lxc-download.in index c318041..04f5846 100644 --- a/templates/lxc-download.in +++ b/templates/lxc-download.in @@ -396,7 +396,7 @@ if [ "$DOWNLOAD_USE_CACHE" = "false" ]; then echo $DOWNLOAD_BUILD > $LXC_CACHE_PATH/build_id if [ -n "$LXC_MAPPED_UID" ] && [ "$LXC_MAPPED_UID" != "-1" ]; then -chown $LXC_MAPPED_UID -Rf $LXC_CACHE_BASE >/dev/null 2>&1 || true +chown $LXC_MAPPED_UID -R $LXC_CACHE_BASE >/dev/null 2>&1 || true fi echo "The image cache is now ready" fi @@ -489,7 +489,7 @@ for file in $TEMPLATE_FILES; do done if [ -n "$LXC_MAPPED_UID" ] && [ "$LXC_MAPPED_UID" != "-1" ]; then -chown $LXC_MAPPED_UID -f $LXC_PATH/config $LXC_PATH/fstab || true +chown $LXC_MAPPED_UID $LXC_PATH/config $LXC_PATH/fstab >/dev/null 2>&1 || true fi if [ -e "$(relevant_file create-message)" ]; then -- 1.8.5.2 ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] Last minute template addition - universal image based template
On Tue, Jan 14, 2014 at 9:24 PM, Stéphane Graber wrote: > On Tue, Jan 14, 2014 at 09:12:31PM -0500, S.Çağlar Onur wrote: >> Hey Stéphane, >> >> On Tue, Jan 14, 2014 at 6:52 PM, Stéphane Graber wrote: >> > On Tue, Jan 14, 2014 at 06:38:43PM -0500, Dwight Engen wrote: >> >> On Mon, 13 Jan 2014 20:56:23 -0500 >> >> Stéphane Graber wrote: >> >> >> >> [...] >> >> > >> >> > Yeah, I did a few last-minute changes. >> >> > >> >> > fstab is no longer required (only copied over if it's there). >> >> > >> >> > If the expiry file is messing, it's simply assumed that the container >> >> > won't expire. >> >> >> >> Nice, that makes sense. >> >> >> >> [...] >> >> > Now for Oracle, I guess it depends what's most useful for your users. >> >> > >> >> > Is there actually still a demand for 4.x? I thought at least RHEL 4.x >> >> > went out of support last year. >> >> > >> >> > In any case, I suspect that starting with the latest of each supported >> >> > release on i386 and amd64 is probably a good start. >> >> > We can then expand that to include popular minor releases, possibly >> >> > the last few 6.x? >> >> >> >> Yeah I think it makes sense to start with just x86_64 6.latest, and >> >> we'll see how it goes from there. >> >> >> >> > > One question I have on this is that the rootfs (at least that the >> >> > > Oracle template makes, not sure about others) isn't quite right >> >> > > since the host name will have already been injected into config >> >> > > files (for example /etc/hosts), but lxc-download wants to template >> >> > > them itself. Should we add a switch to the distro template so it >> >> > > knows when its being called to create a rootfs for lxc-download to >> >> > > put LXC_NAME in there instead the --name it was passed? >> >> > >> >> > So currently my build script (Jenkins job) will call the template >> >> > with: >> >> > - --rootfs=/build-lxc/container/LXC_NAME/rootfs >> >> > - --path=/build-lxc/container/LXC_NAME >> >> > - --name=LXC_NAME >> >> >> >> Oh yeah, doh! Clever, that should make it work fine. >> >> >> >> [...] >> >> > > I have not tried from a normal user account yet. Is it basically >> >> > > that you expect the template to be run by a normal user, but be >> >> > > running in a userns? Can you describe how mapped_uid is supposed to >> >> > > be set? Thanks! >> >> > -d oracle -r 6.5 -a x86_64 --server phocis/lxc-images --no-validate >> >> > Yeah, lxc-create basically does all the magic we need there. >> >> > When run as a user, it'll run the template in a userns mapped with the >> >> > container's range. >> >> > >> >> > $mapped_uid appears to be set to the uid in the userns which maps back >> >> > to the user's own uid outside of it and makes it possible to chown >> >> > files back to the actual user. >> >> >> >> So I had to dig into the source to see how I could get this to work, >> >> and tried passing a line like: >> >> >> >> lxc-create -P /home/dengen/ct -f /home/dengen/ct/dengen_id_map.conf -n >> >> ol65 -t download -- -d oracle -r 6.5 -a x86_64 --server >> >> lxchttp/lxc-images --no-validate >> >> >> >> where /home/dengen/ct/dengen_id_map.conf just has: >> >> lxc.id_map = u 0 10 1 >> >> lxc.id_map = g 0 10 1 >> >> >> >> in order to get mapped_uid in lxc-create to kick in. Sadly this didn't >> >> work because lxc.spec is still installing lxc-create (and a lot more) >> >> setuid, so the geteuid() check in create_run_template() isn't firing. >> >> So my question is: which lxc binaries are supposed to be installed >> >> setuid these days? Is it just lxc-user-nic? Once I know, I can go ahead >> >> and fixup lxc.spec. Thanks. >> > >> > Oh, wow, I didn't realize some distros were still installing anything >> > setuid these days, especially after we drop lxc-setuid and lxc-setcap >> > from the upstream tree. >> > >> > So anyway, nowadays, the recommendation is for only lxc-user-nic to be >> > setuid, everything else should always run as the user. When run as root, >> > you'll end up with system containers, when run as a user, you'll get an >> > unprivileged container. >> >> Should I expect [1] to work on saucy with trusty kernel? Here is what >> I'm getting >> >> [caglar@oOo:~] ./unprivileged.sh >> Creating unpriv with dir >> Using image from local cache >> Unpacking the rootfs >> chown: invalid user: ‘-f’ > > What shell is providing /bin/sh on your system? > > I confirmed that chown had a -f argument on both busybox, dash and bash, > but apparently you're using something else. > > Anyway, I'll fix that particular failure by using a good old || true then. I'm using bash but I think problem is not the -f parameter but wrong LXC_MAPPED_UID value. Printing the LXC_MAPPED_UID via if [ -n "$LXC_MAPPED_UID" ] && [ "$LXC_MAPPED_UID" != "-1" ]; then echo "***" $LXC_MAPPED_UID "***" chown $LXC_MAPPED_UID -f $LXC_PATH/config $LXC_PATH/fstab || true fi shows this [caglar@oOo:~] ./unprivileged.sh Creating unpriv with dir Using image from local cache Unpacking the rootfs **
Re: [lxc-devel] Last minute template addition - universal image based template
On Tue, Jan 14, 2014 at 09:12:31PM -0500, S.Çağlar Onur wrote: > Hey Stéphane, > > On Tue, Jan 14, 2014 at 6:52 PM, Stéphane Graber wrote: > > On Tue, Jan 14, 2014 at 06:38:43PM -0500, Dwight Engen wrote: > >> On Mon, 13 Jan 2014 20:56:23 -0500 > >> Stéphane Graber wrote: > >> > >> [...] > >> > > >> > Yeah, I did a few last-minute changes. > >> > > >> > fstab is no longer required (only copied over if it's there). > >> > > >> > If the expiry file is messing, it's simply assumed that the container > >> > won't expire. > >> > >> Nice, that makes sense. > >> > >> [...] > >> > Now for Oracle, I guess it depends what's most useful for your users. > >> > > >> > Is there actually still a demand for 4.x? I thought at least RHEL 4.x > >> > went out of support last year. > >> > > >> > In any case, I suspect that starting with the latest of each supported > >> > release on i386 and amd64 is probably a good start. > >> > We can then expand that to include popular minor releases, possibly > >> > the last few 6.x? > >> > >> Yeah I think it makes sense to start with just x86_64 6.latest, and > >> we'll see how it goes from there. > >> > >> > > One question I have on this is that the rootfs (at least that the > >> > > Oracle template makes, not sure about others) isn't quite right > >> > > since the host name will have already been injected into config > >> > > files (for example /etc/hosts), but lxc-download wants to template > >> > > them itself. Should we add a switch to the distro template so it > >> > > knows when its being called to create a rootfs for lxc-download to > >> > > put LXC_NAME in there instead the --name it was passed? > >> > > >> > So currently my build script (Jenkins job) will call the template > >> > with: > >> > - --rootfs=/build-lxc/container/LXC_NAME/rootfs > >> > - --path=/build-lxc/container/LXC_NAME > >> > - --name=LXC_NAME > >> > >> Oh yeah, doh! Clever, that should make it work fine. > >> > >> [...] > >> > > I have not tried from a normal user account yet. Is it basically > >> > > that you expect the template to be run by a normal user, but be > >> > > running in a userns? Can you describe how mapped_uid is supposed to > >> > > be set? Thanks! > >> > -d oracle -r 6.5 -a x86_64 --server phocis/lxc-images --no-validate > >> > Yeah, lxc-create basically does all the magic we need there. > >> > When run as a user, it'll run the template in a userns mapped with the > >> > container's range. > >> > > >> > $mapped_uid appears to be set to the uid in the userns which maps back > >> > to the user's own uid outside of it and makes it possible to chown > >> > files back to the actual user. > >> > >> So I had to dig into the source to see how I could get this to work, > >> and tried passing a line like: > >> > >> lxc-create -P /home/dengen/ct -f /home/dengen/ct/dengen_id_map.conf -n > >> ol65 -t download -- -d oracle -r 6.5 -a x86_64 --server lxchttp/lxc-images > >> --no-validate > >> > >> where /home/dengen/ct/dengen_id_map.conf just has: > >> lxc.id_map = u 0 10 1 > >> lxc.id_map = g 0 10 1 > >> > >> in order to get mapped_uid in lxc-create to kick in. Sadly this didn't > >> work because lxc.spec is still installing lxc-create (and a lot more) > >> setuid, so the geteuid() check in create_run_template() isn't firing. > >> So my question is: which lxc binaries are supposed to be installed > >> setuid these days? Is it just lxc-user-nic? Once I know, I can go ahead > >> and fixup lxc.spec. Thanks. > > > > Oh, wow, I didn't realize some distros were still installing anything > > setuid these days, especially after we drop lxc-setuid and lxc-setcap > > from the upstream tree. > > > > So anyway, nowadays, the recommendation is for only lxc-user-nic to be > > setuid, everything else should always run as the user. When run as root, > > you'll end up with system containers, when run as a user, you'll get an > > unprivileged container. > > Should I expect [1] to work on saucy with trusty kernel? Here is what > I'm getting > > [caglar@oOo:~] ./unprivileged.sh > Creating unpriv with dir > Using image from local cache > Unpacking the rootfs > chown: invalid user: ‘-f’ What shell is providing /bin/sh on your system? I confirmed that chown had a -f argument on both busybox, dash and bash, but apparently you're using something else. Anyway, I'll fix that particular failure by using a good old || true then. > > --- > You just created an Ubuntu container (release=saucy, arch=amd64). > The default username/password is: ubuntu / ubuntu > To gain root privileges, please use sudo. > Starting/Attaching/Stopping to unpriv > lxc-start: command get_cgroup failed to receive response > lxc-attach: failed to get the init pid > unpriv is not running > Destroying unpriv The rest of the failure is coming from you not having the proper cgroupfs setup. Try something like: for controller in /sys/fs/cgroup; do sudo mkdir -p $controller/$USER/lxc sudo chown -R $USER $controller/$USER echo $
Re: [lxc-devel] Last minute template addition - universal image based template
Hey Stéphane, On Tue, Jan 14, 2014 at 6:52 PM, Stéphane Graber wrote: > On Tue, Jan 14, 2014 at 06:38:43PM -0500, Dwight Engen wrote: >> On Mon, 13 Jan 2014 20:56:23 -0500 >> Stéphane Graber wrote: >> >> [...] >> > >> > Yeah, I did a few last-minute changes. >> > >> > fstab is no longer required (only copied over if it's there). >> > >> > If the expiry file is messing, it's simply assumed that the container >> > won't expire. >> >> Nice, that makes sense. >> >> [...] >> > Now for Oracle, I guess it depends what's most useful for your users. >> > >> > Is there actually still a demand for 4.x? I thought at least RHEL 4.x >> > went out of support last year. >> > >> > In any case, I suspect that starting with the latest of each supported >> > release on i386 and amd64 is probably a good start. >> > We can then expand that to include popular minor releases, possibly >> > the last few 6.x? >> >> Yeah I think it makes sense to start with just x86_64 6.latest, and >> we'll see how it goes from there. >> >> > > One question I have on this is that the rootfs (at least that the >> > > Oracle template makes, not sure about others) isn't quite right >> > > since the host name will have already been injected into config >> > > files (for example /etc/hosts), but lxc-download wants to template >> > > them itself. Should we add a switch to the distro template so it >> > > knows when its being called to create a rootfs for lxc-download to >> > > put LXC_NAME in there instead the --name it was passed? >> > >> > So currently my build script (Jenkins job) will call the template >> > with: >> > - --rootfs=/build-lxc/container/LXC_NAME/rootfs >> > - --path=/build-lxc/container/LXC_NAME >> > - --name=LXC_NAME >> >> Oh yeah, doh! Clever, that should make it work fine. >> >> [...] >> > > I have not tried from a normal user account yet. Is it basically >> > > that you expect the template to be run by a normal user, but be >> > > running in a userns? Can you describe how mapped_uid is supposed to >> > > be set? Thanks! >> > -d oracle -r 6.5 -a x86_64 --server phocis/lxc-images --no-validate >> > Yeah, lxc-create basically does all the magic we need there. >> > When run as a user, it'll run the template in a userns mapped with the >> > container's range. >> > >> > $mapped_uid appears to be set to the uid in the userns which maps back >> > to the user's own uid outside of it and makes it possible to chown >> > files back to the actual user. >> >> So I had to dig into the source to see how I could get this to work, >> and tried passing a line like: >> >> lxc-create -P /home/dengen/ct -f /home/dengen/ct/dengen_id_map.conf -n ol65 >> -t download -- -d oracle -r 6.5 -a x86_64 --server lxchttp/lxc-images >> --no-validate >> >> where /home/dengen/ct/dengen_id_map.conf just has: >> lxc.id_map = u 0 10 1 >> lxc.id_map = g 0 10 1 >> >> in order to get mapped_uid in lxc-create to kick in. Sadly this didn't >> work because lxc.spec is still installing lxc-create (and a lot more) >> setuid, so the geteuid() check in create_run_template() isn't firing. >> So my question is: which lxc binaries are supposed to be installed >> setuid these days? Is it just lxc-user-nic? Once I know, I can go ahead >> and fixup lxc.spec. Thanks. > > Oh, wow, I didn't realize some distros were still installing anything > setuid these days, especially after we drop lxc-setuid and lxc-setcap > from the upstream tree. > > So anyway, nowadays, the recommendation is for only lxc-user-nic to be > setuid, everything else should always run as the user. When run as root, > you'll end up with system containers, when run as a user, you'll get an > unprivileged container. Should I expect [1] to work on saucy with trusty kernel? Here is what I'm getting [caglar@oOo:~] ./unprivileged.sh Creating unpriv with dir Using image from local cache Unpacking the rootfs chown: invalid user: ‘-f’ --- You just created an Ubuntu container (release=saucy, arch=amd64). The default username/password is: ubuntu / ubuntu To gain root privileges, please use sudo. Starting/Attaching/Stopping to unpriv lxc-start: command get_cgroup failed to receive response lxc-attach: failed to get the init pid unpriv is not running Destroying unpriv [caglar@oOo:~] grep ERROR unpriv.log lxc-start 1389751901.034 ERRORlxc_cgroup - Permission denied - Could not create cgroup /unpriv lxc-start 1389751901.034 ERRORlxc_cgroup - Permission denied - cgroup_rmdir: failed to delete /sys/fs/cgroup/hugetlb//lxc lxc-start 1389751901.035 ERRORlxc_cgroup - Permission denied - cgroup_rmdir: failed to delete /sys/fs/cgroup/hugetlb/ lxc-start 1389751901.035 ERRORlxc_cgroup - Permission denied - cgroup_rmdir: failed to delete /sys/fs/cgroup/perf_event//lxc lxc-start 1389751901.035 ERRORlxc_cgroup - Permission denied - cgroup_rmdir: failed to delete /sys/fs/cgroup/perf_event/ lxc-start 1389751901.035 ERRORlxc_cgroup - Permission denied - cgroup_rmdi
Re: [lxc-devel] Last minute template addition - universal image based template
On Tue, Jan 14, 2014 at 06:38:43PM -0500, Dwight Engen wrote: > On Mon, 13 Jan 2014 20:56:23 -0500 > Stéphane Graber wrote: > > [...] > > > > Yeah, I did a few last-minute changes. > > > > fstab is no longer required (only copied over if it's there). > > > > If the expiry file is messing, it's simply assumed that the container > > won't expire. > > Nice, that makes sense. > > [...] > > Now for Oracle, I guess it depends what's most useful for your users. > > > > Is there actually still a demand for 4.x? I thought at least RHEL 4.x > > went out of support last year. > > > > In any case, I suspect that starting with the latest of each supported > > release on i386 and amd64 is probably a good start. > > We can then expand that to include popular minor releases, possibly > > the last few 6.x? > > Yeah I think it makes sense to start with just x86_64 6.latest, and > we'll see how it goes from there. > > > > One question I have on this is that the rootfs (at least that the > > > Oracle template makes, not sure about others) isn't quite right > > > since the host name will have already been injected into config > > > files (for example /etc/hosts), but lxc-download wants to template > > > them itself. Should we add a switch to the distro template so it > > > knows when its being called to create a rootfs for lxc-download to > > > put LXC_NAME in there instead the --name it was passed? > > > > So currently my build script (Jenkins job) will call the template > > with: > > - --rootfs=/build-lxc/container/LXC_NAME/rootfs > > - --path=/build-lxc/container/LXC_NAME > > - --name=LXC_NAME > > Oh yeah, doh! Clever, that should make it work fine. > > [...] > > > I have not tried from a normal user account yet. Is it basically > > > that you expect the template to be run by a normal user, but be > > > running in a userns? Can you describe how mapped_uid is supposed to > > > be set? Thanks! > > -d oracle -r 6.5 -a x86_64 --server phocis/lxc-images --no-validate > > Yeah, lxc-create basically does all the magic we need there. > > When run as a user, it'll run the template in a userns mapped with the > > container's range. > > > > $mapped_uid appears to be set to the uid in the userns which maps back > > to the user's own uid outside of it and makes it possible to chown > > files back to the actual user. > > So I had to dig into the source to see how I could get this to work, > and tried passing a line like: > > lxc-create -P /home/dengen/ct -f /home/dengen/ct/dengen_id_map.conf -n ol65 > -t download -- -d oracle -r 6.5 -a x86_64 --server lxchttp/lxc-images > --no-validate > > where /home/dengen/ct/dengen_id_map.conf just has: > lxc.id_map = u 0 10 1 > lxc.id_map = g 0 10 1 > > in order to get mapped_uid in lxc-create to kick in. Sadly this didn't > work because lxc.spec is still installing lxc-create (and a lot more) > setuid, so the geteuid() check in create_run_template() isn't firing. > So my question is: which lxc binaries are supposed to be installed > setuid these days? Is it just lxc-user-nic? Once I know, I can go ahead > and fixup lxc.spec. Thanks. Oh, wow, I didn't realize some distros were still installing anything setuid these days, especially after we drop lxc-setuid and lxc-setcap from the upstream tree. So anyway, nowadays, the recommendation is for only lxc-user-nic to be setuid, everything else should always run as the user. When run as root, you'll end up with system containers, when run as a user, you'll get an unprivileged container. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: Digital signature ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] Last minute template addition - universal image based template
On Mon, 13 Jan 2014 20:56:23 -0500 Stéphane Graber wrote: [...] > > Yeah, I did a few last-minute changes. > > fstab is no longer required (only copied over if it's there). > > If the expiry file is messing, it's simply assumed that the container > won't expire. Nice, that makes sense. [...] > Now for Oracle, I guess it depends what's most useful for your users. > > Is there actually still a demand for 4.x? I thought at least RHEL 4.x > went out of support last year. > > In any case, I suspect that starting with the latest of each supported > release on i386 and amd64 is probably a good start. > We can then expand that to include popular minor releases, possibly > the last few 6.x? Yeah I think it makes sense to start with just x86_64 6.latest, and we'll see how it goes from there. > > One question I have on this is that the rootfs (at least that the > > Oracle template makes, not sure about others) isn't quite right > > since the host name will have already been injected into config > > files (for example /etc/hosts), but lxc-download wants to template > > them itself. Should we add a switch to the distro template so it > > knows when its being called to create a rootfs for lxc-download to > > put LXC_NAME in there instead the --name it was passed? > > So currently my build script (Jenkins job) will call the template > with: > - --rootfs=/build-lxc/container/LXC_NAME/rootfs > - --path=/build-lxc/container/LXC_NAME > - --name=LXC_NAME Oh yeah, doh! Clever, that should make it work fine. [...] > > I have not tried from a normal user account yet. Is it basically > > that you expect the template to be run by a normal user, but be > > running in a userns? Can you describe how mapped_uid is supposed to > > be set? Thanks! > -d oracle -r 6.5 -a x86_64 --server phocis/lxc-images --no-validate > Yeah, lxc-create basically does all the magic we need there. > When run as a user, it'll run the template in a userns mapped with the > container's range. > > $mapped_uid appears to be set to the uid in the userns which maps back > to the user's own uid outside of it and makes it possible to chown > files back to the actual user. So I had to dig into the source to see how I could get this to work, and tried passing a line like: lxc-create -P /home/dengen/ct -f /home/dengen/ct/dengen_id_map.conf -n ol65 -t download -- -d oracle -r 6.5 -a x86_64 --server lxchttp/lxc-images --no-validate where /home/dengen/ct/dengen_id_map.conf just has: lxc.id_map = u 0 10 1 lxc.id_map = g 0 10 1 in order to get mapped_uid in lxc-create to kick in. Sadly this didn't work because lxc.spec is still installing lxc-create (and a lot more) setuid, so the geteuid() check in create_run_template() isn't firing. So my question is: which lxc binaries are supposed to be installed setuid these days? Is it just lxc-user-nic? Once I know, I can go ahead and fixup lxc.spec. Thanks. ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 3139ae: Fix return value of userns_exec_1
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 3139aead4d5e91147ae6dfc1ac3ef516bcde7222 https://github.com/lxc/lxc/commit/3139aead4d5e91147ae6dfc1ac3ef516bcde7222 Author: Stéphane Graber Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M src/lxc/conf.c Log Message: --- Fix return value of userns_exec_1 Instead of always returning -1 and call SYSERROR when the child returns non-zero. Have userns_exec_1 always return the return value from the function it's calling and let the caller do the error handling (as is already done by its only caller). Signed-off-by: Stéphane Graber Acked-by: Serge E. Hallyn ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Fix return value of userns_exec_1
Quoting Stéphane Graber (stgra...@ubuntu.com):
> Instead of always returning -1 and call SYSERROR when the child returns
> non-zero. Have userns_exec_1 always return the return value from the
> function it's calling and let the caller do the error handling (as is
> already done by its only caller).
>
> Signed-off-by: Stéphane Graber
Acked-by: Serge E. Hallyn
> ---
> src/lxc/conf.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/src/lxc/conf.c b/src/lxc/conf.c
> index 7e0eddd..159684c 100644
> --- a/src/lxc/conf.c
> +++ b/src/lxc/conf.c
> @@ -4054,10 +4054,11 @@ int userns_exec_1(struct lxc_conf *conf, int
> (*fn)(void *), void *data)
> goto err;
> }
>
> - if ((ret = wait_for_pid(pid)) < 0) {
> - ERROR("Child returned an error: %d\n", ret);
> - goto err;
> - }
> + ret = wait_for_pid(pid);
> +
> + close(p[1]);
> + return ret;
> +
> err:
> if (p[0] != -1)
> close(p[0]);
> --
> 1.8.5.2
>
> ___
> 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
[lxc-devel] [PATCH] Fix return value of userns_exec_1
Instead of always returning -1 and call SYSERROR when the child returns
non-zero. Have userns_exec_1 always return the return value from the
function it's calling and let the caller do the error handling (as is
already done by its only caller).
Signed-off-by: Stéphane Graber
---
src/lxc/conf.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 7e0eddd..159684c 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -4054,10 +4054,11 @@ int userns_exec_1(struct lxc_conf *conf, int (*fn)(void
*), void *data)
goto err;
}
- if ((ret = wait_for_pid(pid)) < 0) {
- ERROR("Child returned an error: %d\n", ret);
- goto err;
- }
+ ret = wait_for_pid(pid);
+
+ close(p[1]);
+ return ret;
+
err:
if (p[0] != -1)
close(p[0]);
--
1.8.5.2
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [Fixed] lxc/lxc#62 (master - 275a2d0)
Build Update for lxc/lxc - Build: #62 Status: Fixed Duration: 2 minutes and 59 seconds Commit: 275a2d0 (master) Author: Stéphane Graber Message: tests: Fix startone's call to want_daemonize Signed-off-by: Stéphane Graber View the changeset: https://github.com/lxc/lxc/compare/b335cf8d4b56...275a2d0bcacb View the full build log and details: https://travis-ci.org/lxc/lxc/builds/16963159 -- You can configure recipients for build notifications in your .travis.yml file. See http://about.travis-ci.org/docs/user/build-configuration ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH 1/2] debian: Support ssh host keys regeneration
Signed-off-by: Stéphane Graber --- templates/lxc-debian.in | 24 1 file changed, 24 insertions(+) diff --git a/templates/lxc-debian.in b/templates/lxc-debian.in index d6f07b9..f399c0b 100644 --- a/templates/lxc-debian.in +++ b/templates/lxc-debian.in @@ -93,6 +93,30 @@ EOF chroot $rootfs /usr/sbin/update-rc.d -f hwclock.sh remove chroot $rootfs /usr/sbin/update-rc.d -f hwclockfirst.sh remove +# generate new SSH keys +if [ -x $rootfs/var/lib/dpkg/info/openssh-server.postinst ]; then +cat > $rootfs/usr/sbin/policy-rc.d << EOF +#!/bin/sh +exit 101 +EOF +chmod +x $rootfs/usr/sbin/policy-rc.d + +if [ -f $rootfs/etc/init/ssh.conf ]; then +mv $rootfs/etc/init/ssh.conf $rootfs/etc/init/ssh.conf.disabled +fi + +rm -f $rootfs/etc/ssh/ssh_host_*key* + +DPKG_MAINTSCRIPT_PACKAGE=openssh DPKG_MAINTSCRIPT_NAME=postinst chroot $rootfs /var/lib/dpkg/info/openssh-server.postinst configure +sed -i "s/root@$(hostname)/root@$hostname/g" $rootfs/etc/ssh/ssh_host_*.pub + +if [ -f "$rootfs/etc/init/ssh.conf.disabled" ]; then +mv $rootfs/etc/init/ssh.conf.disabled $rootfs/etc/init/ssh.conf +fi + +rm -f $rootfs/usr/sbin/policy-rc.d +fi + # set initial timezone as on host if [ -f /etc/timezone ]; then cat /etc/timezone > $rootfs/etc/timezone -- 1.8.5.2 ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH 2/2] ubuntu: Fix path to openssh-server's postinst
The path isn't relative to @LOCALSTATEDIR@ Signed-off-by: Stéphane Graber --- templates/lxc-ubuntu.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/templates/lxc-ubuntu.in b/templates/lxc-ubuntu.in index a707f5b..d9bb8a4 100644 --- a/templates/lxc-ubuntu.in +++ b/templates/lxc-ubuntu.in @@ -95,7 +95,7 @@ EOF fi # generate new SSH keys -if [ -x $rootfs$LOCALSTATEDIR/lib/dpkg/info/openssh-server.postinst ]; then +if [ -x $rootfs/var/lib/dpkg/info/openssh-server.postinst ]; then cat > $rootfs/usr/sbin/policy-rc.d << EOF #!/bin/sh exit 101 @@ -104,7 +104,7 @@ EOF rm -f $rootfs/etc/ssh/ssh_host_*key* mv $rootfs/etc/init/ssh.conf $rootfs/etc/init/ssh.conf.disabled -DPKG_MAINTSCRIPT_PACKAGE=openssh DPKG_MAINTSCRIPT_NAME=postinst chroot $rootfs $LOCALSTATEDIR/lib/dpkg/info/openssh-server.postinst configure +DPKG_MAINTSCRIPT_PACKAGE=openssh DPKG_MAINTSCRIPT_NAME=postinst chroot $rootfs /var/lib/dpkg/info/openssh-server.postinst configure mv $rootfs/etc/init/ssh.conf.disabled $rootfs/etc/init/ssh.conf sed -i "s/root@$(hostname)/root@$hostname/g" $rootfs/etc/ssh/ssh_host_*.pub -- 1.8.5.2 ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [Still Failing] lxc/lxc#61 (master - b335cf8)
Build Update for lxc/lxc - Build: #61 Status: Still Failing Duration: 3 minutes and 59 seconds Commit: b335cf8 (master) Author: Stéphane Graber Message: lxc-archlinux: Cleanup fstab It's been brought to my attention that the read-only mount of /proc/sys is causing problems to archlinux users, so instead just have LXC mount proc and sysfs normally (read-write). Reported-by: John Lane Signed-off-by: Stéphane Graber View the changeset: https://github.com/lxc/lxc/compare/b4f7af7a520b...b335cf8d4b56 View the full build log and details: https://travis-ci.org/lxc/lxc/builds/16962914 -- You can configure recipients for build notifications in your .travis.yml file. See http://about.travis-ci.org/docs/user/build-configuration ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] gentoo template (updated network management, master rebase)
Le 14/01/2014 23:40, Stéphane Graber a écrit : > On Tue, Jan 14, 2014 at 11:34:19PM +0100, l...@zitta.fr wrote: >> Le 14/01/2014 22:42, Stéphane Graber a écrit : >>> On Tue, Jan 14, 2014 at 12:06:26AM +0100, l...@zitta.fr wrote: Gentoo template Signed-off-by: gza >>> Hi, >>> >>> I must admit having only very briefly gone through the code as I'm not >>> familiar with Gentoo and it's a rather massive template to do a full >>> review of. >>> >>> I just noticed you're missing a .gitignore entry which I'll add and it's >>> also unfortunate that a new template isn't using the new common config >>> includes instead of hardcoding the whole config into every single >>> container, but that's something you'll obviously fix in the near future. >>> >>> >>> In the meant time: >>> Acked-by: Stéphane Graber >> Hi, I'll try to apply best practices during next days. >> >> BTW, What about common "bash functions" for templates ? >> Perhaps for Lxc 1.1 ... > It's been mentioned a few times but apparently nobody actually did that yet. > Adding a new lxc-templates.functions with standard shell functions for > template to use would make a lot of sense to me. I'll do proposals ... after 1.0 > Btw, I forgot to comment on that earlier, you say: +#I'll drink champagne the day we do templates in python +#let's do some drity bash things > Well, there's actually no reason why you couldn't have written your > template in python. It's just a coincidence that everyone so far has > been using either POSIX shell or bash for their templates. LXC simply > expects a standard set of arguments to be accepted by the template and > have it exit 1 on error and 0 on success. Yep, perhaps you're right, perhaps shell was chosen when templates where simple :) In the other hand, all we do with sed, mkdirs, chroots, etc... may be very difficult in python. Anyway, this comment should not be left and will be removed. Thanks for all. ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] lxc-destroy erased my hard disc
Quoting Dan Fandrich (d...@coneharvesters.com): > On Mon, Jan 13, 2014 at 06:23:24PM -0600, Serge Hallyn wrote: > > Gah, that really does suck, sorry. The need to run as root has always > > been annoying. We're finally at the point that some containers can be > > created and run entirely as non-root, so that your host should be a lot > > safer. > > That's definitely a positive development! > > > > This was with lxc 0.8.0 on x86 Linux (the relevant 0.9.0 code looks > > > substantially similar). It happened shortly after installing lxc for the > > > first > > > time to try it out. I believe what must have happened was that the > > > container I > > > created wasn't shut down properly and still had its bind mounts for /lib > > > etc. > > > > lxc-start would not have done any mounting in the host's mount > > namespace, so that scenario shouldn't be possible. > > > > So I would actually guess that lxc-create (actually the template) was to > > blame for leaving the bind mounts. Since it looks like you're not using > > a stock template I'm not sure how you created the container. > > That's quite possible; I'm not completely sure yet how all the lxc > moving parts fit together yet. I was using the stock busybox template, but > there were a couple of configuration problems with lxc, so it wasn't a single > perfectly clean create/start/stop. > > > > in place. The container must have been down enough to be considered not > > > running > > > according to lxc-info, so lxc-destroy helpfully rm -rf'ed it, including > > > the > > > contents of the bind mounts which pointed into my host system. > > > > > > rm was given the --one-file-system option, but it didn't prevent this from > > > occurring, presumably because the device ID of the container location was > > > the > > > same as the device ID of the /lib of the host. After looking at the > > > source to > > > lxc-destroy, I'm surprised this kind of problem doesn't happen more > > > often--it > > > > We do discourage bind-mounting from the host fs into the container, but > > historcally it was considered useful (and may again) for checkpoint/restart. > > > > > is not at all defensively written (error codes ignored, arguments not > > > properly > > > quoted, this problem I'm writing about, etc.), so I was glad to see that > > > lxc-destroy has since been reimplemented. However, on briefly looking at > > > the > > > new source, it seems that the same problem can still occur. There's a > > > comparison of device IDs before deleting files (presumably, to try to > > > accomplish the same thing as rm's --one-file-system option), but my > > > situation > > > of bind mounts on the same filesystem device means once again that > > > wouldn't be > > > effective in preventing this erroneous deletion. > > > > > > I strongly suggest improving the checks before deletion to avoid this > > > kind of > > > problem in the future. This may be as simple as checking the bind mount > > > points against /proc/mounts before starting the destroy process. > > > > I can see no reason not to add a check against /proc/mounts for any > > entries under $rootfs (if it is a directory). That should definately be > > added. > > I'm attaching the patch I added to my system to try to stop this from > happening > again. The ugly sed to create the grep regex is because rootdev ends up with > two leading slashes instead of one, which wouldn't otherwise match. I suspect > that's simply a bug in the sed two lines before, but I wasn't sure if there > were implications for lvdisplay or btrfs in fixing it, so I left it. The patch doesn't actually seem to be attached? Note though that lxc-destroy is now a c program. I don't recall whether someone actually stepped up to Stéphane's call for maintainers for older versions - it would be a good thing to have. -serge ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH 1/1] Initial support for cgmanager
This patch splits out most of the cgroupfs-specific code, so that
cgroup-manager versions can be plugged in. The case I did
not handle is cgroup_enter at lxc_attach. I'm hoping that case can
be greatly simplified, but will worry about it after fleshing out the
cgroup manager handlers.
This also simplify the freezer functions.
This seems to not regress my common tests when running without
cgmanager, but I'd like to do a bit more testing before pushing.
However I was hoping to get some more eyes on this so am sending it
out now.
Signed-off-by: Serge Hallyn
---
configure.ac| 18 +++
src/lxc/Makefile.am | 18 +++
src/lxc/attach.c| 6 +-
src/lxc/cgmanager.c | 367
src/lxc/cgroup.c| 350 -
src/lxc/cgroup.h| 61 +++--
src/lxc/commands.c | 13 +-
src/lxc/conf.c | 10 +-
src/lxc/conf.h | 5 +-
src/lxc/freezer.c | 14 --
src/lxc/lxc.h | 8 --
src/lxc/start.c | 47 ++-
src/lxc/start.h | 2 +-
13 files changed, 718 insertions(+), 201 deletions(-)
create mode 100644 src/lxc/cgmanager.c
diff --git a/configure.ac b/configure.ac
index 8514267..e513bbe 100644
--- a/configure.ac
+++ b/configure.ac
@@ -240,6 +240,23 @@ AM_COND_IF([ENABLE_SECCOMP],
])
])
+# cgmanager
+AC_ARG_ENABLE([cgmanager],
+ [AC_HELP_STRING([--enable-cgmanager], [enable cgmanager support
[default=auto]])],
+ [], [enable_cgmanager=auto])
+
+if test "x$enable_cgmanager" = "xauto" ; then
+
AC_CHECK_LIB([cgmanager],[cgmanager_create],[enable_cgmanager=yes],[enable_cgmanager=no])
+fi
+AM_CONDITIONAL([ENABLE_CGMANAGER], [test "x$enable_cgmanager" = "xyes"])
+
+AM_COND_IF([ENABLE_CGMANAGER],
+ [PKG_CHECK_MODULES([CGMANAGER], [libcgmanager])
+ PKG_CHECK_MODULES([NIH], [libnih >= 1.0.2])
+ PKG_CHECK_MODULES([NIH_DBUS], [libnih-dbus >= 1.0.0])
+ PKG_CHECK_MODULES([DBUS], [dbus-1 >= 1.2.16])
+ ])
+
# Linux capabilities
AC_ARG_ENABLE([capabilities],
[AC_HELP_STRING([--enable-capabilities], [enable kernel capabilities
support [default=auto]])],
@@ -684,6 +701,7 @@ Security features:
- Linux capabilities: $enable_capabilities
- seccomp: $enable_seccomp
- SELinux: $enable_selinux
+ - cgmanager: $enable_cgmanager
Bindings:
- lua: $enable_lua
diff --git a/src/lxc/Makefile.am b/src/lxc/Makefile.am
index 1e0232b..34d69a6 100644
--- a/src/lxc/Makefile.am
+++ b/src/lxc/Makefile.am
@@ -93,6 +93,10 @@ liblxc_so_SOURCES = \
\
$(LSM_SOURCES)
+if ENABLE_CGMANAGER
+liblxc_so_SOURCES += cgmanager.c
+endif
+
if IS_BIONIC
liblxc_so_SOURCES += \
../include/ifaddrs.c ../include/ifaddrs.h \
@@ -122,6 +126,10 @@ if ENABLE_APPARMOR
AM_CFLAGS += -DHAVE_APPARMOR
endif
+if ENABLE_CGMANAGER
+AM_CFLAGS += -DHAVE_CGMANAGER
+endif
+
if ENABLE_SELINUX
AM_CFLAGS += -DHAVE_SELINUX
endif
@@ -144,6 +152,11 @@ liblxc_so_LDFLAGS = \
liblxc_so_LDADD = $(CAP_LIBS) $(APPARMOR_LIBS) $(SECCOMP_LIBS)
+#if ENABLE_CGMANAGER
+liblxc_so_LDADD += $(CGMANAGER_LIBS) $(DBUS_LIBS) $(NIH_LIBS) $(NIH_DBUS_LIBS)
+liblxc_so_CFLAGS += $(CGMANAGER_CFLAGS) $(DBUS_CFLAGS) $(NIH_CFLAGS)
$(NIH_DBUS_CFLAGS)
+#endif
+
bin_SCRIPTS = \
lxc-ps \
lxc-netstat \
@@ -245,6 +258,11 @@ LDADD=liblxc.so @CAP_LIBS@ @APPARMOR_LIBS@ @SECCOMP_LIBS@
lxc_attach_SOURCES = lxc_attach.c
lxc_autostart_SOURCES = lxc_autostart.c
lxc_cgroup_SOURCES = lxc_cgroup.c
+#if ENABLE_CGMANAGER
+lxc_cgroup_SOURCES += cgmanager.c
+lxc_cgroup_LDADD = $(CGMANAGER_LIBS) $(DBUS_LIBS) $(NIH_LIBS) $(NIH_DBUS_LIBS)
$(LDADD)
+lxc_cgroup_CFLAGS = $(CGMANAGER_CFLAGS) $(DBUS_CFLAGS) $(NIH_CFLAGS)
$(NIH_DBUS_CFLAGS)
+#endif
lxc_checkpoint_SOURCES = lxc_checkpoint.c
lxc_config_SOURCES = lxc_config.c
lxc_console_SOURCES = lxc_console.c
diff --git a/src/lxc/attach.c b/src/lxc/attach.c
index 422f24c..de32549 100644
--- a/src/lxc/attach.c
+++ b/src/lxc/attach.c
@@ -748,7 +748,11 @@ int lxc_attach(const char* name, const char* lxcpath,
lxc_attach_exec_t exec_fun
goto cleanup_error;
}
- ret = lxc_cgroup_enter(container_info, attached_pid,
false);
+ /*
+* TODO - switch over to using a cgroup_operation. We
can't use
+* cgroup_enter() as that takes a handler.
+*/
+ ret = lxc_cgroupfs_enter(container_info, attached_pid,
false);
lxc_cgroup_process_info_free(container_info);
if (ret < 0) {
ERROR("could not move attached process %ld to
cgroup of container", (long)attached_pid);
diff --git a/src/lxc/cgmanager.c b/src/lxc/cgmanager.c
new file mode 100644
index 000..92745dc
--- /dev/null
+++ b/src/lxc/cgmanager.c
@@ -0,0 +1,367 @@
+/*
+ * lxc: linux Container library
+ *
+
Re: [lxc-devel] [PATCH] gentoo template (updated network management, master rebase)
On Tue, Jan 14, 2014 at 11:34:19PM +0100, l...@zitta.fr wrote:
>
> Le 14/01/2014 22:42, Stéphane Graber a écrit :
> > On Tue, Jan 14, 2014 at 12:06:26AM +0100, l...@zitta.fr wrote:
> >> Gentoo template
> >>
> >> Signed-off-by: gza
> > Hi,
> >
> > I must admit having only very briefly gone through the code as I'm not
> > familiar with Gentoo and it's a rather massive template to do a full
> > review of.
> >
> > I just noticed you're missing a .gitignore entry which I'll add and it's
> > also unfortunate that a new template isn't using the new common config
> > includes instead of hardcoding the whole config into every single
> > container, but that's something you'll obviously fix in the near future.
> >
> >
> > In the meant time:
> > Acked-by: Stéphane Graber
> Hi, I'll try to apply best practices during next days.
>
> BTW, What about common "bash functions" for templates ?
> Perhaps for Lxc 1.1 ...
It's been mentioned a few times but apparently nobody actually did that yet.
Adding a new lxc-templates.functions with standard shell functions for
template to use would make a lot of sense to me.
Btw, I forgot to comment on that earlier, you say:
> >> +#I'll drink champagne the day we do templates in python
> >> +#let's do some drity bash things
Well, there's actually no reason why you couldn't have written your
template in python. It's just a coincidence that everyone so far has
been using either POSIX shell or bash for their templates. LXC simply
expects a standard set of arguments to be accepted by the template and
have it exit 1 on error and 0 on success.
> >> ---
> >> configure.ac| 1 +
> >> templates/Makefile.am | 1 +
> >> templates/lxc-gentoo.in | 828
> >>
> >> 3 files changed, 830 insertions(+)
> >> create mode 100644 templates/lxc-gentoo.in
> >>
> >> diff --git a/configure.ac b/configure.ac
> >> index 8514267..d69afe7 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -648,6 +648,7 @@ AC_CONFIG_FILES([
> >> templates/lxc-archlinux
> >> templates/lxc-alpine
> >> templates/lxc-plamo
> >> +templates/lxc-gentoo
> >>
> >> src/Makefile
> >> src/lxc/Makefile
> >> diff --git a/templates/Makefile.am b/templates/Makefile.am
> >> index ff0a603..ac870a1 100644
> >> --- a/templates/Makefile.am
> >> +++ b/templates/Makefile.am
> >> @@ -10,6 +10,7 @@ templates_SCRIPTS = \
> >> lxc-debian \
> >> lxc-download \
> >> lxc-fedora \
> >> +lxc-gentoo \
> >> lxc-openmandriva \
> >> lxc-opensuse \
> >> lxc-oracle \
> >> diff --git a/templates/lxc-gentoo.in b/templates/lxc-gentoo.in
> >> new file mode 100644
> >> index 000..2bc13fd
> >> --- /dev/null
> >> +++ b/templates/lxc-gentoo.in
> >> @@ -0,0 +1,828 @@
> >> +#!/bin/bash
> >> +
> >> +#
> >> +# LXC template for gentoo
> >> +#
> >> +# Author: Guillaume Zitta
> >> +#
> >> +# Widely inspired from lxc-gentoo script at
> >> https://github.com/globalcitizen/lxc-gentoo
> >> +#
> >> +# this version is reworked with :
> >> +# - out of the lxc-create compat
> >> +# - vanilla gentoo config
> >> +# - ready to use cache
> >> +#
> >> +
> >> +# Ensure strict root's umask doesen't render the VM unusable
> >> +umask 022
> >> +
> >> +
> >> +#Various helper functions
> >> +
> >> +
> >> +# param: $1: the name of the lock
> >> +# param: $2: the timeout for the lock
> >> +# The rest contain the command to execute and its parameters
> >> +execute_exclusively()
> >> +{
> >> +mkdir -p @LOCALSTATEDIR@/lock/subsys/
> >> +
> >> +local lock_name="$1"
> >> +local timeout="$2"
> >> +shift 2
> >> +
> >> +{
> >> +printf "Attempting to obtain an exclusive lock (timeout: %s sec)
> >> named \"%s\"...\n" "${timeout}" "$lock_name"
> >> +
> >> +flock -x -w "${timeout}" 50
> >> +
> >> +if [[ $? -ne 0 ]]; then
> >> +printf " => unable to obtain lock, aborting.\n"
> >> +return 2
> >> +else
> >> +printf " => done.\n"
> >> +fi
> >> +
> >> +printf " => Executing \"%s\"\n" "$*"
> >> +"$@"
> >> +retval=$?
> >> +} 50> "@LOCALSTATEDIR@/lock/subsys/lxc-gentoo-${lock_name}"
> >> +return $retval
> >> +}
> >> +
> >> +# a die function is always a good idea
> >> +die()
> >> +{
> >> +printf "\n[the last exit code leading to this death was: %s ]\n" "$?"
> >> +local retval="$1"
> >> +shift 1
> >> +printf "$@"
> >> +exit "$retval"
> >> +}
> >> +
> >> +# gentoo arch/variant detection
> >> +set_default_arch()
> >> +{
> >> +printf "### set_default_arch: default arch/variant autodetect...\n"
> >> +arch=$(arch)
> >> +if [[ $arch =~ i.86 ]]; then
> >> +arch="x86"
> >> +variant="x86"
> >> +elif [[ $arch == "x86
Re: [lxc-devel] [PATCH] Modify lxc-fedora and lxc-centos for multiple issues...
On Tue, 2014-01-14 at 17:02 -0500, Stéphane Graber wrote:
> On Sun, Jan 12, 2014 at 08:53:49PM -0500, Michael H. Warfield wrote:
> > This is a reissue of two previous patches along with some additional
> > changes for hardening the root password process based on discussions
> > on-list.
> >
> > --
> > This patch modifies the lxc-fedora and lxc-centos templates for 3 things.
> >
> > 1) Extensively modifies root password generation, storage, and management
> > based on discussions on the devel list.
> >
> > Root passwords are hardened and have advanced configurability.
> > A static password may be provided.
> > A password based on a template may be generated, including ${RANDOM}.
> > A password may be generated through mktmp using a template with X's.
> > Root passwords default to expired, initially.
> > Passwords may optionally be echoed to stdout at container creation. (no)
> > Passwords may optionally be stored in ${rootfs_path}/tmp_root_pass.
> > (yes)
> > Users may be optionally forced to change the password at creation time.
> > (no)
> > Default is to generate a pattern based password and store, no force
> > change.
> > All of this may be overridden by environment variables through
> > conditional assignment.
> >
> > 2) Random static hardware addresses are generated for all configured
> > interfaces.
> >
> > 3) Add code to create sysv init style scripts to intercept shutdown and
> > reboot to prevent init restart and hang for CentOS and legacy Fedora
> > systems on shutdown, reboot, init 0, and init 6. This solves a variety
> > of hang conditions but only affects newly created containers. Does
> > not have any impact on systemd based containers.
> >
> I had to manually update the patch a bit to apply to master, but I think
> I got it right.
I'll check it. I saw that big "bashism" patch go in and thought to my
self "oh that's gonna hurt when my patch hits it" so I was figuring
something wouldn't go cleanly.
Thanks!
Regards
Mike
> Acked-by: Stéphane Graber
>
> > Signed-off-by: Michael H. Warfield
> > ---
> > templates/lxc-centos.in | 197
> > +---
> > templates/lxc-fedora.in | 182 +---
> > 2 files changed, 342 insertions(+), 37 deletions(-)
> >
> > diff --git a/templates/lxc-centos.in b/templates/lxc-centos.in
> > index 3126bba..4b12850 100644
> > --- a/templates/lxc-centos.in
> > +++ b/templates/lxc-centos.in
> > @@ -30,9 +30,40 @@
> > arch=$(arch)
> > cache_base=@LOCALSTATEDIR@/cache/lxc/centos/$arch
> > default_path=@LXCPATH@
> > -# We really need something better here!
> > -root_password=root
> >
> > +# Some combinations of the tunning knobs below do not exactly make sense.
> > +# but that's ok.
> > +#
> > +# 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 contians more than 3 consecutive X's, pass it as
> > +# a template to mktemp and take the result.
> > +#
> > +# If root_display_password = yes, display the temporary root password at
> > exit.
> > +# If root_store_password = yes, store it in the configuration directory
> > +# If root_prompt_password = yes, invoke "passwd" to force the user to
> > change
> > +# the root password after the container is created.
> > +#
> > +# These are conditional assignments... The can be overridden from the
> > +# preexisting environment variables...
> > +#
> > +# Make sure this is in single quotes to defer expansion to later!
> > +# :{root_password='Root-${name}-${RANDOM}'}
> > +: ${root_password='Root-${name}-XX'}
> > +
> > +# Now, it doesn't make much sense to display, store, and force change
> > +# together. But, we gotta test, right???
> > +: ${root_display_password='no'}
> > +: ${root_store_password='yes'}
> > +# Prompting for something interactive has potential for mayhem
> > +# with users running under the API... Don't default to "yes"
> > +: ${root_prompt_password='no'}
> > +
> > +# These are only going into comments in the resulting config...
> > lxc_network_type=veth
> > lxc_network_link=lxcbr0
> >
> > @@ -284,8 +315,21 @@ EOF
> > mknod -m 600 ${dev_path}/initctl p
> > mknod -m 666 ${dev_path}/ptmx c 5 2
> >
> > -echo "setting root passwd to $root_password"
> > +if [ ${root_display_password} = "yes" ]
> > +then
> > +echo "Setting root password to '$root_password'"
> > +fi
> > +if [ ${root_store_password} = "yes" ]
> > +then
> > +touch ${config_path}/tmp_root_pass
> > +chmod 600 ${config_path}/tmp_root_pass
> > +echo ${root_password} > ${config_path}/tmp_root_pass
>
[lxc-devel] [lxc/lxc] 275a2d: tests: Fix startone's call to want_daemonize
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 275a2d0bcacb6e584083988c28166be780a156e4 https://github.com/lxc/lxc/commit/275a2d0bcacb6e584083988c28166be780a156e4 Author: Stéphane Graber Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M src/tests/startone.c Log Message: --- tests: Fix startone's call to want_daemonize Signed-off-by: Stéphane Graber ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [Still Failing] lxc/lxc#59 (master - d16079b)
Build Update for lxc/lxc - Build: #59 Status: Still Failing Duration: 3 minutes and 9 seconds Commit: d16079b (master) Author: Stéphane Graber Message: ubuntu: Set default hwaddr to match template Signed-off-by: Stéphane Graber View the changeset: https://github.com/lxc/lxc/compare/f8d0243a78c6...d16079b6cb98 View the full build log and details: https://travis-ci.org/lxc/lxc/builds/16960914 -- You can configure recipients for build notifications in your .travis.yml file. See http://about.travis-ci.org/docs/user/build-configuration ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [Still Failing] lxc/lxc#60 (master - b4f7af7)
Build Update for lxc/lxc
-
Build: #60
Status: Still Failing
Duration: 2 minutes and 6 seconds
Commit: b4f7af7 (master)
Author: Michael H. Warfield
Message: Modify lxc-fedora and lxc-centos for multiple issues...
This is a reissue of two previous patches along with some additional
changes for hardening the root password process based on discussions
on-list.
--
This patch modifies the lxc-fedora and lxc-centos templates for 3 things.
1) Extensively modifies root password generation, storage, and management
based on discussions on the devel list.
Root passwords are hardened and have advanced configurability.
A static password may be provided.
A password based on a template may be generated, including ${RANDOM}.
A password may be generated through mktmp using a template with X's.
Root passwords default to expired, initially.
Passwords may optionally be echoed to stdout at container creation. (no)
Passwords may optionally be stored in ${rootfs_path}/tmp_root_pass. (yes)
Users may be optionally forced to change the password at creation time. (no)
Default is to generate a pattern based password and store, no force change.
All of this may be overridden by environment variables through
conditional assignment.
2) Random static hardware addresses are generated for all configured
interfaces.
3) Add code to create sysv init style scripts to intercept shutdown and
reboot to prevent init restart and hang for CentOS and legacy Fedora
systems on shutdown, reboot, init 0, and init 6. This solves a variety
of hang conditions but only affects newly created containers. Does
not have any impact on systemd based containers.
Signed-off-by: Michael H. Warfield
Acked-by: Stéphane Graber
View the changeset:
https://github.com/lxc/lxc/compare/d16079b6cb98...b4f7af7a520b
View the full build log and details:
https://travis-ci.org/lxc/lxc/builds/16961396
--
You can configure recipients for build notifications in your .travis.yml file.
See http://about.travis-ci.org/docs/user/build-configuration
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] gentoo template (updated network management, master rebase)
Le 14/01/2014 22:42, Stéphane Graber a écrit :
> On Tue, Jan 14, 2014 at 12:06:26AM +0100, l...@zitta.fr wrote:
>> Gentoo template
>>
>> Signed-off-by: gza
> Hi,
>
> I must admit having only very briefly gone through the code as I'm not
> familiar with Gentoo and it's a rather massive template to do a full
> review of.
>
> I just noticed you're missing a .gitignore entry which I'll add and it's
> also unfortunate that a new template isn't using the new common config
> includes instead of hardcoding the whole config into every single
> container, but that's something you'll obviously fix in the near future.
>
>
> In the meant time:
> Acked-by: Stéphane Graber
Hi, I'll try to apply best practices during next days.
BTW, What about common "bash functions" for templates ?
Perhaps for Lxc 1.1 ...
>> ---
>> configure.ac| 1 +
>> templates/Makefile.am | 1 +
>> templates/lxc-gentoo.in | 828
>>
>> 3 files changed, 830 insertions(+)
>> create mode 100644 templates/lxc-gentoo.in
>>
>> diff --git a/configure.ac b/configure.ac
>> index 8514267..d69afe7 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -648,6 +648,7 @@ AC_CONFIG_FILES([
>> templates/lxc-archlinux
>> templates/lxc-alpine
>> templates/lxc-plamo
>> +templates/lxc-gentoo
>>
>> src/Makefile
>> src/lxc/Makefile
>> diff --git a/templates/Makefile.am b/templates/Makefile.am
>> index ff0a603..ac870a1 100644
>> --- a/templates/Makefile.am
>> +++ b/templates/Makefile.am
>> @@ -10,6 +10,7 @@ templates_SCRIPTS = \
>> lxc-debian \
>> lxc-download \
>> lxc-fedora \
>> +lxc-gentoo \
>> lxc-openmandriva \
>> lxc-opensuse \
>> lxc-oracle \
>> diff --git a/templates/lxc-gentoo.in b/templates/lxc-gentoo.in
>> new file mode 100644
>> index 000..2bc13fd
>> --- /dev/null
>> +++ b/templates/lxc-gentoo.in
>> @@ -0,0 +1,828 @@
>> +#!/bin/bash
>> +
>> +#
>> +# LXC template for gentoo
>> +#
>> +# Author: Guillaume Zitta
>> +#
>> +# Widely inspired from lxc-gentoo script at
>> https://github.com/globalcitizen/lxc-gentoo
>> +#
>> +# this version is reworked with :
>> +# - out of the lxc-create compat
>> +# - vanilla gentoo config
>> +# - ready to use cache
>> +#
>> +
>> +# Ensure strict root's umask doesen't render the VM unusable
>> +umask 022
>> +
>> +
>> +#Various helper functions
>> +
>> +
>> +# param: $1: the name of the lock
>> +# param: $2: the timeout for the lock
>> +# The rest contain the command to execute and its parameters
>> +execute_exclusively()
>> +{
>> +mkdir -p @LOCALSTATEDIR@/lock/subsys/
>> +
>> +local lock_name="$1"
>> +local timeout="$2"
>> +shift 2
>> +
>> +{
>> +printf "Attempting to obtain an exclusive lock (timeout: %s sec)
>> named \"%s\"...\n" "${timeout}" "$lock_name"
>> +
>> +flock -x -w "${timeout}" 50
>> +
>> +if [[ $? -ne 0 ]]; then
>> +printf " => unable to obtain lock, aborting.\n"
>> +return 2
>> +else
>> +printf " => done.\n"
>> +fi
>> +
>> +printf " => Executing \"%s\"\n" "$*"
>> +"$@"
>> +retval=$?
>> +} 50> "@LOCALSTATEDIR@/lock/subsys/lxc-gentoo-${lock_name}"
>> +return $retval
>> +}
>> +
>> +# a die function is always a good idea
>> +die()
>> +{
>> +printf "\n[the last exit code leading to this death was: %s ]\n" "$?"
>> +local retval="$1"
>> +shift 1
>> +printf "$@"
>> +exit "$retval"
>> +}
>> +
>> +# gentoo arch/variant detection
>> +set_default_arch()
>> +{
>> +printf "### set_default_arch: default arch/variant autodetect...\n"
>> +arch=$(arch)
>> +if [[ $arch =~ i.86 ]]; then
>> +arch="x86"
>> +variant="x86"
>> +elif [[ $arch == "x86_64" ]]; then
>> +arch="amd64"
>> +variant="amd64"
>> +elif [[ $arch =~ arm.* ]]; then
>> +arch="arm"
>> +variant="armv7a"
>> +else
>> +#who knows, it may work...
>> +printf " => warn: unexpected arch:${arch} let me knows if it works
>> :)\n"
>> +variant="${arch}"
>> +fi
>> +printf " => Got: arch=%s variant=%s\n" "${arch}" "${variant}"
>> +}
>> +
>> +store_user_message()
>> +{
>> +user_message="${user_message}=> $@\n"
>> +}
>> +
>> +
>> +#CACHE Preparation
>> +
>> +# during setup cachedir is $cacheroot/partial-$arch-$variant
>> +# at the end, it will be $cacheroot/rootfs-$arch-$variant
>> +
>> +cache_setup(){
>> +partialfs="${cacheroot}/partial-${arch}-${variant}"
>> +
>> +#if cache exists and flush not needed, return
>> +[[ -d "${cac
[lxc-devel] [lxc/lxc] d8c77a: lxc-archlinux: don't drop mknod capability
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: d8c77af0ae59a3c48a44a11c95b991bd10473713 https://github.com/lxc/lxc/commit/d8c77af0ae59a3c48a44a11c95b991bd10473713 Author: John Lane Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M templates/lxc-archlinux.in Log Message: --- lxc-archlinux: don't drop mknod capability Signed-off-by: John Lane Acked-by: Stéphane Graber Commit: 734d0bed55ea17793510e1ce1de34ebc8c5eb6ab https://github.com/lxc/lxc/commit/734d0bed55ea17793510e1ce1de34ebc8c5eb6ab Author: John Lane Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M templates/lxc-archlinux.in Log Message: --- lxc-archlinux: support different architectures Signed-off-by: John Lane Acked-by: Stéphane Graber Commit: 012f591a7df0a3cb025905ba2e7d2033b550dac1 https://github.com/lxc/lxc/commit/012f591a7df0a3cb025905ba2e7d2033b550dac1 Author: John Lane Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M templates/lxc-archlinux.in Log Message: --- lxc-archlinux: support enabling systemd units Signed-off-by: John Lane Acked-by: Stéphane Graber Commit: d0800999b2aff2c2445e1ac18905fddbfe71cb8c https://github.com/lxc/lxc/commit/d0800999b2aff2c2445e1ac18905fddbfe71cb8c Author: John Lane Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M templates/lxc-archlinux.in Log Message: --- lxc-archlinux: optional --root_passwd argument Signed-off-by: John Lane Acked-by: Stéphane Graber Commit: b335cf8d4b56a49d5bc3fd1229139c2595779891 https://github.com/lxc/lxc/commit/b335cf8d4b56a49d5bc3fd1229139c2595779891 Author: Stéphane Graber Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M templates/lxc-archlinux.in Log Message: --- lxc-archlinux: Cleanup fstab It's been brought to my attention that the read-only mount of /proc/sys is causing problems to archlinux users, so instead just have LXC mount proc and sysfs normally (read-write). Reported-by: John Lane Signed-off-by: Stéphane Graber Compare: https://github.com/lxc/lxc/compare/b4f7af7a520b...b335cf8d4b56___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [Still Failing] lxc/lxc#58 (master - f8d0243)
Build Update for lxc/lxc - Build: #58 Status: Still Failing Duration: 2 minutes and 8 seconds Commit: f8d0243 (master) Author: l...@zitta.fr Message: gentoo: Initial template Signed-off-by: gza Acked-by: Stéphane Graber View the changeset: https://github.com/lxc/lxc/compare/c8ad5f4623bb...f8d0243a78c6 View the full build log and details: https://travis-ci.org/lxc/lxc/builds/16960290 -- You can configure recipients for build notifications in your .travis.yml file. See http://about.travis-ci.org/docs/user/build-configuration ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] Modify lxc-fedora and lxc-centos for multiple issues...
On Sun, Jan 12, 2014 at 08:53:49PM -0500, Michael H. Warfield wrote:
> This is a reissue of two previous patches along with some additional
> changes for hardening the root password process based on discussions
> on-list.
>
> --
> This patch modifies the lxc-fedora and lxc-centos templates for 3 things.
>
> 1) Extensively modifies root password generation, storage, and management
> based on discussions on the devel list.
>
> Root passwords are hardened and have advanced configurability.
> A static password may be provided.
> A password based on a template may be generated, including ${RANDOM}.
> A password may be generated through mktmp using a template with X's.
> Root passwords default to expired, initially.
> Passwords may optionally be echoed to stdout at container creation. (no)
> Passwords may optionally be stored in ${rootfs_path}/tmp_root_pass. (yes)
> Users may be optionally forced to change the password at creation time.
> (no)
> Default is to generate a pattern based password and store, no force
> change.
> All of this may be overridden by environment variables through
> conditional assignment.
>
> 2) Random static hardware addresses are generated for all configured
> interfaces.
>
> 3) Add code to create sysv init style scripts to intercept shutdown and
> reboot to prevent init restart and hang for CentOS and legacy Fedora
> systems on shutdown, reboot, init 0, and init 6. This solves a variety
> of hang conditions but only affects newly created containers. Does
> not have any impact on systemd based containers.
>
I had to manually update the patch a bit to apply to master, but I think
I got it right.
Acked-by: Stéphane Graber
> Signed-off-by: Michael H. Warfield
> ---
> templates/lxc-centos.in | 197
> +---
> templates/lxc-fedora.in | 182 +---
> 2 files changed, 342 insertions(+), 37 deletions(-)
>
> diff --git a/templates/lxc-centos.in b/templates/lxc-centos.in
> index 3126bba..4b12850 100644
> --- a/templates/lxc-centos.in
> +++ b/templates/lxc-centos.in
> @@ -30,9 +30,40 @@
> arch=$(arch)
> cache_base=@LOCALSTATEDIR@/cache/lxc/centos/$arch
> default_path=@LXCPATH@
> -# We really need something better here!
> -root_password=root
>
> +# Some combinations of the tunning knobs below do not exactly make sense.
> +# but that's ok.
> +#
> +# 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 contians more than 3 consecutive X's, pass it as
> +# a template to mktemp and take the result.
> +#
> +# If root_display_password = yes, display the temporary root password at
> exit.
> +# If root_store_password = yes, store it in the configuration directory
> +# If root_prompt_password = yes, invoke "passwd" to force the user to change
> +# the root password after the container is created.
> +#
> +# These are conditional assignments... The can be overridden from the
> +# preexisting environment variables...
> +#
> +# Make sure this is in single quotes to defer expansion to later!
> +# :{root_password='Root-${name}-${RANDOM}'}
> +: ${root_password='Root-${name}-XX'}
> +
> +# Now, it doesn't make much sense to display, store, and force change
> +# together. But, we gotta test, right???
> +: ${root_display_password='no'}
> +: ${root_store_password='yes'}
> +# Prompting for something interactive has potential for mayhem
> +# with users running under the API... Don't default to "yes"
> +: ${root_prompt_password='no'}
> +
> +# These are only going into comments in the resulting config...
> lxc_network_type=veth
> lxc_network_link=lxcbr0
>
> @@ -284,8 +315,21 @@ EOF
> mknod -m 600 ${dev_path}/initctl p
> mknod -m 666 ${dev_path}/ptmx c 5 2
>
> -echo "setting root passwd to $root_password"
> +if [ ${root_display_password} = "yes" ]
> +then
> +echo "Setting root password to '$root_password'"
> +fi
> +if [ ${root_store_password} = "yes" ]
> +then
> +touch ${config_path}/tmp_root_pass
> +chmod 600 ${config_path}/tmp_root_pass
> +echo ${root_password} > ${config_path}/tmp_root_pass
> +echo "Storing root password in '${config_path}/tmp_root_pass'"
> +fi
> +
> echo "root:$root_password" | chroot $rootfs_path chpasswd
> +# Also set this password as expired to force the user to change it!
> +chroot $rootfs_path passwd -e root
>
> # This will need to be enhanced for CentOS 7 when systemd
> # comes into play... /\/\|=mhw=|\/\/
> @@ -402,6 +446,7 @@ copy_centos()
> # i prefer rsync (no reason really)
> mkdir -
[lxc-devel] [lxc/lxc] b4f7af: Modify lxc-fedora and lxc-centos for multiple issu...
Branch: refs/heads/master
Home: https://github.com/lxc/lxc
Commit: b4f7af7a520b23c873e404562ec518a576e63d4c
https://github.com/lxc/lxc/commit/b4f7af7a520b23c873e404562ec518a576e63d4c
Author: Michael H. Warfield
Date: 2014-01-14 (Tue, 14 Jan 2014)
Changed paths:
M templates/lxc-centos.in
M templates/lxc-fedora.in
Log Message:
---
Modify lxc-fedora and lxc-centos for multiple issues...
This is a reissue of two previous patches along with some additional
changes for hardening the root password process based on discussions
on-list.
--
This patch modifies the lxc-fedora and lxc-centos templates for 3 things.
1) Extensively modifies root password generation, storage, and management
based on discussions on the devel list.
Root passwords are hardened and have advanced configurability.
A static password may be provided.
A password based on a template may be generated, including ${RANDOM}.
A password may be generated through mktmp using a template with X's.
Root passwords default to expired, initially.
Passwords may optionally be echoed to stdout at container creation. (no)
Passwords may optionally be stored in ${rootfs_path}/tmp_root_pass. (yes)
Users may be optionally forced to change the password at creation time. (no)
Default is to generate a pattern based password and store, no force change.
All of this may be overridden by environment variables through
conditional assignment.
2) Random static hardware addresses are generated for all configured
interfaces.
3) Add code to create sysv init style scripts to intercept shutdown and
reboot to prevent init restart and hang for CentOS and legacy Fedora
systems on shutdown, reboot, init 0, and init 6. This solves a variety
of hang conditions but only affects newly created containers. Does
not have any impact on systemd based containers.
Signed-off-by: Michael H. Warfield
Acked-by: Stéphane Graber
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [Broken] lxc/lxc#57 (master - c8ad5f4)
Build Update for lxc/lxc - Build: #57 Status: Broken Duration: 2 minutes and 57 seconds Commit: c8ad5f4 (master) Author: Serge Hallyn Message: api change: default container->daemonize to true Pretty much the only case where we do NOT want to daemonize a container start is lxc-start. So make c->daemonize true by default, and have lxc-start set it to false. If there are existing API users who rely on daemonize by default, then they will be broken by this. It seems we should do this before beta1 if we're going to do it. Signed-off-by: Serge Hallyn Acked-by: Stéphane Graber View the changeset: https://github.com/lxc/lxc/compare/4213a747e8f2...c8ad5f4623bb View the full build log and details: https://travis-ci.org/lxc/lxc/builds/16959120 -- You can configure recipients for build notifications in your .travis.yml file. See http://about.travis-ci.org/docs/user/build-configuration ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] d16079: ubuntu: Set default hwaddr to match template
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: d16079b6cb98290f474851611c9f6d264e9b30e7 https://github.com/lxc/lxc/commit/d16079b6cb98290f474851611c9f6d264e9b30e7 Author: Stéphane Graber Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M config/etc/default.conf.ubuntu Log Message: --- ubuntu: Set default hwaddr to match template Signed-off-by: Stéphane Graber ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] f8d024: gentoo: Initial template
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: f8d0243a78c65ea3c46eb60fbeef799c3f6e9a5b https://github.com/lxc/lxc/commit/f8d0243a78c65ea3c46eb60fbeef799c3f6e9a5b Author: l...@zitta.fr Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M .gitignore M configure.ac M templates/Makefile.am A templates/lxc-gentoo.in Log Message: --- gentoo: Initial template Signed-off-by: gza Acked-by: Stéphane Graber ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] gentoo template (updated network management, master rebase)
On Tue, Jan 14, 2014 at 12:06:26AM +0100, l...@zitta.fr wrote:
> Gentoo template
>
> Signed-off-by: gza
Hi,
I must admit having only very briefly gone through the code as I'm not
familiar with Gentoo and it's a rather massive template to do a full
review of.
I just noticed you're missing a .gitignore entry which I'll add and it's
also unfortunate that a new template isn't using the new common config
includes instead of hardcoding the whole config into every single
container, but that's something you'll obviously fix in the near future.
In the meant time:
Acked-by: Stéphane Graber
> ---
> configure.ac| 1 +
> templates/Makefile.am | 1 +
> templates/lxc-gentoo.in | 828
>
> 3 files changed, 830 insertions(+)
> create mode 100644 templates/lxc-gentoo.in
>
> diff --git a/configure.ac b/configure.ac
> index 8514267..d69afe7 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -648,6 +648,7 @@ AC_CONFIG_FILES([
> templates/lxc-archlinux
> templates/lxc-alpine
> templates/lxc-plamo
> +templates/lxc-gentoo
>
> src/Makefile
> src/lxc/Makefile
> diff --git a/templates/Makefile.am b/templates/Makefile.am
> index ff0a603..ac870a1 100644
> --- a/templates/Makefile.am
> +++ b/templates/Makefile.am
> @@ -10,6 +10,7 @@ templates_SCRIPTS = \
> lxc-debian \
> lxc-download \
> lxc-fedora \
> +lxc-gentoo \
> lxc-openmandriva \
> lxc-opensuse \
> lxc-oracle \
> diff --git a/templates/lxc-gentoo.in b/templates/lxc-gentoo.in
> new file mode 100644
> index 000..2bc13fd
> --- /dev/null
> +++ b/templates/lxc-gentoo.in
> @@ -0,0 +1,828 @@
> +#!/bin/bash
> +
> +#
> +# LXC template for gentoo
> +#
> +# Author: Guillaume Zitta
> +#
> +# Widely inspired from lxc-gentoo script at
> https://github.com/globalcitizen/lxc-gentoo
> +#
> +# this version is reworked with :
> +# - out of the lxc-create compat
> +# - vanilla gentoo config
> +# - ready to use cache
> +#
> +
> +# Ensure strict root's umask doesen't render the VM unusable
> +umask 022
> +
> +
> +#Various helper functions
> +
> +
> +# param: $1: the name of the lock
> +# param: $2: the timeout for the lock
> +# The rest contain the command to execute and its parameters
> +execute_exclusively()
> +{
> +mkdir -p @LOCALSTATEDIR@/lock/subsys/
> +
> +local lock_name="$1"
> +local timeout="$2"
> +shift 2
> +
> +{
> +printf "Attempting to obtain an exclusive lock (timeout: %s sec)
> named \"%s\"...\n" "${timeout}" "$lock_name"
> +
> +flock -x -w "${timeout}" 50
> +
> +if [[ $? -ne 0 ]]; then
> +printf " => unable to obtain lock, aborting.\n"
> +return 2
> +else
> +printf " => done.\n"
> +fi
> +
> +printf " => Executing \"%s\"\n" "$*"
> +"$@"
> +retval=$?
> +} 50> "@LOCALSTATEDIR@/lock/subsys/lxc-gentoo-${lock_name}"
> +return $retval
> +}
> +
> +# a die function is always a good idea
> +die()
> +{
> +printf "\n[the last exit code leading to this death was: %s ]\n" "$?"
> +local retval="$1"
> +shift 1
> +printf "$@"
> +exit "$retval"
> +}
> +
> +# gentoo arch/variant detection
> +set_default_arch()
> +{
> +printf "### set_default_arch: default arch/variant autodetect...\n"
> +arch=$(arch)
> +if [[ $arch =~ i.86 ]]; then
> +arch="x86"
> +variant="x86"
> +elif [[ $arch == "x86_64" ]]; then
> +arch="amd64"
> +variant="amd64"
> +elif [[ $arch =~ arm.* ]]; then
> +arch="arm"
> +variant="armv7a"
> +else
> +#who knows, it may work...
> +printf " => warn: unexpected arch:${arch} let me knows if it works
> :)\n"
> +variant="${arch}"
> +fi
> +printf " => Got: arch=%s variant=%s\n" "${arch}" "${variant}"
> +}
> +
> +store_user_message()
> +{
> +user_message="${user_message}=> $@\n"
> +}
> +
> +
> +#CACHE Preparation
> +
> +# during setup cachedir is $cacheroot/partial-$arch-$variant
> +# at the end, it will be $cacheroot/rootfs-$arch-$variant
> +
> +cache_setup(){
> +partialfs="${cacheroot}/partial-${arch}-${variant}"
> +
> +#if cache exists and flush not needed, return
> +[[ -d "${cachefs}" && -z "${flush_cache}" ]] && return 0
> +
> +printf "## cache_setup(): doing cache preparation\n"
> +local retval=1
> +
> +#clean from failed previous run
> +rm -rf "${partialfs}"
> +mkdir -p "${partialfs}"
> +
> +#let's go
> +cache_precheck && \
> +cache_stage3 && \
> +cache_portage && \
> +cache_
[lxc-devel] [lxc/lxc] c8ad5f: api change: default container->daemonize to true
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: c8ad5f4623bb5e61b1065047a22b90182daa2e66 https://github.com/lxc/lxc/commit/c8ad5f4623bb5e61b1065047a22b90182daa2e66 Author: Serge Hallyn Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M src/lxc/lxc_start.c M src/lxc/lxccontainer.c M src/tests/startone.c Log Message: --- api change: default container->daemonize to true Pretty much the only case where we do NOT want to daemonize a container start is lxc-start. So make c->daemonize true by default, and have lxc-start set it to false. If there are existing API users who rely on daemonize by default, then they will be broken by this. It seems we should do this before beta1 if we're going to do it. Signed-off-by: Serge Hallyn Acked-by: Stéphane Graber ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 1/1] RFC: api change: default container->daemonize to true
On Mon, Jan 13, 2014 at 11:08:48AM -0600, Serge Hallyn wrote:
> Pretty much the only case where we do NOT want to daemonize
> a container start is lxc-start. So make c->daemonize true
> by default, and have lxc-start set it to false.
>
> If there are existing API users who rely on daemonize by
> default, then they will be broken by this. It seems we should
> do this before beta1 if we're going to do it.
>
> Signed-off-by: Serge Hallyn
Acked-by: Stéphane Graber
> ---
> src/lxc/lxc_start.c| 4 ++--
> src/lxc/lxccontainer.c | 1 +
> src/tests/startone.c | 1 +
> 3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/lxc/lxc_start.c b/src/lxc/lxc_start.c
> index e6ca355..d5379da 100644
> --- a/src/lxc/lxc_start.c
> +++ b/src/lxc/lxc_start.c
> @@ -325,8 +325,8 @@ int main(int argc, char *argv[])
> conf->inherit_ns_fd[i] = fd;
> }
>
> - if (my_args.daemonize) {
> - c->want_daemonize(c, true);
> + if (!my_args.daemonize) {
> + c->want_daemonize(c, false);
> }
>
> if (pid_fp != NULL) {
> diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
> index 48fef74..5c2c62a 100644
> --- a/src/lxc/lxccontainer.c
> +++ b/src/lxc/lxccontainer.c
> @@ -3059,6 +3059,7 @@ struct lxc_container *lxc_container_new(const char
> *name, const char *configpath
> lxcapi_destroy(c);
> lxcapi_clear_config(c);
> }
> + c->daemonize = true;
>
> // assign the member functions
> c->is_defined = lxcapi_is_defined;
> diff --git a/src/tests/startone.c b/src/tests/startone.c
> index 678f62e..93992c1 100644
> --- a/src/tests/startone.c
> +++ b/src/tests/startone.c
> @@ -168,6 +168,7 @@ int main(int argc, char *argv[])
> fprintf(stderr, "%d: failed to get extra ref to container\n",
> __LINE__);
> exit(1);
> }
> + c->want_daemonize(false);
> pid_t pid = fork();
> if (pid < 0) {
> fprintf(stderr, "%d: fork failed\n", __LINE__);
> --
> 1.8.5.2
>
> ___
> 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
signature.asc
Description: Digital signature
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 4213a7: Make ubuntu templates squid-deb-proxy-client aware
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 4213a747e8f2f953114be798bab0e2bf11da4563 https://github.com/lxc/lxc/commit/4213a747e8f2f953114be798bab0e2bf11da4563 Author: Chris Glass Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M hooks/Makefile.am A hooks/squid-deb-proxy-client M templates/lxc-ubuntu.in Log Message: --- Make ubuntu templates squid-deb-proxy-client aware This makes the ubuntu and ubuntu-cloud templates automatically aware of apt proxy settings when the LXC host has "squid-deb-proxy-client" installed. This makes installations *much* faster when a suitable squid-deb-proxy is found on the network (or installed on the host). Signed-off-by: Chris Glass Acked-by: Stéphane Graber ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 17abf2: handle simple bashisms:
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 17abf2784de1047fb2904ff130ee5efe4ea7b598 https://github.com/lxc/lxc/commit/17abf2784de1047fb2904ff130ee5efe4ea7b598 Author: Elan Ruusamäe Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M templates/lxc-alpine.in M templates/lxc-altlinux.in M templates/lxc-archlinux.in M templates/lxc-busybox.in M templates/lxc-centos.in M templates/lxc-debian.in M templates/lxc-openmandriva.in M templates/lxc-opensuse.in M templates/lxc-oracle.in M templates/lxc-sshd.in M templates/lxc-ubuntu-cloud.in M templates/lxc-ubuntu.in Log Message: --- handle simple bashisms: - [[ ]] -> [ ] - == -> = - source -> . - redirect of fd 200 is error in mksh, use fd 9 - &> /dev/null -> > /dev/null 2>&1 - useless function keyword - echo -e -> printf still left bash shebang which did not validate with checkbashism, mostly due 'type' being reported as bashism Signed-Off-By: Elan Ruusamäe Acked-by: Stéphane Graber ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 3aa0ac: lxc-start-ephemeral: Fix syntax error in aufs
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 3aa0acaf0cbb70088ef1517b3ed97c39f3693606 https://github.com/lxc/lxc/commit/3aa0acaf0cbb70088ef1517b3ed97c39f3693606 Author: Åsmund Grammeltvedt Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M src/lxc/lxc-start-ephemeral.in Log Message: --- lxc-start-ephemeral: Fix syntax error in aufs Signed-off-by: Åsmund Grammeltvedt Acked-by: Stéphane Graber ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 33aa35: download: Fix download_sig logic
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 33aa351ac13936fb2549403f18a44fed32b2edfb https://github.com/lxc/lxc/commit/33aa351ac13936fb2549403f18a44fed32b2edfb Author: Stéphane Graber Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M templates/lxc-download.in Log Message: --- download: Fix download_sig logic Signed-off-by: Stéphane Graber Acked-by: Serge E. Hallyn Commit: fecf101cc4352e9bf60ed3477196146a65b5c4f6 https://github.com/lxc/lxc/commit/fecf101cc4352e9bf60ed3477196146a65b5c4f6 Author: Stéphane Graber Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M templates/lxc-download.in Log Message: --- download: Don't use an hardcoded exclude list Instead of hardcoding --exclude=./dev/*, use a new metadata file "excludes" which lists all the paths or patterns to exclude during extraction (one per line). Signed-off-by: Stéphane Graber Acked-by: Serge E. Hallyn Commit: 10a5fab6f3ad5cab234b198da31633e41c8ee364 https://github.com/lxc/lxc/commit/10a5fab6f3ad5cab234b198da31633e41c8ee364 Author: Stéphane Graber Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M templates/lxc-download.in Log Message: --- download: Support listing available images Signed-off-by: Stéphane Graber Acked-by: Serge E. Hallyn Commit: 9accc2efea59a685942501c13e8eb7a21f74a5f6 https://github.com/lxc/lxc/commit/9accc2efea59a685942501c13e8eb7a21f74a5f6 Author: Stéphane Graber Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M templates/lxc-download.in Log Message: --- download: Improve cache handling This adds a new --force-cache parameter which will force use of the cache even for expired images. An expired image is now only flushed from the cache once a new one is successfuly downloaded (to avoid destroying the local cache when the host doesn't have internet connectivity). The ID of the build in cache is also tracked so that we don't re-download something we already have (should only happen if we don't have a new build published by the time the previous one expires). Signed-off-by: Stéphane Graber Acked-by: Serge E. Hallyn Compare: https://github.com/lxc/lxc/compare/83b4b1dca80a...9accc2efea59___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 4/4] download: Improve cache handling
Quoting Stéphane Graber (stgra...@ubuntu.com): > This adds a new --force-cache parameter which will force use of the > cache even for expired images. > > An expired image is now only flushed from the cache once a new one is > successfuly downloaded (to avoid destroying the local cache when the > host doesn't have internet connectivity). > > The ID of the build in cache is also tracked so that we don't > re-download something we already have (should only happen if we don't > have a new build published by the time the previous one expires). > > Signed-off-by: Stéphane Graber Acked-by: Serge E. Hallyn ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH 3/4] download: Support listing available images
Quoting Stéphane Graber (stgra...@ubuntu.com):
> Signed-off-by: Stéphane Graber
(Didn't test, but looks ok)
Acked-by: Serge E. Hallyn
> ---
> templates/lxc-download.in | 60
> ++-
> 1 file changed, 54 insertions(+), 6 deletions(-)
>
> diff --git a/templates/lxc-download.in b/templates/lxc-download.in
> index 2298a9b..70a2389 100644
> --- a/templates/lxc-download.in
> +++ b/templates/lxc-download.in
> @@ -41,6 +41,7 @@ DOWNLOAD_URL=
> DOWNLOAD_SHOW_HTTP_WARNING="true"
> DOWNLOAD_SHOW_GPG_WARNING="true"
> DOWNLOAD_COMPAT_LEVEL=1
> +DOWNLOAD_LIST_IMAGES="false"
>
> LXC_NAME=
> LXC_PATH=
> @@ -148,9 +149,10 @@ Required arguments:
> [ -d | --dist ]: The name of the distribution
> [ -r | --release ]: Release name/version
> [ -a | --arch ]: Architecture of the container
> -[ -h | --help ]: This help message
>
> Optional arguments:
> +[ -h | --help ]: This help message
> +[ -l | --list ]: List all available images
> [ --variant ]: Variant of the image (default: "default")
> [ --server ]: Image server (default: "images.linuxcontainers.org")
> [ --keyid ]: GPG keyid (default: 0x...)
> @@ -167,8 +169,8 @@ EOF
> return 0
> }
>
> -options=$(getopt -o d:r:a:h -l dist:,release:,arch:,help,variant:,server:,\
> -keyid:,no-validate,flush-cache,name:,path:,rootfs:,mapped-uid: -- "$@")
> +options=$(getopt -o d:r:a:hl -l dist:,release:,arch:,help,list,variant:,\
> +server:,keyid:,no-validate,flush-cache,name:,path:,rootfs:,mapped-uid: --
> "$@")
>
> if [ $? -ne 0 ]; then
> usage
> @@ -178,7 +180,8 @@ eval set -- "$options"
>
> while :; do
> case "$1" in
> --h|--help) usage $0 && exit 0;;
> +-h|--help) usage && exit 1;;
> +-l|--list) DOWNLOAD_LIST_IMAGES="true"; shift 1;;
> -d|--dist) DOWNLOAD_DIST=$2; shift 2;;
> -r|--release) DOWNLOAD_RELEASE=$2; shift 2;;
> -a|--arch) DOWNLOAD_ARCH=$2; shift 2;;
> @@ -226,8 +229,8 @@ if [ "$(in_userns)" = "yes" ]; then
> DOWNLOAD_MODE="user"
> fi
>
> -if [ -z "$DOWNLOAD_DIST" ] || [ -z "$DOWNLOAD_RELEASE" ] || \
> - [ -z "$DOWNLOAD_ARCH" ]; then
> +if ([ -z "$DOWNLOAD_DIST" ] || [ -z "$DOWNLOAD_RELEASE" ] || \
> +[ -z "$DOWNLOAD_ARCH" ]) && [ "$DOWNLOAD_LIST_IMAGES" = "false" ]; then
> echo "ERROR: Missing required argument" 1>&2
> usage
> exit 1
> @@ -237,6 +240,51 @@ fi
> trap cleanup EXIT HUP INT TERM
> DOWNLOAD_TEMP=$(mktemp -d)
>
> +# Simply list images
> +if [ "$DOWNLOAD_LIST_IMAGES" = "true" ]; then
> +# Initialize GPG
> +gpg_setup
> +
> +# Grab the index
> +DOWNLOAD_INDEX_PATH=/meta/1.0/index-${DOWNLOAD_MODE}
> +
> +echo "Downloading the image index"
> +if ! download_file ${DOWNLOAD_INDEX_PATH}.${DOWNLOAD_COMPAT_LEVEL} \
> + ${DOWNLOAD_TEMP}/index noexit ||
> + ! download_sig ${DOWNLOAD_INDEX_PATH}.${DOWNLOAD_COMPAT_LEVEL}.asc \
> +${DOWNLOAD_TEMP}/index.asc noexit; then
> +download_file ${DOWNLOAD_INDEX_PATH} ${DOWNLOAD_TEMP}/index normal
> +download_sig ${DOWNLOAD_INDEX_PATH}.asc \
> +${DOWNLOAD_TEMP}/index.asc normal
> +fi
> +
> +gpg_validate ${DOWNLOAD_TEMP}/index.asc
> +
> +# Parse it
> +echo ""
> +echo "---"
> +echo "DIST\tRELEASE\tARCH\tVARIANT\tBUILD"
> +echo "---"
> +while read line; do
> +# Basic CSV parser
> +OLD_IFS=$IFS
> +IFS=";"
> +set -- $line
> +IFS=$OLD_IFS
> +
> +[ -n "$DOWNLOAD_DIST" ] && [ "$1" != "$DOWNLOAD_DIST" ] && continue
> +[ -n "$DOWNLOAD_RELEASE" ] && [ "$2" != "$DOWNLOAD_RELEASE" ] &&
> continue
> +[ -n "$DOWNLOAD_ARCH" ] && [ "$3" != "$DOWNLOAD_ARCH" ] && continue
> +[ -n "$DOWNLOAD_VARIANT" ] && [ "$4" != "$DOWNLOAD_VARIANT" ] &&
> continue
> +[ -z "$5" ] || [ -z "$6" ] && continue
> +
> +echo "$1\t$2\t$3\t$4\t$5"
> +done < ${DOWNLOAD_TEMP}/index
> +echo "---"
> +
> +exit 1
> +fi
> +
> # Setup the cache
> if [ "$DOWNLOAD_MODE" = "system" ]; then
> LXC_CACHE_BASE="$LOCALSTATEDIR/cache/"
> --
> 1.8.5.2
>
> ___
> 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] [PATCH 2/4] download: Don't use an hardcoded exclude list
Quoting Stéphane Graber (stgra...@ubuntu.com):
> Instead of hardcoding --exclude=./dev/*, use a new metadata file
> "excludes" which lists all the paths or patterns to exclude during
> extraction (one per line).
>
> Signed-off-by: Stéphane Graber
Acked-by: Serge E. Hallyn
> ---
> templates/lxc-download.in | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/templates/lxc-download.in b/templates/lxc-download.in
> index 4f28d0c..2298a9b 100644
> --- a/templates/lxc-download.in
> +++ b/templates/lxc-download.in
> @@ -341,14 +341,20 @@ fi
>
> # Unpack the rootfs
> echo "Unpacking the rootfs"
> -if [ "$DOWNLOAD_MODE" = "system" ]; then
> -tar --numeric-owner -xpJf ${LXC_CACHE_PATH}/rootfs.tar.xz -C
> ${LXC_ROOTFS}
> -else
> -tar --anchored --exclude="./dev/*" --numeric-owner -xpJf \
> -${LXC_CACHE_PATH}/rootfs.tar.xz -C ${LXC_ROOTFS}
> -mkdir -p ${LXC_ROOTFS}/dev/pts/
> +
> +EXCLUDES=""
> +excludelist=$(relevant_file excludes)
> +if [ -f "${excludelist}" ]; then
> +while read line; do
> +EXCLUDES="$EXCLUDES --exclude=$line"
> +done < $excludelist
> fi
>
> +tar --anchored ${EXCLUDES} --numeric-owner -xpJf \
> +${LXC_CACHE_PATH}/rootfs.tar.xz -C ${LXC_ROOTFS}
> +
> +mkdir -p ${LXC_ROOTFS}/dev/pts/
> +
> # Setup the configuration
> configfile=$(relevant_file config)
> fstab=$(relevant_file fstab)
> --
> 1.8.5.2
>
> ___
> 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] [PATCH 1/4] download: Fix download_sig logic
Quoting Stéphane Graber (stgra...@ubuntu.com):
> Signed-off-by: Stéphane Graber
Acked-by: Serge E. Hallyn
> ---
> templates/lxc-download.in | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/templates/lxc-download.in b/templates/lxc-download.in
> index fa54686..4f28d0c 100644
> --- a/templates/lxc-download.in
> +++ b/templates/lxc-download.in
> @@ -73,10 +73,17 @@ download_file() {
> }
>
> download_sig() {
> -download_file $1 $2 noexit
> -if [ "$DOWNLOAD_VALIDATE" = "true" ]; then
> -echo "ERROR: Failed to download http://${DOWNLOAD_SERVER}/$1"; 1>&2
> -exit 1
> +if ! download_file $1 $2 noexit; then
> +if [ "$DOWNLOAD_VALIDATE" = "true" ]; then
> +if [ "$3" = "normal" ]; then
> +echo "ERROR: Failed to download
> http://${DOWNLOAD_SERVER}/$1"; 1>&2
> +exit 1
> +else
> +return 1
> +fi
> +else
> +return 0
> +fi
> fi
> }
>
> @@ -268,11 +275,11 @@ if [ "$DOWNLOAD_USE_CACHE" = "false" ]; then
> echo "Downloading the image index"
> if ! download_file ${DOWNLOAD_INDEX_PATH}.${DOWNLOAD_COMPAT_LEVEL} \
> ${DOWNLOAD_TEMP}/index noexit ||
> - ! download_file ${DOWNLOAD_INDEX_PATH}.${DOWNLOAD_COMPAT_LEVEL}.asc \
> + ! download_sig ${DOWNLOAD_INDEX_PATH}.${DOWNLOAD_COMPAT_LEVEL}.asc \
> ${DOWNLOAD_TEMP}/index.asc noexit; then
> download_file ${DOWNLOAD_INDEX_PATH} ${DOWNLOAD_TEMP}/index normal
> download_sig ${DOWNLOAD_INDEX_PATH}.asc \
> -${DOWNLOAD_TEMP}/index.asc
> +${DOWNLOAD_TEMP}/index.asc normal
> fi
>
> gpg_validate ${DOWNLOAD_TEMP}/index.asc
> --
> 1.8.5.2
>
> ___
> 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
[lxc-devel] [PATCH 4/4] download: Improve cache handling
This adds a new --force-cache parameter which will force use of the
cache even for expired images.
An expired image is now only flushed from the cache once a new one is
successfuly downloaded (to avoid destroying the local cache when the
host doesn't have internet connectivity).
The ID of the build in cache is also tracked so that we don't
re-download something we already have (should only happen if we don't
have a new build published by the time the previous one expires).
Signed-off-by: Stéphane Graber
---
templates/lxc-download.in | 69 +--
1 file changed, 43 insertions(+), 26 deletions(-)
diff --git a/templates/lxc-download.in b/templates/lxc-download.in
index 70a2389..c318041 100644
--- a/templates/lxc-download.in
+++ b/templates/lxc-download.in
@@ -42,6 +42,7 @@ DOWNLOAD_SHOW_HTTP_WARNING="true"
DOWNLOAD_SHOW_GPG_WARNING="true"
DOWNLOAD_COMPAT_LEVEL=1
DOWNLOAD_LIST_IMAGES="false"
+DOWNLOAD_BUILD=
LXC_NAME=
LXC_PATH=
@@ -159,6 +160,7 @@ Optional arguments:
[ --keyserver ]: GPG keyserver to use
[ --no-validate ]: Disable GPG validation (not recommended)
[ --flush-cache ]: Flush the local copy (if present)
+[ --force-cache ]; Force the use of the local copy even if expired
LXC internal arguments (do not pass manually!):
[ --name ]: The container name
@@ -170,7 +172,8 @@ EOF
}
options=$(getopt -o d:r:a:hl -l dist:,release:,arch:,help,list,variant:,\
-server:,keyid:,no-validate,flush-cache,name:,path:,rootfs:,mapped-uid: -- "$@")
+server:,keyid:,no-validate,flush-cache,force-cache:,name:,path:,\
+rootfs:,mapped-uid: -- "$@")
if [ $? -ne 0 ]; then
usage
@@ -190,6 +193,7 @@ while :; do
--keyid)DOWNLOAD_KEYID=$2; shift 2;;
--no-validate) DOWNLOAD_VALIDATE="false"; shift 1;;
--flush-cache) DOWNLOAD_FLUSH_CACHE="true"; shift 1;;
+--force-cache) DOWNLOAD_FORCE_CACHE="true"; shift 1;;
--name) LXC_NAME=$2; shift 2;;
--path) LXC_PATH=$2; shift 2;;
--rootfs) LXC_ROOTFS=$2; shift 2;;
@@ -300,13 +304,14 @@ if [ -d "$LXC_CACHE_PATH" ]; then
if [ "$DOWNLOAD_FLUSH_CACHE" = "true" ]; then
echo "Flushing the cache..."
rm -Rf $LXC_CACHE_PATH
+elif [ "$DOWNLOAD_FORCE_CACHE" = "true" ]; then
+DOWNLOAD_USE_CACHE="true"
else
DOWNLOAD_USE_CACHE="true"
if [ -e "$(relevant_file expiry)" ]; then
if [ "$(cat $(relevant_file expiry))" -lt $(date +%s) ]; then
echo "The cached copy has expired, re-downloading..."
DOWNLOAD_USE_CACHE="false"
-rm -Rf $LXC_CACHE_PATH
fi
fi
fi
@@ -348,6 +353,7 @@ if [ "$DOWNLOAD_USE_CACHE" = "false" ]; then
continue
fi
+DOWNLOAD_BUILD=$5
DOWNLOAD_URL=$6
break
done < ${DOWNLOAD_TEMP}/index
@@ -357,32 +363,43 @@ if [ "$DOWNLOAD_USE_CACHE" = "false" ]; then
exit 1
fi
-# Download the actual files
-echo "Downloading the rootfs"
-download_file $DOWNLOAD_URL/rootfs.tar.xz \
-${DOWNLOAD_TEMP}/rootfs.tar.xz normal
-download_sig $DOWNLOAD_URL/rootfs.tar.xz.asc \
- ${DOWNLOAD_TEMP}/rootfs.tar.xz.asc normal
-gpg_validate ${DOWNLOAD_TEMP}/rootfs.tar.xz.asc
-
-echo "Downloading the metadata"
-download_file $DOWNLOAD_URL/meta.tar.xz \
-${DOWNLOAD_TEMP}/meta.tar.xz normal
-download_sig $DOWNLOAD_URL/meta.tar.xz.asc \
-${DOWNLOAD_TEMP}/meta.tar.xz.asc normal
-gpg_validate ${DOWNLOAD_TEMP}/meta.tar.xz.asc
-
-mkdir -p $LXC_CACHE_PATH
-mv ${DOWNLOAD_TEMP}/rootfs.tar.xz $LXC_CACHE_PATH
-if ! tar Jxf ${DOWNLOAD_TEMP}/meta.tar.xz -C $LXC_CACHE_PATH; then
-echo "ERROR: Invalid rootfs tarball." 2>&1
-exit 1
-fi
+if [ -d "$LXC_CACHE_PATH" ] && [ -f "$LXC_CACHE_PATH/build_id" ] && \
+ [ "$(cat $LXC_CACHE_PATH/build_id)" = "$DOWNLOAD_BUILD" ]; then
+echo "The cache is already up to date."
+echo "Using image from local cache"
+else
+# Download the actual files
+echo "Downloading the rootfs"
+download_file $DOWNLOAD_URL/rootfs.tar.xz \
+${DOWNLOAD_TEMP}/rootfs.tar.xz normal
+download_sig $DOWNLOAD_URL/rootfs.tar.xz.asc \
+ ${DOWNLOAD_TEMP}/rootfs.tar.xz.asc normal
+gpg_validate ${DOWNLOAD_TEMP}/rootfs.tar.xz.asc
+
+echo "Downloading the metadata"
+download_file $DOWNLOAD_URL/meta.tar.xz \
+${DOWNLOAD_TEMP}/meta.tar.xz normal
+download_sig $DOWNLOAD_URL/meta.tar.xz.asc \
+${DOWNLOAD_TEMP}/meta.tar.xz.asc normal
+gpg_validate ${DOWNLOAD_TEMP}/meta.tar.xz.asc
+
+if [ -d $LXC_CACHE_PATH ]; then
+rm -Rf $LXC_CACHE_PATH
+fi
+mkdir -p $LXC_CACHE_PATH
+mv ${DOWNLOAD_TEMP}/rootfs.tar.xz $LXC_CACHE_PATH
+if ! tar Jxf ${DOWNLOAD_TEMP}/
[lxc-devel] [PATCH 3/4] download: Support listing available images
Signed-off-by: Stéphane Graber
---
templates/lxc-download.in | 60 ++-
1 file changed, 54 insertions(+), 6 deletions(-)
diff --git a/templates/lxc-download.in b/templates/lxc-download.in
index 2298a9b..70a2389 100644
--- a/templates/lxc-download.in
+++ b/templates/lxc-download.in
@@ -41,6 +41,7 @@ DOWNLOAD_URL=
DOWNLOAD_SHOW_HTTP_WARNING="true"
DOWNLOAD_SHOW_GPG_WARNING="true"
DOWNLOAD_COMPAT_LEVEL=1
+DOWNLOAD_LIST_IMAGES="false"
LXC_NAME=
LXC_PATH=
@@ -148,9 +149,10 @@ Required arguments:
[ -d | --dist ]: The name of the distribution
[ -r | --release ]: Release name/version
[ -a | --arch ]: Architecture of the container
-[ -h | --help ]: This help message
Optional arguments:
+[ -h | --help ]: This help message
+[ -l | --list ]: List all available images
[ --variant ]: Variant of the image (default: "default")
[ --server ]: Image server (default: "images.linuxcontainers.org")
[ --keyid ]: GPG keyid (default: 0x...)
@@ -167,8 +169,8 @@ EOF
return 0
}
-options=$(getopt -o d:r:a:h -l dist:,release:,arch:,help,variant:,server:,\
-keyid:,no-validate,flush-cache,name:,path:,rootfs:,mapped-uid: -- "$@")
+options=$(getopt -o d:r:a:hl -l dist:,release:,arch:,help,list,variant:,\
+server:,keyid:,no-validate,flush-cache,name:,path:,rootfs:,mapped-uid: -- "$@")
if [ $? -ne 0 ]; then
usage
@@ -178,7 +180,8 @@ eval set -- "$options"
while :; do
case "$1" in
--h|--help) usage $0 && exit 0;;
+-h|--help) usage && exit 1;;
+-l|--list) DOWNLOAD_LIST_IMAGES="true"; shift 1;;
-d|--dist) DOWNLOAD_DIST=$2; shift 2;;
-r|--release) DOWNLOAD_RELEASE=$2; shift 2;;
-a|--arch) DOWNLOAD_ARCH=$2; shift 2;;
@@ -226,8 +229,8 @@ if [ "$(in_userns)" = "yes" ]; then
DOWNLOAD_MODE="user"
fi
-if [ -z "$DOWNLOAD_DIST" ] || [ -z "$DOWNLOAD_RELEASE" ] || \
- [ -z "$DOWNLOAD_ARCH" ]; then
+if ([ -z "$DOWNLOAD_DIST" ] || [ -z "$DOWNLOAD_RELEASE" ] || \
+[ -z "$DOWNLOAD_ARCH" ]) && [ "$DOWNLOAD_LIST_IMAGES" = "false" ]; then
echo "ERROR: Missing required argument" 1>&2
usage
exit 1
@@ -237,6 +240,51 @@ fi
trap cleanup EXIT HUP INT TERM
DOWNLOAD_TEMP=$(mktemp -d)
+# Simply list images
+if [ "$DOWNLOAD_LIST_IMAGES" = "true" ]; then
+# Initialize GPG
+gpg_setup
+
+# Grab the index
+DOWNLOAD_INDEX_PATH=/meta/1.0/index-${DOWNLOAD_MODE}
+
+echo "Downloading the image index"
+if ! download_file ${DOWNLOAD_INDEX_PATH}.${DOWNLOAD_COMPAT_LEVEL} \
+ ${DOWNLOAD_TEMP}/index noexit ||
+ ! download_sig ${DOWNLOAD_INDEX_PATH}.${DOWNLOAD_COMPAT_LEVEL}.asc \
+${DOWNLOAD_TEMP}/index.asc noexit; then
+download_file ${DOWNLOAD_INDEX_PATH} ${DOWNLOAD_TEMP}/index normal
+download_sig ${DOWNLOAD_INDEX_PATH}.asc \
+${DOWNLOAD_TEMP}/index.asc normal
+fi
+
+gpg_validate ${DOWNLOAD_TEMP}/index.asc
+
+# Parse it
+echo ""
+echo "---"
+echo "DIST\tRELEASE\tARCH\tVARIANT\tBUILD"
+echo "---"
+while read line; do
+# Basic CSV parser
+OLD_IFS=$IFS
+IFS=";"
+set -- $line
+IFS=$OLD_IFS
+
+[ -n "$DOWNLOAD_DIST" ] && [ "$1" != "$DOWNLOAD_DIST" ] && continue
+[ -n "$DOWNLOAD_RELEASE" ] && [ "$2" != "$DOWNLOAD_RELEASE" ] &&
continue
+[ -n "$DOWNLOAD_ARCH" ] && [ "$3" != "$DOWNLOAD_ARCH" ] && continue
+[ -n "$DOWNLOAD_VARIANT" ] && [ "$4" != "$DOWNLOAD_VARIANT" ] &&
continue
+[ -z "$5" ] || [ -z "$6" ] && continue
+
+echo "$1\t$2\t$3\t$4\t$5"
+done < ${DOWNLOAD_TEMP}/index
+echo "---"
+
+exit 1
+fi
+
# Setup the cache
if [ "$DOWNLOAD_MODE" = "system" ]; then
LXC_CACHE_BASE="$LOCALSTATEDIR/cache/"
--
1.8.5.2
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH 1/4] download: Fix download_sig logic
Signed-off-by: Stéphane Graber
---
templates/lxc-download.in | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/templates/lxc-download.in b/templates/lxc-download.in
index fa54686..4f28d0c 100644
--- a/templates/lxc-download.in
+++ b/templates/lxc-download.in
@@ -73,10 +73,17 @@ download_file() {
}
download_sig() {
-download_file $1 $2 noexit
-if [ "$DOWNLOAD_VALIDATE" = "true" ]; then
-echo "ERROR: Failed to download http://${DOWNLOAD_SERVER}/$1"; 1>&2
-exit 1
+if ! download_file $1 $2 noexit; then
+if [ "$DOWNLOAD_VALIDATE" = "true" ]; then
+if [ "$3" = "normal" ]; then
+echo "ERROR: Failed to download http://${DOWNLOAD_SERVER}/$1";
1>&2
+exit 1
+else
+return 1
+fi
+else
+return 0
+fi
fi
}
@@ -268,11 +275,11 @@ if [ "$DOWNLOAD_USE_CACHE" = "false" ]; then
echo "Downloading the image index"
if ! download_file ${DOWNLOAD_INDEX_PATH}.${DOWNLOAD_COMPAT_LEVEL} \
${DOWNLOAD_TEMP}/index noexit ||
- ! download_file ${DOWNLOAD_INDEX_PATH}.${DOWNLOAD_COMPAT_LEVEL}.asc \
+ ! download_sig ${DOWNLOAD_INDEX_PATH}.${DOWNLOAD_COMPAT_LEVEL}.asc \
${DOWNLOAD_TEMP}/index.asc noexit; then
download_file ${DOWNLOAD_INDEX_PATH} ${DOWNLOAD_TEMP}/index normal
download_sig ${DOWNLOAD_INDEX_PATH}.asc \
-${DOWNLOAD_TEMP}/index.asc
+${DOWNLOAD_TEMP}/index.asc normal
fi
gpg_validate ${DOWNLOAD_TEMP}/index.asc
--
1.8.5.2
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH 2/4] download: Don't use an hardcoded exclude list
Instead of hardcoding --exclude=./dev/*, use a new metadata file
"excludes" which lists all the paths or patterns to exclude during
extraction (one per line).
Signed-off-by: Stéphane Graber
---
templates/lxc-download.in | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/templates/lxc-download.in b/templates/lxc-download.in
index 4f28d0c..2298a9b 100644
--- a/templates/lxc-download.in
+++ b/templates/lxc-download.in
@@ -341,14 +341,20 @@ fi
# Unpack the rootfs
echo "Unpacking the rootfs"
-if [ "$DOWNLOAD_MODE" = "system" ]; then
-tar --numeric-owner -xpJf ${LXC_CACHE_PATH}/rootfs.tar.xz -C ${LXC_ROOTFS}
-else
-tar --anchored --exclude="./dev/*" --numeric-owner -xpJf \
-${LXC_CACHE_PATH}/rootfs.tar.xz -C ${LXC_ROOTFS}
-mkdir -p ${LXC_ROOTFS}/dev/pts/
+
+EXCLUDES=""
+excludelist=$(relevant_file excludes)
+if [ -f "${excludelist}" ]; then
+while read line; do
+EXCLUDES="$EXCLUDES --exclude=$line"
+done < $excludelist
fi
+tar --anchored ${EXCLUDES} --numeric-owner -xpJf \
+${LXC_CACHE_PATH}/rootfs.tar.xz -C ${LXC_ROOTFS}
+
+mkdir -p ${LXC_ROOTFS}/dev/pts/
+
# Setup the configuration
configfile=$(relevant_file config)
fstab=$(relevant_file fstab)
--
1.8.5.2
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] Pull request: make ubuntu templates apt proxy aware
On Tue, Jan 14, 2014 at 06:07:32PM +0100, Chris Glass wrote: > Should I post the patch to this list instead or is it simply that > nobody had time to look at it yet? > I don't mean to sound pushy at all (sorry if I do), I'm just trying to > contribute "the right way" :) > > Thanks > > - Chris Nope, that's fine. I've just been busy with other things at the moment. I hope to have some time to go through github pull requests later today. Btw, it's pretty likely that I'll postpone beta2 until tomorrow as I've got a few more changes to lxc-download which I want to get in before then. > > On Mon, Jan 13, 2014 at 6:23 PM, Chris Glass > wrote: > > (gmail is messing with my signature, that'll teach me to use the web > > interface) > > > > On Mon, Jan 13, 2014 at 6:22 PM, Chris Glass > > wrote: > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> Hi all, > >> > >> Here are the changes I was referring to in my previous email thread - > >> these changes make the ubuntu templates aware of squid-deb-proxy > >> servers visible to the host. > >> > >> https://github.com/lxc/lxc/pull/134 > >> > >> squid-deb-proxy uses avahi to advertise itself, and so installing > >> squid-deb-proxy-client on the LXC host lets apt autodetect proxy > >> settings. With this path the proxy settings are consumed by LXC when > >> both debootstrapping a new image and inside the container itself. > >> > >> This makes deploying similar environments (on a development machine > >> for example, in a CI lab, or for example using juju) *much* faster. > >> One could achieve similar results by setting APT_PROXY or HTTP_PROXY > >> when running lxc-create, but the advantage of this patch is that it's > >> completely automatic. > >> > >> The cost for people not using squid-deb-proxy is negligible, this > >> patch therefore adds the hook to the default ubuntu and ubuntu-cloud > >> templates. > >> > >> Note: this requires "dbus," to be added to the > >> /etc/apparmor.d/abstractions/lxc/start-container apparmor profile as > >> Stephane suggested in the previous thread (if not using the PPA > >> packages). > >> > >> > >> Hope this can be as useful for other people as it has been for me so far, > >> > >> - - Chris > >> > >> -BEGIN PGP SIGNATURE- > >> Version: GnuPG v1.4.14 (GNU/Linux) > >> > >> iEYEARECAAYFAlLUIH0ACgkQND4mi+cKVzTNLQCfU0S9XAFec79gbsiR+FMgoMwq > >> piEAnR5S9jmJ6sdaODTRjCOvm4SCMxDb > >> =OM7W > >> -END PGP SIGNATURE- > ___ > 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 signature.asc Description: Digital signature ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] Pull request: make ubuntu templates apt proxy aware
Should I post the patch to this list instead or is it simply that nobody had time to look at it yet? I don't mean to sound pushy at all (sorry if I do), I'm just trying to contribute "the right way" :) Thanks - Chris On Mon, Jan 13, 2014 at 6:23 PM, Chris Glass wrote: > (gmail is messing with my signature, that'll teach me to use the web > interface) > > On Mon, Jan 13, 2014 at 6:22 PM, Chris Glass > wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hi all, >> >> Here are the changes I was referring to in my previous email thread - >> these changes make the ubuntu templates aware of squid-deb-proxy >> servers visible to the host. >> >> https://github.com/lxc/lxc/pull/134 >> >> squid-deb-proxy uses avahi to advertise itself, and so installing >> squid-deb-proxy-client on the LXC host lets apt autodetect proxy >> settings. With this path the proxy settings are consumed by LXC when >> both debootstrapping a new image and inside the container itself. >> >> This makes deploying similar environments (on a development machine >> for example, in a CI lab, or for example using juju) *much* faster. >> One could achieve similar results by setting APT_PROXY or HTTP_PROXY >> when running lxc-create, but the advantage of this patch is that it's >> completely automatic. >> >> The cost for people not using squid-deb-proxy is negligible, this >> patch therefore adds the hook to the default ubuntu and ubuntu-cloud >> templates. >> >> Note: this requires "dbus," to be added to the >> /etc/apparmor.d/abstractions/lxc/start-container apparmor profile as >> Stephane suggested in the previous thread (if not using the PPA >> packages). >> >> >> Hope this can be as useful for other people as it has been for me so far, >> >> - - Chris >> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.14 (GNU/Linux) >> >> iEYEARECAAYFAlLUIH0ACgkQND4mi+cKVzTNLQCfU0S9XAFec79gbsiR+FMgoMwq >> piEAnR5S9jmJ6sdaODTRjCOvm4SCMxDb >> =OM7W >> -END PGP SIGNATURE- ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] Last minute template addition - universal image based template
Hi, > Due to the way the Jenkins job were setup, we always start from a clean > environment, so that means re-downloading everything every time. > For templates using http that's not a big problem because I have a > gigabit Debian and Ubuntu mirror on site and I have a gigabit squid > proxy for any other http query. The problem with plamo is that you're > using ftp which doesn't get through the transparent squid... I understand. I will try to improve lxc-plamo to use http. > Anyway, it's not a huge problem as we're only building two plamo images, > so an hour of download time a day is no that problematic. If we had 20 > builds, then it'd definitely be a rather big problem :) OK! :-) ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] Last minute template addition - universal image based template
On Tue, Jan 14, 2014 at 09:04:32PM +0900, KATOH Yasufumi wrote: > Hi, > > >>> On Mon, 13 Jan 2014 18:33:04 -0500 > in message "Re: [lxc-devel] Last minute template addition - universal > image based template" > St$(D+1(Bphane Graber-san wrote: > > > I've added plamo support to Jenkins and built two initial images. I > > still need to hook Jenkins to the public server so you'll probably > > only see them in a couple of days. > > Thanks!! > > > I went with a 48h expiry date for plamo. Jenkins will typically attempt > > a build once a day, so 48h should avoid us expiring an image when > > there's no new one around and still force users to re-grab new images > > often enough for your use case. > > OK! > > > Oh, also. Do you know if there's a North American plamo mirror? Download > > speeds from the default location are dreadful from here. It took me > > 35min to download the 200MB from the ftp site (instead of the expected > > 30s to a minute)... > > I don't know any North American mirror. :-( > > I list other mirrors in Japan, maybe download become faster (maybe > slower ^_^;): > ftp://ftp.dnsbalance.ring.gr.jp/pub/linux/Plamo/ > ftp://srv2.ftp.ne.jp/Linux/distributions/plamolinux/ Thanks, I'll try those. > > But as my previous mail, once lxc-create creates the cache, unless you > remove the cache, next running lxc-create will not access ftp site > (^_^;). Due to the way the Jenkins job were setup, we always start from a clean environment, so that means re-downloading everything every time. For templates using http that's not a big problem because I have a gigabit Debian and Ubuntu mirror on site and I have a gigabit squid proxy for any other http query. The problem with plamo is that you're using ftp which doesn't get through the transparent squid... Anyway, it's not a huge problem as we're only building two plamo images, so an hour of download time a day is no that problematic. If we had 20 builds, then it'd definitely be a rather big problem :) -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: Digital signature ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] RFC: cgroups aware proc
On Tue, Jan 14, 2014 at 02:58:14AM +0200, Marian Marinov wrote: > On 01/13/2014 07:12 PM, Peter Zijlstra wrote: > >On Mon, Jan 13, 2014 at 06:23:50PM +0200, Marian Marinov wrote: > >>Hello Peter, > >> > >>I need help with the scheduler. > >> > >>I'm currently trying to patch the /proc/loadavg to show the load that is > >>only related to the processes from the current cgroup. > >> > >>I looked trough the code and I was hoping that tsk->sched_task_group->cfs_rq > >>struct will give me the needed information, but unfortunately for me, it did > >>not. > >> > >>Can you advise me, how to approach this problem? > > > >Yeah, don't :-) Really, loadavg is a stupid metric. > > Yes... stupid, but unfortunately everyone is looking at it :( > > > > >>I'm totally new to the scheduler code. > > > >Luckily you won't actually have to touch much of it. Most of the actual > >loadavg code lives in the first ~400 lines of kernel/sched/proc.c, read > >and weep. Its one of the best documented bits around. > > I looked trough it but I don't understand how to introduce the per cgroup > calculation. > > I looked trough the headers and found the following, which is already > implemented. > > task->sched_task_group->load_avg > task->sched_task_group->cfs_rq->load_avg > task->sched_task_group->cfs_rq->load.weight > task->sched_task_group->cfs_rq->runnable_load_avg > > Unfortunately there is almost no documentation for these elements of the > cfs_rq and task_group structs. > > It seams to me that part of the per task group loadavg code is already > present. No, those are actual load metrics and completely unrelated to loadavg. Loadavg requires per-cgroup-per-cpu variants of nr_running and nr_uninterruptible. Those are the only metrics used in kernel/sched/proc.c for loadavg. ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 83b4b1: doc: Update lxc.conf(5)
Branch: refs/heads/master Home: https://github.com/lxc/lxc Commit: 83b4b1dca80ab147a7596ffb634863c138b8d9cf https://github.com/lxc/lxc/commit/83b4b1dca80ab147a7596ffb634863c138b8d9cf Author: KATOH Yasufumi Date: 2014-01-14 (Tue, 14 Jan 2014) Changed paths: M doc/ja/lxc.conf.sgml.in M doc/lxc.conf.sgml.in Log Message: --- doc: Update lxc.conf(5) * Update Japanese lxc.conf(5) for commit 508c263ee6ed2fac73f6979af287caba38963b4b * Remove duplicate line in English lxc.conf(5) Signed-off-by: KATOH Yasufumi Acked-by: Stéphane Graber ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] doc: Update lxc.conf(5)
On Tue, Jan 14, 2014 at 03:51:47PM +0900, KATOH Yasufumi wrote: > * Update Japanese lxc.conf(5) for commit > 508c263ee6ed2fac73f6979af287caba38963b4b > * Remove duplicate line in English lxc.conf(5) > > Signed-off-by: KATOH Yasufumi Acked-by: Stéphane Graber > --- > doc/ja/lxc.conf.sgml.in | 8 ++-- > doc/lxc.conf.sgml.in| 1 - > 2 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/doc/ja/lxc.conf.sgml.in b/doc/ja/lxc.conf.sgml.in > index 3b7ae79..5e1b410 100644 > --- a/doc/ja/lxc.conf.sgml.in > +++ b/doc/ja/lxc.conf.sgml.in > @@ -480,10 +480,14 @@ by KATOH Yasufumi > the interface mac address is dynamically allocated by > default to the virtual interface, but in some cases, > this is needed to resolve a mac address conflict or to > - always have the same link-local ipv6 address > + always have the same link-local ipv6 address. > + Any "x" in address will be replaced by random value, > + this allows setting hwaddr templates. >--> > - インターフェースの MAC アドレスは，デフォルトでは動的に割り当てられます． > + 仮想インターフェースの MAC アドレスは，デフォルトでは動的に割り当てられます． >しかし，MAC アドレスの衝突や，リンクローカルIPv6 アドレスを常に同じにした場合などは，このオプションが必要です． > + アドレス中の "x" という文字は，ランダムな値に置き換えられます． > + これによりテンプレートに hwaddr を設定することが可能になります． > > > > diff --git a/doc/lxc.conf.sgml.in b/doc/lxc.conf.sgml.in > index ba10939..4910cff 100644 > --- a/doc/lxc.conf.sgml.in > +++ b/doc/lxc.conf.sgml.in > @@ -360,7 +360,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, > Boston, MA 02110-1301 USA > the interface mac address is dynamically allocated by > default to the virtual interface, but in some cases, > this is needed to resolve a mac address conflict or to > - always have the same link-local ipv6 address > always have the same link-local ipv6 address. > Any "x" in address will be replaced by random value, > this allows setting hwaddr templates. > -- > 1.8.4.4 > > ___ > 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 signature.asc Description: Digital signature ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] Last minute template addition - universal image based template
Hi, >>> On Mon, 13 Jan 2014 18:33:04 -0500 in message "Re: [lxc-devel] Last minute template addition - universal image based template" St$(D+1(Bphane Graber-san wrote: > I've added plamo support to Jenkins and built two initial images. I > still need to hook Jenkins to the public server so you'll probably > only see them in a couple of days. Thanks!! > I went with a 48h expiry date for plamo. Jenkins will typically attempt > a build once a day, so 48h should avoid us expiring an image when > there's no new one around and still force users to re-grab new images > often enough for your use case. OK! > Oh, also. Do you know if there's a North American plamo mirror? Download > speeds from the default location are dreadful from here. It took me > 35min to download the 200MB from the ftp site (instead of the expected > 30s to a minute)... I don't know any North American mirror. :-( I list other mirrors in Japan, maybe download become faster (maybe slower ^_^;): ftp://ftp.dnsbalance.ring.gr.jp/pub/linux/Plamo/ ftp://srv2.ftp.ne.jp/Linux/distributions/plamolinux/ But as my previous mail, once lxc-create creates the cache, unless you remove the cache, next running lxc-create will not access ftp site (^_^;). -- ka...@jazz.email.ne.jp ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] lxc-destroy erased my hard disc
On Mon, Jan 13, 2014 at 06:23:24PM -0600, Serge Hallyn wrote: > Gah, that really does suck, sorry. The need to run as root has always > been annoying. We're finally at the point that some containers can be > created and run entirely as non-root, so that your host should be a lot > safer. That's definitely a positive development! > > This was with lxc 0.8.0 on x86 Linux (the relevant 0.9.0 code looks > > substantially similar). It happened shortly after installing lxc for the > > first > > time to try it out. I believe what must have happened was that the > > container I > > created wasn't shut down properly and still had its bind mounts for /lib > > etc. > > lxc-start would not have done any mounting in the host's mount > namespace, so that scenario shouldn't be possible. > > So I would actually guess that lxc-create (actually the template) was to > blame for leaving the bind mounts. Since it looks like you're not using > a stock template I'm not sure how you created the container. That's quite possible; I'm not completely sure yet how all the lxc moving parts fit together yet. I was using the stock busybox template, but there were a couple of configuration problems with lxc, so it wasn't a single perfectly clean create/start/stop. > > in place. The container must have been down enough to be considered not > > running > > according to lxc-info, so lxc-destroy helpfully rm -rf'ed it, including the > > contents of the bind mounts which pointed into my host system. > > > > rm was given the --one-file-system option, but it didn't prevent this from > > occurring, presumably because the device ID of the container location was > > the > > same as the device ID of the /lib of the host. After looking at the source > > to > > lxc-destroy, I'm surprised this kind of problem doesn't happen more > > often--it > > We do discourage bind-mounting from the host fs into the container, but > historcally it was considered useful (and may again) for checkpoint/restart. > > > is not at all defensively written (error codes ignored, arguments not > > properly > > quoted, this problem I'm writing about, etc.), so I was glad to see that > > lxc-destroy has since been reimplemented. However, on briefly looking at the > > new source, it seems that the same problem can still occur. There's a > > comparison of device IDs before deleting files (presumably, to try to > > accomplish the same thing as rm's --one-file-system option), but my > > situation > > of bind mounts on the same filesystem device means once again that wouldn't > > be > > effective in preventing this erroneous deletion. > > > > I strongly suggest improving the checks before deletion to avoid this kind > > of > > problem in the future. This may be as simple as checking the bind mount > > points against /proc/mounts before starting the destroy process. > > I can see no reason not to add a check against /proc/mounts for any > entries under $rootfs (if it is a directory). That should definately be > added. I'm attaching the patch I added to my system to try to stop this from happening again. The ugly sed to create the grep regex is because rootdev ends up with two leading slashes instead of one, which wouldn't otherwise match. I suspect that's simply a bug in the sed two lines before, but I wasn't sure if there were implications for lvdisplay or btrfs in fixing it, so I left it. >>> Dan ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
