Quoting Michael H. Warfield ([email protected]): > Hey all, > > I'm in the middle of some cleanup and fix-ups in the Fedora and CentOS > templates including hardening the root password and some static MAC > address code and generally reconciling the two templates into some > semblance of coherency. > > I noticed this in the comments emitted from the CentOS template into the > container config: > > #lxc.network.veth.pair = v-$name-e0 > > Hmmm... That's interesting. I wonder if that would work in the default > config? That could be real handy (subject to name collisions > understood.) Nope. It's a literal copy from the default config over to > the initial starting point container config. Sigh... > > That's an idea, though, if variables could be expanded. That's easy > enough to deal with in the templates. Since I'm already recopying that > initialized config to add some hwaddr addresses (in my upcoming > patches), I can add this to those templates and do the expansions > (reading from the initial default config and copying back to the target > config)... > > # This should catch variable expansions from the default config... > if expr "${LINE}" : '.*\$' > /dev/null 2>&1 > then > LINE=$(eval "echo \"${LINE}\"") > fi > > I've got that working and will submit it along with my other patches > shortly... > > It's a thought, though there may be other ways we could do this. It > could be useful. I can use it. Does no harm if nobody puts environment > variables in the default config. Not sure what the potential for random > acts of terrorism is if someone stuffs something STUPID in there... > Simple expansions like above are prone to abuse in unexpected ways... > Other shell meta characters could be a PITA... > > Thoughts?
Sounds reasonable. _______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
