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 paquetages externes (tels SQLite, MySQL ou PostgreSQL) pour compiler correctement en accord avec les options que vous aurez choisies. Pour vous simplifier la tâche, nous avons combiné plusieurs de ces programmes dans deux paquetages depkgs (paquetages 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.
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ées du catalogue a été mise à jour (c'est presque toujours le cas à chaque nouvelle version majeure), 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. Ceci est normalement fait lorsque Bacula est compilé et installé par :
cd <installed-scripts-dir> (default /etc/bacula) ./update_bacula_tables
Ce script de mise à jour peut aussi être trouvé dans le répertoire src/cats des sources de Bacula.
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.
Enfin, notez qu'il n'est généralement pas nécessaire d'utiliser make uninstall avant de procéder à une mise à jour. En fait, si vous le faites vous effacerez probablement vos fichiers de configuration, ce qui pourrait être désastreux. La procédure normale de mise à jour est simplement :
./configure (your options) make make install
En principe, aucun de vos fichiers .conf ou .sql ne devrait être écrasé, et vous devez exécuter les deux commandes make et make install. make install sans un make préalable ne fonctionnera pas.
Pour plus d'informations sur les mises à jour, veuillez consulter la partie Upgrading Bacula Versions du chapitre Astuces de ce manuel
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.
Vous pouvez, bien sur, obtenir les dernieres versions de ces paquetages de leurs auteurs. Les références nécessaires figurent dans le README de chaque paquet. Quoi qu'il en soit, soyez conscient du fait que nous avons testé la compatibilité des paquetages des fichiers depkgs.
Typiquement, un paquetage de dépendances sera nommé depkgs-ddMMMyy.tar.gz et depkgs1-ddMMMyy.tar.gz où dd 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 paquetage (s'il est requis), vous devez:
La composition exacte des paquetages de dépendance est susceptible de changer de temps en temps, voici sa composition actuelle :
| Paquets externes | depkgs | depkgs1 |
| SQLite | X | - |
| SQLite3 | X | - |
| mtx | X | - |
| readline | - | X |
| pthreads | - | - |
| zlib | - | - |
| wxWidgets | - | - |
Notez que certains de ces paquets sont de taille respectable, si bien que l'étape de compilation peut prendre un certain 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 est obsolète à partir de la version 1.39 de Bacula. Il était autrefois utilisé pour compiler le client natif Win32 qui est désormais construit sur Linux grâce à un mécanisme de compilation croisée. Tous les outils et librairies tierces sont automatiquement téléchargées par l'exécution de scripts apropriés. Lisez le fichier src/win32/README.mingw32 pour plus de détails.
Veuillez consulter la section Systèmes supportés du chapitre Démarrer avec Bacula de ce manuel.
L'installation basique est plutôt simple.
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.
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.
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.
Si vous ignorez cette étape (make) et poursuivez immédiatement avec make install, vous commettez deux erreurs sérieuses : d'abord, votre installation va échouer car Bacula a besoin d'un make avant un make install ; ensuite, vous vous privez de la possibilité de vous assurer qu'il n'y a aucune erreur avant de commencer à écrire les fichiers dans vos répertoires système.
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ésactivé.
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 y a 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 Fedora, RedHat ou SuSE, 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 \
--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 confèrent 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 la plupart des systèmes, y compris RedHat et SuSE, vous
devriez inclure le paquet ncurses. Si Le processus de configuration de
Bacula le détecte, il l'utilisera plutôt que la librairie termcap.
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
lors de la compilation 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, ou si vous utilisez une librairie MySQL qui requiert le chiffrement. Dans ce dernier cas, vous pouvez exporter les librairies additionnelles comme indiqué ci-dessus ou, alternativement, les inclure directement en paramètres de la commande ./configure comme ci-dessous :
LDFLAGS="-lssl -lcyrpto" \
./configure <vos-options>
Veuillez noter que sur certains systèmes tels que Mandriva, 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 paquetage conio gobe vos
invites de commandes.
Readline n'est plus supporté depuis la version 1.34. Le code reste disponible, et si des utilisateurs soumettent des patches, je serai heureux de les appliquer. Cependant, étant donné que chaque version de readline semble incompatible avec les précédentes, et qu'il y a des différences significatives entre les systèmes, je ne puis plus me permettre de le supporter.
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. Ceci vous facilitera beaucoup l'installation car SQLite est compilé dans Bacula et ne requiert aucune administration. SQLite fonctionne bien et sied bien aux petites et moyennes configurations (maximum 10-20 machines). Cependant, il nous faut signaler que plusieurs utilisateurs ont subi des corruptions inexpliquées de leur catalogue SQLite. C'est pourquoi nous recommandons de choisir MySQL ou PostgreSQL pour une utilisation en production.
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. MySQL est une base de données de haute qualité très efficace et qui convient pour des configurations de toutes tailles. MySQL est légèrement plus complexe à installer et administrer que SQLite en raison de ses nombreuses fonctions sophistiquées telles que userids et mots de passe. MySQL fonctionne en tant que processus distinct, est réellement une solution professionnelle et peut prendre en charge des bases de données de dimension quelconque.
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. PostgreSQL est très similaire à MySQL bien que tendant à être un peu plus conforme à SQL92. PostgreSQL possède beaucoup plus de fonctions avancées telles que les transactions, les procédures stockées, etc. PostgreSQL requiert une certaine connaissance pour son installation et sa maintenance.
Si vous souhaitez utiliser SQLite pour votre catalogue Bacula, consultez le chapitre Installer et Configurer SQLite de ce manuel.
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 le processus ./configure ne parvient pas à trouver les librairies spécifiques (par exemple libintl), assurez vous que le paquetage approprié est installé sur votre système. S'il est installé dans un répertoire non standard (au moins pour Bacula), il existe dans la plupart des cas une option parmi celles énumérées ci-dessous (ou avec "./configure --help") qui vous permettra de spécifier un répertoire de recherche. D'autres options vous permettent de désactiver certaines fonctionnalités (par exemple --disable-nls).
Si vous souhaitez vous jeter à l'eau, nous vous conseillons de passer directement au chapitre suivant, et d'exécuter 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.
TAQUET MISE A JOUR
Les options en ligne de commande suivantes sont disponibles pour configure afin d'adapter votre installation à vos besoins.
Par défaut, Bacula installe une simple page de manuel dans /usr/share/man. Si vous voulez qu'elle soit installée ailleurs, utilisez cette options pour spécifier le chemin voulu. Notez que les principaux documents Bacula en HTML et PDF sont dans une archive tar distincte des sources de distribution de Bacula.
--disable-static-tools.
--enable-client-only décrite plus loin est aussi intéressante
pour compiler un simple client sans les autres parties du programme.
Pour lier un binaire statique, l'éditeur de liens a besoin des versions statiques de toutes les librairies utilisées, aussi les utilisateurs rencontrent fréquemment des erreurs d'édition de liens à l'utilisation de cette option. La première chose à faire est de s'assurer d'avoir la librairie glibc statiquement liée sur votre système. Ensuite, il faut s'assurer de ne pas utiliser les options --openssl ou --with-python de la commande configure, car elle requierent des librairies supplémentaires. Vous devriez pouvoir activer ces options, mais il vous faudra charger les librairies statiques additionnelles correspondantes.
Pour lier un binaire statique, l'éditeur de liens a besoin des versions statiques de toutes les librairies utilisées, aussi les utilisateurs rencontrent fréquemment des erreurs d'édition de liens à l'utilisation de cette option. La première chose à faire est de s'assurer d'avoir la librairie glibc statiquement liée sur votre système. Ensuite, il faut s'assurer de ne pas utiliser les options --openssl ou --with-python de la commande configure, car elle requierent des librairies supplémentaires. Vous devriez pouvoir activer ces options, mais il vous faudra charger les librairies statiques additionnelles correspondantes.
Pour lier un binaire statique, l'éditeur de liens a besoin des versions statiques de toutes les librairies utilisées, aussi les utilisateurs rencontrent fréquemment des erreurs d'édition de liens à l'utilisation de cette option. La première chose à faire est de s'assurer d'avoir la librairie glibc statiquement liée sur votre système. Ensuite, il faut s'assurer de ne pas utiliser les options --openssl ou --with-python de la commande configure, car elle requierent des librairies supplémentaires. Vous devriez pouvoir activer ces options, mais il vous faudra charger les librairies statiques additionnelles correspondantes.
Pour lier un binaire statique, l'éditeur de liens a besoin des versions statiques de toutes les librairies utilisées, aussi les utilisateurs rencontrent fréquemment des erreurs d'édition de liens à l'utilisation de cette option. La première chose à faire est de s'assurer d'avoir la librairie glibc statiquement liée sur votre système. Ensuite, il faut s'assurer de ne pas utiliser les options --openssl ou --with-python de la commande configure, car elle requierent des librairies supplémentaires. Vous devriez pouvoir activer ces options, mais il vous faudra charger les librairies statiques additionnelles correspondantes.
Pour lier un binaire statique, l'éditeur de liens a besoin des versions statiques de toutes les librairies utilisées, aussi les utilisateurs rencontrent fréquemment des erreurs d'édition de liens à l'utilisation de cette option. La première chose à faire est de s'assurer d'avoir la librairie glibc statiquement liée sur votre système. Ensuite, il faut s'assurer de ne pas utiliser les options --openssl ou --with-python de la commande configure, car elle requierent des librairies supplémentaires. Vous devriez pouvoir activer ces options, mais il vous faudra charger les librairies statiques additionnelles correspondantes.
--disable-largefile.
Voyez aussi la note ci-dessous, après le paragraphe --with-postgreSQL
Voyez aussi la note ci-dessous, après le paragraphe --with-postgreSQL
Voyez aussi la note ci-dessous, après le paragraphe --with-postgreSQL
Notez que pour que Bacula soit configuré correctement, vous devez spécifier l'une des quatre options de bases de données supportées : --with-sqlite, --with-sqlite3, --with-mysql, ou --with-postgresql, faute de quoi ./configure échouera.
--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. Readline n'est désormais plus supporté, ce qui signifie que
vous l'utilisez à vos risques et périls
Pour plus d'informations sur la configuration et les tests de TCP wrappers, consultez la section Configurer et Tester TCP Wrappers du chapitre sur la sécurité.
Sur SuSE, les librairies libwrappers requises pour lier Bacula appartiennent au paquet tcpd-devel. Sur RedHat, le paquet se nomme tcp_wrappers.
--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.
Notez: de nombreuses options supplémentaires vous sont présentées
lorsque vous entrez ./configure --help, mais elles ne sont pas
implémentées.
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 de compilation, (comme le
feront les développeurs la plupart du temps), vous devriez aussi inclure les
options --sbindir et --sysconfdir avec les chemins approprié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. Le processus
d'installation va créer les répertoires sbindir et sysconfdir s'ils
n'existent pas, mais il ne créera pas les répertoires pid-dir, subsys-dir
ni working-dir, aussi assurez vous qu'ils existent avant de lancer Bacula.
L'exemple ci-dessous montre la façon de procéder de Kern.
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
ou une installation RedHat complètement traditionnelle :
CFLAGS="-g -Wall" ./configure \ --prefix=/usr \ --sbindir=/usr/sbin \ --sysconfdir=/etc/bacula \ --with-scriptdir=/etc/bacula \ --enable-smartalloc \ --enable-gnome \ --with-mysql \ --with-working-dir=/var/bacula \ --with-pid-dir=$HOME/var/run \ --enable-conio
Notez que Bacula suppose que les répertoires /var/bacula, /var/run et /var/lock/subsys existent, ils ne seront pas crées par le processus d'installation.
D'autre part, avec gcc 4.0.1 20050727 (Red Hat 4.0.1-5) sur processeur AMD64 et sous CentOS4 64 bits, un bug du compilateur génère du code erroné qui conduit Bacula à des erreurs de segmentation. Typiquement, vous le rencontrerez d'abord avec le Storage Daemon. La solution consiste à s'assurer que Bacula est compilé sans optimisation (normalement -O2)
Pour installer Bacula depuis les sources, il vous faudra les paquetages suivants sur votre système (ils ne sont pas installés par défaut) : libiconv, gcc 3.3.2, stdc++, libgcc ( pour les librairies stdc++ and gcc_s ), make 3.8 ou plus récent.
Il vous faudra probablement aussi ajouter /usr/local/bin et /usr/css/bin à PATH pour ar.
#!/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
Comme mentionné ci-dessus, le processus d'installation va créer les répertoires sbindir et sysconfdir s'ils n'existent pas, mais il ne créera pas les répertoires pid-dir, subsys-dir ni working-dir, aussi assurez vous qu'ils existent avant de lancer Bacula.
Notez que vous pouvez aussi avoir besoin des paquetages suivants pour installer Bacula depuis les sources :
SUNWbinutils, SUNWarc, SUNWhea, SUNWGcc, SUNWGnutls SUNWGnutls-devel SUNWGmake SUNWgccruntime SUNWlibgcrypt SUNWzlib SUNWzlibs SUNWbinutilsS SUNWGmakeS SUNWlibm export PATH=/usr/bin::/usr/ccs/bin:/etc:/usr/openwin/bin:/usr/local/bin:/usr/sfw/bin:/opt/sfw/bin:/usr/ucb:/usr/sbin
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.
Si vous utilisez Bacula avec MySQL, vous devriez prendre garde à compiler MySQL avec les threads natifs de FreeBSD plutôt qu'avec ceux de Linux, car c'est avec ceux là qu'est compilé Bacula et le mélange des deux ne fonctionnera probablement pas.
Pour installer la version binaire Win32 du File Daemon, consultez le chapitre Installation sur systèmes Win32 de ce document.
A partir de la version 1.34, Bacula n'utilise plus CYGWIN pour le client Win32. Il est cependant encore compilé sous un environnement CYGWIN -- Bien que vous puissiez probablement le faire avec seulement VC Studio. Si vous souhaitez compiler le client Win32 depuis 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é.
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 avons 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.
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
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
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 cette configuration, et seul le client sera
compilé.
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
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 supprime 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 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 de choses 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 bwx-console bwx-console.conf
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 observez 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.
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)
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.
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.
Consultez le chapitre Configurer Bacula de ce manuel pour les instructions de configuration de Bacula.