[lxc-devel] [PATCH 1/1] resolve lxcpath and rcfile arguments
Serge Hallyn
serge.hallyn at ubuntu.com
Tue Nov 5 13:30:17 UTC 2013
Quoting Stéphane Graber (stgraber at ubuntu.com):
> On Mon, Nov 04, 2013 at 02:44:44PM -0600, Serge Hallyn wrote:
> > So we don't always have to give full paths.
> >
> > realpath(x,NULL) mallocs memory, but these paths shouldn't get called
> > from the API so not freeing should be ok.
> >
>
> What's the reason behind this change?
Simply that as I test unprivileged lxc I'm having to do
lxc-create -t ubuntu-cloud -P /home/serge/lxcbase -f /home/serge/lxc.conf -n a1 -- -r saucy
lxc-start -P /home/serge/lxcbase -n a1
lxc-stop -P /home/serge/lxcbase -n a1 -K
and it gets a bit old. But maybe (in the fresh light of morning) I'm better
off adding a per-user lxc.conf file that specifies default lxcpath and
lxc.conf to use.
> Am I reading this right that this will only affect cases where -P is
> passed and that the default value won't be resolved?
>
> In any case, I suspect this change is incomplete since we also support
> -P in some of the python tools which wouldn't be resolved, leading to
> lxc-info and others to fail to find the container (if for example
> /var/lib/lxc is a symlink to say /data/containers).
>
>
> > Signed-off-by: Serge Hallyn <serge.hallyn at ubuntu.com>
> > ---
> > src/lxc/arguments.c | 9 ++++++++-
> > src/lxc/lxc_execute.c | 10 +++++++---
> > src/lxc/lxc_start.c | 9 +++++++++
> > 3 files changed, 24 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/lxc/arguments.c b/src/lxc/arguments.c
> > index adcf8fe..65b2284 100644
> > --- a/src/lxc/arguments.c
> > +++ b/src/lxc/arguments.c
> > @@ -155,6 +155,7 @@ See the %s man page for further information.\n\n",
> > static int lxc_arguments_lxcpath_add(struct lxc_arguments *args,
> > const char *lxcpath)
> > {
> > + char *resolved_path = NULL;
> > if (args->lxcpath_additional != -1 &&
> > args->lxcpath_cnt > args->lxcpath_additional) {
> > fprintf(stderr, "This command only accepts %d -P,--lxcpath arguments\n",
> > @@ -168,7 +169,13 @@ static int lxc_arguments_lxcpath_add(struct lxc_arguments *args,
> > lxc_error(args, "no memory");
> > return -ENOMEM;
> > }
> > - args->lxcpath[args->lxcpath_cnt++] = lxcpath;
> > + resolved_path = realpath(lxcpath, NULL);
> > + if (!resolved_path) {
> > + perror("realpath");
> > + fprintf(stderr, "Error resolving lxcpath %s", lxcpath);
> > + return -1;
> > + }
> > + args->lxcpath[args->lxcpath_cnt++] = resolved_path;
> > return 0;
> > }
> >
> > diff --git a/src/lxc/lxc_execute.c b/src/lxc/lxc_execute.c
> > index 6a54bf6..083b5db 100644
> > --- a/src/lxc/lxc_execute.c
> > +++ b/src/lxc/lxc_execute.c
> > @@ -105,9 +105,13 @@ int main(int argc, char *argv[])
> > return -1;
> >
> > /* rcfile is specified in the cli option */
> > - if (my_args.rcfile)
> > - rcfile = (char *)my_args.rcfile;
> > - else {
> > + if (my_args.rcfile) {
> > + rcfile = realpath((char *)my_args.rcfile, NULL);
> > + if (!rcfile) {
> > + SYSERROR("Failed to resolve file path: %s", my_args.rcfile);
> > + return -1;
> > + }
> > + } else {
> > int rc;
> >
> > rc = asprintf(&rcfile, "%s/%s/config", my_args.lxcpath[0], my_args.name);
> > diff --git a/src/lxc/lxc_start.c b/src/lxc/lxc_start.c
> > index add2542..7eea26a 100644
> > --- a/src/lxc/lxc_start.c
> > +++ b/src/lxc/lxc_start.c
> > @@ -173,6 +173,15 @@ int main(int argc, char *argv[])
> >
> > const char *lxcpath = my_args.lxcpath[0];
> >
> > + if (my_args.rcfile) {
> > + char *r = realpath(my_args.rcfile, NULL);
> > + if (!r) {
> > + SYSERROR("Failure resolving path: %s", my_args.rcfile);
> > + exit(1);
> > + }
> > + my_args.rcfile = r;
> > + }
> > +
> > /*
> > * rcfile possibilities:
> > * 1. rcfile from random path specified in cli option
> > --
> > 1.8.1.2
> >
> >
> > ------------------------------------------------------------------------------
> > November Webinars for C, C++, Fortran Developers
> > Accelerate application performance with scalable programming models. Explore
> > techniques for threading, error checking, porting, and tuning. Get the most
> > from the latest Intel processors and coprocessors. See abstracts and register
> > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Lxc-devel mailing list
> > Lxc-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/lxc-devel
>
> --
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com
More information about the lxc-devel
mailing list