Document revision date: 19 July 1999

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

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

18.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.

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-1998 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 18.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-1998 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-1998 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

18.6.2.8 Contents of an Operator Log File

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

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

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

18.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)

18.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.

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-1998 12:28:20.11 %%%%%%%%%%% Logfile was closed by operator _MARS$VTA2: (3) Logfile was HOMER::SYS$MANAGER:[SYSMGT]OPERATOR.LOG;27 %%%%%%%%%%% OPCOM, 19-APR-1998 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.

18.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 18-6.

Table 18-6 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 18.7.4.

18.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 18-6 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.

18.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

	privacy and legal statement
6017PRO_082.HTML