RE: DBAs running

From: Sheehan, Jeremy <>
Date: Mon, 3 Feb 2014 17:32:04 +0000
Message-ID: <>


Our SA team created a website does this for us. We just pass the parameter of SERVER and location of file and it runs the script for us. It doesn't address the problem of changing the file, tho. However, it works out quite well for us DBA's where I work.



-----Original Message-----

From: [] On Behalf Of Austin Hackett Sent: Monday, February 03, 2014 12:08 PM To: oracle-l digest users
Subject: DBAs running

Hi List

If you work in a security conscious environment, I'd be keen to hear how your site handles the script.

To give you some background:

In my environment, DBAs are currently given direct root access to allow them to run However, the SA Team would like to tighten this up. If giving the DBAs direct root access isn't acceptable (not even temporarily) then two options spring to my mind:

  1. SA team run on behalf of the DBAs. Geography and logistics in my organisation are such that having an SA walk over to the DBAs desk is a realistic option. Our SAs aren't keen on this approach
  2. Give DBAs the ability to run as the root user via sudo. This, of course, means that DBAs can run anything they like by editing, so doesn't really help. Understandably our SAs don't like this approach

I am being asked to look into keeping Oracle software version specific scripts in a root-owned location (we are Linux only, so no multi-platform concerns). This would allow for secure sudo privileges. We'd need these for RDBMS, Grid Infrastructure, and Client.

However, I've explained the scripts are dynamically generated by runInstaller and have the Oracle Home path hard-coded into them. We'd need a root-owned for every distinct ORACLE_HOME path we create (some hosts have multiple homes, so there's dbhome_1, dbhome_2 etc.). Maybe there are other considerations that I'm unaware of - I don't really like to second guess what else is going on in the "closed box" of the OUI that could be host dependent.

To my mind, taking this non-standard approach is more risky than having someone run the script on our behalf, even if it risks introducing delays into the build process.

How is this handled in your organisation? Have you ever been asked to have a centralised set of scripts under root control for this reason? Have you made it work?

If anyone has some time to share their experiences, it would be much appreciated.




-- Received on Mon Feb 03 2014 - 18:32:04 CET

Original text of this message