The database may hold (i) internal message from yule, the log server, and (ii) client messages. The latter result in two rows: one for the client message, and one for the server message recording the arrival of the client message, the originating remote host, and the timestamp. The different message types can be recognized by the log_ref field (see below).
Many database fields record details of files (see man stat ), before (_old) and after (_new) a detected modification. For some items, both numeric (iXXX) and string values are reported, because the translation between both is host-specific. This allows to perform updates of the file signature database(s) on the server side. Other fields are listed below. Basically, most of the fields supply additional information for log_msg if relevant.
Unique index of the message (primary key).
Zero for internal server messages, NULL for messages received from a client, log_index(client_message) for server timestamp of client message.
The host where the message originates.
The timestamp of the message.
The severity/priority of the message.
The message itself.
A checksum over the union of user-defineable fields.
NEW for new entries. Used by the Beltane frontend to track the status of a message.
Path of a file (whenever a message refers to a file).
UID of the current user if relevant (e.g. if access to a file fails).
Name of a group (for messages reporting problems with a GID, e.g. no entry in /etc/group).
Name of the current process (startup message).
Name of an internal subroutine (in messages reporting failure of a subroutine).
Exit status value of samhain.
Checksum of configuration file (if gpg not used). Startup message.
Path and checksum of data file (if gpg not used). Startup message.
User ID and key id of GPG key used to sign the configuration file. Startup message.
User ID of GPG key used to sign the data file (different keys for configuration and data file cause program abort). Startup failure message.
Address of a connecting host.
Generic field to hold additional information. Occasionally used.
Name of a library routine/interface (error messages).
Name of a directory, if relevant.
In reports about dangling symlinks.
Port number (in reports about connections errors).
Logging facility or remote service (failure reports).