Bacula 1.35 - Mode d'emploi
Back
Démarrer avec Bacula
Index
Index
Next
Exécuter Bacula

Installer Bacula

Prérequis

En général, il vous faudra les sources de la version courante de Bacula, et si vous souhaitez exécuter un client Windows, vous aurez besoin de la version binaire du client Bacula pour Windows. Par ailleurs, Bacula a besoin de certains paquettages externes (tels readline, SQLite, MySQL ou PostgreSQL) pour compiler correctement en accord avec les options que vous aurez choisi. Pour vous simplifier la tâche, nous avons combiné plusieurs de ces programmes dans deux paquettages depkgs (paquettages de dépendances). Ceci peut vous simplifier la vie en vous fournissant tous les paquets nécessaires plutôt que de vous contraindre à les trouver sur la Toile, les charger et installer.

Mettre Bacula à jour

Si vous faites une mise à jour de Bacula, vous devriez d'abord lire attentivement les ReleaseNotes de toutes les versions entre votre version installée et celle vers laquelle vous souhaitez mettre à jour. Si la base de donnée du catalogue a été mise à jour, vous devrez soit réinitialiser votre base de données et repartir de zéro, soit en sauvegarder une copie au format ASCII avant de procéder à sa mise à jour. S'il y a eu plusieurs mises à jour de la base de données entre votre version et celle vers laquelle vous souhaitez évoluer, il faudra appliquer chaque script de mise à jour de base de données. Vous pouvez trouver tous les anciens scripts de mise à jour dans le répertoire upgradedb des sources de Bacula. Il vous faudra éditer ces scripts pour qu'ils correspondent à votre configuration. Le script final, s'il y en a un, sera dans le répertoire src/cats comme indiqué dans la ReleaseNote.

Si vous migrez d'une version majeure vers une autre, vous devrez remplacer tous vos composants (daemons) en même temps car, généralement, le protocole inter-daemons aura changé. Par contre, entre deux versions mineures d'une même majeure (par exemple les versions 1.32.x), à moins d'un bug, le protocole inter-daemons ne changera pas. Si cela vous semble confus, lisez simplement les ReleaseNotes três attentivement, elles signaleront si les daemons doivent être mis à jour simultanément.

Paquettage de Dépendences

Comme nous l'évoquions plus haut, nous avons combiné une série de programmes dont Bacula peut avoir besoin dans les paquets depkgs et depkgs1. Vous pouvez, bien sur, obtenir les paquets les plus récents directement des auteurs. Le fichier README dans chaque paquet indique où les trouver. Pourtant, il faut noter que nous avons testé la compatibilité des paquets contenus dans les fichiers depkgs avec Bacula.

Typiquement, ils seront nommés depkgs-ddMMMyy.tar.gzdd est le jour où n'ous l'avons publié, MMM l'abbréviation du mois et yy l'année. Par exemple: depkgs-07Apr02.tar.gz. Pour installer et construire ce paquettage (s'il est requis), vous devez:

  1. Créer un répertoire bacula, dans lequel vous placerez les sources de Bacula et le paquettage de dépendances.
  2. Désarchiver le depkg dans le répertoire bacula.
  3. vous déplacer dans le répertoire obtenu: cd bacula/depkgs
  4. exécuter make
La composition exacte des paquettages de dépendance est susceptible de changer de temps en temps, voici sa composition actuelle :

Paquets externes depkgs depkgs1 depkgs-win32
SQLite X - -
mtx X - -
readline X - -
pthreads - - X
zlib - - X

Notez que certains de ces paquets sont de taille respectable, si bien que l'étape de compilation peut prendre un peu de temps. Les instructions ci-dessous construiront tous les paquets contenus dans le répertoire. Cependant, la compilation de Bacula, ne prendra que les morceaux dont Bacula a effectivement besoin.

Une alternative consiste à ne construire que les paquets nécessaires. Par exemple,

cd bacula/depkgs
make sqlite
configurera et construira SQLite et seulement SQLite.

Vous devriez construire les paquets requis parmi depkgs et/ou depkgs1 avant de configurer et compiler Bacula car Bacula en aura besoin dès la compilation.

Même si vous n'utilisez pas SQLite, vous pourriez trouver le paquet depkgs pratique pour construire mtx car le programme tapeinfo qui vient avec peut souvent vous fournir de précieuses informations sur vos lecteurs de bandes SCSI (e.g. compression, taille min/max des blocks,...).

Le paquet depkgs-win32 contient le code source pour les librairies pthreads et zlib utilisées par le client Win32 natif. Vous n'en aurez besoin que si vous prévoyez de construire le client Win32 depuis les sources.

Systèmes Supportés

Veuillez consulter la section Systèmes supportés du chapitre Démarrer avec Bacula de ce manuel.

Construire Bacula à partir des sources

L'installation basique est plutôt simple.

  1. Installez and construisez chaque depkgs comme indiqué plus haut.
  2. Configurez et installez MySQL ou PostgreSQL (si vous le souhaitez). Installer et configurer MySQL Phase I ou Installer et configurer PostgreSQL Phase I. Si vous installez depuis des rpms, et utilisez MySQL, veillez à installer mysql-devel, afin que les fichiers d'en-tête de MySQL soient disponibles pour la compilation de Bacula. De plus, la librairie client MySQL requière la librairie de compression gzip libz.a ou libz.so. Ces librairies sont dans le paquet libz-devel. Sur Debian, vous devrez charger le paquet zlib1g-dev. Si vous n'utilisez ni rpms, ni debs, il vous faudra trouver le paquettage adapté à votre système. Notez que si vous avez dejà MySQL ou PostgreSQL sur votre système vous pouvez sauter cette phase pourvu que vous ayez construit "the thread safe libraries" et que vous ayez déjà installé les rpms additionnels sus-mentionnés.
  3. En alternative à MySQL et PostgreSQL, configurez et installez SQLite, qui fait partie du paquettage depkgs. Installer et configurer SQLite.
  4. Désarchivez les sources de Bacula, de préférence dans le répertoire bacula évoqué ci-dessus.
  5. Déplacez-vou dans ce répertoire.
  6. Exécutez ./configure (avec les options appropriés comme décrit ci-dessus)
  7. Examinez très attentivement la sortie de ./configure, particulièrement les répertoires d'installation des binaires et des fichiers de configuration. La sortie de ./configure est stockée dans le fichier config.out et peut être affichée à volonté sans relancer ./configure par la commande cat config.out.
  8. Vous pouvez relancer ./configure avec des options différentes après une première exécution, cela ne pose aucun problème, mais vous devriez d'abord exécuter:
         make distclean
         
    afin d'être certain de repartir de zéro et d'éviter d'avoir un mélange avec vos premières options. C'est nécessaire parce que ./configure met en cache une bonne partie des informations. make distclean est aussi recommandé si vous déplacez vos fichiers source d'une machine à une autre. Si make distclean échoue, ignorez-le et continuez.
  9. make

    Si vous obtenez des erreurs durant le linking dans le répertoire du storage daemon (/etc/stored), c'est probablement parce que vous avez chargé la librairie statique sur votre système. J'ai remarqué ce problème sur un Solaris. Pour le corriger, assurez-vous de ne pas avoir ajouté l'option --enable-static-tools à la commande ./configure.

  10. make install
  11. Si vous êtes un nouvel utilisateur de Bacula, nous vous recommandons fortement de sauter l'étapes suivante et d'utiliser le fichier de configuration par défaut, puis d'exécuter le jeu d'exemples du prochain chapitre avant de revenir modifier vos fichier de configuration pour qu'ils satisfassent vos besoins.
  12. Modifiez les fichiers de configuration de chacun des trois daemons (Directory, File, Storage) et celui de la Console. Pour plus de détails, consultez le chapitre Fichiers de Configuration de Bacula Nous vous recommandons de commencer par modifier les fichiers de configuration fournis par défaut, en faisant les changements minima indispensables. Vous pourrez procéder à une adaptation complète une fois que Bacula fonctionnera correctement. Veuillez prendre garde à modifier les mots de passe qui sont générés aléatoirement, ainsi que les noms car ils doivent s'accorder entre les fichiers de configuration pour des raisons de sécurité.
  13. Créez la base de données Bacula MySQLet ses tables (si vous utilisez MySQL) Installer et configurer MySQL Phase II ou créez la base de données Bacula PostgreSQL et ses tables Installer et configurer PostgreSQL Phase II (si vous utilisez PostgreSQL) ou encore Installer et configurer SQLite Phase II (si vous utilisez SQLite)
  14. Démarrez Bacula (./bacula start) Notez: Le prochain chapitre expose ces étapes en détail.
  15. Lancez la Console pour communiquer avec Bacula.
  16. Pour les deux éléments précédents, veuillez suivre les instructions du chapitre Exécuter Bacula où vous ferez une simple sauvegarde et une restauration. Faites ceci avant de faire de lourdes modifications aux fichiers de configuration, ainsi vous serez certain que Bacula fonctionne, et il vous sera plus familier. Après quoi il vous sera plus facile de changer les fichiers de configuration.
  17. Si après l'installation de Bacula, vous décidez de le "déplacer, c'est à dire de l'installer dans un jeu de répertoires différents, procédez comme suit :
          make uninstall
          make distclean
          ./configure (vos-nouvelles-options)
          make
          make install
          

Si tout se passe bien, ./configure déterminera correctement votre système et configurera correctement le code source. Actuellement, FreeBSD, Linux (RedHat), et Solaris sont supportés. Des utilisateurs rapportent que le client Bacula fonctionne sur MacOS X 10.3 tant que le support readline est déqactivé.

Si vous installez Bacula sur plusieurs systèmes identiques, vous pouvez simplement transférer le répertoire des sources vers ces autres systèmes et faire un "make install". Cependant s'il ya des différences dans les librairies, ou les versions de systèmes, ou si vous voulez installer sur un système différent, vous devriez recommencer à partir de l'archive tar compressée originale. si vous transférez un répertoire de sources où vous avez déjà exécuté la commande ./configure, vous DEVEZ faire:

make distclean
avant d'exécuter à nouveau ./configure. Ceci est rendu nécessaire par l'outil GNU autoconf qui met la configuration en cache, de sorte que si vous réutilisez la configuration d'une machine Linux sur un Solaris, vous pouvez être certain que votre compilation échouera. Pour l'éviter, comme mentionné plus haut, recommencez depuis l'archive tar, ou faites un "make distclean".

En général, vous voudrez probablement sophistiquer votre configure pour vous assurer que tous les modules que vous souhaitez soient construits et que tout soit placé dans les bons répertoires.

Par exemple, sur RedHat, on pourrait utiliser ceci:

CFLAGS="-g -Wall" \
  ./configure \
    --sbindir=$HOME/bacula/bin \
    --sysconfdir=$HOME/bacula/bin \
    --with-pid-dir=$HOME/bacula/bin/working \
    --with-subsys-dir=$HOME/bacula/bin/working \
    --with-mysql=$HOME/mysql \
    --with-working-dir=$HOME/bacula/bin/working \
    --with-dump-email=$USER
Notez: l'avantage de cette configuration pour commencer, est que tout sera mis dans un seul répertoire, que vous pourrez ensuite supprimer une fois que vous aurez exécuté les exemples du prochain chapitre, et appris comment fonctionne Bacula. De plus, ceci peut être installé et exécuté sans être root.

Pour le confort des développeurs, j'ai ajouté un script defaultconfig au répertoire examples. Il contient les réglages que vous devriez normalement utiliser, et chaque développeur/utilisateur devrait le modifier pour l'accorder à ses besoins. Vous trouverez d'autres exemples dans ce répertoire.

Les options --enable-conio ou --enable-readline sont utiles car elles fournissent un historique de lignes de commandes et des capacités d'édition à la Console. Si vous avez inclus l'une ou l'autre option, l'un des deux paquets termcap ou ncurses sera nécessaire pour compiler. Sur certains systèmes, tels que Suse, la librairie termcap n'est pas dans le répertoire standard des librairies par conséquent, l'option devrait être désactivée ou vous aurez un message tel que:

/usr/lib/gcc-lib/i586-suse-linux/3.3.1/.../ld:
cannot find -ltermcap
collect2: ld returned 1 exit status
ilors de la comilation de la Console Bacula. Dans ce cas, il vous faudra placer la variable d'environnement LDFLAGS avant de compiler.
export LDFLAGS="-L/usr/lib/termcap"
Les mêmes contraintes de librairies s'appliquent si vous souhaitez utiliser les sous-programmes readlines pour l'édition des lignes de commande et l'historique.

Veuillez noter que sur certains systèmes tels que Mandrake, readline tend à "avaler" l'invite de commandes, ce qui le rend totalement inutile. Si cela vous arrive, utilisez l'option "disable", ou si vous utilisez une version postérieure à 1.33 essayez --enable-conio pour utiliser une alternative à readline intégrée. Il vous faudra tout de même termcap ou ncurses, mais il est peu probable que le paquettage conio gobe vos invites de commandes.

Quelle base de données utiliser ?

Avant de construire Bacula, vous devez décider si vous voulez utiliser SQLite, MySQL ou PostgreSQL. Si vous n'avez pas déjà MySQL ou PostgreSQL sur votre machine, nous vous recommandons de démarrer avec SQLite pour vous faciliter l'installation.

Si vous souhaitez utiliser MySQL pour votre catalogue Bacula, consultez le chapitre Installer et Configurer MySQL de ce manuel. Vous devrez installer MySQL avant de poursuivre avec la configuration de Bacula.

Si vous souhaitez utiliser PostgreSQL pour votre catalogue Bacula, consultez le chapitre Installer et Configurer PostgreSQL de ce manuel. Vous devrez installer PostgreSQL avant de poursuivre avec la configuration de Bacula.

Si vous souhaitez utiliser SQLite pour votre catalogue Bacula, consultez le chapitre Installer et Configurer SQLite de ce manuel.

Démarrage rapide

Il y a de nombreuses options et d'importantes considérations données ci-dessous que vous pouvez passer pour le moment si vous n'avez eu aucun problème lors de la compilation de Bacula avec une configuration simplifiée comme celles montrées plus haut.

Si vous souhaitez vous jeter à l'eau, nous vous conseillons de passer directement au chapitre suivant, et d"executer le jeu d'exemples. Il vous apprendra beaucoup sur Bacula, et un Bacula de test peut être installé dans un unique répertoire (pour une destruction aisée) et exécuté sans être root. Revenez lire les détails de ce chapitre si vous avez un quelconque problème avec les exemples, ou lorsque vous voudrez effectuer une installation réelle.

Options de la commande configure

Les options en ligne de commande suivantes sont disponibles pour configure afin d'adapter votre installation à vos besoins.

--sysbindir=<binary-path>
Définit l'emplacement des binaires Bacula.
--sysconfdir=<config-path>
Définit l'emplacement des fichiers de configuration de Bacula.
--enable-smartalloc
Permet l'inclusion du code Smartalloc de détection de tampons orphelin (NDT : orphaned buffer). Cette option est vivement recommandée. Nous n'avons jamais compilé sans elle, aussi vous pourriez subir des désagréments si vous ne l'activez pas. Ce paramètre est utilisé lors de la compilation de Bacula.
--enable-gnome
Si vous avez installé GNOME sur votre ordinateur, vous devez spécifier cette option pour utiliser la Console graphique GNOME. Vous trouverez les binaires dans le répertoire src/gnome-console.
--enable-wx-console
Si vous avez installé wxWidgets sur votre ordinateur, vous devez spécifier cette option pour utiliser la Console graphique wx-console. Vous trouverez les binaires dans le répertoire src/wx-console. Ceci peut être utile aux utilisateurs qui veulent une Console graphique, mais ne souhaitent pas installer Gnome, car wxWidgets fonctionner avec les librairies GTK+, Motif ou même X11.
--enable-tray-monitor
Si vous avez installé GTK sur votre ordinateur et utilisez un gestionnaire de fenêtre compatible avec le système de notification standard FreeDesktop (tels KDE et GNOME), vous pouvez utiliser une interface graphique pour surveiller les daemons Bacula en activant cette option. Les binaires seront placés dans le répertoire src/tray-monitor.
--enable-static-tools
Avec cette option, les utilitaires relatifs au Storage Daemon (bls, bextract, et bscan) seront liés statiquement, ce qui vous permet de les utiliser même si les librairies partagées ne sont pas chargées. Si vous avez des difficultés de type "linking" à la compilation du répertoire src/stored, assurez-vous d'avoir désactivé cette option, en ajoutant éventuellement --disable-static-tools.
--enable-static-fd
Avec cette option, la compilation produira un static-bacula-fd en plus du File Daemon standard. Cette version qui inclut les librairies statiquement liées est requise pour la reconstruction complète d'une machine après un désastre. Cette option est largement surpassée par l'usage de make static-bacula-fd du répertoire src/filed.
--enable-static-sd
Avec cette option, la compilation produira un static-bacula-sd en plus du Storage Daemon standard. Cette version qui inclut les librairies statiquement liées peut se révéler utile pour la reconstruction complète d'une machine après un désastre.
--enable-static-dir
Avec cette option, la compilation produira un static-bacula-dir en plus du Director Daemon standard. Cette version qui inclut les librairies statiquement liées peut se révéler utile pour la reconstruction complète d'une machine après un désastre.
--enable-static-cons
Avec cette option, la compilation produira une static-console et une static-gnome-console en plus de la Console standard standard. Cette version qui inclut les librairies statiquement liées peut se révéler utile pour la reconstruction complète d'une machine après un désastre.
--enable-client-only
Avec cete option, la compilation produira seulement le File Daemon et les librairies qui lui sont nécessaires. Aucun des autres daemons, outils de stockage, ni la console ne sera compilé. De même, un make install installera seulement le File Daemon. Pour obtenir tous les daemons, vous devez la désactiver. Cette option facilite grandemment la compilation sur les simples clients.
--enable-largefile
Cette option (activée par défaut) provoque la compilation de Bacula avec le support d'adressage de fichiers 64 bits s'il est disponible sur votre système. Ainsi Bacula peut lire et écrire des fichiers de plus de 2 GBytes. Vous pouvez désactiver cette option et revenir à un adressage de fichiers 32 bits en utilisant --disable-largefile.
--with-sqlite=<sqlite-path>
Cette option permet l'utilisation de la base de données SQLite. Il n'est, en principe, pas nécessaire de spécifier le chemin sqlite-path car Bacula recherche les composants requis dans les répertoires standards (depkgs/sqlite). voyez Installer et Configurer SQLite pour plus de détails.
--with-mysql=<mysql-path>
Cette option permet la compilation des services de Catalogue de Bacula. Elle implique que MySQL tourne déjà sur votre système, et qu'il soit installé dans le chemin mysql-path que vous avez spécifié. Si cette option est absente, Bacula sera compilé automatiquement avec le code de la base Bacula interne. Nous recommandons d'utiliser cette option si possible. Si vous souhaitez utilisez cette option, veuillez procéder à l'installation de MySQL (Installer and Configurer MySQL avant de procéder à la configuration.
--with-postgresql=<path>
Cette option déclare un chemin explicite pour les librairies PostgreSQL si Bacula ne les trouve pas dans le répertoire par défaut.
--enable-conio
Cette option permet la compilation d'une petite et légère routine en alternative à readline, beaucoup plus facile à configurer, même si elle nécessite aussi les librairies temcap ou ncurses.NDT: Notez qu'à l'heure actuelle (6 septembre 2004), l'alternative conio ne supporte pas les caractères UTF-8. Ceci signifie que vous ne pourrez saisir de caractères accentués dans la console Bacula si vous compilez sans readline. Ainsi, vous ne pourrez restaurer les fichiers ou répertoires dont le nom comporte des caractères accentués qu'en restaurant tout le répertoire de niveau supérieur.
--with-readline=<readline-path>
Spécifie l'emplacement de readline. En principe, Bacula devrait le trouver s'il est dans une librairie standard. Sinon, et si l'option --with-readline n'est pas renseignée, readline sera désactivé. Cette option affecte la compilation de Bacula. Readline fournit le programme Console avec un historique des lignes de commandes et des capacités d'édition. NDT: Notez qu'à l'heure actuelle (6 septembre 2004), l'alternative conio ne supporte pas les caractères UTF-8. Ceci signifie que vous ne pourrez saisir de caractères accentués dans la console Bacula si vous compilez sans readline. Ainsi, vous ne pourrez restaurer les fichiers ou répertoires dont le nom comporte des caractères accentués qu'en restaurant tout le répertoire de niveau supérieur.
--with-tcp-wrappers=<path>
Cette option précise que vous voulez TCP wrappers (man hosts_access(5)) compilé dans Bacula. Le chemin est facultatifpuisque Bacula devrait, en principe, trouver les librairies dans les répertoires standards. Cette option affecte la compilation. Lorsque vous spécifierez vos restrictions dans les fichiers /etc/hosts.allow ou /etc/hosts.deny, n'utilisez pas l'option twist (man hosts_options(5)) ou le processus Bacula sera stoppé.

Pour plus d'informations sur la configuration et les tests deTCP wrappers, consultez la section Configurer et Tester TCP Wrappers du chapitre sur la sécurité.

--with-working-dir=<working-directory-path>
Cette option est obligatoire et spécifie un répertoire dans lequel Bacula peut placer en toute sécurité les fichiers qui resteront d'une exécution à l'autre. Par exemple, si la base de données interne est utilisée, Bacula stockera ces fichiers dans ce répertoire. Cette option n'est utilisée que pour modifier les fichiers de configuration de Bacula. Vous pourrez éventuellement effectuer cette modification plus tard directement en les éditant plus tard.
--with-base-port=<port=number>
Bacula a besoin de trois ports TCP/IP pour fonctionner (un pour la Console, un pour le Storage daemon et un pour le File daemon). L'option --with-baseport permet d'assigner automatiquement trois ports consécutifs à partir du port de base spécifié. Vous pouvez aussi changer les numéros de ports dans les fichiers de configuration. Cependant, vous devez prendre garde à ce que les numéros de ports se correspondent fidèlement dans chacun des trois fichiers de configuration. Le port de base par défaut est 9101, ce qui assigne les ports 9101 à 9103. Ces ports (9101,9102 et 9103) ont été officiellement assigné à Bacula par l'IANA. Cette option n'est utilisée que pour modifier les fichiers de configuration de Bacula. Vous pouvez à tout moment faire cette modification en éditant directement ces fichiers.
--with-dump-email=<email-address>
Cette option spécifie l'adresse e-mail qui recevra tous les core dump. Cette option n'est en principe utilisée que par les développeurs.
--with-pid-dir=<PATH>
Ceci précise le répertoire de stockage du fichier d'id de processus lors de l'exécution. La valeur par défaut est : /var/run.
--with-subsys-dir=<PATH>
Cette option précise le répertoire de stockage des fichiers verrous du sous-système lors de l'exécution. Le répertoire par défaut est /var/run/subsys.Veillez à ne pas spécifier le même répertoire que pour l'option sbindir.
--with-dir-password=<Password>
Cette option vous permet de préciser le mot de passe d'accès au Director (contacté, en principe, depuis la console). S'il n'est pas précisé, configure en créé un aléatoirement.
--with-fd-password=<Password>
Cette option vous permet de préciser le mot de passe d'accès au File Daemon (contacté, en principe, depuis le Director). S'il n'est pas précisé, configure en créé un aléatoirement.
--with-sd-password=<Password>
Cette option vous permet de préciser le mot de passe d'accès au Storage Daemon (contacté, en principe, depuis le File Daemon). S'il n'est pas précisé, configure en créé un aléatoirement.
--with-dir-user=<User>
Cette option vous permet de spécifier l'UserId utilisée pour l'exécution du Director. Le Director doit être démarré en tant que root, mais n'a pas besoin d'être exécuté en tant que root. Après avoir effectué les opérations d'initialisation préliminaires, il peut redescendre au niveau de l'UserId spécifié dans cette option.
--with-dir-group=<Group>
Cette option vous permet de spécifier le GroupId utilisée pour l'exécution du Director. Le Director doit être démarré en tant que root, mais n'a pas besoin d'être exécuté en tant que root. Après avoir effectué les opérations d'initialisation préliminaires, il peut redescendre au niveau du GroupId spécifié dans cette option.
--with-sd-user=<User>
Cette option vous permet de spécifier l'UserId utilisé pour exécuter le Storage Daemon. Le Storage Daemon doit être démarré en tant que root, mais n'a pas besoin d'être exécuté en tant que root. Après avoir effectué les opérations d'initialisation préliminaires, il peut redescendre au niveau de l'UserId spécifié dans cette option. Si vous utilisez cette option, veillez à ce que le Storage Daemon ait accès à tous les périphériques de stockage dont il a besoin.
--with-sd-group=<Group>
Cette option vous permet de spécifier le GroupId utilisé pour exécuter le Storage Daemon. Le Storage Daemon doit être démarré en tant que root, mais n'a pas besoin d'être exécuté en tant que root. Après avoir effectué les opérations d'initialisation préliminaires, il peut redescendre au niveau du GroupId spécifié dans cette option.
--with-fd-user=<User>
Cette option vous permet de spécifier l'UserId utilisé pour exécuter le File Daemon. Le File Daemon doit être démarré et, dans la plupart des cas, exécuté en tant que root, de sorte que cette option n'est utilisée que dans des cas bien particuliers. Malgré tout, après avoir effectué les opérations d'initialisation préliminaires, il peut redescendre au niveau de l'UserId spécifié dans cette option.
--with-fd-group=<Group>
Cette option vous permet de spécifier le GroupId utilisé pour exécuter le File Daemon. Le File Daemon doit être démarré et, dans la plupart des cas, exécuté en tant que root, de sorte que cette option n'est utilisée que dans des cas bien particuliers. Malgré tout, après avoir effectué les opérations d'initialisation préliminaires, il peut redescendre au niveau du GroupId spécifié dans cette option.
Notez: de nombreuses options supplémentaires vous sont présentées lorsque vous entrez ./configure --help, mais elles ne sont pas implémentées.

Options recommandées pour la plupart des systèmes

Pour la plupart des systèmes, nous recommandons de commencer avec les options suivantes :

./configure \
  --enable-smartalloc \
  --sbindir=$HOME/bacula/bin \
  --sysconfdir=$HOME/bacula/bin \
  --with-pid-dir=$HOME/bacula/bin/working \
  --with-subsys-dir=$HOME/bacula/bin/working \
  --with-mysql=$HOME/mysql \
  --with-working-dir=$HOME/bacula/working

Si vous souhaitez installer Bacula dans un répertoire d'installation plutôt que de l'exécuter depuis le répertoire d'installation, (comme le feront les développeurs la plupart du temps), vous devriez aussi inclure les options --sbindir et --sysconfdir avec les chemins apropriés. Aucune n'est nécessaire si vous ne vous servez pas de "make install", comme c'est le cas pour la plupart des travaux de développement. L'exemple ci-dessous montre la façon de procéder de Kern.

RedHat

Avec SQLite:
 
CFLAGS="-g -Wall" ./configure \
  --sbindir=$HOME/bacula/bin \
  --sysconfdir=$HOME/bacula/bin \
  --enable-smartalloc \
  --with-sqlite=$HOME/bacula/depkgs/sqlite \
  --with-working-dir=$HOME/bacula/working \
  --with-pid-dir=$HOME/bacula/bin/working \
  --with-subsys-dir=$HOME/bacula/bin/working \
  --enable-gnome \
  --enable-conio
ou
 
CFLAGS="-g -Wall" ./configure \
  --sbindir=$HOME/bacula/bin \
  --sysconfdir=$HOME/bacula/bin \
  --enable-smartalloc \
  --with-mysql=$HOME/mysql \
  --with-working-dir=$HOME/bacula/working
  --with-pid-dir=$HOME/bacula/bin/working \
  --with-subsys-dir=$HOME/bacula/bin/working
  --enable-gnome \
  --enable-conio

Solaris

#!/bin/sh
CFLAGS="-g" ./configure \
  --sbindir=$HOME/bacula/bin \
  --sysconfdir=$HOME/bacula/bin \
  --with-mysql=$HOME/mysql \
  --enable-smartalloc \
  --with-pid-dir=$HOME/bacula/bin/working \
  --with-subsys-dir=$HOME/bacula/bin/working \
  --with-working-dir=$HOME/bacula/working

FreeBSD

Veuillez consulter: The FreeBSD Diary pour une description détaillée de la méthode pour faire fonctionner Bacula sur votre système. De plus, les utilisateurs de versions de FreeBSD antérieures à la 4.9-STABLE du lundi 29 décembre 2003 15:18:01 qui envisagent d'utiliser des lecteurs de bandes doivent consulter le chapitre Tester son lecteur de bandes de ce manuel pour d'importantes informations sur la configuration des lecteurs pour qu'ils soient compatibles avec Bacula.

Win32

Pour installer la version binaire Win32 du File Daemon, consultez le chapitre Installation sur systèmes Win32 de ce document.

Systèmes Windows avec CYGWIN installé

Si vous souhaitez compiler les sources, il vous faudra Microsoft C++ version 6.0 ou supérieur. Dans les versions de Bacula antérieures à la 1.33, CYGWIN était utilisé. A partir de la version 1.33, la version CYGWIN du client Bacula a été abandonnée au profit d'un client Win32 natif (File Daemon).

Notez qu'en dépit du fait que la plupart des éléments de Bacula puissent compiler sur les systèmes Windows, la seule partie que nous ayons testée et utilisée est le File Daemon.

Finalement, vous devriez suivre les instructions d'installation de la section Win32 Installation sur systèmes Win32 de ce document en occultant la partie qui décrit la décompression de la version binaire.

Le script Configure de Kern

Voici le script que j'utilise pour compiler sur mes machines Linux de "production":
#!/bin/sh
# This is Kern's configure script for Bacula
CFLAGS="-g -Wall" \
  ./configure \
    --sbindir=$HOME/bacula/bin \
    --sysconfdir=$HOME/bacula/bin \
    --enable-smartalloc \
    --enable-gnome \
    --with-pid-dir=$HOME/bacula/bin/working \
    --with-subsys-dir=$HOME/bacula/bin/working \
    --with-mysql=$HOME/mysql \
    --with-working-dir=$HOME/bacula/bin/working \
    --with-dump-email=$USER \
    --with-smtp-host=mail.your-site.com \
    --with-baseport=9101
exit 0
Notez que je fixe le port de base à 9101, ce qui signifie que Bacula utilisera le port 9101 pour la console Director, le port 9102 pour le File Daemon, et le 9103 pour le Storage Daemon. Ces ports devraient être disponibles sur tous les systèmes étant donné qu'ils ont été officiellement attribués à Bacula par l'IANA (Internet Assigned Numbers Authority). Nous recommandons fortement de n'utiliser que ces ports pour éviter tout conflit avec d'autres programmes. Ceci est en fait la configuration par défaut si vous n'utilisez pas l'option --with-baseport.

Vous pouvez aussi insérer les entrées suivantes dans votre fichier /etc/services de façon à rendre les connections de Bacula plus aisées à repérer (i.e. netstat -a):

bacula-dir      9101/tcp
bacula-fd       9102/tcp
bacula-sd       9103/tcp

Installer Bacula

Avant de personnaliser vos fichiers de configuration, vous voudrez installer Bacula dans son répertoire définitif. tapez simplement:
make install
Si vous avez précédemment installé Bacula, les anciens binaires seront écrasés, mais les anciens fichiers de configuration resteront inchangés, et les "nouveaux" recevront l'extension .new. Généralement, si vous avez déjà installé et exécuté Bacula, vous préfèrerez supprimer ou ignorer les fichiers de configuration avec l'extension .new

Compiler un File Daemon (ou Client)

Si vous exécutez le Director et le Storage Daemon sur une machine et si vous voulez sauvegarder une autre machine, vous devez avoir un File Daemon sur cette machine. Si la machine et le système sont identiques, vous pouvez simplement copier le binaire du File Daemon bacula-fd ainsi que son fichier de configuration bacula-fd.conf, puis modifier le nom et le mot de passe dans bacula-fd.conf de façon à rendre ce fichier unique. Veillez à faire les modifications correspondantes dans le fichier de configuration du Director (bacula-dir.conf).

Si les architectures, les systèmes, ou les versions de systèmes diffèrent, il vous faudra compiler un File Daemon sur la machine cliente. Pour ce faire, vous pouvez utiliser la même commande ./configure que celle utilisée pour construire le programme principal, soit en partant d'une copie fraiche du répertoire des sources, soit en utilisant make distclean avant de lancer ./configure.

Le File Daemon n'ayant pas d'accès au catalogue, vous pouvez supprimer les option --with-mysql ou --with-sqlite. Ajoutez l'option --enable-client-only. Ceci va compiler seulement les librairies et programmes clients, et donc éviter d'avoir à installer telle ou telle base de données. Lancez make avec ctte configuration, et seul le client sera compilé.

Démarrage automatique des Daemons

Si vous souhaitez que vos daemons soient lancés automatiquement au démarrage de votre système (une bonne idée !), une étape supplémentaire est requise. D'abord, le processus ./configure doit reconnaître votre système -- ce qui signifie que ce doit être une plate-forme supportée et non inconnue, puis vous devez installer les fichiers dépendants de la plate-forme comme suit :
(devenez root)
make install-autostart
Notez que la fonction d'autodémarrage n'est implémentée que pour les systèmes que nous supportons officiellement (actuellement FreeBSD, RedHat Linux, et Solaris), et n'a été pleinement testée que sur RedHat Linux.

make install-autostart installe les scripts de démarrage apropriés ainsi que les liens symboliques nécessaires. Sur RedHat Linux, Ces scripts résident dans /etc/rc.d/init.d/bacula-dir /etc/rc.d/init.d/bacula-fd, et /etc/rc.d/init.d/bacula-sd. Toutefois, leur localisation exacte dépend de votre système d'exploitation.

Si vous n'installez que le File Daemon, tapez:

make install-autostart-fd

Autres notes concernant la compilation

Pour recompiler tout exécutable, tapez

make
dans le répertoire correspondant.. Afin d'éliminer tous les objets et binaires (y compris les fichiers temporaires nommés 1,2 ou 3 qu'utilise Kern), tapez
make clean

Pour un nettoyage exhaustif en vue de distribution, entrez:

make distclean
. Notez que cette commande supprimme les Makefiles. Elle est en principe lancée depuis la racine du répertoire des sources pour les préparer à la distribution. Pour revenir de cet état, vous devez réexécuter la commande ./configure à la racine des sources puisque tous les Makefiles ont été détruits.

Pour ajouter un nouveau fichier dans un sous-répertoire, éditez Makefile.in dans ce sous-répertoire, puis faites un simple make. Dans la plupart des cas, le make reconstruira le Makefile à partir du nouveau Makefile.in. Dans certains cas, il peut être nécessaire d'exécuter make une deuxième fois. Dans les cas extrèmes, remontez à la racine des sources et entrez make Makefiles.

Pour ajouter des dépendances:

make depend
La commande make depend insère la les fichiers d'en-têtes de dépendances aux Makefile et Makefile.in pour chaque fichier objet. Cette commande devrait être lancée dans chaque répertoire où vous modifiez les dépendances. En principe, il suffit de l'exécuter lorsque vous ajoutez ou supprimez des sources ou fichiers d'en-têtes. make depend est invoqué automatiquement durant le processus de configuration.

Pour installer:

make install
En principe, vous n'utilisez pas cette commande si vous êtes en train de développer Bacula, mais si vous vous apprétez à l'exécuter pour sauvegarder vos systèmes.

Après avoir lancé make install, les fichiers suivants seront installés sur votre système (à peu dechoses près). La liste exacte des fichiers installés et leur localisation dépend de votre commande c./configure (e.g. gnome-console et gnome-console.conf ne sont pas installés si vous ne configurez pas GNOME. De même, si vous utilisez SQLite plutôt que MySQL, certains fichiers seront différents.

bacula
bacula-dir
bacula-dir.conf
bacula-fd
bacula-fd.conf
bacula-sd
bacula-sd.conf
bacula-tray-monitor
tray-monitor.conf
bextract
bls
bscan
btape
btraceback
btraceback.gdb
bconsole
bconsole.conf
create_mysql_database
dbcheck
delete_catalog_backup
drop_bacula_tables
drop_mysql_tables
fd
gnome-console
gnome-console.conf
make_bacula_tables
make_catalog_backup
make_mysql_tables
mtx-changer
query.sql
bsmtp
startmysql
stopmysql
wx-console
wx-console.conf

Installer Tray Monitor

Le Tray Monitor est déjà installé si vous avez utilisé l'option --enable-tray-monitor de la commande configure et exécuté make install.

Comme vous n'exécutez pas votre environnement graphique en tant que root (si vous le faites, vous devriez changer cette mauvaise habitude), n'oubliez pas d'autoriser votre utilisateur à lire tray-monitor.conf, et exécuter bacula-tray-monitor (ceci ne constitue pas une faille de sécurité).

Puis, connectez vous à votre environnement graphique (KDE, Gnome, ou autre), lancez bacula-tray-monitor avec votre utilisateur et observer si l'icone d'une cartouche apparaît quelque part sur l'écran, usuellement dans la barre des tâches.
Sinon, suivez les instructions suivantes relatives à votre gestionnaire de fenètres.

GNOME

System tray, ou zone de notification si vous utilisez la terminologie GNOME, est supporté par GNOME depuis la version 2.2. Pour l'activer, faites un click droit sur un de vos espaces de travail, ouvrez le menu Ajouter à ce bureau, puis Utilitaire et enfin, cliquez sur Zone de notification. (NDT: A valider)

KDE

System tray est supporté par KDE depuis la version 3.1. Pour l'activer, faites un click droit sur la barre de tâches, ouvrez le menu Ajouter, puis Applet, enfin cliquez sur System Tray.

Autres gestionnaires de fenètres

Lisez la documentation pour savoir si votre gestionnaire de fenètres supporte le standard systemtray de FreeDesktop, et comment l'activer le cas échéant.

Modifier les fichiers de configuration de Bacula

Consultez le chapitreConfiguring Bacula de ce manuel pour les instructions de configuration de Bacula.


Back
Démarrer avec Bacula
Index
Index
Next
Exécuter Bacula
Bacula 1.35 - Mode d'emploi
La solution de sauvegardes réseau
Copyright © 2000-2004
Kern Sibbald et John Walker