HP OpenVMS Systems Documentation

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

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

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.

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.

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

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

 %%%%%%%%%%%  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

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)

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.

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

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.

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.

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.

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