Operating System - HP-UX
1748265 Members
3824 Online
108760 Solutions
New Discussion юеВ

Re: operators profile in HPUX best practise

 
apple
Super Advisor

operators profile in HPUX best practise

dear HP UX Gurus,
we have few operator ids that are used to execute our database and server shutdown.
our current practise, we share the same profile for all the operators.
when we create the id, we will put the same home path for all.
would like to seek your advice, is that the best practise to share the same profile for all the operators.
many thanks in advance.
3 REPLIES 3
Bill Hassell
Honored Contributor

Re: operators profile in HPUX best practise

Well, do the operators all share the same login? That is not recommended at all because you cannot determine who may have done something incorrectly. Sharing the same HOME directory is not usually a problem if the operators do not create files in the HOME directory. Sharing the same .profile is a best practice for all non-Unix users. Personally, I prefer to limit damage by untrained users with menu scripts, no shell access. That way, they cannot do anything that is not in the menu. Sounds exactly like what your operators need.


Bill Hassell, sysadmin
Tim Nelson
Honored Contributor

Re: operators profile in HPUX best practise

My preference is the same.

Each has their own so you can track. No sharing of .profiles.

I use restricted SAM to give them the abitlity to run admin scripts with the required privelages. SAM takes care of the menuing. Just add a properly protected script, assign the user then assign the "run as" .

User cannot break out, great for audits also, as menu level access to SAM is logged.

A. Clay Stephenson
Acclaimed Contributor

Re: operators profile in HPUX best practise

This is one of those "it depends" situations because if your users are knowledgable then it's very easy to circumvent simple settings in .profiles. Of course, if your users aren't knowledable, why should they have access to the shell at all? In that case, locking them inside a menu is a good technique.

If you do have users that need common settings such as ORACLE_HOME, ORACLE_SID, PATH, ... then a rather good technique is to allow them individual .profiles but each of these profiles should source external files which set and export the required variables.

For example,
create a file /usr/local/bin/oraenv.sh:
ORACLE_BASE=/u01/oracle
ORACLE_HOME=${ORACLE_BASE}:/product/10.0.6
PATH=${PATH}:${ORACLE_HOME}/bin
export ORACLE_BASE ORACLE_HOME PATH

Now each of your users' .profile might do something like this:

ORAF=/usr/local/bin/oraenv.sh
if [[ -r ${ORAF} ]]
then
. ${ORAF}
fi
unset ORAF

This had the added benefit that the users' .profile's and any cron'ed or rc'ed script can also source oraenv.sh and should any changes be needed, you change one file and the change affects all of your files.

NOTE: Such a sourced file should not contain an exit or return statement as that will have the undesired effect of terminating the foreground process.
If it ain't broke, I can fix that.