[colug-432] puppet: leveraging another module

[Scott Merrill]

> I wrote a module that installs and configures an application.  The hiera config is pretty simple - include the class and optionally a hash of user accounts to create.  The module I wrote contains a file that needs to get dropped into /etc/sudoers.d.  Right now, that's exactly what it does -- using a File{} resource.  I'd rather instruct the sudo module to handle this, because it's already good at that.  It handles things like running a syntax check, knowing where the file should go, etc.
> 
> I can easily do that from the hiera config.  That is, I can write a yaml block
> 
> myapp::myadmins:
> 	- rhornsby
> 	- bsmith
> 
> sudo::configs:
> 	myapp:
> 		source: 'puppet:///modules/myapp/etc/sudoers.d/myapp'
> 		priority: 10
> 
> 
> I don't like that.  Besides triggering my OCD, it's messy and breaks the heira containment (my phrase) for a single module into two distinct/unrelated blocks.  By that, I mean that I'm using heira to instruct another module to do something for my module.

In general, you’re on the right track.  Try to ensure that Hiera configuration elements are as localized as possible.  It gets hard to remember what values to edit when your namespaces are divergent as above.

> I'm trying to understand if within the myapp module: can I somehow call the sudo module and tell it "hey, here's a sudoers config file, handle it" -- or is that a bad practice because of the cross-module dependency created?
> 
> Obviously, in the myapp/manifests/config.pp this will not work:
> 
> sudo::configs { 'myapp':
> 	source => 'puppet:///modules/myapp/etc/sudoers.d/myapp',
> 	priority => 10,
> }
> 
> because sudo::configs is not a valid resource type (or is it and I'm missing something?).

sudo::configs *is* a valid resource because it's in the saz sudo module, which is presumably included somewhere within your manifests at the time the Puppet Master compiles the catalog.  But sudo::configs a class, which means you can only ever have one instance of it in your entire catalog.  Additionally, it looks like saz discourages explicit inclusion of that class because the main init.pp manifest handles that for you.

https://github.com/saz/puppet-sudo/blob/master/manifests/configs.pp#L5
https://github.com/saz/puppet-sudo/blob/master/manifests/init.pp#L144

> Or is there an entirely different approach that would be a better practice?  This won't be a one-time thing.  I've got a few other modules I'm working on that will have a sudoers file.

You have a couple of choices here.  Rather than create and manage a full file, you could use the sudo::conf defined type to make smaller rules, like this:

  sudo::conf { ‘linux_admins no passwords' :
    content => '%linux_admins ALL=(ALL) NOPASSWD: ALL'
  }

If your modules only have a few specific sudo requirements, you could use rules like the above directly embedded into your modules.  This kind of cross-module integration is generally discouraged, but sometimes you just can’t avoid it.  I like this because it makes it clear within your “myapp” module what sudo requirements it has.

(The role/profile/tech pattern of Puppet modules is one attempt to provide guidance around how and when modules can reach outside of their own boundaries.  If you’re not yet familiar with this pattern, do check it out.  A “myapp” profile might be justified to handle bridging both the “myapp” tech module and the sudo module.)

Another option would be to make a design decision within your Puppet manifests that *all* sudo configurations will be handled via Hiera.  This appears to be well supported by the saz module.

https://github.com/saz/puppet-sudo#using-hiera

This makes it consistent within your modules that Hiera is the sole source of truth for sudo.  This can get a little more complicated, though, if you want specific rules enabled on some servers but not others.  It’s possible, depending on your Hiera hierarchy configuration, but takes a lot of careful planning.

I hope this helps!

Cheers,
Scott