2 of 2 people found this helpful
It is not mandatory to install the agent as root, but what you want to decide is what mode you will run the (unix/linux) agents in rather than what user you will use to install them?
The mode can be configured post installation so what user you use to install is less critical.
There are three modes to run a UNIX/Linux Agent:
In this mode the agent runs as 'root' so it can trigger jobs as any OS User (defined in the Job Definition in the RUN_AS field) without you having to store the password of the OS user on the agent.
From an on-going operational management perspective this mode is the simplest to maintain as there is no password management needed in Control-M.
The main con for this mode is that users can define jobs to run as 'root' and that may be considered a security problem.
Typically this is mitigated by having a process around job creation and by using Control-M/EM security to manage what RUN_AS users a user can specify in a job.
i.e. APP1 group can be configured to only be allowed to create jobs with RUN_AS of app1*
UNIX ADMIN group can be configured to only be allowed to create jobs with RUN_AS of root
You can further enforce the RUN_AS security if you have Control-M Workload Change Manager by implementing Site Standards and including RUN_AS in the Site Standards rules.
In this mode the agent runs as the agent_owner user (the user that installed the agent).
It can trigger jobs as agent_owner without having to store the password of the agent_owner user in Control-M.
But, to trigger jobs as any other OS user you need to store that user's password in Control-M. (done via utilities, aapi or CCM GUI)
The main con with this mode is the added administrative cost to store/update passwords in Control-M.
The main pro is that the security risk of running a process as root is eliminated.
If all jobs on a specific agent were going to run as the same user so this mode is probably the best option. (but typically you don't know in advance what the RUN_AS users will be on a specific host, and even if that host is dedicated to one application, that app may have multiple batch users it requires to have its jobs run_as)
In this mode the agent runs as the agent_owner user (the user that installed the agent) but you configure the sudoers files to allow agent_owner to run any command as the specific RUN_AS users you intend to run jobs on this host.
The pro of this mode is that you don't need to manage passwords in control-m and that the agent processes don't run as root.
The main con is that you have the added administration of managing sudoers files.
When you install the agent as root, the install automatically starts the agent as root and it is running in root-mode.
When you install the agent as agent_owner, the install automatically starts the agent as agent_owner and it is running in non-root-mode.
To set the agent running mode post install, use the set_agent_mode script. (Control-M 9.0.20 Control-M Documentation - Control-M - BMC Documentation)
You can change the agent running mode any time you want but it requires stop/start of the agent and if you're setting it to root-mode so the root user needs to run set_agent_mode script.
One more point in relation to who/how you run the start-ag and shut-ag scripts:
1. in root-mode: the start-ag and shut-ag need to be triggered by root. So for admins to manually be able to do this for maintenance or troubleshooting, it is recommended to give the admin users sudo permission to run those two scripts.
2. in non-root or sudo modes: the start-ag and shut-ag need to be triggered by agent_owner.
I.e. if you install the agent as root, or run set_agent_mode to set it to root-mode, but then the agent_owner user runs start-ag, it will be running in non-root-mode.
In summary, first decide what mode the agent should run in (typically this will be one part of the overall security model and be considered with the WCM Site Standard definitions and EM Security definitions), then decide what user to perform the install as to make running it in that mode the simplest to configure.
Hope this answer helps and sorry it is so long :-)
That's a great explanation!
Thank you for the explanation!