%SHOW-W-NOAUDITING, security auditing disabled; no events will be logge

[Clark Powell]

After getting this message at the end of the SHOW AUDIT display (shown below) we have come to conclusion that the file VMS$AUDIT_SERVER.DAT can be located in different locations using the logical, VMS$AUDIT_SERVER, but that doesn't mean that it can be shared by a cluster. That is, every node must have it's own VMS$AUDIT_SERVER.DAT. We have our logical pointing to the same spot on both nodes and the audit server only runs and collects data on the first node to start. Does anyone agree with this or have a different idea of what our audit server problem might be?

$ show audit
System security alarms currently enabled for:
ACL
Authorization
Audit: illformed
Breakin: dialup,local,remote,network,detached
Logfailure: batch,dialup,local,subprocess,detached

System security audits currently enabled for:
ACL
Authorization
SYSGEN
Audit: illformed
Breakin: dialup,local,remote,network,detached
Logfailure: batch,dialup,local,remote,network,subprocess,detached
Privilege use:
OPER

%SHOW-W-NOAUDITING, security auditing disabled; no events will be logged

thanks,
Clark Powell

[Jon Pinkley]

what does show audit/all say at the top?

[Jon Pinkley]

As far as VMS$AUDIT_SERVER.DAT, we have a 2 node cluster running Alpha VMS 7.3-2 from a common system disk. We do not have VMS$AUDIT_SERVER defined as a logical name.

The file is in our sys$common:[sysmgr] directory, and it is shared by both nodes.

This is a realatively small file, it has the audit settings in it, not the audit records.

What version(s) of VMS are in your cluster?

I am not sure, but I think this information needs to be the same on all cluster nodes, i.e. I don't believe it is possible to have different items audited on different nodes, although I have never tried puting the VMS$AUDIT_SERVER.DAT file in a system specific location.

Jon

[Jon Pinkley]

Please look at sys$manager:sylogicals.template.

This has a list of the "Site-specific VMScluster core file definitions" that should be the same for all memebers of the cluster.

The intent is that VMS$AUDIT_SERVER be one file that is shared by all cluster nodes.

Where are you defining VMS$AUDIT_SERVER? It needs to be defined before the audit server starts. SYS$MANAGER:SYLOGICALS.COM is the normal place where it would be defined.

I am attaching an extract from sys$manager:sylogicals.com on an Alpha VMS 8.3 system.

Jon

[Karl Rohwedder]

Perhaps someone defined SYS$AUDIT_SERVER_INHIBIT? Check with SHOW LOGICAL.

regards Kalle

[Wim Van den Wyngaert]

We have a cluster with 2 system disks and 1 shared SAN disk with the common data. We did set aud/dest= to define a common audit file. No problem yet after 6 years.

Wim

[Wim Van den Wyngaert]

BTW : our vms$audit_server.dat is on each system disk. It's our responsibility to keep the setting on both nodes the same.

Wim

[Wim Van den Wyngaert]

Just tried to use a common file in a test. No problem at all (7.3).
1) did you define the logical on both nodes
2) did you restart audit_server on both nodes
3) is the destination as shown in show aud/all seen by both nodes >
4) nothing in the operator log file/accounting ?

Wim

Wim

[Clark Powell]

MORE BACKGROUND:
I have been so uniform in screwing up the audit server on both our Cert and Prod clusters that they have exactly same problem. In each cluster (alpha 8.3 almost all patches) there are two nodes, two separate system disk, logical VMS$AUDIT_SERVER defined on both nodes, logical SYS$AUDIT_SERVER_INHIBIT not defined, (see below,) At boot audit server does not start on both nodes. Here on our Cert cluster you can see what it looks like
right after boot with ALPHAX not running the audit server:
SYSMAN> DO SHO AUDIT
%SYSMAN-I-OUTPUT, command execution on node ALPHAZ
System security alarms currently enabled for:
ACL
Authorization
Audit: illformed
Breakin: dialup,local,remote,network,detached
System security audits currently enabled for:
ACL
Authorization
SYSGEN
Audit: illformed
Breakin: dialup,local,remote,network,detached
Logfailure: batch,dialup,local,remote,network,subprocess,detached
Privilege use:
OPER
%SYSMAN-I-OUTPUT, command execution on node ALPHAX
System security alarms currently disabled
System security audits currently disabled
%SHOW-W-NOAUDSRV, AUDIT_SERVER process not running; use "SET AUDIT/SERVER=START"
to start
%SHOW-W-NOAUDITING, security auditing disabled; no events will be logged

But after executing the SET AUDIT/SERVER=START we get what you see below.

To answer the second respondent on production cluster. I checked this command on both nodes and except for the SHOW-W-NOAUDITING error message the output is the same.

ALPHAC> sho audit/all
List of audit journals:
Journal name: SECURITY
Journal owner: (system audit journal)
Destination: SYS$COMMON:[SYSMGR]SECURITY.AUDIT$JOURNAL
Monitoring: enabled
Warning thresholds, Block count: 100 Duration: 2 00:00:00.0
Action thresholds, Block count: 25 Duration: 0 00:30:00.0

Security auditing server characteristics:
Database version: 4.4
Backlog (total): 100, 200, 700
Backlog (process): 5, 2
Server processing intervals:
Archive flush: 0 00:01:00.00
Journal flush: 0 00:05:00.00
Resource scan: 0 00:05:00.00
Final resource action: purge oldest audit events

Security archiving information:
Archiving events: none
Archive destination:

System security alarms currently enabled for:
ACL
Authorization
Audit: illformed
Breakin: dialup,local,remote,network,detached
Logfailure: batch,dialup,local,subprocess,detached

System security audits currently enabled for:
ACL
Authorization
SYSGEN
Audit: illformed
Breakin: dialup,local,remote,network,detached
Logfailure: batch,dialup,local,remote,network,subprocess,detached
Privilege use:
OPER

%SHOW-W-NOAUDITING, security auditing disabled; no events will be logged
ALPHAC>

thanks for helping!
Clark Powell

[Hoff]

You

*must*

set up the logical names per

SYLOGICALS.TEMPLATE

in an OpenVMS cluster.

Yes, OpenVMS might

*appear*

to work if you don't have all the right logical names and the files configured and shared (or -- in the case of a multiple-SYSUAF cluster -- carefully synchronized), but weirdness then tends to ensue.

I'm the perpetrator of that list of logical names, and I implemented that specifically because folks with multiple system disks inevitably got it wrong. (Until I put that list together, *I* got it wrong.) And weirdness ensued. Multiple system disk configurations are particularly prone to weirdnesses.

For the shared files on (I assume) a shared I/O bus, make sure you have the disks mounted at the appropriate place in startup; early on. (I'm assuming a shared I/O bus is present because a two-node cluster is pretty hairy otherwise. And it's way more work.)

If you *do* have these logical names defined and the cluster configured properly (and congrats; that's not easy!), then the next step is to take a look around for audit server dump files, or for whatever is causing the audit server to tip over. DIR SYS$SYSROOT:[*...]*.DMP /SINCE or such, and check the accounting data (ACCOUNT /SINCE=last-boot-time-and-date /FULL SYS$MANAGER:ACCOUNTNG.DAT or such)