From: Sebastien Guilbaud <sebastien.guilbaud@bull.net>
Date: Wed, 31 Mar 2010 07:10:39 +0000 (+0200)
Subject: Apply Sebastien's second French patch
X-Git-Tag: Release-5.2.1~134
X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=287561e9f4b80537b5949e62ca4948d1b51881f0;p=bacula%2Fdocs

Apply Sebastien's second French patch
---

diff --git a/docs/manuals/fr/utility/rpm-faq-fr.tex b/docs/manuals/fr/utility/rpm-faq-fr.tex
new file mode 100644
index 00000000..e9a81eff
--- /dev/null
+++ b/docs/manuals/fr/utility/rpm-faq-fr.tex
@@ -0,0 +1,397 @@
+
+%%
+%%
+
+\chapter{FAQ Création de paquets RPM Bacula}
+\label{RpmFaqChapter}
+\index[general]{FAQ!Bacula\textsuperscript{\textregistered} - RPM Packaging }
+\index[general]{Bacula\textsuperscript{\textregistered} - RPM Packaging FAQ }
+
+\section{FAQ}
+
+\subsection{Questions}
+
+\begin{enumerate}
+\item \ztitleref{faq1}  
+\item \ztitleref{faq2}  
+\item \ztitleref{faq3}  
+\item \ztitleref{faq4}  
+\item \ztitleref{faq5} 
+\item \ztitleref{faq6} 
+\item \ztitleref{faq7}
+\item \ztitleref{faq8}  
+\item \ztitleref{faq9}  
+\end{enumerate}
+
+\subsection{Réponses}
+   
+   \subsubsection{Comment compiler Bacula pour la plate-forme xxx?}\zlabel{faq1}
+   Le fichier de spec de Bacula contient des \texttt{define} permettant de le 
+   compiler pour plusieurs plates-formes :
+   \begin{itemize}
+   \item Red Hat 7.x (rh7), Red Hat 8.0 (rh8), Red Hat 9 (rh9),
+   \item Fedora Core (fc1, fc3, fc4, fc5, fc6, fc7, fc8),
+   \item Whitebox Enterprise Linux 3.0 (wb3),
+   \item Red Hat Enterprise Linux (rhel3, rhel4, rhel5),
+   \item Mandrake 10.x (mdk), Mandriva 2006.x (mdv), 
+   \item CentOS (centos3, centos4, centos5) 
+   \item Scientific Linux (sl3, sl4, sl5) and
+   \item SuSE (su9, su10, su102, su103, su110).
+   \end{itemize}
+   
+   La construction du paquet est contrôlée par un ensemble de \texttt{define}
+   obligatoires au début du fichier spec. Ces \texttt{define} sont là pour 
+   déterminer les informations de dépendances contenues dans les paquets RPM
+   résultants, ainsi que des options spécifiques à \texttt{configure}. 
+   Le \texttt{define} de plate-forme peut aussi être modifié directement dans
+   le fichier de spec (par défault tous les \texttt{define} sont à 0 ou "not set"
+   ). Par exemple, pour construire le paquet pour Redhat 7.x, il suffit de 
+   trouver la ligne suivante du fichier de spec :
+
+\footnotesize
+\begin{verbatim}
+        %define rh7 0
+\end{verbatim}
+\normalsize
+
+et de la modifier de la façon suivante :
+
+\footnotesize
+\begin{verbatim}
+        %define rh7 1
+\end{verbatim}
+\normalsize
+
+Une autre possibilité est de passer le define en ligne de commande de rpmbuild :
+
+\footnotesize
+\begin{verbatim}
+        rpmbuild -ba --define "build_rh7 1" bacula.spec
+        rpmbuild --rebuild --define build_rh7 1" bacula-x.x.x-x.src.rpm
+\end{verbatim}
+\normalsize
+
+   
+   \subsubsection{Comment décider quel sera le support des bases de données}\zlabel{faq2}
+   Un autre \texttt{define} obligatoire décide du support des bases de données
+   dans le binaire résultant, c'est un des suivants : 
+   \begin{itemize}
+   \item \texttt{build\_sqlite}
+   \item \texttt{build\_mysql}
+   \item \texttt{build\_postgresql}
+   \end{itemize}
+   Pour construire le paquet avec le support de MySQL, sans distinction de 
+   version, il faut modifier les lignes suivantes :
+
+\footnotesize
+\begin{verbatim}
+        %define mysql 0
+        OR
+        %define mysql4 0
+        OR
+        %define mysql5 0
+\end{verbatim}
+\normalsize
+
+en :
+
+\footnotesize
+\begin{verbatim}
+        %define mysql 1
+        OR
+        %define mysql4 1
+        OR
+        %define mysql5 1
+\end{verbatim}
+\normalsize
+
+dans le fichier de spec ou bien en les passant en ligne de commande à rpmbuild :
+
+\footnotesize
+\begin{verbatim}
+        rpmbuild -ba --define "build_rh7 1" --define "build_mysql 1" bacula.spec
+        rpmbuild -ba --define "build_rh7 1" --define "build_mysql4 1" bacula.spec
+        rpmbuild -ba --define "build_rh7 1" --define "build_mysql5 1" bacula.spec
+\end{verbatim}
+\normalsize
+
+   
+   \subsubsection{Quels autres defines peuvent être utilisés ?}\zlabel{faq3}
+   Trois autres defines à noter sont \texttt{depkgs\_version}, 
+   \texttt{docs\_version} et \texttt{\_rescuever}. Ces deux defines sont 
+   modifiés à chaque release et doivent correspondre à la version des sources
+   utilisées pour construire les paquets. En temps normal, vous n'avez pas 
+   besoin de les omdifier. Voyez aussi la section "Build Options" plus bas pour
+   les autres options de construction qui peuvent être passées en ligne de 
+   commande.
+  
+   \subsubsection{Je rencontre des erreurs de permissions quand j'essaie de
+   construire les paquets. Dois-je être root ?}\zlabel{faq4}
+   Non, vous n'avez pas besoin d'être root, et c'est en fait une bonne habitude
+   de construire les paquets RPM en utilisateur non privilégié. Les paquets de
+   Bacula sont prévus pour être construits en tant qu'utilisateur normal, mais 
+   vous devez effectuez quelques modifications à votre système pour que cela
+   fonctionne. Si vous construisez les paquets sur votre propre système, la 
+   méthode la plus simple est d'ajouter des permissions en écriture à tout le 
+   monde sur les répertoires de construction (/usr/src/redhat/, /usr/src/RPM or
+   /usr/src/packages).  
+   Pour ce faire, tapez les commandes suivantes en tant que root :
+
+\footnotesize
+\begin{verbatim}
+        chmod -R 777 /usr/src/redhat
+        chmod -R 777 /usr/src/RPM
+        chmod -R 777 /usr/src/packages
+\end{verbatim}
+\normalsize
+
+Si vous travaillez sur un système partagé où vous ne pouvez pas utliser la 
+méthode ci-dessus, vous devez créer l'arborescence ci-dessus dans votre 
+répertoire personnel (home).  Créez ensuite un fichier appelé {\tt .rpmmacros} 
+dans votre répertoire pesonnel (ou modifiez le fichier s'il existe déjà) pour
+avoir le contenu de fichier suivant :
+
+\footnotesize
+\begin{verbatim}
+        %_topdir /home/myuser/redhat
+        %_tmppath /tmp
+\end{verbatim}
+\normalsize
+
+Une autre directive pratique pour empêcher la création de paquets RPM de debug
+peut être ajoutée à votre fichier {\tt .rpmmacros} :
+
+\footnotesize
+\begin{verbatim}
+        %debug_package %{nil}
+\end{verbatim}
+\normalsize
+
+   
+   \subsubsection{Je construis mes propres RPMs mais sur toutes les 
+   plates-formes, j'ai une dépendance non résolue sur /usr/afsws/bin/pagsh.}
+   \zlabel{faq5}
+   C'est un shell de l'OpenAFS (Andrew File System).  Si vous rencontrez cette
+   erreur, c'est que vous avez choisi d'inclure le répertoire docs/examples dans
+   votre paquet. Un des scripts d'exemple de ce répertoire est un script pagsh.
+   Quand {\tt rpmbuild} analyse les dépendances, il vérifie la présence de la
+   ligne shebang de tous les scripts inclus dans le package, en plus des 
+   vérifications de librairies partagées. Pour ne pas avoir cette dépendance, il
+   ne faut pas include le répertoire des exemples dans le paquet. Si vous 
+   rencontrez de problème, vous devez être en train de construire un paquet
+   d'une très vieille version de Bacula, car les exemples ont été supprimés du
+   paquet de documentation.
+      
+   \subsubsection{Je construis mes propres RPMs car vous ne les fournissez pas
+   pour ma plate-forme. Puis-je publier mes paquets sur Sourceforge pour qu'ils
+   servent à d'autres ?}\zlabel{faq6}
+   Oui, les contributions de la part d'utilisateurs sont acceptées et bien sûr
+   appréciées ! Consultez le répertoire \texttt{platforms/contrib-rpm} dans les
+   sources pour plus de détails.
+
+   \subsubsection{Existe-t'il une solution plus simple que d'utiliser toutes ces
+   options en ligne de commmande ?}\zlabel{faq7}
+   Oui, il y a un assistant graphique que vous pouvez utiliser pour construire
+   le paquet src RPM. Vous trouverez dans les sources le script
+   \texttt{platforms/contrib-rpm/rpm\_wizard.sh}, il vous permettra de spécifier
+   les options de construction en passant par une interface graphique GNOME. Ce
+   script nécessite d'avoir zenity installé.
+   
+   \subsubsection{Je viens juste mettre à jour Bacula de la version 1.36.x en
+   1.38.x et le Director Daemon ne démarre plus. Il semble démarrer mais plante
+   en silence, et j'ai une erreur "connection refused" quand je démarre la 
+   console.} \zlabel{faq8}
+   A partir de la version 1.38, les paquets RPMS sont paramétrés pour exécuter
+   les daemons Director et Storage en tant qu'utilisateur non privilégié 
+   (non-root). Le File Daemon est exécuté en tant qu'utilisateur root et groupe
+   bacula, le Storage Daemon en tant qu'utilisateur bacula et groupe disk, et le
+   Director en tant qu'utilisateur bacula et groupe bacula. Lors de la mise à 
+   jour, il faut modifier les droits sur certains fichier pour que tout 
+   fonctionne.   Lancez les commandes suivantes en tant que root :
+
+\footnotesize
+\begin{verbatim}
+        chown bacula.bacula /var/bacula/*
+        chown root.bacula /var/bacula/bacula-fd.9102.state
+        chown bacula.disk /var/bacula/bacula-sd.9103.state
+\end{verbatim}
+\normalsize
+
+Ensuite, si vous utilisez des volumes de type File plutôt que des bandes, ces
+fichiers devront appartenir à l'utilisateur bacula et au groupe bacula.
+  
+   \subsubsection{Il y a beaucoup de paquets RPM, duquel ai-je besoin pour quel
+   rôle ?}\zlabel{faq9}
+   Pour un serveur Bacula, vous devez choisir le paquet suivant le système de 
+   base de données que vous utiliserez pour le catalogue : c'est soit
+   bacula-mysql, bacula-postgresql ou bacula-sqlite. Si votre système ne fournit
+   pas de paquet pour mtx, vous devez installer bacula-mtx pour satisfaire la
+   dépendance. Pour une machine client, vous devez seulement installer 
+   bacula-client. Pour soit un serveur ou uyn client, vous pouvez installer 
+   les consoles graphiques bacula-gconsole et/ou bacula-wxconsole. BAT (Bacula
+   Administration Tool) est installé par le paquet bacula-bat. Pour finir, le
+   paquet bacula-updatedb est requis seulement lors des mises à jour d'un 
+   serveur, de plus d'un niveau de révision de base de données. 
+
+
+\section{Support for RHEL3/4/5, CentOS 3/4/5, Scientific Linux 3/4/5 and x86\_64}
+
+Les exemples ci-dessous démontrent des constructions avec le support 
+   explicite de la RHEL4 et de la CentOS4. Le support de l'architecture x86\_64 
+   a également été ajouté. 
+
+   Lancez la construction avec une de ces trois commandes :
+
+\footnotesize
+\begin{verbatim}
+rpmbuild --rebuild \
+        --define "build_rhel4 1" \
+        --define "build_sqlite 1" \
+        bacula-1.38.3-1.src.rpm
+
+rpmbuild --rebuild \
+        --define "build_rhel4 1" \
+        --define "build_postgresql 1" \
+        bacula-1.38.3-1.src.rpm
+
+rpmbuild --rebuild \
+        --define "build_rhel4 1" \
+        --define "build_mysql4 1" \
+        bacula-1.38.3-1.src.rpm
+\end{verbatim}
+\normalsize
+
+Pour la CentOS, indiquez {\tt--define "build\_centos4 1"} à la place de rhel4. 
+Pour la Scientific Linux, indiquez {\tt--define "build\_sl4 1"} à la place de 
+rhel4.
+
+Pour le support du 64 bits, ajoutez {\tt--define "build\_x86\_64 1"}
+
+\section{Options de construction}
+\index[general]{Options de construction}
+Le fichier de spec supporte actuellement la construction sur les plateformes
+suivantes :
+\footnotesize
+\begin{verbatim}
+Red Hat builds
+--define "build_rh7 1"
+--define "build_rh8 1"
+--define "build_rh9 1"
+
+Fedora Core build
+--define "build_fc1 1"
+--define "build_fc3 1"
+--define "build_fc4 1"
+--define "build_fc5 1"
+--define "build_fc6 1"
+--define "build_fc7 1"
+--define "build_fc8 1"
+--define "build_fc9 1"
+
+Whitebox Enterprise build
+--define "build_wb3 1"
+
+Red Hat Enterprise builds
+--define "build_rhel3 1"
+--define "build_rhel4 1"
+--define "build_rhel5 1"
+
+CentOS build
+--define "build_centos3 1"
+--define "build_centos4 1"
+--define "build_centos5 1"
+
+Scientific Linux build
+--define "build_sl3 1"
+--define "build_sl4 1"
+--define "build_sl5 1"
+
+SuSE build
+--define "build_su9 1"
+--define "build_su10 1"
+--define "build_su102 1"
+--define "build_su103 1"
+--define "build_su110 1"
+--define "build_su111 1"
+
+Mandrake 10.x build
+--define "build_mdk 1"
+
+Mandriva build
+--define "build_mdv 1"
+
+MySQL support:
+for mysql 3.23.x support define this
+--define "build_mysql 1"
+if using mysql 4.x define this,
+currently: Mandrake 10.x, Mandriva 2006.0, SuSE 9.x & 10.0, FC4 & RHEL4
+--define "build_mysql4 1"
+if using mysql 5.x define this,
+currently: SuSE 10.1 & FC5
+--define "build_mysql5 1"
+
+PostgreSQL support:
+--define "build_postgresql 1"
+
+Sqlite support:
+--define "build_sqlite 1"
+
+Build the client rpm only in place of one of the above database full builds:
+--define "build_client_only 1"
+
+X86-64 support:
+--define "build_x86_64 1"
+
+Supress build of bgnome-console:
+--define "nobuild_gconsole 1"
+
+Build the WXWindows console:
+requires wxGTK >= 2.6
+--define "build_wxconsole 1"
+
+Build the Bacula Administration Tool:
+requires QT >= 4.2
+--define "build_bat 1"
+
+Build python scripting support:
+--define "build_python 1"
+
+Modify the Packager tag for third party packages:
+--define "contrib_packager Your Name <youremail@site.org>"
+
+Install most files to /opt/bacula directory:
+--define "single_dir_install 1"
+
+Build the rescue files:
+--define "build_rescue 1"
+
+\end{verbatim}
+\normalsize
+
+\section{Problèmes d'installation de RPMs}
+\index[general]{Problèmes d'installation de RPMs}
+Une fois qu'ils sont correctement construits, les paquets RPM s'installent en
+général sans problème. Toute fois, certains problèmes peuvent se déclarer au
+lancement des daemons :
+\begin{itemize}
+\item Mauvaises permissions sur /var/bacula : par défaut, les daemons Director 
+    Storage ne sont pas exécutés en root. Si /var/bacula appartient à root, il
+    est possible que les daemons Director et Storage ne soient pas capables 
+    d'accéder à ce répertoire, alors que c'est leur répertoire de travail 
+    (Working Directory). Pour corriger celà, la méthode la plus simple est :
+    \verb+chown bacula:bacula /var/bacula+.\\
+  Note : à partir de la version 1.38.8, le répertoire /var/bacula est créé avec
+  des permissions en mode 770 et un propriétaire à root:bacula.
+\item Le Storage daemon ne peut pas accéder au lecteur de bandes : ceci peut 
+    arriver dans des anciennes versions de paquets RPM où le Storage Daemon
+    fonctionnait sous l'identité userid bacula, groupe bacula. Il y a deux
+    méthodes pour corriger ceci : la meilleure reste de modifier le script de
+    démarrage /etc/init.d/bacula-sd pour que le Storage daemon soit lancé sous
+    le groupe "disk". La seconde méthode est de changer les droits sur le 
+    device du lecteur de bande (habituellement /dev/nst0) pour que Bacula puisse
+    y accéder. Vous devrez certainement aussi changer les permissions sur le
+    device de contrôle SCSI, habituellement /dev/sg0. Les noms exacts de device
+    dépendent de votre configuration, référez-vous au chapitre "Tape Testing"
+    pour plus d'informations sur les devices.
+\end{itemize}
+ 
diff --git a/docs/manuals/fr/utility/utility.tex b/docs/manuals/fr/utility/utility.tex
index 9dfc1da2..3b4dccb7 100644
--- a/docs/manuals/fr/utility/utility.tex
+++ b/docs/manuals/fr/utility/utility.tex
@@ -29,6 +29,7 @@
 \usepackage[utf8]{inputenc}
 \usepackage[francais]{babel}
 \usepackage{alltt}
+\usepackage[titleref,user]{zref}
 
 \makeindex
 \newindex{general}{idx}{ind}{Index Général}
@@ -72,7 +73,7 @@
 
 \include{progs-fr}
 \include{bimagemgr-chapter-fr}
-\include{rpm-faq}
+\include{rpm-faq-fr}
 \include{fdl}