Quoting Martin Pitt ([email protected]): > 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 _______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
