I was tying set up some cron jobs to do some file-system check. So, I
defined a "file" like this:
--------------------------------------------------------------------
define cron_job( $enable='true', $ival='d', $t='', $u='root', $c='',
$l="/var/log/$name.log", $o='2>&1', $pkg='' ) {
file { "/etc/cron.$ival/$name":
content => "$t $u $c $l $o\n",
ensure => $enable ? {
"false" => absent,
default => file,
},
force => true,
owner => root,
group => root,
mode => $ival ? {
"d" => 644,
default => 755,
},
require => $pkg ? {
"" => undef,
default => Package[$pkg],
},
}
}
# create the cron-job
class zfs::cronjob {
cron_job { 'zfs-check':
t => '43 3 * * *',
c => '/etc/zfs/check_zfs.sh myfile.ac.uk',
pkg => 'zfs';
}
}
---------------------------------------------------------------------
This writes a line like
"43 3 * * * root /etc/zfs/check_zfs.sh myfile.ac.uk /var/
log/zfs-check.log 2>&1"
in the "zfs-check" file. Is it possible to put multiple lines in the
same file? Any input greatly appreciated.
Cheers,
San
PS. Is there any better of doing that?
Cheers,
Sant
On Dec 5, 4:29 am, Sans <r.santanu....@gmail.com> wrote:
> Sorry to bump but I still didn't able to come up with any suitable
> work around this issue. Does any one have anything to say?
Is there some reason why you don't want to use the built-in Cron
resource type?
If you don't want to use Cron, then the usual general-purpose solution
for multiple resources contributing parts of one file is the Concat
module, which you should find in the forge.
John
I'm not sure - can I create a cron-job in e.g. "/etc/cron.d/" with
built in Cron
resource type? I thought it was only for crontab.
-S
On Dec 5, 10:11 am, Sans <r.santanu....@gmail.com> wrote:
> > Is there some reason why you don't want to use the built-in Cron
> > resource type?
>
> I'm not sure - can I create a cron-job in e.g. "/etc/cron.d/" with
> built in Cron
> resource type? I thought it was only for crontab.
I'm not sure, but you should look into Cron's 'target' parameter,
which looks like it is intended for that purpose. But that begs the
question: why is it important for the job to be recorded within /etc/
cron.d/?
If that doesn't work then you always have the alternative of extending
one of the built-in Cron providers to create one that puts files where
you want. That shouldn't be hard, and it would make your manifests
much more readable and maintainable.
John