Puppet users - Dec 2010 - Running puppet as non-root user

Hi.

Lets say that for several administrative/burocratic/procedural reasons, you
dont have the option of running puppet as root, in any way - not as a daemon
on the managed node, nor as root on the command line with puppet apply. Say,
you are the "middleware" application team and you dont have the rights
to
touch any part of the server that are not your apache/tomcat/whatever
instances, so you run puppet under your "middleware" account(s)

Do you think there is still value to be obtained from puppet with this
limitation? Anybody running it that way and wants to share why and what
benefits do they get? For what I can see it should be possible but then you
throw out a lot of functionality - your manifests cant do things like ensure
an user or a package are installed, cause that needs root, probably you cant
even start the services if they use privileged ports unless somebody else
defined a sudo for you to do it, but you can deploy files under your user,
instantiate templates, maybe.... maybe with correct reporting tell the
"system" level guys that you need X or Y done when the manifest dies
cause
it is not in place, etc.

------------------------------

Jesús Couto F.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi.
On Dec 13, 2010, at 1:30 PM, Jesús Couto wrote:
> Hi.
> 
> Lets say that for several administrative/burocratic/procedural reasons, you
dont have the option of running puppet as root, in any way - not as a daemon on
the managed node, nor as root on the command line with puppet apply. Say, you
are the "middleware" application team and you dont have the rights to
touch any part of the server that are not your apache/tomcat/whatever instances,
so you run puppet under your "middleware" account(s)
> 
> Do you think there is still value to be obtained from puppet with this
limitation? Anybody running it that way and wants to share why and what benefits
do they get? For what I can see it should be possible but then you throw out a
lot of functionality - your manifests cant do things like ensure an user or a
package are installed, cause that needs root, probably you cant even start the
services if they use privileged ports unless somebody else defined a sudo for
you to do it, but you can deploy files under your user, instantiate templates,
maybe.... maybe with correct reporting tell the "system" level guys
that you need X or Y done when the manifest dies cause it is not in place, etc.
my customer has different departments who have different responsibilities.
the unix team started with puppet implementation on os level.
very soon an application team learned about puppet and asked for inclusion of
their config files but were forced to use their own puppetmaster.

we now have two puppetmasters and two instances of puppetclient running on a
server:
one client is used for base os and one for the application configuration.

the base os puppet client runs in daemon mode and connects every 30 minutes to
puppetmaster
the application puppet is running in application user space (non-root) and runs
in listen mode.
the application team can initiate a puppetrun on their application puppetmaster.

another option which was discussed but declined was using different or cascaded
vcs repositories.

Martin

> ------------------------------
> 
> Jesús Couto F.
> 
> -- 
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Mon, Dec 13, 2010 at 23:30, Jesús Couto <jesus.couto@gmail.com> wrote:
> Lets say that for several administrative/burocratic/procedural reasons, you
> dont have the option of running puppet as root, in any way - not as a
daemon
> on the managed node, nor as root on the command line with puppet apply.
Say,
> you are the "middleware" application team and you dont have the
rights to
> touch any part of the server that are not your apache/tomcat/whatever
> instances, so you run puppet under your "middleware" account(s)
>
> Do you think there is still value to be obtained from puppet with this
> limitation?
Yes.  Like Martin, I would still deploy puppet in this mode: you get
all the management benefits of puppet without having to be root,
albeit with a more limited set of things you can manage.  Having it
make sure your application is right, and all the dependencies are
there, is still a big win. :)

Regards,
    Daniel
-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
              ♽ made with 100 percent post-consumer electrons

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Ok, so, not as strange and uncommon practice as I thought :-P

So what do you do in your manifests? I mean, do you code the manifest so you
never, ever get to any place Puppet is going to croak due to not being root
(that would mean, probably, just exporting template and config files under
your accounts), or do you do and then use the error as a way to report the
failed dependencies to whoever its in charge of fixing them? (The "root
Puppet" in Martin case, or just the "operating system" team in
general)

It looks to me like it will cut a lot of the advantages of having your
machine configuration inside a tool that can replicate it at will, but
sometimes the difficult problems are not technical but political :-/
------------------------------

Jesús Couto F.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.