<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!--Converted with LaTeX2HTML 2008 (1.71)
original version by: Nikos Drakos, CBLU, University of Leeds
* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
* with significant contributions from:
Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
<HTML>
<HEAD>
<TITLE>Messages Resource</TITLE>
<META NAME="description" CONTENT="Messages Resource">
<META NAME="keywords" CONTENT="main">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">
<META NAME="Generator" CONTENT="LaTeX2HTML v2008">
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
<LINK REL="STYLESHEET" HREF="main.css">
<LINK REL="next" HREF="Console_Configuration.html">
<LINK REL="previous" HREF="Autochanger_Resource.html">
<LINK REL="up" HREF="Bacula_Main_Reference.html">
<LINK REL="next" HREF="Console_Configuration.html">
</HEAD>
<BODY >
<!--Navigation Panel-->
<A NAME="tex2html1538"
HREF="Console_Configuration.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A>
<A NAME="tex2html1532"
HREF="Bacula_Main_Reference.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A>
<A NAME="tex2html1526"
HREF="Autochanger_Resource.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A>
<A NAME="tex2html1534"
HREF="Contents.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A>
<A NAME="tex2html1536"
HREF="Thanks.html">
<IMG WIDTH="43" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="index" SRC="index.png"></A>
<BR>
<B> Next:</B> <A NAME="tex2html1539"
HREF="Console_Configuration.html">Console Configuration</A>
<B> Up:</B> <A NAME="tex2html1533"
HREF="Bacula_Main_Reference.html">Bacula Main Reference</A>
<B> Previous:</B> <A NAME="tex2html1527"
HREF="Autochanger_Resource.html">Autochanger Resource</A>
<B> <A NAME="tex2html1535"
HREF="Contents.html">Contents</A></B>
<B> <A NAME="tex2html1537"
HREF="Thanks.html">Index</A></B>
<BR>
<BR>
<!--End of Navigation Panel-->
<H1><A NAME="SECTION002200000000000000000"></A>
<A NAME="MessagesChapter"></A>
<BR>
Messages Resource
</H1>
<A NAME="12956"></A>
<A NAME="12957"></A>
<P>
The Messages resource defines how messages are to be handled and destinations
to which they should be sent.
<P>
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.
<P>
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).
<P>
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 <B>/usr/lib/sendmail</B>. 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.
<P>
The records contained in a Messages resource consist of a <B>destination</B>
specification followed by a list of <B>message-types</B> in the format:
<P>
<DL>
<DT><STRONG>destination = message-type1, message-type2, message-type3, ... </STRONG></DT>
<DD><A NAME="12962"></A>
</DD>
</DL>
<P>
or for those destinations that need and address specification (e.g. email):
<P>
<DL>
<DT><STRONG>destination = address = message-type1, message-type2,
message-type3, ... </STRONG></DT>
<DD><A NAME="12965"></A>
<P>
Where <B>destination</B> is one of a predefined set of keywords that define
where the message is to be sent (<B>stdout</B>, <B>file</B>, ...), <B> message-type</B> is one of a predefined set of keywords that define the type of
message generated by <B>Bacula</B> (<B>ERROR</B>, <B>WARNING</B>, <B>FATAL</B>,
...), and <B>address</B> varies according to the <B>destination</B> keyword, but
is typically an email address or a filename.
</DD>
</DL>
<P>
The following are the list of the possible record definitions that can be used
in a message resource.
<P>
<DL>
<DT><STRONG>Messages</STRONG></DT>
<DD><A NAME="12978"></A>
Start of the Messages records.
<P>
</DD>
<DT><STRONG>Name = name</STRONG></DT>
<DD><A NAME="12981"></A>
The name of the Messages resource. The name you specify here will be used to
tie this Messages resource to a Job and/or to the daemon.
<P>
<A NAME="mailcommand"></A></DD>
<DT><STRONG>MailCommand = command</STRONG></DT>
<DD><A NAME="12985"></A>
In the absence of this resource, Bacula will send all mail using the
following command:
<P>
<B>mail -s "Bacula Message" recipients</B>
<P>
In many cases, depending on your machine, this command may not work.
However, by using the <B>MailCommand</B>, you can specify exactly how to
send the mail. During the processing of the <B>command</B> part, normally
specified as a quoted string, the following substitutions will be used:
<P>
<UL>
<LI>%% = %
</LI>
<LI>%c = Client's name
</LI>
<LI>%d = Director's name
</LI>
<LI>%e = Job Exit code (OK, Error, ...)
</LI>
<LI>%i = Job Id
</LI>
<LI>%j = Unique Job name
</LI>
<LI>%l = Job level
</LI>
<LI>%n = Job name
</LI>
<LI>%r = Recipients
</LI>
<LI>%t = Job type (e.g. Backup, ...)
</LI>
</UL>
<P>
Please note: any <B>MailCommand</B> directive must be specified
in the <B>Messages</B> resource <B>before</B> the desired
<B>Mail</B>, <B>MailOnSuccess</B>, or <B>MailOnError</B>
directive. In fact, each of those directives may be preceded by
a different <B>MailCommand</B>.
<P>
The following is the command I (Kern) use. Note, the whole command should
appear on a single line in the configuration file rather than split as is
done here for presentation:
<P>
<B>mailcommand = "/home/kern/bacula/bin/bsmtp -h mail.example.com -f
\"\(Bacula\)
%r\" -s \"Bacula: %t %e of %c
%l\" %r"</B>
<P>
The <B>bsmtp</B> program is provided as part of <B>Bacula</B>. For
additional details, please see the
bsmtp - Customizing Your Email Messagesbsmtp section of
the Bacula Utility Programs chapter of this manual. Please test any <B>mailcommand</B> 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.
<P>
</DD>
<DT><STRONG>OperatorCommand = command</STRONG></DT>
<DD><A NAME="13012"></A>
This resource specification is similar to the <B>MailCommand</B> except that
it is used for Operator messages. The substitutions performed for the <B> MailCommand</B> are also done for this command. Normally, you will set this
command to the same value as specified for the <B>MailCommand</B>.
The <B>OperatorCommand</B> directive must appear in the <B>Messages</B>
resource before the <B>Operator</B> directive.
<P>
</DD>
<DT><STRONG>destination = message-type1,
message-type2, ...</STRONG></DT>
<DD><A NAME="13119"></A>
<P>
Where <B>destination</B> may be one of the following:
<P>
<DL>
<DT><STRONG>stdout</STRONG></DT>
<DD><A NAME="13029"></A>
Send the message to standard output.
<P>
</DD>
<DT><STRONG>stderr</STRONG></DT>
<DD><A NAME="13030"></A>
Send the message to standard error.
<P>
</DD>
<DT><STRONG>console</STRONG></DT>
<DD><A NAME="13031"></A>
Send the message to the console (Bacula Console). These messages are held
until the console program connects to the Director.
</DD>
</DL>
<P>
</DD>
<DT></DT>
<DD><B>destination = address =
message-type1, message-type2, ...</B>
<A NAME="13121"></A>
<P>
Where <B>address</B> depends on the <B>destination</B>.
<P>
The <B>destination</B> may be one of the following:
<P>
<DL>
<DT><STRONG>director</STRONG></DT>
<DD><A NAME="13047"></A>
<A NAME="13048"></A>
Send the message to the Director whose name is given in the <B>address</B>
field. Note, in the current implementation, the Director Name is ignored, and
the message is sent to the Director that started the Job.
<P>
</DD>
<DT><STRONG>file</STRONG></DT>
<DD><A NAME="13050"></A>
<A NAME="13051"></A>
Send the message to the filename given in the <B>address</B> field. If the
file already exists, it will be overwritten.
<P>
</DD>
<DT><STRONG>append</STRONG></DT>
<DD><A NAME="13053"></A>
<A NAME="13054"></A>
Append the message to the filename given in the <B>address</B> field. If the
file already exists, it will be appended to. If the file does not exist, it
will be created.
<P>
</DD>
<DT><STRONG>syslog</STRONG></DT>
<DD><A NAME="13056"></A>
Send the message to the system log (syslog) using the facility specified in
the <B>address</B> field. Note, for the moment, the <B>address</B> field is
ignored and the message is always sent to the LOG_DAEMON facility with
level LOG_ERR. See <B>man 3 syslog</B> for more details. Example:
<P>
<PRE>
syslog = all, !skipped
</PRE>
<P>
Although the <B>syslog</B> 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
<B>syslog</B> to prevent loss of the message, so you might occassionally
check the <B>syslog</B> for Bacula output (normally <B> /var/log/syslog</B>).
<P>
</DD>
<DT><STRONG>mail</STRONG></DT>
<DD><A NAME="13066"></A>
Send the message to the email addresses that are given as a comma
separated list in the <B>address</B> field. Mail messages are grouped
together during a job and then sent as a single email message when the
job terminates. The advantage of this destination is that you are
notified about every Job that runs. However, if you backup five or ten
machines every night, the volume of email messages can be important.
Some users use filter programs such as <B>procmail</B> to automatically
file this email based on the Job termination code (see <B> mailcommand</B>).
<P>
</DD>
<DT><STRONG>mail on error</STRONG></DT>
<DD><A NAME="13070"></A>
Send the message to the email addresses that are given as a comma
separated list in the <B>address</B> field if the Job terminates with an
error condition. MailOnError messages are grouped together during a job
and then sent as a single email message when the job terminates. This
destination differs from the <B>mail</B> destination in that if the Job
terminates normally, the message is totally discarded (for this
destination). If the Job terminates in error, it is emailed. By using
other destinations such as <B>append</B> you can ensure that even if the
Job terminates normally, the output information is saved.
<P>
</DD>
<DT><STRONG>mail on success</STRONG></DT>
<DD><A NAME="13074"></A>
Send the message to the email addresses that are given as a comma
separated list in the <B>address</B> field if the Job terminates
normally (no error condition). MailOnSuccess messages are grouped
together during a job and then sent as a single email message when the
job terminates. This destination differs from the <B>mail</B>
destination in that if the Job terminates abnormally, the message is
totally discarded (for this destination). If the Job terminates
normally, it is emailed.
<P>
</DD>
<DT><STRONG>operator</STRONG></DT>
<DD><A NAME="13077"></A>
Send the message to the email addresses that are specified as a comma
separated list in the <B>address</B> field. This is similar to <B> mail</B> above, except that each message is sent as received. Thus there
is one email per message. This is most useful for <B>mount</B> messages
(see below).
<P>
</DD>
<DT><STRONG>console</STRONG></DT>
<DD><A NAME="13081"></A>
Send the message to the Bacula console.
<P>
</DD>
<DT><STRONG>stdout</STRONG></DT>
<DD><A NAME="13082"></A>
Send the message to the standard output (normally not used).
<P>
</DD>
<DT><STRONG>stderr</STRONG></DT>
<DD><A NAME="13083"></A>
Send the message to the standard error output (normally not used).
<P>
</DD>
<DT><STRONG>catalog</STRONG></DT>
<DD><A NAME="13084"></A>
Send the message to the Catalog database. The message will be
written to the table named <B>Log</B> and a timestamp field will
also be added. This permits Job Reports and other messages to
be recorded in the Catalog so that they can be accessed by
reporting software. Bacula will prune the Log records associated
with a Job when the Job records are pruned. Otherwise, Bacula
never uses these records internally, so this destination is only
used for special purpose programs (e.g. <B>bweb</B>).
<P>
</DD>
</DL>
<P>
For any destination, the <B>message-type</B> field is a comma separated
list of the following types or classes of messages:
<P>
<DL>
<DT><STRONG>info</STRONG></DT>
<DD><A NAME="13090"></A>
General information messages.
<P>
</DD>
<DT><STRONG>warning</STRONG></DT>
<DD><A NAME="13091"></A>
Warning messages. Generally this is some unusual condition but not expected
to be serious.
<P>
</DD>
<DT><STRONG>error</STRONG></DT>
<DD><A NAME="13092"></A>
Non-fatal error messages. The job continues running. Any error message should
be investigated as it means that something went wrong.
<P>
</DD>
<DT><STRONG>fatal</STRONG></DT>
<DD><A NAME="13093"></A>
Fatal error messages. Fatal errors cause the job to terminate.
<P>
</DD>
<DT><STRONG>terminate</STRONG></DT>
<DD><A NAME="13094"></A>
Message generated when the daemon shuts down.
<P>
</DD>
<DT><STRONG>notsaved</STRONG></DT>
<DD><A NAME="13095"></A>
<A NAME="13096"></A>
Files not saved because of some error. Usually because the file cannot be
accessed (i.e. it does not exist or is not mounted).
<P>
</DD>
<DT><STRONG>skipped</STRONG></DT>
<DD><A NAME="13097"></A>
<A NAME="13098"></A>
Files that were skipped because of a user supplied option such as an
incremental backup or a file that matches an exclusion pattern. This is
not considered an error condition such as the files listed for the <B> notsaved</B> type because the configuration file explicitly requests these
types of files to be skipped. For example, any unchanged file during an
incremental backup, or any subdirectory if the no recursion option is
specified.
<P>
</DD>
<DT><STRONG>mount</STRONG></DT>
<DD><A NAME="13100"></A>
<A NAME="13101"></A>
Volume mount or intervention requests from the Storage daemon. These
requests require a specific operator intervention for the job to
continue.
<P>
</DD>
<DT><STRONG>restored</STRONG></DT>
<DD><A NAME="13102"></A>
<A NAME="13103"></A>
The <B>ls</B> style listing generated for each file restored is sent to
this message class.
<P>
</DD>
<DT><STRONG>all</STRONG></DT>
<DD><A NAME="13105"></A>
All message types.
<P>
</DD>
<DT><STRONG>security</STRONG></DT>
<DD><A NAME="13106"></A>
Security info/warning messages principally from unauthorized
connection attempts.
<P>
</DD>
<DT><STRONG>alert</STRONG></DT>
<DD><A NAME="13107"></A>
Alert messages. These are messages generated by tape alerts.
<P>
</DD>
<DT><STRONG>volmgmt</STRONG></DT>
<DD><A NAME="13108"></A>
Volume management messages. Currently there are no volume mangement
messages generated.
</DD>
</DL>
<P>
</DD>
</DL>
<P>
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:
<P>
<PRE>
Messages {
Name = Standard
mail = enforcement@sec.com = all, !skipped, !terminate
operator = enforcement@sec.com = mount
console = all, !skipped, !saved
}
</PRE>
<P>
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 <B>mailcommand</B> and <B>operatorcommand</B> are on a single line - they had to be
split for this manual:
<P>
<PRE>
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
}
</PRE>
<P>
<HR>
<!--Navigation Panel-->
<A NAME="tex2html1538"
HREF="Console_Configuration.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A>
<A NAME="tex2html1532"
HREF="Bacula_Main_Reference.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A>
<A NAME="tex2html1526"
HREF="Autochanger_Resource.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A>
<A NAME="tex2html1534"
HREF="Contents.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A>
<A NAME="tex2html1536"
HREF="Thanks.html">
<IMG WIDTH="43" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="index" SRC="index.png"></A>
<BR>
<B> Next:</B> <A NAME="tex2html1539"
HREF="Console_Configuration.html">Console Configuration</A>
<B> Up:</B> <A NAME="tex2html1533"
HREF="Bacula_Main_Reference.html">Bacula Main Reference</A>
<B> Previous:</B> <A NAME="tex2html1527"
HREF="Autochanger_Resource.html">Autochanger Resource</A>
<B> <A NAME="tex2html1535"
HREF="Contents.html">Contents</A></B>
<B> <A NAME="tex2html1537"
HREF="Thanks.html">Index</A></B>
<!--End of Navigation Panel-->
<ADDRESS>
2012-01-24
</ADDRESS>
</BODY>
</HTML>
