Fin de storedconf.tex, debut de messagesres.tex.

[bacula/docs] / docs / manual-fr / messagesres.tex

%%
%%

\section*{La ressource Messages}
\label{_ChapterStart15}
\index[general]{Ressource!Messages}
\index[general]{Messages Ressource}
\addcontentsline{toc}{section}{Ressource Messages}

\subsection*{La ressource  Messages}
\label{MessageResource}
\index[general]{Ressource!Messages}
\index[general]{Messages Ressource}
\addcontentsline{toc}{subsection}{La ressource Messages}

La ressource Messages définit la façon dont les messages doivent être construits 
et vers quelles destinations ils doivent être transmis.

Bien que chaque {\it daemon} intègre un gestionnaire de messages pleinement 
fonctionnel, vous choisirez certainement de centraliser les messages appropriés 
des File Daemons et du Storage Daemon vers le Director. Ainsi, tous les messages 
associés à un job donné peuvent être combinés et envoyés en un simple courrier 
électronique vers l'utilisateur, ou enregistré dans quelque fichier de logs.

Chaque message généré par un {\it daemon} Bacula possède un type associé tel 
que INFO, WARNING, ERROR, FATAL, etc. La ressource Messages vous permet de 
stipuler les types de messages que vous voulez voir, et où les envoyer. De plus, 
un message peut être expédié vers plusieurs destinations. Par exemple, vous 
pouvez faire en sorte quque tous les messages d'erreur soient consignés dans un 
fichier de logs tout en vous étant envoyés par courrier élecronique. En 
définissant plusieurs ressources Messages, vous pouvez profiter de différents 
modes de prise en charge pour chaque type de job (par exemple, selon qu'il 
s'agit d'une full ou d'un incrémentale). 

En général, les messages sont attachés à un job et sont inclus dans le rapport de job. 
Il existe de rares situations où ce n'est pas possible, par exemple lorsqu'aucun 
job n'est en cours d'exécution, ou si une erreur de communication se produit 
entre un daemon et le Director. Dans ce genre de situations, le message demeure 
dans le système et devrait être purgé à la fin job suivant. Cependant, comme de tels 
messages ne sont pas attachés à un job, tous ceux qui sont envoyés par courrier 
électronique sont envoyés à {\bf /usr/lib/sendmail}. Si sur votre système, comme c'est 
le cas de FreeBSD, sendmail réside en un autre emplacement, veillez à le lier 
depuis l'emplacement ci-dessus. 

Les enregistrements contenus dans une ressource Messages consistent en une 
spécification de  {\bf destination} suivie d'une liste de types de messages 
{\bf message-types} au format :

\begin{description}

\item [destination = message-type1, message-type2, message-type3, ...  ]
   \index[dir]{destination}
   \end{description}

ou, pour ces destinations qui nécessitent de spécifier une adresse (e-mail, par exemple) :

\begin{description}

\item [destination = address = message-type1, message-type2,
   message-type3, ...  ]
   \index[dir]{destination}

où {\bf destination} est l'un des mots-clef prédéfinis qui précise où le message 
doit être expédié ({\bf stdout}, {\bf file}, ...), {\bf  message-type} est l'un des 
mots-clef prédéfinis qui précise le type de messages généré par Bacula ({\bf ERROR}, 
{\bf WARNING}, {\bf FATAL}, ...) et {\bf address} varie selon le mot clef  {\bf destination} 
mais peut typiquement être une adresse de courrier électronique ou un nom de fichier.

\end{description}

Voici la liste des directives disponibles pour définir des ressources Messages :


\begin{description}

\item [Messages]
   \index[dir]{Messages}
   Début des enregistrements de Messages

\item [Name = \lt{}name\gt{}]
   \index[dir]{Name}
   Le nom de la ressource Message. Ce nom sera utilisé pour lier cette ressource 
Message à un job et/ou au un daemon.

\label{mailcommand}

\item [MailCommand = \lt{}command\gt{}]
   \index[dir]{MailCommand}
En l'absence de cette directive, Bacula enverra tous ses messages avec la 
commande suivante :

{\bf mail -s "Bacula Message" \lt{}recipients\gt{}}  
Dans de nombreusx cas, selon votre machine, cette commande peut ne pas fonctionner. 
La directive  {\bf MailCommand} vous permet de stipuler précisément la façon 
d'envoyer vos courrier électroniques. Lors de l'exécution de la commande 
{\bf command}, spécifiée entre guillemets, les substitutions suivantes sont 
effectuées :

\begin{itemize}
  \item \%\% = \%  
  \item \%c = Le nom du client
  \item \%d = Le nom du Director  
  \item \%e = Le code de sortie du job (OK, Error, ...)  
  \item \%i = L'Id du Job  
  \item \%j = Le nom unique du job  
  \item \%l = Le niveau (Full, differential, ...) du job  
  \item \%n = Le om du job  
  \item \%r = Les destinataires  
  \item \%t = Le type du job (Backup, verify, ...)  
\end{itemize}

Voici la commande que j'utilise (Kern) :

{\bf mailcommand = "/home/kern/bacula/bin/bsmtp -h mail.example.com -f
\textbackslash{}"\textbackslash{}(Bacula\textbackslash{})
\%r\textbackslash{}" -s \textbackslash{}"Bacula: \%t \%e of \%c
\%l\textbackslash{}" \%r"}

Notez que la commande entière devrait apparaître sur une seulle ligne plutôt 
que découpée comme ici pour des raisons de présentation.

Le programme {\bf bsmtp} est fourni en tant que partie de Bacula. Pour plus 
de détails, consultez la section \ilink{ bsmtp -- Personnaliser l'envoi 
de vos message par courrier électronique}{bsmtp}. Testez soigneusement 
toute commande {\bf mailcommand} pour vous assurer que votre passerelle 
bsmtp accepte le format d'adressage que vous utilisez. Certains programmes 
tels Exim peut se montrer très sélectif en ce qui concerne les format 
autorisés, particulièrement en ce qui concerne le champ "from".

\item [OperatorCommand = \lt{}command\gt{}]
   \index[fd]{OperatorCommand}
   This resource specification is  similar to the {\bf MailCommand} except that
it is used for Operator  messages. The substitutions performed for the {\bf
MailCommand} are  also done for this command. Normally, you will set this
command to the  same value as specified for the {\bf MailCommand}. 

\item [Debug = \lt{}debug-level\gt{}]
   \index[fd]{Debug}
   This sets the debug message level  to the debug level, which is an integer.
Higher debug levels cause more  debug information to be produced. You are
requested not to use this  record since it will be deprecated. 

\item [\lt{}destination\gt{} = \lt{}message-type1\gt{},
   \lt{}message-type2\gt{}, ...]
   \index[fd]{\lt{}destination\gt{}}

Where {\bf destination} may be one of the following:  

\begin{description}

\item [stdout]
   \index[fd]{stdout}
   Send the message to standard output.  

\item [stderr]
   \index[fd]{stderr}
   Send the message to standard error.  

\item [console]
   \index[console]{console}
   Send the message to the console (Bacula Console).  These messages are held
until the console program  connects to the Director.  
\end{description}

\item {\bf \lt{}destination\gt{} = \lt{}address\gt{} =
   \lt{}message-type1\gt{}, \lt{}message-type2\gt{}, ...}
   \index[console]{\lt{}destination\gt{}}

Where {\bf address} depends on the {\bf destination}, which  may be one of the
following:  

\begin{description}

\item [director]
   \index[dir]{director}
   Send the message to the Director whose name  is given in the {\bf address}
field. Note, in the current  implementation, the Director Name is ignored, and
the message  is sent to the Director that started the Job.  

\item [file]
   \index[dir]{file}
   Send the message to the filename given in  the {\bf address} field. If the
file already exists, it will be  overwritten.  

\item [append]
   \index[dir]{append}
   Append the message to the filename given  in the {\bf address} field. If the
   file already exists, it will  be appended to. If the file does not exist, it
   will be created.  

\item [syslog]
   \index[fd]{syslog}
   Send the message to the system log (syslog)  using the facility specified in
   the {\bf address} field.  Note, for the moment, the {\bf address} field is
   ignored  and the message is always sent to the LOG_DAEMON facility with
   level LOG_ERR. See {\bf man 3 syslog} for more details. Example:
\begin{verbatim}
   syslog = all, !skipped, !saved
\end{verbatim}

\item [mail]
   \index[fd]{mail}
   Send the message to the email addresses that are given as a comma
   separated list in the {\bf address} 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 5 or 10
   machines every night, the volume of email messages can be important.
   Some users use filter programs such as {\bf procmail} to automatically
   file this email based on the Job termination code (see {\bf
   mailcommand}).

\item [mail on error]
   \index[fd]{mail on error}
   Send the message to the email addresses that are given as a comma
   separated list in the {\bf address} 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 {\bf mail} 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 {\bf append} you can ensure that even if the
   Job terminates normally, the output information is saved.

\item [operator]
   \index[fd]{operator}
   Send the message to the email addresses that are specified as a comma
   separated list in the {\bf address} field.  This is similar to {\bf
   mail} above, except that each message is sent as received.  Thus there
   is one email per message.  This is most useful for {\bf mount} messages
   (see below).  \end{description}

   For any destination, the {\bf message-type} field is a comma separated
   list of the following types or classes of messages:

\begin{description}

\item [info]
   \index[fd]{info}
   General information messages.  

\item [warning]
   \index[fd]{warning}
   Warning messages. Generally this is some  unusual condition but not expected
to be serious. 

\item [error]
   \index[fd]{error}
   Non-fatal error messages. The job continues running.  Any error message should
be investigated as it means that something  went wrong.  

\item [fatal]
   \index[fd]{fatal}
   Fatal error messages. Fatal errors cause the  job to terminate.  

\item [terminate]
   \index[fd]{terminate}
   Message generated when the daemon shuts down.  

\item [saved]
   \index[fd]{saved}
   Files saved normally.  

\item [notsaved]
   \index[fd]{notsaved}
   Files not saved because of some error.  Usually because the file cannot be
accessed (i.e. it does not  exist or is not mounted).  

\item [skipped]
   \index[fd]{skipped}
   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 {\bf
   notsaved} 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.

\item [mount]
   \index[dir]{mount}
   Volume mount or intervention requests from the Storage daemon.  These
   requests require a specific operator intervention for the job to
   continue.

\item [restored]
   \index[dir]{restored}
   The {\bf ls} style listing generated for each file restored is sent to
   this message class.

\item [all]
   \index[fd]{all}
   All message types.  

\item [*security]
   \index[fd]{*security}
   Security info/warning messages principally from unauthorized      
   connection attempts.
\end{description}

\end{description}

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:

\footnotesize
\begin{verbatim}
Messages {
  Name = Standard
  mail = enforcement@sec.com = all, !skipped, !terminate
  operator = enforcement@sec.com = mount
  console = all, !skipped, !saved
}
\end{verbatim}
\normalsize

With the exception of the email address (changed to avoid junk mail from
robot's), Kern's Director's Messages resource is as follows. Note, the {\bf
mailcommand} and {\bf operatorcommand} are on a single line -- they had to be
split for this manual: 

\footnotesize
\begin{verbatim}
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
}
\end{verbatim}
\normalsize