Auditing

During the day to day operation of EMu there may be times when an administrator or user requires details about who changed a record, when it was changed and what changes were made. An auditing facility creates audit trails, a sequence of records that describe the operations performed by a user and the time at which the changes were made. These records generally include the:

  • operation performed (e.g. insertion, update, etc.)
  • module affected (e.g. eparties)
  • name of the user
  • date and time
  • IRN of the record affected
  • data specific to the operation performed (e.g. fields changed for an update)
  • database sub-system that performed the operation

EMu has a fully integrated auditing facility. The facility includes an Audit Trails module (eaudit), which contains complete audit trails for all operations registered for monitoring. There are five levels for which audit records may be generated:

  • change (insertions, updates, deletions)
  • search (queries)
  • display (viewed, sorted, reported)
  • login (first access of a module in current session)
  • all (all database operations)

Each of these may be set on a per module basis, which means that it is possible to monitor all changes to records in the Parties module, for instance, while Multimedia records may be audited for changes, searches and records viewed.

Every EMu module contains an Audit tab that lists all audit trail records for the current record. Each record details the operation performed, who performed it and the date on which it was performed. From this tab it is also possible to view the complete audit trail record in the Audit Trails module.

The Audit facility is extensible, which allows other services that require access to detailed information about record changes to take advantage of its framework. In particular two other services use the audit framework to monitor record modifications. The first is the archiver service, which allows raw XML audit trail records to be stored in a file. The second is the sync service, which is used to ensure that dependent records are updated when the master record is changed.

Another service that uses the auditing facility is the archiver. All XML audit records generated are passed to the archiver service to determine whether a copy should be placed in a file for archiving. The service allows administrators to keep a backup copy of all XML audit records (which can be used for reference or supplying to other software as input).

To enable the archiver service the directory logs/audit must exist on the EMu server. By default, the directory does not exist when EMu is installed and must be created by an administrator. When the directory is first created the auditing sub-system must be restarted via:

emuload stop audit

emuload start audit

All XML audit records for a day are placed in a single file under the logs/audit directory. The file name is in the form yyyy-mm-dd. Once all the entries for a day have been added, the file is compressed (with gzip) and renamed to yyyy-mm-dd.gz. To view a compressed archive file use:

gzcat yyyy-mm-dd.gz

The archiver can be disabled by either renaming the logs/audit directory or removing it. Once disabled the auditing sub-system must be restarted via:

emuload stop audit

emuload start audit

The sync service is used to ensure that all records that extract data from another record are up to date. For example, a Catalogue record may copy the Full Name field from the Parties module into the Creator's Name field for a work of art. The copy is used to allow high speed searching on the Creator's Name field in the Catalogue. If the record in the Parties module is changed so that the value of the Full Name field changes, all Catalogue records that copy in the Full Name value must be updated to the new value.

A table is maintained automatically in etc/syncmap and is used by the sync service to determine which fields need to be updated when a field is modified. In the example above the map would contain:

eparties    NamFullName    ecatalogue    CreCreatorRef_tab

This indicates that when the NamFullName field in the eparties table is changed, the CreCreatorRef_tab field in the ecatalogue table is checked to see if the value needs to be updated.

The sync service is implemented as a background load and is controlled by the emuload command. In the day to day working of the system the sync service must be running to ensure that records are always up to date.