Previous Topic: Using Ports to Transfer DataNext Topic: Integrating with CA Spectrum Service Assurance

Using Ports to Transfer Data › Configure the DIA Communications Port

Configure the DIA Communications Port

DIA requires the use of four distinctive ports for communication. By default, these ports are 11501, 11502, 11503 and 11504. You can change them in DIA configuration files.

Note: You must complete the following procedure on each machine where DIA is installed.

To change the DIA ports

  1. Open the dna.cfg file in the folder InstallPath\CA\SharedComponents\CCS\DIA\dia\dna\config using a text editor of your choice.
  2. Set RMI_REGISTRY_PORT and RMI_DATA_PORT to the port numbers you want.

    The two port numbers must be different.

  3. Save the dna.cfg file.
  4. Open the ukb.cfg file in the folder InstallPath\CA\SharedComponents\CCS\DIA\dia\ukb\config using a text editor of your choice.
  5. Set RMI_DNA_REGISTRY_PORT to the same port number that you specified in RMI_REGISTRY_PORT in dna.cfg at Step 2.
  6. Set RMI_REGISTRY_PORT and RMI_DATA_PORT to the port numbers you want.

    The two port numbers must be different from each other and should be different from those you set for RMI_REGISTRY_PORT and RMI_DATA_PORT in the dna.cfg file.

  7. Save the ukb.cfg file.
  8. Modify the SRV record and set the port number field to the same value as you have for RMI_REGISTRY_PORT in the ukb.cfg file.

    See the topic Configure Unicenter Domain Name Services earlier in this appendix. If you do not have an SRV record in the domain, skip this step.

  9. Stop both of the following services or daemons and restart them to apply the changes:

The following example assumes you want to set customized ports to 16001, 16002, 16003, and 16004:

  1. In the dna.cfg file, set the following:
  2. In the ukb.cfg file, set the following
  3. In the SRV record of DNS, make the following change:

    Set “port number field” to 16003.

NSMADM-CA Messaging Overview

The CA Message Queuing Service (CAM) is one of the two principle data transport mechanisms used by CA NSM. CAM provides connection-less application-to-application messaging with reliable delivery. In addition to the standard IP protocols, CAM provides the following features:

CAM combines the lightweight benefits of UDP with the reliable delivery of TCP. A CAM server process runs on each host supporting CAM. CA's applications that use CAM communicate with the CAM local server, which then forwards messages to other CAM servers or to other CAM client applications on the same computer. For more information about CAM, see the CAM product documentation.

CAFT is a simple file transfer protocol (similar to FTP) that uses CAM for its data transport.

NSMADM-CAM Supported Transport Layer Protocols

CAM supports the following Transport Layer Protocols:

Components That Use CAM/CAFT

The following CA NSM components make use of CAM and in certain cases, CAFT, as their principle messaging/data transport mechanism.

Component

Subcomponent

Windows Executable

UNIX/Linux Executable

Continuous Discovery

Continuous Discovery Manager

dscvmgrservice.exe

CaDiscMgrService

 

Continuous Discovery Agent

dscvagtservice.exe

CaDiscAgentService

Systems Performance

Performance Scope

perfscope.exe

N/A

 

Performance Trend

perftrend.exe

N/A

 

Performance Web Reporting

java.exe

java

 

Performance Configuration

egc30n.exe

N/A

 

 

discover.exe

N/A

 

 

hpaprofile.exe

N/A

 

Performance Configuration (one-click)

capmwvc.exe

N/A

 

Performance Data Grid

pdectl.exe

pdectl

 

 

pdgstat.exe

pdgstat

 

 

capmpde.exe

capmpde

 

 

pdesumgen.exe

pdesumgen

 

Performance Domain Server

configserver.exe

configserver

 

Performance Distribution Server

profileserver.exe

profileserver

 

Performance Agent

prfagent.exe

prfAgent

 

 

hpaagent.exe

hpaAgent

 

 

hpacbman.exe

hpacbman

 

 

hpacbcol.exe

hpacbcol

 

Performance Utilities

cubespider.exe

cubespider

 

 

rtpmon.exe

rtpmon

 

 

cfgutil.exe

cfgutil

 

 

pdtodm_m.exe

pdtodm_m

 

 

pdtodb_u.exe

pdtodb_u

 

 

pdtoxml.exe

pdtoxml

CAM/CAFT Configuration FIles

The configuration files for CAM and CAFT are as follows:

cam.cfg

Main CAM configuration file. Configures most aspects of CAM's operation, including basic configuration settings, routing rules, logging and tracing control, port and transport layer control, and so forth.

camclient.cfg

Contains a list of registered processes that can be automatically started by CAM when a message arrives for them.

caftenv.cfg

CAFT environment variables (for example, used to store locations set at install time of Systems Performance Cube Store directories).

CAM/CAFT Binaries

The following list of CAM binaries includes the principle CAM components, as well as utilities and configuration tools.

Windows

UNIX/Linux

Description

cam.exe

cam

CAM server

camabort.exe

camabort

Stops the CAM server (forcefully)

camben.exe

camben

Benchmarks a communications link

camclose.exe

camclose

Stops the CAM server cleanly (informs clients first).

camconfig.exe

camconfig

Changes the CAM configuration and routing.

camping.exe

camping

Similar to ICMP echo request (ping), but can check availability of client applications as well as hosts.

camq.exe

camq

Lists and manipulates queues in the CAM server.

camsave.exe

camsave

Saves the CAM server's configuration in the same format as cam.cfg.

camstat.exe

camstat

Displays detailed status information for a CAM server.

camswitch.exe

camswitch

Forces a log file switch.

How to Encrypt the MCC Data Transport (CAM) for AIS Providers

For security reasons, you may want to encrypt the information going over the network between the MCC and the AIS Providers (WorldView, DSM, etc.). These providers use the AIS subsystem, which in turn uses CAM. Complete the following process to encrypt CAM for AIS providers:

  1. Install the CA Secure Socket Adapter (SSA).
  2. Reconfigure CAM to use the newly installed SSA component.

Install the CA Secure Socket Adapter

You must install the CA Secure Socket Adapter (SSA) so that you can use it to encrypt CAM.

To install the CA Secure Socket Adapter

  1. Navigate to the following location on the CA NSM installation DVD: Windows\NT\$LANGPACK\$ALL\SSA
  2. Run the following executable: 
    CASockAdapterSetupWin32.exe
  3. Follow the prompts to install SSA.

Note: SSA 2.0 is not currently supported on Solaris on Intel. All other manager/client configurations are supported.

Integrating with the Secure Socket Adapter

The Secure Socket Adapter provides a means of adding extra services to TCP connections without requiring changes to the programs that make these connections. This description applies to SSA 2.0 or later but is also applicable to the earlier version of SSA, known as the Dylan Socket Adapter. For the Dylan Socket Adapter, the csamconfigedit command described below is known as configedit.

CAM makes use of SSA to enhance the security of its messaging. When using SSA, TCP paths can be secured using SSA's ability to provide SSL/TLS encryption.

Note: Communications within a machine are not normally encrypted, and the CAM API library does not integrate with SSA.

On UNIX platforms, the CAM server detects SSA's presence at startup and and makes use of the SSA library to interface with the underlying communications layer. On Windows, we provide a version of the CAM server code that has been adapted to use SSA. In both cases, the adapted CAM performs no differently unless SSA is configured to adapt the port that CAM uses for TCP.

Configure CAM for SSA

SSA adapts TCP connections, but does not adapt UDP messages. To account for the lack of UDP support, if all CAM communications are to use SSL/TLS, you can disable UDP, making TCP the default protocol. To disable UDP for CAM, include the following line in the CAM configuration file, cam.cfg:

*CONFIG
udp_port=0

Alternatively, you can configure specific paths that you want to adapt by defining them in the *PATHS section. However, this approach could be cumbersome on large networks and difficult to maintain when machine addresses are determined by DHCP.

A more usable option is to select the machines on which you always want to use SSL for CAM communications and configure them as follows in cam.cfg:

*CONFIG
udp_port=-1

With this setting, all remote paths created by CAM are TCP paths (and can then be adapted, using SSA to use SSL). Also, if other machines attempt to establish a UDP path, they are rejected and switched to TCP. However, the part of the network where security is not required can continue to use UDP.

Note: With this configuration, one unencrypted UDP message is sent and rejected for connections that are switched to TCP.

Activate SSA-enabled CAM on Windows

On Windows, you must activate the SSA-enabled version of CAM.

To activate SSA-enabled CAM on Windows

  1. Open a command prompt of a user with administrator privileges.

    Note: On Windows Vista and later Windows versions, you must explicitly request administrator privileges when opening the command prompt, even if you are an administrator.

  2. Enter the following command: 
    camdsa install

    The command associates the SSA-enabled version of the CAM server with the CAM service.

  3. Restart the CAM service.

    CAM is SSA-enabled.

You can reverse this process by running the following command and restarting the CAM service:

cam install
Configure SSA to Enable CAM to use SSL/TLS

You must configure the SSA-enabled CAM to use SSL/TLS by requesting the support and enabling use of the SSA connection broker.

To configure SSA-enabled CAM to use SSL/TLS, run the following command at a command prompt:

csamconfigedit port=4105 EnableSSL=True EnablePmux=True PmuxLegacyPortListen=True PmuxLegacyPortBindAddress=127.0.0.1

This command requests SSL/TLS encryption on the CAM TCP port and enables use of the SSA connection broker (port multiplexer) for connections using that port. The port multiplexer must be used to allow support for non-encrypted TCP connections, as it enables the SSA software to differentiate between the two. Legacy connections are also allowed on the port but are restricted to within-machine connections by binding to 127.0.0.1, the IPv4 localhost address.

In an IPv6 environment, you may need to replace the final parameter value of 127.0.0.1 with localhost (or 127.0.0.1;::1 if localhost cannot be resolved to one or both of these addresses).

Note: On some machines, localhost may not resolve to any addresses.

On AIX, in rare circumstances, CAM may not be able to accept local connection when using CAM 1.12 or later if you set a bind address. If you experience this issue (one symptom is that the camf process is running but utilities such as camstat claim that it is not), remove the PmuxLegacyPortBindAddress parameter from the initial definition or set it back to its default value.

If you want to accept unadapted connections from remote machines, you can omit the PmuxLegacyPortBindAddress parameter, but you also have to define an appropriate OutboundHostList to ensure that outward connections to these machines are not adapted. This operation may prove complex in practice, and the most viable policy is to encrypt all connections. You could use UDP for non-encrypted connections, but this would require you to explicitly configure (in CAM) all encrypted connections. SSA 2.1 will improve flexibility in this area.