New sudo lwrp for managing sudoers fragments


#1

I wrote a sudo lwrp, comments appreciated

It now has a much simpler api . Comments, criticism would be much appreciated

from the README.md

It has two modes, “natural” mode which mimics the sudoers file
interface and “template” mode where you supply a regular erb template
and hash of variables. For “template” mode, the sudo lwrp simply
ensures that resulting sudo fragment passes validation and has the
proper filesystem permissions.

In either mode, the sudo lwrp will render a sudoers fragment in /etc/sudoers.d/

In the case that the sudoers fragment does not pass validation, this
lwrp will fail the chef-client run before the fragment can be copied
to /etc/sudoers.d. This prevents the corruption of your sudoers
configuration.

Example of the default mode, “natural” mode

sudo “tomcat” do
user “%tomcat” # or a username
runas “app_user” # or “app_user : tomcat"
commands [”/etc/init.d/tomcat restart"] # array of commands, will be
.join(",")
host "ALL"
nopasswd false # true prepends the runas_spec with NOPASSWD
end
Example of template mode

sudo “tomcat”

this template must exist in the calling cookbook

template "restart_tomcat.erb"
variables( :cmds => [ “/etc/init.d/tomcat restart” ] )
end
In either case, the following file would be generated in /etc/sudoers.d/tomcat

this file was generated by chef

%tomcat ALL=(app_user) /etc/init.d/tomcat restart


#2

On Jan 6, 2012, at 1:15 PM, Bryan Berry wrote:

It now has a much simpler api . Comments, criticism would be much appreciated

Only on my 2nd cup of coffee, but it looks like render_sudo_attributes writes the file every time and marks itself as updated.

render_sudo_template also marks it self as updated every run, even though template may not.

The could called unexpected behaviors with notifies and subscribes when using these.

You could generate the file as you do know, but do a checksum and only move the file into place if it’s different.

–Brian


#3

that is correct, render_sudo_attributes does write the file every
time. I hadn’t figured out how to avoid this behavior. Thanks for the
suggestion into using a checksum. I will look into it

On Sat, Jan 7, 2012 at 4:20 PM, Brian Akins brian@akins.org wrote:

On Jan 6, 2012, at 1:15 PM, Bryan Berry wrote:

It now has a much simpler api . Comments, criticism would be much appreciated

Only on my 2nd cup of coffee, but it looks like render_sudo_attributes writes the file every time and marks itself as updated.

render_sudo_template also marks it self as updated every run, even though template may not.

The could called unexpected behaviors with notifies and subscribes when using these.

You could generate the file as you do know, but do a checksum and only move the file into place if it’s different.

–Brian


#4

the simplest solution would be to do a checksum on the rendered
template and compare it to the file currently in place. If they are
different, overwrite the sudoers fragment in /etc/sudoers.d/ and call
new_resource.updated_by_last_action(true). If they are not different
I wouldn’t overwrite the fragment currently in use and also wouldn’t
call new_resource.updated_by_last_action(true) at all.

Does that sound right?

Also, should I invoke new_resource.updated_by_last_action(false) if
the template hasn’t changed?

On Sat, Jan 7, 2012 at 4:25 PM, Bryan Berry bryan.berry@gmail.com wrote:

that is correct, render_sudo_attributes does write the file every
time. I hadn’t figured out how to avoid this behavior. Thanks for the
suggestion into using a checksum. I will look into it

On Sat, Jan 7, 2012 at 4:20 PM, Brian Akins brian@akins.org wrote:

On Jan 6, 2012, at 1:15 PM, Bryan Berry wrote:

It now has a much simpler api . Comments, criticism would be much appreciated

Only on my 2nd cup of coffee, but it looks like render_sudo_attributes writes the file every time and marks itself as updated.

render_sudo_template also marks it self as updated every run, even though template may not.

The could called unexpected behaviors with notifies and subscribes when using these.

You could generate the file as you do know, but do a checksum and only move the file into place if it’s different.

–Brian


#5

On Jan 7, 2012, at 10:35 AM, Bryan Berry wrote:

If they are not different
I wouldn’t overwrite the fragment currently in use and also wouldn’t
call new_resource.updated_by_last_action(true) at all.

Does that sound right

yes.

Also, should I invoke new_resource.updated_by_last_action(false) if
the template hasn’t changed?

i think so, or just don;t call updated_by_last_action at all.