
%%
%%

\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}
 
