cc/td/doc/product/dsl_prod/vr4ov/rel235
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Starting ViewRunner Server and ViewRunner Client

Starting ViewRunner Server and ViewRunner Client

7.1 Start ViewRunner Server Applications

ViewRunner for HP OpenView provides startup scripts for the server applications that must be run by the root user. In order to provide easy access to the environment variable setup scripts, the scripts should be copied to the local bin directory.


Note During installation, the ViewRunner servers can be configured to start automatically in /etc/rc2.d/s86vr4hpov. The Oracle database is configured to automatically start in /etc/rc2.d/s85vrdb.

Following are the steps for starting ViewRunner Server applications:

Step 1 Source the server and client startup scripts to set up the ViewRunner environment variables.

    # . /opt/CSCOvrovs/env/vrs.kshrc
    # . /opt/CSCOvrovc/env/vrc.kshrc

Step 2 Verify that the local bin directory is included in every user's path.

Step 3 Copy the ViewRunner server and client scripts to the local bin directory.

Step 4 The pkgadd process places vrs.kshrc and vrs.cshrc in the $VRS_HOME/env directory and vrc.kshrc and vrc.cshrc in the $VRC_HOME/env directory. These are, respectively, the Korn/Bourne shell and C-shell scripts necessary to set up the environment variables for the ViewRunner server and client applications. The pkgadd scripts should place these scripts in the local bin directory to ensure they are accessible to all users. Placing these scripts in the local bin directory also ensures that the scripts continue to function, even if the PATH environment variable is changed to point to a different $VRS_HOME or $VRC_HOME directory.

Step 5 Copy the ViewRunner utility scripts to the local bin directory.

    # cp $VRS_HOME/bin/check_servers /opt/bin/check_servers
    # cp $VRS_HOME/bin/check_clients /opt/bin/check_clients
    # cp $VRS_HOME/bin/check_ovw /opt/bin/check_ovw
    # chmod 755 /opt/bin/check_servers
    # chmod 755 /opt/bin/check_clients
    # chmod 755 /opt/bin/check_ovw

Step 6 Start the ViewRunner Server applications. If you plan to exit this shell and do not want the ViewRunner Server applications to exit as well, ensure you start them using nohup.

    # nohup vrStart &
     
    

The servers should start up. To check the currently running servers, use the ViewRunner utility check_servers, which is described in "ViewRunner Server Utility Scripts".

7.2 ViewRunner Server Utility Scripts

There are eight utility scripts that are included with ViewRunner server applications:

The first five scripts are intended for use by the root user only. The last three scripts are intended for use by all ViewRunner users. Additional scripts and added functionality will be provided with later releases.

7.2.1 vrStart Utility

The vrStart script is used to start the primary ViewRunner server application, vrProcessMon, and any applications on which it depends (HP OpenView and Oracle7). If vrStart detects a failure of vrProcessMon, it will restart vrProcessMon, unless ViewRunner is stopped with the vrStop Utility, HP OpenView is stopped with ovstop, or Oracle is stopped with stop_ora.

Syntax
vrStart [-h] [-t <traceLevel>]
Parameters

The parameter traceLevel is an optional parameter that will set the tracing level as follows:

-h

Display the usage of this command

-t <traceLevel>

1

- Trace Error
- System Level Messages
- Server Startup/Shutdown
- Log File cleanup
- Error Messages

2

- Trace Events
- Function calls of major functions and routines
- Additional client/server information (socket info, etc.)
- Additional warning messages

3

- Trace Functions
- Lower level (remaining) function calls

4

- Trace Path Flow
- Function call stack information
- Display of major application tables and object info

The default trace level is 1, and should be used in most cases. To start ViewRunner at trace level 3, enter the following command:

vrStart -t 3
 

See "vrTrace Utility" for more information on trace levels.

7.2.2 vrStop Utility

The vrStop application interacts with vrProcessMon to shut down ViewRunner server applications.

Syntax
vrStop [-h][-p pipe] [-r <reason>]
Parameters

-h

Display the usage for this command

-p pipe

The communication pipe for the server applications for which the shutdown message is to be sent. If this parameter is not specified, all server applications will be shut down. Otherwise indicate a specific server application name.

-r reason

1

- Server shutdown

2

- Operator in shutdown

3

- OpenView shutdown

4

- Exception shutdown

7.2.3 vrTrace Utility

The vrTrace application interacts with vrProcessMon to set the trace levels of the ViewRunner server applications. vrTrace can be used to change the log file size as well as the log truncation size. The default log size is 81,920K, and the default log truncation size is 51,200K.

The trace level of a running server can be changed from the command line by the root user. If a regular user tries to change the trace level, the operation will fail silently.

To determine the current trace level, run the script check_servers which will inform you of the initial trace level. You also can search the log files for any changes to the trace level by using the following command: grep "Tracing level set to" $VRS_HOME/log/*.

Syntax
vrTrace [-h] [-m truncSize] [-M maxSize] [-t traceLevel] -p {processName | all}
Parameters

-h

Display the usage for this command

-m truncSize

The size to which the trace file will be truncated if it reaches max size

-M maxSize

The size beyond which the trace file will be truncated

-t traceLevel

1

- Trace Error
- System Level Messages
- Server Startup/Shutdown
- Log File cleanup
- Error Messages

2

- Trace Events
- Function calls of major functions and routines
- Additional client/server information (socket info, etc.)
- Additional warning messages

3

- Trace Functions
- Lower level (remaining) function calls

4

- Trace Path Flow
- Function call stack information
- Display of major application tables and object info

-p processName | all

The valid process names are vrProcessMon, vrNetMon, vrAlarmFormatter, and vrDataCollect.

The default trace level is 1, and should be used in most cases.

Trace messages can have one of four possible severities:

7.2.4 vrPerformConfigSync Utility

The vrPerformSync application allows the user to manually control synchronization runs. This utility can be used to perform intelligent configuration synchronizations (the default) or to force full configuration synchronizations. Multiple Cisco 6100s can be synchronized in parallel, subject to the limitations set in the MAX_GLOBAL_CONFIGURATION_SYNCS and MAX_CONFIGURATION_SYNCS_PER_NETMON parameters in the ViewRunner configuration file. The vrPerformSync utility can be run by the root user only.


Note This utility should be run regularly if more than one SNMP management system is used to provision Cisco 6100s.

The ViewRunner installation process automatically schedules a full configuration synchronization every day at midnight using a cron job.

Syntax
vrPerformConfigSync [-h] [-c] [-s] [-i] [-f] [-p] -n all | address[address ...]
Parameters

-h

Display the usage for this command

-c

Configuration synchronization

-s

Save configuration.

-i

Perform an intelligent configuration synchronization

-f

Force a full configuration synchronization

-p

Perform configuration synchronizations in parallel

-n

Select all Cisco 6100s or select individual Cisco 6100s by IP address for configuration synchronization

To perform an intelligent configuration synchronization on two nodes, execute the following command:

vrPerformConfigSync -i -n 172.24.133.20 172.24.133.40
 

To force a full configuration synchronization on all the nodes, execute the following command:

vrPerformConfigSync -f -n all

7.2.5 vrPerformAlarmSync Utility

The vrAlarmSync application reconciles alarm assertions and clears between the Cisco 6100 current alarm tables and the ViewRunner alarm database. The assertions and clears of alarms that were discovered by this utility are annotated in the Event Browser with "Discovered by ViewRunner". The vrPerformSync utility can be run by the root user only.


Note This utility should be run regularly if Cisco 6100s are not provisioned to send traps to the ViewRunner management station.
Syntax
vrPerformAlarmSync [-h] [-p] -n all | address[address...]
Parameters

-h

Display the usage for this command

-p

Perform alarm synchronization in parallel

-n

Select all Cisco 6100s or select individual Cisco 6100s by IP address for configuration synchronization

7.2.6 start_ora Utility

The start_ora script is used to start the vrunner Oracle database. This command should not be executed while any of the ViewRunner server applications are running. This script may be run after boot up of the workstation to ensure that the Oracle database is on line. The vrStart script will start the database if it is not already running. Ordinarily, this utility is not invoked manually. The start_ora utility must be executed by the root user.

7.2.7 start_listener Utility

The start_listener utility starts the Oracle listener. Typically, this utility is started by start_ora and is not invoked manually. The start_listener utility must be executed by the root user.

7.2.8 stop_ora Utility

The stop_ora script is used to stop the vrunner Oracle database. This command should not be executed while any of the ViewRunner server applications are running. This command, however, should be executed before rebooting the server workstation. The stop_ora utility must be executed by the root user.


Note After installing the servers, you should create a link to this script in /etc/rc0.d and /etc/rc1.d to shut down the database when the workstation is being shut down or run level is changed to single user mode (e.g., ln-s $VRS_HOME/bin/start_ora /etc/rc0.d/K00oracle).

7.2.9 check_ora Utility

The check_ora script checks the status of the vrunner Oracle database. It can be run by any user at any time. It has no parameters.

7.2.10 check_servers Utility

To check the currently running servers, use the ViewRunner utility check_servers, which is located in $VRS_HOME/bin and/or the local bin directory. The current version of check_servers is a simple script that looks in the process table for the various process names associated with the servers. The servers that should be running are:

7.2.11 check_clients Utility

To check the currently running client applications, use the ViewRunner utility check_clients, which is located in $VRS_HOME/bin, $VRC_HOME/bin and/or the local bin directory. The current version of check_clients is a simple script that looks in the process table for the various process names associated with the client. The clients that could be running are:


Note The current implementation of this utility is limited to reporting on clients running on the local machine.

7.2.12 check_ovw Utility

To check the currently running OpenView Windows sessions, use the ViewRunner utility check_ovw, which is located in $VRS_HOME/bin, $VRC_HOME/bin and/or the local bin directory. The current version of check_ovw is a simple script that looks in the process table for "ovw" and filters out the other OpenView processes.


Note The current implementation of this utility is limited to reporting on clients running on the local machine.

7.2.13 Viewing NetMon Log File

Use the following commands to view the NetMon log file when using a C shell.

source /opt/bin/vrs.cshrc
cd $VRS_HOME/log
check_servers             #will show process (pid) id of running NetMon(s)
vi vrNetMon.log.<pid>     #where <pid> is value returned from previous command
 

Use the following commands to view the NetMon log file when using a Korn shell.

. /opt/bin/vrs.kshrc
cd $VRS_HOME/log
check_servers             #will show process (pid) id of running NetMon(s)
vi vrNetMon.log.<pid>     #where <pid> is value returned from previous command
 

7.3 Start ViewRunner Client Applications

In order to start the ViewRunner client applications, the user must source the vrc.kshrc or vrc.cshrc script in $VRC_HOME/env or the local bin directory. This will set up the proper paths to the client applications, Oracle, and HP OpenView.

$ . /opt/bin/vrc.kshrc
$ ovw &

The client's applications are then started through the ViewRunner GUI menu options. The initial map that is loaded is HP OpenView's default map. This map does not have View Map (one of ViewRunner's client applications) enabled, so the user must create a new map or open an existing map that does support View Map. See "Miscellaneous Setup" for information on defining a View Map.

See the ViewRunner for HP OpenView Provisioning and Operation Guide for more information on the operation of the ViewRunner client applications.


Note Instructions are provided assuming that user is root and is using ksh.

7.4 ViewRunner Client Utility Scripts

There are two utility scripts that are included with ViewRunner client applications:

Additional scripts and added functionality will be provided with later releases.

7.4.1 check_clients Utility

To check the currently running client applications, use the ViewRunner utility check_clients, which is located in $VRS_HOME/bin, $VRC_HOME/bin and/or the local bin directory. The current version of check_clients is a simple script that looks in the process table for the various process names associated with the client. The clients that could be running are:


Note The current implementation of this utility is limited to reporting on clients running on the local machine.

7.4.2 check_ovw Utility

To check the currently running OpenView Windows sessions, use the ViewRunner utility check_ovw, which is located in $VRS_HOME/bin, $VRC_HOME/bin and/or the local bin directory. The current version of check_ovw is a simple script that looks in the process table for "ovw" and filters out the other OpenView processes.


Note The current implementation of this utility is limited to reporting on clients running on the local machine.


hometocprevnextglossaryfeedbacksearchhelp
Posted: Fri Apr 23 13:59:58 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.