Ask HN: What features/behaviour do you want in a cron management tool? | Hacker News Reader

Ask HN: What features/behaviour do you want in a cron management tool?

1 pointswalladge6 comments

Background: I have recently begun using configuration management software (specifically ansible, and more recently, salt). I also make use of cron and the cron module in salt. Unfortunately the current cron module is buggy, so I'm in the process of writing a new module for it, which I may expand out to a self-contained cron management software in future as well. You can follow development at https://github.com/swalladge/cron_ng .

I'm posting here looking for feedback on what features and behaviour you believe a cron management module should have. Things like:

- should it work with crontabs or the `/etc/cron.d` directory

- should it be allowed to work with lines already present in the crontab?

- what syntax would you want to be able to use to control it?

- what api points would you find useful? (eg. job-present, env-present)

- how should it manage environment variables in crontabs? (seeing as a command only sees variables defined _above_ the line)

- what are your most/least favourite things about existing cron management tools/modules?

- anything else!

For reference, the current cron module in salt has docs at https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.cron.html and https://docs.saltstack.com/en/latest/ref/states/all/salt.states.cron.html

This is not just for Salt users - if you use another configuration management tool or none at all, please voice your opinion as well!

Thanks

> I have recently begun using configuration management software (specifically ansible, and more recently, salt).

You were misled. Ansible and Salt are deployment scripts, not configuration management software, they're only abused to do that task. CFEngine and Puppet are configuration management software.

> For reference, the current cron module in salt [...]

The first part of that is a stateful command interface to what was just fine with declarative flat configuration file. It's a downgrade in system administration, as you can do much less with some hidden magical state than with plain files.

The second part is reinventing crontab's syntax, along with some conditionals that simply don't belong there.

What are you actually aimig at? What bothers you with crontab files that made you try to fix them?

> You were misled. Ansible and Salt are deployment scripts, not configuration management software, they're only abused to do that task. CFEngine and Puppet are configuration management software.

Oh really? Everywhere I've read, they are all classed in the same category and compared... Why is this so?

I'm not sure what you mean by a declarative flat configuration file? You mean don't use config management to manage cronjobs at all?

> What are you actually aimig at? What bothers you with crontab files that made you try to fix them?

Nothing bothers me with crontab files actually, it's just working out how to manage jobs across multiple systems using something like Salt. I guess I'm aiming to improve the current cron state modules available.

> Oh really? Everywhere I've read, they are all classed in the same category and compared... Why is this so?

Because those people mainly have a handful of servers, all of them running continuously with no downtime.

Ansible and Salt run in push mode, meaning that they send to servers their new configuration. But what happens when one of the servers is down? Ansible just blows up and leaves figuring out the rest to the operator. Salt, as I remember, has some schedule hacked on top of this brittle architecture of sending changes, but it didn't feel like a proper solution to a problem that should not exist in the first place.

CFEngine and Puppet don't have this problem, because agent regularly hails its master server and fetches the configuration, applying it if it's different from current state. (Push operation is implemented as executing a pull outside its schedule.)

Then there is this idea quite common in unices that configuration is something stored in files. Ansible, despite having many modules to work with files in some way, doesn't seem to have a crystalized idea how to put a config file in place. The best shot is "assemble" module, but it's only one of the ways (and not the best one at that).

> I'm not sure what you mean by a declarative flat configuration file? You mean don't use config management to manage cronjobs at all?

No. I mean "don't use shell(-like) commands to add stuff to files". Crontabs under configuration management are just fine.

>> What are you actually aimig at? What bothers you with crontab files that made you try to fix them?

> Nothing bothers me with crontab files actually, it's just working out how to manage jobs across multiple systems using something like Salt.

Oh, so it's just the mismatch between what the tool is sensible at and what you are trying to do with it.

The best shot at managing crontabs I've seen is to generate appropriate files from templates and then put them in place with configuration management software. CFEngine and Puppet both have their own engines for templates, but I prefer using something external (I wrote cfgen on top of Template::Toolkit for this precisely, but writing a custom tool is not difficult.)

Thanks for that explanation! pull vs push mode makes sense.

Yes, none of the modules I've seen can efficiently work with configuration stored in a single file like crontabs. For example, the salt module needs to read and write the entire crontab for each state configuration.

The only problem I have against building a crontab from a template before placing them with the software is that it makes it difficult to keep things modular since all the cron jobs need to be defined in a single place (even if they are for totally different things).

Uhm... Why do you want to put all the entries in a single file? Use templates of multiple files and put multiple files to /etc/cron.d.

Hmm yeah that sounds like it could work better. Are there any disadvantages of using /etc/cron.d over crontab though? It seems that doing it that way would require root access on the client/minion, but I guess running as root is the most common anyway.

Reply on news.ycombinator.com