No way to clear old and erroneous /etc/suders.d entries about sudo

[bcg62]

@nkadel-skyhook the zap cookbook tries to address this issue at a higher level. You can probably use it to accomplish this. https://github.com/nvwls/zap

[nkadel-skyhook]

Thanks for the pointer: there are similar issues for the nagios, bind, and nginx cookbooks.

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

On Dec 4, 2015, at 11:51, "Brendan Germain" <[email protected]mailto:[email protected]> wrote:

@nkadel-skyhookhttps://github.com/nkadel-skyhook the zap cookbook tries to address this issue at a higher level. You can probably use it to address this issue. https://github.com/nvwls/zap

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

[tas50]

At the moment you have to use the delete action to cleanup old entries. We don't have a native accumulator concept in chef to properly cleanup non-chef managed data, but we could write something or use zap. It's probably worth doing.

[tas50]

I'm closing this since this is more of a chef-client issue and less of an issue with this cookbook. We actively manage files and we don't deal with files we don't manage. That's a pretty core concept in Chef and deleting non-managed files in this directory would go against that concept. Nothing stops you from writing logic to look at the sudo resource that have executes and nuke anything else. That's up to you if you feel comfortable executing something like that in your environment.

[nkadel-skyhook]

May I respectfully disagree with this approach?

If it was the "users" or "yum" recipe, I'd agree with your reasoning. Even "hostsfile" depends on not clearing away various OS published components.

But tandard package deployment tools do not seem to touch /etc/sudoers.d. And as soon as sudoers.d is activated by the sudo cookbook, then it becomes like /etc/nginx/sites-enabled, which is kept pruned by the "nginx" cookbook", or /etc/httpd/sites-enabled on RHEL, which is kept pruned by the apache2 cookbook. Non-chef-managed entries are automatically cleared, successfully, on every chef client run. This allows mere disabling of a chef managed recipe to also clear the old configuration file, without having to write local wrappers to delete them and without havingi to force the ongoing use of obsolete recipes in a "remove" mode.

But the persistent use of cookbooks which merely deploy add-on features and never clean up after themselves, and force the local admin having to write and maintain their local set of wrapper cookbooks to do cleanup as well as deployment, has been problematic. And extra entries in /etc/sudoers.d can break chef deployed configurations. So it seems worth some effort.

If I can find cycles to write in a "zap" cleanup, would you be amenable to a pull requiest to support this? Ideally as a "default enabled" option?