However, sometimes the monitored Java applications execute as a privileged user who is different than the user running the JON agent, or who is not allowed to connect directly via ssh. This is even more of a problem if the default umask of that privileged user ID prevents even read access by other users.
In these cases developers and sysadmins typically ssh to the server, then use the 'sudo' command to access the application files. The rules that allow this are defined in the "sudoers" file using the "visudo" command. (See the Linux man pages for more information about sudo.) The following explanation assumes familiarity with these commands.
RTI supports using sudo(8) on a per-collector basis by reading a special file before executing a collector-specific operation. The special file is called .ocs-rti-sudoers, and is searched for first in $HOME, then in /var/opt, then in /var/tmp, then in /tmp.
The format of the .ocs-rti-sudoers file is:
If the RTI command includes a collector that matches the pattern on the left, the $RTI_HOME/py/rti command is executed with
sudo -u uid $RTI_HOME/py/rti ......
For example, if tomcat and jboss applications ran as user 'jboss' on a given server, then server:/var/opt/.ocs-rti-sudoers might contain:
Then the command
/opt/ocsystems/rti/ee64/bin/rti server get_collector_data -c tomcat_opt_apache-tomcat-7.0.26 ...
would in turn execute
sudo -u jboss /opt/ocsystems/rti/ee64/py/rti -c tomcat...
To support this, the user or sysadmin uses the visudo command to add entries in the /etc/sudoers file similar to the following:
## Allow jsmith to sudo to jboss to run RTI preserving RTI variables
Cmnd_Alias RTI = /opt/ocsystems/rti/ee64/py/rti
Defaults:jsmith env_keep+="RTI_HOME RTI_DATA JAVA_HOME"
Defaults:jsmith !require_tty
Defaults:jsmith !authenticate
jsmith ALL=(jboss) NOPASSWD: RTI 
To see what these mean and how to extend it to multiple users or systems with other restrictions, refer to the sudoers(8) man page.

loading table of contents...