make this module foreman-ready

[jaredjennings]

Right now, admins can use the defined resource types provided by this module to configure sudo in some detail. But that won't help first-time users.

Make a single class with a ton of parameters. This is how you can include this class in a modern, not-knowing-details fashion, and do your configuration with Foreman host groups, or smart parameters, or Hiera, or what-have-you.

Include code to install/remove the sudo software.

[jaredjennings]

So far I've managed sudo on Red Hat >=6 and on the Mac OS >=10.6; in both places it has a sane enough default configuration that I always want to modify it rather than throwing it out, and the software is installed by default.

So part of making one big class is to make sure the package is installed. And maybe the configuration should sometimes be replaced, I don't know. saz supports it. At a further look it seems like saz is including a FixedSudoers lens, which fixes some bug I don't know of in the RHEL5 sudoers lens. This is important.

[jaredjennings]

The bug, among others, is that you can't use the RHEL5 sudoers lens to edit the sudo config file to talk about uppercase usernames.

I wrote a big long comment to this, and I don't know what happened to it. Perhaps that's best. Restated:

To be self-contained, and also work on, say, Solaris 10, this module needs to know as much about installing sudo as saz-sudo does. But the installation stuff needs to be a little different to fit right in this module. But forking the installation code from saz-sudo isolates it from the saz-sudo community and the ongoing enhancements and fixes they'll be making. That's bad.

Meanwhile, the reason this module exists is so that fine-grained sudo configuration can be spread across multiple modules, but that means each of those modules depends on this one. That is good when this module and all the depending ones are managed together, like they were in CMITS, but if someone makes a PostgreSQL module that installs a script and wants the script to be runnable under sudo, -- most admins who use that module won't want such tight control over sudo as this module (puppet-cmits-sudo) affords, but the PostgreSQL module author either depends on this module or doesn't; I'm not aware of a way to make a soft dependency, like "if you are using puppet-cmits-sudo, here is a snippet of sudo policy; if not, don't sweat it." This dependency conundrum casts doubt on the idea that puppet-cmits-sudo should stand alone.

But if it were renamed to auditable_sudo, and the sudo installation left to, say, saz-sudo, then saz-sudo could trample over the configuration so carefully put in place by this module. So, in the outside world, puppet-cmits-sudo should stand alone.

∴∅

[jaredjennings]

Disregarding the undesirable contradiction at which we have arrived, what can affirmatively be done? We grab the sudo install code from saz-sudo. I've tried this already and got bogged down in the part where the sudo config file gets installed. So we say, it needs specialized. We accept that any revolutions in sudo installation functionality that are contributed to saz-sudo will need to be ported to show up here.

So then, we still have the module dependency problem. But now it is easy for admins to start using the module, and customize who gets to sudo. Module authors customize what is executable via sudo. Or, because of the dependency problem, it's more likely that the admin makes one or more side modules with calls to the defined resource type sudo::auditable::command_alias. Following the theme that anything that admins have to do shouldn't be code but configuration, we make a new class sudo::auditable::local_policy, with a complicated parameter listing groups of executables which should be sudoable with or without executing other things, and with or without the ability to set environment variables the resulting process will be able to see (noexec, exec, setenv_noexec, setenv_exec, see under Tag_Spec in sudoers(5)). This class would be implemented by taking the complicated parameter and using it to create command_alias defined resources. Now the admin is coding in Hiera instead of Puppet, or typing a huge data structure into a text box in Foreman. So much easier!! (/s.)

And I suppose we would have a parameter to the sudo class about whether to impose the default policy that comes with this module, defaulting to true.