More on Unix Privileged Account vs. Unix Action Account and root-level access context
A couple of weeks ago, I posted “Privileged and Non-Privileged “Run As” accounts in cross platform monitoring”, which was a brief article giving an overview of Run As accounts for OpsMgr Cross Platform. I ended up writing a long post in the forum about this, since it’s a common question and not documented very well. I thought I’d also write another article about this and not only provide what I said in the forum post, but a couple of other tidbits as well…
Run As Profiles
First of all there's the topic of the two Run As Profiles - the "Unix Action Account" and the "Unix Privileged Account". Each of these profiles needs to be configured and must contain at least one user account to function. They can both use the same account, or they can use different accounts. The Unix Privileged Account must be root if you want all of the rules, diagnostics and recoveries to function . The agent does not currently support sudo accounts. For diagnostics and recoveries, it's possible to override the command used (something like "<p:command>sudo sh -c 'ps -ef | grep syslog | grep -v grep'</p:command>", but sudo passwords cannot be used. The Unix Privileged Account profile is used for certain actions that require root-level privileges to perform. These include some rules, some diagnostics, and most recoveries.
You can find out which monitors, diagnostics or recoveries require which account profile by looking at the management packs (you could use either the Authoring Console to look at the sealed MP or you can access the XML from the Health Service State\Management Packs directory and view it in an XML editor). Just look for things like "Invoke.Privileged.ProbeAction" (compared to the normal "Invoke.ProbeAction"). There's also "Invoke.Privileged.WriteAction" and "SCXLog.Priviledged.DataSource".
- TechNet Documentation: Configuring a Cross Platform Run As Account
Root Account Requirements for the Agent
Next is the topic of why a root account is needed to install the agent, and why the agent runs in root context. Basically, the Linux/UNIX kernel requires root-level privileges in order to access the data counters that the agent uses and reports on. Many of the classes used are read only and we allow them to be queries with a non-privileged account. For classes that also allow write operations (like ExecuteCommand()), the agent runs the command using the credentials of the Run As account. Since only root can spawn processes as other users, the agent requires root context to run. Other processes like the logfile scanning provider use the Run As account to instantiate the provider process to make sure privileged files can only be read by privileged users.
Agent Background Activities
Finally, the answer to "just what is the agent doing in the background when not asked to provide monitor data to OpsMgr?"... The agent is performing collection of performance data in a separate thread. For the delta counters (CPU load, Disk IO, etc.), data is kept in a rolling window, and when OpsMgr asks for it, an average value is returned. There is very little cost in querying the agent for the data, since the data had already been collected. The data sampling interval has been optimized for the OpsMgr-> agent communication interval to reduce load.
Hope this helps.