[GTALUG] Crontab versioning

Christopher Browne cbbrowne at gmail.com
Thu May 3 16:02:55 EDT 2018


On Thu, 3 May 2018 at 10:45, Alex Beamish via talk <talk at gtalug.org> wrote:

> I'm developing scripts that get run by crontab, so I'm in there making
updates fairly regularly. I would love to be able to document the changes,
so I'm wondering if there a usual and customary technique to version
crontabs?

> Ideally there would be some sort of hook around 'crontab -e', but failing
that, I'd have the output of 'crontab -l' (run regularly by cron?) go to a
versioned file. Plan B sounds a bit hokey to me.

Some years back, I built a bit of infrastructure for this.

We didn't have git at the time (heh, AIX was involved.  It's always quite
the chase to get things running on AIX! ;-) )

I did a combination of push *and* pull on my crontabs:

a) I had tooling (integrated using cfengine 2, which tells you how far
back! ;-) ) to add desired entries into files.  So I used this to modify a
copy of the crontab to make sure that the copy included Stuff I Wanted.

This represents the "push"; have a way to push things in.

But my push was into a *copy*, not the real file...

b) Also, nice to have a "pull"

If git had been an option, I'd have taken the present contents of crontab,
exported via "crontab -l", stow that in git, as a preface to step a).

instead, I'd pull the present contents, see if it was different from the
latest recorded version, and if so, rename the previous one to mark when it
was obsolesced.

Then rewrite via a), and use "crontab < authoritative_new_version" to
update cron on the new schedule.

If one uses an SCM, then that changes a few steps, but not in any huge way.

In these modern days, it probably isn't "cfagent+script", but rather "git +
ansible/salt/..."

-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"


More information about the talk mailing list