Supporting Configuration Management

2 Supporting Configuration Management

This chapter explains how to use the Oracle Communications IP Service Activator Software Development Kit (SDK) to include support for Oracle Communications Configuration Management in base and service cartridges. With support enabled, devices connected to IP Service Activator through the network processor have access to certain facilities in the Configuration Management module.

Note:

For details about installing the SDK and the required third party tools, plus a detailed overview of all SDK concepts, a discussion of cartridge components, and an explanation of how cartridges integrate with the network processor, see IP Service Activator SDK Developer Overview Guide and IP Service Activator SDK Installation and Setup Guide.

Table 2-1 lists the directory placeholders used in this guide.

Table 2-1 Directory Placeholders

Placeholder	Description
SDK_home	The directory in which the SDK is installed.
Service_Activator_home	The directory to which IP Service Activator is deployed. Typically C:Program Files\Oracle Communications\IP Service Activator

This guide assumes:

That the required versions of additional third party tools to support the SDK are installed correctly.
That you have set up the required environment variables to support the SDK functions.

For details about installing the SDK and the third party tool versions, refer to IP Service Activator SDK Installation and Setup Guide.

Additional Procedures and References

Key components from the SDK and concepts from their documentation are required in order to configure support for Configuration Management.

Configuration Management Integration

The following services provided by Configuration Management can be supported in the network processor through various SDK components:

Audit: supported through base and service cartridges
Configuration activation: supported from configuration policies through service cartridges in conjunction with a base cartridge.
Restore: can be implemented in base cartridges

Audit

Configuration Management's audit services let you identify configuration changes between the archive version and the running configuration. Basic audit support is pre-configured in the base cartridge source files generated by the SDK.

When you create a skeleton set of base cartridge source files, ...\audit\auditTemplate.xml is automatically created for you. It contains the basic commands needed to support Configuration Management audit services.

The audit template is integrated into the base cartridge through the Registry.xml file.

An example section of the Registry.xml file follows:

<audit>
  <auditTemplate>
    <auditTemplateEntry>
      <auditTemplateFile>com/metasolv/service activator/cartridges/cisco/audit/auditTemplate.xml</auditTemplateFile>
      <appliesTo>
        <deviceTypes useRegex="true">Cisco.*</deviceTypes>
        <osVersions useRegex="true">.*</osVersions>
      </appliesTo>
    </auditTemplateEntry>                
  </auditTemplate>
</audit>

Supporting Audit for New Commands

If you add additional services through customized service cartridges, audit support for the new commands can be implemented through the audit\auditTemplate.xml template in the service cartridge source.

Refer to the generated base cartridge auditTemplate.xml template file for examples of how to support commands.

The auditTemplate.xml file is registered with the service cartridge in the Extensions.xml file. This is pre-configured when the service cartridge source is generated by the SDK skeleton generator tool.

For more details on Audit services, refer to IP Service Activator SDK Developer Overview Guide, IP Service Activator SDK Base Cartridge Developer Guide, and IP Service Activator System Administrator's Guide.

Configuration Activation

Support for Configuration Activation exists in base cartridges. Using this facility, you can efficiently send small, specific configuration commands to devices directly through the network processor. Configuration Activation commands are sourced in this "special" configuration policy (configlet) and passed through IP Service Activator to the network processor for configuration on the device.

Configuration Restoration

To support the restoration of an archived configuration to a device through Configuration Management, you will need to create a restore template and register it with your base cartridge.

When you create your restore template, it should be integrated into the base cartridge source. A sample restore template file is created when you generate the sample cisco base cartridge. It is located in

SDK_home\baseCartridges\cisco\src\...\cisco\transforms\restoreTemplate.xml

This restore template file contains commands to perform the restore actions required by Configuration Management.

The restore template is integrated into the base cartridge through the Registry.xml file.

An example section of the Registry.xml file follows:

<restore>  <restoreTemplate>    <restoreTemplateEntry>      <restoreTemplateFile>com/metasolv/serviceactivator/ cartridges/cisco/transforms/restoreTemplate.xml</restoreTemplateFile>      <appliesTo>        <deviceTypes useRegex="true">Cisco.*</deviceTypes>        <osVersions useRegex="true">.*</osVersions>      </appliesTo>    </restoreTemplateEntry>                  </restoreTemplate></restore>

An example restore template follows:

<?xml version="1.0" encoding="UTF-8"?>
<commandSession xmlns="http://www.metasolv.com/serviceactivator/climodel" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.metasolv.com/serviceactivator/climodel     file:../../../../networkprocessor/climodel/cliModel.xsd">
  <command>
  <!-- commands to restore configuration -->
  <commandString/>
  <command>
    <commandString>terminal length 0</commandString>
  </command>
  <command kind="restore">
    <commandString>copy tftp startup-config</commandString>
    <conditionalPrompt>.*Address or name of remote host.*</conditionalPrompt>
    <conditionalCommand>
      <commandString>TFTPIP</commandString>
      <conditionalPrompt>.*Source filename.*</conditionalPrompt>
      <conditionalCommand>
          <commandString>RESTOREFILE</commandString>
          <conditionalPrompt>.*Destination filename.*</conditionalPrompt>
          <conditionalCommand>
            <commandString>startup-config</commandString>
          </conditionalCommand>
          <timeoutSeconds>600</timeoutSeconds>
        </conditionalCommand>
        <timeoutSeconds>600</timeoutSeconds>
      </conditionalCommand>
    <timeoutSeconds>1000</timeoutSeconds>
    </command>
    <command>
      <commandString>reload</commandString>
      <conditionalPrompt>.*Proceed with reload.*</conditionalPrompt>
      <conditionalCommand>
      <commandString>y</commandString>
      </conditionalCommand>
    </command>
  </command>     
</commandSession>

Change Tracking

To support change tracking for Cisco IOS devices, use the service cartridge cisco syslog.

For other vendors, create a service cartridge based on the cisco syslog example. Refer to IP Service Activator SDK Service Cartridge Developer Guide for details about creating service cartridges.

Receiving CM Events Through JMS

Events are published in the Java Message Service (JMS) topic (oracle/communications/activation/configurationmanagement/SubscriptionManagementTopic), and they are available to any subscribed client. The client first subscribes to the JMS topic by creating a topic connection and opening a session with the topic. One connection can have more than one topic session with each session having durable or non-durable subscriber. Once a third party application establishes a subscription, it listens to the topic for any published event.

The following are four types of Events generated through the Configuration Management Engine:

AllChangeEvent: every time there is a change on the device(s)
ManualChangeEvent: every time there is a manual change on the device(s)
AutomatedChangeEvent: every time there is an automated (IPSA or CM) change on the device(s)
DiscrepancyChangesEvent: after an archive, a comparison is made to see if there is a discrepancy (missing configuration). If yes, an event is generated. An event per broken service is generated.

Events contain the following data:

Event Type
Device Id
Device Name,
Device IP Address
Device Path
Command issued
Raw Syslog Message
UserName
User IP Address

Discrepancy Event contains the following information:

Service Name
Service Type
Command Document
Concrete Id
Device Type
Network Name
Interface Name
CustomerName
Syslog messages (which were sent between the two archives that could have lead to this discrepancy)