[lxc-devel] [PATCH 1/6] Move lxcbr0 setup logic into lxc.net script

[Serge Hallyn]

Quoting Martin Pitt (martin.pitt at ubuntu.com):
> Hey Serge,
> 
> Serge Hallyn [2014-07-31 17:46 +0000]:
> > Note there is no Signed-off-by line here.  (git commit -s will add one)
> 
> Right, do you need one? I'm already the Author:, so signing off my own
> commits seems a little redundant?

But just because you sent the patch doesn't guarantee that you're the
author :)  If you can just reply to this email with something like

"""
Signed-off-by: ...
for the whole set
"""

that'll do.


> > Now, if we're going to move this out of upstart, should we be putting
> > in full paths for all of the commands?  Who knows how admins will get to
> > the script...
> 
> Not sure what you mean here, you mean the full path for things like
> iptables, brctl, dnsmasq? I really wouldn't want to do that -- that
> would make the script highly platform dependant and break the
> possibility of using /usr/local/bin etc.

We could detect all the tools in configure.in, use @IPTABLES@ etc in
the script, and process the script at build time.

> For an upstart context this doesn't change anything -- the upstart
> job has a default $PATH set which gets inherited by calling lxc.net
> from the job:
> 
> > > +pre-start exec /usr/share/lxc/lxc.net start
> > > +post-stop exec /usr/share/lxc/lxc.net stop
> 
> For systemd units it is similar. At least it works fine under a

Ok, then I guess we can wait on this.  I'm more worried about the
sysvinit case, but it's not yet using the script.

> Debian/Ubuntu context, I haven't tested it under Fedora; but it would
> be weird if their tools wouldn't be in $PATH for the root user?

The concern isn't the tools not being under $PATH, but exploit versions
being put into a mangled path.

-serge