EMC Smarts Network Configuration Manager Device Services ......document. Purpose This document...

EMC® Smarts®

Network Configuration Manager Device Services Support (DSr)Version 14.0

Configuration GuideP/N 300-014-742REV 01

EMC Smarts Network Configuration Manager Device Services Support (DSr) Configuration Guide2

Copyright © 2009 - 2012 EMC Corporation. All rights reserved. Published in the USA.

Published November, 2012

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

The information in this publication is provided as is. EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

EMC2, EMC, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the United States and other countries. All other trademarks used herein are the property of their respective owners.

For the most up-to-date regulatory document for your product line, go to EMC Online Support (https://support.emc.com).

http://support.emc.com

CONTENTS

Preface

Chapter 1 Introduction

About this Manual ........................................................................................ 8 Compatibility ................................................................................................ 8

Chapter 2 Device Management and Customization

Types of Customization ............................................................................... 10

Chapter 3 Implementing and Preserving Customizations

Overview..................................................................................................... 12 Using the [Product directory]/custompackage directory............................... 12 Additional Information ................................................................................ 14

Chapter 4 Customizing Device Prompts

Introduction................................................................................................ 16 Device Drivers XML Prompt Support ............................................................ 17

Change Prompt Example ....................................................................... 17

Chapter 5 Customizing Event SYSLOG and TRAP Filtering

Introduction................................................................................................ 20 Usage ......................................................................................................... 20 Explanation of XML Elements and Detailed Usage ....................................... 20 Additional Information ................................................................................ 21

Chapter 6 Changing the Syslog Message Parsing

Editing syslog.xml ....................................................................................... 24

Chapter 7 Use Cases: Using the custompackage Folder/Directory

Case 1: Make Changes to the Driver File in .dasl or .inc(Implementation Only) ................................................................................. 26 Case 2: Make Changes to the Driver File .dasl or .inc (Interface Change) ...... 26 Case 3: SEARCHORDER=2 ........................................................................... 27 Case 4: Application interface Changes......................................................... 27

Chapter 8 Adding a product model

Overview..................................................................................................... 30 Adding new product models to Network Configuration Manager .................. 30

Appendix A Device Server Configuration

Important Notes.......................................................................................... 32 CiscoPIXFirewallSysLog.xml......................................................................... 32

EMC Smarts Network Configuration Manager Device Services Support (DSr) Configuration Guide 3

Contents

CiscoPIXFirewallTrap.xml ............................................................................. 33 Additional examples for XMLs ..................................................................... 33

Glossary

Index

4 EMC Smarts Network Configuration Manager Device Services Support (DSr) Configuration Guide

PREFACE

As part of an effort to improve its product lines, EMC periodically releases revisions of its software and hardware. Therefore, some functions described in this document might not be supported by all versions of the software or hardware currently in use. The product release notes provide the most up-to-date information on product features.

Contact your EMC technical support professional if a product does not function properly or does not function as described in this document.

Note: This document was accurate at publication time. Go to EMC Online Support (https://support.emc.com) to ensure that you are using the latest version of this document.

PurposeThis document describes how to configure and use EMC Smarts Network Configuration Manager Device Services Support (DSr).

AudienceThis document is part of the EMC Smarts Network Configuration Manager documentation set, and is intended for use by those individuals who have the responsibility of installing and deploying EMC Smarts Network Configuration Manager 9.1.

Readers of this document are expected to be familiar with the following topics:

◆ Windows® , Solaris, and Linux® operating system

◆ Database architecture and concepts

◆ Security management

◆ Internet protocols, including HTTP, TCP/IP, File Transfer Protocol (FTP), and Telnet

◆ Lightweight Directory Access Protocol (LDAP) and directory services

◆ Authentication and authorization.

Related documentationThe following EMC publications provide additional information:

◆ EMC Smarts Network Configuration Manager Device Services Support (DSr) Release Notes

◆ EMC Smarts Network Configuration Manager Device Services Support (DSr) Support Matrix

Conventions used in this documentEMC uses the following conventions for special notices:

NOTICE is used to address practices not related to personal injury.

Preface 5


Preface

Note: A note presents information that is important, but not hazard-related.

IMPORTANT

An important notice contains information essential to software or hardware operation.

Typographical conventions

EMC uses the following type style conventions in this document:

Where to get helpEMC support, product, and licensing information can be obtained as follows:

Product information — For documentation, release notes, software updates, or information about EMC products, go to EMC Online Support at:

https://support.emc.com

Technical support — Go to EMC Online Support and click Service Center. You will see several options for contacting EMC Technical Support. Note that to open a service request, you must have a valid support agreement. Contact your EMC sales representative for details about obtaining a valid support agreement or with questions about your account.

Your commentsYour suggestions will help us continue to improve the accuracy, organization, and overall quality of the user publications. Send your opinions of this document to:

[email protected]

Bold Use for names of interface elements, such as names of windows, dialog boxes, buttons, fields, tab names, key names, and menu paths (what the user specifically selects or clicks)

Italic Use for full titles of publications referenced in text

Monospace Use for:• System output, such as an error message or script• System code• Pathnames, filenames, prompts, and syntax• Commands and options

Monospace italic Use for variables.

Monospace bold Use for user input.

[ ] Square brackets enclose optional values

| Vertical bar indicates alternate selections — the bar means “or”

{ } Braces enclose content that the user must specify, such as x or y or z

... Ellipses indicate nonessential information omitted from the example



CHAPTER 1Introduction

This chapter presents these topics:

◆ About this Manual .................................................................................................... 8◆ Compatibility ............................................................................................................ 8

Introduction 7

Introduction

About this ManualThe following information is included in this Device Server User Guide document:

◆ Device Management Information

◆ Customization Information for the following:

• Device Prompts

• Event Filtering

◆ Use Cases for the Custom Package Directory

◆ Device Server Configuration Information

CompatibilityThis release is certified to work with EMC Smarts Network Configuration Manager Release 9.1, on the following environments:

◆ Red Hat Enterprise Linux 5.8

◆ Red Hat Enterprise Linux 6.x

◆ Microsoft Windows Server 2008 R2

◆ Solaris 10


CHAPTER 2Device Management and Customization

This chapter presents this topic:

◆ Types of Customization ........................................................................................... 10

Device Management and Customization 9

Device Management and Customization

Types of CustomizationOn occasion, customers may require customizations to their device server implementation to properly interact with their network environment. There are three types of customizations supported in the product today. The most common customizations include:

◆ Changing the prompts that a device driver should use when logging into a device.

◆ Updating the traps and syslog events that the device driver should recognize from a specific device type.

◆ Advanced users and professional services organizations can also modify existing drivers or create new device support using the DASL script language. The EMC Smarts Network Configuration Manager Device Access Scripting Language (DASL) Specifications Guide contains additional information on the DASL language specification.


CHAPTER 3Implementing and Preserving Customizations


◆ Overview................................................................................................................. 12◆ Using the [Product directory]/custompackage directory........................................... 12◆ Additional Information ............................................................................................ 14

Implementing and Preserving Customizations 11

Implementing and Preserving Customizations

OverviewThis section includes the steps required to implement and preserve existing customizations, as well as describing the process for changing prompts and the events recognized.

This information is also available in the install under [Product directory]/package/customizationREADME.txt.

◆ The device server architecture allows local customizations to device drivers and control/data files in a directory separate from the distribution directory. This enables customers to create modified versions of these files without altering the files distributed with the product.

◆ By creating copies of the distributed files and making modifications to the copies, customers are insulated from the possibility of having their customizations overwritten during the application of maintenance, or in future product releases.

◆ This feature is provided using a custompackage directory, which can be searched prior to the device driver package directory distributed with the software. Device drivers or control files found in the custompackage directory are used; if they are absent, the system defaults to using the files from the device driver package directory distributed with the software.

Officially released hotfixes, and other driver components will always be installed in the package directory, and not in the custompackage directory.

Using the [Product directory]/custompackage directory

Ensure you do not make any changes to the package Directory ([Product directory]/package), or to any of the package directory contents, other than the permissible changes described in this document.

The following steps are used to access and use the custompackage Directory.

1. To create a modified version of a file distributed in the package directory, create a copy of the file in the custompackage directory ([Product directory]/custompackage), setting up the same directory structure as under the package directory.

2. Make the necessary modifications to that file. Use the following steps for this procedure:

a. Identify the directory structure under the package directory containing the file that is to be modified. For example: [Product directory]/package/cisco/catos

b. Create the exact same directory structure under the custompackage directory. For example: mkdir –p [Product directory]/custompackage/cisco/catos



c. Copy the file to be modified from the directory structure under the package directory, to the directory structure under the custompackage directory. For example: cp [Product directory]/package/cisco/catos/devCiscoCat.dasl

d. [Product directory]/custompackage/cisco/catos/devCiscoCat.dasl

3. You can now make the needed changes to the file under the custompackage directory. For example: vi [Product directory]/custompackage/cisco/catos/devCiscoCat.dasl

4. Restart the device server services. If there are multiple device servers, make the same changes individually, on all device servers; meaning the same steps must be repeated on each device server.

5. If you are changing any of the following files, a restart the ControlDaemon.

The following must be changed on the Application Server.

• DevicePackageSupport.xml

• Any of the .pkg files in the custompackage/pkgxml directory

• For Example: service controldaemon restart (UNIX)

• For Example: restart from the services panel on Windows (GUI)

With this release, the addev.order changes are supported only in the package directory, as such, this file is not supported from the custompackage, and must be modified (if needed) in its original package directory location.

6. SEARCHORDER : By default, the software will look for the driver control/data files in the custompackage first, then look in the package directory second. It is possible (although not recommended), to alter the search order to ignore either the custompackage directory or the package directory altogether. This is accomplished by modifying the PACKAGEDIR_SEARCHORDER value in the infrastructures database.

Permissible values for PACKAGEDIR_SEARCHORDER are listed in the following three steps.

7. Value = 1: search custompackage directory first, then package directory. This is the default, and if the PACKAGEDIR_SEARCHORDER value is not present, the system will use this value to control the directory search selection.

8. Value = 2: Ignore the custompackage directory, and use only the package directory to locate drivers and control/data files.

9. Value = 3: Ignore the package directory, and use only the custompackage directory to locate drivers and control/data files.

10. To alter the setting of the PACKAGEDIR_SEARCHORDER, use the following procedure on the application server. This SEARCHORDER change propagates to all device servers.

11. Stop all daemons and services on application servers, and device servers, and complete the steps below on the application server.

• Store the cflist to a text file that can be edited. For Example:

. /etc/voyence.confcd [Product directory]/cgi-bin. /cflist.cgi > out.txt

Using the [Product directory]/custompackage directory 13


• Edit the contents of the resulting file, replacing the value for PACKAGEDIR_SEARCHORDER to create the desired system behavior. If PACKAGEDIR_SEARCHORDER is omitted (or removed), the system behaves as if it were set to 1 (the default value). Note that the value set for PACKAGEDIR_SEARCHORDER must be in quotes. For Example:

• HEAD RTypeList= PollTypeList= UserList= DispositionList= DeliveryList= UrlList= PolList=1000 NetList=999: PACKAGEDIR_SEARCHORDER=”1”

• Rewrite the cflist using the new values from the edited file. For Example: ./cfwrite.cgi <out.txt

12. Restart the Application and Device Server Services on all the servers.

Additional Information◆ Stop all daemons and services before making any changes to the search order, and do

not restart the daemons and services until after the changes have been made.

◆ For the Application Server Interface changes (for example, for controldaemon), only the CUSTOMPACKAGEFIRST (value 1) is supported in this release.

◆ All supported drivers and control/data files will be present in the package directory. Entries in custompackage directory are assumed to be modified, and are not supported.

It is the responsibility of the person completing the customization to ensure that the customized code is correct and adheres to the DASL compliance rules.


CHAPTER 4Customizing Device Prompts


◆ Introduction............................................................................................................ 16◆ Device Drivers XML Prompt Support ........................................................................ 17

Customizing Device Prompts 15

Customizing Device Prompts

IntroductionThe device prompts that a driver can expect to encounter on accessing a device can be configured without modifications to the device driver. These modifications are made by copying the associated xml file into the custompackage directory, as described in the previous section.

The device prompts are organized in a strict three-level hierarchy:

1. Global Prompts

Default prompt regular expressions shared by all DASL Drivers. These are the standard prompts with the default prompt regular expressions values (such as, stdEnablePromptState). These prompt regular expressions are used if they are not explicitly overridden.

2. Device Class Prompts

Overrides of the standard prompts with device class (such as, Cisco IOS Router) specific values. Also, new device class specific prompts can be defined in these files. These overrides are used for all devices of the device class (for example, all Cisco IOS Routers).

3. IDX Prompts

Overrides of the standard prompts for a specific device (such as, Nortel Router with IDX 1432). Also, device class specific prompts can be overridden in these files.

The prompt xml files are used by DASL each time the Network Configuration Manager Logs into a device.

1. First, the Global prompts xml file is read, and all of the standard prompts are initialized with the regular expressions in this file.

2. Next, the Device Class prompts xml file is read (if it exists), and all of the prompts listed in it are initialized.

3. Finally, if a Device Class prompts file exists and an IDX prompts xml file is present, all of the prompts listed are initialized. All prompt files are deployed into a subdirectory in the package/pkgxml directory of the Network Configuration Manager Installation directory. Prompt file changes should be placed in the corresponding custompackage directory.

“Case 2: Make Changes to the Driver File .dasl or .inc (Interface Change)” on page 26 provides more information on custompackage directory.



Device Drivers XML Prompt Support

Change Prompt Example

The following is an example for changing a prompt.

As an example, consider a network where the prompt has been changed to LABNET on some of the Cisco Routers. Shown below is the default Device Class Prompts file for Cisco IOS Routers.

<Prompts Version="1.0"> <CiscoIOSRouter> <EnablePromptState> <ID>1001</ID> <Expr><![CDATA[[-A-Za-z0-9_!@$%^&+|~]+# *$]]></Expr> </EnablePromptState> <DisablePromptState> <ID>1002</ID> <Expr><![CDATA[> *$]]></Expr> </DisablePromptState>

<ConfigPromptState> <ID>1003</ID> <Expr><![CDATA[[$].*[$] *# *$]]></Expr> </ConfigPromptState>

<LoginPromptState> <ID>1004</ID> <Expr><![CDATA[ogin:|sername ?:|[Ii][Dd]:]]></Expr> </LoginPromptState>

<PasswordPromptState> <ID>1005</ID><ciscoInvalidInputState> <ID>10003</ID> <Expr><![CDATA[Invalid input|^%|[Dd]uplicate|Bad mask]]></Expr> </ciscoInvalidInputState>

<ciscoBannerPromptState> <ID>10007</ID> <Expr><![CDATA[Enter TEXT message.]]></Expr> </ciscoBannerPromptState>

<ciscoMenuPromptState> <ID>10010</ID> <Expr><![CDATA[User Interface Menu]]></Expr> </ciscoMenuPromptState> </CiscoIOSRouter></Prompts>

To add LABNET as a valid prompt the <Expr> element of both the EnablePromptState and DisablePromptState elements in the file package/pkgxml/CiscoIOSRouter/CiscoIOSRouterPrompts.xml, (relative to the Network Configuration Manager installation directory) must be modified to include LABNET

The elements should be changed to the following:

<Expr><![CDATA[[-A-Za-z0-9_!@$%^&+|~]+# *$|LABNET]]></Expr>

and

<Expr><![CDATA[> *$|LABNET]]></Expr>

Device Drivers XML Prompt Support 17

CHAPTER 5Customizing Event SYSLOG and TRAP Filtering


◆ Introduction............................................................................................................ 20◆ Usage ..................................................................................................................... 20◆ Explanation of XML Elements and Detailed Usage ................................................... 20◆ Additional Information ............................................................................................ 21

Customizing Event SYSLOG and TRAP Filtering 19

Customizing Event SYSLOG and TRAP Filtering

IntroductionPreviously, the Network Configuration Manager introduced xml Configuration files for event filtering and recognition of config change events. These xml files can be edited and customized to fit the requirements of both the customer’s environment and devices.

UsageThese files are present in relevant class directory under the [Product directory]/package/pkgxml/ directory.

For example, the CiscoIOSRouterTrap.xmp file is located in the /opt/smarts-ncm/package/pkgxml/CiscoIOSRouter/ directory.

1. If a change to a file is needed, you can create a similar directory structure under the [Product directory]/custompackage/pkgxml/ directory and copy the file to the new directory.For example, copy the new file to the /opt/smarts-ncm/custompackage/pkgxml/CiscoIOSRouter/CiscoIOSRouterTrap.xml directory and edit the copied file. See the “Case 2: Make Changes to the Driver File .dasl or .inc (Interface Change)” for more information.

2. Restart the Device Server Services.

3. The XML configuration file can be disabled by setting the <IsActive> value to false. In this case, fallback occurs to DASL scripts -> deviceEvent function.

This is recommended in cases of complex event parsing not available through xml-like complex ANDing logic of regular expressions.

4. By default, all xml configurations except NetScreen Syslogs are enabled at installation.

5. New driver event files can be placed into the [Product directory]/custompackage/event/ directory as needed. See the “Case 2: Make Changes to the Driver File .dasl or .inc (Interface Change)” for more information.

Explanation of XML Elements and Detailed UsageThere are two xml Event files per driver; one file each for syslogs and SNMP traps. See the examples shown in “Device Server Configuration” on page 31. The format and description of the data is as follows.

◆ The trapConfig xml has a <TrapConfig> root element, while the syslog Config xml has a <SysConfig> root element.

◆ Each xml has exactly one <Package> sub element.



◆ Within the <Package> there contains:

• A valid <PackageID> sub element providing the driverNumber must be present.

• The <IsActive> element value “true” or “TRUE” indicates if this package information must be used or ignored.

• Multiple <Event> elements can be provided within each package element. At least one sub element <EVENT > is required.

– One <MatchString> sub element value is used to match relevant events. Note a “.*” matches all messages, while an empty value ignores all messages.

– One <NegativeMatchString> sub element value indicates that if this match occurs, ignore the event.

– One <PullConfig> value of 1 indicates to setup a configuration pull if a match successfully occurred with a message, or a simple match to read changes by data, or for additional purposes in the future.

– Any number of <ChangedBy> regular expressions is matched to extract the username, if present in the message.

Additional InformationYou can disable the use of an xml-based event configuration by setting the <IsActive> element value to false.

◆ If the package configuration for a device class is not present, or if the <IsActive> is set to false, the Network Configuration Manager fallbacks to the old mechanism of letting the driver identify config change events. This may hamper performance, but would enable complex message parsing that can be completed more easily in DASL.

◆ The syslog event xml must be named. *SysLog.*, and the trap event xml must be named .*Trap.*

◆ All xmls are objectified in memory by commmgr.

◆ Some device syslog xmls, such as for NetScreen, have %% run parameters that users need to change, and set the xml IsActive to true. “Device Server Configuration” on page 31 provides more information.

Additional Information 21

CHAPTER 6Changing the Syslog Message Parsing

This chapter presents this topic:

◆ Editing syslog.xml ................................................................................................... 24

Changing the Syslog Message Parsing 23

Changing the Syslog Message Parsing

Editing syslog.xmlThe Syslog message parsing in the Network Configuration Manager can be changed so it parses a new or different Syslog message format. In the Network Configuration Manager, the Syslog message formats are externalized in the XML file [Product directory]/syslog.xml.

The format of the syslog.xml content is as follows:

<SysLog> <SysLogFormats> <SysLogFormat> <MatchString>[Place regular expression here]</MatchString> <Group>1</Group> </SysLogFormat> </SysLogFormats></SysLog>

◆ Multiple SysLogFormat elements can be added.

◆ Each SysLogFormat element can have one MatchString element, but multiple Group Elements. The NCM_CommMgr daemon uses the match strings and group to perform a regular expression search, and uses the results to locate known devices as the source of the Syslog message.

◆ Any change to the syslog.xml file requires a restart of NCM_CommMgr. This can be done by restarting the voyence daemon on Red Hat Enterprise Linux 5.8 or 6.x, or Solaris 10, or restarting the NCM_CommMgr service on Windows Server 2008.

If no known device is found using the above steps, the algorithm falls back, and uses the standard message format for parsing.


CHAPTER 7Use Cases: Using the custompackage Folder/Directory


◆ Case 1: Make Changes to the Driver File in .dasl or .inc (Implementation Only) ........ 26◆ Case 2: Make Changes to the Driver File .dasl or .inc (Interface Change) .................. 26◆ Case 3: SEARCHORDER=2 ....................................................................................... 27◆ Case 4: Application interface Changes..................................................................... 27

Use Cases: Using the custompackage Folder/Directory 25

Use Cases: Using the custompackage Folder/Directory

Case 1: Make Changes to the Driver File in .dasl or .inc (Implementation Only)

1. Make Changes to driver file .dasl or .inc (only Implementation change), based on SEARCHORDER 1. For example, if you want to change cisco/ios/stdfuncs.inc.

2. If [Product directory]/custompackage/cisco/ios directory is not present, you must create this directory. If the cisco/ios/stdfuncs.inc was already present in the custompackage, modify the file.

3. If not already present,

4. copy [Product directory]/package/cisco/ios/stdfuncs.inc to [Product directory]/custompackage/cisco/ios/stdfuncs.inc. If this file is present, continue with step 3.

5. Make modifications to [Product directory]/custompackage/cisco/ios/stdfuncs.inc, and then

6. Save the file.

7. Restart the device server services.

8. Test the new functionality from the application, or test, based on thechanges made.

Case 2: Make Changes to the Driver File .dasl or .inc (Interface Change)

1. Make changes to driver file .dasl or .inc (Interface Change) .SEARCHORDER 1.

2. This is similar to Use Case 1, except that if the change is being made to a function signature that requires many other caller related driver sources to change, you must ensure that all changes are appropriately made into the custompackage directory.

3. In most cases, making interface changes to functions is recommended only if needed. If changes are made, make sure to only add default parameters.

For example: termConnect(var useMechanism,var port=23,var

userPrompted=false, var cutThru=false,var uid="UndefinedUserId",var pwd=UndefinedPassword");

needs to add a new parameter to the end, as example: forward termConnect(var useMechanism,var port=23,var userPrompted=false, var cutThru=false,var uid="UndefinedUserId",var pwd="UndefinedPassword",var retryCount=5);



Case 3: SEARCHORDER=2SEARCHORDER=2 (IGNORECUSTOMPACKAGE)

◆ Refer to step 3 in “Using the [Product directory]/custompackage directory” on page 12 for instructions.

◆ With this SEARCHORDER, setting changes and files in the custompackage directory are totally ignored. This SEARCHORDER is used when a new release was just installed, and all custom changes were included in the new release. There is no need for custompackage changes when you installed a new release, and all custom changes are included in the new release.

This has the same impact as completely deleting the custompackage directory contents.

Case 4: Application interface Changes◆ These changes include changes to the .pkg files, and other xmls that contain

Application Server/Device Server interface information.

◆ For example, if OS support is added to a driver onsite to enable the same driver, the xml attribute in .pkg <OSUpgrade supported="true"> is added, and set to True.

◆ In this case, this .pkg must be placed under the custompackage/pkgxml directory on the Application Server, and the controldaemon service must then be restarted.

Case 3: SEARCHORDER=2 27

CHAPTER 8Adding a product model


◆ Overview................................................................................................................. 30◆ Adding new product models to Network Configuration Manager .............................. 30

Adding a product model 29

Adding a product model

OverviewWhen the Network Configuration Manager device driver development creates a driver based on a customer request, the driver is developed against the requested device (given OID) and not the family that the device belongs to.

However, the driver can be modified in the field to expand the support for the driver to other products in the family. The base assumption to be able to do this is that the operating system, command line instructions and so on, of the devices are the same. But it may be a form factor that differs, such as 12, 24, 48-port versions of the product. Where it is a form factor difference, the driver can be easily updated in the field to support the new model of a certified/supported family of products.

Adding new product models to Network Configuration ManagerNew product models of the same family can be added into Network Configuration Manager by adding the model name in the .model file. If Network Configuration Manager needs to manage a new product model that belongs to the same operating system class, same commands and same output of the commands as of any other supported model, that product model can be added to Network Configuration Manager.

The following steps use a Cisco example to add a new product model. Follow these steps to add a new product model into .model file:

1. Add the model name, sysObjectID and Device Driver ID in the .model file under the directory <[Product directory]>/custompackage/<Vendor>/.

For example, add the below entries in Cisco.models file under the directory <[Product directory]>/custompackage/<Cisco/

• Model: Nexus 5596

• sysObjectID: 12.3.1.3.1.038

• Driver ID: 1460

2. Run the the script mkmodelsxml.pl from the directory <[Product directory]>/tools/ to generate models xml file. For example,

<[Product directory]>/tools/mkmodelsxml.pl < Cisco.models > CiscoModels.xml

3. Place the Models.xml file under <[Product directory]/custompackage/pkgxml/<Vendor>/ directory. For example,

<[Product directory]/custompackage/pkgxml/Cisco/

4. Restart the Network Configuration Manager service using the command:

service NCM restart

5. Discover the newly added model in Network Configuration Manager.


APPENDIX ADevice Server Configuration

This appendix presents these topics:

◆ Important Notes...................................................................................................... 32◆ CiscoPIXFirewallSysLog.xml..................................................................................... 32◆ CiscoPIXFirewallTrap.xml ......................................................................................... 33◆ Additional examples for XMLs ................................................................................. 33

Device Server Configuration 31

Device Server Configuration

Important NotesNote the following:

◆ In most cases, a single event sub element suffices, but multiple events can be provided, as shown for the pix driver.

◆ It is expected that Regular Expressions (RegEx) are used as a best practice for the following values:

<MatchString>

<NegativeMatchString>

<ChangedBy>

Caveat:

◆ To keep xmls uncomplicated, one of the limitations is that currently the ANDing of <MatchString> as a match is not provided. However, this should very rarely be needed if proper regular expressions are used. Also, fallback to DASL is available.

◆ NetScreen SysLog xml is disabled by default (fallback to dasl script occurs).

◆ Replace the %DEVICESERVERIPADDR% variable with the actual value of the Device Server IP Address, and enable by changing the value of the <IsActive> variable to true before use.

CiscoPIXFirewallSysLog.xml<SysConfig>

<Package><IsActive>true</IsActive><PackageID>10</PackageID>

<Event><MatchString>SYS-5-CONFIG</MatchString><PullConfig>1</PullConfig></Event>

<Event><MatchString>PIX-5-111005</MatchString><PullConfig>1</PullConfig></Event>

<Event><MatchString>PIX-5-111008</MatchString><ChangedBy>User '(.*)' executed the 'enable' command</ChangedBy></Event>

<Event><MatchString>ASA-5-111008:.*configure terminal.</MatchString><ChangedBy>User '(.*)' executed the 'configure terminal'

command</ChangedBy><PullConfig>1</PullConfig></Event>

<Event><MatchString>ASA-4-111008:.*configure terminal.</MatchString><ChangedBy>User '(.*)' executed the 'configure terminal'

command</ChangedBy>



<PullConfig>1</PullConfig></Event>

<Event><MatchString>FWSM-4-111008:.*configure terminal.</MatchString><ChangedBy>User '(.*)' executed the 'configure terminal'

command</ChangedBy><PullConfig>1</PullConfig></Event>

CiscoPIXFirewallTrap.xml<TrapConfig><Package><IsActive>true</IsActive><PackageID>10</PackageID><Event><MatchString>1.3.6.1.4.1.9.9.41.1.2.3.1.5.0.*configure t</MatchString><PullConfig>1</PullConfig></Event></Package></TrapConfig>

Additional examples for XMLsThis configuration is disabled. <IsActive>false</IsActive> must be enabled with the %DEVICESERVERIPADDR% substituted with devserver ip by the customer. Until then, fallback would be enabled to DASL.

<SysConfig><Package><PackageID>21</PackageID><IsActive>false</IsActive>

<Event><MatchString>system-information-00767: System configuration saved by

.* via</MatchString><ChangedBy>system-information-00767: System configuration saved by

(.*) via</ChangedBy><PullConfig>1</PullConfig></Event>

<Event><MatchString>system-warning-00515: Admin user .* has

logged</MatchString><ChangedBy>system-warning-00515: Admin user (.*) has

logged</ChangedBy><NegativeMatchString>from %DEVICESERVERIPADDR%</NegativeMatchString><PullConfig>1</PullConfig></Event>

</Package>

This matches all syslog messages for pulls

<SysConfig><Package><PackageID>100</PackageID><IsActive>true</IsActive><Event><MatchString>.*</MatchString><PullConfig>1</PullConfig>

CiscoPIXFirewallTrap.xml 33


</Event></Package>

This filters out all messages; a <MatchString> is empty.

<SysConfig><Package><PackageID>100</PackageID><IsActive>true</IsActive><Event><MatchString></MatchString><PullConfig>1</PullConfig></Event></Package></SysConfig>

This is equivalent to <IsActive>false</IsActive> as there are no events.

<SysConfig><Package><IsActive>true</IsActive><PackageID>2000</PackageID><IsActive>true</IsActive></Package>

</SysConfig>This is configured for Generic RME driver 2000. Notice the deviceName. This is used to extract the device name from the EMS message

<TrapConfig>

<Package><IsActive>true</IsActive><PackageID>2000</PackageID><Event><DeviceName>1.3.6.1.4.1.9.9.143.1.2.3.1.5.0:(.*)$</DeviceName><MatchString>1.3.6.1.4.1.9.9.143.1.2.3.1.7.0</MatchString><NegativeMatchString>User initiated archive

update</NegativeMatchString><ChangedBy>1.3.6.1.4.1.9.9.143.1.2.3.1.8.0:(.*)$</ChangedBy><PullConfig>1</PullConfig></Event>


GLOSSARY

This glossary contains terms related to disk storage subsystems. Many of these terms are used in this manual.

D

DASL Device Access Scripting Language

DSr Device Support Release

G

GUI Graphical User Interface

I

IP Internet Protocol. This is a network layer protocol in the Internet protocol suite and is encapsulated in a data link layer protocol (e.g., Ethernet).

O

OS Operating System

R

RegEx Regular Expression

RME Resource Manager Essentials (CISCO)

U

UNIX A multi-user, multitasking computer operating system

V

VPN Virtual Private Network

X

XML eXtensible Markup Language: a simplified version of SGML that can be used, esp. on the World Wide Web, to create a tagging scheme that allows elements of a document to be marked according to their content rather than their format.


Glossary


INDEX

AAbout this Manual 8Additional examples for xmls 33

CCase 1

Make Changes to the Driver File in .dasl or .inc (Implementation Only) 26

Case 2Make Changes to the Driver File .dasl or .inc (Interface

Change) 26Case 3

SEARCHORDER=2 27Case 4

Application interface Changes 27Change Prompt Example 17Changing the Syslog Message Parsing 23CiscoPIXFirewallSysLog.xml 32CiscoPIXFirewallTrap.xml 33Compatibility 8

DDevice Drivers with XML Prompt Support 17

EExplanation of XML Elements 20extract the device name from the EMS message 34

LLABNET 17

Ssyslog messages for pulls 33

UUsage 20

VVOYENCE_HOME/package/pkgxml/event/ directory. 20


Index


EMC Smarts Network Configuration Manager Device Services ......document. Purpose This document...

Documents

Transcript of EMC Smarts Network Configuration Manager Device Services ......document. Purpose This document...