Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

the sysadmins are present in the sudoers files of all environments, but other sudoers are not. Different environments all have slightly different sudoers. Most of the time, 90% of users are the same, and 10% vary so we cannot have only one sudoers file for everything.

Right now, we are using puppet with 10 different files with names like sudoers.production1, sudoers.production2, sudoers.production3, sudoers.testing1, sudoers.staging1 and so forth.

Puppet then picks the file to deploy based on the server's $domain (ex: dbserver.staging1.acme.com) or $hardwaremodel. It works fine but it's a nightmare to maintain so many files.

I'd like to autogenerate sudoers files based on the server's domain and have only one big file with all the sudoers permissions for all users and all environments. Something that looks like:

User_Alias ADMINS = abe, bob, carol, dave

case $domain {
 "staging1.acme.com" {
    #add dev1,dev2,tester1,tester2 to sudoers file 
  }
 "testing2.acme.com" {
    #add tester1, tester3, tester4 to sudoers file
  }    

What's the best way to go about this? Suggestions for alternatives are welcome. I'd appreciate any tips.

Update 1:

For security reasons, we'd rather not concatenate a bunch of files from a folder located on a puppet client in case someone puts a file in there (maliciously or not) and either breaks the combined file or inserts something in it.

Most importantly, for usability, we'd like to keep the number of sudoers related files (fragment or complete) on puppet server to either 3 (prod/stage/test) or preferably 1 file. this file would (somehow) generate sudoers files on the puppet server and send one customized file to each puppet client.

The purpose of this would be only searching for a username in a single file and removing it quicker than doing it on 11 files. When adding a user to a bunch of environments, it won't be as quick, but only one file would need to be opened and looked at, greatly reducing the chances of an omission.

our Sudo version is 1.6.9p8 so we can't use /sudoers.d folder, only a sudoers file.

Update2:

I've been googling some and I just found this, which I've spent the past hour looking at:

https://github.com/saz/puppet-sudo#readme

I'm not certain but it looks like it might do the trick. Has anyone used it or heard about it?

share|improve this question
add comment

3 Answers

up vote 8 down vote accepted

What version of sudo? Does your version of sudo support using #includedir option to break things out into a fragment directory /etc/sudoers.d/?

If so, then I suggest you use that functionality to build your config.

Have your main config file delivered to /etc/sudoers that includes all the settings that is common to every host you control. Then have role-specific configuration get dropped into a file within /etc/sudoers.d/.

Each class or puppet section is responsible for updating the small portion of the sudo config directly related to that class.

share|improve this answer
    
Oooh, that could be nice. Is that available in CentOS/RHEL? –  ewwhite Dec 4 '12 at 18:14
    
we have Sudo version 1.6.9p8. We are not currently using sudoers.d folders. maybe because the solaris version of sudo we're using doesn't support it? –  gozu Dec 4 '12 at 18:16
    
@ewwhite, from what I read it is available in RHEL 5.5 and above. Haven't tested though. rhn.redhat.com/errata/RHBA-2010-0212.html –  Zoredache Dec 4 '12 at 18:41
    
@gozu, the #includedir is a relatively new option. It wouldn't surprise me that it isn't supported everywhere. If that is not available, then you can achieve similar functionality using a concatenate pattern. Basically you deliver all the fragements, and then have some tool merge them into a single file. See github.com/ripienaar/puppet-concat or projects.puppetlabs.com/projects/puppet/wiki/… and serverfault.com/a/441048/984 –  Zoredache Dec 4 '12 at 18:45
    
For security reasons, we'd rather not concatenate a bunch of files from a folder in case someone puts a file in there (maliciously or not) and breaks the file or inserts something in the sudoers file. Most importantly, for usability, we'd like to keep the number of sudoers related files (fragment or complete) on puppet server to either 3 (prod/stage/test) or preferably 1 file. this file would (somehow) generate sudoers files on the puppet server and send one customized file to each puppet client. –  gozu Dec 4 '12 at 20:15
show 1 more comment

look at virtual resources and realize - http://docs.puppetlabs.com/guides/virtual_resources.html - this does exactly that - on some systems you 'realize' the resource and on some you don't.

share|improve this answer
    
Thanks, I'm looking into it :) –  gozu Dec 5 '12 at 16:36
    
Any examples you know of? It's an interesting approach. –  gozu Dec 6 '12 at 18:18
    
make something that can be included by all systems - let's call it base so class base { @user { sysadmin: ensure => present } } and then on the systems where you want to include this you just 'realize' it as class admins { include base; User <| title == sysadmin |> } - there is also a function called realize that behaves a bit different. For the systems where you want the database users you proceed the same - include base and if you want to 'realize' the user you just use the above example - Basically what virtual resources give is the ability to include the resource on multiple hosts. –  silviud Dec 7 '12 at 18:49
add comment

You can do with using Puppet templates... Site-specific configuration with a small ruby snippet/variable for the user you need. (I'll post an example later)

The traditional way of handling this is by using group definitions instead of named-users in your /etc/sudoers. It may be less of a hassle to manage.

share|improve this answer
    
That'd be great! Thanks. –  gozu Dec 4 '12 at 20:02
    
Don't forget the possibility of using unix groups to handle this. –  ewwhite Dec 5 '12 at 5:42
    
I'm not sure what you mean exactly. We are already using groups in the sudoers files right now. admin group, tester group, etc. But on any environment, there are anywhere from 2 to 12 "special" singleton users who can't be grouped with anybody else. I think you're right that puppet templates are the way to go for me. Hopefully your example will help me grok it. In the meantime I'm reading up on puppet templates. Suggestions are welcome :) –  gozu Dec 5 '12 at 16:35
    
Have you been able to find that example? I'd like to see it before I decide :) –  gozu Dec 6 '12 at 18:16
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.