restarting the SECURITY.AUDIT$JOURNAL file

[Alon Jacob]

Hello all.
That file has grown to a huge size of 2Gb on one of our servers, and I need to ask a few things :
1. What command do I use to restart the file?
2. Can I limit the size of the file using some sysgen param? if so - what happens when it gets to that limit - will it cycle?

Thanks.

[Karl Rohwedder]

Alon,

HELP SET AUDIT is your friend. A new file
is created with SET AUDIT /SERVER=NEW_LOG.

I know of now ways to limits the logfile size directly, but you may check the audit events your are logging, if all of them are needed (SHOW AUDIT).

The auditserver monitors the remaining space on the target disk. With SET AUDIT you can specify some limits, on which the auditserver reacts with some actions (can also be specified).
With this mechanism you are able to somewhat limit the impact.

mfg kalle

[Mobeen_1]

Alon,
I concur with Roheder.. i don't know of any way the security audit log file size could be limited. It behaves and responds just the way the Operator.log does.

The way to create a new log file is

$SET AUDIT/SERVER=NEW_LOG

Look at the help for the above command, i might be just about wrong and there might be some way to have a limitatin using a qualifier

/THRESHOLD

regards
Mobeen

[Wim Van den Wyngaert]

We check the size of the file each night and when it is bigger that x, we open a new one.

Wim

[Ian Miller.]

I would recommend starting a new one at a regular interval e.g daily, weekly or whatever fits. You should bear in mind your backup schedule (when tapes are reused) as to when you delete the previous log incase you need to go back to earlier logs. After starting a new log then renaming the old one with a name based on the date is a good idea - a name that results in files in a sensible order in directory list.
This also applies to other vms log files such as operator log, accounting, error log and so on.

[Jan van den Ende]

Alon,

your needs may vary, of course, but we create a new logfile every day, by a batchqueue running a few seconds after midnight. After the re-create we rename the old one to a version .-
(in COMPARISON format).
Those are kept online for two months, accessible to security people, after which they are archived offline.

Obviously, we do have security audit needs!.

Proost.

Have one on me.

Jan

[Wim Van den Wyngaert]

Note that changing log file complicates queries. You have to specify all the files in the anal/aud command.

Wim

[Jan van den Ende]

Wim,

that is only relative.

If you KNOW the date of interest, searching a small file is great with respect to performance; if not, wildxards are supported.
To me, much more advantages then disadvantages, but of course, your needs may vary.

Proost.

Have one on me.

Jan

[John Gillings]

re Jan:

>we create a new logfile every day, by
>a batchqueue running a few seconds
>after midnight. After the re-create
>we rename the old one to a
>version .-

Be careful!

The SET AUDIT/SERVER=NEW sends a request to AUDIT_SERVER to perform the roll over, which means the command is asynchronous. SET AUDIT may return BEFORE the file has actually rolled over (especially in a cluster). If you rename the *active* journal file, very strange and odd things can happen! You also need to make absolutely certain that all members of the cluster share a physical VMS$OBJECTS file and agree on the location of the audit journal.

The "normal" configuration is a cluster common journal file, so the SET AUDIT/SERVER=NEW should be done on ONE node only. However, it is possible to configure node specific journal files (not recommended), in which case you need to roll them over on each node.

Here's a DCL fragment I use to make sure the journal file has rolled over before attempting to archive the old one:


$ j="COMMON$LOGS:SECURITY.AUDIT$JOURNAL"
$ ArchiveFile=F$SEARCH(j)
$ SET AUDIT/SERVER=NEW_LOG
$!
$! Wait for new file to be created before archiving the old one
$ aud_loop: WAIT 00:00:01.00
$ NewFile=F$SEARCH(j)
$ IF NewFile.EQS.ArchiveFile THEN GOTO aud_loop
$ @CLUSTER$FILES:ARCHIVE_OLD_VERSIONS -
'NewFile' COMMON$ARCHIVE:
$!

Similar code should be used when rolling over all other logs and journal files, especially in a cluster.

[Jan van den Ende]

John,

thanks for the details.

Yes, we do this only once clusterwide.
We do an F$SEARCH for version -1 of
the file, and only operate on that. If not found, MAIL is sent to the system managers.
.. and should the rename somehow have failed yesterday, we re-evaluate -1 and rename any extra find as well. I do not remember any MAIL from recent years, but obviously we had some reasons to put in the signalling (procedure date 1995).

As per your remark, I added an extra WAIT 0:0:5 after SET AUD, before the rename logic, if only just for robustness. Thanks.

Proost.

Have one on me.

Jan

[Alon Jacob]

.