[colug-432] puppet: leveraging another module

[Rick Hornsby]

> On Jun 11, 2015, at 13:44, Scott Merrill <skippy at skippy.net> wrote:
>> 
>> 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.

Right. That's definitely the idea.

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

You hit the same snag I did - which helped me figured out where I was going wrong.

The class is sudo::configs.  The resource type is sudo::conf.  The saz/sudo documentation is a little confusing (probably because I'm a novice) on this point.  I don't think he made any mistakes in the doc, it's just confusing.

Once I realized the resource type is sudo::conf the catalog, with myapp using that resource, compiles and executes fine.  No matter, this is a very helpful discussion in terms of finer points of puppet and best practices.

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

Agreed.  I have the idea in my head that I want the module to own its configuration and declare what it needs.  It's a pipe dream but I hope eventually other people around here will start writing and contributing puppet modules for their stuff.

I don't necessarily mind that they depend on a forge-based module.  stdlib and concat are already dependencies required for some forge-based modules I'm using.  To that end, I've separated the forge-based modules to /etc/puppet/modules and the home-grown modules to /var/lib/puppet/modules.  The thinking is that the modules in /etc/puppet/modules should not be touched, while the ones in /var/lib/puppet/modules are expected to be changed, updated, etc.

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

I'll have to look into this, thanks.

> 
> 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've been thinking about that.  I like the sole source of truth for sudo.  I was inadvertently working that direction, and the heira configuration got messy really quickly.  It also created that separation between the myapp module and the configuration that myapp requires to function properly.  I'd like to keep those things within a single logical container if possible.  In my heira config are a handful of "TODO: move this sudoers declaration to myappX module" to clean up the mess I made.

You're right about it being a design decision - something I need to ponder on a little more.

-rick