Attention !!! Si vous envisagez d'utiliser PostgreSQL, vous devriez être conscient de la philosophie des mises à jour de PostgreSQL qui peut être déstabilisant dans un environnement de production. En gros, pour chaque mise à jour vers une version majeure, vous devez exporter vos bases de données au format ASCII, faire la mise à jour, et recharger vos bases de données. Ceci est dû au à des mises à jour fréquentes du "format de données" d'une version à 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ètement inutiles si aucun des nouveaux outils ne peut y accéder en raison d'un changement de format, auquel cas le serveur PostgreSQL sera dans l'incapacité de démarrer.
Si vous avez utilisé l'option ./configure
--with-postgresql=PostgreSQL-Directory pour configurer Bacula, vous
avez besoin d'installer la version 7.3 ou supérieure de PostgreSQL.
ATTENTION! Les versions préalables à la 7.3 ne fonctionnent pas avec
Bacula. Si PostgreSQL est installé dans ses répertoires sandards, seule
l'option --with-postgresql est nécessaire, le programme de
configuration scrutant tous les répertoires standards. Si PostgreSQL est
installé dans votre répertoire de travail ou dans un répertoire
atypique, il faut préciser l'option --with-postgresql suivie du
répertoire ad hoc.
Installer et configurer PostgreSQL n'est pas compliqué mais peut être déroutant la première fois. Si vous préférez, vous pouvez utiliser le paquet de votre distribution. Les paquets binaires sont disponibles sur la plupart des mirroirs de PostgreSQL.
Si vous préférez installer PostgreSQL à partir des sources, nous vous recommandons de suivre les instructions de la documentation PostgreSQL.
Si vous utilisez PostgreSQL pour FreeBSD, cet article vous sera peut être utile. Même si vous n'utilisez pas FreeBSD, l'article contient des informations utiles à la configuration et au paramétrage de PostgreSQL.
Après l'installation de PostgreSQL, terminez l'installation de Bacula. Ensuite, quand Bacula sera installé, reprenez ce chapitre pour terminer l'installation. Notez que les fichiers d'installation utilisés dans cette seconde phase de l'installation de PostgreSQL sont créés durant l'installation de Bacula.
Si vous en êtes là, vous avez construit et installé PostgreSQL, ou vous aviez déjà un serveur PostgreSQL existant et vous avez configuré et installé Bacula. Dans le cas contraire, nous vous invitons à le faire avant de poursuivre.
Notez bien que la commande ./configure utilisée pour
construire Bacula nécessite d'ajouter l'option --with-postgresql=repertoire_de_PostgreSQL, où repertoire_de_PostgreSQL spécifie le chemin de PostgreSQL indiqué à
la commande ./configure. (si vous n'avez pas spécifié de répertoire ou
si PostgreSQL est installé dans son répertoire par défaut, cette option
n'est pas nécessaire). Cette option est nécessaire pour que Bacula puisse
trouver les fichiers d'en-tête et les librairies d'interface à PostgreSQL.
Bacula installe les scripts pour la gestion de la base de données (créer, détruire, créer les tables, etc.) dans le répertoire principal de l'installation. Ces fichiers sont de la forme *_bacula_* (par exemple create_bacula_database). Ces fichiers sont également disponibles dans le répertoire <bacula-src>/src/cats après que la commande ./configure ait été lancée. Si vous consultez le fichier create_bacula_database, vous verrez qu'il fait appel à create_postgresql_database. Les fichiers *_bacula_* sont fournis pour faciliter les choses. Peu importe la base de données choisie, create_bacula_database créera la base de données.
Maintenant vous allez créer la base de données PostgreSQL et les tables utilisées par Bacula. On présume dans la suite que votre serveur PostgreSQL fonctionne. Vous devez exécuter les différentes étapes ci-dessous en tant qu'utilisateur autorisé à créer des bases. Ceci peut être fait avec l'utilisateur PostgreSQL (sur la plupart des systèmes il s'agit de pgsql. NDT: sur debian il s'agit de postgres)
Ce répertoire contient le catalogue des routines d'interfaces.
Ce script créé le catalogue bacula PostgreSQL. S'il échoue, c'est probablement que vous n'avez pas les droits requis sur la base de données. Sur la plupart des systèmes, le propriétaire de la base de données est pgsql, et sur d'autres tels que RedHat ou Fedora, c'est postgres. Vous pouvez déterminer lequel en examinant le fichier /etc/passwd. Pour créer un nouvel utilisateur avec votre nom ou le nom bacula, vous pouvez faire ce qui suit :
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
A ce stade, vous devriez pouvoir exécuter la commande ./create_bacula_database
Créée les tables utilisées par Bacula.
Créée l'utilisateur de la base de données bacula avec des droits d'accès restreints. Vous pouvez modifier ce script pour cadrer avec votre propre configuration. Attention, cette base n'est pas protégée par un mot de passe.
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 être utile pour spécifier le nom de l'utilisateur. Par exemple, vous pouvez avoir besoin d'ajouter -h nom_d_hote à la ligne de commande pour spécifier le serveur de base de données distant.
Pour avoir un bon aperçu des droits d'accès que vous avez spécifié vous pouvez utiliser la commande
repertoire_de_PostgreSQL/bin/psql --command \\dp bacula
J'ai rencontré un problème de permissions avec le mot de passe. J'ai finalement du modifier mon fichier pg_hba.conf (situé dans /var/lib/pgsql/data sur ma machine) :
de local all all ident sameuser vers local all all trust sameuser
Ceci a résolu le problème pour moi, mais ce n'est pas pas forcément une bonne chose du point de vue de la sécurité, mais j'ai ainsi pu exécuter mes scripts de régression sans mot de passe.
Un moyen plus sécurisé pour l'authentification auprès de la base de données consiste à utiliser le hachage MD5 des mots de passe. Pour cela, éditez les fichier pg_hba.conf, et ajoutez ajoutez ce qui suit juste avant les lignes "local" et "host" existantes :
local bacula bacula md5
Puis redémarrez le daemon Postgres (la plupart du temps, avec "/etc/init.d/postgresql restart") pour activer cette nouvelle règle d'authentification.
Ensuite, en tant qu'administrateur Postgres (connectez-vous en tant qu'utilisateur postgres ou en utilisant su pour devenir root, puis su postgres), ajoutez un mot de passe à la base de données bacula pour l'utilisateur bacula avec les commandes suivantes :
\$ psql bacula bacula=# alter user bacula with password 'secret'; ALTER USER bacula=# \\q
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 à ceci :
dbname = bacula; user = bacula; password = "secret"
... and ...
RunBeforeJob = "/etc/make_catalog_backup bacula bacula secret"
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ême avec ces restrictions, il reste un problème de sécurité avec cette approche : sur certaines plateformes, la variable d'environnement utilisée pour soumettre le mot de passe à Postgres est disponible pour tout utilisateur local du système. Pour supprimer ce problème, l'équipe Postgres a décrété obsolète ce mécanisme de passage de mot de passe par variable d'environnement et recommande d'utiliser un fichier .pgpass. Pour utiliser ce mécanisme, créez un fichier nommé .pgpass vcontenant une simple ligne :
localhost:5432:bacula:bacula:secret
Ce fichier devrait être copié dans les répertoires personnels (NDT : home directories) de tous les comptes susceptibles d'avoir besoin d'accéder à la base de données : 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 être positionnées à 600 pour limiter l'accès au propriétaire du fichier.
Après avoir fait un certain nombre de tests avec Bacula, vous aurez très certainement envie de nettoyer le catalogue des sauvegardes et faire disparaître tous les travaux de tests que vous avez lancés. Pour ce faire, vous pouvez exécuter les commandes suivantes:
cd <r\'epertoire_d_installation> ./drop_bacula_tables ./make_bacula_tables ./grant_bacula_privileges
Attention! Toutes les informations contenues dans cette base seront perdues et vous repartirez de zéro. Si vous avez écrit sur certains volumes (média de sauvegarde), vous devrez écrire une marque de fin de fichier (EOF) sur chacun d'eux afin que Bacula puisse les réutiliser. Pour ce faire:
(arr\^eter Baula ou demonter les volumes) mt -f /dev/nst0 rewind mt -f /dev/nst0 weof
où vous devrez remplacer /dev/nst0 par le chemin approprié de votre lecteur de sauvegarde.
postgresql postgresql-devel
Il en va de même avec la plupart des gestionnaires de paquetages.
La procédure de migration présentée ici à fonctionné pour Norm Dressler <ndressler at dinmar dot com>
Ce process a été testé en utilisant les versions suivantes des différents logiciels:
ATTENTION! Par précaution, réalisez une sauvegarde complète de vos systèmes avant de procéder à cette migration.
mysqldump -f -t -n >bacula-backup.dmp
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.
./create_postgresql_database
./make_postgresql_tables
./grant_postgresql_privileges
psql -Ubacula bacula
Vous ne devriez avoir aucune erreur.
psql -Ubacula bacula <bacula-backup.dmp>
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));
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.
Tous mes remerciements à Dan Languille pour l'écriture du driver PostgreSQL qui deviendra très certainement la base de données la plus réputée utilisable avec Bacula