On Jan 5, 10:59 am, Nigel Kersten <[email protected]> wrote: > On Wed, Jan 5, 2011 at 6:56 AM, Jason Parrott <[email protected]> wrote: > > On Jan 4, 7:13 pm, Patrick <[email protected]> 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 >
Absolutely. Thanks Nigel. http://projects.puppetlabs.com/issues/5779 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
