On Wed, Sep 17, 2014 at 1:47 PM, Lennart Regebro rege...@gmail.com wrote:
While writing a blog post about software configuration management I looked
into buildout, and using it as an SCM tool. And it has one big restriction:
You can't run certain parts as root.
I think adding that would actually not be too hard. Are there any principal
arguments against it? I looked at making an extension, but I would need a
hook that is run before and after each step in that case.
I was thinking that you could define which parts should run as root in one
of two ways:
1. A parameter in the part config
2. Having a global configuration with a list of parts. This for the case
when the parts recipe itself has a parameter that clashes with the parameter
in 1.
I'm leaning towards having a setuid parameter, so you can set to other id's
than 0.
Technically it would be done by setuid to root for the configured parts, and
then back after it has run. You would have to run buildout as a whole with
sudo for this to work. It would use the login name as the normal setuid,
unless configured explicitly with a global setuid parameter.
Thoughts?
We deploy to production with buildout and have never needed this.
Our approach is to have separate buildouts for building software
(RPMs currently) and for deploying to production machines.
The deployment buildouts are run as root (typically from another
process that runs from root, https://bitbucket.org/zc/zkdeployment).
These 2 buildouts are run at very different times and situations.
A better approach IMO is to deploy with Docker. With Docker,
all of your deployment is done when you build an image, still as root.
Unfortunately, our current scheme is working well enough and we have
enough other priorities that I fear I won't find time to dockerfy our
processes soon.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
