7.4. Interactions with System Users for Agents and Resources
The agent runs as a specific system user, and so do servers such as JBoss and Apache which are managed by JBoss ON. The general assumption with many of the agent management tasks, including discovery, is that the agent user is the same as the resource user. If the users are different, then that can have an impact on how resources can be discovered and managed.
The common types of servers which JBoss ON manages are:
- JBoss EAP servers
- PostgreSQL databases
- Tomcat servers
- Apache servers
- Generic JVMs
For some management operations initiated by the JBoss ON agent, the agent system user is never even involved. For example, the JBoss EAP plug-in connects to the EAP instance using authentication mechanisms managed by JBoss EAP itself, so no system ACLs or user permissions are required. As long as the user can access the JBoss EAP instance, everything works.
Cheat Sheet for Agent and Resource Users
- PostgreSQL
- No effect for monitoring and discovery.The agent user must have read/write permissions to the PostgreSQL configuration file for configuration viewing and editing.
- Apache
- No effect for monitoring and discovery.The agent user must have read/write permissions to the Apache configuration file for configuration viewing and editing.
- Tomcat
- Must use the same user or the agent can not be discovered.
- JMX server or JVM
- Different users are fine when using JMX remoting; cannot be discovered with different users and the attach API
- JBoss AS/EAP
- Different users are all right, but requires read permissions on run.jar and execute and search permission on all ancestor directories for run.jar
7.4.1. The Agent User
There is a general assumption that the agent runs as the same user as the managed resources, and this is the cleanest option for configuration.
When the JBoss ON agent is installed from the agent installer JAR file, the system user and group who own the agent installation files is the same user who installs the JAR. So, a special system user can be created or selected, and then the agent can be installed by that user.
7.4.2. Agent Users and Discovery
An agent discovers a resource by searching for certain common properties, such as PIDs and processes or start scripts.
It does not necessarily matter whether the agent has superior privileges as the resource user.
For most resources, the agent simply requires read access to that resource's configuration. For resources like Apache and Postgres, as long as the agent can read the resource configuration, the resources can be discovered.
For some other resources, the agent user has to have very specific permissions:
- For JBoss EAP resources, the agent must have read permissions to the
run.jarfile, plus execute and search permissions for every directory in the path to therun.jarfile. - Tomcat servers can only be discovered if the JBoss ON agent and the Tomcat server are running as the same user. Even if the agent is running as root, the Tomcat server cannot be discovered if it is running as a different user than the agent.
- If a JVM or JMX server is running with JMX remoting, then it can be discovered if the agent is running as a different user. However, if it is running with using the attach API, it has to be running as the same user as the agent for the resource to be discovered.
7.4.3. Users and Management Tasks
The system user which the agent runs as impacts several common agent tasks:
- Discovery
- Deploying applications
- Executing scripts
- Running start, stop, and restart operations
- Creating child resources through the JBoss ON UI
- Viewing and editing resource configuration
The key thing to determine is what tasks need to be performed and who needs to perform that operation, based on limits on the resource or the operating system for permissions or authorization.
For some actions — discovery, deploying applications, or creating child resources — setting system ACLs that grant the agent user permission are sufficient. This is covered in Section 7.5, “Running the Agent as a Non-Root User”.
For running operations or executing scripts, it may be necessary to run the task as a user other than the agent user. This can be done using sudo.
Whatever method, the goal is to grant the JBoss ON user all of the required system permissions necessary to carry out the operations.
7.4.4. Using sudo with JBoss ON Operations
The time to use sudo is for long-running operations, such as starting a service or a process, or for scripts which are owned by a resource user. The user which executes the script should be the same as the resource user because that user already has the proper authorization and permissions.
The user can really be the same, or the JBoss ON user can be granted sudo rights to the given command.
When elevating the agent user's permissions, two things must be true:
- There can be no required interaction from the user, including no password prompts.
- It should be possible for the agent to pass variables to the script.
To set up sudo for resource scripts:
- Grant the JBoss ON agent user sudo rights to the specific script or command. For example, to run a script as the jbossadmin user:
[root@server ~]# visudo jbosson-agent hostname=(jbossadmin) NOPASSWD: /opt/jboss-eap/jboss-as/bin/*myScript*.sh
Using the NOPASSWD option runs the command without prompting for a password.ImportantJBoss ON passes command-line arguments with the start script when it starts an EAP instance. This can be done either by including the full command-line script (including arguments) in thesudoersentry or by using the sudo -u user command in a wrapper script or a script prefix.The second option has a simplersudoersentry - Create or edit a wrapper script to use. Instead of invoking the resource's script directly, invoke the wrapper script which uses sudo to run the script.NoteFor the EAP start script, it is possible to set a script prefix in the connection settings, instead of creating a separate wrapper script:
/usr/bin/sudo -u jbosson-agent
For example, for a start script wrapper,start-myScript.sh:#!/bin/sh # start-myScript.sh # Helper script to execute start-myConfig.sh as the user jbosson-agent # sudo -u jbosson-agent /opt/jboss-eap/jboss-as/bin/start-myConfig.sh
- Create the start script, with any arguments or settings to pass with the
run.shscript. For example, forstart-myConfig.sh:nohup ./run.sh -c MyConfig -b jonagent-host 2>&1> jboss-MyConfig.out &
