%%
%%

\section*{Installer et configurer PostgreSQL}
\label{_ChapterStart10}
\index[general]{PostgreSQL!Installer et configurer }
\index[general]{Installer et configurer PostgreSQL }
\addcontentsline{toc}{section}{Installer et configurer PostgreSQL}

\subsection*{Installer et configurer PostgreSQL -- Phase I}
\index[general]{Installer et configurer PostgreSQL -- Phase I }
\index[general]{Phase I!Installer et configurer PostgreSQL -- }
\addcontentsline{toc}{subsection}{Installer et configurer PostgreSQL -- Phase
I}

Attention !!! Si vous envisagez d'utiliser PostgreSQL, vous devriez 
\^etre conscient de la philosophie des mises \`a jour de PostgreSQL qui 
peut \^etre d\'estabilisant dans un environnement de 
production. En gros, pour chaque mise \`a jour vers une version majeure, 
vous devez exporter vos bases de donn\'ees au format ASCII, faire la 
mise \`a jour, et recharger vos bases de donn\'ees. Ceci est d\^u au \`a des 
mises \`a jour fr\'equentes du "format de donn\'ees" d'une version \`a l'autre, 
et aucun outil n'est fourni pour effectuer la conversion automatiquement. 
Si vous omettez d'exporter vos bases au format ASCII, elles peuvent 
devenir compl\`etement inutiles si aucun des nouveaux outils ne peut y 
acc\'eder en raison d'un changement de format, auquel cas le serveur 
PostgreSQL sera dans l'incapacit\'e de d\'emarrer. 

Si vous avez utilis\'e l'option {\bf ./configure
\verb{--{with-postgresql=PostgreSQL-Directory} pour configurer {\bf Bacula}, vous
avez besoin d'installer la version 7.3 ou sup\'erieure de PostgreSQL.
ATTENTION! Les versions pr\'ealables \`a la 7.3 ne fonctionnent pas avec
Bacula. Si PostgreSQL est install\'e dans ses r\'epertoires sandards, seule
l'option {\bf \verb{--{with-postgresql} est n\'ecessaire, le programme de
configuration scrutant tous les r\'epertoires standards. Si PostgreSQL est
install\'e dans votre r\'epertoire de travail ou dans un r\'epertoire
atypique, il faut pr\'eciser l'option {\bf \verb{--{with-postgresql} suivie du
r\'epertoire {\it ad hoc}. 

Installer et configurer PostgreSQL n'est pas compliqu\'e mais peut \^etre
d\'eroutant la premi\`ere fois. Si vous pr\'ef\'erez, vous pouvez utiliser le
paquet de votre distribution. Les paquets binaires sont disponibles sur la
plupart des mirroirs de PostgreSQL. 

Si vous pr\'ef\'erez installer PostgreSQL \`a partir des sources, nous vous
recommandons de suivre les instructions de la 
\elink{documentation PostgreSQL}{http://www.postgresql.org/docs/}. 

Si vous utilisez PostgreSQL pour FreeBSD, 
\elink{cet article}{http://www.freebsddiary.org/postgresql.php} vous sera peut
\^etre utile. M\^eme si vous n'utilisez pas FreeBSD, l'article contient des
informations utiles \`a la configuration et au param\'etrage de PostgreSQL. 

Apr\`es l'installation de PostgreSQL, terminez l'installation de {\bf Bacula}.
Ensuite, quand Bacula sera install\'e, reprenez ce chapitre pour terminer
l'installation. Notez que les fichiers d'installation utilis\'es dans cette
seconde phase de l'installation de PostgreSQL sont cr\'e\'es durant
l'installation de Bacula. 
\label{PostgreSQL_phase2}

\subsection*{Installer et configurer PostgreSQL -- Phase II}
\index[general]{Phase II!Installer et configurer PostgreSQL -- }
\index[general]{Installer et configurer PostgreSQL -- Phase II }
\addcontentsline{toc}{subsection}{Installer et configurer PostgreSQL -- Phase
II}

Si vous en \^etes l\`a, vous avez construit et install\'e PostgreSQL, ou vous
aviez d\'ej\`a un serveur PostgreSQL existant et vous avez configur\'e et
install\'e {\bf Bacula}. Dans le cas contraire, nous vous invitons \`a le
faire avant de poursuivre. 

Notez bien que la commande {\bf ./configure} utilis\'ee pour
construire {\bf Bacula} n\'ecessite d'ajouter l'option {\bf
\verb{--{with-postgresql=repertoire\_de\_PostgreSQL}, o\`u {\bf
repertoire\_de\_PostgreSQL} sp\'ecifie le chemin de PostgreSQL indiqu\'e \`a
la commande ./configure. (si vous n'avez pas sp\'ecifi\'e de r\'epertoire ou
si PostgreSQL est install\'e dans son r\'epertoire par d\'efaut, cette option
n'est pas n\'ecessaire). Cette option est n\'ecessaire pour que Bacula puisse
trouver les fichiers d'en-t\^ete et les librairies d'interface \`a PostgreSQL.


{\bf Bacula} installe les scripts pour la gestion de la base de donn\'ees
(cr\'eer, d\'etruire, cr\'eer les tables, etc.) dans le r\'epertoire principal
de l'installation. Ces fichiers sont de la forme *\_bacula\_* (par exemple
create\_bacula\_database). Ces fichiers sont \'egalement disponibles dans le
r\'epertoire \lt{}bacula-src\gt{}/src/cats apr\`es que la commande ./configure
ait \'et\'e lanc\'ee. Si vous consultez le fichier create\_bacula\_database,
vous verrez qu'il fait appel \`a create\_postgresql\_database. Les fichiers
*\_bacula\_* sont fournis pour faciliter les choses. Peu importe la base de
donn\'ees choisie, create\_bacula\_database cr\'eera la base de donn\'ees. 

Maintenant vous allez cr\'eer la base de donn\'ees PostgreSQL et les tables
utilis\'ees par Bacula. On pr\'esume dans la suite que votre serveur
PostgreSQL fonctionne. Vous devez ex\'ecuter les diff\'erentes \'etapes
ci-dessous en tant qu'utilisateur autoris\'e \`a cr\'eer des bases. Ceci peut
\^etre fait avec l'utilisateur PostgreSQL (sur la plupart des syst\`emes il
s'agit de pgsql. NDT: sur debian il s'agit de postgres) 

\begin{enumerate}
\item cd \lt{}r\'epertoire\_d\_installation\gt{}

   Ce r\'epertoire contient le catalogue des routines d'interfaces.  

\item ./create\_bacula\_database

   Ce script cr\'e\'e le catalogue {\bf bacula} PostgreSQL. S'il \'echoue, 
   c'est probablement que vous n'avez pas les droits requis sur la 
   base de donn\'ees. Sur la plupart des syst\`emes, le propri\'etaire de 
   la base de donn\'ees est {\bf pgsql}, et sur d'autres tels que RedHat ou 
   Fedora, c'est {\bf postgres}. Vous pouvez d\'eterminer lequel en examinant 
   le fichier /etc/passwd. Pour cr\'eer un nouvel utilisateur avec votre nom 
   ou le nom {\bf bacula}, vous pouvez faire ce qui suit :
      
\begin{verbatim}
   su
   (entrez le mot de passe root)
   su pgsql (ou postgres)
   createuser kern (ou peut-\^etre bacula)
   Shall the new user be allowed to create databases? (y/n) y
   Shall the new user be allowed to create more new users? (y/n) (choisissez ce que vous voulez)
   exit
\end{verbatim}


    A ce stade, vous devriez pouvoir ex\'ecuter la commande ./create\_bacula\_database

\item ./make\_bacula\_tables

   Cr\'e\'ee les tables utilis\'ees par {\bf Bacula}.  
\item ./grant\_bacula\_privileges

   Cr\'e\'ee l'utilisateur de la base de donn\'ees {\bf bacula} avec des droits
d'acc\`es restreints. Vous pouvez modifier ce script pour cadrer avec votre
propre configuration. Attention, cette base n'est pas prot\'eg\'ee par un mot
de passe.  

\end{enumerate}

Chacun de ces scripts (create\_bacula\_database, make\_bacula\_tables et
grant\_bacula\_privileges) permet l'ajout d'arguments en ligne de commande.
Ceci peut \^etre utile pour sp\'ecifier le nom de l'utilisateur. Par exemple,
vous pouvez avoir besoin d'ajouter {\bf -h nom\_d\_hote} \`a la ligne de
commande pour sp\'ecifier le serveur de base de donn\'ees distant. 

Pour avoir un bon aper{\c c}u des droits d'acc\`es que vous avez sp\'ecifi\'e
vous pouvez utiliser la commande 

\footnotesize
\begin{verbatim}

repertoire_de_PostgreSQL/bin/psql --command \\dp bacula
\end{verbatim}
\normalsize

J'ai rencontr\'e un probl\`eme de permissions avec le mot de passe. J'ai finalement 
du modifier mon fichier  {\bf pg\_hba.conf} (situ\'e dans /var/lib/pgsql/data sur ma 
machine) :

\footnotesize
\begin{verbatim}
de
  local   all    all        ident  sameuser
vers
  local   all    all        trust  sameuser
\end{verbatim}
\normalsize

Ceci a r\'esolu le probl\`eme pour moi, mais ce n'est pas pas forc\'ement une bonne 
chose du point de vue de la s\'ecurit\'e, mais j'ai ainsi pu ex\'ecuter mes scripts de 
r\'egression sans mot de passe.

Un moyen plus s\'ecuris\'e pour l'authentification aupr\`es de la base de donn\'ees 
consiste \`a utiliser le hachage MD5 des mots de passe. Pour cela, \'editez les 
fichier {\bf pg\_hba.conf}, et ajoutez ajoutez ce qui suit juste avant les lignes 
"local" et "host" existantes :

\footnotesize
\begin{verbatim}
  local bacula bacula md5
\end{verbatim}
\normalsize

Puis red\'emarrez le {\it daemon} Postgres (la plupart du temps, avec 
 "/etc/init.d/postgresql restart") pour activer cette nouvelle r\`egle 
d'authentification.

Ensuite, en tant qu'administrateur Postgres (connectez-vous en tant 
qu'utilisateur postgres ou en utilisant {\bf su} pour devenir root, puis 
 {\bf su postgres}), ajoutez un mot de passe \`a la base de donn\'ees bacula 
pour l'utilisateur bacula avec les commandes suivantes :

\footnotesize
\begin{verbatim}
  \$ psql bacula
  bacula=# alter user bacula with password 'secret';
  ALTER USER
  bacula=# \\q
\end{verbatim}
\normalsize

Enfin, il vous faudra ajouter ce mot de passe en deux endroits du fichier 
bacula-dir.conf : au niveau de la ressource Catalog et au niveau de la 
directive RunBeforeJob de la ressource Job BackupCatalog. Avec les mots de 
passe en place, ces deux lignes devraient ressembler \`a ceci :

\footnotesize
\begin{verbatim}
  dbname = bacula; user = bacula; password = "secret"
    ... and ...
  RunBeforeJob = "/etc/make_catalog_backup bacula bacula secret"
\end{verbatim}
\normalsize

Naturellement, vous devriez choisir un meilleur mot de passe, et vous assurer 
que le fichier bacula-dir.conf qui contient ce mot de passe n'est lisible 
que par root.

M\^eme avec ces restrictions, il reste un probl\`eme de s\'ecurit\'e avec cette approche : 
sur certaines plateformes, la variable d'environnement utilis\'ee pour soumettre le 
mot de passe \`a Postgres est disponible pour tout utilisateur 
local du syst\`eme. Pour supprimer ce probl\`eme, l'\'equipe Postgres a d\'ecr\'et\'e 
obsol\`ete ce m\'ecanisme de passage de mot de passe par variable d'environnement et 
recommande d'utiliser un fichier .pgpass. Pour utiliser ce m\'ecanisme, cr\'eez un fichier 
nomm\'e .pgpass vcontenant une simple ligne :

\footnotesize
\begin{verbatim}
  localhost:5432:bacula:bacula:secret
\end{verbatim}
\normalsize

Ce fichier devrait \^etre copi\'e dans les r\'epertoires personnels (NDT : home directories) 
de tous les comptes susceptibles d'avoir besoin d'acc\'eder \`a la base de donn\'ees : 
typiquement, il s'agit de root, bacula et tout utilisateur de la console Bacula. Les fichiers 
doivent appartenir aux utilisateur et groupe correspondant : root:root pour la copie 
dans ~root, etc. Les permissions doivent \^etre positionn\'ees \`a 600 pour limiter 
l'acc\`es au propri\'etaire du fichier.

\subsection*{R\'einitialiser la base des catalogues (de sauvegardes)}
\index[general]{R\'einitialiser la base des catalogues (de sauvegardes) }
\index[general]{Sauvegardes!R\'einitialiser la base des catalogues de }
\addcontentsline{toc}{subsection}{R\'einitialiser la base des catalogues (de
sauvegardes)}

Apr\`es avoir fait un certain nombre de tests avec {\bf Bacula}, vous aurez
tr\`es certainement envie de nettoyer le catalogue des sauvegardes et faire
dispara{\^\i}tre tous les travaux de tests que vous avez lanc\'es. Pour ce
faire, vous pouvez ex\'ecuter les commandes suivantes: 

\footnotesize
\begin{verbatim}

  cd <r\'epertoire_d_installation>
  ./drop_bacula_tables
  ./make_bacula_tables
  ./grant_bacula_privileges
\end{verbatim}
\normalsize

Attention! Toutes les informations contenues dans cette base seront perdues et
vous repartirez de z\'ero. Si vous avez \'ecrit sur certains volumes (m\'edia
de sauvegarde), vous devrez \'ecrire une marque de fin de fichier (EOF) sur
chacun d'eux afin que {\bf Bacula} puisse les r\'eutiliser. Pour ce faire: 

\footnotesize
\begin{verbatim}

   (arr\^eter Baula ou demonter les volumes)
   mt -f /dev/nst0 rewind
   mt -f /dev/nst0 weof
\end{verbatim}
\normalsize

o\`u vous devrez remplacer {\bf /dev/nst0} par le chemin appropri\'e de votre
lecteur de sauvegarde. 

\subsection*{Installer PostgreSQL avec les RPMs}
\index[general]{PostgreSQL!Installer avec les RPMs}
\index[general]{Installer PostgreSQL avec les RPMs}
\addcontentsline{toc}{subsection}{Installer PostgreSQL avec les RPMs}
Si vous installez PostgreSQL avec les RPMs, il vous faut installer les 
binaires PostgreSQL ainsi que les librairies clientes. Ces derni\`eres font 
g\'en\'eralement partie de paquetages de d\'eveloppement, aussi vous devez installer :

\footnotesize
\begin{verbatim}
  postgresql
  postgresql-devel
\end{verbatim}
\normalsize

Il en va de m\^eme avec la plupart des gestionnaires de paquetages.

\subsection*{Migrer de MySQL \`a PostgreSQL}
\index[general]{Migrer de MySQL \`a PostgreSQL }
\index[general]{PostgreSQL!Migrer de MySQL \`a }
\addcontentsline{toc}{subsection}{Migrer de MySQL \`a PostgreSQL}

La proc\'edure de migration pr\'esent\'ee ici \`a fonctionn\'e pour Norm
Dressler \lt{}ndressler at dinmar dot com\gt{} 

Ce process a \'et\'e test\'e en utilisant les versions suivantes des
diff\'erents logiciels: 

\begin{itemize}
\item Linux Mandrake 10/Kernel 2.4.22-10 SMP 
\item MySQL Ver 12.21 Distrib 4.0.15, pour mandrake-linux-gnu (i586) 
\item PostgreSQL 7.3.4 
\item Bacula 1.34.5 
   \end{itemize}

ATTENTION! Par pr\'ecaution, r\'ealisez une sauvegarde compl\`ete de vos
syst\`emes avant de proc\'eder \`a cette migration. 

\begin{enumerate}
\item Arr\^etez bacula (cd /etc/bacula;./bacula stop)  
\item Lancez la commande pour extraire les donn\'ees de votre base MySQL:  

   \footnotesize
\begin{verbatim}

       mysqldump -f -t -n >bacula-backup.dmp
    
\end{verbatim}
\normalsize

\item Faites une sauvegarde de votre r\'epertoire /etc/bacula (mais laisser
   l'original en place  ).  
\item Allez dans le r\'epertoire source de {\bf Bacula} et reconstruisez le en
   incluant le support  PostgreSQL au lieu de celui de MySQL . V\'erifiez que  le
   fichier config.log de votre configuration originale et remplacez enable-mysql
par enable-postgresql.  
\item Recompilez Bacula avec la commande make et si tout se passe correctement
 lancez un "make install".  
\item Arr\^etez MySQL. 
\item Lancez PostgreSQL sur votre syst\`eme.  
\item Cr\'eez un utilisateur {\bf Bacula} dans Postgres avec la commande
   "createuser".  En fonction de votre installation, vous serez peut \^etre
   amen\'e \`a faire un "su" vers l'utilisateur ad\'equat (NDT: su postgres).  
\item Verifiez que le fichier pg\_hba.conf (NdT sur Debian:
   /etc/postgres/pg\_hba.conf) contient les permissions ad\'equates pour
   permettre \`a {\bf Bacula} d'acc\'eder au serveur. Le mien contient les
informations suivantes, et il est situ\'e sur un r\'eseau s\'ecuris\'e,  

\footnotesize
\begin{verbatim}

local all all trust
                
host all all 127.0.0.1 255.255.255.255 trust
                
ATTENTION: vous devez red\'emmarer PostgreSQL si vous faites des changements dans ce fichier.
      
\end{verbatim}
\normalsize

\item Allez dans le r\'epertoire /etc/bacula et pr\'eparez la base de
   donn\'ees avec les commandes suivantes:  

\footnotesize
\begin{verbatim}

./create_postgresql_database
                                
./make_postgresql_tables
                                
./grant_postgresql_privileges
       
\end{verbatim}
\normalsize

\item Verifiez que vous avez acc\`es \`a la base de donn\'ees:  

   \footnotesize
\begin{verbatim}
  
psql -Ubacula bacula
      
\end{verbatim}
\normalsize

Vous ne devriez avoir aucune erreur.  
\item Chargez la base PostgreSQL avec l'extraction MySQL gr\^ace \`a la
   commande:  

\footnotesize
\begin{verbatim}

psql -Ubacula bacula <bacula-backup.dmp>
      
\end{verbatim}
\normalsize

\item R\'eindexez vos tables avec les commandes suivantes:  

   \footnotesize
\begin{verbatim}

psql -Ubacula bacula
                
SELECT SETVAL('basefiles_baseid_seq', (SELECT
MAX(baseid) FROM basefiles));

SELECT SETVAL('client_clientid_seq', (SELECT
MAX(clientid) FROM client));

SELECT SETVAL('file_fileid_seq', (SELECT MAX(fileid)
FROM file));

SELECT SETVAL('filename_filenameid_seq', (SELECT
MAX(filenameid) FROM filename));
                
SELECT SETVAL('fileset_filesetid_seq', (SELECT
MAX(filesetid) FROM fileset));
                
SELECT SETVAL('job_jobid_seq', (SELECT MAX(jobid) FROM job));

SELECT SETVAL('jobmedia_jobmediaid_seq', (SELECT
MAX(jobmediaid) FROM jobmedia));

SELECT SETVAL('media_mediaid_seq', (SELECT MAX(mediaid) FROM media));

SELECT SETVAL('path_pathid_seq', (SELECT MAX(pathid) FROM path));
                
SELECT SETVAL('pool_poolid_seq', (SELECT MAX(poolid) FROM pool));
       
\end{verbatim}
\normalsize

\item Parvenu ici, lancez {\bf Bacula}, v\'erifiez votre librairie et
   faites un test pour valider que tout s'est bien d\'eroul\'e. 
\end{enumerate}

\subsection*{Mettre \`a jour PostgreSQL}
\index[general]{Mettre \`a jour PostgreSQL }
\index[general]{Mettre \`a jour!PostgreSQL }
\addcontentsline{toc}{subsection}{Mettre \`a jour PostgreSQL}
Si vous mettez PosgreSQL \`a jour, vous devez reconfigurer, recompiler et 
r\'einstaller Bacula, faute de quoi vous constaterez probalement des 
erreurs \'etranges. 
Pour cela, il vous faut installer le RPM source, modifier le fichier bacula.spec 
pour l'accorder \`a votre version de PostgreSQL, reconstruire le RPM et l'installer.

If you upgrade PostgreSQL, you must reconfigure, rebuild, and re-install
Bacula otherwise you are likely to get bizarre failures.  If you
to modify the bacula.spec file to account for the new PostgreSQL version.
You can do so by rebuilding from the source rpm. To do so, you may need
install from rpms and you upgrade PostgreSQL, you must also rebuild Bacula.


\subsection*{Credits}
\index[general]{Credits }
\addcontentsline{toc}{subsection}{Credits}

Tous mes remerciements \`a Dan Languille pour l'\'ecriture du driver
PostgreSQL qui deviendra tr\`es certainement la base de donn\'ees la plus
r\'eput\'ee utilisable avec {\bf Bacula} 
