Re: [lxc-devel] 0.9.x versions before 1.0
Quoting Stéphane Graber (stgra...@ubuntu.com): On Tue, Jul 09, 2013 at 06:05:28PM -0400, Dwight Engen wrote: Hi guys, Just curious, has there been any thought about doing any more lxc versions 0.9.x before lxc 1.0? Seems like a few things have accumulated since 0.9.0. Just pulled this out of git for perspective: Name Commits Diffstat 0.7.0140 84 files changed, 4952 insertions(+), 2957 deletions(-) 0.7.177 files changed, 62 insertions(+), 15 deletions(-) 0.7.229 23 files changed, 532 insertions(+), 90 deletions(-) 0.7.323 17 files changed, 493 insertions(+), 162 deletions(-) 0.7.446 32 files changed, 1800 insertions(+), 526 deletions(-) 0.7.555 47 files changed, 1764 insertions(+), 1436 deletions(-) 0.8.0223 97 files changed, 5994 insertions(+), 1300 deletions(-) 0.9.0366 200 files changed, 17683 insertions(+), 3726 deletions(-) HEAD 194 136 files changed, 10540 insertions(+), 3319 deletions(-) 0.9.x is now the stable branch, so if someone has the time and willingness to cherry-pick fixes from HEAD, it'd be great to release a 0.9.1 bugfix release, however we shouldn't land any new features in there, so the cherry-picking work may be quite big. For that matter, I've been meaning to email the list to say, if anyone wants to maintain a stable branch of 0.7.5 or 0.8.0, please let me know. I can pull into say 0.7.5-stable from your github tree or something. If several distros have older releases using roughly the same version, it might help consolidate some effort. My own focus however will be on the bleeding edge (at least until I'm done with user and maybe syslog namespaces) so I'll just be pulling, not porting patches that don't apply cleanly. As for 1.0, I've been pretty busy with non-LXC things lately but still hope to get an alpha-1 out by end of July or early August, Ubuntu 13.10 will likely be using that (or alpha-2) as it's release version with 1.0 being aimed at 14.04 LTS next year. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] 0.9.x versions before 1.0
Quoting Qiang Huang (h.huangqi...@huawei.com): On 2013/7/10 6:05, Dwight Engen wrote: Hi guys, Just curious, has there been any thought about doing any more lxc versions 0.9.x before lxc 1.0? Seems like a few things have accumulated since 0.9.0. Just pulled this out of git for perspective: Name Commits Diffstat 0.7.0140 84 files changed, 4952 insertions(+), 2957 deletions(-) 0.7.177 files changed, 62 insertions(+), 15 deletions(-) 0.7.229 23 files changed, 532 insertions(+), 90 deletions(-) 0.7.323 17 files changed, 493 insertions(+), 162 deletions(-) 0.7.446 32 files changed, 1800 insertions(+), 526 deletions(-) 0.7.555 47 files changed, 1764 insertions(+), 1436 deletions(-) 0.8.0223 97 files changed, 5994 insertions(+), 1300 deletions(-) 0.9.0366 200 files changed, 17683 insertions(+), 3726 deletions(-) HEAD 194 136 files changed, 10540 insertions(+), 3319 deletions(-) Hi, I found we tried to change some script to c file, such like lxc-create, but it is not accomplished yet, we can't create a container without -t option, You misunderstood. We are not getting rid of the templates. We replaced the lxc-create script with an lxc_create.c program using the lxccontainer.c API. The lxc_create.c and the api do the actual basic container config creation and creation of the container rootfs. The templates are simply scripts which fill in the rootfs. Those *should* remain separate. In fact we probably should be hosting a repository of customized templates. (That gets a bit touchy - there are other projects doing the work of creating 'cloud images', and I don't care to duplicate their work.) are we going to finish it before lxc 1.0? Because it seems like a bug. Why? -serge -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] template output
Quoting S.Çağlar Onur (cag...@10ur.org): Hi, It looks like LXC@staging started to write template outputs to stdout like following when one uses the API; [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] sudo ./create Creating container... Checking cache download in /var/cache/lxc/raring/rootfs-amd64 ... Copy /var/cache/lxc/raring/rootfs-amd64 to /usr/lib/x86_64-linux-gnu/lxc/rootfs ... Copying rootfs to /usr/lib/x86_64-linux-gnu/lxc/rootfs ... Generating locales... en_US.UTF-8... up-to-date Generation complete. Creating SSH2 RSA key; this may take some time ... Creating SSH2 DSA key; this may take some time ... Creating SSH2 ECDSA key; this may take some time ... ## # The default user is 'ubuntu' with password 'ubuntu'! # Use the 'sudo' command to run tasks as root in the container. ## It wasn't like that @0.9 and I'm not sure whether this change was intentional. Wanted to check with you before diving into code to see what changed. It was intentional. The template scripts provide meaningful output which I (after switching to lxc_create.c) was silencing, so I considered that a bug. Do you disagree? Should we keep it silent? Should we add an option to lxc-create to dump template output either to a file or stdout or (if unspecified) silent? -serge -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [PATCH] lxc-fedora template - Fix retries, use os-release for release, add utsname.
Quoting Michael H. Warfield (m...@wittsend.com):
Hey all!
Patch for the Fedora template. Several things...
1) A month or so ago, I floated an idea of adding an option for utsname
which Serge seemed to like but we let it float for more feedback (none
came).
2) In private mail to Serge and Stéphane I mentioned the idea of using
the CPE (Common Platform Enumeration) for host distro and version
identification. I heard back from Serge but not Stéphane. CPE is a
standard promoted by NIST and Mitre (along with CVE and CVSS) as part of
Oh, I though Stéphane had replied, but maybe not. It comes down to: if
Debian starts using it, we'll pick that up, but we're not going to
differentiate on this. We already have our own well-established
/etc/lsb*.
Might some helpers in functions.in to parse whatever we could find be
be useful? In that way we could work toward having all the templates
use somewhat generic means of figuring out where they run, what tools
and packages they need to run, etc.
But, since you're only detecting *fedora* releases below, what you
have seems fine.
Note that splitting up the patch and then putting this email in a
0/N intro email would make replying a much lower threshold activity :)
Looks good though! So, ...
the security community as a common identification mechanism. It's
supported by RedHat based distros and many others (notable exception
Ubuntu). I've patched the Fedora template to parse first
the /etc/os-release file or, alternatively, the /etc/system-release-cpe
file for the distro ID and version instead of the human
readable /etc/redhat-release. There's more that can be done with that
in the realm of cross distro container builds, I suspect.
3) At the time of working on 12 I noticed that the retry logic in the
Fedora template just didn't seem right. I believe I posted a message
asking for clarification on that behavior. A recently post in the
-users list indicating that someone could not create a Fedora 19
container (because the release ver string was 19-2 and the template was
only looking for -1) prompted me to rework the retry logic for handling
the mirror list and servers as well as revamp the download logic to
properly identify the correct release package.
The patch for all of the above is attached below the jump. It's been
tested on Fedora 17 through Fedora 19 hosts and has created containers
for F11, F12, F13, F14, F16, F17, F18, and F19. F15 failed for rpm
dependency issues that are not worth fixing (IMHO).
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!
--
Signed-off-by: Michael H. Warfield m...@wittsend.com
Acked-by: Serge E. Hallyn serge.hal...@ubuntu.com
---
diff --git a/templates/lxc-fedora.in b/templates/lxc-fedora.in
index f5da7b5..23728c6 100644
--- a/templates/lxc-fedora.in
+++ b/templates/lxc-fedora.in
@@ -33,8 +33,43 @@ root_password=root
# is this fedora?
# Alow for weird remixes like the Raspberry Pi
-if [ -e /etc/redhat-release ]
+#
+# Use the Mitre standard CPE identifier for the release ID if possible...
+# This may be in /etc/os-release or /etc/system-release-cpe. We
+# should be able to use EITHER. Give preference to /etc/os-release for now.
+
+if [ -e /etc/os-release ]
+then
+# This is a shell friendly configuration file. We can just source it.
+# What we're looking for in here is the ID, VERSION_ID and the CPE_NAME
+. /etc/os-release
+echo Host CPE ID from /etc/os-release: ${CPE_NAME}
+fi
+
+if [ ${CPE_NAME} = -a -e /etc/system-release-cpe ]
+then
+CPE_NAME=$(head -n1 /etc/system-release-cpe)
+CPE_URI=$(expr ${CPE_NAME} : '\([^:]*:[^:*]\)')
+if [ ${CPE_URI} != cpe:/o ]
+then
+CPE_NAME=
+else
+echo Host CPE ID from /etc/system-release-cpe: ${CPE_NAME}
+# Probably a better way to do this but sill remain posix
+# compatible but this works, shrug...
+# Must be nice and not introduce convenient bashisms here.
+ID=$(expr ${CPE_NAME} : '[^:]*:[^:]*:[^:]*:\([^:]*\)')
+VERSION_ID=$(expr ${CPE_NAME} : '[^:]*:[^:]*:[^:]*:[^:]*:\([^:]*\)')
+fi
+fi
+
+if [ ${CPE_NAME} != -a ${ID} = fedora -a ${VERSION_ID} != ]
then
+fedora_host_ver=${VERSION_ID}
+is_fedora=true
+elif [ -e /etc/redhat-release ]
+then
+# Only if all other methods fail, try to parse the redhat-release file.
fedora_host_ver=$( sed -e '/^Fedora /!d' -e
's/Fedora.*\srelease\s*\([0-9][0-9]*\)\s.*/\1/' /etc/redhat-release )
if [ $fedora_host_ver != ]
then
@@ -66,7 +101,7 @@ configure_fedora()
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
-HOSTNAME=${name}
+HOSTNAME=${utsname}
NM_CONTROLLED=no
Re: [lxc-devel] template output
Hi Serge, On Wed, Jul 10, 2013 at 10:36 AM, Serge Hallyn serge.hal...@ubuntu.comwrote: Quoting S.Çağlar Onur (cag...@10ur.org): Hi, It looks like LXC@staging started to write template outputs to stdout like following when one uses the API; [caglar@oOo:~/go/src/github.com/caglar10ur/lxc/examples] sudo ./create Creating container... Checking cache download in /var/cache/lxc/raring/rootfs-amd64 ... Copy /var/cache/lxc/raring/rootfs-amd64 to /usr/lib/x86_64-linux-gnu/lxc/rootfs ... Copying rootfs to /usr/lib/x86_64-linux-gnu/lxc/rootfs ... Generating locales... en_US.UTF-8... up-to-date Generation complete. Creating SSH2 RSA key; this may take some time ... Creating SSH2 DSA key; this may take some time ... Creating SSH2 ECDSA key; this may take some time ... ## # The default user is 'ubuntu' with password 'ubuntu'! # Use the 'sudo' command to run tasks as root in the container. ## It wasn't like that @0.9 and I'm not sure whether this change was intentional. Wanted to check with you before diving into code to see what changed. It was intentional. The template scripts provide meaningful output which I (after switching to lxc_create.c) was silencing, so I considered that a bug. Do you disagree? Should we keep it silent? Should we add an option to lxc-create to dump template output either to a file or stdout or (if unspecified) silent? -serge I think your suggestion providing an option to dump template output either to a file or stdout or (if unspecified) silent sounds best among possible solutions. Cheers -- S.Çağlar Onur cag...@10ur.org -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] 0.9.x versions before 1.0
Quoting Qiang Huang (h.huangqi...@huawei.com): On 2013/7/10 22:30, Serge Hallyn wrote: Quoting Qiang Huang (h.huangqi...@huawei.com): On 2013/7/10 6:05, Dwight Engen wrote: Hi guys, Just curious, has there been any thought about doing any more lxc versions 0.9.x before lxc 1.0? Seems like a few things have accumulated since 0.9.0. Just pulled this out of git for perspective: Name Commits Diffstat 0.7.0140 84 files changed, 4952 insertions(+), 2957 deletions(-) 0.7.177 files changed, 62 insertions(+), 15 deletions(-) 0.7.229 23 files changed, 532 insertions(+), 90 deletions(-) 0.7.323 17 files changed, 493 insertions(+), 162 deletions(-) 0.7.446 32 files changed, 1800 insertions(+), 526 deletions(-) 0.7.555 47 files changed, 1764 insertions(+), 1436 deletions(-) 0.8.0223 97 files changed, 5994 insertions(+), 1300 deletions(-) 0.9.0366 200 files changed, 17683 insertions(+), 3726 deletions(-) HEAD 194 136 files changed, 10540 insertions(+), 3319 deletions(-) Hi, I found we tried to change some script to c file, such like lxc-create, but it is not accomplished yet, we can't create a container without -t option, You misunderstood. We are not getting rid of the templates. We replaced the lxc-create script with an lxc_create.c program using the lxccontainer.c API. Yes, I understand this. The lxc_create.c and the api do the actual basic container config creation and creation of the container rootfs. So lxc_create.c is planing to replace lxc_create.in, we'll delete lxc_create.in in the future, right? The templates are simply scripts which fill in the rootfs. Those *should* remain separate. In fact we probably should be hosting a repository of customized templates. (That gets a bit touchy - there are other projects doing the work of creating 'cloud images', and I don't care to duplicate their work.) are we going to finish it before lxc 1.0? Because it seems like a bug. Why? # lxc-create -n test -f config Segmentation fault This used to work. I looked through the code, it didn't handle the situation without -t option. Is this exactly what you want? Oh - lol - yeah maybe we should fix that :) Thanks for pointing that out. There's another thing missing, now that you mention it - if the template is passed in as a path, we should allow that (without prepending lxc- to it). -serge -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] 0.9.x versions before 1.0
On Wed, Jul 10, 2013 at 09:28:52PM -0500, Serge Hallyn wrote: Quoting Qiang Huang (h.huangqi...@huawei.com): On 2013/7/10 22:30, Serge Hallyn wrote: Quoting Qiang Huang (h.huangqi...@huawei.com): On 2013/7/10 6:05, Dwight Engen wrote: Hi guys, Just curious, has there been any thought about doing any more lxc versions 0.9.x before lxc 1.0? Seems like a few things have accumulated since 0.9.0. Just pulled this out of git for perspective: Name Commits Diffstat 0.7.0140 84 files changed, 4952 insertions(+), 2957 deletions(-) 0.7.177 files changed, 62 insertions(+), 15 deletions(-) 0.7.229 23 files changed, 532 insertions(+), 90 deletions(-) 0.7.323 17 files changed, 493 insertions(+), 162 deletions(-) 0.7.446 32 files changed, 1800 insertions(+), 526 deletions(-) 0.7.555 47 files changed, 1764 insertions(+), 1436 deletions(-) 0.8.0223 97 files changed, 5994 insertions(+), 1300 deletions(-) 0.9.0366 200 files changed, 17683 insertions(+), 3726 deletions(-) HEAD 194 136 files changed, 10540 insertions(+), 3319 deletions(-) Hi, I found we tried to change some script to c file, such like lxc-create, but it is not accomplished yet, we can't create a container without -t option, You misunderstood. We are not getting rid of the templates. We replaced the lxc-create script with an lxc_create.c program using the lxccontainer.c API. Yes, I understand this. The lxc_create.c and the api do the actual basic container config creation and creation of the container rootfs. So lxc_create.c is planing to replace lxc_create.in, we'll delete lxc_create.in in the future, right? The templates are simply scripts which fill in the rootfs. Those *should* remain separate. In fact we probably should be hosting a repository of customized templates. (That gets a bit touchy - there are other projects doing the work of creating 'cloud images', and I don't care to duplicate their work.) are we going to finish it before lxc 1.0? Because it seems like a bug. Why? # lxc-create -n test -f config Segmentation fault This used to work. I looked through the code, it didn't handle the situation without -t option. Is this exactly what you want? Oh - lol - yeah maybe we should fix that :) Thanks for pointing that out. There's another thing missing, now that you mention it - if the template is passed in as a path, we should allow that (without prepending lxc- to it). -serge To add to the you broke my lxc-create list, the new version also dropped the fancy header I introduced a while back (showing the template name, the arguments passed to it and the checksum of the template used at the time. An example was: # Template used to create this container: ubuntu # Parameters passed to the template: -a amd64 -r precise # Template script checksum (SHA-1): b1f15036868c53cca0698f1efcadd88dfefaee9b -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: Digital signature -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH 2/2] lxcapi_create: fix template handling
1. If no template is passed in, then do not try to execute it. The user
just wanted to write the configuration.
2. If template is passed in as a full path, then use that instead of
constructing '$templatedir/lxc-$template'.
Reported-by: Wanlong Gao gaowanl...@cn.fujitsu.com
Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
---
src/lxc/lxccontainer.c | 64 +-
1 file changed, 43 insertions(+), 21 deletions(-)
diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
index caf8c72..47d7df1 100644
--- a/src/lxc/lxccontainer.c
+++ b/src/lxc/lxccontainer.c
@@ -646,17 +646,6 @@ static bool lxcapi_stop(struct lxc_container *c)
return ret == 0;
}
-static bool valid_template(char *t)
-{
- struct stat statbuf;
- int statret;
-
- statret = stat(t, statbuf);
- if (statret == 0)
- return true;
- return false;
-}
-
/*
* create the standard expected container dir
*/
@@ -715,6 +704,46 @@ static struct bdev *do_bdev_create(struct lxc_container
*c, const char *type,
return bdev;
}
+/*
+ * Given the '-t' template option to lxc-create, figure out what to
+ * do. If the template is a full executable path, use that. If it
+ * is something like 'sshd', then return $templatepath/lxc-sshd. If
+ * no template was passed in, return NULL (this is ok).
+ * On error return (char *) -1.
+ */
+char *get_template_path(const char *t)
+{
+ int ret, len;
+ char *tpath;
+
+ if (!t)
+ return NULL;
+
+ if (t[0] == '/' access(t, X_OK) == 0) {
+ tpath = strdup(t);
+ if (!tpath)
+ return (char *) -1;
+ return tpath;
+ }
+
+ len = strlen(LXCTEMPLATEDIR) + strlen(t) + strlen(/lxc-) + 1;
+ tpath = malloc(len);
+ if (!tpath)
+ return (char *) -1;
+ ret = snprintf(tpath, len, %s/lxc-%s, LXCTEMPLATEDIR, t);
+ if (ret 0 || ret = len) {
+ free(tpath);
+ return (char *) -1;
+ }
+ if (access(tpath, X_OK) 0) {
+ SYSERROR(bad template: %s\n, t);
+ free(tpath);
+ return (char *) -1;
+ }
+
+ return tpath;
+}
+
static char *lxcbasename(char *path)
{
char *p = path + strlen(path) - 1;
@@ -854,20 +883,13 @@ static bool lxcapi_create(struct lxc_container *c, const
char *t,
{
bool bret = false;
pid_t pid;
- char *tpath = NULL;
- int partial_fd, ret, len;
+ char *tpath;
+ int partial_fd;
if (!c)
return false;
- len = strlen(LXCTEMPLATEDIR) + strlen(t) + strlen(/lxc-) + 1;
- tpath = malloc(len);
- if (!tpath)
- return false;
- ret = snprintf(tpath, len, %s/lxc-%s, LXCTEMPLATEDIR, t);
- if (ret 0 || ret = len)
- goto out;
- if (!valid_template(tpath)) {
+ if ((tpath = get_template_path(t)) 0) {
ERROR(bad template: %s\n, t);
goto out;
}
--
1.8.1.2
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
