|
|
ViewRunner for HP OpenView provides start-up utilities for the server applications that must be run by the root user. In order to provide easy access to the environment-variable setup utilities, the utilities should be copied to the local bin directory.
Following are the steps for starting ViewRunner Server applications:
Step 1 Find the source for the server and client start-up utilities to set up the ViewRunner environment variables.
# . /opt/CSCOvrovs/env/vrs.kshrc
Step 2 Verify that the local bin directory is included in every user's path.
Step 3 Copy the ViewRunner server and client utilities to the local bin directory.
Step 4 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 that you start them using nohup.
# nohup vrStart &
The servers should start up. To check the servers that are currently running, use the ViewRunner utility check_servers, which is described in the "ViewRunner Utilities" section.
The following twelve utilities are included with ViewRunner applications:
The first nine of the preceding utilities are intended for use by the root user only. The last three utilities are intended for use by all ViewRunner users.
The vrStart utility 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 restarts vrProcessMon unless ViewRunner is stopped with one of the following processes:
vrStart [-h] [-t <traceLevel>]
The parameter traceLevel is an optional parameter that sets the trace level as follows:
-h | Displays the usage of this command | |
-t <traceLevel> | 1 | - Trace error |
| 2 | - Trace events |
| 3 | - Trace functions |
| 4 | - Trace path flow |
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 the "vrTrace Utility" section for more information on trace levels.
The vrStop utility interacts with vrProcessMon to shut down ViewRunner server applications.
vrStop [-h][-p pipe] [-r <reason>]
-h | Displays 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 are shut down. Otherwise, indicate a specific server application name. | |
-r reason | 1 | - Server shutdown |
| 2 | - Operator shutdown |
| 3 | - OpenView shutdown |
| 4 | - Exception shutdown |
The vrTrace utility interacts with vrProcessMon to set the trace levels of the ViewRunner server applications. The vrTrace utility can be used to change the log file size as well as the log truncation size. The default log size is 81,920 K, and the default log truncation size is 51,200 K.
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 start-up fails silently.
To determine the current trace level, run the utility check_servers, which informs you of the
initial trace level. Also, you 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/*.
vrTrace [-h] [-m truncSize] [-M maxSize] [-t traceLevel] -p {processName | all}
-h | Displays the usage for this command | |
-m truncSize | The size to which the trace file is truncated if it reaches maximum size | |
-M maxSize | The size beyond which the trace file is truncated | |
-t traceLevel | 1 | - Trace error |
| 2 | - Trace events |
| 3 | - Trace functions |
| 4 | - Trace path flow |
-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:
The vrPerformConfigSync utility allows you 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 6100 Series systems 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 vrPerformConfigSync utility can be run by the root user only.
The ViewRunner installation process automatically schedules a full configuration synchronization every day at midnight using a cron job.
vrPerformConfigSync -h vrPerformConfigSync -s [-p] -n all | address[address ...] vrPerformConfigSync -c [-f|-i] [-p] -n all | address[address ...]
-h | Displays the usage for this command | |
-c | Perform a configuration synchronization | |
-s1 | Save configuration | |
-i | Perform an intelligent configuration synchronization | |
-f | Force a full configuration synchronization | |
-p | Perform configuration synchronizations in parallel | |
-n | Select all Cisco 6100 Series systems or select individual Cisco 6100 Series systems 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
The vrPerformAlarmSync utility reconciles alarm assertions and alarm clears between the Cisco 6100 Series system current alarm tables and the ViewRunner alarm database. The alarm assertions and clears that were discovered by this utility are annotated in the Event Browser with "Discovered by ViewRunner." The vrPerformAlarmSync utility can be run by the root user only.
vrPerformAlarmSync [-h] [-p] -n all | address[address...]
-h | Displays the usage for this command | |
-p | Perform alarm synchronization in parallel | |
-n | Select all Cisco 6100 Series systems or select individual Cisco 6100 Series systems by IP address for configuration synchronization | |
The start_ora utility is used to start the vrunner Oracle database. This command should not be executed while any of the ViewRunner server applications are running. This utility may be run after boot up of the workstation to ensure that the Oracle database is on line. The vrStart utility starts 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.
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.
The stop_ora utility is used to stop the vrunner Oracle database. This command should not be executed while any of the ViewRunner server applications are running. However, this command should be executed before rebooting the server workstation. The stop_ora utility must be executed by the root user.
The check_ora utility checks the status of the vrunner Oracle database. It can be run by any user at anytime. This utility has no parameters.
To check the servers that are currently running, use the ViewRunner utility, check_servers, which is located in $VRS_HOME/bin or the local bin directory. The current version of check_servers is a simple utility that looks in the process table for the various process names associated with the servers. The following servers should be running:
To check the client applications that are currently running, use the ViewRunner utility, check_clients, which is located in $VRS_HOME/bin, $VRC_HOME/bin or the local bin directory. The current version of check_clients is a simple utility that looks in the process table for the various process names associated with the client. The clients that could be running are
To check the OpenView Windows sessions that are currently running, use the ViewRunner utility, check_ovw, which is located in $VRS_HOME/bin, $VRC_HOME/bin or the local bin directory. The current version of check_ovw is a simple utility that looks in the process table for "ovw" and filters out the other OpenView processes.
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 #start-up 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 #start-up show process (pid) id of running NetMon(s) vi vrNetMon.log.<pid> #where <pid> is value returned from previous command
In order to start the ViewRunner client applications, you must source the vrc.kshrc or vrc.cshrc utility in $VRC_HOME/env or the local bin directory. This sets 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 the HP OpenView default map. This map does not have ViewMap (one of ViewRunner's client applications) enabled, so you must create a new map or open an existing map that does support ViewMap. See "Miscellaneous Setup" for information on defining a ViewMap.
See the ViewRunner for HP OpenView Provisioning and Operation Guide for more information on the operation of the ViewRunner client applications.
There are two utilities that are included with ViewRunner client applications.
To check the client applications that are currently running, use the ViewRunner utility, check_clients, which is located in $VRS_HOME/bin, $VRC_HOME/bin or the local bin directory. The current version of check_clients is a simple utility that looks in the process table for the various process names associated with the client. The clients that could be running are
To check the OpenView Windows sessions that are currently running, use the ViewRunner utility, check_ovw, which is located in $VRS_HOME/bin, $VRC_HOME/bin or the local bin directory. The current version of check_ovw is a simple utility that looks in the process table for "ovw" and filters out the other OpenView processes.
Posted: Fri Oct 8 13:50:27 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.