Configure and manage cron jobs with focus on tidiness

Table of Contents

  1. Description

  2. Setup - The basics of getting started with cron

  3. Usage - Configuration options and additional functionality

  4. Reference - An under-the-hood peek at what the module is doing and how

  5. Limitations - OS compatibility, etc.

  6. Development - Guide for contributing to the module

Description

This module is an interface for cron jobs with the main idea to be tidy. That means that any jobs that are not managed should not exist. Once you switch all cron jobs to this module, simply removing the definition is sufficient without worrying about setting ensure => disable and waiting for changes to propagate.

Setup

Beginning with cron

To start out with cron:

include cron

This will start purging all unmanaged cron resources and also make sure the ‘cron’ package is installed and the service is running.

WARNING: All existing unmanaged cron jobs will be purged!

Usage

Also manage /etc/cron.d directory

class { 'cron':
  purge_crond => true,
}

Same result through Hiera:

cron::purge_crond: true

Wipe it all out

class { 'cron':
  ensure => absent,
}

Same result through Hiera:

cron::ensure: absent

cron::job example

cron::job { 'backup':
  user     => 'backup', # default: 'root'
  minute   => '3-59/5',
  hour     => '9-17',
  monthday => '*/2',
  month    => [ 4, 8, 12 ],
  weekday  => '0-4',
}

cron::whitelist example

cron::whitelist { 'pkg_backup': }

This will make /etc/cron.d/pkg_backup immune, and keep the file’s contents untouched.

crontab access on FreeBSD

This module changes the stock FreeBSD default for who may use crontab(1).

Out of the box, FreeBSD ships without /var/cron/allow or /var/cron/deny, which lets every user manage their own crontab. This module is restrictive by design, so including it writes a /var/cron/allow file — which means only the listed users may use crontab(1). By default that list is just root, matching the module’s “only root by default” behavior on Linux.

Note that on FreeBSD cron.allow governs root too (unlike Linux, where root always bypasses it), so root must be listed explicitly. The module’s FreeBSD data does this for you.

To allow extra users, keep root in the list (setting allowed_users replaces the default, it does not append to it):

class { 'cron':
  allowed_users => ['root', 'alice'],
}

To restore stock FreeBSD behavior (all users may use crontab, no allow/deny files managed):

class { 'cron':
  allow_all_users => true,
}

Reference

Type Aliases

  • Cron::Command - Used for cron::job::command parameter. Does not allow newline characters (which breaks crontab).

  • Cron::User - Match username to fail early if invalid username is provided.

  • Cron::Minute - Stricter cron::job::minute.

  • Cron::Hour - Stricter cron::job::hour.

  • Cron::Monthday - Stricter cron::job::monthday.

  • Cron::Month - Stricter cron::job::month.

  • Cron::Weekday - Stricter cron::job::weekday.

Full reference

Check out REFERENCE for up-to-date details.

Limitations

  • Supported and tested on:

    • Ubuntu 20.04, 22.04, 24.04

    • FreeBSD 13, 14, 15 (acceptance-tested on 14 and 15)

  • On FreeBSD the module manages /var/cron/{allow,deny} and, by default, restricts crontab(1) to root — which differs from stock FreeBSD, where all users may use crontab. See access on FreeBSD[#crontab-access-on-freebsd].

  • Custom Cron::* time types are a lot stricter than builtin cron ones. Careful - this may break existing cron jobs you are converting.

  • All cron jobs managed by built-in cron type are fair play. They won’t be purged as long as they’re in the catalog. But using this module’s cron::job type does have its advantages.

Development

I’ll be happy to know you’re using this for one reason or the other. And if you want to contribute - even better. Feel free to submit an issue / fire up a PR / whatever.