Quoting Jäkel, Guido (g.jae...@dnb.de): > Hi Serge, > > >> to assist to avoid such problems i would propose to introduce macro > >> expansion (of the own tags but also by incorporating the > >environment variables) into the configuration argument parser and to provide > >some useful basics like the container name. Then one may > >use e.g. > >> > >> lxc.hook.mount = $MYCONTAINER_HOME/hooks/$lxc.name > > > >That sounds good. Would you be able to post a patch to do this?
Ok, so along the lines of this, I propose (and will send a patch soon if there are no objections) the following behavior for lxc-clone: 1. hook files only get copied if they are in $lxpath/$lxc_name 2. hook files do not get 'updated'. They should be using the container name and lxcpath from environment/arguments 3. configuration file will expand $p to lxcpath and $n to lxcname (with \$ for escaping $ though I can't see anyone doing that). 4. $lxcpath/$lxcname/fstab and lxc.mount.entries should not need to be updated. The destination should be relative to the mounted container root. I don't know of any cases where the source is relative to the container itself. If there are such cases, then we can add $p and $n expansion to ONLY the mount source. 5. lxc_clone will update the container name in lxc.utsname only. -serge ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users