Sudo cookbook and lwrp -- feedback needed

Chef Infra (archive)
1

dear chefs,

I have added an lwrp to the sudo cookbook. Msf (Matthieu St. F?),
hailing from lovely Osaka, made some important contributions to it

At its most basic, it wraps around an existing erb template, sets the
proper permissions, and fails noisily before a invalid fragment can
frag your sudo configuration

At the more advanced level, it uses generalized "patterns" of sudo
configurations. read for

This works for me, but as Atomic-penguin says, "A great chef creates
solutions that work for others, not just him/herself." feed back would
be most appreciated

sudo LWRP

This is a fairly complex LWRP for managing sudoers fragment files in
/etc/sudoers.d. It has many different options. Regardless
of which options you use, this lwrp will 1) make sure the permissions
on any sudoers fragment file are correct 2) fail the chef-client run
before trying to place an invalid fragment file in /etc/sudoers.d/ .
#2 ensures that your existing sudoers configuration will not be corrupted.

This LWRP operates in two modes, "template" and "pattern"

The simplest mode is template mode

sudo "nagios"
  template "nagios_sudoers.erb"
  variables( :cmds => [ "check_init_service",  "check_hpasm" ] )
end

This generates the file /etc/sudoers.d/nagios

# this file was generated by chef
nagios ALL=NOPASSWD: /usr/local/nagios/plugins/check_init_service
nagios ALL=NOPASSWD: /usr/local/nagios/plugins/check_hpasm

This mode essentially wraps around a the template resource to ensure
the resulting configuration is valid.

The template attribute sources the "nagios_sudoers.erb" file from the
calling cookbook, not the sudo cookbook. The variables attribute works
just like the variables attribute of the template resource.

Pattern mode is more complex. The purpose of pattern mode is to
abstract common "patterns" of sudo use so that the calling cookbook
doesn't have to supply them at all, the current patterns are:

  • super - full sudo access, essentially root access
  • app - The members of an application group can act as the same user
    that the application runs under and manage the application using the
    service command
  • act_as_all - user/group can execute the supplied commands as any user

These patterns use templates in this cookbook, templates/default/#{pattern}

Example using a pattern

sudo "tomcat" do
  user "tomcat"
  pattern "app"
end

This generates the following

 # This file is generated by Chef, all manual changes will be overriden
 %geo     ALL=(geo) NOPASSWD:ALL
 %geo     ALL=(root)  NOPASSWD: /sbin/service geo [a-zA-Z]*

Description of all attributes

  • :user -- user to provide sudo privileges to
  • :group -- group to provide sudo privileges to
  • :service -- specific to the "app" pattern, used when the service to
    be manipulated has an different name than the user it runs as
  • :cmds -- an array of commands that the user/group can execute using
    sudo, must use the full path
  • :passwordless -- whether or not a password must be supplied when
    invoking sudo
  • :pattern -- use a template built into the sudo cookbook, the default
    is "act_as_all"
  • :template -- a template file in the current cookbook (not the sudo
    cookbook), currently must be an erb template
  • :variables -- variables to use with the template
2

The documentation needs more examples. Its ambiguous given the number
of LWRP parameters, and the descriptions for each of them.

The pattern mode seems quite complicated, but perhaps its just
under-documented given its complexity. You’ve shown 2 parameters in an
example, when you have 8 parameters altogether. Could you describe
defaults for each of the 8 pattern parameters in the documentation to
make it more clear?

3

alright I will work on improving the docs and better explaining the
attributes. I will also harrass Mathieu Sauve-Frankel to get some more
great ideas of him. Unfortunately, I probably won't get around to this
today :frowning:

On Fri, Dec 16, 2011 at 6:09 AM, Eric G. Wolfe eric.wolfe@marshall.edu wrote:

The documentation needs more examples. Its ambiguous given the number of
LWRP parameters, and the descriptions for each of them.

The pattern mode seems quite complicated, but perhaps its just
under-documented given its complexity. You've shown 2 parameters in an
example, when you have 8 parameters altogether. Could you describe defaults
for each of the 8 pattern parameters in the documentation to make it more
clear?

4

On Dec 16, 2011, at 1:21, Bryan Berry wrote:

sudo LWRP

This is a fairly complex LWRP for managing sudoers fragment files in
/etc/sudoers.d. It has many different options. Regardless
of which options you use, this lwrp will 1) make sure the permissions
on any sudoers fragment file are correct 2) fail the chef-client run
before trying to place an invalid fragment file in /etc/sudoers.d/ .
#2 ensures that your existing sudoers configuration will not be corrupted.

The name may confuse potential users. I would think that this resource allows running some command with "sudo". I would suggest renaming it to something like "sudoers", "sudo_config" or the like.

5

hah! that was my original idea actually, to make the resource name
actually "sudo_ers"

On Fri, Dec 16, 2011 at 8:29 AM, Maxim Kulkin maxim.kulkin@gmail.com wrote:

On Dec 16, 2011, at 1:21, Bryan Berry wrote:

sudo LWRP

This is a fairly complex LWRP for managing sudoers fragment files in
/etc/sudoers.d. It has many different options. Regardless
of which options you use, this lwrp will 1) make sure the permissions
on any sudoers fragment file are correct 2) fail the chef-client run
before trying to place an invalid fragment file in /etc/sudoers.d/ .
#2 ensures that your existing sudoers configuration will not be corrupted.

The name may confuse potential users. I would think that this resource allows running some command with "sudo". I would suggest renaming it to something like "sudoers", "sudo_config" or the like.