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