FAQ
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.
On Tuesday, November 5, 2013 7:46:42 PM UTC+2, basepi wrote:

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


On Mon, Nov 4, 2013 at 3:38 PM, Jeff Zellner <jeff.z...@gmail.com
<javascript:>> wrote:
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
On Saturday, January 5, 2013 12:36:46 AM UTC-5, Thomas Hatch wrote:

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


On Fri, Jan 4, 2013 at 12:53 PM, Bernhard J. M. Grün <
bernhar...@gmail.com> wrote:
Am Freitag, 4. Januar 2013 19:31:41 UTC+1 schrieb LesMikesell:
On Fri, Jan 4, 2013 at 12:22 PM, Corey Quinn <co...@sequestered.net>
wrote:
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. :-)
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

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

--

--
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 <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupsalt-users @
postedDec 30, '14 at 8:32a
activeDec 30, '14 at 8:32a
posts1
users1

1 user in discussion

Bogdan L: 1 post

People

Translate

site design / logo © 2022 Grokbase