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=48808831&iu=/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=48808831&iu=/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=48808831&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] 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 1&2 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
Acked-by: Serge E. Hallyn
>
> ---
> 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
Re: [lxc-devel] [PATCH] fix potential out of bounds pointer deref
Quoting Dwight Engen (dwight.en...@oracle.com):
> I noticed that if find_first_wholeword() is called with word at the very
> beginning of p, we will deref *(p - 1) to see if it is a word boundary.
> Fix by considering p = p0 to be a word boundary.
>
> Signed-off-by: Dwight Engen
Acked-by: Serge E. Hallyn
thanks,
-serge
> ---
> src/lxc/lxccontainer.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
> index 4dbb587..245d5eb 100644
> --- a/src/lxc/lxccontainer.c
> +++ b/src/lxc/lxccontainer.c
> @@ -1534,13 +1534,16 @@ static int is_word_sep(char c)
> }
> }
>
> -static const char *find_first_wholeword(const char *p, const char *word)
> +static const char *find_first_wholeword(const char *p0, const char *word)
> {
> + const char *p = p0;
> +
> if (!p)
> return NULL;
>
> while ((p = strstr(p, word)) != NULL) {
> - if (is_word_sep(*(p-1)) && is_word_sep(p[strlen(word)]))
> + if ((p == p0 || is_word_sep(*(p-1))) &&
> + is_word_sep(p[strlen(word)]))
> return p;
> p++;
> }
> --
> 1.8.1.4
>
>
> --
> 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=48808831&iu=/4140/ostg.clktrk
> ___
> Lxc-devel mailing list
> Lxc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel
--
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=48808831&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 2/2] oracle template: use clonehostname hook script
Quoting Stéphane Graber (stgra...@ubuntu.com): > On Tue, Jul 09, 2013 at 02:44:36PM -0400, Dwight Engen wrote: > > Signed-off-by: Dwight Engen > > Acked-by: Stéphane Graber > > Please don't push until we push the final version of 1/2. Both pushed. -- 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=48808831&iu=/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
Hi Serge, On Wed, Jul 10, 2013 at 10:36 AM, Serge Hallyn wrote: > 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 -- 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=48808831&iu=/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 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? > > -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=48808831&iu=/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=48808831&iu=/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=48808831&iu=/4140/ostg.clktrk___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [PATCH 1/2] lxcapi_create: split out the template execution
Make it its own function to make both more readable.
Signed-off-by: Serge Hallyn
---
src/lxc/lxccontainer.c | 215 +++--
1 file changed, 118 insertions(+), 97 deletions(-)
diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
index 245d5eb..caf8c72 100644
--- a/src/lxc/lxccontainer.c
+++ b/src/lxc/lxccontainer.c
@@ -715,115 +715,34 @@ static struct bdev *do_bdev_create(struct lxc_container
*c, const char *type,
return bdev;
}
-static bool lxcapi_destroy(struct lxc_container *c);
-/*
- * lxcapi_create:
- * create a container with the given parameters.
- * @c: container to be created. It has the lxcpath, name, and a starting
- * configuration already set
- * @t: the template to execute to instantiate the root filesystem and
- * adjust the configuration.
- * @bdevtype: backing store type to use. If NULL, dir will be used.
- * @specs: additional parameters for the backing store, i.e. LVM vg to
- * use.
- *
- * @argv: the arguments to pass to the template, terminated by NULL. If no
- * arguments, you can just pass NULL.
- */
-static bool lxcapi_create(struct lxc_container *c, const char *t,
- const char *bdevtype, struct bdev_specs *specs,
- char *const argv[])
+static char *lxcbasename(char *path)
{
- bool bret = false;
- pid_t pid;
- char *tpath = NULL, **newargv;
- int partial_fd, ret, len, nargs = 0;
-
- if (!c)
- return false;
+ char *p = path + strlen(path) - 1;
+ while (*p != '/' && p > path)
+ p--;
+ return p;
+}
- len = strlen(LXCTEMPLATEDIR) + strlen(t) + strlen("/lxc-") + 1;
- tpath = malloc(len);
+static bool create_run_template(struct lxc_container *c, char *tpath,
+ char *const argv[])
+{
+ pid_t pid;
+
if (!tpath)
- return false;
- ret = snprintf(tpath, len, "%s/lxc-%s", LXCTEMPLATEDIR, t);
- if (ret < 0 || ret >= len)
- goto out;
- if (!valid_template(tpath)) {
- ERROR("bad template: %s\n", t);
- goto out;
- }
-
- if (!c->save_config(c, NULL)) {
- ERROR("failed to save starting configuration for %s\n",
c->name);
- goto out;
- }
-
- /* container is already created if we have a config and rootfs.path is
accessible */
- if (lxcapi_is_defined(c) && c->lxc_conf && c->lxc_conf->rootfs.path &&
access(c->lxc_conf->rootfs.path, F_OK) == 0)
- goto out;
-
- /* Mark that this container is being created */
- if ((partial_fd = create_partial(c)) < 0)
- goto out;
-
- /* no need to get disk lock bc we have the partial locked */
-
- /*
-* Create the backing store
-* Note we can't do this in the same task as we use to execute the
-* template because of the way zfs works.
-* After you 'zfs create', zfs mounts the fs only in the initial
-* namespace.
-*/
- pid = fork();
- if (pid < 0) {
- SYSERROR("failed to fork task for container creation
template\n");
- goto out_unlock;
- }
-
- if (pid == 0) { // child
- struct bdev *bdev = NULL;
-
- if (!(bdev = do_bdev_create(c, bdevtype, specs))) {
- ERROR("Error creating backing store type %s for %s",
- bdevtype ? bdevtype : "(none)", c->name);
- exit(1);
- }
-
- /* save config file again to store the new rootfs location */
- if (!c->save_config(c, NULL)) {
- ERROR("failed to save starting configuration for %s\n",
c->name);
- // parent task won't see bdev in config so we delete it
- bdev->ops->umount(bdev);
- bdev->ops->destroy(bdev);
- exit(1);
- }
- exit(0);
- }
- if (wait_for_pid(pid) != 0)
- goto out;
-
- /* reload config to get the rootfs */
- if (c->lxc_conf)
- lxc_conf_free(c->lxc_conf);
- c->lxc_conf = NULL;
- if (!load_config_locked(c, c->configfile))
- goto out;
+ return true;
- /*
-* now execute the template
-*/
pid = fork();
if (pid < 0) {
SYSERROR("failed to fork task for container creation
template\n");
- goto out_unlock;
+ return false;
}
if (pid == 0) { // child
char *patharg, *namearg, *rootfsarg, *src;
struct bdev *bdev = NULL;
int i;
+ int ret, len, nargs = 0;
+ char **newargv;
if (unshare(CLONE_NEWNS) < 0) {
ERROR("error unsharing mounts
[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
Signed-off-by: Serge Hallyn
---
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=48808831&iu=/4140/ostg.clktrk
___
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
