This is where hiera comes in handy. I personally dislike hiera, and in general all repositories of information which are not bound to a tightly validating schema and which don't natively lend themselves to being queried with a query language. Anyway this is another story.
This is the Puppet class:
class acme::crontab ($acme_crontab_entries = hiera('acme_crontab_entries', {})) {
create_resources(cron, $acme_crontab_entries)
}
and in your <hostname>.yaml file enter:
acme_crontab_entries :
logrotate:
command : '/usr/sbin/logrotate'
user : 'soa'
hour : '2'
minute : '0'
I can't think of anything simpler.
NOTA BENE:
hiera('acme_crontab_entries', {})
the empty hash {} is needed so that, if a <hostname>.yaml doesn't define the acme_crontab_entries variable, you don't get the message
Could not find data item acme_crontab_entries in any Hiera data file and no default supplied at /tmp/vagrant-puppet/modules-0/acme/manifests/crontab.pp:6 on node osb-vagrant.acme.com
However this is a bit of abuse of hiera.... hiera should contain minimal configuration information, letting the Puppet modules to handle the details.
A more structured approach is to define in hiera only a boolean flag determining is a given cron entry is needed on a specific server: "acme_install_logrotate_service : true" , and then in your init.pp you do:
$acme_install_logrotate_service = hiera('acme_install_logrotate_service', false)
if $acme_install_logrotate_service {
class {'acme::logrotateservices': }
}
and the class logrotateservices contains the Puppet statement:
cron { logrotate:
command => "/usr/sbin/logrotate",
user => root,
hour => ['2-4'],
minute => '*/10'
}
No comments:
Post a Comment