[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
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.
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.
thanks!
[1] https://forge.puppetlabs.com/saz/sudo
More information about the colug-432
mailing list