IBM Tivoli Monitoring > Version 6.3 Fix Pack 2 > Installation Guides > Agent Installation Guides > Linux Agent Installation Guide > Agent installation and configuration
IBM Tivoli Monitoring, Version 6.3 Fix Pack 2
Run as a non-Administrator user
The monitoring agent can be run by a non-Administrator user (a non-root user), however some functionality becomes unavailable.
The Machine BIOS information uses the dmidecode executable to extract the relevant information. This Linux provided executable must be run by the Administrator user to extract BIOS information. This attribute group does not report data if the agent is not run by the Administrator user. This information is also used by Tivoli Application Dependency Discovery Manager.
A non-Administrator user can only access the directories that it has permissions to read. Therefore, functionality of the File Information attribute group might be reduced.
For Agent Management Services, data reported in the Agent Active Runtime Status attribute group, for example the PID, the command line, the CPU, and the memory, might also be affected when the non-Administrator user is monitoring agents running as a different non-Administrator user.
Also for Agent Management Services, the watchdog cannot stop or start any agent that it does not have privileges to stop or start. If the OS agent is running as a user other than Administrator but you would still like to use it to stop and start other agents, the sudo facility on UNIX and Linux provides one way of supporting this capability. In the example that follows, the OS agent user is a member of a group called 'itm'. Also, it is assumed that Agent Management Services will not be prompted for a password to perform these operations and that the target agents' user IDs are 'user1' and 'user2':
# sudoers file. # # This file MUST be edited with the 'visudo' command as root. # Failure to use 'visudo' may result in syntax or file permission errors # that prevent sudo from running. # # See the sudoers man page for the details on how to write a sudoers file. # # Host alias specification # User alias specification # Cmnd alias specification
Cmnd_Alias AMSAGENTSTART = /opt/PAS/ITMTEST/bin/itmcmd agent -[po] [[\:alnum\:]_]* start [[\:alnum\:]][[\:alnum\:]],/opt/PAS/ITMTEST/bin/itmcmd agent start [[\:alnum\:]][[\:alnum\:]]
Cmnd_Alias AMSAGENTSTOP = /opt/PAS/ITMTEST/bin/itmcmd agent -[po] [[\:alnum\:]_]* stop [[\:alnum\:]][[\:alnum\:]],/opt/PAS/ITMTEST/bin/itmcmd agent stop [[\:alnum\:]][[\:alnum\:]]
Cmnd_Alias ITMAMSCMD = AMSAGENTSTART,AMSAGENTSTOP
# Defaults specification # Runas alias specification Runas_Alias ITMAGENTIDS = user1,user2 # Same thing without a password %itmusers ALL=( ITMAGENTIDS ) NOPASSWD: ITMAMSCMD
This is just one possible example. The sudo facility has many advanced capabilities including the ability to audit and to alert administrators of usage of the sudo command by unauthorized users. See your operating system's sudo man pages for more information.
In the agentInstanceCommand.sh script, replace calls to 'su' with calls to 'sudo'. For example:
if [ -z "$USR" ]; then $START_CMD else # su - $USR -c "$START_CMD" sudo -u $USR $START_CMD fi ... if [ -z "$USR" ]; then $STOP_CMD else # su - $USR -c "$STOP_CMD" sudo -u $USR $STOP_CMD fi
Ensure that the user1 and user2 users also have write permission to any files to which an application agent needs to write.
Parent topic:
Agent installation and configuration