cron state and system-wide cron ( /etc/crontab )

[Bernhard J. M. Grün]

Hello,

does salt support the manipulation of the system-wide cron in /etc/crontab (using the functions present and absent of the cron state)?

I think this could ease the migration from a non-salted system to a salted system.

Or is there a good reason why one should not manipulate the system-wide cron with salt?

Best regards,

Bernhard J. M. Grün

[Thomas S Hatch]

Right now we do not have direct management of the /etc/crontab file built into the cron system, but you can manage the file with file.managed. If you are putting cron jobs in there at all I would discourage it, since you have more granularity placing the cron jobs in user crontabs and system level cron jobs should be maintained in root's crontab.

Granted, this is my experience, if people are interested in management of /etc/crontab let me know, but I would use the user crontabs

--
 
 

[Corey Quinn]

On Jan 4, 2013, at 10:19 AM, Thomas S Hatch <that...@gmail.com> wrote:

> Right now we do not have direct management of the /etc/crontab file built into the cron system, but you can manage the file with file.managed. If you are putting cron jobs in there at all I would discourage it, since you have more granularity placing the cron jobs in user crontabs and system level cron jobs should be maintained in root's crontab.

Actually, I'd argue that virtually all crontabs should live in /etc/cron.d/ (where supported), thus giving you granularity on a per job / per user basis, but not having to differentiate between user crontab locations (RedHat likes /var/spool/cron, Debian likes /var/spool/cron/crontabs/) depending upon platform.

This sounds like a brewing holy-war. :-)

-- Corey

[Les Mikesell]

I think it is more a question of whether you are trying to replace
what something else does or co-exist with other things. If you want
to control what other system packages install, you pretty much have to
know and use the existing location(s).

--
Les Mikesell
lesmi...@gmail.com

[Corey Quinn]

Hmm. I was under the impression that packaging standards already specified /etc/cron.d/ but I'm failing to find a citation; if I'm wrong on that I have some fixing to do…

-- Corey

[Sean Channel]

You're right, they do.

http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/sysinit.html

On 01/04/2013 10:39 AM, Corey Quinn wrote:
>
> Hmm. I was under the impression that packaging standards already specified /etc/cron.d/ but I'm failing to find a citation; if I'm wrong on that I have some fixing to do�
>
> -- Corey
>

[Bernhard J. M. Grün]

I did not want to start a holy war. But now...

I really prefer system cron jobs on our systems. Therefore I would vote for a new feature that makes editing of crontab files in /etc/cron.d/ or of the main crontab file /etc/crontab possible.

In the meantime I will try to work with the file.managed function and then place the files in /etc/cron.d. But I fear this is not as easy to use as the cron state.

 

-- Bernhard J. M. Grün

[Thomas S Hatch]

heh, honestly it should not be hard to add, and it seems there is enough interest here. please open an issue. I won't place it on high priority, so if someone wants to add this it will get in sooner

--
 
 

[Jeff Zellner]

Has there been any work on this? It's a pretty big missing feature (to me!) -- I'm considering taking it on if there hasn't been any other progress. Cheers!

-Jeff

[Colton Myers]

Well, have you looked at the cron state?  http://docs.saltstack.com/ref/states/all/salt.states.cron.html

There's also an execution module.

--

Colton Myers

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Bogdan L]

Judging from the documentation, this is still not possible, right? Both state and module talk about a user's crontab only.

Use case:
1. Prefer system cron jobs in system crontab rather than root's crontab
2. Have images with different /etc/crontab files depending on cloud provider

Can still be managed in other ways, of course, but it would be useful since the cron state is the first thing one looks at for such a task.

[James Beckett]

There's also no provision direct in the cron state to manipulate the /etc/cron.allow and deny files, so where that's been provisioned prior to salt (e.g. for CIS compliance) adding for anyone other than root will fail

Cron /opt/scripts/... for user jenkins failed to commit with error The user jenkins cannot use this program (crontab)