Auditing
During the day to day operation of
- 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
- 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
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
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:
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
The sync service is implemented as a background load and is controlled by the