Building a CentOS Management Pack (part 3)

In part 1 of this article, I talked about the basics of building a CentOS Management Pack, beginning with trying out the Red Hat agent. In part 2, I talked about how to build the actual MPs. Now I need to actually install the MPs and make sure it all works.

Importing the Management Packs

To import the MPs:

1. Go to the OpsMgr console and from the Administration pane on the left, right-click on Management Packs and select Import Management Packs.
   
2. Click Add > Add from Disk and then click on No at the Online Catalog Connection prompt.
3. Select the library MP file (not the XML file) and the CentOS.5 XML file, and click OK.
   
4. You’ll see the two MPs in the list for import. Click Install. The MPs begin importing and each will show status of Imported when done.
   
5. Click Close to exit the wizard.

Deploying the Agent

II made sure I uninstalled the SCX agent from my test machine (using “rpm –e scx”) so that I could test agent deployment, which would now be automated. Just to be absolutely sure it would be a clean install, I made sure all “microsoft” directories were removed from /opt, and /etc/opt (which also removed the certificate). I also deleted the computer from OpsMgr.

Now we need to go through discovery and deployment of the agent. Right-click inside the Administration pane in OpsMgr and select Discovery Wizard. Select Unix/Linux computers and click Next. Click Add, enter the appropriate information for the remote computer, and enter root-level credentials. Click OK when done to save the entry.

Note: Make sure Enable SSH based discovery is checked or you’ll have to manually install the agent.

Click Discover. The discovery process starts and when complete, you should see something similar to this:

Note that it shows the operating system as CentOS. This means that the discovery in the MP we imported worked successfully. However, it’s set to “No Action” and if I click Details, the dialog states that this is an unsupported platform.

It just so happened that I was running the DebugView utility during my discovery, which allowed me to see some deeper information about what was going on. Looking at the output, I see the following:

Return from DiscoveryTaskHelper.GetSupportedAgentInfo() Microsoft.MOM.UI.Console.exe Error: 0 : 10.10.10.15: Did not find a matching supported agent.

The issue is that when the discovery runs, it returns information from the computer telling it the OS, architecture and other information. This information is matched against the MP’s discovery info, and then an agent file name is built from the settings information. If the agent file is not found in the AgentManagement\UnixAgents directory under OpsMgr’s installation directory, then this error occurs.

Here’s the XML that the discovery script returns to the Management Server:

<DiscoveredOS> <Hostname>myhost.microsoft.com</Hostname> <OSName>CentOS</OSName> <OSAlias>CentOS</OSAlias> <Version>5.4</Version> <Arch>x86_64</Arch> <IsLinux>true</IsLinux> </DiscoveredOS>

These values are mapped to the MP’s discovery settings like this:

• OSAlias -> OS
• Version -> MinVersion (only the major version is compared)
• Arch -> Arch

Going back to the first part of this article, I see that the Red Hat agent files begin with “scx-1.0.4-252.rhel.5". So, I find the two files (one for x86 and one for x64) and create copies of them, and then rename the copies to the following:

• scx-1.0.4-252.centos.5.i386.rpm
• scx-1.0.4-252.centos.5.x86_64.rpm

This corresponds to the following properties in the Discovery Settings:

Property Name	Value in MP	Value in agent file name	Comparison
Version	1.0.3	1.0.4	If version of agent file is => this version, it can be used
Build	106	252	If build of agent file is => this build #, it can be used
OS	CentOS	CentOS	Must be equal
KitOSVersion	5	5	Must be equal
ArchKitName	x86_64	x86_64	Must be equal
Ext	rpm	rpm	Must be equal

After creating these files, I restarted the System Center Management and System Center Management Configuration services to make sure that everything was reloaded and not cached, or the discovery could fail again because OpsMgr didn’t know about the changes. After going back through the Discovery Wizard, I can see the output changed. The Action now shows as “Install Agent and Discover” and clicking on the Details button displays the message “Install agent and discover computer instance into Operations Manager.”

I can now select the checkbox next to the computer and the Next button is enabled. Click Next to start the deployment process. The Status field on the wizard will update as different actions occur.

If everything was successful, the status will display as such, and you can now click Done to end the process. If things didn’t work (probably a certificate error), then you can troubleshoot that and try again.

Monitoring the CentOS Computers

Now that a CentOS computer has been discovered, new things appear in the console. If you go to the Monitoring pane of OpsMgr, then drill down to Unix/Linux Servers->Linux, you’ll see a new CentOS Computers Diagram. You should see something like this:

Unfortunately, because of the standard Red Hat discoveries’ configuration, you will also see this under the Red Hat Computers Diagram.

We can take care of this issue a little later. First we need to make sure everything is working as expected. Right-click on the CentOS computer and select Health Explorer. This opens the Health Explorer for that computer, and you should see something similar to this:

 

You’ll notice that some monitors are clear, and some monitors show green checkmarks even though there’s not any state change events for that monitor. This is not abnormal, but this bears some further investigation.

First, we want to make sure that all the discoveries and monitors are enabled. This is the only way to test that they work. The easiest way to check this in the console is to go to Authoring > Management Pack Objects > Object Discoveries. Click on Change Scope at the top right to filter everything just to what we need, which is the CentOS objects. Just type in CentOS in the Look for box, then click Select All, then OK.

From this list, you can see that two discoveries, Physical Disk and Processor, are not enabled by default (the same as the default Red Hat MP).

To enable these, just right-click on them and select Enable. Looking at all the Monitors and Rules, it appears that they are all enabled by default, so no changes needed here.

There are also the potential requirements for all the discoveries to actually fire. By default, some discoveries may take hours before they fire again, so you rely on cookdown for some stuff, and a repeat fire for other stuff. Just to make sure my discoveries are firing again instead of waiting for some potentially long timeout period, I restart the services again. Here is what I end up with:

 

 

 

 

 

 

 

 

 

 

 

 

So far so good… it now looks like I have status monitoring for everything except Application/Service Availability, Availability - Processor0, Performance – eth1, and Security. Everything else is now showing a green checkmark. Assuming these are not just timing issues, let’s go investigate.

Looking back in Authoring -> Management Pack Objects -> Monitors, I can see that in the CentOS Linux 5 Processor group, there isn’t any monitor configured for the Availability category. So that makes sense that there’s no monitor status for that in the Health Explorer. It looks like the same is true for Performance under CentOS 5 Linux Network Adapter and Security under CentOS 5 Linux Computer.

So, it looks like we’re getting monitoring information for all the things we should be getting monitoring for. The next thing to do is to test that when things aren’t working, that the monitors change state, and that the diagnostics and recoveries work as expected.

Want to download the completed Management Pack? It's available from the "Source Code" section of the CodePlex site (not in release downloads) Go here: https://scxcommunity.codeplex.com/SourceControl/list/changesets

Comments

• Anonymous
  January 19, 2010
  The comment has been removed

• Anonymous
  January 20, 2010
  Hi Adrian, I need to get more details in order to help. Can you email me directly using the email link on my profile here: http://blogs.msdn.com/user/Profile.aspx?UserID=53946

• Anonymous
  April 13, 2010
  I followed instructions closely. The CentOS server gets discovered, and an agent can be installed. I'm having problems with performance data discovery. All health circles are empty, with only green checks in Heartbeat and Configuration. All discovery objects are enabled. Any ideas? SCOM 2007 R2 with Xplat Upgrade 2 discovering CentOS 5.3 Thanks,

• Anonymous
  April 14, 2010
  Try using the MPs available on the CodePlex site (http://scxcommunity.codeplex.com/) If that doesn't work, you'll want to start checking logs.

• Anonymous
  April 26, 2010
  Hi, I used the MPs from CodePlex, only modifying the public key token in the Microsoft.Linux.CentOS.5.xml file after sealing and signing the Microsoft.Linux.CentOS.Library.xml file. It detects the OS as CentOS, and installs the rpm properly. But after the installation, the computer doesn't appear under the CentOS Computers, nor has as many monitors as it should under the Health Explorer. I did the last bits of the procedure above, with no problems. Any ideas? Thanks, Isaac

• Anonymous
  April 27, 2010
  I'm not sure what you mean by it doesn't have "as many monitors as it should". Do you mean that the actual number of monitors is not the same as the Red Hat MP, or that the number of active monitors is low (meaning some monitors are active and some are not)? Does the computer appear under Red Hat?

• Anonymous
  April 27, 2010
  well, after a couple of hours everything appeared as it should.... Didn't know you had to wait so much to get the data and the computers appearing under the CentOS Linux Computers Group. Is there a way to force the pull (of push) of data from the agent? I did a new install, and only used the CentOS mp, now linux computers doesn't appear at all, after a successful discovery. Are always needed the redhat MPs? Thanks, Isaac

• Anonymous
  June 10, 2010
  Hi Isaac, You shouldn't need the Red Hat MPs if you've created a CentOS MP and a CentOS Library MP. You may have accidentally added a reference to a Red Hat class or the MP or something. The issue with discoveries is that it has to wait 5 minutes between trips, and if the data source module is collecting one thing at a time, it may take a while to get everything populated. You can force it to work faster by overriding the interval to something shorter, but don't leave it that way :)

• Anonymous
  December 09, 2011
  Great article! However I did not manage to push an agent. I'm getting this error: No installable agent is available. Although I have renamed the unix agents into: scx-1.0.4-277.centos.5.x64 and scx-1.0.4-277.centos.5.x86 The discovered system is: centos 5.7 Any idea? Regards, Chris

• Anonymous
  February 13, 2012
  I am also getting the "No installable agent is available" and I have also renamed the rpm and followed all other guidlines

• Anonymous
  September 18, 2012
  Hi Guys, I successfully imported the management pack and was able to discover the CentOs Linux machine. But the state remains "Not monitored". Is there a way to check if agents are sending data to server or troubleshoot the problem. Please help.

• Anonymous
  October 21, 2012
  Hi Robert, i am looking for a solutin to integrate CentOS 6.3 into SCOM 2012. Do you have experiance with the "newer" SCOM and CentOS? Best Regards Ralf

• Anonymous
  October 22, 2012
  I suspect this post is not going to get updated to reflect the details of System Center 2012 OpsMgr.  The reason is that the upcoming SP1 update for System Center 2012 will include built-in official support for CentOS, including CentOS 6.3.  A Beta version of System Center 2012 SP1 is already available for download, and the Beta version includes the CentOS support. If you have further questions in this area, I recommend the OpsMgr Linux/UNIX public forum -- see social.technet.microsoft.com/.../threads.  This public forum has a fair amount of activity and is probably seen by a wider range of people than the comments on this blog post.