La ressource Messages

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 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 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 à /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 destination suivie d'une liste de types de messages message-types au format :

destination = message-type1, message-type2, message-type3, ...

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

destination = address = message-type1, message-type2, message-type3, ...

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

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

Messages

Début des enregistrements de Messages

Name = <name>

Le nom de la ressource Message. Ce nom sera utilisé pour lier cette ressource Message à un job et/ou au un daemon.

MailCommand = <command>

En l'absence de cette directive, Bacula enverra tous ses messages avec la commande suivante :

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

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

Voici la commande que j'utilise (Kern) :

mailcommand = "/home/kern/bacula/bin/bsmtp -h mail.example.com -f \"\(Bacula\) %r\" -s \"Bacula: %t %e of %c %l\" %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 bsmtp est fourni en tant que partie de Bacula. Pour plus de détails, consultez la section bsmtp -- Personnaliser l'envoi de vos message par courrier électronique. Testez soigneusement toute commande 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".

OperatorCommand = <command>

Cette directive est analogue à MailCommand, mais elle est utilisée pour les messages destinés à l'opérateur. Les substitutions effectuées pour la directive MailCommand sont aussi effectuées pour celle-ci. Normalement, vous mettrez ici la même valeur que pour MailCommand.

Debug = <debug-level>

Cette directive règle le niveau de débogage des messages. C'est un entier. Plus sa valeur est grande, plus grande est la quantité d'informations de débogages produites. Nous vous conseillons de ne pas utiliser cette directive car elle sera bientôt obsolète.

<destination> = <message-type1>, <message-type2>, ...

Où la destination peut être l'une des suivantes :

stdout

Envoie le message vers la sortie standard.

stderr

Envoie le message vers l'erreur standard

console

Envoie le message vers la console Bacula. Ces messages sont gardés en attente jusqu'à ce que la console contacte le Director.

<destination> = <address> = <message-type1>, <message-type2>, ...

Où address dépend de la destination, qui peut être l'une des suivantes :

director

Envoie le message vers le Director dont le nom est spécifié dans le champ address. Notez que dans l'implémentation actuelle, le nom du Director est ignoré, le message étant envoyé au Directr qui a lancé le job.

file

Envoie le message vers le fichier désigné dans le champ address. Si le fichier existe, il est écrasé.

append

Ajoute le message à la suite du fichier désigné dans le champ address. Si le fichier n'existe pas encore, il est créé.

syslog

Envoie le message vers le système de journalisation (syslog) en utilisant le service désigné par le champ address Notez que, pour le moment, le champ address est ignoré, et que le message est toujours envoyé au service LOG_DAEMON avec le niveau LOG_ERR. Consultez la page man 3 syslog pour plus de détails. Exemple :

   syslog = all, !skipped, !saved

mail

Expédie le message vers les adresses électroniques spécifiées dans le champ address (séparées par des points-virgule). Les messages sont rassemblés au cours du job, puis expédiés lorsqu'il prend fin en un seul courrier électronique. L'avantage de cette Destination est que vous recevez une notification de chaque job exécuté. Toutefois, si vous sauvegardez cinq ou dix machines chaque nuit, la quantité de courrier électronique peut devenir importante. Certains utilisateurs mettent en oeuvre des filtres de courrier tels procmail pour classer automatiquement ces courriers en fonction des codes de fin de job (voyez la commande mailcommand

mail on error

Expédie le message vers les adresses électroniques spécifiées dans le champ address (séparées par des points-virgule) si le job se termine avec un code d'erreur. Les messages MailOnError sont rassemblés au cours du job, puis expédiés lorsqu'il prend fin en un seul courrier électronique. Cette Destination diffère de la Destination mail en ce que si le job s'achève normalement, le message est complètement abandonné (pour cette Destination). En utilisant d'autres Destinations, telles que append, vous pouvez vous assurer que les informations de sorties ne seront pas perdues même si le job se termine normalement.

operator

Expédie le message vers les adresses électroniques spécifiées dans le champ address (séparées par des points virgule). Cette directive est similaire à mail décrite plus haut, sauf que chaque message est envoyé aussitôt reçu, de sorte qu'il y a un courrier électronique par message . Ceci est surtout utile pour les messages de type mount (voir ci-dessous).

Pour toutes les Destinations, le champ "type de message" message-type est une liste des types (ou classes) de messages suivants séparés par des points-virgule :

info

Messages d'information générale.

warning

Messages d'avertissement. En général, il s'agit de quelque situation inhabituelle sans toutefois être très sérieuse.

error

Messages d'erreur non-fatale. Le job se poursuit. Tout message d'erreur devrait être suivi d'investigations, car il signifie que quelque chose est allé de travers.

fatal

Messages d'erreur fatale. Ces erreurs précipitent la fin du job.

terminate

Messages générés lorsque le daemon s'arrète.

saved

Fichiers sauvegardés normalement.

notsaved

Fichiers non sauvegardés en raison d'une erreur, en général, parce que le fichier n'a pu être accédé (il n'existait pas ou n'était pas monté).

skipped

Fichiers qui ont été laissés de coté en raison d'une option posée par un utilisateur (par exemple le niveau d'une sauvegarde ou une option d'exclusion. Ceci n'est pas considéré comme une condition d'erreur au même titre que pour le type notsaved puisque le fichier de configuration stipule explicitement que ces fichiers ne doivent pas être sauvegardés. Des cas typiques de fichiers de type skipped : fichiers inchangés lors d'une incrémentale, sous-répertoires si l'option no recursion est activée...

mount

Montage d'un volume ou intervention d'un opérateur requis par le Storage Daemon. Ces requêtes nécessitent une intervention spécifique de l'opérateur pour que le job puisse se poursuivre.

restored

La liste, façon ls, de tous les fichiers restaurés est envoyée vers cette classe de messages.

all

Tous les types de messages.

*security

Messages d'information ou d'avertissement relatifs à la sécurité, essentiellement les tentatives de connection non-autorisées.

Voici un exemple d'une définition de ressource Messages valide, où tous les messages sont envoyés par courrier électronique à enforcement@sec.com à l'exception de ceux concernant les fichiers explicitement exclus (skipped), et des messages d'arrêt de daemon (terminate). De plus, tous les messages de type mount sont envoyés à l'opérateur (courrier à enforcement@sec.com). Enfin, tous les messages autres que ceux relatifs aux fichiers explicitement exclus et aux fichiers sauvegardés sont envoyés vers la console :

Messages {
  Name = Standard
  mail = enforcement@sec.com = all, !skipped, !terminate
  operator = enforcement@sec.com = mount
  console = all, !skipped, !saved
}

A l'exception de l'adresse électronique (modifiée pour éviter le spam), voici la ressource Message du Director de Kern. Notez que les commandes mailcommand et operatorcommand sont sur une seule ligne et non coupées comme ici pour des besoins de mise en page.

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
}