Freigeben über

More on Unix Privileged Account vs. Unix Action Account and root-level access context

  • Artikel

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".

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.

Comments

  • Anonymous
    March 10, 2010
    root password is changed so often, we want to use another account with same rights. Can another account be added to group 0 thus providing very similar rights to replace root? If a second account is created with the UserID exactly the same as root (different name) that is essentially a clone of root can it then fully monitor non-windows Thanks

  • Anonymous
    April 14, 2010
    You should be able to do this for all the monitors and privileged actions. The question is qhether it would work for actual installation of the agent since I think root is required for user impersonation as a service.

  • Anonymous
    April 27, 2010
    The comment has been removed

  • Anonymous
    June 10, 2010
    Thanks for the advice! Now you can put it into practice using the process I describe in this article: Using sudo (instead of root) for running privileged tasks (blogs.msdn.com/.../using-a-sudo-account-for-unix-linux-agent-deployment-instead-of-root.aspx)