We usually create separate modules for those things anyway, they are
just really small. What might be a single package {'blah': ensure =>
present} now, might grow into something bigger later. We stick to that
paradigm even for things where we know chances are near 0 that that
will ever happen.
Slightly offtopic, besides that, we have a /modules/ and a /services/
dir with modules in them. The /modules/ path only has environment
agnostic modules in them (ie. /modules/apache) and then we have one or
more modules in /services/ that use one or more modules in /modules/
to create a specific service. So /services/s_apache will create our
specific apache configuration using the apache module, then if we have
many vhosts for instance, we create /services/s_http_yomama and
/services/s_http_yodaddy which hold the configurations for those
specific vhosts (this may include mysql databases, users and grants or
other things related to those vhosts.
cheers,
Walter
On Wed, Mar 21, 2012 at 04:14, Denmat <tu2bg...@gmail.com> wrote:
> Hi,
>
> For common files that aren't easily grouped I currently manage them is a base
> module that everyone gets.
>
> They get their own class or define and are called like so:
> class blah {
> Include base
> base::sysctl {"vm.swappiness": value => 10 }
> }
> Cheers,
> Den
>
>
>
>
> On 21/03/2012, at 4:35, Scott Merrill <ski...@skippy.net> wrote:
>
>> How are folks organizing their Puppet modules?
>>
>> For things that fit the trifecta
>> (http://projects.puppetlabs.com/projects/puppet/wiki/Core_Types_Cheat_Sheet/)
>> it makes sense (to me) to make them top-level citizens in my
>> /etc/puppet/modules directory. This constitute things like Postfix,
>> ntp, snmp, and the like.
>>
>> Moving past these, though, I'm curious how people are organizing
>> modules for essentially "standalone" files, i.e. those that don't
>> directly associate to a daemon. Things like /etc/sysctl.conf,
>> /etc/inittab, shell and profile controls, and the like. This also
>> includes miscellaneous services to start or stop when there's no
>> attendant config file to require; as well as packages to ensure are
>> installed or absent.
>>
>> What unexpected headaches -- if any -- resulted from your organizational
>> choice?
>>
>> Thanks!
>> Scott
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
Walter Heck
--
follow @walterheck on twitter to see what I'm up to!
--
Check out my new startup: Server Monitoring as a Service @ http://tribily.com
Follow @tribily on Twitter and/or 'Like' our Facebook page at
http://www.facebook.com/tribily
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
