- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: operators profile in HPUX best practise
Operating System - HP-UX
1748265
Members
3824
Online
108760
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-16-2008 11:16 PM
тАО01-16-2008 11:16 PM
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.
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-17-2008 12:26 PM
тАО01-17-2008 12:26 PM
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
Bill Hassell, sysadmin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-17-2008 02:14 PM
тАО01-17-2008 02:14 PM
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-17-2008 03:57 PM
тАО01-17-2008 03:57 PM
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 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.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP