User Guide for Device Fault Manager 3.1 (With LMS 3.1)
Chapter11:Administering DFM (Advanced)
Download this chapter
Chapter11:Administering DFM (Advanced)Chapter11:Administering DFM (Advanced)
Download the complete book
User Guide for Device Fault Manager 3.1 - PDF of Entire BookUser Guide for Device Fault Manager 3.1 - PDF of Entire Book (PDF - 5 MB)
give_us_feedback

Table Of Contents

Administering DFM (Advanced)

Security Considerations

File Ownership and Protection

Secure Socket Layer (SSL)

SNMPv3

Working with Firewalls

Device Support

System Administration

Registering Additional DFM Servers with the LMS Portal

Configuring Users (ACS and Non-ACS)

Configuring Users Using CiscoWorks Local Mode

Configuring Users Using ACS Mode

Using DFM in ACS Mode

Creating Self-Signed Security Certificates Yearly

Backing Up and Restoring DFM Data

Changing the Password for DFM Databases

Configuring Logging

Viewing and Maintaining Log Files

Starting and Stopping DFM Processes

Registering and Unregistering DFM Processes

Example 1: Specifying Clients that Can Connect to DFM

Example 2: Configuring the DFM Server to Use a Privileged Port


Administering DFM (Advanced)

These topics are intended for system administrators who will perform Device Fault Manager (DFM) administrative functions. The topics include:

•Security Considerations

•Device Support

•System Administration

Security Considerations

These topics address some important DFM security issues:

•File Ownership and Protection

•Secure Socket Layer (SSL)

•SNMPv3

•Working with Firewalls

File Ownership and Protection

Security for DFM files is based on the same standards used for CiscoWorks.

Caution Do not change the protection of any file or directory to be less restrictive. You may, if you wish, make the protections more restrictive.

All DFM files are installed with owner CASUSER. Only CASUSER can create, delete, or modify the files installed in NMSROOT. NMSROOT is the directory where CiscoWorks is installed on your system. If you selected the default directory during installation, on Windows it is C:\Program Files\CSCOpx. On Solaris, it is /opt/CSCOpx.

When typing the Windows default installation directory, enter C:\Progra~1\CSCOpx.

Note File protections are not enforced on FAT partitions.

Secure Socket Layer (SSL)

SSL is an application-level protocol that enables secure transactions of data through privacy, authentication, and data integrity. It relies upon certificates, public keys, and private keys. You can enable or disable SSL depending on the need to use secure access.

DFM supports SSL between clients and the server. By default, DFM is not SSL-enabled. For information on enabling SSL, see the Common Services Online help.

SNMPv3

Like CiscoWorks Common Services, DFM supports SNMPv3 (authentication and access control but no data encryption) between server and devices to eliminate leakage of confidential info. This provides packet-level security, integrity protection, and replay protection, but does not encrypt the packets.

Working with Firewalls

DFM will work across firewalls, but you must perform the following two tasks:

•Configure the DFM server to use a specific port (outgoing connection)

•Configure the firewall to use an automatic established connection (incoming connection)

Step 1 Configure the DfmServer process so it binds to a privileged port, using the pdcmd --port option (see Table 11-5 for more pdreg options):

Note The ports and protocols used by CiscoWorks are listed in the Installation and Getting Started Guide for LAN Management Solution 3.1.

a. Check the flags that are currently set for the DfmServer process, and write them down (you need to reset them later): 

# NMSROOT/bin/pdreg -l DfmServer

b. Unregister the DfmServer process: 

# NMSROOT/bin/pdcmd -u DfmServer

c. Re-register the DfmServer process with all the flags found in Step a and the following sm_server flags, as needed:

--port=port

Specifies port (for example, on a firewall) on which DfmServer will run

--privopen=protocol:port

Specifies privileged port to which DfmServer has access (for example, UDP:162) 


# NMSROOT/bin/pdcmd -r DfmServer -e NMSROOT/objects/smarts/bin/sm_server --output -n 
DFM -c icf --privopen=UDP:162 --bootstrap=DFM_bootstrap.conf --subscribe=default"

Use the following command to list all sm_server flags:

NMSROOT/objects/smarts/bin/sm_server --help

Step 2 Configure the established connection keyword in the firewall to be automatic.

For additional information on using the privopen option, see Example 2: Configuring the DFM Server to Use a Privileged Port.

Device Support

When support for new devices becomes available for DFM, minor releases will be announced on the planner page for DFM on Cisco.com. Visit the planner page for announcements, downloads, and installation instructions for these releases as they become available.

When a new minor release becomes available, you can download it from Cisco.com by going to

http://www.cisco.com/pcgi-bin/tablebuild.pl/cw2000-dfm

You will be prompted to log into Cisco.com.

System Administration

DFM system administration can be performed only by the following types of users:

•Users in a System Administrator role. These users can perform system administration tasks that can be started from the CiscoWorks desktop. These tasks include:

–Configuring users

–Backing up and restoring data

–Configuring logging

–Starting and stopping CiscoWorks processes

•Users who log in as local administrator to the system where DFM is installed. These users can view log files.

If the DFM server is using CiscoSecure Access Control Server (ACS) mode, these CiscoWorks roles are mapped to ACS roles.

Using CiscoWorks Server Hostname Change Scripts in a Windows machine (with DFM)

When you change the hostname of the CiscoWorks Server, you need to change the hostname related entries in the CiscoWorks directories and files, registry entries, and databases. Common Services provides a CLI utility to update the new hostname information in the Common Services related directories and files, registry entries, and databases, after you have changed your hostname.

You can use the hostnamechange.pl script to update the hostname changes in all files, database entries and registry entries.

After running this script in a Windows machine (with DFM), the system needs to be rebooted for DFM features to work properly.

Registering Additional DFM Servers with the LMS Portal

You can register additional DFM servers so that they appear on the LMS portal. There is no limit to the number of servers you can register, since device limits are enforced from the DFM server side.

The LMS portal is a portal for the different applications. However, you will probably want to limit your home page to two or three DFM servers. The local DFM server name is always listed first on the LMS Portal.

If you have multiple instances of DFM on your home page, you can always map a DFM instance to its Common Services instance by the server hostname (DFM@server, CS@server).

Note When you use a remote version of DFM, CiscoWorks will prompt you to reauthenticate yourself.

Step 1 Go to the LMS portal and select Common Services > Server > HomePage Admin > Application Registration.

The Application Registration Status page appears.

Step 2 Click Registration.

The Registration Location page opens.

Step 3 Activate the Import from Other Servers radio button, and click Next.

The Import Server's Attributes page opens.

Step 4 In the Import Server's Attributes page, enter the following information:

•Server Name—Host name or IP address.

•Server Display Name—A user-specified name that will be displayed on the LMS portal, and as the DFM home page title when you select that DFM instance.

•Port—1741.

Step 5 Click Next.

CiscoWorks verifies that the remote server is reachable.

When you select the new DFM server instance from the LMS portal, you will have to authenticate by entering a user name and password for the remote host.

Configuring Users (ACS and Non-ACS)

The CiscoWorks server provides the mechanism for authenticating and authorizing users for CiscoWorks applications. What users can see and do is determined by their user role.

System Administrators can configure user roles by selecting Server  >  Security > Single-Server Management > Local User Setup. From here you can add, modify, or delete users.

The CiscoWorks server provides two different mechanisms or modes for authenticating users for CiscoWorks applications:

•CiscoWorks Local Mode—By default, the CiscoWorks server uses CiscoWorks Local mode, or non-ACS mode. In CiscoWorks Local mode, CiscoWorks assigns roles, along with privileges associated with those roles, as described in the Common Services Permission Report.

You can generate a Permission Report from the LMS portal by selecting Server > Reports > Permission Report and clicking Help. For more information, see to Configuring Users Using CiscoWorks Local Mode.

•CiscoSecure Access Control Server (ACS) Mode—ACS specifies the privileges associated with roles; however, ACS also allows you to perform device-based filtering, so that users only see authorized devices.

You can use ACS only when it is installed on your network and DFM is registered with ACS. For more information, see Configuring Users Using ACS Mode.

If Common Services is using ACS mode, DFM must also use ACS mode; Otherwise, DFM users will not have any permissions. However, if another instance of DFM is already integrated with ACS, the new DFM will also be integrated with ACS.

You can also use the CiscoWorks Assistant Server Setup workflow to set the server login mode to ACS mode, as described in User Guide for CiscoWorks Assistant 1.1.

Configuring Users Using CiscoWorks Local Mode

To add a user and specify their user role using CiscoWorks Local Mode, select Server  >  Security > Single-Server Management > Local User Setup from the LMS portal. Click the Help button for information on the configuration steps.

Use the CiscoWorks Permission Report to understand how each user role relates to tasks in DFM. From the LMS portal, select Server  >  Reports > Permission Report and scroll down until you find Device Fault Manager.

Configuring Users Using ACS Mode

To use this mode for DFM, Cisco Secure ACS must be installed on your network, and DFM must be registered with ACS.

Step 1 Verify which mode the CiscoWorks server is using.

Step 2 From the LMS portal, select Server > Security > AAA Mode Setup and check what is listed in the Current Settings table.

Either CiscoWorks Local or TACACS (ACS) will be displayed.

Step 3 Verify whether DFM is registered with ACS (if ACS Mode is being used) by checking the ACS server.

To modify ACS roles:

•See the ACS online help (on the ACS server) for information on modifying roles.

•See the Common Services online help for information on the implications of ACS on the DCR (specifically, role dependencies).

Note If you modify DFM roles using ACS, your changes will be propagated to all other instances of DFM that are using Common Services servers which are registered with the same ACS server.

See the following for other information related to ACS:

•To register applications with ACS, and for information on supported ACS versions, refer to Installing and Getting Started with CiscoWorks LAN Management Solution 3.1.

•To understand CiscoSecure Groups, Users, and Command Authorization Sets, see User Guide for CiscoSecure ACS.

•For information on the implications of ACS custom roles on the DCR, see the online help for Common Services.

Using DFM in ACS Mode

Before performing any tasks that are mentioned here, you must ensure that you have successfully completed configuring Cisco Secure ACS with the CiscoWorks server. If you have installed DFM after configuring the CiscoWorks Login Module to the ACS mode, DFM users are not granted any permissions. However, the DFM application is registered to Cisco Secure ACS.

CiscoWorks login modules allow you to add new users using a source of authentication other than the native CiscoWorks server mechanism (that is, the CiscoWorks Local login module).

You can use the Cisco Secure ACS services for this purpose. You can integrate the CiscoWorks server with CiscoSecure ACS to provide improved access control using Authentication, Authorization, and Accounting.

The following topics provide information on how to use DFM in the ACS mode:

•Modifying CiscoWorks Roles and Privileges

•Device-Based Filtering

By default, the CiscoWorks server authentication scheme has six roles. They are listed here from least privileged to most privileged:

Help Desk

Users with this role have the privileges to access network status information from the persisted data. Users do not have the privilege to contact any device or schedule a job that will reach the network.

Approver

Users with this role have the privilege to approve all DFM tasks. They can also perform all the Help Desk tasks.

Network Operator

Users with this role have the privilege to perform all tasks that involve collecting data from the network. Users do not have write access on the network. Users can also perform all the Approver tasks.

Network Administrator

Users with this role have the privilege to change the network. Users can also perform Network Operator tasks.

System Administrator

Users with this role have the privilege to perform all CiscoWorks system administration tasks. See the Permission Report on the CiscoWorks server (Common Services > Server > Reports > Permission Report).

Super Admin

Users have full access rights to perform any task in CiscoWorks including administration and approval tasks.

When you integrate your CiscoWorks Server with your ACS Server, you only need to:

1. Set up an user account in ACS corresponding to the System Identity User account configured in CiscoWorks.

For example, if you have configured the System Identity User as TestUser in CiscoWorks, set up a user TestUser in ACS.

2. Assign the Super Admin role to the user configured in ACS, for all CiscoWorks applications.

With the introduction of Super Admin role, you need not create a custom role with all the privileges and assign that role to a user.

You can assign this role to users only on Cisco Secure ACS Server and only when your login module is set to ACS. This role is not available in the CiscoWorks local mode and during the local user setup on CiscoWorks Server.


Cisco Secure ACS allows you to modify the privileges to these roles. You can also create custom roles and privileges that help you customize Common Services client applications to best suit your business workflow and needs.

To modify the default CiscoWorks roles and privileges, see Modifying CiscoWorks Roles and Privileges.

To create custom roles and privileges, see the Cisco Secure ACS online help. (On Cisco Secure ACS, click Online Documentation > Shared Profile Components > Command Authorization Sets to view the help page.)

Note See the Common Services Online help for important information on how ACS custom roles affect the DCR.

Modifying CiscoWorks Roles and Privileges

If another instance of DFM is registered with the same Cisco Secure ACS, your instance of DFM will inherit those role settings.

Furthermore, any changes you make to DFM roles will be propagated to other instances of DFM through Cisco Secure ACS. If you reinstall DFM, your Cisco Secure ACS settings will automatically be applied upon DFM restart.

Step 1 Select Shared Profile Components > DFM and click on the DFM roles that you want to modify.

Step 2 Select or deselect any of the DFM tasks that suit your business workflow and needs.

Step 3 Click Submit.

Device-Based Filtering

In ACS, you can create and modify users who can perform certain tasks on certain devices. The devices listed for you are based on your roles defined in CiscoSecure ACS. See User Guide for CiscoSecure ACS for more information.

Creating Self-Signed Security Certificates Yearly

When you install DFM, DFM creates a self-signed security certificate on the server. Users on some client systems must install the certificate; see Responding to Security Alerts. Self-signed security certificates expire one year from the date of creation.

Create a new self-signed security certificate yearly, before the certificate expires. You can also do so after the certificate expires. However, users might not be able to access DFM until you complete this task.

Step 1 From the LMS portal, select Server > Security > Single-Server Management > Certificate Setup.

The Create Certificates page appears.

Step 2 Enter the values for the fields described in the following table.

Field
Description
Usage Notes

Country Name

Name of your country

Use two-character country code.

State or Province

Name of your state or province

Use two-character state or province code or complete name of state or province.

Locality

Name of your city or town

Use two-character city or town code or complete name of city or town.

Organization Name

Name of your organization

Use complete name or abbreviation for your organization.

Organization Unit Name

Name of department in your organization

Use complete name or abbreviation for your department.

Host Name

Name of server on which DFM is installed

Use the DNS name of the server.

Use the proper domain name, which should already be displayed in the Host Name field.

Email Address

Your e-mail address

—


Step 3 Click Apply.

Backing Up and Restoring DFM Data

Use the LMS portal to perform immediate backups or schedule backups of DFM data. Common Services provides a command line script that restores data, including data from previous versions of Common Services and DFM.

•For backing up data, select Server > Admin > Backup, click Help, and follow the instructions.

•For restoring data, select Server > Admin > Backup, click Help, and click the Help link to the Restoring Data topic.

If you are restoring data from DFM 1.2.x or earlier, you will see a warning message and should follow the instructions in the message.

Step 1 On the DFM 1.2.x or earlier server, run the following command on Solaris. NMSROOT is the folder where DFM is installed on the server. 

NMSROOT/objects/smarts/bin/sm_tpmgr -s DFM --dump-agents > seedfile.txt

If you selected the default directory during installation, it is C:\Program Files\CSCOpx on Windows and /opt/CSCOpx on Solaris.)

For Windows, run this command: 

NMSROOT\objects\smarts\bin\sm_tpmgr.exe -s DFM --dump-agents > seedfile.txt

Step 2 Copy seedfile.txt to a temporary location on your upgraded server.

Step 3 Use the CiscoWorks pdshow command to verify that the daemon manager is running (crmdmgtd on Windows and dmgtd on Solaris).

Step 4 Import the DFM 1.2.x or earlier information, using this command on Solaris: 

NMSROOT/bin/dfmimport fn=fullpath/seedfile.txt

Step 5 Run this command on Windows: 

NMSROOT\bin\dfmimport.exe fn=fullpath\seedfile.txt

Database files are stored using the backup directory structure described in Table 11-1.

•Format—/generation_number/suite[/directory]/filename

•Example—/1/dfm/dfmFh.db

Table 11-1 DFM Backup Directory Structure 

Option
Description
Usage Notes

generationNumber

Backup number

For example, 1, 2, and 3, with 3 being the latest database backup.

suite

Application, function, or module

When you perform a backup, data for all suites is backed up. The CiscoWorks Common Services suite is cmf. The DFM application suite is dfm.

directory

What is being stored

Suite applications (if applicable).

filename

Specific file that has been backed up

Files include database (.db), log (.log), version (DbVersion.txt), manifest (.txt), tar (.tar), and data files (datafiles.txt).

For DFM, the following files are listed directly under generationNumber/suite:

dfmEpm.db
dfmInv.db
dfmFh.db
filebackup.tar

The file backup.tar contains the following directories and files:

NMSROOT/objects/smarts/conf
NMSROOT/objects/smarts/local/repos
NMSROOT/objects/smarts/local/logs
NMSROOT/objects/smarts/local/conf
NMSROOT/setup/dfm.info
NMSROOT/objects/dps/config


Changing the Password for DFM Databases

Before You Begin

The procedure in this topic enables you to change the password for the following DFM databases. All DFM databases must use the same password.

•dfmEpm—Event promulgation

•dfmFh—Fault History

•dfmInv—Inventory

Step 1 Go the command prompt on the DFM server and stop the daemon manager by entering the following command:

•On Windows: 

net stop crmdmgmt

•On Solaris: 

/etc/init.d/dmgtd stop

Step 2 Change directory to NMSROOT/conf/dfmDb/bin. For example, on Windows: 

cd Program Files\CSCOpx\conf\dfmDb\bin

On Solaris: 

cd /opt/CSCOpx/conf/dfmDb/bin

Note NMSROOT is the folder where DFM is installed on the server. If you selected the default directory during installation, it is C:\Program Files\CSCOpx on Windows and /opt/CSCOpx on Solaris.

Step 3 Enter ChangeDfmDbPasswd.pl, providing a new password as input. For example: 

ChangeDfmDbPasswd.pl newpassword

Step 4 Restart the daemon manager by entering the following command:

•On Windows: 

net start crmdmgmt

•On Solaris: 

/etc/init.d/dmgtd stop

Configuring Logging

DFM writes application log files for all major functional modules. By default, DFM writes only error and fatal messages to these log files; DFM saves the previous three logs as backups.You cannot disable logging. However, you can:

•Collect more data when needed by increasing the logging level

•Return to the default logging level as the norm

This task can be performed by a user logged in to DFM in any of the following roles:

•System Administrator

•Network Administrator

•Network Operator

After selecting the DFM Configuration tab, select Logging. The Logging: Level Configuration page is displayed.

Note You cannot disable logging. DFM will always write error and fatal messages to application log files.

For each DFM functional module, the Error check box is always selected; you cannot deselect it.

To set all modules to Error, the default logging level:

Step 1 Click the Default button.

A confirmation page is displayed.

Step 2 Click OK.

To change the logging level for individual modules:

Step 1 For each module that you want to change, select one (or deselect all) of the following logging levels:

•Warning—Log error messages and warning messages

•Informational—Log error, warning, and informational messages

•Debug—Log error, warning, informational, and debug messages

Note Deselecting all check boxes for a module returns it to Error, the default logging level.

Step 2 Review your changes.

To cancel your changes, click the Cancel button. Otherwise, click the Apply button.

When you click Apply it starts to reset the changed logging levels for the DFM functional modules.

Viewing and Maintaining Log Files

Each DFM module writes log files to its own folder within the NMSROOT/log/dfmLogs folder. Table 11-2 lists each DFM module, the name of the folder where the log files are stored, the related log files, the maximum log size, and the number of backup logs that are saved.

Note NMSROOT is the folder where DFM is installed on the server. If you selected the default directory during installation, it is C:\Program Files\CSCOpx. On Solaris it is /opt/CSCOpx.

When a log file reaches its maximum size, the module backs up the file and starts writing to a new log file. The module appends a number to the backup file, until it reaches the maximum allowed backups. In the following example, the oldest file is TISServer.log.2, and TISServer.log is the current log file. 

02:42 PM      4,481,607      TISServer.log 
10:22 AM      5,120,447      TISServer.log.1 
03:17 AM      5,120,105      TISServer.log.2

By default, DFM writes error messages only to log files. You can change the logging level and thereby affect the amount of information stored in log files. To do so, see Configuring Logging.

If there are two instances of the DfmServer running, each will have a log file, DFM.log and DFM1.log.

Table 11-2 DFM Log Files by Module 

Function/Module
Folder in NMSROOT\log\dfmLogs
Log Files
Maximum Size (KB)
No. of Backup Files

Alerts and Activities Display

AAD

AAD.log

1000

3

Inventory Interactor

cfi

Interactor.log/Interactor1.log

1000

5

Inventory Collector

cfi

InventoryCollector.log/InventoryCollector1.log

35000

5

Polling and Threshold Adapter

cfi

PollingThresholdAdapter.log/PollingThresholdAdapter1.log

10000

5

Detailed Device View

DDV

DDV.log

1000

2

Daily Purging Schedule

DPS

DPS.log

100

2

Event Processing Adapters

epa

adapterServer.log/adapterServer1.log

dfmEvents.log/dfmEvents1.log

1000

5

Event Promulgation Module

EPM

EPM.log

15000

5

Fault History

FH

FHCollector.log

FHUI.log

1000

2

Logging Services

LogService

DfmLogService.log

500

2

Processes with multiple threads

LogService

MultiProcLogger.log

10000

5

License (device limit)

license

licenseCheck.log

100

2

Notification Services

NOS

nos.log

5000

2

DFM Object Grouping Service Server

N/A1

DFMOGSServer.log

300002

152

Polling and Threshold Manager

PTM

PTMClient.log

PTMServer.log

1000

5

Polling and Threshold Manager (database)

PTM

PTMDB.log

1000

5

Polling and Threshold Manager (grouping services)

PTM

PTMOGS.log

1000

5

Polling and Threshold Manager (Polling and Threshold Adapter)

PTM

PTMPTA.log

1000

5

Rediscovery Schedule

Rediscovery

Rediscovery.log

100

2

Device and Credentials Repository Adapter

TIS

DCRAdapter.log

1000

2

Device Management

TIS

DeviceManagement.log

1000

2

Inventory Service

TIS

TISServer.log

1000

2

View Group Management

VGM

vgm.log

1000

3

1 The DFMOGSServer.log file is not stored in NMSROOT/log/dfmLogs with the other DFM log files. It is stored in NMSROOT/log on Windows, and /var/adm/CSCOpx/log on Solaris.

2 On Windows, there is no limit setting for the log size or number of backup log files for DFMOGSServer.log.


Table 11-3 Incharge Log Files

Function/Module
Folder in NMSROOT\obj\smarts\local\logs
Log Files

Inventory

Incharge engine

DFM.log/DFM1.log


Starting and Stopping DFM Processes

Note You cannot stop or unregister a process if any process that depends on it is running. You must first stop or unregister all dependent processes, and then stop or unregister the process.

Step 1 Log in to DFM as a system administrator.

Step 2 Select Common Services > Server Configuration  >  Adm  >  Processes.

The Processes page appears.

Note If a process is not listed, it has not yet been started.

Step 3 On the Processes page, select the process you want to stop in the Process list.

Step 4 Click Stop.

To restart the process, select Server Configuration  >  Admin  >  Processes.

The Processes page appears.

On the Processes page, select the process you want to start in the Process list.

To start the process, click Start.

Table 11-4 provides a complete list of DFM-related CiscoWorks processes. Logs for most of these processes are provided in Table 11-2.

Table 11-4 DFM-Related CiscoWorks Processes 

Name
Description
Dependency

AdapterServer/
AdapterServer 1

Event adapter takes events from backend servers.

None

DataPurge

Data Purge—Starts as scheduled in the GUI and purges the Fault History database.

jrm

DfmBroker

DFM Broker maintains a registry about DFM domain managers, which register the following information with the broker when its initialization is complete:

•Application name of the domain manager

•Hostname where the domain manager is running

•TCP port at which the HTTP server is listening

When a client needs to connect to the domain manager, it first connects to the broker to determine the hostname and TCP port where that server's HTTP service is listening.

It then disconnects from the broker and establishes a connection to the domain manager.

The DfmBroker log file is located at NMSROOT/objects/smarts/local/logs/brstart.log.

None

DFMLogServer

Controls DFM logs.

None

DFMMultiProcLogger

Handles processes with multiple threads.

None

DFMOGSServer

DFM Object Grouping Service Server evaluates group membership.

CmfDbEngine, ESS, DCRServer, TISServer

DfmServer/DfmServer 1

Infrastructure device domain manager, a program that provides backend services for DFM. Services include SNMP data retrieval and event analysis. The DfmServer log is NMSROOT/objects/smarts/logs/DFM.log.

If there are two instances of the DfmServer running, each will have a log file, DFM.log and DFM1.log.

DfmBroker

DFMCTMStartup

Handles interprocess communication.

None

EPMDbEngine

Event Promulgation Module (EPM) database engine—Repository for the EPM module.

None

EPMServer

Sends events to notification services.

EPMDbEngine

FHDbEngine

Fault History database engine—Repository for alerts and events.

None

FHPurgeTask

Fault History purge task.

None

FHServer

Fault History server, a program that runs backend services for Fault History.

EPMServer, EPMDbEngine, FHDBEngine

Interactor

Provides inventory and device information to the Detailed Device View (DDV); updates the DDV with events.

InventoryCollector

Interactor 1

Provides inventory and device information to the Detailed Device View (DDV); updates the DDV with events.

Inventory
Collector 1

InventoryCollector/
InventoryCollector 1

Synchronizes voice device inventory with infrastructure device inventory. Handles all inventory events, such as adding and deleting devices.

ESS, TISServer, DFMOGSServer

INVDbEngine

Inventory database engine—Repository for devices.

None

NOSServer

Notification Server monitors alerts and sends notifications based on subscriptions.

EPMDbEngine,
EPMServer,
INVDbEngine, DFMOGSServer

PTMServer

Polling and thresholds server.

DFMOGSServer

TISServer

Inventory server.

EssMonitor, INVDbEngine


Registering and Unregistering DFM Processes

You can use pdcmd to manually unregister and reregister DFM processes with the CiscoWorks daemon manager. This is useful when you want to do any of the following:

•Specify clients that can connect to DFM.

•Configure adapters to restart automatically whenever the DFM server stops and restarts.

•Configure the DFM server to use a privileged port.

Because these commands are complex, be sure to refer to the examples in these sections:

•Example 1: Specifying Clients that Can Connect to DFM

•Example 2: Configuring the DFM Server to Use a Privileged Port

Before registering a process, you must unregister the related processes in this order:

1. Any processes that depend on the DfmServer process.

2. The DfmServer process.

3. The DfmBroker process.

Use the following syntax when unregistering DFM processes (for Windows, the command is pdcmd.exe): 

NMSROOT/bin/pdcmd -u process

When you reregister the process, specify all options in the same command instance. If you enter the pdcmd multiple times, only the last instance is used. Register the processes in the following order:

1. The DfmBroker process.

2. The DfmServer process.

3. Any processes that depend on DfmServer.

Use the following syntax to reregister the DFM processes. (See Table 11-5 for information about the options and arguments). 

NMSROOT/bin/pdcmd -r DfmBroker -e path -f arguments

NMSROOT/bin/pdcmd -r DfmServer -e path -d depends -f arguments

NMSROOT/bin/pdcmd -r dependent_process -d DfmServer


To view the default settings for a process, enter NMSROOT/bin/pdreg -l  process.

Note If you specify registration options using pdcmd, you must rerun your command whenever the daemon manager restarts.

The ports and protocols used by CiscoWorks are listed in the Installation and Getting Started Guide for LAN Management Solution 3.1.

Table 11-5 Options to pdcmd 

Option
Description and Arguments

-u process

Unregister process. The processes are listed in Table 11-4.

-r process

Register process to CiscoWorks daemon manager and start process whenever the dependent (parent) process starts (as described in the -d depends option). The processes are listed in Table 11-4.

 

-e path

Process binary path. path should be:

•DFM broker: NMSROOT/objects/smarts/bin/brstart

•DFM server: NMSROOT/objects/smarts/bin/sm_server

 

-d depends

Process dependency. For DfmServer, depends should be DfmBroker.

-r process

(continued from previous page)

 
 

-f "arguments"

DFM-specific arguments, enclosed in one set of quotes. arguments can be the following:

--accept host1,host2...

(Optional.) Comma-separated list of hostnames or IP addresses specifying clients which can connect to the server. (The DFM server does not use reverse lookups to determine names of connecting hosts.

•If you specify a client as hostname, be sure the hostname is in DNS, especially if you are using DHCP.

•If you want to specify localhost, use the hostname or IP address, not localhost; refer to Example 1: Specifying Clients that Can Connect to DFM.)

--privopen=open-list

(Optional.) Specify the privileged ports and protocol which DfmBroker or DfmServer may open (see Working with Firewalls, for an example). open-list can be a comma-separated list of the following (IP:protocol is always required):

TCP:port, UDP:port, IP:protocol

The defaults for open-list depend on whether DFM is using a reserved port:

--privopen=IP:1

Default if reserved port is not being used.

--privopen=IP:1, UDP:reserved_port

Default if reserved port is being used (normally 162).

--ouptut=file

(Required.) Name of process output file. For DfmServer, file should be DFM.

--port=port

(DfmBroker only.) DFM broker port. port should always be 9002.

--restore=file

(DfmBroker only.) Restore broker state from backup file. file should always be:

--restore=NMSROOT/objects/smarts/conf/broker.rps

-n

Do not restart process when DfmServer is stopped and restarted.


Example 1: Specifying Clients that Can Connect to DFM

This example shows how to configure DFM to only accept client connections from the hostnames lucy and ethel. In this case you must unregister and reregister the DFM broker, server, and notification adapter processes.

To allow connections from processes running on the same host, specify the host's name—do not use "localhost." This is because connections made using the DFM Broker will appear to come from the DFM Broker's host.

Only connections that explicitly specify "localhost" as the target address will appear to come from localhost. Such target addresses may result in configurations that forward incoming connections (such as through software that provides an encrypted tunnel).

Step 1 Unregister the processes.

a. Unregister the DFM notification adapters: 

# NMSROOT/bin/pdcmd -u DfmFileNotifier

# NMSROOT/bin/pdcmd -u DfmMailNotifier

# NMSROOT/bin/pdcmd -u DfmTrapNotifier

b. Unregister the DFM server process: 

# NMSROOT/bin/pdcmd -u DfmServer

c. Unregister the DFM broker process: 

# NMSROOT/bin/pdcmd -u DfmBroker

Step 2 Reregister the processes, specifying the clients that can connect to the broker and server:

a. For the DFM broker (the following command is one line): 

# NMSROOT/bin/pdcmd -r DfmBroker -e NMSROOT/objects/smarts/bin/brstart -f "--output --port=9002 
--accept=lucy,ethel --restore=NMSROOT/objects/smarts/conf/broker.rps"

b. For the DFM server (the following command is one line): 

# NMSROOT/bin/pdcmd -r DfmServer -e NMSROOT/objects/smarts/bin/sm_server -d DfmBroker -f 
"--bootstrap=DFM_bootstrap.conf --accept=lucy,ethel --output --name=DFM"

When specifying other options (such as --privopen) for DfmServer, use one pdcmd instance. See Example 2: Configuring the DFM Server to Use a Privileged Port.

c. For DFM notification adapters (the following commands are each one line): 

# NMSROOT/bin/pdcmd -r DfmFileNotifier -d DfmServer -e NMSROOT/objects/smarts/bin/sm_notify -f 
"--adapter=filelog --output=sm_file_notifier"


# NMSROOT/bin/pdcmd -r DfmMailNotifier -d DfmServer -e NMSROOT/objects/smarts/bin/sm_notify -f 
"--adapter=mail --output=sm_mail_notifier"


# NMSROOT/bin/pdcmd -r DfmTrapNotifier -d DfmServer -e NMSROOT/objects/smarts/bin/sm_notify -f 
"--adapter=trap --output=sm_trap_notifier"

Example 2: Configuring the DFM Server to Use a Privileged Port

This example shows how to configure DFM to use a privileged port.

Step 1 Unregister any processes that depend on the DfmServer (such as the notification adapters). 

# NMSROOT/bin/pdcmd -u DfmFileNotifier

# NMSROOT/bin/pdcmd -u DfmMailNotifier

# NMSROOT/bin/pdcmd -u DfmTrapNotifier

Step 2 Unregister the DfmServer process: 

# NMSROOT/bin/pdcmd -u DfmServer

Step 3 Reregister the DfmServer process to use UDP port 162 and the IP protocol 1: 

# NMSROOT/bin/pdcmd -r DfmServer -e NMSROOT/objects/smarts/bin/sm_server -d DfmBroker -f 
"--bootstrap=DFM_bootstrap.conf --privopen=IP:1,UDP:162 --output --name=DFM"

Step 4 Reregister any processes that depend on DfmServer: 

# NMSROOT/bin/pdcmd -r DfmFileNotifier -d DfmServer -e NMSROOT/objects/smarts/bin/sm_notify -f 
"--adapter=filelog --output=sm_file_notifier"


# NMSROOT/bin/pdcmd -r DfmMailNotifier -d DfmServer -e NMSROOT/objects/smarts/bin/sm_notify -f 
"--adapter=mail --output=sm_mail_notifier"


# NMSROOT/bin/pdcmd -r DfmTrapNotifier -d DfmServer -e NMSROOT/objects/smarts/bin/sm_notify -f 
"--adapter=trap --output=sm_trap_notifier"

If you also want DFM to accept only specific client connections, you must specify the --accept option when registering the DfmServer process (you do not have to do this for the adapter processes).

The following example registers the DfmServer process to use UDP port 162 and IP protocol 1, and specifies that DFM can accept connections from hostnames lucy and ethel: 

# NMSROOT/bin/pdcmd -r DfmServer -e NMSROOT/objects/smarts/bin/sm_server -d DfmBroker -f 
"--bootstrap=DFM_bootstrap.conf --accept=lucy,ethel --privopen=IP:1,UDP:162 --output --name=DFM"