Running puppet as non-root user
Jesús Couto
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.
Martin Alfke
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...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Daniel Pittman
> 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 ✉ dan...@rimspace.net ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
Jesús Couto
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.