Mise a jour de dirddconf.tex. Debut 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 

Specify the ports and addresses on which the Director daemon will listen
   for Bacula Console connections.  Probably the simplest way to explain is
   to show an example:

\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

where ip, ip4, ip6, addr, and port are all keywords. Note, that  the address
can be specified as either a dotted quadruple, or  IPv6 colon notation, or as
a symbolic name (only in the ip specification).  Also, port can be specified
as a number or as the mnemonic value from  the /etc/services file.  If a port
is not specified, the default will be used. If an ip  section is specified,
the resolution can be made either by IPv4 or  IPv6. If ip4 is specified, then
only IPv4 resolutions will be permitted,  and likewise with ip6.  

\item [FDPort = \lt{}port-number\gt{}]
   \index[console]{FDPort  }
   This specifies the port number  on which the Client listens for Director
connections. It must agree  with the FDPort specified in the Client resource
of the Director's  configuration file. The default is 9102. 

\item [FDAddress = \lt{}IP-Address\gt{}]
   \index[console]{FDAddress  }
   This record is optional,  and if it is specified, it will cause the File
daemon server (for  Director connections) to bind to the specified {\bf
IP-Address},  which is either a domain name or an IP address specified as a 
dotted quadruple. If this record is not specified, the File daemon  will bind
to any available address (the default). 

\item [SDConnectTimeout = \lt{}time-interval\gt{}]
   \index[console]{SDConnectTimeout  }
   This  record defines an interval of time that  the File daemon will try to
connect to the  Storage daemon. The default is 30 minutes. If no connection 
is made in the specified time interval, the File daemon  cancels the Job. 

\item [Maximum Network Buffer Size = \lt{}bytes\gt{}]  
   \index[console]{Maximum Network Buffer Size  }
   where \lt{}bytes\gt{} specifies the initial network buffer  size to use with
the File daemon. This size will be adjusted down  if it is too large until it
is accepted by the OS. Please use  care in setting this value since if it is
too large, it will  be trimmed by 512 bytes until the OS is happy, which may
require  a large number of system calls. The default value is 32,768 bytes. 
\end{description}

The following is an example of a valid Client resource definition: 

\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*{The Director Resource}
\label{DirectorResource}
\index[general]{Director Resource }
\index[general]{Resource!Director }
\addcontentsline{toc}{subsection}{Director Resource}

The Director resource defines the name and password of the Directors that are
permitted to contact this Client. 

\begin{description}

\item [Director]
   \index[fd]{Director }
   Start of the Director records. There may be any  number of Director resources
in the Client configuration file. Each  one specifies a Director that is
allowed to connect to this  Client. 

\item [Name = \lt{}name\gt{}]
   \index[fd]{Name  }
   The name of the Director  that may contact this Client. This name must be the 
same as the name specified on the Director resource  in the Director's
configuration file. This record is required. 

\item [Password = \lt{}password\gt{}]
   \index[fd]{Password  }
   Specifies the password that must be  supplied for a Director to be authorized.
This password  must be the same as the password specified in the  Client
resource in the Director's configuration file.  This record is required. 

\item [Monitor = \lt{}yes|no\gt{}]
   \index[fd]{Monitor  }
   If Monitor is set to {\bf no} (default),  this director will have full access
to this Client. If Monitor is set to  {\bf yes}, this director will only be
able to fetch the current status  of this Client.

Please note that if this director is being used by a Monitor, we highly 
recommend to set this directive to {\bf yes} to avoid serious security 
problems. 
\end{description}

Thus multiple Directors may be authorized to use this Client's services. Each
Director will have a different name, and normally a different password as
well. 

The following is an example of a valid Director resource definition: 

\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*{The Message Resource}
\label{MessagesResource}
\index[general]{Message Resource }
\index[general]{Resource!Message }
\addcontentsline{toc}{subsection}{Message Resource}

Please see the 
\ilink{Messages Resource}{_ChapterStart15} Chapter of this
manual for the details of the Messages Resource. 

There must be at least one Message resource in the Client configuration file. 

\subsection*{Example Client Configuration File}
\label{SampleClientConfiguration}
\index[general]{Example Client Configuration File }
\index[general]{File!Example Client Configuration }
\addcontentsline{toc}{subsection}{Example Client Configuration File}

An example File Daemon configuration file might be the following: 

\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