Centralized Configuration design

IBM Tivoli Monitoring > Version 6.3 Fix Pack 2 > Administrator's Guide > Agent-based services > Centralized Configuration
IBM Tivoli Monitoring, Version 6.3 Fix Pack 2

Centralized Configuration design

The Centralized Configuration structure that you define depends on the size and organization of your monitored enterprise, the types of monitoring agents you want to maintain, what kinds of updates, and how often.

Configuration load list
Any newly installed monitoring agent or an existing agent can participate in Centralized Configuration by using a configuration load list. The configuration load list is an XML configuration file that is unique to the running agent. It tells the agent how to connect to one or more central configuration servers and what files to download from those servers.
Administrators maintain and update the configuration file in this centralized repository. New agents collect initial configuration files from this location and periodically or on-demand contact the server to collect any updates or changes.

Central configuration server

The configuration load list contains one or more ConfigServer elements that tell the agent how to connect to a central configuration server. Central configuration servers contain a repository of files that are served to the monitoring agents using HTTP.
The server authenticates requests, examines the configuration article last update time stamp (set to GMT), and, if the client copy of the requested file is older than the server copy, the server returns the configuration article contents to the agent. Otherwise, it returns HTTP status 304 - Object Not Modified. The server returns other HTTP status if an error is encountered during article processing. When deploying a central configuration server, consider these factors:
User access

Administrators require access to maintain the configuration load list that are to be distributed. The central configuration clients need access to the central configuration server to collect the updates. If you already have a web server and are familiar with access and maintaining files there, you can use any available web server to act as a central configuration server. This includes the web server for the Agent Service Interface.

Directory structure

Identify a directory structure on the server and client that enable you organize your files, to minimize any duplication on the server, and to reduce the number of files that must be maintained.

Keyword substitution

Use keyword substitution in the configuration load list can simplify the organization of configuration files.

For example, if all of the Linux OS agents run one set of private situations with events defined and the Windows OS agents run another set, the @PRODUCT@ keyword can be used to direct the agents to the correct directory and file on the central configuration server. Place the files in the install_dir/localconfig directory or as specified by the IRA_SERVICE_INTERFACE_CONFIG_HOME environment variable. For example,

common
     cnfglist.xml

lz
     lz_situations.xml
     lz_trapcnfg.xml

nt
     nt_situations.xml
     nt_trapcnfg.xml
The cnfglist.xml file can use the @PRODUCT@ keyword to direct the agents to the correct files. Example:
<ConfigurationArtifact>
  <ConfigServer
   Name="CENTRAL-CONFIG-SERVER"
   URL="http://icvr5a05.tivlab.raleigh.ibm.com/" 
   User="itmuser"
   Password="{AES256:keyfile:a}vHBiEqmmvylNPs90Dw1AhQ==" />
  <ConfigFile  
   Server="CENTRAL-CONFIG-SERVER"  
   Name="cnfglist.xml"
   Path="common"
   Disp="CNFGLIST"
   Activate="YES" /> 
  <ConfigFile  
   Server="CENTRAL-CONFIG-SERVER"  
   Name="@PRODUCT@_situations.xml"
   Path="@PRODUCT@"
   Disp="PVTSIT"
   Activate="YES" /> 
  <ConfigFile  
   Server="CENTRAL-CONFIG-SERVER"  
   Name="@PRODUCT@_trapcnfg.xml"
   Path="@PRODUCT@"
   Disp="TRAPCNFG"
   Activate="RESTART" />
</ConfigurationArtifact>
Other keywords can be used to create the granularity required for each agent to get the correct files.
Web server as the central configuration server
Tivoli monitoring agents can use existing web servers to collect configuration files. You can use any web server that the agents can access with HTTP or HTTPS as a central configuration server.
To use a web server, create a user ID that has permission to access the files on the central configuration server and reference those credentials in the configuration load list. The URL specification is slightly different than when the central configuration server is a monitoring agent, but that is the only difference in the configuration load list. The ConfigServer element looks like this:
<ConfigServer  
   Name="CENTRAL-CONFIG-SERVER" 
   URL="http://webserver.domain.com/" 
   User="itmuser"
   Password="{AES256:keyfile:a}vHBiEqmmvylNPs90Dw1AhQ==" />
Monitor agent as the central configuration server

All monitoring agents (enterprise or system monitor) that run on Windows, Linux and UNIX platforms contain an HTTP-based Service Interface that can be used as a central configuration server. Monitoring agents on z/OS and i5 do not provide an HTTP Service interface, so cannot be used as central configuration servers.
The advantage of using a monitoring agent as the central configuration server rather than a web server, is that you do not need to maintain a web server and you can use several agents to form a set of cascading central configuration server to provide some workload balancing.
User access to the central configuration server

Access to an agent's Service Interface is controlled using its Access Authorization Group Profile (AAGP). The ability to request or place files on an agent requires more security rights than viewing metrics or historical data. By default, any valid ID on the host computer where the agent is running can access the Agent Service Interface. Those users can view metrics, situations, and historical data collected by the agent. However, the default behavior gives only the Administrative ID on the host the permission to access central configuration files through the agent's Service Interface.

The following user IDs are default members of the Administrative group on the platform where the agent is running:

Administrator

root

ITMUSER

QSECOFR
You can create configuration load lists and use the Administrative credentials to connect to the monitoring agent that is acting as the central configuration server. The ID does not have to exist on the client agents for them to connect to the central configuration server.

On Windows systems, the agent automatically discovers all user accounts belonging to the AAGP Administrators group; the agent adds those accounts to the AAGP Administrative group at startup. On UNIX and Linux systems, the agent automatically discovers all user IDs having root (superuser) authority; the agent adds them to AAGP Administrative group at startup. (Userid QSECOFR on IBM i and ITMUSER on z/OS remain unchanged at this time.) As results:

Customers do not need to create special user account to use agent services.

Administrator/root ID exposure is avoided.

Any authorized account on a system automatically gains access to privileged agent services such as file access, AAGP customization, and so on.

Although user IDs can be stored in encrypted format, in most cases you want to define a user ID on the system that will be hosting the central configuration server and add that user to the agent's AAGP.
The following example gives the steps for creating a user on the Linux OS agent and granting administrative access to the central configuration server there:
Create the user on the system: The user named "itmuser" is created on the Linux operating system and the Linux OS agent (lz) is the central configuration server.
Create an AAGP.xml file in the install_dir/localconfig directory that adds the new ID to the Administrative group:
<AAGP>
  <AAUSER>
    <ID>itmuser</ID>
    <ASSIGN>AD</ASSIGN>
  </AAUSER>
</AAGP>
The default local configuration directory can be changed with the IRA_SERVICE_INTERFACE_CONFIG_HOME environment variable.
Tip: Consider having each agent collect an AAGP file so that you can contact the agent directly through its Agent Service Interface to perform configuration actions with a non-root ID. By connecting directly to an agent's Service Interface with AD permission, you can provide credentials to connect to a new central configuration server, put or get files, or force immediate refreshes of configuration files.
On the monitoring agent that functions as the central configuration server, edit the configuration load list to add a DISP="AAGP" ConfigFile entry to load the AAGP XML file. This load list must use credentials ( root; Administrator) to connect to itself to add the new user ID to the AAGP. The edited configuration load list looks like this:
<ConfigurationArtifact>
   <ConfigServer
    Name="CENTRAL-CONFIG-SERVER"
    URL="http://linuxhost:1920///linuxhost_lz/linuxhost_lz/"
    User="root"
    Password="{AES256:keyfile:a}vHBiEqmmvylNPs90Dw1AhQ==" />
   <ConfigFile
    Server="CENTRAL-CONFIG-SERVER"
    Name="AAGP.xml"
    Path="/"
    Disp="AAGP" />
</ConfigurationArtifact>
Save the load list in install_dir/localconfig/lz/lz_cnfglist.xml. This directory is the default location on Linux systems and can be changed with the IRA_SERVICE_INTERFACE_CONFIG_LOADLIST environment variable.

Start the Linux OS agent.
All of the central configuration clients that connect to this central configuration server can now use the credentials for "itmuser" rather than "root".
  <ConfigServer
    Name="CENTRAL-CONFIG-SERVER"
    URL="http://linuxhost:1920///linuxhost_lz/linuxhost_lz/"
    User="itmuser"
    Password="{AES256:keyfile:a}vHBiEqmmvylNPs90Dw1AhQ==" />
Cascading central configuration servers

Other monitoring agents can collect an Access Authorization Group Profile (AAGP) update from a central configuration server and then be used to distribute files to other agents.

Cascading servers must be configured so that they distribute configuration load lists that specify their Agent Service Interface for the ConfigServer element's URL.

Cascading servers use the DISP=CUSTOM ConfigFile elements to download the content that they distribute to other agents.
Agent service interface
The Service Interface for an agent can be used to enter and process configuration load list requests on demand. See Agent Service Interface request - Configuration control.

Parent topic:
Centralized Configuration

+
Search Tips | Advanced Search