Re: Cron management...

I never thought about things like "puppet" and "chef", mainly because I have (until recently) usually been restricted to working with what I find in the customer's environment, and these are tools I pretty much never find -- or they are never made available to me. Sysadmins should probably do the same due diligence on these tools as any other, but their widespread use suggests that they are probably pretty safe. (Oddly enough, sysadmins often seem to be less skeptical of the tools *they* use -- I bet there will be no objections here.)

Don't underestimate the value of monitoring in all of this. For example, its great to *schedule *backups -- by whatever means you like -- but it is dangerous if you start to *assume* that the scheduled backups are actually running. (And with 30 or more database servers, such assumptions are very tempting.) It can be terribly valuable to have a monitoring test in place that verifies that backups are run on schedule (or, at the very least, any given database is backed up once per XXXXX) and being alerted when this is not the case. This way, if your scheduling mechanism does fail (or is misused or misconfigured) you can learn about it *before* the damage is irreparable.

On Mon, Apr 13, 2015 at 6:21 AM, Niall Litchfield < niall.litchfield_at_gmail.com> wrote:

> On Mon, Apr 13, 2015 at 3:11 AM, MARK BRINSMEAD <mark.brinsmead_at_gmail.com>
> wrote:
>
>> I am in agreement with Seth on both points.
>>
>> The sysadmins here are simply being cautious -- as well they should be.
>> I, too, would be concerned about a network service that runs as "root" and
>> can -- by design -- run any command as any user at any time, based on
>> instructions received from a remote server, and I would also want to be
>> convinced of its safety before deploying it. These are the sorts of things
>> of which internaltion headline stories of massive security breaches are
>> made. Which is not to say, of course, that there is anything *wrong*
>> with the products you have mentioned -- just that the sysadmins in question
>> are simply doing their jobs in asking for assurance that there isn't.
>>
>
> In this particular case I think it would make sense to get your sysadmins
> to look again at the security requirements of the product.
> http://www.cisco.com/c/en/us/td/docs/net_mgmt/datacenter_mgmt/Tidal_Enterprise_Scheduler/6-2/installation/guide/Cisco_TES_6-2_Installation_Guide/Installation_Prerequisites.html#pgfId-1057180
> is relevant. My understanding is that this product requires root access to
> install, but not to run. You would of course need to ensure that the owner
> of the tidal agent gets the appropriate rights to execute scripts and so
> on. It is indeed sensible to be cautious - security is of course also
> something that enterprise scheduling products need to consider which is why
> in general they do not have to run as root (at least with modern versions).
> Given that this is an Enterprise wide scheduler, you'll need as an
> Enterprise to work out the security and administration model for it - that
> is often a challenge in traditionally structured IT departments (do you
> want admin access over database backup schedules provided to a non-dba
> group? what about server backups, application start/stop scripts etc). This
> of course is the exact same challenge that EM adoption faces.
>
>
>
>> As for crontabs...
>>
>> Managing crontabs across 30 servers can be a little unwieldy, but it is
>> certainly possible. Here are a few things I have seen in the past:
>>
>> - Monitoring jobs that report -- and require acknowledgement -- when
>> a crontab has been modified.
>> - Monitoring jobs that report when backups have failed to run as
>> scheduled. (Note: this is NOT the same as reporting "when a backups has
>> run and failed".)
>> - Source code control for administrative scripts (which can include
>> your crontab, by the way). Something as simple as RCS can do. If you are
>> paranoid, "check out" each of your scripts from the repository once per
>> day. Let people make unauthorized changes -- who cares?
>> - Keep a log of changes to the crontab. Something as simple as
>> piping "crontab -l" to a file, and then checking that into an RCS archive
>> will keep a very concise record of what was changed and when, although not
>> necessarily by whom.
>>
>> A centralized solution might be right for you. Maybe even for most
>> people. But I would not say it is mandatory. By the way, what do you
>> propose to do when somebody "accidentally deletes" all the
>> scripts/configuration for the centralized job-scheduling facility? You'll
>> probably need a plan for that
>>
> I'd add configuration management tools such as puppet or chef as a
> feasible solution for crontab management. You might find that your
> sysadmins are more amenable to that sort of solution and/or that it is
> cheaper.
>
>

--
http://www.freelists.org/webpage/oracle-l