Audit Server in 2-Node Cluster, Two Security.Audit$server files

[Jim Geier_1]

On a homogeneous cluster running OpenVMS Alpha V7.3-1 with one system disk and two AlphaServer ES40 systems, there are two Security.Audit$Server files in the Sys$Manager directory. One file each is accessed by the AUDIT_SERVER process on each system.

All other clustered systems to which I have access are running OpenVMS Alpha V7.3-2 or newer, and have one Security.Audit$Server file accessed by all AUDIT_SERVER processes in the cluster. Therefore I cannot make a direct comparison.

Should there only be one Security.Audit$Server file in the OpenVMS 7.3-1 cluster? If so, how do I get the Audit_Server processes back to referencing the same file?

[Bill Hall]

Jim,

I believe the default and recommendation is to have a common audit journal in the cluster. The audit server processes in the cluster are supposed to be communicating with each other so that if you change the journal file, they are all aware of it.

I would verify you really have different journal files and then determine why. If they are different, I would expect a logical name problem.

Check to see if you have the VMS$AUDIT_SERVER logical name defined on your cluster nodes and note the value. It should be defined the same on all cluster members and point to a cluster common device, directory and file. Show your current journal file name and destination on each cluster member with a $show audit/journal. If they are all the same do a $directory/file on the VMS$AUDIT_SERVER.DAT (or the file pointed to by the VMS$AUDIT_SERVER logical) and the journal file itself. Are the file ids unique on each system or are they the same?

Bill

[Volker Halle]

Jim,

in OpenVMS there is no Security.Audit$Server file. Are you talking about SYS$MANAGER:SECURITY.AUDIT$JOURNAL ?

This file should be in SYS$COMMON:[SYSMGR] on the system disk (by default) and should be used by all the AUDIT_SERVER processes in the cluster (SHOW AUDIT/JOURNAL). The location of this file is stored in VMS$AUDIT_SERVER.DAT, which should also be in SYS$COMMON:[SYSMGR].

In an homogeneous cluster, these files should all be centralized and shared.

Volker.

[Jim Geier_1]

I stand corrected, The files are indeed SECURITY.AUDIT$JOURNAL. There are two separate and distinct files, both in the sys$common:[sysmgr] directory.

Directory SYS$COMMON:[SYSMGR]
SECURITY.AUDIT$JOURNAL;47 27/105501 21-NOV-2006 15:04:07.64
SECURITY.AUDIT$JOURNAL;46 56/110400 21-NOV-2006 15:02:23.81

Searching through the output from SHOW DEVICE/FILES reveals that one of the files is open by the AUDIT_SERVER process on one system and the other file is open by the AUDIT_SERVER process on the other system.

The logical name VMS$AUDIT_SERVER is not defined on either system.

The output from SHOW AUDIT/JOURNAL is the same on both systems, with the "Destination" being SYS$COMMON:[SYSMGR]SECURITY.AUDIT$JOURNAL.

There is one VMS$AUDIT_SERVER.DAT file in the SYS$COMMON:[SYSMGR] directory, and thus the file-id is the same on both systems. Searching the output from SHOW DEVICE/FILES reveals that the AUDIT_SERVER process on both systems has that same file open.

Volker, I agree that because this is a homogeneous cluster with one system disk and no apparent creative use of logical names that there should be one VMS$AUDIT_SERVER.DAT file and one SECURITY.AUDIT$JOURNAL file for the cluster both in the common SYSMGR directory. There should be. That does not answer the question which is how do I get this cluster to be in that state when there are two SECURITY.AUDIT$JOURNAL files?

[EdgarZamora]

I'm not sure how you got into that state so this is just speculation. Someone might have done the command SET AUDIT/SERV=CREATE which would create a new file for the node where it was executed from. I'm not sure if this will work but why not try a SET AUDIT/SERV=NEW from one of your nodes. That should create a new file for all nodes in the cluster.

[Bill Hall]

Jim,

Now you can issue a $set audit/server=new_log command on one node of the cluster. A new version of the journal file will be created and both systems should begin writing to the new file.

Bill

[Jim Geier_1]

Sorry to say this, but been there, done that ... I issued the command SET AUDIT/SERVER=NEW_LOG on each system yesterday, and each system created a new version of the file. If you look at my previous entry, the dates of the files are November 21 at about 3:00 PM. Good idea, but I do not think this is the solution, since it already did not work. I'll be happy to try it again, though, but I suspect the same results will occur.

Also, I do not believe the command SET AUDIT/SERVER=CREATE was used to cause the problem. This is a system with all captive users and one system manager (me). I noticed the two files after a cluster reboot on October 14. My attempt to fix the problem was the set adit/server=new_log command, and that did not work. Any other ideas?

[EdgarZamora]

I suspected you might have a deeper problem than that and that's why I was unsure that the SET AUD/SERV=NEW would work.

Have you looked through your startup logs from the last reboot to see if there were any unusual things that went on?

What about trying to restart the Audit server of the node that has the lower version of the file open? On that node I would do a SET AUDIT/SERV=EXIT then @SYS$SYSTEM:STARTUP AUDIT_SERVER. See if that node then uses the same version of the file as the other node, or if it creates a new file. Good luck!

[Bill Hall]

Jim,

Did you stop and restart the audit servers on both nodes? Execute $set audit/server=exit on both systems to shutdown the audit servers. After they are both down, restart them one at a time using $@SYS$SYSTEM:STARTUP AUDIT_SERVER.

If that doesn't resolve the problem, I'd have to guess there must be a communication problem between the nodes. I'm not sure if signaling is done through the VMS$AUDIT_SERVER.DAT file or ICC and/or a combination???

Bill

[Bill Hall · Accepted solution]

Jim,

Do you have ECO VMS731_AUDSRV-V0200 installed on this cluster? Check out the release notes at http://www2.itrc.hp.com/service/patch/patchDetail.do?patchid=VMS731_AUDSRV-V0200&sel={openvms:alpha:7.3-1,}&BC=main|search|

The release notes might be describing what you are seeing.

Bill

[Ian Miller.]

Here is a direct pointer to that patch kit which does sound relevant.

ftp://ftp.itrc.hp.com/openvms_patches/alpha/V7.3-1/VMS731_AUDSRV-V0200.txt
ftp://ftp.itrc.hp.com/openvms_patches/alpha/V7.3-1/VMS731_AUDSRV-V0200.PCSI-DCX_AXPEXE

[Jim Geier_1]

After installing the VMS731_AUDSRV-V0200 patch kit and restarting the Audit Server on both systems, they now share one file.