On Wed, Jan 5, 2011 at 6:56 AM, Jason Parrott <fana...@gmail.com> wrote:
> On Jan 4, 7:13 pm, Patrick <kc7...@gmail.com> wrote: > > On Jan 4, 2011, at 10:42 AM, Jason Parrott wrote: > > > > > > > > > Greetings, > > > > > Our environment consists of about 600 Redhat Enterprise Linux 3, 4, 5, > > > and soon 6 servers. We use cfengine 2 currently, but plan on > > > migrating to puppet. Right now, we have our root-owned cfengine > > > client running every 15 minutes from cron contacting a single cfservd > > > server. Additionally, our employees start their own cfengine and > > > puppet instances on on some servers running under their various > > > service accounts to manage their own software configurations (for > > > example, the Hadoop team does not have root access, and runs as the > > > 'hadoop' user with a puppet instance running as 'hadoop'). Having > > > multiple configuration management daemons causes increased system load > > > and it generally seems wrong. > > > > > I'd like the ability to have one puppetmasterd with our normal set of > > > rules (after migrating from cfengine), but allow our users to add > > > their own manifests. The trick is that these manifests must run as > > > their service account and not as root. For example, I'd like to pull > > > in manifests from a hadoop/ directory, and any file edits, copies, > > > package installations, etc will run as the 'hadoop' user. > > > > > I've been thinking about adding a custom provider, one which wraps > > > commands with "su -c "command" hadoop", for example, but I'm not sure > > > how feasible this is. > > > > This still gives them root access. All they need to do is use a normal > provider. > > > > What about running both instances of puppet from cron? That should save > you the resources. > > Thanks for your input guys. Although it does seem the most simple > solution would be to run separate puppet client process in cron for > each user, I'm afraid it won't scale well long term for us. > > If this catches on beyond the dozen or so users we have now, I can > imagine 1000+ service users wanting to take advantage of puppet. At > that point, I'd be attempting to spread out the cron entries so that > they all didn't run at the same time, but at some point my server > would be running a cron entry every few seconds, or I'd have to lower > the frequency of updates . > > It seems smarter and have less overhead to let one client instance > running as root drop privileges on a per-module basis. Has anyone > thought of, or are there any plans to extend access controls to allow > modules to be contained as a user, or perhaps even inside a chroot? > I'd really love to have one puppet client instance run and not have to > add rules to manage cron entries for every service user on a > particular system. I could allow our employees to package and deploy > modules to our puppetmaster, and somehow guarantee that those modules > would be run in a secure way. > > As a short term solution, I like the idea of running an instance of > puppet from cron per service user. The root-owned instance would sync > the files, and the service-user-owned instances would read from their > particular subdirectory. However, I'm still interested in a long term > solution that doesn't involve the cron overhead across more than a > handful of users. > Can you put a feature request in for this please Jason? I can't promise anything, as I expect there are a fair few complicating factors that make implementing this non-trivial, but it's certainly worth capturing as a feature request. http://projects.puppetlabs.com/projects/puppet/ > > Thanks again, > > Jason > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com<puppet-users%2bunsubscr...@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-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
