Building a CentOS Management Pack (part 2)

Inpart 1 of this article, I talked about the basics of building a CentOS Management Pack, beginning with trying out the Red Hat agent. Now I’ll continue the article where I left off, talking about building the MP itself.

Creating the Management Pack

In order to replicate everything I did, it helps to understand a bit of the process surrounding the cross platform management capabilities in Operations Manager 2007 R2. First of all, there’s the schema, or organization, of the libraries and management classes related to UNIX and Linux. Here is a section of the schema chart for the classes for Red Hat related to the System.LogicalHardware class:

You’ll notice that there are several levels that drill down into further and further detail: UNIX - > Linux -> Red Hat -> RHEL 5. Each lower level derives from and adds greater detail to the more common properties of the one above. This is a basic concept of Operations Manager (hey, I said I was new to this, so bear with me).

After I wrote the last article “Using OpsMgr Class Inheritance to Extend Monitoring to New (Unsupported) Operating Systems” I thought about going a different direction in creating this MP than I was going to do originally. I thought about using overrides and inheritance to extend the RHEL.5 MP for CentOS, but in the end I decided to stick with the “copy, search and replace” method. The reason was the same one we have for creating virtually identical RHEL4 and RHEL5 MPs – because if anything changes in the base, it could break the derivative if the derivative didn’t need to change.

So what I’m going to demonstrate here is taking the existing Red Hat Library and the Red Hat 5 Management Pack and then creating new MPs to support CentOS 5. The graphic below sort of demonstrates how these new MPs will fit into the hierarchy.

Creating the CentOS MP XML Files

The first thing I need to do is to get copies of the Red Hat Library and Red Hat 5 MPs. Since these MPs are sealed, I need to export them into XML format so that I can see what needs to be changed. To do this, I got the MpToXml.ps1 PowerShell script for converting sealed MPs to XML from the OpsMgr++ Blog here: Converting a sealed management pack to readable XML. This PowerShell script really only does two things (using the public OpsMgr SDK): creates a management pack object from the MP specified, and then writes it out to XML.

I ran the script to export the MPs (RHEL.5 shown below):

I copied these files to a new location and renamed them Microsoft.Linux.CentOS.Library.xml and Microsoft.Linux.CentOS.5.xml. I opened these files and did a search and replace on the following strings (you should do them in this order):

Root XML Element Changes

Because the XML comes from a sealed MP, the “ManagementPack” element in the XML includes a “RevisionId” attribute, and the “ContentReadable” attribute is set to “false”. And, since our new CentOS MP is not sealed, this needs to be changed. Just remove the “RevisionId” attribute and its setting, and set “ContentReadable” to “true”, as the example shows below:

<ManagementPack xmlns:xsd="https://www.w3.org/2001/XMLSchema"
xmlns:xsl="https://www.w3.org/1999/XSL/Transform" ContentReadable="true">

Identity Element Changes

Just like the above, a sealed MP has a PublicKeyToken value inside the Identity element. Because this MP is not sealed (yet), this element needs to be removed. Just remove the whole element and its contents as shown below:

Next, there are specific changes for the individual files.

Changes to the Library XML File

Computer Discovery Changes

While it’s true that CentOS is a derivative of Red Hat, and as you saw in the first part of this article, the Red Hat agent works on CentOS, unless we change something in the discovery to distinguish a CentOS computer from a Red Hat computer, OpsMgr won’t know which is which.

If we look back at the output from the command to scxcimcli enumerating the SCX_OperatingSystem class, then compare that to the same output from a Red Hat computer, the “Name” property of both is “Red Hat Distribution”. However, looking at the “Caption” property, the CentOS computer has a value of “CentOS release 5.4 (Final) . This is what we’ll have to use to distinguish the two computer types.

To make this change, look for the Monitoring -> Discoveries -> Discovery element with an ID of “Microsoft.Linux.CentOS.Computer.Discovery”. Now just change the values of the FilterProperty and FilterValue elements in the XML to the values shown below:

There’s one more change needed in this discovery to make it work. We could have put the exact OS version string in the FilterValue property (“CentOS release 5.4 (Final)”), but that would make it fixed to that specific build, and since this is a general CentOS library, we want it to work with any version. The version-specific MP should have that information in it, not this one. So what I did was I just put the beginning of the string there (enough to distinguish that it’s CentOS). However, if you look at the DataSource element below, it’s using an “Equal” comparison, so a partial match is not a match. This needs to be changed to “ContainSubstring” so we can do the partial comparison:

We’re done editing the library XML, so save the file and close it.

MP Sealing Requirements

Since I mentioned the previous MPs were sealed, now is a good time to talk about sealing requirements. Any time an MP references or extends another MP, the base MP must be sealed. This means that if I want to replicate the OS Library -> OS Version structure of Red Hat’s MP, I have to seal the new CentOS Library MP in order for the CentOS 5 MP to extend it.

In order to seal an MP you will need a key file, which is a strong name key ending with an extension of “.snk”. You can create a key using the Strong Name Tool, and use it for signing any of your custom MPs.

Once you have the key file, the easiest way to seal an MP (and check it for issues in the process) is to use the Operations Manager Authoring Console. Open the XML file for the Library (you may need to locate the UNIX and Linux Library MPs as well). Verify the MP is structured correctly by selecting Tools > Verify, and you should get a success notification like the one below:

Next, select File > Save As > Sealed and Signed Management pack from the menu. The file should automatically be named Microsoft.Linux.CentOS.Library.mp. Click Save. Enter appropriate values for Company name and Copyright, and click the button on the right to browse to your key file created above.

Click OK. A new .mp file is created in the target directory.

Changes to the CentOS.5 XML file

Reference Changes

This XML references the CentOS.Library MP because it extends that MP. However, the PublicKeyToken value for this reference needs to be changed to point to the specific value from the sealed MP you just created. Since this was a cut and paste, the current value points to the Red Hat MP value. You can get the value for this by using the sn.exe utility again with the following command line:

The utility will display something similar to the following (your PublicKeyToken value will be different):

Now take this value and replace the current value in the XML, similar to the following:

Computer Discovery Changes

Just like the Library MP, the CentOS.5 MP needs to change what it’s looking for to classify the discovered system as a CentOS 5 computer. To make this change, look for the Monitoring -> Discoveries -> Discovery element with an ID of “Microsoft.Linux.CentOS.5.Computer.Discovery”. Now just change the value of the FilterValue element (since it already uses the “Caption” property”) in the XML as shown below:

The same change needs to be made to the Microsoft.Linux.CentOS.5.OperatingSystem.Discovery element contents.

So now we have a library MP file (signed and sealed) and a CentOS.5 MP file (still in XML format) that references the library. The next step is to import the MPs into OpsMgr and use them. I’ll cover that in the next installment of the article.