"best practice" root.sh

[Raf_L]

Team,


Executing root.sh does not need to happen to often, I know. But when you have 200 Oracle servers, changes are big "root.sh" has to be executed nevertheless once or more a week (200 servers, 1 patching per year --> more or less 1 server a day)

DBA's don't get root access, period !

We need to find a trick, and I'm convinced that sudo does this trick very well. Maybe also rbac.

I just wanted to ask you as the community for some tipes and tricks, especially about the fact that "root.sh" is writable by oracle-user, so if oracle-user wants to be nasty, he can....

brgds,


Raf L

[Richard Hepworth]

Hi there,

sudo does do the trick as you say but the risk is there with root.sh being editable by the oracle user. I guess it comes down to trust mainly, either trust the dba's to do their job or keep the overhead of running root.sh for them yourselves (which is not the worlds most exciting part of being a sysadmin ;-) ).

If using sudo make sure you enter the full path to most common root.sh's in the sudoers file

[Mel Burslan]

I second the opinion above. Running root.sh being the most mundane thing in your day, it still is a necessary evil.

even though as sysadmins, we generally trust the DBAs and run the script unquestioned, in fact it needs to be scrutinized before each run as some malicious code might get inserted in it.

running scripts as root via sudo is a generally frowned upon practice due to the gaping security holes it introduces.

Good luck

[Bart Paulusse]

Hi Raf,

The actions root.sh performs are not rocket science. A few chmod, mkdir and cp commands, that's all. The only real reason for root.sh to be executed as user root are these 2 lines:
"$CHOWN root $ORACLE_HOME/bin/dbsnmp"
"$CHOWN root $ORACLE_HOME/bin/oradism"

You could create your own root.sh substitute script, UNWRITABLE but executable for the oracle user, and in the script, you perform the commands with sudo.

That way, you prevent abuse of the root.sh script and you don't have to give your dba's root access.
It may mean that you have to create a few versions because the root.sh script may vary from release to release.

Regards,
Bart

[Eric Antunes]

Hi,

I think the best aproach would be to create a new user with root access and password aging for DBA's.

dba's would be required to inform previously sysadmin before root.sh kinds of maintenance.

PS: I'm dba and sysadmin and the me sysadmin has never had reasons for complaints about me dba. ;-)

Best Regards,

Eric Antunes