Document revision date: 30 March 2001

## OpenVMS System Manager's Manual

Previous | Contents | Index

#### 20.6.2.5 Volume Mount and Dismount Messages

Perhaps the widest range of operator messages occurs with volume mounts and dismounts; for example:

    %%%%%%%%%%%  OPCOM, 19-APR-2000 22:41:07.54  %%%%%%%%%%%
    message from user SYSTEM
    Volume "KLATU       " dismounted, on physical device MTA0:
    15-APR-2000 22:42:14.81, request 2 completed by operator OPA0

#### 20.6.2.6 System Parameter Messages

Users with the appropriate privileges can change the following sets of values for system parameters:

Values | Description
--- | ---
Current | Values stored in the default parameter file on disk and used to boot the system
Active | Values stored in memory and used while the system is running

When the system boots, it reads the current values into memory, creating active values. An active value remains equal to the current value until you change either value.

Users can make the following changes to active and current system parameters:

- Active system parameters---Users with CMKRNL privilege can use the System Management utility (SYSMAN) or the System Generation utility (SYSGEN) to change system parameters in the running (active) system. Users can change only those active values that are categorized as dynamic system parameters.
- Current system parameters---Users with SYSPRV privilege can use SYSMAN or SYSGEN to change system parameters in the current system.

Note Compaq recommends that you use AUTOGEN or SYSMAN, not SYSGEN, to change system parameters, as explained in Section 15.2.

OPCOM logs all changes made to active and current system parameters with messages in the following format:

    %%%%%%%%%%%  %OPCOM <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%%
    Message from user <user-name>
    %SYSGEN-I-WRITExxx, <system-mode> system parameters modified by process ID
    <process-id> into file <file-spec>

Example

    %%%%%%%%%%%  %OPCOM 3-JUN-2000 08:11:59.55 %%%%%%%%%%%
    Message from user D_PLUTO on ANASAT
    %SYSGEN-I-WRITECUR, CURRENT system parameters modified by process ID 0000020B
    into file SYS$UPDATE:[SYSTEM]UPDATESYS.PAR;2

This message indicates that current system parameters have been changed.

Note If you have changed the format of system messages with the DCL command SET MESSAGE, these messages might not appear in the log file.

#### 20.6.2.7 Security Alarm Messages

Alarm messages are sent to the security operator terminal when selected events occur. See Section 20.7.6 for instructions about how to enable a terminal to receive security alarm messages.

Example

The following example shows a security alarm OPCOM message after a change to JTQUOTA:

    %%%%%%%%%%%  OPCOM   6-JAN-2000 10:41:21.10  %%%%%%%%%%%
    Message from user AUDIT$SERVER on BISCO
    Security alarm (SECURITY) and security audit (SECURITY) on BISCO, system id:
    20353
    Auditable event:          System UAF record modification
    Event time:               6-JAN-2000 10:41:20.69
    PID:                      00600123
    Process name:             SYSTEM
    Username:                 SYSTEM
    Process owner:            [SYSTEM]
    Terminal name:            RTA1:
    Image name:               BISCO$DUA0:[SYS0.SYSCOMMON.][SYSEXE]AUTHORIZE.EXE
    Object class name:        FILE
    Object name:              SYS$SYSTEM:SYSUAF.DAT;4
    User record:              NEWPORT
    JTQUOTA:                  New:           2048
                              Original:      1024

#### 20.6.2.8 Contents of an Operator Log File

Example 20-6 illustrates some typical messages found in an operator log file.

Example 20-6 Sample Operator Log File (SYS$MANAGER:OPERATOR.LOG)

     %%%%%%%%%%%  OPCOM, 19-APR-2000 22:26:07.90  %%%%%%%%%%%
     Device DMA0: is offline. (1)
     Mount verification in progress.
     %%%%%%%%%%%  OPCOM, 19-APR-2000 22:26:20.22  %%%%%%%%%%%
     Mount verification completed for device DMA0:
     %%%%%%%%%%%  OPCOM, 19-APR-2000 22:33:54.07  %%%%%%%%%%%
     Operator '_ZEUS$VT333:' has been disabled, user JONES (2)
     %%%%%%%%%%%  OPCOM, 19-APR-2000 22:34:15.47  %%%%%%%%%%%
     Operator '_ZEUS$VT333:' has been enabled, user SMITH
     %%%%%%%%%%%  OPCOM, 19-APR-2000 22:34:15.57  %%%%%%%%%%%
     operator status for '_ZEUS$VT333:'
     PRINTER, TAPES, DISKS, DEVICES
     %%%%%%%%%%%  OPCOM, 19-APR-2000 22:38:53.21  %%%%%%%%%%%
     request 1, from user PUBLIC (3)
     Please mount volume KLATU in device MTA0:
     The tape is in cabinet A
     %%%%%%%%%%%  OPCOM, 19-APR-2000 22:39:54.37  %%%%%%%%%%%
     request 1 was satisfied.
     %%%%%%%%%%%  OPCOM, 19-APR-2000 22:40:23.54  %%%%%%%%%%%
     message from user SYSTEM (4)
     Volume "KLATU       " mounted, on physical device MTA0:
     %%%%%%%%%%%  OPCOM, 19-APR-2000 22:40:38.02  %%%%%%%%%%%
     request 2, from user PUBLIC
     MOUNT new relative volume 2 () on MTA0:
     %%%%%%%%%%%  OPCOM, 19-APR-2000 22:41:07.54  %%%%%%%%%%%
     message from user SYSTEM
     Volume "KLATU       " dismounted, on physical device MTA0:
     15-APR-2000 22:42:14.81, request 2 completed by operator OPA0
     %%%%%%%%%%%  OPCOM, 19-APR-2000 22:46:47.96  %%%%%%%%%%%
     request 4, from user PUBLIC
     _TTB5:, This is a sample user request with reply expected.
     %%%%%%%%%%%  OPCOM, 19-APR-2000 22:47:38.50  %%%%%%%%%%%
     request 4 was canceled
     %%%%%%%%%%%  OPCOM, 19-APR-2000 22:48:21.15  %%%%%%%%%%%
     message from user PUBLIC
     _TTB5:, This is a sample user request without a reply expected.
     %%%%%%%%%%%  OPCOM, 19-APR-2000 22:49:37.64  %%%%%%%%%%%
     Device DMA0: has been write locked.
     Mount verification in progress.
     %%%%%%%%%%%  OPCOM, 19-APR-2000 23:33:54.07  %%%%%%%%%%%
     message from user NETACP
     DECnet shutting down

The following messages appear in the example:

1. Device status message
2. Terminal enable and disable message
3. User request and operator reply messages
4. Volume mount and dismount messages

### 20.6.3 Setting Up the Operator Log File

The operator log file normally resides on the system disk in the [SYSMGR] directory. You can, however, maintain the log file in a different location by defining the logical name OPC$LOGFILE_NAME.

The size of and access to the OPERATOR.LOG file (or to the file pointed to by the logical OPC$LOGFILE_NAME) is limited by the size and access of the disk device on which it resides. If the disk device does not have enough room to write to the log file or if access to the device is restricted in any other way, records might be missing from the log file.

Because this file is in ASCII format, you can print it. Print copies regularly and retain these copies for reference. Section 20.6.5 describes how to print copies of the operator log file.

The system creates a new version of OPERATOR.LOG each time the system is rebooted (except on workstations in an OpenVMS Cluster environment, where the log file is not opened by default). Note that one operator log file exists for each node; it is not a shared file.

#### 20.6.3.1 Creating a New Version of the Operator Log File

You can use the DCL command REPLY/LOG to create a new version of the file at any time. The highest version is always the one in use and is inaccessible to other users. By default, messages of all operator classes are in the log file.

The following list contains guidelines for using the REPLY/LOG command:

- You can use the REPLY/LOG/ENABLE=(keyword) and REPLY/LOG/DISABLE=(keyword) commands to specify which operator classes to include in the log file.
- When you use the /LOG qualifier with the REPLY/ENABLE and REPLY/DISABLE commands, the classes you select are enabled or disabled for the log file rather than for the terminal.

If a log file is already open, the list of classes is preserved and enabled on the newly created log file. If a log file is not open, the value of the logical OPC$ENABLE_LOGFILE_CLASSES is used. If that logical does not exist, all classes are enabled on the new log file.

For more information, refer to the REPLY/LOG, REPLY/ENABLE, and REPLY/DISABLE commands in the OpenVMS DCL Dictionary.

Example

The following command opens a log file to include messages about mounting and dismounting disks and tapes:

    $ REPLY/LOG/ENABLE=(DISKS,TAPES)

#### 20.6.3.2 Specifying Logical Names

You can specify the default state of the operator log files by defining logical names in the command procedure SYS$MANAGER:SYLOGICALS.COM. The following table lists these logical names and their functions. For more information about SYLOGICALS.COM, see Section 5.2.5.

Caution Setting the OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND logical names to FALSE severs all OPCOM traffic in the specified direction. All OPCOM messages, as well as any returned status messages that might be expected, will not be delivered.

Logical Name | Function
--- | ---
OPC$ALLOW_INBOUND | Allows OPCOM traffic that is inbound to the node to be turned on or off. By default, this logical name is set to TRUE. If this logical name is set to FALSE, the node will not receive any OPCOM messages from other nodes in the cluster.
OPC$ALLOW_OUTBOUND | Allows OPCOM traffic that is outbound from the node to be turned on or off. By default, this logical name is set to TRUE. If this logical name is set to FALSE, the node will not send any OPCOM messages to other nodes in the cluster.
OPC$LOGFILE_ENABLE | Specifies whether an operator log file is opened. If defined to be true, an operator log file is opened. If defined to be false, no operator log file is opened. By default, a log file is opened on all systems except workstations in an OpenVMS Cluster environment.
OPC$LOGFILE_CLASSES | Specifies the operator classes that are enabled for the log file. By default, a log file is opened for all classes. The logical name can be a search list of the allowed classes, a comma-separated list, or a combination of the two. Note that you can define OPC$LOGFILE_CLASSES even if you do not define OPC$LOGFILE_ENABLE. In that case, the classes are used for any log files that are opened, but the default is used to determine whether to open the log file.
OPC$LOGFILE_NAME | Specifies the name of the log file. By default, the log file is named SYS$MANAGER:OPERATOR.LOG. If you specify a disk other than the system disk, include commands to mount that disk in the command procedure SYLOGICALS.COM.
OPC$OPA0_ENABLE | Overrides values of symbols for workstations in a cluster. If you define the logical as TRUE, it sets the OPA0 device to BROADCAST (overrides the NOBROADCAST default setting). For systems that are not workstations in a cluster, if you define the logical as FALSE, it sets the OPA0 device to NOBROADCAST.

Note The only logical that is used for more than the initial startup of OPCOM is OPC$LOGFILE_NAME. All other OPCOM logicals are ignored. For example, a REPLY/LOG command opens a new operator log file even if the logical OPC$LOGFILE_ENABLE is defined to be false. To reset OPCOM states and classes after startup, use REPLY/ENABLE or REPLY/DISABLE commands.

### 20.6.4 Maintaining the Operator Log File

Devise a plan for regular maintenance of operator log files. One way is to start a new log file and rename the second-highest version daily. (See the example in the next section.) You might want to purge outdated versions of the operator log file on a regular basis. However, do not delete versions that you have not backed up. For more information, see Section 5.2.7.9.

If OPCOM is inadvertently deleted, follow these steps to start it manually:

1. Log in to the SYSTEM account so that you have the required privileges to perform the operation.
2. Enter the following command to execute the startup command procedure (STARTUP.COM), specifying OPCOM as the command parameter:

       $ @SYS$SYSTEM:STARTUP OPCOM

### 20.6.5 Printing the Operator Log File

Perform the following operation to produce a printed copy of the most recent version of the operator log file. (You must have OPER privilege.)

1. Use the following command to enable the terminal as an operator terminal:

       $ REPLY/ENABLE

2. Close the current log file and open a new one by entering the following command:

       $ REPLY/LOG

3. Set the default to SYS$MANAGER and enter the following command to list all versions of the file:

       $ SET DEFAULT SYS$MANAGER
       $ DIRECTORY OPERATOR.LOG

4. Rename the second-highest version to OPERATOR.OLD:

       $ RENAME OPERATOR.LOG;-1 OPERATOR.OLD

   The version number, --1, specifies that you want to rename the second-highest version of this file. (The highest version number is the current operator log file.)
5. Print the operator log file by entering the following command:

       $ PRINT OPERATOR.OLD

Example

    $ REPLY/ENABLE (1)
    $ REPLY/LOG (2)
    %%%%%%%%%%%  OPCOM, 19-APR-2000 12:28:20.11  %%%%%%%%%%%
    Logfile was closed by operator _MARS$VTA2: (3)
    Logfile was HOMER::SYS$MANAGER:[SYSMGT]OPERATOR.LOG;27
    %%%%%%%%%%%  OPCOM, 19-APR-2000 12:29:24.52  %%%%%%%%%%%
    Logfile has been initialized by operator _MARS$VTA2:
    Logfile is HOMER::SYS$MANAGER:[SYSMGT]OPERATOR.LOG;28
    $ SET DEFAULT SYS$MANAGER (4)
    $ DIRECTORY OPERATOR.LOG (5)
    Directory SYS$MANAGER:[SYSMGT]
    OPERATOR.LOG;28           OPERATOR.LOG;27
    Total of 2 files.
    $ RENAME OPERATOR.LOG;-1 OPERATOR.OLD (6)
    $ PRINT OPERATOR.OLD (7)

The following list provides explanations of the numbered commands and responses in the example:

1. The REPLY/ENABLE command enables the terminal as an operator terminal.
2. The REPLY/LOG command closes the current log file and opens a new one.
3. The response from OPCOM verifies that it has opened a new log file.
4. The SET DEFAULT command sets the operator default disk to the system disk.
5. The DIRECTORY command displays the files in the directory [SYSMGT] on the system disk.
6. The RENAME command renames the second-highest version of the operator log file to OPERATOR.OLD.
7. The PRINT command prints the old operator log file, OPERATOR.OLD.

## 20.7 Using Security Auditing

This section discusses how security auditing works; it also explains how to enable security auditing and how to create a new version of the security audit log file. For more information about the security audit log file, refer to the OpenVMS Guide to System Security.

### 20.7.1 Understanding Security Auditing

Security auditing is the act of recording security-relevant events as they occur on the system. Security-relevant events are divided into a number of categories called event classes.

By default, the system enables security auditing when you install or upgrade your system for the events shown in Table 20-7.

Table 20-7 Event Classes Audited by Default
Class | Description
--- | ---
ACL | Access to any object holding a security Auditing ACE.
AUDIT | All uses of the SET AUDIT command. You cannot disable this category.
AUTHORIZATION | All changes to the authorization database: System user authorization file (SYSUAF) Network proxy authorization files: NETPROXY and NET$PROXY Rights database (RIGHTSLIST)
BREAKIN | All break-in attempts: batch, detached, dialup, local, network, remote.
LOGFAILURE | All login failures: batch, dialup, local, remote, network, subprocess, detached.

If the security requirements at your site justify additional auditing, you can enable security auditing for other event classes by using the DCL command SET AUDIT, as explained in Section 20.7.4.

#### 20.7.1.1 Security Audit Log File

The audit server process, which is created at system startup, records the events that are shown in Table 20-7 in the security audit log file, SYS$MANAGER:SECURITY.AUDIT$JOURNAL.

The usefulness of the security audit log file depends upon the procedures you adopt to review the file on a regular basis. For example, you might implement the following procedure as part of your site audit review policy:

1. Create a new version of the security audit log file each morning.
2. Review the previous version of the log file for suspicious system activity. Depending on the number of security events you are auditing on your system, it might be impractical to review every audit record written to the audit log file. In that case, you might want to select a specific set of records from the log file (for example, all Authorization and Breakin records, or all events created outside normal business hours).
3. If, during your review, you find any security events that appear suspicious, perform a more detailed inspection of the security audit log file, as described in the OpenVMS Guide to System Security.

#### 20.7.1.2 Audit Log Files in Mixed-Version Clusters

The Audit Analysis utility (ANALYZE/AUDIT) running on earlier-version systems is unable to process the current version of audit log files. You must use the current version of ANALYZE/AUDIT to process the current version of the audit log files. The recommended procedure is to maintain separate audit log files on mixed-version clusters.

If redirecting the audit log files, issue the following command on both the earlier-version node and on the node running the current version:

    AUDIT/JOURNAL/DESTINATION=filespec

The destination filespec is stored in the audit server database file. By default, the files are stored in SYS$COMMON:[SYSMGR] and are called SECURITY_AUDIT.AUDIT$JOURNAL and SECURITY.AUDIT$JOURNAL, respectively.

The operating system allows workstations and other users with limited management resources to duplicate their audit log files on another node. The secondary log, a security archive file, is then available to a security administrator on a remote node who has the skills to analyze the file.

Each node in a cluster must have its own archive file. An archive file cannot be shared by multiple nodes in a cluster.

Refer to the OpenVMS Guide to System Security for more information.

### 20.7.2 Displaying Security Auditing Information

To see which event classes your site currently audits, you can enter the DCL command SHOW AUDIT.

The follow example contains security information:

    $ SHOW AUDIT

    System security alarms currently enabled for:
      ACL
      Breakin:       dialup,local,remote,network,detached
      Privilege use:
        SECURITY
      Privilege failure:
        SECURITY

    System security audits currently enabled for:
      ACL
      Authorization
      Breakin:       dialup,local,remote,network,detached
      Login:         dialup,local,remote,network,detached
      Logfailure:    batch,dialup,local,remote,network,subprocess,detached
      Logout:        dialup,local,remote,network,detached
      Privilege use:
        SECURITY
      Privilege failure:
        ACNT      ALLSPOOL  ALTPRI    AUDIT     BUGCHK    BYPASS    CMEXEC    CMKRNL
        DETACH    DIAGNOSE  EXQUOTA   GROUP     GRPNAM    GRPPRV    LOG_IO    MOUNT
        NETMBX    OPER      PFNMAP    PHY_IO    PRMCEB    PRMGBL    PRMMBX    PSWAPM
        READALL   SECURITY  SETPRV    SHARE     SHMEM     SYSGBL    SYSLCK    SYSNAM
        SYSPRV    TMPMBX    VOLPRO    WORLD
      DEVICE access:
        Failure:     read,write,physical,logical,control
      FILE access:
        Failure:     read,write,execute,delete,control
      VOLUME access:
        Failure:     read,write,create,delete,control

Previous | Next | Contents | Index

| privacy and legal statement |
6017PRO_086.HTML