Difference between revisions of "HowTos/Using the Audit logging"
Line 216: | Line 216: | ||
An example of the Router logging at level 11: | An example of the Router logging at level 11: | ||
− | |||
routing | routing | ||
Line 241: | Line 240: | ||
part-count 2 | part-count 2 | ||
delivered-count 1 | delivered-count 1 | ||
+ | |||
+ | An example of a person signing-off: | ||
+ | |||
+ | user-signoff | ||
+ | time 970243413 Fri Sep 29 17:03:33 2000 +60 | ||
+ | user 101 Mr Admin/kuda,training | ||
+ | duration 6 | ||
+ | signoff-status 0 | ||
+ | |||
+ | '''Analyzing Audit Log Output''' | ||
+ | |||
+ | By default, all audit logs are written to the file ~/logs/audit and this is a simple | ||
+ | text file. You can change this behaviour by editing audit.cfg so that various parts output to | ||
+ | different files - it depends on how you intend to work with it. If you intend to write scripts to | ||
+ | take this output you might find it easier to work with one file or with many files. It’s up to you. | ||
+ | But, assuming the default where everything is writing to is ~/logs/audit, this makes it a | ||
+ | great real-time troubleshooting tool. You can set up your audit logging levels and then set up a | ||
+ | window that is doing a tail -f on the ~/logs/audit file. Now when you send your test | ||
+ | message you see it actually logging in the audit log as it happens. | ||
+ | This can be very good when trying to troubleshoot gateway problems, where you want to see if | ||
+ | the message was actually sent from Scalix (or received). Also, for Directory or Bulletin- | ||
+ | Board synchronisation, this is very useful, as you can see messages going out/in the system(s). | ||
+ | |||
+ | '''Age the Scalix audit log''' | ||
+ | |||
+ | The Scalix audit log (/var/opt/scalix/logs/audit) should be aged on a daily basis. Use basic Linux scripting to roll the | ||
+ | logs. | ||
+ | |||
+ | Example: | ||
+ | |||
+ | AUDFIL=/var/opt/scalix/*/s/logs/audit | ||
+ | DAY=`date '+%a'` | ||
+ | SAVFIL="$AUDFIL.$DAY" | ||
+ | rm -f $SAVFIL 2>&1 >> $MAINTLOG | ||
+ | mv -f $AUDFIL $SAVFIL 2>&1 >> $MAINTLOG | ||
+ | touch $AUDFIL 2>&1 >> $MAINTLOG | ||
+ | chown Scalix $AUDFIL 2>&1 >> $MAINTLOG | ||
+ | chgrp sxoffice $AUDFIL 2>&1 >> $MAINTLOG | ||
+ | chmod 660 $AUDFIL 2>&1 >> $MAINTLOG | ||
+ | |||
+ | This is part from sxmaint(/opt/scalix/bin) and it should be used for frequent, daily and weekly maintenance. | ||
+ | |||
+ | You typically cron this to run as follows: | ||
+ | |||
+ | |||
+ | minute hour monthday month weekday command | ||
+ | 00,30 * * * * /opt/scalix/bin/sxmaint -frequent | ||
+ | 01 0 * * * /opt/scalix/bin/sxmaint -daily | ||
+ | 15 2 * * 0 /opt/scalix/bin/sxmaint -weekly | ||
+ | |||
+ | Exactly when you run everything doesn't matter. Frequent is for frequentops such as checking for aborted queues or other errors. Daily empties the users' wastebaskets, rolls the audit logs, and does backups. Weekly runs omscan. You might be able to throw omscan in the daily part if you have a small installation. |
Revision as of 16:13, 19 May 2009
Introduction
Audit level logging was originally implemented so that Scalix administrators could extract accounting information. They could determine how often people were logging on, for how long, etc., in order to bill for connection time. The actual output of the Audit logs is pretty basic, but there are already a number of people who have written scripts to take this output and produce PC-format files that can be fed into graphics packages to produce lovely statistics of message pass-through rates etc..
Although originally written with accounting in mind, Audit logging should not be overlooked as a debugging/troubleshooting tool. Indeed, you should consider using Audit logging as your first mechanism when trying to see what’s happening on the system.
Overview
The whole audit logging setup is configured through the file:
/var/opt/scalix/*/s/sys/audit.cfg
In this file, you specify what activities are logged and for what Audit level they are logged.
The commands for setting up Audit level logging are:
• omshowaud - to show the current settings
• omconfaud - to configure the settings
You can enable Audit logging on the various parts of Scalix. To see the complete list,
simply issue an omshowaud:
$ omshowaud
Service Router 0
Local Delivery 0
Internet Mail Gateway 0
Local Client Interface 0
Remote Client Interface 0
Administration 0
Request Server 0
Directory Synchronization 0
Bulletin Board Server 0
Lotus Notes Interface 0
SMS Gateway 0
Background Search Service 0
By default, everything is turned off! To see what information you get at the various levels you
must look at the audit.cfg file.
audit.cfg
The entries in this file are grouped for each part of Scalix that knows about Audit logging.
The first trick is working out the mapping between the part number within this audit.cfg file and the part name as specified in the omconfaud command.
The section commented as service router is pretty obvious, but how can you tell which sections relate to Remote Client Interface? When you look in the audit.cfg file you do not see any section called Remote Client Interface...you see sections called user-signon and user-signoff. Indeed this had confused people for so long that in B.04 we added an extra file audit.map which shows these mappings.
It looks something like this:
'$ cat ~scalix/*/s/sys/audit.map # # This file maps entries in ~/sys/audit.cfg (1st col) to services (2nd col) # 1 2 # ’routing’ to Service Router 2 11 # ’omscan’ to Administration 3 8 # ’user-signon’ to Local Client Interface 3 9 # ’user-signon’ to Remote Client Interface 4 8 # ’user-signoff’ to Local Client Interface 4 9 # ’user-signoff’ to Remote Client Interface 4 25 # ’user-signoff’ to P7 Client Interface 5 11 # ’subsystem-start’ to Administration 6 11 # ’subsystem-stop’ to Administration 7 16 # ’fax’ to Fax Gateway 8 3 # ’delivery’ to Local Delivery 9 18 # ’request’ to Request Server 10 4 # ’unix-in’ to Unix Mail Gateway 11 4 # ’unix-out’ to Unix Mail Gateway 12 6 # ’desk-in’ to HPDesk Gateway 13 6 # ’desk-out’ to HPDesk Gateway 14 5 # ’x400-in’ to X400 Interface 15 5 # ’x400-out’ to X400 Interface 16 24 # ’dirsync-in’ to Directory Synchronization 17 24 # ’dirsync-out’ to Directory Synchronization 18 26 # ’bulletin’ to Bulletin Board Server 19 29 # ’sms-out’ to SMS Gateway 20 29 # ’sms-in’ to SMS Gateway'
The next trick is to understand what parts of the audit.cfg file you can change and what parts are fixed:
The file format is as follows:
# service router <----------------- Descriptive comment % 1 routing ~/logs/audit <-------- output file name 1 time 1 2 type 5 3 ua-message-id 1 4 ua-ack-id 3 <-------- The audit level that produces this output The four in front of ua-ack-id is The Unique ID ua-ack-id= Text to be output
You can change:
• The text to be output
• The output file name
• The Audit level that produces this output
...that’s all!
As an example of the kind of things you can set up, here’s an extract of the audit.cfg file:
#Default audit.cfg configuration file.Only the audit log filenames and the #audit logging levels (the last number on each line) are administrator- #configurable. Use omconfaud for normal audit configuration. # # Do not localise this file. Localise the scripts that read the audit log # file instead. # # Field names should be less than 30 characters long. # service router % 1 routing ~/logs/audit 1 time 1 2 type 5 3 ua-message-id 1 4 ua-ack-id 3 5 mta-message-id 1 6 mta-ack-id 3 10 subject 11 20 sensitivity 7 21 priority 7 22 importance 7 23 created-locally 7 30 originator 9 35 designate-originator 9 40 part-type 11 41 part-size 11 42 message-size 5 43 part-count 11 45 hop-count 7 50 recipient-from 9 51 recipient-to 9 52 recipient-cc 9 53 recipient-bcc 9 60 ack-req 7 61 message-filter-info 9 70 queue 9 80 delivered-count 7 91 orig-recip 7 92 new-recip 7 95 non-delivery-reason 7 96 all-recips-non-deliv 7 98 max-nest-depth 11 # omscan % 2 omscan ~/logs/audit 1 time 1 10 user 5 20 tray 7 30 user-messages 7 40 user-size 5 70 bb-area-messages 3 80 bb-area-size 3 90 duration 9 # user-agent signon % 3 user-signon ~/logs/audit 1 time 1 10 user-agent-id 7 20 user 1 22 designate-user 1 25 client-type 9 30 signon-status 1 # user-agent signoff % 4 user-signoff ~/logs/audit 1 time 1 10 user 1 12 designate-user 1 20 duration 7 30 signoff-status 5 ...
Example Output
Here is an example of a person signing on:
user-signon time 970243407 Fri Sep 29 17:03:27 2000 +60 user-agent-id Windows Client Version B.06.00.00 client-type 1 hp-client user 101 Mr Admin/kuda,training 1000 1000 signon-status 0
An example of the Router logging at level 11:
routing time 970243505 Fri Sep 29 17:05:05 2000 +60 type 0 message priority 0 normal sensitivity 0 normal importance 0 normal created-locally 1 hop-count 1 originator Mr Admin / kuda, training subject a test msg ua-message-id H0000065000013a3.0970243485.kuda.pwd.hp.com mta-message-id H0000065000013a3.0970243485.kuda.pwd.hp.com part-size 132 part-type 1166 DISTRIBUTION LIST part-size 9 part-type 1167 TEXT recipient-to Mr Normal / kuda, training ack-req 0 none queue LOCAL max-nest-depth 0 message-size 750 part-count 2 delivered-count 1
An example of a person signing-off:
user-signoff time 970243413 Fri Sep 29 17:03:33 2000 +60 user 101 Mr Admin/kuda,training duration 6 signoff-status 0
Analyzing Audit Log Output
By default, all audit logs are written to the file ~/logs/audit and this is a simple text file. You can change this behaviour by editing audit.cfg so that various parts output to different files - it depends on how you intend to work with it. If you intend to write scripts to take this output you might find it easier to work with one file or with many files. It’s up to you. But, assuming the default where everything is writing to is ~/logs/audit, this makes it a great real-time troubleshooting tool. You can set up your audit logging levels and then set up a window that is doing a tail -f on the ~/logs/audit file. Now when you send your test message you see it actually logging in the audit log as it happens. This can be very good when trying to troubleshoot gateway problems, where you want to see if the message was actually sent from Scalix (or received). Also, for Directory or Bulletin- Board synchronisation, this is very useful, as you can see messages going out/in the system(s).
Age the Scalix audit log
The Scalix audit log (/var/opt/scalix/logs/audit) should be aged on a daily basis. Use basic Linux scripting to roll the logs.
Example:
AUDFIL=/var/opt/scalix/*/s/logs/audit DAY=`date '+%a'` SAVFIL="$AUDFIL.$DAY" rm -f $SAVFIL 2>&1 >> $MAINTLOG mv -f $AUDFIL $SAVFIL 2>&1 >> $MAINTLOG touch $AUDFIL 2>&1 >> $MAINTLOG chown Scalix $AUDFIL 2>&1 >> $MAINTLOG chgrp sxoffice $AUDFIL 2>&1 >> $MAINTLOG chmod 660 $AUDFIL 2>&1 >> $MAINTLOG
This is part from sxmaint(/opt/scalix/bin) and it should be used for frequent, daily and weekly maintenance.
You typically cron this to run as follows:
minute hour monthday month weekday command 00,30 * * * * /opt/scalix/bin/sxmaint -frequent 01 0 * * * /opt/scalix/bin/sxmaint -daily 15 2 * * 0 /opt/scalix/bin/sxmaint -weekly
Exactly when you run everything doesn't matter. Frequent is for frequentops such as checking for aborted queues or other errors. Daily empties the users' wastebaskets, rolls the audit logs, and does backups. Weekly runs omscan. You might be able to throw omscan in the daily part if you have a small installation.