[OpenVMS documentation]
[Site home] [Send comments] [Help with this site] [How to order documentation] [OpenVMS site] [Compaq site]
Updated: 11 December 1998

OpenVMS System Manager's Manual


Previous Contents Index

18.7.3 Delaying Startup of Auditing

Ordinarily, the system turns on auditing in VMS$LPBEGIN just before SYSTARTUP_VMS.COM executes. You can change this behavior, however, by redefining the logical name SYS$AUDIT_SERVER_INHIBIT.

To change the point at which the operating system begins to deliver security-event messages, add the following line to the SYS$MANAGER:SYLOGICALS.COM command procedure:


$ DEFINE/SYSTEM/EXECUTIVE SYS$AUDIT_SERVER_INHIBIT YES 

You can initiate auditing during another phase of system startup, perhaps at the end of SYSTARTUP_VMS.COM, by editing the command file to add the following line:


$ SET AUDIT/SERVER=INITIATE 

For information about editing SYSTARTUP_VMS.COM, see Section 5.2.7.

18.7.4 Enabling Security Auditing for Additional Classes

To enable security auditing for classes in addition to those shown in Table 18-6, use the following format:

SET AUDIT/ENABLE=keyword[,...] {/ALARM | /AUDIT} 

The OpenVMS Guide to System Security contains descriptions of event classes that you can enable.

When you enable auditing for additional event classes, you must specify two qualifiers:

  1. /ENABLE
  2. Either /ALARM or /AUDIT (Although you must specify one qualifier, you can specify both.)

The following table contains explanations of the /ENABLE, /ALARM, and /AUDIT qualifiers.
Qualifier Explanation
/ENABLE Defines which event classes you want audited. See Chapter 19 for more information.
/ALARM
/AUDIT
Defines the destination of the event message.
  • /ALARM directs the message to all enabled security operator terminals.
  • /AUDIT directs the message to the security audit log file.

Use the /ALARM and /AUDIT qualifiers to report critical events. Less critical events can be written only to the security audit log file for later examination.

The default event classes listed in Table 18-6 are sent as both alarms and audits.

The system begins auditing new events on all nodes as soon as you enable them.

Examples

  1. The command in the following example enables auditing for volume mounts and dismounts and sends messages to the security audit log file.


    $ SET AUDIT/ENABLE=MOUNT/AUDIT
    

  2. The command in the following example enables auditing of unsuccessful file accesses and sends messages to all enabled security operator terminals as well as to the security audit log file.


    $ SET AUDIT/ALARM/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=FILE  
    

18.7.5 Disabling Security Auditing

The system continues auditing until you explicitly disable the classes with the /DISABLE qualifier using the following syntax:

SET AUDIT/DISABLE=keyword[,...] {/ALARM | /AUDIT} 

18.7.6 Enabling a Terminal to Receive Alarm Messages

The system sends alarm messages to terminals enabled for security class messages. Security alarm messages are not written to the operator log file. They appear only on terminals enabled for security class messages.

In most cases, security alarm messages appear on the system console by default. Since messages scroll quickly off the screen, it is good practice to enable a separate terminal for security class messages and disable message delivery to the system console.

Either choose a terminal in a secure location that provides hardcopy output, or have dedicated staff to monitor the security operator terminal. You can enable any number of terminals as security operators.

To set up a terminal to receive security class alarms, enter the following DCL command from the designated terminal:


$ REPLY/ENABLE=SECURITY 

Example

The following example shows a security alarm message:


%%%%%%%%%%%  OPCOM  25-MAY-1998 16:07:09.20  %%%%%%%%%%%  
Message from user AUDIT$SERVER on GILMORE 
Security alarm (SECURITY) on GILMORE, system id: 20300 
Auditable event:          Process suspended ($SUSPND) 
Event time:               25-MAY-1998 16:07:08.77 
PID:                      30C00119 
Process name:             Hobbit 
Username:                 HUBERT  
Process owner:            [LEGAL,HUBERT] 
Terminal name:            RTA1: 
Image name:               $99$DUA0:[SYS0.SYSCOMMON.][SYSEXE]SET.EXE 
Status:                   %SYSTEM-S-NORMAL, normal successful completion 
Target PID:               30C00126 
Target process name:      SMISERVER 
Target username:          SYSTEM 
Target process owner:     [SYSTEM] 

18.7.7 Generating Security Reports

The most common type of report to generate is a brief, daily listing of events. You can create a command procedure that runs in a batch job every evening before midnight to generate a report of the day's security event messages and send it to the system manager via Mail.

Note

Because the MOUNT command translates /NOLABEL to /FOREIGN in the audit record, use ANALYZE/AUDIT/SELECT=MOUNT_FLAGS=FOREIGN instead of ANALYZE/AUDIT/SELECT=MOUNT_FLAGS=NOLABEL.

The following example shows the ANALYZE/AUDIT command line you would use to generate this type of report:


$ ANALYZE/AUDIT/SINCE=TODAY/OUTPUT=31JAN1998.AUDIT -
_$ SYS$MANAGER:SECURITY.AUDIT$JOURNAL
$ MAIL/SUBJECT="Security Events" 31JAN1998.AUDIT SYSTEM  

18.7.8 Creating a New Version of the Security Audit Log File

Because the security audit log file continues to grow until you take action, you must devise a plan for maintaining it.

Use the SET AUDIT command to create a new version of the clusterwide security audit log file. To prevent the loss of audit messages, the previous version of the audit log file is not closed until all audit messages stored in memory are written to the file.

18.7.8.1 Creating a New Clusterwide Version of the Log File

To open a new, clusterwide version of the security audit log file, use the following command:


$ SET AUDIT/SERVER=NEW_LOG

The audit server process opens a new version of the audit log file on each cluster node.

After you open the new log, rename the old version, using a naming convention for your files that incorporates in the file name a beginning or ending date for the data. Then copy the file to another disk, delete the log from the system disk to save space, and run the Audit Analysis utility on the old log.

By archiving this file, you maintain a clusterwide history of auditing messages. If you ever discover a security threat on the system, you can analyze the archived log files for a trail of suspicious user activity during a specified period of time.

18.7.8.2 Creating a New Node-Specific Version of the Log File

In some cases, OpenVMS Cluster nodes might not share the same system security audit log file. To create a new, node-specific version of the security audit log file, use the following commands:


$ SET AUDIT/DESTINATION=filespec
$ SET AUDIT/SERVER=NEW_LOG

where filespec is a logical name that points to a node-specific file; for example, SYS$SPECIFIC:[SYSMGR]SECURITY. System security audit log files on other nodes are unaffected.

18.8 Monitoring Operating System Performance

The Monitor utility (MONITOR) is a system management tool that you can use to obtain information about operating system performance. Various MONITOR qualifiers collect system performance data from the running system or play back data recorded previously in a recording file. When you play back data, you can display it, summarize it, and even rerecord it to reduce the amount of data in the recording file.

Following an explanation of the Monitor utility are sections that tell how to perform these tasks:
Task Section
Invoking the Monitor utility Section 18.8.2
Using live display monitoring Section 18.8.3
Using live recording monitoring Section 18.8.4
Using concurrent display and recording monitoring Section 18.8.5
Using playback monitoring Section 18.8.6
Using remote playback monitoring Section 18.8.7
Rerecording monitoring Section 18.8.8
Running MONITOR continuously Section 18.8.9
Using remote monitoring Section 18.8.10

For additional information about interpreting the information the Monitor utility provides, refer to the OpenVMS Performance Management. For additional information about using the Monitor utility, refer to the OpenVMS System Management Utilities Reference Manual.

18.8.1 Understanding MONITOR

Using MONITOR, you can monitor classes of systemwide performance data (such as system I/O statistics, page management statistics, and time spent in each of the processor modes) at specifiable intervals, and produce several types of output. You can also develop a database of performance information for your system by running MONITOR continuously as a background process, as explained in Section 18.8.9.

18.8.1.1 MONITOR Classes

Each MONITOR class consists of data items that, taken together, provide a statistical measure of a particular system performance category. The data items defined for individual classes are listed in the description of the MONITOR command in the OpenVMS System Management Utilities Reference Manual.

To monitor a particular class of information, specify a class name on the MONITOR command line. The information MONITOR displays depends on the type of class you select. Table 18-7 compares the two MONITOR class types.

Table 18-7 Types of MONITOR Classes
Type of class Description
System Provides statistics on resource use for the entire system
Component Provides statistics on the contribution of individual components to the overall system or cluster

As an example of the distinction between types of MONITOR classes, the IO class includes a data item to measure all direct I/O operations for the entire system, and is therefore a system class. The DISK class measures direct I/O operations for individual disks, and is therefore a component class.

Table 18-8 describes each MONITOR class and indicates whether it is a system or component class.

Table 18-8 MONITOR Classes
Class Type Description
ALL_CLASSES System or Component Statistics for all classes
CLUSTER System Clusterwide performance statistics
DECNET System DECnet for OpenVMS statistics
DISK Component Disk I/O statistics
DLOCK System Distributed lock management statistics
FCP System File control primitive statistics
FILE_SYSTEM_CACHE System File system cache statistics
IO System System I/O statistics
LOCK System Lock management statistics
MODES Component Time spent in each of the processor modes
MSCP_SERVER System MSCP server statistics
PAGE System Page management statistics
PROCESSES Component Statistics on all processes
RMS Component Record Management Services statistics
SCS Component System Communications Services statistics
STATES System Number of processes in each of the scheduler states
SYSTEM System Summary of statistics from other classes
TRANSACTION System DECdtm services statistics
+VBS System Virtual balance slot statistics
VECTOR System Vector processor scheduled usage


+VAX specific

18.8.1.2 Display Data

Except in the PROCESSES class, all data item statistics are displayed as rates or levels:

You can request any or all of four different statistics for each data item:
Statistic Description
Current rate or level Most recently collected value for the rate or level
Average rate or level Measured from the beginning of the MONITOR request
Minimum rate or level Measured from the beginning of the MONITOR request
Maximum rate or level Measured from the beginning of the MONITOR request

For the DISK, MODES, SCS, and STATES classes, you can optionally express all statistics as percentages.

In the PROCESSES class, MONITOR displays descriptive information, level information, and counters that increase over time.

18.8.1.3 Output Types

MONITOR collects system performance data by class and produces three forms of optional output, depending on the qualifier you specify:
Qualifier Description
/DISPLAY Produces output in the form of ASCII screen images, which are written at a frequency governed by the /VIEWING_TIME qualifier.
/RECORD Produces a binary recording file containing data collected for requested classes; one record for each class is written per interval.
/SUMMARY Produces an ASCII file containing summary statistics for all requested classes over the duration of the MONITOR request.

If you specify /INPUT with any of these qualifiers, MONITOR collects performance data from one or more previously created recording files; otherwise, data is collected from counters and data structures on the running system.

You use the /BEGINNING and /ENDING qualifiers to specify, respectively, when you want a MONITOR request to begin and end.

Using the /DISPLAY Qualifier

Information collected by MONITOR is normally displayed as ASCII screen images. You can use the optional /DISPLAY qualifier to specify a disk file to contain the information. If you omit the file specification, output is directed to SYS$OUTPUT.

Note

Be careful when you use the /DISPLAY qualifier. Because MONITOR enters display information into the file continuously, its size can grow very quickly.

Refer to the OpenVMS System Management Utilities Reference Manual for a discussion of the /DISPLAY qualifier.

Using the /RECORD Qualifier

When you use the /RECORD qualifier, all data pertaining to the class is recorded, even if you are concurrently displaying only a single statistic or a single item of a component statistics class. The file is created when a MONITOR request is initiated and closed when a request terminates. You can use the resulting file as a source file for later requests to format and display the data on a terminal, to create a summary file, or to create a new recording file with different characteristics.

18.8.2 Invoking MONITOR

To invoke the Monitor utility, enter the following DCL command:


$ MONITOR

MONITOR then displays the following prompt:


MONITOR>

In response to the prompt, you can enter any of the MONITOR commands, which are described in OpenVMS System Management Utilities Reference Manual. The most frequently used MONITOR command, however, specifies a class name.

Example


MONITOR> MONITOR PAGE

In this example, you specify the PAGE class name in the MONITOR command to monitor page management statistics.

You can also use the MONITOR command from DCL command level.

How to Override or Terminate a MONITOR Request

Generally, each MONITOR request runs until the time specified or implied by the /ENDING qualifier. However, to override or terminate a MONITOR request, you can press one of the following conbinations of keys:
Keys Description
Ctrl/W Temporarily overrides a /VIEWING_TIME value and generates a new display immediately following the current one. This feature is useful when a broadcast message overwrites the MONITOR display area.

You can also use Ctrl/W in conjunction with a large /VIEWING_TIME value to generate display events on demand.

Ctrl/C Terminates the current request without exiting from the utility. You can then initiate a new request or enter any MONITOR command at the MONITOR> prompt.
Ctrl/Z Terminates the current request and exits from MONITOR.

18.8.3 Using Live Display Monitoring

Use the live display monitoring mode of operation when you want to examine the activity of a running system, either on a routine basis or as part of an installation checkout, tuning, or troubleshooting exercise. The system does not keep a historical record of output. The following examples show how to use the live display monitoring mode.

Examples


  1. $ MONITOR PROCESSES/TOPCPU
    

    The command displays a bar graph showing the eight processes that were the top consumers of CPU time during the period between displays. It also displays the amount of CPU time each process used.
    The command might produce a display similar to the following one:


                          OpenVMS Monitor Utility 
                           TOP CPU TIME PROCESSES 
                                on node BOMBAY 
                            20-JAN-1998 10:06:49 
     
                                   0         25        50        75       100 
                                   + - - - - + - - - - + - - - - + - - - - -+ 
    07E00181  CAFARET         100  **************************************** 
                                   |         |         |         |          | 
     
                                   |         |         |         |          | 
     
                                   |         |         |         |          | 
     
                                   |         |         |         |          | 
     
                                   |         |         |         |          | 
     
                                   |         |         |         |          | 
     
                                   + - - - - + - - - - + - - - - + - - - - -+ 
     
    

    This example shows that user CAFARET is using 100 percent of the CPU time available. To display more information about the computer resources a user is using, use a command similar to the following one:


    $ SHOW PROCESS/CONTINUOUS/ID=07E00181
    

    For this example, the most useful information in the resulting display is the name of the image at the end of the display; for example:


    . 
    . 
    . 
    $1$DUA1:[SYS1D.SYSCOMMON.][SYSEXE]RODAN.EXE 
    

    This example indicates that CAFARET is running RODAN.EXE, which might be new software that is unintentionally running in a loop. This situation would occur if CAFARET were a privileged user running a process at a higher priority than other users.


  2. $ MONITOR/DISPLAY=PROCESSES.LOG PROCESSES
    

    You can route MONITOR display output to any supported terminal device or to a disk file. This command writes MONITOR's display process statistics to the file PROCESSES.LOG. You can then print this file on a hardcopy device.

    Caution

    Because data is continuously added to the display file, be careful that the file does not grow too large.

  3. $ MY_CLASSES :== -
    _$ "DECNET+FCP+IO+LOCK+MODES+PAGE+PROCESSES+STATES"
    $ MONITOR/NODE=(CURLEY,LARRY)/INTERVAL=20/VIEWING_TIME=8 'MY_CLASSES'
    

    You might find it convenient to establish DCL symbols for frequently used combinations of class names, as in this example. The MONITOR command collects selected classes of data for OpenVMS Cluster nodes CURLEY and LARRY every 20 seconds. Every 8 seconds, the system displays the most recently collected data for one of the classes. MONITOR predetermines the ordering of the classes for display.


Previous Next Contents Index

[Site home] [Send comments] [Help with this site] [How to order documentation] [OpenVMS site] [Compaq site]
[OpenVMS documentation]

Copyright © Compaq Computer Corporation 1998. All rights reserved.

Legal
6017PRO_083.HTML