Re: Cron management...

From: Mladen Gogala <mgogala_at_yahoo.com>
Date: Sun, 12 Apr 2015 19:38:09 -0400
Message-ID: <552B01E1.9060800_at_yahoo.com>



On 04/12/2015 02:47 PM, Chris Grabowy wrote:
> Howdy.
>
> We currently have about 30 Redhat Linux servers running Oracle 11.2
>
> Recently for a short time the crontab entry for a production backup was commented out.
>
> Just last week one of the DBAs had "accidently" deleted all the backup scripts. The scripts directory is NFS mounted so it impacted every server.
>
> The Netbackup folks like to do maintenance during the day. Any Oracle backups that may have been running abort. These days we get notice from the Netbackup folks but it's kinda tricky to check 30 servers and determine if anything is running. Or kick off 30+ archive log backup scripts across all the servers to clean up the archive log directories before the Netbackup maintenance.
>
> Managing crontabs, jobs and scripts across 30 servers just doesn't seem to be working.
>
> Our company uses a job scheduling app called Tidal. The manager of that app demo'd the product to me and it seems like it can address many of our headaches. In theory a single simple interface to manage all the jobs scheduled across all the database servers.
>
> However one of the issues identified by the Linux admin is that the Tidal agent needs root access so he is reluctant to install the Tidal agent anywhere but a couple of designated Tidal servers.
>
> I am wondering if other sites have stopped using crontab? If so then what did you replace it with?
>
> Anyway, I am open to any thoughts, suggestions, etc.
>
> Thanks,
> Chris Grabowy
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>

Chris, I am not sure why are you using crontab with NetBackup? NetBackup has its own scheduler and can schedule the scripts centrally, through the NB GUI. All you need is the right script in /usr/openv/netbackup/bin and all will be well.

As for Tidal, I have no experience whatsoever with the product, but I do have an experience with the competing product called Control-M from BMC. Unfortunately, all 3rd party scheduling products, including NetBackup which also has a centralized scheduler, must have a service which runs as user "root". The reason for that is that they have to be able to switch user and run something as user "oracle", without being prompted for password every time they need to run a job.

These products are usually installed as Linux service, in /etc/init.d directory and are started during the Linux start-up. Please, inform your system administrator that NetBackup requires root access as well and ask him to remove it from all the systems for security reasons. Why stop there? Oracle also requires root access in the installation phase, one must run orainstRoot.sh and $ORACLE_HOME/root.sh as user root, so your system administrator should remove that, too. God forbid you have ASM, that requires root access, too. To further secure your systems, after removing all 3rd party products, including Oracle, he or she should execute "service network stop" as user "root" on every system. That would completely secure your Linux system and make it impossible to anyone without the physical access to the server to use them. Of course, no security is complete without physical security, so you should consider the industry standard security measures like barbed wire, mine fields, electrified fence, guard dogs, machine gun nests and Chuck Norris.

Long story short, you are dealing with an unreasonable system administrator. It's not your problem, it's a problem for your boss. Management decides what runs on the company systems, not the system administrator. There is one piece of trivia which people frequently forget: the only completely secure systems are systems that are not being used and contain no useful information. Refusing to install an established 3rd party product based on the assessment that it "needs root access" is ludicrous, to put it mildly.

-- 
Mladen Gogala
Oracle DBA
http://mgogala.freehostia.com

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Apr 13 2015 - 01:38:09 CEST

Original text of this message