HowTos/Using the Audit logging

From Scalix Wiki
Revision as of 16:26, 19 May 2009 by Greg (Talk | contribs)

Jump to: navigation, search

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