The Road to Operations Manager 2012 – Managing *nix systems


Foreword. It’s been 20 years since the last time I professionally worked on unix systems, so when reading this article keep in mind my knowledge of such systems is obsolete.

The guide has been tested on Red Hat Enterprise 6.x.

Introduction

System Center 2012 Operations Manager improves xPlat monitoring (i.e. monitoring of non windows systems and applications) in several ways: it offers a better and more secure experience in monitoring *nix systems broadening the supported platforms and it introduces the support for J2E (or J2EE) monitoring. This article is about the improvements and correct configuration of *nix systems monitoring.

One of the most notable improvement with System Center 2012 Operations Manager is the ability to install and manage *nix agents without the needing of root privileges. Obviously, since the agent installation process needs to perform privileged operations, it still needs an account that can elevate its privileges to install the agent. This can be achieved via sudo or su. I will focus on sudo. Sudo is for *nix systems what UAC is for windows ones: a way for an unprivileged account to perform privileged actions in a controlled way. Thanks to this new introduction in OpsMgr now we have 3 different user profiles needed for *nix monitoring:

·         An installation / agent management account (root like or “sudoable”)

·         An unprivileged monitoring account

·         A privileged monitoring account (root like or “sudoable”)

http://technet.microsoft.com/en-us/library/hh476947 states the requirements for the three UNIX/Linux action accounts. You can use a single local UNIX/Linux account for all three action accounts, if configured properly, as discussed at http://technet.microsoft.com/en-us/library/hh230690.

You can find suggestions on runas account planning and configuration at: Cross Platform Discovery Settings.

Before digging into the configuration process, a few things to remember:

·         Remote agent installation is performed through SSH (defaults on port 22, configurable)

·         The remote agent is a passive agent, it must be queried by the management server in charge of monitoring to perform anything, in this respect is very different from the Windows agent: with the former OpsMgr is performing a polling, with the latter the agent contact the management server to send monitoring data and ask for configurations. For *nix agents the communication is performed using WS-MAN over SSL (self signed certificate) using tcp port 1270 (not configurable).

 

Basic configuration

The following is my personal checklist to properly enable a secure xPlat system monitoring:

·         Import the proper *nix Management Packs. By default the basic library management packs should be present, they starts with UNIX / Linux

clip_image002

·         Then import the management packs for the platforms you need to monitor

clip_image003

·         Prepare a new Resource Pool for Unix monitoring, this is useful even if the management group doesn’t have a dedicated management server for xPlat monitoring. If high availability is needed at least two management servers (or gateways) must be included in the resource pool

·         Create the monitoring account on the *nix side. To do this you must know a little about sudo. There’s a good step by step guide here (http://technet.microsoft.com/en-us/library/hh230690). The guide suggest to disable the requiretty for sudo altogether for the entire system, this is probably something your *nix admin won’t take easily. Searching the web I found a better way to achieve the same result limiting the batch access to sudo to the operations manager account. Once you modified the /etc/sudoers file with visudo following the technet guide, instead of commenting out the Defaults requiretty line, you can add Defaults:scomaccount !requiretty. Then sudoers snippet should become like this

 

Defaults requiretty

Defaults:scomaccount !requiretty

scomadmin ALL=(ALL) NOPASSWD: ALL

 

This must be done for both the privileged account, personally I prefer to have just one privileged/sudoable account, in the previous example named scomaccount.

·         Once the account(s) are ready, it’s time to define them in Operations Manager, regardless on how many accounts have been defined on the *nix system, I suggest to create three runas accounts, create them as secure distribution and distribute the to the Unix monitoring resource pool (the one just created)

·         Now it’s time to install the agents, again I won’t rewrite what has been shown here Cross Platform Discovery Settings

·         Once the agents have been installed it’s a good idea to create a group of Unix Computers for each different combinations of accounts needed, this is useful if different credentials are needed to manage different Unix systems.

·         The last step is the association of the runas account to the runas profiles, targeting is especially important. If a group has been created then you need to associate the runas account to group, if a group has not been created then you need to associate the runas account to the specific objects (of Unix machine) identifying one by one the single Unix systems.

 

Troubleshooting

To check for sudo commands invoked by Operations Manager take a look at the following log file:

/var/log/secure

– Daniele

This posting is provided “AS IS” with no warranties, and confers no rights.

Advertisements
  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: