sudoers.d default setting

[chef-boneyard]

sudoers.d default setting

[cwebberOps]

@rmoriz that seems reasonable to me... I would agree that it is rare anymore to see it be turned off. Would love to get more input though.

Would you be cool starting a discussion on the mailing list about it?

[nkadel-skyhook]

Please set it to true!!!

[kwilczynski]

I would actually be even more content if the cookbook would do absolutely nothing in default.rb. I would love to be able to managed entries under /etc/sudoers.d only with the resource, but retain what was initially in the /etc/sudoers file. The defaults provided are not necessary something that I would want to have, plus like @rmoriz said, it breaks sudo access for Vagrant / Test Kitchen, etc. What do you think, @cwebberOps?

[nkadel-skyhook]

Don't mix the issues, please! I agree that "do not touch /etc/sudoers" is a very reasonable option to have, but leaving /etc/sudoers.d intact is more useful for now.

[nkadel-skyhook]

I like the idea, as an option set by role or environment.

Nico Kadel-Garcia
Email: [email protected]:[email protected]
Sent from iPhone

On Jul 15, 2015, at 2:33, "Krzysztof Wilczynski" <[email protected]mailto:[email protected]> wrote:

I would actually be even more content if the cookbook would do absolutely nothing in default.rb. I would love to be able to managed entries under /etc/sudoers.d only with the resource, but retain what was initially in the /etc/sudoers file. The defaults provided are not necessary something that I would want to have, plus like @rmorizhttps://github.com/rmoriz said, it breaks sudo access for Vagrant / Test Kitchen, etc. What do you think, @cwebberOpshttps://github.com/cwebberOps?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/51#issuecomment-121506169.

[rmoriz]

so… can we set this finally to "true"?

[tas50]

Let me check the state of distros. With RHEL 5 / Ubuntu 12.04 going away we can probably do it now.

[tas50]

This is on my whiteboard to investigate and fix

[tas50]

This will be resolved by #110 now that RHEL 5 is EOL.