ITM Centralized Configuration

by Anthony Mico

One of the interesting recent additions to the IBM Tivoli Monitoring product is the Centralized Configuration feature.  This feature provides ITM agents with a pull-based mechanism for obtaining configuration files such as situation threshold overrides and Universal Agent meta files from a central configuration source.  The configuration source can be either a web server or another ITM agent.  In addition to the ITM specific configuration files, a CUSTOM type is also supported meaning that any type of file can be handled by this mechanism.  One area where this could be particularly useful is with the management of configuration files used to drive custom agents built with the Agent Builder tool.  Where the monitoring requirements for things like filesystems and processes can vary considerably from one server to another, a not uncommon approach is to use a custom agent with locally defined threshold information to perform the monitoring.  Whilst this provides a great deal of flexibility, it does introduce a headache when it comes to managing those configuration files, something which the Centralized Configuration feature may help to solve.

There are a number of ways that you can organise the content held at the configuration source but for the purposes of this tip I’m going to work on that basis that we want to be able to manage a set of configuration files on a per product/per server basis. As such, the following directory and file structure is created on the web server:

 CCF 1

At the heart of the agent-side configuration is a configuration load list which provides the agent with the details of the configuration source (e.g. URL and access credentials), as well as the specific files it should request.

The default location for the configuration load list is $ITM_HOME/localconfig/pc/pc_cnfglist.xml (where pc is the agent product code), although this can be changed via the IRA_SERVICE_INTERFACE_CONFIG_LOADLIST environment variable.

The initial load list for the agent is shown below:

 CCF 2

The configuration source details are provided in the ConfigServer element.  In this example, a local Apache webserver is being used to host the configuration files, which are located under the configserver directory.  The password for the itmuser user has been encrypted using the itmpwdsnmp utility.

Each ConfigFile element identifies a file that the agent should request.  The Disp attribute indicates the type of file that is being requested, CFNGLIST in this case indicates that the file to be downloaded is another configuration load list, the significance of which will be explained shortly.  The Name attribute identifies the name of the source file and the Path attribute details where it is located relative to the ConfigServer URL.  In both cases we can use keyword substitution to dynamically build the values.  So in this example, the agent installed on a server with a hostname of itm623 would request the URL ‘  http://localhost/configserver/lz/hosts/itm623/itm623_cnfglist.xml’.

The itm623_cnfglist.xml file held at the configuration source looks like this:

 CCF 3

This file is similar to the first however it contains two additional ConfigFile entries, which reflect the files we wish the agent to download. The LocalPath and LocalName attributes are used to specify what the downloaded file should be named and where it should be located.

The flow for the processing of these files is as follows:

1) Agent processes the initial load list and requests   http://localhost/configserver/lz/hosts/itm623/itm623_cnfglist.xml

2) As the file requested is of type Disp, the existing configuration load list lz_cnfglist.xml is replaced with the contents of itm623_cnfglist.xml

3) The new configuration load list is processed and   http://localhost/configserver/lz/hosts/itm623/itm623_cnfglist.xml is requested

4) As no changes been made to   http://localhost/configserver/lz/hosts/itm623/itm623_cnfglist.xml since the last time it was requested, no further action is taken

5) The file   http://localhost/configserver/lz/hosts/itm623/itm623_1.txt is requested and downloaded to ITM_HOME/tmp/itm623_1.txt

6) The file   http://localhost/configserver/lz/hosts/itm623/itm623_2.txt is requested and downloaded to ITM_HOME/tmp/itm623_2.txt

7) Agent sleeps until the next request interval, denoted by the IRA_SERVICE_INTERFACE_CONFIG_INTERVAL (default is 60 minutes)

Notice that the itm623_cfnglist.xml file contains a reference to itself. This ensures that should any changes be made to this file at source, such as the additional of further ConfigFile elements, the changes will be detected by the agent and the new configuration load list will be downloaded and processed.  If you use this technique do not alter the IRA_SERVICE_INTERFACE_CONFIG_BYPASS_TIMESTAMP environment variable (default value is N) otherwise the agent will enter an infinite loop downloading and re-processing the configuration load list.

The Centralized Configuration feature could prove to be a useful addition to the systems management utility belt, although in some regards it could be argued that it just re-locates the management headache rather than solving it. After all, problems relating to the auditing and revision control of changes still exist, as does the implementation of an authorisation model controlling who can and can’t make what changes.  If these are challenges you are facing, perhaps you might be interested in our SSP product which addresses these problems and does so much more.

Views: 188