[colug-432] puppet: leveraging another module

Rick Hornsby richardjhornsby at gmail.com
Thu Jun 11 14:09:21 EDT 2015

I've finally mostly got saz's sudo puppet module[1] figured out.  Usage is fairly simple once I understood what he was looking for.

This might be a best practices question, or might be a technical question -- I'm trying to understand how to leverage his module in my own modules.  

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

	- rhornsby
	- bsmith

		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.

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?).

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.


[1] https://forge.puppetlabs.com/saz/sudo

More information about the colug-432 mailing list