Fin de filedconf.tex

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

%%
%%

\section*{Configuration du Client/File Daemon}
\label{_ChapterStart25}
\index[general]{Configuration!Client/File daemon }
\index[general]{Client/File daemon Configuration }
\addcontentsline{toc}{section}{Client/File daemon Configuration}

\subsection*{General}
\index[general]{General }
\addcontentsline{toc}{subsection}{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 \ilink{Configuration}{_ChapterStart16} de ce manuel. 
Les ressources suivantes doivent être définies :

\begin{itemize}
\item 
   \ilink{Client}{ClientResource} -- pour définir les clients qui doivent être 
   sauvegardés.
\item 
   \ilink{Director}{DirectorResource} -- pour définir le nom du Director et son 
   mot de passe.
\item 
   \ilink{Messages}{_ChapterStart15} -- pour définir où les messages d'erreur et 
   d'information doivent être envoyés.
\end{itemize}

\subsection*{La ressource Client}
\label{ClientRessource}
\index[general]{Ressource!Client }
\index[general]{Client Ressource }
\addcontentsline{toc}{subsection}{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.

\begin{description}

\item [Client (ou FileDaemon)]
   \index[fd]{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.

\item [Name = \lt{}name\gt{}]
   \index[fd]{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 façon à identifier facilement les messages d'erreur si vous avez 
   plusieurs clients. Cette directive est requise.

\item [Working Directory = \lt{}Directory\gt{}]
   \index[fd]{Working 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 {\bf 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).
   
\item [Pid Directory = \lt{}Directory\gt{}]
   \index[fd]{Pid 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 
    {\bf Directory} est faite lorsque le fichier de configuration est lu, de 
    sorte que des valeurs telles que {\bf \$HOME} seront correctement 
    substituées.

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

\item [Heartbeat Interval = \lt{}time-interval\gt{}]
   \index[fd]{Heartbeat Interval  }
   \index[general]{Heartbeat Interval}
   \index[general]{Broken pipe}
   Cette directive définit un intervalle de temps. Chaque "pulsation" 
   du Storage Daemon reçue par le File Daemon est transmise au Director. 
   De plus, si aucune pulsation n'est reçue 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 {\it keepalive}. Il en résulte en général 
   un message "broken pipe error".

   Si vous continuez de recevoir de messages broken pipe malgré 
   {\bf 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 \gt{} Panneau de configuration \gt{} 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.


\item [Maximum Concurrent Jobs = \lt{}number\gt{}]
   \index[fd]{Maximum Concurrent Jobs  }
   Où \lt{}number\gt{} 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 {\bf status} dans la console alors qu'un job est en cours, vous 
   devez régler cette valeur supérieure à 1.
   

\item [FDAddresses = \lt{}IP-address-specification\gt{}]
   \index[console]{FDAddresses  }
   Spécifie les ports et adresses sur lesquels le Director écoute les connections 
   de consoles Bacula. La meilleure explication est probalement un exemple :

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

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.

\item [FDPort = \lt{}port-number\gt{}]
   \index[console]{FDPort  }
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.

\item [FDAddress = \lt{}IP-Address\gt{}]
   \index[console]{FDAddress  }
  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 
{\bf 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).

\item [SDConnectTimeout = \lt{}time-interval\gt{}]
   \index[console]{SDConnectTimeout  }
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.

\item [Maximum Network Buffer Size = \lt{}bytes\gt{}]  
   \index[console]{Maximum Network Buffer Size  }
Où \lt{}bytes\gt{} 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.
\end{description}

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

\footnotesize
\begin{verbatim}
Client {                              # this is me
  Name = rufus-fd
  WorkingDirectory = $HOME/bacula/bin/working
  Pid Directory = $HOME/bacula/bin/working
}
\end{verbatim}
\normalsize

\subsection*{La ressource Director}
\label{DirectorResource}
\index[general]{La ressource Director}
\index[general]{Resource!Director }
\addcontentsline{toc}{subsection}{Director Ressource}
La ressource Director définit le nom et le mot de passe des Directors 
autorisés à contacter ce client.

\begin{description}

\item [Director]
   \index[fd]{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.

\item [Name = \lt{}name\gt{}]
   \index[fd]{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.

\item [Password = \lt{}password\gt{}]
   \index[fd]{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.

\item [Monitor = \lt{}yes|no\gt{}]
   \index[fd]{Monitor  }
   Si cette directive est réglée à {\bf no} (valeur par défaut), ce Director 
   dispose d'un accès total à ce Client. Dans le cas contraire ({\bf 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 à {\bf yes} pour 
   éviter de sérieux problèmes de sécurité.
\end{description}

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 :

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

\subsection*{La ressource Message}
\label{MessagesResource}
\index[general]{La ressource Message}
\index[general]{Ressource!Message }
\addcontentsline{toc}{subsection}{Ressource Message}
Voyez le chapitre \ilink{La ressource Messages}{_ChapterStart15} 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.

\subsection*{Un exemple de fichier de configuration de Client}
\label{SampleClientConfiguration}
\index[general]{Exemple fichier configuration Client }
\index[general]{Fichier!Exemple configuration Client}
\addcontentsline{toc}{subsection}{Exemple fichier de configuration Client}

Voici un exemple de fichier de configuration de Client :

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