Need modules for cron

135 views
Skip to first unread message

Jeeva

unread,
Mar 8, 2012, 11:20:05 AM3/8/12
to Puppet Users
We are planning to run the puppet client as a cron rather than running
as a daemon. Could you please help me in creating a module for running
the puppet client as a cron

Jeffrey Watts

unread,
Mar 8, 2012, 11:32:33 AM3/8/12
to puppet...@googlegroups.com
Here's what I do.  I use generate() to calculate the run times for our jobs so that each server runs twice per hour at a pseudo-random but consistent time.  I use the IP address of the server, modulo 30.

  # Generate the times when the cronjob will run
  $cron_time1= generate('/usr/bin/env', 'sh', '-c', "printf $(($(echo $::ipaddress | awk -F . \'{print \$1+\$2+\$3+\$4}\') % 30))")
  $cron_time2 = $cron_time1 + 30

  cron { 'puppet-cron':
    ensure      => present,
    command     => $puppet_command,
    minute      => [$cron_time1, $cron_time2],
    user        => 'root',
  }

Hope this helps,
Jeffrey.

Munna S

unread,
Mar 8, 2012, 11:38:48 AM3/8/12
to Puppet Users
Hi Jeffrey,
 
Thanks for the quick response.
 
I need to copy the below content into init.pp file which is under my module right ? Also i created the module like this.
 
/etc/puppet/modules/cron_puppet
 
also should i define my class in the init.pp file. could you please help me on this. i am getting errors
 
-Jeeva

Peter Berghold

unread,
Mar 8, 2012, 11:58:57 AM3/8/12
to puppet...@googlegroups.com
Munna,

Here is a typical module tree:

xinetd/
|-- manifests
|   `-- init.pp
`-- templates

I chose this module as my "pattern" for you to look at because it is a very simple module.

In your case I'd be creating
puppetcron/
`-- manifests

with a single file "init.pp" with a single class:

class puppetcron {
     cron {  run-my-puppet-agent:
         minute => "1,31",
         command => "/usr/sbin/puppet agent --test"
    }
}

Modify the minute parameter for how often you want cron to execute puppet.  Or add hour, day or whatever to suit your installation.

Of course you going to have to run the agent manually on each host to "jumpstart" this process, but there ya have it.

One thought: 

If you are running out of cron you run the risk of multiple client systems accessing your puppet master all at once. This can become a scaling issue.  My advice is to just execute "puppet agent" on bootup (or manually) on each machine and let them figure out when to talk to the master.



--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.



--
Peter L. Berghold
Owner, Shark River Technical Solutions LLC

Munna S

unread,
Mar 8, 2012, 12:05:47 PM3/8/12
to puppet...@googlegroups.com
Hi Peter,
 
with the help of Jerrery, i got the below module and i modified it as per our requirement. So the below module will create a crontab on root user right ?
 
# Generate the times when the cronjob will run
class cron_puppet {

  $cron_time1= generate('/usr/bin/env', 'sh', '-c', "printf $(($(echo $::ipaddress | awk -F . \'{print \$1+\$2+\$3+\$4}\') % 30))")
  $cron_time2 = $cron_time1 + 30
  cron { 'run-my-puppet-agent':
    ensure      => present,
    command     => /usr/local/sbin/puppetd --onetime --no-daemonize  > /dev/null 2>&1,

    minute      => [$cron_time1, $cron_time2],
    user        => 'root',
  }
}


Krzysztof Wilczynski

unread,
Mar 8, 2012, 12:18:24 PM3/8/12
to puppet...@googlegroups.com
Hi,


On Thursday, 8 March 2012 17:05:47 UTC, Jeeva wrote:
Hi Peter,
 
with the help of Jerrery, i got the below module and i modified it as per our requirement. So the below module will create a crontab on root user right ?
 
# Generate the times when the cronjob will run
class cron_puppet {
  $cron_time1= generate('/usr/bin/env', 'sh', '-c', "printf $(($(echo $::ipaddress | awk -F . \'{print \$1+\$2+\$3+\$4}\') % 30))")
  $cron_time2 = $cron_time1 + 30
  cron { 'run-my-puppet-agent':
    ensure      => present,
    command     => /usr/local/sbin/puppetd --onetime --no-daemonize  > /dev/null 2>&1,
    minute      => [$cron_time1, $cron_time2],
    user        => 'root',
  }
}


If you already have MCollective and/or planning to incorporate it into your infrastructure in the future, then have a look at this:

http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/ToolPuppetcommander

Beats every cron job.

KW

Dan White

unread,
Mar 8, 2012, 12:19:05 PM3/8/12
to puppet...@googlegroups.com
Would it be overkill to be worried about launching the puppet agent before the last run has finished ?

If so, I would use a bash script that generates a pid-file like this:
http://www.xarg.org/2009/10/write-a-pid-file-in-bash/

That way, if the previous run is still running, you can skip doing it again and probably send out a notification that there are serious problems causing it to hang or run too long.

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)

Dominik Zyla

unread,
Mar 8, 2012, 6:16:42 PM3/8/12
to puppet...@googlegroups.com
On Thursday, 8 March 2012 at 18:19, Dan White wrote:
> Would it be overkill to be worried about launching the puppet agent before the last run has finished ?
>
> If so, I would use a bash script that generates a pid-file like this:
> http://www.xarg.org/2009/10/write-a-pid-file-in-bash/
>
> That way, if the previous run is still running, you can skip doing it again and probably send out a notification that there are serious problems causing it to hang or run too long.
>
> “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
> Bill Waterson (Calvin & Hobbes)
>
> ----- Peter Berghold <salty....@gmail.com (mailto:salty....@gmail.com)> wrote:
> >
> > If you are running out of cron you run the risk of multiple client systems
> > accessing your puppet master all at once. This can become a scaling issue.
> > My advice is to just execute "puppet agent" on bootup (or manually) on each
> > machine and let them figure out when to talk to the master.
>


I'm using such script to deal with this issue:

#!/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
SLEEP=$(($RANDOM*1500/32767))
sleep $SLEEP

puppetd -tv --report

But puppet commander, about which Krzysztof mentioned seems to be better solution. I have switch to it scheduled in my todo list too.

Best,

--
Dominik Zyla


Reply all
Reply to author
Forward
0 new messages