]> git.sur5r.net Git - bacula/docs/blob - docs/manual/messagesres.tex
Update FOSDEM talk
[bacula/docs] / docs / manual / messagesres.tex
1 %%
2 %%
3
4 \chapter{Messages Resource}
5 \label{MessagesChapter}
6 \index[general]{Resource!Messages}
7 \index[general]{Messages Resource}
8
9 The Messages resource defines how messages are to be handled and destinations
10 to which they should be sent. 
11
12 Even though each daemon has a full message handler, within the File daemon and
13 the Storage daemon, you will normally choose to send all the appropriate
14 messages back to the Director. This permits all the messages associated with a
15 single Job to be combined in the Director and sent as a single email message
16 to the user, or logged together in a single file. 
17
18 Each message that Bacula generates (i.e. that each daemon generates) has an
19 associated type such as INFO, WARNING, ERROR, FATAL, etc. Using the message
20 resource, you can specify which message types you wish to see and where they
21 should be sent. In addition, a message may be sent to multiple destinations.
22 For example, you may want all error messages both logged as well as sent to
23 you in an email. By defining multiple messages resources, you can have
24 different message handling for each type of Job (e.g. Full backups versus
25 Incremental backups). 
26
27 In general, messages are attached to a Job and are included in the Job report.
28 There are some rare cases, where this is not possible, e.g. when no job is
29 running, or if a communications error occurs between a daemon and the
30 director. In those cases, the message may remain in the system, and should be
31 flushed at the end of the next Job. However, since such messages are not
32 attached to a Job, any that are mailed will be sent to {\bf
33 /usr/lib/sendmail}. On some systems, such as FreeBSD, if your sendmail is in a
34 different place, you may want to link it to the the above location. 
35
36 The records contained in a Messages resource consist of a {\bf destination}
37 specification followed by a list of {\bf message-types} in the format: 
38
39 \begin{description}
40
41 \item [destination = message-type1, message-type2, message-type3, ...  ]
42 \index[dir]{destination}
43 \end{description}
44
45 or for those destinations that need and address specification (e.g. email): 
46
47 \begin{description}
48
49 \item [destination = address = message-type1, message-type2,
50    message-type3, ...  ]
51 \index[dir]{destination}
52
53    Where {\bf destination} is one of a predefined set of keywords that define
54    where the message is to be sent ({\bf stdout}, {\bf file}, ...), {\bf
55    message-type} is one of a predefined set of keywords that define the type of
56    message generated by {\bf Bacula} ({\bf ERROR}, {\bf WARNING}, {\bf FATAL},
57    ...), and {\bf address} varies according to the {\bf destination} keyword, but
58    is typically an email address or a filename. 
59 \end{description}
60
61 The following are the list of the possible record definitions that can be used
62 in a message resource. 
63
64 \begin{description}
65
66 \item [Messages]
67 \index[dir]{Messages}
68    Start of the Messages records.  
69
70 \item [Name = \lt{}name\gt{}]
71 \index[dir]{Name}
72    The name of the Messages resource.  The name you specify here will be used to
73    tie this Messages  resource to a Job and/or to the daemon.  
74
75 \label{mailcommand}
76 \item [MailCommand = \lt{}command\gt{}]
77 \index[dir]{MailCommand}
78    In the absence of this resource,  Bacula will send all mail using the
79    following command:  
80
81 {\bf mail -s "Bacula Message" \lt{}recipients\gt{}}  
82
83 In many cases, depending on your machine, this command may not work.  Using
84 the {\bf MailCommand}, you can specify exactly how to send  the mail. During
85 the processing of the {\bf command}, normally  specified as a quoted string,
86 the following substitutions will be  used:  
87
88 \begin{itemize}
89 \item \%\% = \%  
90 \item \%c = Client's name  
91 \item \%d = Director's name  
92 \item \%e = Job Exit code (OK, Error, ...)  
93 \item \%i = Job Id  
94 \item \%j = Unique Job name  
95 \item \%l = Job level  
96 \item \%n = Job name  
97 \item \%r = Recipients  
98 \item \%t = Job type (e.g. Backup, ...)  
99    \end{itemize}
100
101 The following is the command I (Kern) use. Note, the whole  command should
102 appear on a single line in the configuration file  rather than split as is
103 done here for presentation:  
104
105 {\bf mailcommand = "/home/kern/bacula/bin/bsmtp -h mail.example.com -f
106 \textbackslash{}"\textbackslash{}(Bacula\textbackslash{})
107 \%r\textbackslash{}" -s \textbackslash{}"Bacula: \%t \%e of \%c
108 \%l\textbackslash{}" \%r"}
109
110 Note, the {\bf bsmtp} program is provided as part of {\bf Bacula}.  For
111 additional details, please see the 
112 \ilink{ bsmtp -- Customizing Your Email Messages}{bsmtp} section of
113 the  Bacula Utility Programs chapter of this manual. Please test any  {\bf
114 mailcommand} that you use to ensure that your bsmtp gateway accepts  the
115 addressing form that you use. Certain programs such as Exim can be very 
116 selective as to what forms are permitted particularly in the from part.  
117
118 \item [OperatorCommand = \lt{}command\gt{}]
119 \index[fd]{OperatorCommand}
120    This resource specification is  similar to the {\bf MailCommand} except that
121    it is used for Operator  messages. The substitutions performed for the {\bf
122    MailCommand} are  also done for this command. Normally, you will set this
123    command to the  same value as specified for the {\bf MailCommand}. 
124
125 \item [Debug = \lt{}debug-level\gt{}]
126    \index[fd]{Debug}
127    This sets the debug message level  to the debug level, which is an integer.
128 Higher debug levels cause more  debug information to be produced. You are
129 requested not to use this  record since it will be deprecated. 
130
131 \item [\lt{}destination\gt{} = \lt{}message-type1\gt{},
132    \lt{}message-type2\gt{}, ...]
133    \index[fd]{\lt{}destination\gt{}}
134
135 Where {\bf destination} may be one of the following:  
136
137 \begin{description}
138
139 \item [stdout]
140    \index[fd]{stdout}
141    Send the message to standard output.  
142
143 \item [stderr]
144    \index[fd]{stderr}
145    Send the message to standard error.  
146
147 \item [console]
148    \index[console]{console}
149    Send the message to the console (Bacula Console).  These messages are held
150 until the console program  connects to the Director.  
151 \end{description}
152
153 \item {\bf \lt{}destination\gt{} = \lt{}address\gt{} =
154    \lt{}message-type1\gt{}, \lt{}message-type2\gt{}, ...}
155    \index[console]{\lt{}destination\gt{}}
156
157 Where {\bf address} depends on the {\bf destination}. 
158
159 The {\bf destination} may be one of the following:  
160
161 \begin{description}
162
163 \item [director]
164    \index[dir]{director}
165    \index[general]{director}
166    Send the message to the Director whose name  is given in the {\bf address}
167    field. Note, in the current  implementation, the Director Name is ignored, and
168    the message  is sent to the Director that started the Job.  
169
170 \item [file]
171 \index[dir]{file}
172 \index[general]{file}
173    Send the message to the filename given in  the {\bf address} field. If the
174    file already exists, it will be  overwritten.  
175
176 \item [append]
177 \index[dir]{append}
178 \index[general]{append}
179    Append the message to the filename given  in the {\bf address} field. If the
180    file already exists, it will  be appended to. If the file does not exist, it
181    will be created.  
182
183 \item [syslog]
184 \index[general]{syslog}
185    Send the message to the system log (syslog)  using the facility specified in
186    the {\bf address} field.  Note, for the moment, the {\bf address} field is
187    ignored  and the message is always sent to the LOG\_DAEMON facility with
188    level LOG\_ERR. See {\bf man 3 syslog} for more details. Example:
189 \begin{verbatim}
190    syslog = all, !skipped, !saved
191 \end{verbatim}
192
193 \item [mail]
194    \index[general]{mail}
195    Send the message to the email addresses that are given as a comma
196    separated list in the {\bf address} field.  Mail messages are grouped
197    together during a job and then sent as a single email message when the
198    job terminates.  The advantage of this destination is that you are
199    notified about every Job that runs.  However, if you backup five or ten
200    machines every night, the volume of email messages can be important.
201    Some users use filter programs such as {\bf procmail} to automatically
202    file this email based on the Job termination code (see {\bf
203    mailcommand}).
204
205 \item [mail on error]
206    \index[general]{mail on error}
207    Send the message to the email addresses that are given as a comma
208    separated list in the {\bf address} field if the Job terminates with an
209    error condition.  MailOnError messages are grouped together during a job
210    and then sent as a single email message when the job terminates.  This
211    destination differs from the {\bf mail} destination in that if the Job
212    terminates normally, the message is totally discarded (for this
213    destination).  If the Job terminates in error, it is emailed.  By using
214    other destinations such as {\bf append} you can ensure that even if the
215    Job terminates normally, the output information is saved.
216
217 \item [mail on success]
218    \index[general]{mail on success}
219    Send the message to the email addresses that are given as a comma
220    separated list in the {\bf address} field if the Job terminates
221    normally (no error condition).  MailOnSuccess messages are grouped
222    together during a job and then sent as a single email message when the
223    job terminates.  This destination differs from the {\bf mail}
224    destination in that if the Job terminates abnormally, the message is
225    totally discarded (for this destination).  If the Job terminates in
226    normally, it is emailed.
227
228 \item [operator]
229    \index[general]{operator}
230    Send the message to the email addresses that are specified as a comma
231    separated list in the {\bf address} field.  This is similar to {\bf
232    mail} above, except that each message is sent as received.  Thus there
233    is one email per message.  This is most useful for {\bf mount} messages
234    (see below).  
235
236 \item [console]
237   \index[general]{console}
238   Send the message to the Bacula console.
239
240 \item [stdout]
241   \index[general]{stdout}
242   Send the message to the standard output (normally not used).
243
244 \item [stderr]
245   \index[general]{stderr}
246   Send the message to the standard error output (normally not used).
247
248 \item [catalog]
249    \index[general]{catalog}
250    Send the message to the Catalog database. The message will be
251    written to the table named {\bf Log} and a timestamp field will
252    also be added. This permits Job Reports and other messages to
253    be recorded in the Catalog so that they can be accessed by
254    reporting software.  Bacula will prune the Log records associated
255    with a Job when the Job records are pruned.  Otherwise, Bacula 
256    never uses these records internally, so this destination is only
257    used for special purpose programs (e.g. {\bf bweb}).
258
259 \end{description}
260
261    For any destination, the {\bf message-type} field is a comma separated
262    list of the following types or classes of messages:
263
264 \begin{description}
265
266 \item [info]
267    \index[general]{info}
268    General information messages.  
269
270 \item [warning]
271    \index[general]{warning}
272    Warning messages. Generally this is some  unusual condition but not expected
273    to be serious. 
274
275 \item [error]
276    \index[general]{error}
277    Non-fatal error messages. The job continues running.  Any error message should
278    be investigated as it means that something  went wrong.  
279
280 \item [fatal]
281    \index[general]{fatal}
282    Fatal error messages. Fatal errors cause the  job to terminate.  
283
284 \item [terminate]
285    \index[general]{terminate}
286    Message generated when the daemon shuts down.  
287
288 \item [saved]
289    \index[fd]{saved}
290    \index[general]{saved}
291    Files saved normally.  
292
293 \item [notsaved]
294    \index[fd]{notsaved}
295    \index[general]{notsaved}
296    Files not saved because of some error.  Usually because the file cannot be
297    accessed (i.e. it does not  exist or is not mounted).  
298
299 \item [skipped]
300    \index[fd]{skipped}
301    \index[general]{skipped}
302    Files that were skipped because of a user supplied option such as an
303    incremental backup or a file that matches an exclusion pattern.  This is
304    not considered an error condition such as the files listed for the {\bf
305    notsaved} type because the configuration file explicitly requests these
306    types of files to be skipped.  For example, any unchanged file during an
307    incremental backup, or any subdirectory if the no recursion option is
308    specified.
309
310 \item [mount]
311    \index[dir]{mount}
312    \index[general]{mount}
313    Volume mount or intervention requests from the Storage daemon.  These
314    requests require a specific operator intervention for the job to
315    continue.
316
317 \item [restored]
318    \index[fd]{restored}
319    \index[general]{restored}
320    The {\bf ls} style listing generated for each file restored is sent to
321    this message class.
322
323 \item [all]
324    \index[general]{all}
325    All message types.  
326
327 \item [security]
328    \index[general]{security}
329    Security info/warning messages principally from unauthorized      
330    connection attempts.
331
332 \item [alert]
333    \index[general]{alert}
334    Alert messages. These are messages generated by tape alerts.
335
336 \item [volmgmt]
337    \index[general]{volmgmt}
338    Volume management messages. Currently there are no volume mangement
339    messages generated.
340 \end{description}
341
342 \end{description}
343
344 The following is an example of a valid Messages resource definition, where
345 all messages except files explicitly skipped or daemon termination messages
346 are sent by email to enforcement@sec.com.  In addition all mount messages
347 are sent to the operator (i.e.  emailed to enforcement@sec.com).  Finally
348 all messages other than explicitly skipped files and files saved are sent
349 to the console:
350
351 \footnotesize
352 \begin{verbatim}
353 Messages {
354   Name = Standard
355   mail = enforcement@sec.com = all, !skipped, !terminate
356   operator = enforcement@sec.com = mount
357   console = all, !skipped, !saved
358 }
359 \end{verbatim}
360 \normalsize
361
362 With the exception of the email address (changed to avoid junk mail from
363 robot's), an example Director's Messages resource is as follows. Note, the {\bf
364 mailcommand} and {\bf operatorcommand} are on a single line -- they had to be
365 split for this manual: 
366
367 \footnotesize
368 \begin{verbatim}
369 Messages {
370   Name = Standard
371   mailcommand = "bacula/bin/bsmtp -h mail.example.com \
372     -f \"\(Bacula\) %r\" -s \"Bacula: %t %e of %c %l\" %r"
373   operatorcommand = "bacula/bin/bsmtp -h mail.example.com \
374     -f \"\(Bacula\) %r\" -s \"Bacula: Intervention needed \
375         for %j\" %r"
376   MailOnError = security@example.com = all, !skipped, \
377                 !terminate
378   append = "bacula/bin/log" = all, !skipped, !terminate
379   operator = security@example.com = mount
380   console = all, !skipped, !saved
381 }
382 \end{verbatim}
383 \normalsize