Hi Richard, I'm not certain Puppet itself will be able to fill that role properly. AFAIK there's no way to limit certain manifests access to specific directories, or prevent others from breaking your code. Even with a bunch of testing, en error in some manifest could cause catalog compilation errors. Someone please correct me if I'm wrong.
I think you'll need to abstract the data from the Puppet code. Perhaps, you can code a layer around the features your users need. Maybe a defined type or a provider/type that users can use, combined with a simple code-review tool (like Gerrit) where trusted users can review the suggested changes. You could set up Hiera to pull data from a database or other source. Allow the semi-trusted users to enter that data into the database via a web-app or whatever. Maybe even giving them access to a directory That way you control the Puppet code, hence limiting what the users are allowed to change. They activate parts of the code by providing data via Hiera. Another option is to use something different altogether, though you have probably considered this already. We use Capistrano (actually Webistrano, a web frontend for it) to allow developers to deploy to production servers. Puppet manages the directory structure, deploy-users and permissions. Capistrano deploys the web application from version-control and performs various pre- and post-scripts such as symlinking to shared assets and flushing caches. We're starting to manage Solr cores via Capistrano as well, where we previously used Puppet to do that. Although it worked with Puppet, we ran into similar problem as you: allowing semi-trusted people to manage Solr cores without having them break Puppet turned out to be tricky. We use the basic authentication of Webistrano to control who's allowed to do a deploy. Capistrano is not limited to deploying code from version-control. It's just Ruby. You could write pretty much any script you want. Maybe you could tell us a bit more about the type of actions the users need to be able to perform, so we'll know what would or wouldn't work. Regards, Martijn Op maandag 8 april 2013 13:03:27 UTC+2 schreef Richard het volgende: > > Hi All, > > I'm currently using puppet to deploy our O/S configuration to servers. > I've got a requirement to allow a semi-trusted set of external users to > deploy application configuration onto these same hosts. For example, > they'd be allowed to configure anything under a /apps directory. > > What would be the best way to achieve this? Ideally, I don't think I want > to give them access to our puppet master, although if we really had to we > could, and restrict them to a set of directories on the master using > appropriate permissions. > > Should I think about running a second puppet master - either under a > different user or on a different host? > > Can a puppet client talk to multiple masters? > > Is there any way to restrict them so they can only write modules that > update files under the /apps filesystem? For example, if I'm populating > /etc/hosts via an existing class, I don't want them to be able to write > something that conflicts with this. > > Perhaps I should be using environments for this type of setup? > > Any pointers would be welcome. > > Many thanks, > > Richard. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
