3 ms·

> 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

> 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 10y ago
> 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 10y ago
  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 10y ago
    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 10y ago
      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.

dozzie 10y ago

> 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 10y ago
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 10y ago
  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 10y ago
    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.