1

I have saz-sudo installed and have created a site_sudo module based (I hope) on it. Here's what I have in my site_sudo/manifest/init.pp file:

class { 'site_sudo': }
    sudo::conf { 'web':
      source => 'puppet:///files/etc/sudoers',
    }
    sudo::conf { 'syseng':
      priority => 10,
      content  => "%sysadm ALL=(ALL) NOPASSWD: ALL",
    }

include sudo

No matter what I do, the sudoers file on the target is always overwritten with the sudoers.rhel6 file from saz-sudo module.

I'm using common.yaml too:

classes:
  - site_sudo
1
  • You really should not indent your sudo::conf declarations like that, seeing as they are in the same context as the class {} and include statements. May 28, 2014 at 10:20

4 Answers 4

2

Is that an exact copy from your file? The class { 'site_sudo': } line would include that class into the config, not define the class as you should be doing in the init.pp for the module. This will prevent the rest of the config in the file from being applied (since this file is only being evaluated to load that class; the other lines won't be evaluated as they would in an import statement).

Instead, it should look like this:

class site_sudo { 
  include sudo
  sudo::conf { 'web':
    source => 'puppet:///files/etc/sudoers',
  }
  sudo::conf { 'syseng':
    priority => 10,
    content  => "%sysadm ALL=(ALL) NOPASSWD: ALL",
  }
}
6
  • Worth noting that the import statement is deprecated and will be removed soon: docs.puppetlabs.com/puppet/latest/reference/lang_import.html May 28, 2014 at 6:59
  • You got confused by the bad indenting by the OP. class { 'site_sudo': } is an awkward way of saying include site_sudo, and not in fact defining the class. If you would want to define it, you would need to do away with the : and move the { to the end of the line - class site_sudo { ... } May 28, 2014 at 10:12
  • Thanks to everyone for all the help. I typed import when I meant to type include :P
    – mr.zog
    May 28, 2014 at 14:26
  • So this sufficed to stop the module from overwriting sudoers? Weird. May 28, 2014 at 15:30
  • @FelixFrank Yeah - he was saying it was the site_sudo's init.pp, so I was thinking defining the class was the desired result. Forgot to fix all the syntax for that. I think there's some tricky logic in that sudo module which will drop a default config in if none of its defined types are realized or some such trickery (more clever and opaque than I would like..), causing that behavior. May 28, 2014 at 17:46
3

According to the README, you need to send a parameter to the sudo class:

class { 'sudo':
  config_file_replace => true,
}

instead of plain

include sudo

which clobbers /etc/sudoers as stated.

0

Check out the README and class sudo::configs.

The used convention is rather strange (IMHO it would be easier to just add a hash parameter to class sudo)... but it seems to work quite well with Hiera.

For your example values:

classes:
  - sudo 
  - sudo::configs

sudo::configs:
    'syseng':
        'priority'  : 10
        'content'   : "%sysadm ALL=(ALL) NOPASSWD: ALL"
0

saz/sudo is designed to use a sudoers.d file and #include that. This is why it overwrites your sudoers file with a clean one, to be sure that it's the correct file. Those sudo::conf declarations will cause a file to show up in /etc/sudoers.d instead of changing /etc/sudoers directly.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .