Re: [lxc-devel] [RFC 1/1] snapshots in api: define lxcapi_snapshot
On Wed, Sep 04, 2013 at 11:05:02AM -0500, Serge Hallyn wrote:
> Hi,
>
> before I go on with the snapshots-in-api patchset, I wanted to floar
> this and ask a few questions, as I'm having a hard time deciding how
> we want to talk over the API.
>
> (Though as I've been typing this out, I think I now see how I want it
> to look.)
>
> First, the basics: if you have lxcpath=/var/lib/lxc and take a first
> snapshot of container c1, then the container will be
> /var/lib/lxcsnaps/c1/snap0. Next snapshot will be /var/lib/lxcsnaps/c1/snap1.
> You can pass a text file containing a commit comment, which will simply be
> stored at /var/lib/lxc/lxcsnaps/c0/snap0/comment, and a timestamp is
> created at /var/lib/lxc/lxcsnaps/c0/snap0/tx.
>
> To restore that snap1 as container c2, I'm thinking you would
>
> c = lxc_container_new("c0", "/var/lib/lxc");
> c2 = c->restore(c, "snap1", "c2");
> lxc_container_put(c2);
> lxc_container_put(c);
>
> (Note this doesn't match what's in the patch below). There are other
> ways it could be done. For instance we could open the snapshot as
> its own container and call restore on that, i.e.
>
> c = lxc_container_new("snap1", "/var/lib/lxcsnaps/c1");
> c2 = c->restore(c, "c2");
>
> I think I like the first option better though as it keeps callers
> from digging into the storage details. Thoughts?
>
> In addition, I'll add lxcapi_snapshot_destroy(), which will look like:
>
> c = lxc_container_new("c0", "/var/lib/lxc");
> c->snapshot_destroy(c, "snap1");
> lxc_container_put(c);
>
> As for snapshot_list, I'm thinking it will just look like:
>
> c = lxc_container_new("c0", "/var/lib/lxc");
> ns = c->snapshot_entries(c, NULL, 0);
> for (i=0; i c2 = c->get_snapshot(c, i);
> printf("name is %s, lxcpath %s\n", c->name, c->config_path);
> lxc_container_put(c2);
> }
> lxc_container_put(c);
>
> with 'timestamp' and 'comment_file' fields being added to struct
> container_struct, usually both NULL.
So I think that makes sense and I also prefer the first option you
described. Upon first read of your description it felt a bit weird
having this called restore() since it doesn't actually restore the
snapshot so much as create a new container based on it, but I suppose
that's fine since restore(c, "snpa1", "c0") will probably do what you'd
expect (restore previous state of a container from a snapshot name).
>
> Signed-off-by: Serge Hallyn
>
> ---
> src/lxc/lxccontainer.c | 106
> +
> src/lxc/lxccontainer.h | 14 +++
> src/tests/Makefile.am | 7 +++-
> src/tests/snapshot.c | 97
> 4 files changed, 222 insertions(+), 2 deletions(-)
> create mode 100644 src/tests/snapshot.c
>
> diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
> index f4d1f8e..65e7ebe 100644
> --- a/src/lxc/lxccontainer.c
> +++ b/src/lxc/lxccontainer.c
> @@ -68,6 +68,13 @@ static bool file_exists(char *f)
> return stat(f, &statbuf) == 0;
> }
>
> +static void remove_trailing_slashes(char *p)
> +{
> + int l = strlen(p);
> + while (--l >= 0 && (p[l] == '/' || p[l] == '\n'))
> + p[l] = '\0';
> +}
> +
> /*
> * A few functions to help detect when a container creation failed.
> * If a container creation was killed partway through, then trying
> @@ -2189,6 +2196,101 @@ static int lxcapi_attach_run_wait(struct
> lxc_container *c, lxc_attach_options_t
> return lxc_wait_for_pid_status(pid);
> }
>
> +int get_next_index(const char *lxcpath, char *cname)
> +{
> + char *fname;
> + struct stat sb;
> + int i = 0, ret;
> +
> + fname = alloca(strlen(lxcpath) + strlen(cname) + 20);
> + while (1) {
> + sprintf(fname, "%s/%s_%d", lxcpath, cname, i);
> + ret = stat(fname, &sb);
> + if (ret != 0)
> + return i;
> + i++;
> + }
> +}
> +
> +static bool lxcapi_snapshot(struct lxc_container *c, char *commentfile)
> +{
> + int i, flags, ret;
> + struct lxc_container *c2;
> + char snappath[MAXPATHLEN], newname[20];
> +
> + // /var/lib/lxc -> /var/lib/lxcsnaps \0
> + ret = snprintf(snappath, MAXPATHLEN, "%ssnaps/%s", c->config_path,
> c->name);
> + if (ret < 0 || ret >= MAXPATHLEN)
> + return false;
> + i = get_next_index(snappath, c->name);
> +
> + if (mkdir_p(snappath, 0755) < 0) {
> + ERROR("Failed to create snapshot directory %s", snappath);
> + return false;
> + }
> +
> + ret = snprintf(newname, 20, "snap%d", i);
> + if (ret < 0 || ret >= 20)
> + return false;
> +
> + flags = LXC_CLONE_SNAPSHOT | LXC_CLONE_KEEPMACADDR | LXC_CLONE_KEEPNAME;
> + c2 = c->clone(c, newname, snappath, flags, NULL, NULL, 0, NULL);
> + if (!c2) {
> + ERROR("clone of %s:%s failed\n",
[lxc-devel] lxc-destroy considered harmful
Hi, in https://bugzilla.redhat.com/show_bug.cgi?id=1003136 , a Fedora LXC user reports a problem with lxc-destroy removing parts of his host file system. He's using 0.8.0, and the obvious advice for him is to try with 0.9.0 (which I am currently building packages of), but that said, the problem is deeper imho. The lxc-destroy script contains this line at its end: rm -rf --one-file-system --preserve-root $lxc_path/$lxc_name Now, if - for one reason or the other (we cannot guarantee the lxc is bug free, or that the configuration is correct, etc.) - the bind mounts pointing to the host's file system are still present at that point in the script, the rm command will do something very harmful to the host. We should protect the user here. The --one-file-system option does not help in the case of bind mounts. This has been discussed in coreutils bug #9472 (see http://lists.gnu.org/archive/html/bug-coreutils/2011-09/msg00040.html, as I once experienced the same problem :( ), which is still open afaik. Wouldn't it be possible to have some code around that final rm command in lxc-destroy to avoid this scenario? Something like temporarily bind-mounting $lxc_path somewhere and then rm'ing $lxc_name in that bind mount? What do you think? Regards Thomas -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [RFC 1/1] snapshots in api: define lxcapi_snapshot
Hi,
before I go on with the snapshots-in-api patchset, I wanted to floar
this and ask a few questions, as I'm having a hard time deciding how
we want to talk over the API.
(Though as I've been typing this out, I think I now see how I want it
to look.)
First, the basics: if you have lxcpath=/var/lib/lxc and take a first
snapshot of container c1, then the container will be
/var/lib/lxcsnaps/c1/snap0. Next snapshot will be /var/lib/lxcsnaps/c1/snap1.
You can pass a text file containing a commit comment, which will simply be
stored at /var/lib/lxc/lxcsnaps/c0/snap0/comment, and a timestamp is
created at /var/lib/lxc/lxcsnaps/c0/snap0/tx.
To restore that snap1 as container c2, I'm thinking you would
c = lxc_container_new("c0", "/var/lib/lxc");
c2 = c->restore(c, "snap1", "c2");
lxc_container_put(c2);
lxc_container_put(c);
(Note this doesn't match what's in the patch below). There are other
ways it could be done. For instance we could open the snapshot as
its own container and call restore on that, i.e.
c = lxc_container_new("snap1", "/var/lib/lxcsnaps/c1");
c2 = c->restore(c, "c2");
I think I like the first option better though as it keeps callers
from digging into the storage details. Thoughts?
In addition, I'll add lxcapi_snapshot_destroy(), which will look like:
c = lxc_container_new("c0", "/var/lib/lxc");
c->snapshot_destroy(c, "snap1");
lxc_container_put(c);
As for snapshot_list, I'm thinking it will just look like:
c = lxc_container_new("c0", "/var/lib/lxc");
ns = c->snapshot_entries(c, NULL, 0);
for (i=0; iget_snapshot(c, i);
printf("name is %s, lxcpath %s\n", c->name, c->config_path);
lxc_container_put(c2);
}
lxc_container_put(c);
with 'timestamp' and 'comment_file' fields being added to struct
container_struct, usually both NULL.
Signed-off-by: Serge Hallyn
---
src/lxc/lxccontainer.c | 106 +
src/lxc/lxccontainer.h | 14 +++
src/tests/Makefile.am | 7 +++-
src/tests/snapshot.c | 97
4 files changed, 222 insertions(+), 2 deletions(-)
create mode 100644 src/tests/snapshot.c
diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
index f4d1f8e..65e7ebe 100644
--- a/src/lxc/lxccontainer.c
+++ b/src/lxc/lxccontainer.c
@@ -68,6 +68,13 @@ static bool file_exists(char *f)
return stat(f, &statbuf) == 0;
}
+static void remove_trailing_slashes(char *p)
+{
+ int l = strlen(p);
+ while (--l >= 0 && (p[l] == '/' || p[l] == '\n'))
+ p[l] = '\0';
+}
+
/*
* A few functions to help detect when a container creation failed.
* If a container creation was killed partway through, then trying
@@ -2189,6 +2196,101 @@ static int lxcapi_attach_run_wait(struct lxc_container
*c, lxc_attach_options_t
return lxc_wait_for_pid_status(pid);
}
+int get_next_index(const char *lxcpath, char *cname)
+{
+ char *fname;
+ struct stat sb;
+ int i = 0, ret;
+
+ fname = alloca(strlen(lxcpath) + strlen(cname) + 20);
+ while (1) {
+ sprintf(fname, "%s/%s_%d", lxcpath, cname, i);
+ ret = stat(fname, &sb);
+ if (ret != 0)
+ return i;
+ i++;
+ }
+}
+
+static bool lxcapi_snapshot(struct lxc_container *c, char *commentfile)
+{
+ int i, flags, ret;
+ struct lxc_container *c2;
+ char snappath[MAXPATHLEN], newname[20];
+
+ // /var/lib/lxc -> /var/lib/lxcsnaps \0
+ ret = snprintf(snappath, MAXPATHLEN, "%ssnaps/%s", c->config_path,
c->name);
+ if (ret < 0 || ret >= MAXPATHLEN)
+ return false;
+ i = get_next_index(snappath, c->name);
+
+ if (mkdir_p(snappath, 0755) < 0) {
+ ERROR("Failed to create snapshot directory %s", snappath);
+ return false;
+ }
+
+ ret = snprintf(newname, 20, "snap%d", i);
+ if (ret < 0 || ret >= 20)
+ return false;
+
+ flags = LXC_CLONE_SNAPSHOT | LXC_CLONE_KEEPMACADDR | LXC_CLONE_KEEPNAME;
+ c2 = c->clone(c, newname, snappath, flags, NULL, NULL, 0, NULL);
+ if (!c2) {
+ ERROR("clone of %s:%s failed\n", c->config_path, c->name);
+ return false;
+ }
+
+ lxc_container_put(c2);
+
+ // Now write down the creation time
+ time_t timer;
+ char buffer[25];
+ struct tm* tm_info;
+
+ time(&timer);
+ tm_info = localtime(&timer);
+
+ strftime(buffer, 25, "%Y:%m:%d %H:%M:%S", tm_info);
+
+ char *dfnam = alloca(strlen(snappath) + strlen(newname) + 5);
+ sprintf(dfnam, "%s/%s/ts", snappath, newname);
+ FILE *f = fopen(dfnam, "w");
+ if (!f) {
+ ERROR("Failed to open %s\n", dfnam);
+ return false;
+ }
+ if (fprintf(f, "%s", buffer)
Re: [lxc-devel] [RFC 1/1] snapshots in api: define lxcapi_snapshot
> In addition, I'll add lxcapi_snapshot_destroy(), which will look like:
>
> c = lxc_container_new("c0", "/var/lib/lxc");
> c->snapshot_destroy(c, "snap1");
> lxc_container_put(c);
>
> As for snapshot_list, I'm thinking it will just look like:
>
> c = lxc_container_new("c0", "/var/lib/lxc");
> ns = c->snapshot_entries(c, NULL, 0);
> for (i=0; i c2 = c->get_snapshot(c, i);
> printf("name is %s, lxcpath %s\n", c->name, c->config_path);
> lxc_container_put(c2);
> }
> lxc_container_put(c);
>
> with 'timestamp' and 'comment_file' fields being added to struct
> container_struct, usually both NULL.
No, I guess it's better to have a
struct lxc_snapshot {
// restore the container as a real container in lxcpath
struct lxc_container *(*restore)(char *name);
char *(*get_comment)(void);
char *(*timestamp)(void);
// return a lxc_container for the snapshot itself
struct lxc_container *(*open)(void);
bool (*destroy)(void);
};
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Lxc-users] Working LXC templates?
This issue really belongs on -devel since it's a template development issue that really impacts all the template writers. On Tue, 2013-09-03 at 09:26 -0700, Tony Su wrote: > Thx all for the replies, > - lxc-version returns 0.8.0. Looking around, there might be a more current > unstable, but AFAIK it's the most recently released stable. This is not going to work. 0.8.0 will not support systemd in a container, which all recent supported versions of Fedora are going to require. 0.8.0 may be the more recently released stable "FROM OpenSuse" but it is not the more recently release stable from LXC. The most recently released stable from LXC is 0.9.0 and even that doesn't have some of the necessary patches to the Fedora Template. Your best bet would be to built from the stage branch in git. You may need to wait until we release 1.0.0 and I'll take some of your thoughts into consideration for the Fedora template but I have no way to test them on OpenSuse at this time. Once we release 1.0.0, you'll still have the problem with what OpenSuse releases as their stable. We have no control over what they decide and do. > - I'd have to re-run to get the SSL error again but I think I've described > its error accurately, no further explanation except that the identity of > the remote server cannot be authenticated. This would lead me to guess that > the server is not registered properly with a public CA (eg using a CA root > that isn't in a bootstrap Fedora) so guessing that perhaps an option should > be offered that allows over-riding authentication? SSL encryption of course > should still be implemented for security. Well, I can give you an argument if the error was described accurately enough. I didn't see any site names I could test to see what the root CA is. Without that, I can't tell you why you're seeing that error. I understand fully what the error is (having my own private CA for private activities) but I can't determine the origin without knowing the source. I suspect that their certs are properly signed by a CA particular to the Fedora Project and properly contained in the Fedora rpm root store, so it may really be yet another cross distribution issue that depends on the distribution peculiar packages and configurations. Since there's probably no need (I see no need) for the Fedora Repositories to be "registered properly with a public CA" (and pay the extra expense), I would say the term "properly" is missued in this case. The rpms are all signed by the Fedora Project and their gpg key so, integrity shouldn't be an example unless someone intercepts the original rootfs build and provides a trojaned package with the gpg keys. Since this is an inter-distribution issue, I'm not sure what the proper solution would be (assuming my WAG is true) or what LXC can do to address it. I also don't know why Ubuntu / Debian is not experiencing this problem either. But, without some example names of specific sites exhibiting this problem (I don't run OpenSuse) I have no way to investigate further. Yeah, we could probably add an option to the template to ignore the SSL check or to use and alternate rootca store (if we can avoid the catch-22) but it may be better to investigate a more generic, distribution agnostic, solution to these types of problems. I do think it is an issue with the whole "distribution agnostic template" problem that may require some help from the distros or some innovative ideas of how we can bootstrap distros using distro agnostic tools (like stone knives and bear skins style install of the rootfs using nothing more than tar, gzip, gpg, and curl or wget). > - The lxc-create issue is definitely there. At first, I encountered it > using the openSUSE YAST LXC container applet. but then when I invoked > lxc-create from a console, but the "help" verifies it supports few options > and not these. But, as I described if the template requires parameters, > it's also possible to simply provide them in the script instead of at > runtime as command switches (but might not be apparent at first to someone > reading your script). > > Tony Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk___ Lxc-deve
Re: [lxc-devel] [Lxc-users] Working LXC templates?
On Wed, 04 Sep 2013 09:40:49 -0400 "Michael H. Warfield" wrote: > I do think it is an issue with the whole "distribution agnostic > template" problem that may require some help from the distros or some > innovative ideas of how we can bootstrap distros using distro agnostic > tools (like stone knives and bear skins style install of the rootfs > using nothing more than tar, gzip, gpg, and curl or wget). This would be very nice. I have not had success with any templates except the debian on Alpine Linux. Debian works because we build a debootstrap package. Ubuntu template did not work because it uses 'arch' command which we don't have. (ok, should be trivial to implement if we want it bad enough - and I haven't tested current git templates) However, the alpine template in current git should work on any distro. Here is what we do: * download static apk-tools (package manager) and the package with the public keys used for package signature checking. * unpack the the package manager and public keys package with tar. The package format is basically .tar.gz with some files in the beginning with metadata, so the .apk files can be extracted with tar -zx. * verify that the public keys are unmodified against a sha256 sum that is embedded in the template script. * verify that the static binary is unmodified using the public key and openssl. The apk-tools-static package includes a signature for the static binary. * use the verified static package manager to install a rootfs. The package manager will use the previously downloaded pub keys. This should work on any x86/x86_64 distro with tar, gzip, openssl and wget. -nc signature.asc Description: PGP signature -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] e34b5d: bdev_copy segfaults if bdevtype is NULL
Branch: refs/heads/staging Home: https://github.com/lxc/lxc Commit: e34b5d2ef2c329afe6540bbfc298ae631378832e https://github.com/lxc/lxc/commit/e34b5d2ef2c329afe6540bbfc298ae631378832e Author: S.Çağlar Onur Date: 2013-09-04 (Wed, 04 Sep 2013) Changed paths: M src/lxc/bdev.c Log Message: --- bdev_copy segfaults if bdevtype is NULL Signed-off-by: S.Çağlar Onur Signed-off-by: Serge Hallyn -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] bdev_copy segfaults if bdevtype is NULL
Quoting S.Çağlar Onur (cag...@10ur.org): > Signed-off-by: S.Çağlar Onur Acked-by: Serge E. Hallyn > --- > src/lxc/bdev.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/lxc/bdev.c b/src/lxc/bdev.c > index 39592b2..b45f2cb 100644 > --- a/src/lxc/bdev.c > +++ b/src/lxc/bdev.c > @@ -1939,7 +1939,7 @@ struct bdev *bdev_copy(const char *src, const char > *oldname, const char *cname, > bdevtype = "overlayfs"; > > *needs_rdep = 0; > - if (strcmp(orig->type, "dir") == 0 && > + if (bdevtype && strcmp(orig->type, "dir") == 0 && > strcmp(bdevtype, "overlayfs") == 0) > *needs_rdep = 1; > > -- > 1.8.1.2 > > > -- > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk > ___ > Lxc-devel mailing list > Lxc-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-devel -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH] lxc-alpine: add hwaddr for a single macvlan interface
We already add harware address for a single veth interface. Do the same
with a single macvlan interface.
Signed-off-by: Natanael Copa
---
templates/lxc-alpine.in | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/templates/lxc-alpine.in b/templates/lxc-alpine.in
index 2ab10bb..05aec74 100644
--- a/templates/lxc-alpine.in
+++ b/templates/lxc-alpine.in
@@ -173,9 +173,11 @@ lxc.network.flags = up
EOF
fi
-# if there is exactly one veth network entry, make sure it has an
-# associated mac address.
-nics=$(grep -e '^lxc\.network\.type[ \t]*=[ \t]*veth' $path/config | wc -l)
+# if there is exactly one veth or macvlan network entry, make sure
+# it has an associated mac address.
+nics=$(awk -F '[ \t]*=[ \t]*' \
+'$1=="lxc.network.type" && ($2=="veth" || $2=="macvlan") {print $2}' \
+$path/config | wc -l)
if [ "$nics" -eq 1 ] && ! grep -q "^lxc.network.hwaddr" $path/config; then
# see
http://sourceforge.net/tracker/?func=detail&aid=3411497&group_id=163076&atid=826303
hwaddr="fe:$(dd if=/dev/urandom bs=8 count=1 2>/dev/null |od -t x8 | \
--
1.8.4
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] Fwd: [Lxc-users] Working LXC templates?
-- Forwarded message -- From: Tony Su Date: Wed, Sep 4, 2013 at 10:23 AM Subject: Re: [Lxc-users] Working LXC templates? To: m...@wittsend.com Cc: Frederic Crozat , lxc-users , lxc-devel@lists.sourceforge.net Thx for the thoughts, Michael... Would like to know specifically what you believe is incompatible running 0.8.0 with systemd. I have not noticed any issues running openSUSE 12.2 (systemd v44?) and openSUSE 12.3 (systemd v195) on an openSUSE Host. I've been able to run systemd commands (typically systemctl and journalctl) from within the Containers without an issue most of the time without issue and in the rare cases something didn't work I've typically guessed it was just a potential security issue. I'm guessing that running systemd both fundamentally and using its various associated commands should not be an issue by simply applying namespaces (personally have been speculating on the use of simple random strings instead of user-readable text strings for security reasons). Based on the various templates I've tried, this issue is likely related to how complete and self-contained the container template is, the less it bind mounts or otherwise re-uses the Host system beyond /proc I consider the template more agnostic. Binding Host resources is what causes agnostic problems despite its various benefits. The reason why a specific repo URL wouldn't be useful is because interestingly Fedora's installation only looks up a Host which based on the install's world-wide location and type of proposed installation returns a recommended URL pointing to some repo mirror. This means that there is no point testing against any of the mirror URLs, they should all operate the same way. The URL I provided should be the only relevant and critical URL the install template needs to use correctly. As for why the authentication (GPG?) check isn't working, I haven't dived into exactly what package is being used... But IMO it would make sense in this pre-install environment, the Host's function is being used and openSUSE does require User verification (unless the "silent" switch is invoked which now that I'm thinking about it could be the answer to my specific situation but may not address other distros). H... so, maybe I have something to experiment with... Thx, Tony On Wed, Sep 4, 2013 at 6:40 AM, Michael H. Warfield wrote: > > This issue really belongs on -devel since it's a template development > issue that really impacts all the template writers. > > On Tue, 2013-09-03 at 09:26 -0700, Tony Su wrote: > > Thx all for the replies, > > > - lxc-version returns 0.8.0. Looking around, there might be a more current > > unstable, but AFAIK it's the most recently released stable. > > This is not going to work. 0.8.0 will not support systemd in a > container, which all recent supported versions of Fedora are going to > require. 0.8.0 may be the more recently released stable "FROM OpenSuse" > but it is not the more recently release stable from LXC. The most > recently released stable from LXC is 0.9.0 and even that doesn't have > some of the necessary patches to the Fedora Template. Your best bet > would be to built from the stage branch in git. > > You may need to wait until we release 1.0.0 and I'll take some of your > thoughts into consideration for the Fedora template but I have no way to > test them on OpenSuse at this time. Once we release 1.0.0, you'll still > have the problem with what OpenSuse releases as their stable. We have > no control over what they decide and do. > > > - I'd have to re-run to get the SSL error again but I think I've described > > its error accurately, no further explanation except that the identity of > > the remote server cannot be authenticated. This would lead me to guess that > > the server is not registered properly with a public CA (eg using a CA root > > that isn't in a bootstrap Fedora) so guessing that perhaps an option should > > be offered that allows over-riding authentication? SSL encryption of course > > should still be implemented for security. > > Well, I can give you an argument if the error was described accurately > enough. I didn't see any site names I could test to see what the root > CA is. Without that, I can't tell you why you're seeing that error. I > understand fully what the error is (having my own private CA for private > activities) but I can't determine the origin without knowing the source. > > > > I suspect that their certs are properly signed by a CA particular to the > Fedora Project and properly contained in the Fedora rpm root store, so > it may really be yet another cross distribution issue that depends on > the distribution peculiar packages and configurations. > > Since there's probably no need (I see no need) for the Fedora > Repositories to be "registered properly with a public CA" (and pay the > extra expense), I would say the term "properly" is missued in this case. > The rpms are all signed by the Fedora Project
Re: [lxc-devel] [PATCH] lxc-alpine: add hwaddr for a single macvlan interface
Quoting Natanael Copa (nc...@alpinelinux.org):
> We already add harware address for a single veth interface. Do the same
> with a single macvlan interface.
>
> Signed-off-by: Natanael Copa
Acked-by: Serge E. Hallyn
> ---
> templates/lxc-alpine.in | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/templates/lxc-alpine.in b/templates/lxc-alpine.in
> index 2ab10bb..05aec74 100644
> --- a/templates/lxc-alpine.in
> +++ b/templates/lxc-alpine.in
> @@ -173,9 +173,11 @@ lxc.network.flags = up
> EOF
> fi
>
> -# if there is exactly one veth network entry, make sure it has an
> -# associated mac address.
> -nics=$(grep -e '^lxc\.network\.type[ \t]*=[ \t]*veth' $path/config | wc
> -l)
> +# if there is exactly one veth or macvlan network entry, make sure
> +# it has an associated mac address.
> +nics=$(awk -F '[ \t]*=[ \t]*' \
> +'$1=="lxc.network.type" && ($2=="veth" || $2=="macvlan") {print $2}'
> \
> +$path/config | wc -l)
> if [ "$nics" -eq 1 ] && ! grep -q "^lxc.network.hwaddr" $path/config;
> then
> # see
> http://sourceforge.net/tracker/?func=detail&aid=3411497&group_id=163076&atid=826303
> hwaddr="fe:$(dd if=/dev/urandom bs=8 count=1 2>/dev/null |od -t x8 |
> \
> --
> 1.8.4
>
>
> --
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [lxc/lxc] 75b553: lxc-alpine: add hwaddr for a single macvlan interf...
Branch: refs/heads/staging Home: https://github.com/lxc/lxc Commit: 75b5535282453b3442a41df4a3ba6d3058cd6e48 https://github.com/lxc/lxc/commit/75b5535282453b3442a41df4a3ba6d3058cd6e48 Author: Natanael Copa Date: 2013-09-04 (Wed, 04 Sep 2013) Changed paths: M templates/lxc-alpine.in Log Message: --- lxc-alpine: add hwaddr for a single macvlan interface We already add harware address for a single veth interface. Do the same with a single macvlan interface. Signed-off-by: Natanael Copa Signed-off-by: Serge Hallyn -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] lxc-destroy considered harmful
Quoting Thomas Moschny (thomas.mosc...@gmail.com): > Hi, > > in https://bugzilla.redhat.com/show_bug.cgi?id=1003136 , a Fedora LXC > user reports a problem with lxc-destroy removing parts of his host > file system. > > He's using 0.8.0, and the obvious advice for him is to try with 0.9.0 > (which I am currently building packages of), but that said, the > problem is deeper imho. > > The lxc-destroy script contains this line at its end: > > rm -rf --one-file-system --preserve-root $lxc_path/$lxc_name > > Now, if - for one reason or the other (we cannot guarantee the lxc is > bug free, or that the configuration is correct, etc.) - the bind We're not relying on lxc being bug-free, but rather all mounts for a container are done in a new mounts namespace. So there can be no bind mounts left-over from a container run. That's not to say there can't be mistakes due to templates or user error, both of which are worth taking care to watch out for. > mounts pointing to the host's file system are still present at that > point in the script, the rm command will do something very harmful to > the host. We should protect the user here. The --one-file-system > option does not help in the case of bind mounts. This has been > discussed in coreutils bug #9472 (see > http://lists.gnu.org/archive/html/bug-coreutils/2011-09/msg00040.html, > as I once experienced the same problem :( ), which is still open > afaik. > > Wouldn't it be possible to have some code around that final rm command > in lxc-destroy to avoid this scenario? Something like temporarily > bind-mounting $lxc_path somewhere and then rm'ing $lxc_name in that > bind mount? > > What do you think? Nice idea, that sounds like it might work. Would you be able to send a patch for testing? -serge -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH] valgrind: fix memory leak on container new/put
Signed-off-by: Dwight Engen
---
src/lxc/lxclock.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/lxc/lxclock.c b/src/lxc/lxclock.c
index dea6941..79ebf84 100644
--- a/src/lxc/lxclock.c
+++ b/src/lxc/lxclock.c
@@ -122,6 +122,10 @@ struct lxc_lock *lxc_newlock(const char *lxcpath, const
char *name)
if (!name) {
l->type = LXC_LOCK_ANON_SEM;
l->u.sem = lxc_new_unnamed_sem();
+ if (!l->u.sem) {
+ free(l);
+ l = NULL;
+ }
goto out;
}
@@ -248,8 +252,11 @@ void lxc_putlock(struct lxc_lock *l)
return;
switch(l->type) {
case LXC_LOCK_ANON_SEM:
- if (l->u.sem)
+ if (l->u.sem) {
sem_close(l->u.sem);
+ free(l->u.sem);
+ l->u.sem = NULL;
+ }
break;
case LXC_LOCK_FLOCK:
process_lock();
@@ -264,6 +271,7 @@ void lxc_putlock(struct lxc_lock *l)
}
break;
}
+ free(l);
}
int process_lock(void)
--
1.8.1.4
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [RFC 1/1] snapshots in api: define lxcapi_snapshot
Quoting Stéphane Graber (stgra...@ubuntu.com):
> On Wed, Sep 04, 2013 at 11:05:02AM -0500, Serge Hallyn wrote:
> > Hi,
> >
> > before I go on with the snapshots-in-api patchset, I wanted to floar
> > this and ask a few questions, as I'm having a hard time deciding how
> > we want to talk over the API.
> >
> > (Though as I've been typing this out, I think I now see how I want it
> > to look.)
> >
> > First, the basics: if you have lxcpath=/var/lib/lxc and take a first
> > snapshot of container c1, then the container will be
> > /var/lib/lxcsnaps/c1/snap0. Next snapshot will be
> > /var/lib/lxcsnaps/c1/snap1.
> > You can pass a text file containing a commit comment, which will simply be
> > stored at /var/lib/lxc/lxcsnaps/c0/snap0/comment, and a timestamp is
> > created at /var/lib/lxc/lxcsnaps/c0/snap0/tx.
> >
> > To restore that snap1 as container c2, I'm thinking you would
> >
> > c = lxc_container_new("c0", "/var/lib/lxc");
> > c2 = c->restore(c, "snap1", "c2");
> > lxc_container_put(c2);
> > lxc_container_put(c);
> >
> > (Note this doesn't match what's in the patch below). There are other
> > ways it could be done. For instance we could open the snapshot as
> > its own container and call restore on that, i.e.
> >
> > c = lxc_container_new("snap1", "/var/lib/lxcsnaps/c1");
> > c2 = c->restore(c, "c2");
> >
> > I think I like the first option better though as it keeps callers
> > from digging into the storage details. Thoughts?
> >
> > In addition, I'll add lxcapi_snapshot_destroy(), which will look like:
> >
> > c = lxc_container_new("c0", "/var/lib/lxc");
> > c->snapshot_destroy(c, "snap1");
> > lxc_container_put(c);
> >
> > As for snapshot_list, I'm thinking it will just look like:
> >
> > c = lxc_container_new("c0", "/var/lib/lxc");
> > ns = c->snapshot_entries(c, NULL, 0);
> > for (i=0; i > c2 = c->get_snapshot(c, i);
> > printf("name is %s, lxcpath %s\n", c->name, c->config_path);
> > lxc_container_put(c2);
> > }
> > lxc_container_put(c);
> >
> > with 'timestamp' and 'comment_file' fields being added to struct
> > container_struct, usually both NULL.
>
> So I think that makes sense and I also prefer the first option you
> described. Upon first read of your description it felt a bit weird
> having this called restore() since it doesn't actually restore the
> snapshot so much as create a new container based on it, but I suppose
> that's fine since restore(c, "snpa1", "c0") will probably do what you'd
> expect (restore previous state of a container from a snapshot name).
I like the cleaner API if we have restore go back to the original
container, but I don't like the added concerns about destroying
the original.
I suppose we could have
c = lxc_container_new("c0", "/var/lib/lxc");
c->restore("snap3");
always create a new snapshot of c0, destroy c0, then restore
snap3 to c0. Does that seem like a good behavior?
-serge
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [RFC 1/1] snapshots in api: define lxcapi_snapshot
On Wed, Sep 04, 2013 at 05:14:49PM -0500, Serge Hallyn wrote:
> Quoting Stéphane Graber (stgra...@ubuntu.com):
> > On Wed, Sep 04, 2013 at 11:05:02AM -0500, Serge Hallyn wrote:
> > > Hi,
> > >
> > > before I go on with the snapshots-in-api patchset, I wanted to floar
> > > this and ask a few questions, as I'm having a hard time deciding how
> > > we want to talk over the API.
> > >
> > > (Though as I've been typing this out, I think I now see how I want it
> > > to look.)
> > >
> > > First, the basics: if you have lxcpath=/var/lib/lxc and take a first
> > > snapshot of container c1, then the container will be
> > > /var/lib/lxcsnaps/c1/snap0. Next snapshot will be
> > > /var/lib/lxcsnaps/c1/snap1.
> > > You can pass a text file containing a commit comment, which will simply be
> > > stored at /var/lib/lxc/lxcsnaps/c0/snap0/comment, and a timestamp is
> > > created at /var/lib/lxc/lxcsnaps/c0/snap0/tx.
> > >
> > > To restore that snap1 as container c2, I'm thinking you would
> > >
> > > c = lxc_container_new("c0", "/var/lib/lxc");
> > > c2 = c->restore(c, "snap1", "c2");
> > > lxc_container_put(c2);
> > > lxc_container_put(c);
> > >
> > > (Note this doesn't match what's in the patch below). There are other
> > > ways it could be done. For instance we could open the snapshot as
> > > its own container and call restore on that, i.e.
> > >
> > > c = lxc_container_new("snap1", "/var/lib/lxcsnaps/c1");
> > > c2 = c->restore(c, "c2");
> > >
> > > I think I like the first option better though as it keeps callers
> > > from digging into the storage details. Thoughts?
> > >
> > > In addition, I'll add lxcapi_snapshot_destroy(), which will look like:
> > >
> > > c = lxc_container_new("c0", "/var/lib/lxc");
> > > c->snapshot_destroy(c, "snap1");
> > > lxc_container_put(c);
> > >
> > > As for snapshot_list, I'm thinking it will just look like:
> > >
> > > c = lxc_container_new("c0", "/var/lib/lxc");
> > > ns = c->snapshot_entries(c, NULL, 0);
> > > for (i=0; i > > c2 = c->get_snapshot(c, i);
> > > printf("name is %s, lxcpath %s\n", c->name, c->config_path);
> > > lxc_container_put(c2);
> > > }
> > > lxc_container_put(c);
> > >
> > > with 'timestamp' and 'comment_file' fields being added to struct
> > > container_struct, usually both NULL.
> >
> > So I think that makes sense and I also prefer the first option you
> > described. Upon first read of your description it felt a bit weird
> > having this called restore() since it doesn't actually restore the
> > snapshot so much as create a new container based on it, but I suppose
> > that's fine since restore(c, "snpa1", "c0") will probably do what you'd
> > expect (restore previous state of a container from a snapshot name).
>
> I like the cleaner API if we have restore go back to the original
> container, but I don't like the added concerns about destroying
> the original.
>
> I suppose we could have
>
> c = lxc_container_new("c0", "/var/lib/lxc");
> c->restore("snap3");
>
> always create a new snapshot of c0, destroy c0, then restore
> snap3 to c0. Does that seem like a good behavior?
>
> -serge
I'd be tempted to say that users should know better and that it
shouldn't be the API's job to prevent obvious user mistakes.
I think ->restore("snap3") should wipe the current container and restore
the snapshot without doing anything fancier than that.
Then we can have the command line tool ask the user for confirmation and
have a flag to either snapshot the container first or have the restore
done against as another container.
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
signature.asc
Description: Digital signature
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH] lua: prepare for Lua 5.2
Adjust code for Lua 5.2 and keep compatibility with Lua 5.1.
We also fix a bug in the parsing of /proc/mounts while here.
Signed-off-by: Natanael Copa
---
src/lua-lxc/core.c | 10 --
src/lua-lxc/lxc.lua | 18 ++
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/src/lua-lxc/core.c b/src/lua-lxc/core.c
index 9ccbab4..d404707 100644
--- a/src/lua-lxc/core.c
+++ b/src/lua-lxc/core.c
@@ -25,9 +25,15 @@
#define _GNU_SOURCE
#include
#include
+#include
#include
#include
+#if LUA_VERSION_NUM < 502
+#define luaL_newlib(L,l) (lua_newtable(L), luaL_register(L,NULL,l))
+#define luaL_setfuncs(L,l,n) (assert(n==0), luaL_register(L,NULL,l))
+#endif
+
#ifdef NO_CHECK_UDATA
#define checkudata(L,i,tname) lua_touserdata(L, i)
#else
@@ -389,7 +395,7 @@ static int lxc_lib_uninit(lua_State *L) {
LUALIB_API int luaopen_lxc_core(lua_State *L) {
/* this is where we would initialize liblxc.so if we needed to */
-luaL_register(L, "lxc", lxc_lib_methods);
+luaL_newlib(L, lxc_lib_methods);
lua_newuserdata(L, 0);
lua_newtable(L); /* metatable */
@@ -401,12 +407,12 @@ LUALIB_API int luaopen_lxc_core(lua_State *L) {
lua_rawset(L, -3);
luaL_newmetatable(L, CONTAINER_TYPENAME);
+luaL_setfuncs(L, lxc_container_methods, 0);
lua_pushvalue(L, -1); /* push metatable */
lua_pushstring(L, "__gc");
lua_pushcfunction(L, container_gc);
lua_settable(L, -3);
lua_setfield(L, -2, "__index"); /* metatable.__index = metatable */
-luaL_register(L, NULL, lxc_container_methods);
lua_pop(L, 1);
return 1;
}
diff --git a/src/lua-lxc/lxc.lua b/src/lua-lxc/lxc.lua
index b48eb76..4ef1ff9 100755
--- a/src/lua-lxc/lxc.lua
+++ b/src/lua-lxc/lxc.lua
@@ -32,6 +32,11 @@ local lxc_path
local cgroup_path
local log_level = 3
+-- lua 5.1 compat
+if table.unpack == nil then
+table.unpack = unpack
+end
+
-- the following two functions can be useful for debugging
function printf(...)
local function wrapper(...) io.write(string.format(...)) end
@@ -89,6 +94,9 @@ function cgroup_path_get()
while true do
local c
line = f:read()
+ if line == nil then
+ break
+ end
c = line:split(" ", 6)
if (c[1] == "cgroup") then
cgroup_path = dirname(c[2])
@@ -283,7 +291,7 @@ function container:stat_get_ints(controller, item, coords)
table.insert(result, val)
end
end
-return unpack(result)
+return table.unpack(result)
end
-- read an integer from a cgroup file
@@ -356,10 +364,10 @@ function container:stats_get(total)
return stat
end
-
+local M = { container = container }
-- return configured containers found in LXC_PATH directory
-function containers_configured(names_only)
+function M.containers_configured(names_only)
local containers = {}
for dir in lfs.dir(lxc_path) do
@@ -387,7 +395,7 @@ function containers_configured(names_only)
end
-- return running containers found in cgroup fs
-function containers_running(names_only)
+function M.containers_running(names_only)
local containers = {}
local attr
@@ -423,3 +431,5 @@ end
lxc_path = core.default_config_path_get()
cgroup_path = cgroup_path_get()
+
+return M
--
1.8.4
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
