
Ask HN: What features/behaviour do you want in a cron management tool? - swalladge
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&#x27;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:&#x2F;&#x2F;github.com&#x2F;swalladge&#x2F;cron_ng .<p>I&#x27;m posting here looking for feedback on what features and behaviour you believe a cron management module should have. Things like:<p>- should it work with crontabs or the `&#x2F;etc&#x2F;cron.d` directory<p>- should it be allowed to work with lines already present in the crontab?<p>- what syntax would you want to be able to use to control it?<p>- what api points would you find useful? (eg. job-present, env-present)<p>- how should it manage environment variables in crontabs? (seeing as a command only sees variables defined _above_ the line)<p>- what are your most&#x2F;least favourite things about existing cron management tools&#x2F;modules?<p>- anything else!<p>For reference, the current cron module in salt has docs at https:&#x2F;&#x2F;docs.saltstack.com&#x2F;en&#x2F;latest&#x2F;ref&#x2F;modules&#x2F;all&#x2F;salt.modules.cron.html and https:&#x2F;&#x2F;docs.saltstack.com&#x2F;en&#x2F;latest&#x2F;ref&#x2F;states&#x2F;all&#x2F;salt.states.cron.html<p>This is not just for Salt users - if you use another configuration management tool or none at all, please voice your opinion as well!<p>Thanks
======
dozzie
> 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?

~~~
swalladge
> 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.

~~~
dozzie
> 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.)

~~~
swalladge
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).

~~~
dozzie
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.

~~~
swalladge
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.

