Alex Pearwin

Running periodic Kerberos-authenticated jobs with acron

This post has been archived. It's pretty old and likely concerns topics that are avoidable by using more modern tools and techniques. The original text is preserved below for posterity but it may no longer be relevant or correct.

The cron utility allows you to schedule a program to be run periodically. Once you’ve defined a ‘cron job’, the operating system will make sure that job is run at the times you’ve specified.

Jobs are defined in the ‘cron table’, which can be manipulated with the crontab command. An example job definition might look like this in the crontab.

01 01 1 1 1 echo foo

The command to be run is echo foo. The numbers preceding the command specify when the command is to be run: minute, hour, day of the month, month, and the day of the week. This job will then run at 01:01 am on January 1st, and at the same time every Monday in January (cron will run the job as long as at least one of the two day fields matches the current time).

There are already plenty of tutorials for crontabs, so I won’t dwell on them to long (man crontab and man 5 crontab are good starting points), but I’ll mention two other interesting parts of the crontab syntax.

# First example
01 01 * * * echo foo
# Second example
*/5 01 * * * echo foo

In the first example, we’ve used the asterisk * syntax to tell cron to match any value of the field. In this case, cron will run the job at 01:01 am every day of every month.

In the second example, the slash / syntax tells cron to run in steps on that field. Here, */5 means cron will run the command every 5 minutes when the hour is 01.

Kerberos jobs at CERN

At CERN, user authentication is handled with Kerberos tokens. Generally, as a user, you need to renew your token once every 24 hours by running a command and entering your password.

If you want to run a job periodically, you won’t be around to enter your password every time the job runs, so your job won’t be able to see any of your files! The way around this restriction is to use acron, which will automatically provide your job context with the Kerberos token it needs to be able to have the same access rights as you.

It works in a very similar way to regular cron, but now you edit an ‘acron table’ with the acrontab -e command, and there’s one additional field you need to specify for each row.

01 01 * * * lxplus.cern.ch echo foo

The extra field is before the command, still echo foo, where here we’ve chosen lxplus.cern.ch. This field specifies the machine that acron will run your job on. In this case, our job will run on an lxplus node, which is usual cluster of machines that CERN users run interactive jobs on.

Differences to cron

The syntax allowed in an acrontab file is near-identical to that in a regular crontab, except that step definitions, like */5 we saw earlier, aren’t supported, and neither is a * value in the minute field. This is to prevent the acron system being overloaded with many jobs to run. (After all, CERN has thousands of users, and whereas cron usually runs on your own machine that has one or two users, acron needs to be able to run jobs for everyone.)

Summary

You can define jobs to run periodically on machines in the CERN network with acron, and those jobs will have Kerberos tokens automatically. You can manipulate the acron table with the acrontab command

In the next post, we’ll go over how to set up your own virtual machine in the CERN network that is able to run acron jobs, so that you can install your own software for your jobs to use.