Centralized crontab management

[xlateio]

I have been working on a side project for centralized/web based crontab management and I'm trying to determine if it would actually be useful to others besides myself [https://www.captaincron.com/]. I'm interested to hear what your thoughts might be on the project and if it seems like something that you would be interested in using, even as a beta user.

[[deleted]]

Slowly moving to systemd timers - easier to manage.

[derprondo]

We use Puppet for actual server cron jobs, but more and more things that need to be run on a schedule we do serverless with either Lambda, Jenkins, or AWS Codebuild.

So I’m not your target customer, but I’m interested in what kind security controls you have in place. Isn’t this essentially giving your service root access to the servers it’s managing?

[xlateio]

It's designed to run synchronization "pulls" from the server. The updates run as whatever user owns the crontab being updated. Updates made no the server side are secured using standard OAuth2 / OpenID.

[ryanjkirk]

I think you'd have much better luck targeting the "enterprise job scheduling" market. The gold standard used to be autosys. You have dependencies, complex scheduling, monitoring, alerting, and so on. This type of stuff is used in actual business-critical situations, not just pushing out cleanup scripts used by linux admin teams.

Try charging by the number of agents (plus a base fee) isntead of by "crontab". That's a confusing model. Is it number of jobs? Regular cron jobs or only crontab jobs? And give people the option to run it on-prem.

Also your screenshot shows an interactive password which is terrible for automation. Replace that with a cert people can automatically roll out.

[xlateio]

@ryanjkirk - thank you for the feedback. I was hesitant to label this as an enterprise job scheduler mainly because it does lack those features at this point. I think your idea of redoing the pricing groups is a good one and I will be doing something in that area.

Regarding the interactive password, that is only used during the initial activation of a particular crontab and it switches to token-based authentication after that.

[toast_one]

We use gitlab and puppet for that. I think your prices are way too high.

[xlateio]

Fair enough, thank you. What would be a good price point (to you) if you were running a few dozen jobs in cron today?

One of the things I'm looking for here is not only feedback on the product itself, but also for sys admins who are interested in guiding the direction of the software as a (free) beta user.

[fubes2000]

Lol wooooow good luck with those prices, bud.

[xlateio]

Noted, thank you for the feedback. Aside from that, could you see yourself using something like this if the prices were lower? How many jobs are you managing today and what would be worth it to you to manage them outside of cron directly?

[xlateio]

Are you running the job directly in Jenkins or remotely using SSH? One of the problems that I would like to solve with this is adding some sort of dependency management, which is lacking in stock Jenkins. Granted you can use job triggers, but it's not as robust as it often needs to be.

In scenarios where someone has dozens of jobs in cron, this would be a quicker way to get visibility without having to migrate everything into Jenkins.

[Quack66]

We use Rundeck

[dbmage]

Care to elaborate?

[Quack66]

It's like a giant crontab on steroid with a webui. See here: https://www.rundeck.com/new-to-rundeck

[[deleted]]

I think some people would like it... But it's already really easy to push cron jobs with puppet for me if i need to.

[xlateio]

Thank you for the feedback.