Configuration du Client/File Daemon

General

La configuration du Client (ou File Daemon) est l'une des plus simples à effectuer. En principe, vous n'aurez rien à modifier au fichier par défaut en dehors du nom du Client afin d'identifier clairement les messages d'erreur.

Pour un discours général sur les fichiers de configuration et ressources incluant les types de données reconnues par Bacula, veuillez consulter le chapitre Configuration de ce manuel. Les ressources suivantes doivent être définies :

• Client -- pour définir les clients qui doivent être sauvegardés.
• Director -- pour définir le nom du Director et son mot de passe.
• Messages -- pour définir où les messages d'erreur et d'information doivent être envoyés.

La ressource Client

La ressource Client (ou File Daemon) définit le nom du Client (en tant que client du Director), ainsi que le port sur lequel le Client écoute les connections du Director.

Client (ou FileDaemon)

Début des enregistrements du client. Il ne doit y avoir qu'une seule ressource Client dans le fichier de configuration puisqu'il définit les propriétés du programme client courrant.

Name = <name>

Le nom du client qui doit être utilisé par le Director lors de la connection. Généralement, c'est une bonne idée d'utiliser un nom en relation avec la machine de faon à identifier facilement les messages d'erreur si vous avez plusieurs clients. Cette directive est requise.

Working Directory = <Directory>

Cette directive spécifie le répertoire dans lequel le File Daemon peut placer ses fichiers de statuts. Il ne devrait être utilisé que par Bacula, mais il peut être partagé par d'autres daemons Bacula, pourvu que les noms de daemons définis par la directive Name soient uniques pour chaque daemon. Cette directive est requise.

Sur les systèmes Win32, vous pouvez, dans certaines circonstances, être amené à spécifier une lettre de disque au niveau de la spécification du répertoire. Aussi, assurez-vous que ce répertoire est bien accessible en écriture par l'utilisateur SYSTEM, faute de quoi les restaurations peuvent échouer (le fichier bootstrap transféré au File Daemon par le Director est temporairement placé dans ce répertoire avant d'être transmis au Storage Daemon).

Pid Directory = <Directory>

Cette directive spécifie le répertoire dans lequel le Director peut placer son fichier d'Id de processus. Le fichier d'Id de processus est utilisé pour stopper Bacula et prévenir l'exécution simultanée de plusieurs copies de Bacula. Cette directive est requise. L'évaluation standard du shell de Directory est faite lorsque le fichier de configuration est lu, de sorte que des valeurs telles que $HOME seront correctement substituées.

Typiquement, sur les systèmes Linux, vous utiliserez la valeur /var/run pour cette directive. Si vous n'installez pas Bacula dans les répertoires du système, vous pouvez utiliser le Working Directory tel que défini ci-dessus.

Heartbeat Interval = <time-interval>

Cette directive définit un intervalle de temps. Chaque "pulsation" du Storage Daemon reue par le File Daemon est transmise au Director. De plus, si aucune pulsation n'est reue du Storage Daemon (et donc pas transmise au Director) le File Daemon envoie une pulsation à ces deux daemons afin de conserver les canaux actifs. La valeur par défaut est zéro, ce qui désactive les pulsations. Cette fonction est particulièrement utile si vous avez un routeur tels que les 3com qui ne suivent pas les standards Internet et expirent une connection valide après une courte période en dépit de l'activation de keepalive. Il en résulte en général un message "broken pipe error".

Si vous continuez de recevoir de messages broken pipe malgré Heartbeat Interval, et si vous utilisez Windows, vous devriez envisager de mettre à jour votre pilote ethernet. Il s'agit d'un problème connu des pilotes NVidia NForce 3 (4.4.2 17/05/2004). Vous pouvez aussi essayer la procédure suivante suggérée par Thomas Simmons pour les machines Win32 :

Démarrer > Panneau de configuration > connections réseau

Faites un click droit sur connection pour l'adaptateur nvidia et sélectionnez "propriétés". Sous l'onglet "Général", cliquez "Configurer...". Sous l'onglet "Avancé", désactivez l'option "Checksum Offload" et cliquez "Ok" pour sauvegarder la modification.

L'absence de communication, ou des interruptions dans les communications peuvent aussi être causées par des firewalls Linux si vous avez une règle qui limite les connections ou le trafic.

Right click the connection for the nvidia adapter and select properties. Under the General tab, click "Configure...". Under the Advanced tab set "Checksum Offload" to disabled and click OK to save the change.

Lack of communications, or communications that get interrupted can also be caused by Linux firewalls where you have a rule that throttles connections or traffic.

Maximum Concurrent Jobs = <number>

Où <number> est le nombre maximum de jobs qui peuvent être exécutés simultanément. La valeur par défaut est 2, mais vous pouvez mettre une valeur plus importante. Tout contact du Director (par exemple : requête de statut, de lancement de job...) est considéré comme un job, aussi, si vous souhaitez garder la possibilité de faire une requête de statut status dans la console alors qu'un job est en cours, vous devez régler cette valeur supérieure à 1.

FDAddresses = <IP-address-specification>

Spécifie les ports et adresses sur lesquels le Director écoute les connections de consoles Bacula. La meilleure explication est probalement un exemple :

 FDAddresses  = { 
 ip = { addr = 1.2.3.4; port = 1205; }
    ipv4 = {
        addr = 1.2.3.4; port = http; }
    ipv6 = {
        addr = 1.2.3.4;
        port = 1205;
    }
    ip = {
        addr = 1.2.3.4
        port = 1205
    }
    ip = { addr = 1.2.3.4 }
    ip = {
        addr = 201:220:222::2
    }
    ip = {
        addr = bluedot.thun.net
    }
 }

où ip, ip4, ip6, addr, et port sont tous des mots-clef. Notez que les adresses peuvent être spécifiées aussi bien en quadruplets pointés qu'en notation IPv6 double pointée ou avec des noms symboliques (seulement pour la la spécification d'ip). De même, les ports peuvent être spécifié sous forme de nombres, ou avec les valeurs mnémoniques du fichier /etc/services. Si un port n'est pas spécifié, la valeur par défaut est utilisée. Si une section ip est spécifiée, la résolution peut s'effectuer avec IPv4 et IPv6. Si ip4 est spécifié, alors seule la résolution IPv4 est permise, il en va de même avec ip6.

FDPort = <port-number>

Cette directive spécifie le numéro de port sur lequel le Client est en attente de connections du Director. Le numéro spécifié ici doit s'accorder avec le numéro FDPort spécifié dans la ressource Client du fichier de configuration du Director. La valeur par défaut est 9102.

FDAddress = <IP-Address>

Cette directive est optionnelle. Si elle est spécifiée, le serveur File Daemon (serveur pour les connections du Director) est alors lié à l'adresse spécifiée IP-Address, qui est soit un nom de domaine, soit une adresse IP spécifiée au format quadruplet pointé. Si cet enregistrement n'est pas spécifié, le File Daemon se lie alors à toute adresse disponible (c'est le comportement par défaut).

SDConnectTimeout = <time-interval>

Cette directive définit l'intervalle de temps durant lequel le File Daemon tente de se connecter au Storage Daemon. La valeur par défaut est 30 minutes Si aucune connection n'est établie durant cet intervalle, le File Daemon efface le Job.

Maximum Network Buffer Size = <bytes>

Où <bytes> spécifie la taille initiale du tampon réseau à utiliser avec le File Daemon. Cette taille sera revue à la baisse si elle est trop importante jusqu'à ce qu'elle soit acceptée par le système d'exploitation. Soyez circonspect avec cette directive car si la valeur est trop importante, elle sera diminuée par pas de 512 octets jusqu'à ce qu'elle convienne au système d'exploitation, ce qui peut requérir un grand nombre d'appels systèmes. La valeur par défaut est 32 768 octets.

Voici un exemple d'une définition de ressource Client valide :

Client {                              # this is me
  Name = rufus-fd
  WorkingDirectory = $HOME/bacula/bin/working
  Pid Directory = $HOME/bacula/bin/working
}

La ressource Director

La ressource Director définit le nom et le mot de passe des Directors autorisés à contacter ce client.

Director

Début des enregistrements de Director. Il peut y avoir un nombre quelconque de ressources Director dans le fichier de configuration du Client. Chacune définit un Director autorisé à contacter ce Client.

Name = <name>

Le nom du Director qui peut contacter ce Client. Ce nom doit être le même que celui spécifié au niveau de la ressource Director dans le fichier de configuration du Director. Cette directive est requise.

Password = <password>

Spécifie le mot de passe qui doit être fourni par le Director pour être autorisé. Ce mot de passe doit être le même que celui spécifié dans la ressource Client du fichier de configuration du Director. Cette directive est requise.

Monitor = <yes|no>

Si cette directive est réglée à no (valeur par défaut), ce Director dispose d'un accès total à ce Client. Dans le cas contraire (yes), ce Director est seulement autorisé à relever le statut courant de ce Client.

Veuillez noter que si ce Director est utilisé à des fins de surveillance, nous vous recommandons fortement de mettre cette directive à yes pour éviter de sérieux problèmes de sécurité.

Ainsi, plusieurs Directors peuvent être autorisés à utiliser les services de ce Client. Chaque Director aura un nom différent, et, en principe, un mot de passe différent.

Voici un exemple d'une définition de ressource Director valide :

#
# List Directors who are permitted to contact the File daemon
#
Director {
  Name = HeadMan
  Password = very_good                # password HeadMan must supply
}
Director {
  Name = Worker
  Password = not_as_good
  Monitor = Yes
}

La ressource Message

Voyez le chapitre La ressource Messages de ce manuel pour plus de détails sur la ressource Messages.

Il doit y avoir au moins une ressource Messages définie dans le fichier de configuration du Client.

Un exemple de fichier de configuration de Client

Voici un exemple de fichier de configuration de Client :

#
# Default  Bacula File Daemon Configuration file
#
#  For Bacula release 1.35.2 (16 August 2004) -- gentoo 1.4.16
#
# There is not much to change here except perhaps to
#   set the Director's name and File daemon's name
#   to something more appropriate for your site.
#
#
# List Directors who are permitted to contact this File daemon
#
Director {
  Name = rufus-dir
  Password = "/LqPRkX++saVyQE7w7mmiFg/qxYc1kufww6FEyY/47jU"
}
#
# Restricted Director, used by tray-monitor to get the
#   status of the file daemon
#
Director {
  Name = rufus-mon
  Password = "FYpq4yyI1y562EMS35bA0J0QC0M2L3t5cZObxT3XQxgxppTn"
  Monitor = yes
}
#
# "Global" File daemon configuration specifications
#
FileDaemon {                          # this is me
  Name = rufus-fd
  WorkingDirectory = $HOME/bacula/bin/working
  Pid Directory = $HOME/bacula/bin/working
}
# Send all messages except skipped files back to Director
Messages {
  Name = Standard
  director = rufus-dir = all, !skipped
}