Oracle lockdown, agents, and EM Jobs

From: "Herring, David" <HerringD@xxxxxxx>
To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
Date: Wed, 18 Jun 2014 17:07:53 -0500
Folks,

As some of you may recall I've been placed in a situation where we need to lock 
down all access of "oracle" at the OS level, have hundreds of existing installs 
where GI, Oracle, and the management agent are installed as "oracle" (RAC, 
non-RAC + 10g, 11g), along with many custom EM Jobs for DBA maint and 
monitoring.

What I've run into is a bit of a complexity in dealing with OS environment, the 
agent, and EM Jobs.  I thought I'd try to post the whole situation here since I 
have a tendency to make things overly complex and I may be missing something 
obvious (as the old programmer saying goes, if it was hard to write it should 
be hard to understand).

<setup>
1)  User "oracle" has no direct login or shell available.  All commands to run 
as "oracle" must be run under our individual accounts prefixed with "sudo -u 
oracle".

2)  Only 1 command can be run at a time as "oracle" (no shell).

3)  Cron access is gone, so anything we want scheduled must be from EM.

4)  Periodically DBAs have to restart/fix agent issues, so they restart the 
agent using something like "sudo -u oracle $AGENT_HOME/bin/emctl start agent".  
The agent now runs as "oracle" yet has all it's environment inherited from the 
DBA who ran the command.

5)  We have 50 or so maint/monitoring scripts stored either on a NAS or 
locally.  In both cases they follow the same directory structure but the mount 
may have a different name.  To get around this all .bash_profile scripts for 
"oracle" set a variable for the mount, like "MNT".  Therefore regardless of 
shared or local the scripts would always be found under $MNT/...  This also 
means the scripts can't be found by "oracle" unless .bash_profile is first 
sourced.

6)  We have 12 DBAs on our team with accounts managed by a RedHat LDAP server.  
The DBAs are in charge of x number of environments, with "x" depending on 
complexity and what the given DBA can handle.  DBA shifts cover 24/5 with 
oncall the other 2.
</setup>

Lets say I have maintenance script $MNT/admin/shell/x.sh.  Creating this as an 
EM Job (EMJ) I need OS credentials and I also need to make sure $MNT is known.  
So I make the command line of the Job ". ~/.bash_profile; sudo -u oracle 
$MNT/admin/shell/x.sh".  Since all DBA accounts are basically the same it 
doesn't matter whose credentials are used so lets say Mark's account is used.  
Lets also say that earlier the agent on this server had an issue and Tim, 
working a different shift than Mark, fixed the problem and restarted the agent.

The agent runs as "oracle" but it's environment is all set off Tim's account.  
Now EM Job "EMJ" fires off and users Mark's credentials, so as "markb" it tries 
to run /user/timg/.bash_profile.  Why under "/user/timg"?  Because 
$HOME=/user/timg, since Tim restarted the agent.

Lost interest yet?  I have a few options on how to fix this but before I try I 
figured I better check with more folks as again, I want to avoid making this 
more complex than it has to.  I'll reply to this with options as I see them in 
case the 1 or 2 people still reading this are interested.

Dave Herring


--
//www.freelists.org/webpage/oracle-l
Oracle lockdown, agents, and EM Jobs

Other related posts:
