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. 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 [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.
