Next: Console Configuration Up: Main Reference Previous: Storage Daemon Configuration Contents Index
The Messages resource defines how messages are to be handled and destinations to which they should be sent.
Even though each daemon has a full message handler, within the File daemon and the Storage daemon, you will normally choose to send all the appropriate messages back to the Director. This permits all the messages associated with a single Job to be combined in the Director and sent as a single email message to the user, or logged together in a single file.
Each message that Bacula generates (i.e. that each daemon generates) has an associated type such as INFO, WARNING, ERROR, FATAL, etc. Using the message resource, you can specify which message types you wish to see and where they should be sent. In addition, a message may be sent to multiple destinations. For example, you may want all error messages both logged as well as sent to you in an email. By defining multiple messages resources, you can have different message handling for each type of Job (e.g. Full backups versus Incremental backups).
In general, messages are attached to a Job and are included in the Job report. There are some rare cases, where this is not possible, e.g. when no job is running, or if a communications error occurs between a daemon and the director. In those cases, the message may remain in the system, and should be flushed at the end of the next Job. However, since such messages are not attached to a Job, any that are mailed will be sent to /usr/lib/sendmail. On some systems, such as FreeBSD, if your sendmail is in a different place, you may want to link it to the the above location.
The records contained in a Messages resource consist of a destination specification followed by a list of message-types in the format:
or for those destinations that need and address specification (e.g. email):
Where destination is one of a predefined set of keywords that define where the message is to be sent (stdout, file, ...), message-type is one of a predefined set of keywords that define the type of message generated by Bacula (ERROR, WARNING, FATAL, ...), and address varies according to the destination keyword, but is typically an email address or a filename.
The following are the list of the possible record definitions that can be used in a message resource.
mail -s "Bacula Message" recipients
In many cases, depending on your machine, this command may not work. However, by using the MailCommand, you can specify exactly how to send the mail. During the processing of the command part, normally specified as a quoted string, the following substitutions will be used:
%% = %
%b = Job Bytes
%c = Client's name
%d = Daemon's name (Such as host-dir or host-fd)
%D = Director's name (Also valid on file daemon)
%e = Job Exit Status
%f = Job FileSet (Only on director side)
%F = Job Files
%h = Client address
%i = JobId
%j = Unique Job id
%l = Job Level
%n = Job name
%p = Pool name (Only on director side)
%P = Current PID process
%r = Recipients
%s = Since time
%t = Job type (Backup, ...)
%v = Volume name (Only on director side)
%w = Storage name (Only on director side)
%x = Spooling enabled? ("yes" or "no")
Please note: any MailCommand directive must be specified in the Messages resource before the desired Mail, MailOnSuccess, or MailOnError directive. In fact, each of those directives may be preceded by a different MailCommand.
The following is an exampl. Note, the whole command should appear on a single line in the configuration file rather than split as is done here for presentation:
mailcommand = "/home/kern/bacula/bin/bsmtp -h mail.example.com -f \"\(Bacula\) %r\" -s \"Bacula: %t %e of %c %l\" %r"
The bsmtp program is provided as part of Bacula. For additional details, please see the bsmtp – Customizing Your Email Messagesbsmtputilitysection of the Bacula Utility Programs chapter of this manual. Please test any mailcommand that you use to ensure that your bsmtp gateway accepts the addressing form that you use. Certain programs such as Exim can be very selective as to what forms are permitted particularly in the from part.
Where destination may be one of the following:
Where address depends on the destination.
The destination may be one of the following:
syslog = all, !skipped
Although the syslog destination is not used in the default Bacula config files, in certain cases where Bacula encounters errors in trying to deliver a message, as a last resort, it will send it to the system syslog to prevent loss of the message, so you might occassionally check the syslog for Bacula output (normally /var/log/syslog).
For any destination, the message-type field is a comma separated list of the following types or classes of messages:
The following is an example of a valid Messages resource definition, where all messages except files explicitly skipped or daemon termination messages are sent by email to enforcement@sec.com. In addition all mount messages are sent to the operator (i.e. emailed to enforcement@sec.com). Finally all messages other than explicitly skipped files and files saved are sent to the console:
Messages {
Name = Standard
mail = enforcement@sec.com = all, !skipped, !terminate
operator = enforcement@sec.com = mount
console = all, !skipped, !saved
}
With the exception of the email address (changed to avoid junk mail from robot's), an example Director's Messages resource is as follows. Note, the mailcommand and operatorcommand are on a single line – they had to be split for this manual:
Messages {
Name = Standard
mailcommand = "bacula/bin/bsmtp -h mail.example.com \
-f \"\(Bacula\) %r\" -s \"Bacula: %t %e of %c %l\" %r"
operatorcommand = "bacula/bin/bsmtp -h mail.example.com \
-f \"\(Bacula\) %r\" -s \"Bacula: Intervention needed \
for %j\" %r"
MailOnError = security@example.com = all, !skipped, \
!terminate
append = "bacula/bin/log" = all, !skipped, !terminate
operator = security@example.com = mount
console = all, !skipped, !saved
}