Note
Si vous voulez juste utiliser Bugzilla, vous n'avez pas besoin de l'installer. Aucun de ces chapitres ne vous concerne. Demandez à votre administrateur Bugzilla l'URL pour y accéder par avec votre navigateur Web.
Le logiciel serveur Bugzilla est habituellement installé sur GNU/Linux ou Solaris. Si vous l'installez sur un autre système d'exploitation, vérifiez Notes d'installation spécifiques aux systèmes d'exploitation avant de commencer votre installation pour voir s'il n'y a pas des instructions particulières.
Ce guide suppose que vous avez un accès administrateur à la machine Bugzilla. Il n'est pas possible d'installer et d'exécuter Bugzilla sans accès administrateur, excepté dans la très improbable éventualité où tous les prérequis seraient déjà déjà installés.
Attention
Le processus d'installation peut rendre votre machine non-sûre pendant quelques courtes périodes. Assurez-vous qu'il y a un pare-feu entre vous et le réseau Internet.
Il est fortement recommandé de faire une sauvegarde de votre système avant d'installer Bugzilla (et à intervalles réguliers après cela :-).
Dans les grandes lignes, l'installation se déroule ainsi :
Test de la version installée :
$ perl -v
Toute machine n'ayant pas Perl installé est une machine bien triste. Si vous ne l'avez pas et que votre système d'exploitation ne fournit pas de paquets officiels, visitez http://www.perl.org. Bien que Bugzilla fonctionne avec Perl 5.10.1, c'est une bonne idée que d'utiliser la dernière version stable.
Bugzilla gère les serveurs de bases de données MySQL, PostgreSQL et Oracle. Vous n'avez besoin que d'un seul de ces moteurs de base de données pour faire fonctionner Bugzilla.
Test de la version installée :
$ mysql -V
Si vous ne l'avez pas et que votre système d'exploitation ne fournit pas de paquets officiels, visitez http://www.mysql.com. Vous avez besoin de MySQL version 5.0.15 ou supérieur.
Note
Beaucoup de versions bianires de MySQL stockent leurs fichiers de données dans le répertoire /var. Sur certains systèmes Unix, ce répertoire fait partie d'une plus petite partition root, et peut ne pas avoir assez de place pour votre base de données de bogues. Pour changer le répertoire des données, vous devez compiler MySQL à partir des sources vous-même, et le définir comme option pour configure.
Si vous installez à partir d'autre chose qu'un des systèmes d'installation/empaquet suivants : .rpm (paquet RPM), .deb (paquet Debian), .exe (exécutable Windows) ou .msi (Microsoft Installer), assurez-vous que le serveur MySQL soit lancé au démarrage de la machine.
Test de la version installée :
$ psql -V
Si vous ne l'avez pas et si votre système d'exploitation ne fournit pas de paquets officiels, visitez http://www.postgresql.org/. Vous avez besoin de PostgreSQL version 8.03.0000 ou supérieur.
Si vous installez à partir d'autre chose qu'un des systèmes d'installation/empaquet suivants : .rpm (paquet RPM), .deb (paquet Debian), .exe (exécutable Windows) ou .msi (Microsoft Installer), assurez-vous que le serveur PostGreSQL soit lancé au démarrage de la machine.
Test de la version installée :
SELECT * FROM v$version
(vous devez d'abord vous connectez à votre base de données)
Si vous ne l'avez pas ou que votre système d'exploitation ne fournit pas de paquets officiels, visitez http://www.oracle.com/. Vous devez avoir Oracle version 10.02.0 ou supérieure.
Si vous installez à partir de quelque chose d'autre qu'un paquet/installation système, comme un .rpm (paquet RPM), un .deb (paquet Debian), un .exe (exécutable Windows), ou un .msi (Microsoft Installer), assurez-vous que le serveur Oracle est démarré au lancement de la machine.
Test de la version installée : Consultez la page d'accueil par défaut sur http://<votre-machine>/
Vous avez la liberté de choix ici, pratiquement n'importe quel serveur capable d'exécuter des scripts CGI fonctionnera. Cependant, nous vous recommandons fortement d'utiliser un serveur Apache (version 1.3.x ou 2.x), et les instructions d'installation supposent généralement que vous utilisez Apache. Si vous utilisez Bugzilla avec un autre serveur Web, veuillez partager vos expériences en rapportant un bogue dans http://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla;component=Documentation.
Si vous n'avez pas Apache et que votre système d'exploitation ne fournit pas de paquets officiels, visitez http://httpd.apache.org/.
Téléchargez une archive de Bugzilla (ou récupérez-le à partir de Bzr) et placez-le dans un répertoire approprié accessible par l'utilisateur par défaut du serveur Web (probablement apache ou www). Les meilleurs emplacements sont dans les répertoires de documents du serveur Web ou dans /usr/local avec un lien symbolique vers les répertoires de documents du serveur Web ou un alias dans la configuration du serveur Web.
Attention
La distribution par défaut de Bugzilla n'est PAS conçue pour être placée dans un répertoire cgi-bin. Ceci inclut tout répertoire configué en utilisant la directive ScriptAlias d'Apache.
Quand tous les fichiers sont dans un répertoire accessible par le serveur Web, rendez le répertoire accessible en écriture pour l'utilisateur de votre serveur Web. Ceci est une étape temporaire jusqu'à ce que vous exécutiez le script checksetup.pl qui verrouille votre installation.
Le processus d'installation de Bugzilla est basé sur un script appelé checksetup.pl. La première chose qu'il fait est de vérifier si vous avez les versions appropriées de tous les modules Perl requis. Le propos de cette section est de passer cette vérification. quand elle est passée, procédez à la Configuration.
À partir de ce point, vous devez faire la commande su - root. Vous devrez demeurer root jusqu'à la fin de l'installation. Pour vérifier que vous avez les modules requis, exécutez :
# ./checksetup.pl --check-modules
checksetup.pl affichera une liste de tous les modules Perl requis et optionnels avec leur numéro de version (le cas échéant) installés sur votre machine. La liste des modules requis est plutôt longue ; cependant, vous devez déjà avoir plusieurs d'entre eux installés.
La manière à privilégier pour installer les modules Perl manquants est d'utiliser le gestionnaire de paquets fourni par votre système d'exploitation (par ex. rpm ou apt-get ou yum pour les ditributions GNU/Linux, ou ppm pour Windows si vous utilisez ActivePerl, consulter Modules Perl sur Win32). Si certains modules Perl sont toujours manquants ou sont trop vieux, nous vous recommandons alors d'utiliser le script install-module.pl (il ne fonctionne pas avec ActivePerl sous Windows). Par exemple, sous GNU/Linux, le script install-module.pl est exécuté ainsi :
# perl install-module.pl <modulename>
Note
Beaucoup de gens se plaignent que les modules Perl ne s'installent pas pour eux. La plupart du temps, les messages d'erreur indiquent un fichier manquant dans @INC. Pratiquement à chaque fois, cette erreur est due aux permissions qui sont trop restrictives pour compiler les modulesPerl ou à l'absence des bibliothèques de développement Perl installées sur votre système. Consultez votre administrateur système Unix local pour vous aider à résoudre ces problèmes de permissions ; si vous êtes l'administrateur système Unix local, veuillez consulter le forum ou la liste de discussion pour plus d'assistance ou engagez quelqu'un pour vous aider.
Note
Si vous utilisez un paquet fourni par votre système d'exploitation et que vous essayez d'installer les modules Perl à partir de CPAN, vous aurez peut-être besoin d'installer les paquets développement pour MySQL et GD avant d'essayer d'installer les modules Perl relatifs. Le nom de ces paquets varieront en fonction de la distribution que vous utilisez, mais ils sont souvent appelés <nom_paquet>-devel.
Si pour une raison ou une autre vous avez vraiment besoin d'installer les modules Perl manuellement, consulter Manuel d'installation des modules Perl.
Bugzilla dépend de la disponibilité d'un système de messagerie pour son authentification utilisateur et d'autres tâches.
Note
Ce n'est pas entièrement vrai. Il est possiblede désactiver complètement l'envoi de courriels, ou de faire stocker à Bugzilla les courriels dans un fichier plutôt que de les envoyer. Cependant, c'est principalement destiné aux tests, car désactiver ou détourner des courriels sur une machine de production signifierait que les utilisateurs pourrait manquer d'importants événements (comme les changements sur les bogues et la création de nouveaux comptes). Pour plus d'informations, consultez le paramètre mail_delivery_method dans Configuration de Bugzilla.
Sous GNU/Linux, tout MTA (Mail Transfer Agent) compatible avec Sendmail suffira. Sendmail, Postfix, qmail et Exim sont des exemples de MTA courants. Sendmail est le MTA original d'Unix, mais les autres sont plus faciles à configurer et par conséquent, beaucoup de gens remplacent Sendmail par Postfix ou Exim. Ce sont des remplacements trasparents donc Bugzilla ne fera pas la différence.
Si vous utilisez Sendmail, la version 8.7 ou supérieure est requise. Si vous utilisez un MTA compatible avec Sendmail, il doit être congruent avec au moins la version 8.7 de Sendmail.
Consultez le manuel du MTA que vous avez choisi pour des instructions d'installation détaillées. Chacun de ces programmes a ses propres fichiers de configuration ou vous devez configurer certains paramètres pour vous assurer que les courriels seront distribués correctement. Ils sont mis en œuvres en tant que services et vous devez vous assurer que le MTA est dans la liste de démarrage automatiques des services de votre machine.
Si un courrier envoyé avec le programme en ligne de commande mail réussit, alors Bugzilla devrait fonctionner correctement.
Il est maintenant possible d'exécuter Bugzilla dans mod_perl sur Apache. mod_perl a des prérequis supplémentaires autre que celui d'exécuter Bugzilla sous mod_cgi (la manière standard et précédente).
Bugzilla nécessite que mod_perl soit installé, lequel peut être obtenu sur http://perl.apache.org - Bugzilla nécessite que la version 1.999022 (aussi connue comme 2.0.0-RC5) soit installée.
Attention
Des installations mal configurées de MySQL et Bugzilla ont permis de donner l'accès complet au système aux pirates dans le passé. Veuillez prendre au sérieux les recommandations sur la sécurité de ce guide, même pour des machines Bugzilla protégées derrière votre pare-feu. Assurez-vous de lire La sécurité dans Bugzilla pour ces conseils sur la sécurité importants.
Vous devez maintenant exécuter checksetup.pl à nouveau, cette fois sans l'argument --check-modules.
# ./checksetup.pl
Cette fois, checksetup.pl devrait vous dire que tous les modules appropriés sont installés et affichera un message à ce sujet, et générera un fichier de sortie appelé localconfig. Ce fichier contient les paramètres par défaut pour un grand nombre de paramètres de Bugzilla.
Ouvrez ce fichier dans votre éditeur. Les deux seules valeurs que vous avez besoin de changer sont $db_driver et $db_pass, respectivement le type de base de données et le mot de passe pour l'utilisateur qui créera pour vous la base de données. Choisissez un mot de passe compliqué (pour la simplicité, il ne dervait pas contenir d'apostrophe) et saisissez-le dans le fichier. $db_driver peut être 'mysql', 'Pg', 'oracle' ou 'SQLite'.
Note
Sous Oracle, $db_name devrait en fait être le nom du SID de votre base de données (par ex. XE si vous utilisez Oracle XE).
Vous devrez peut-être changer la valeur de webservergroup si votre serveur Web ne s'exécute pas dans le groupe apache. Sur Debian, par exemple, Apache s'exécute dans le groupe www-data. Si vous allez exécuter Bugzilla sur une machine où vous n'avez pas l'accès root (comme sur un serveur Web partagé hébergé), vous aurez besoin de laisser webservergroup vide, en ignorant les avertissements que checksetup.pl affichera à chacune de ses exécutions.
Attention
Si vous utilisez suexec, vous devez utiliser votre propre groupe principal pour webservergroup plutôt que de le laisser vide, et consultez les autres directives dans la section suexec suexec ou hébergement partagé.
Les autres options du fichier localconfig sont documentés par les commentaires les accompagnant. Si vous avez une configuration légèrement non-standard, vous voudrez sans doute modifier un ou plusieurs autres paramètres $db_*.
Cette section traite de la configuration de votre serveur de base de données utilisé avec Bugzilla. Actuellement, MySQL (MySQL), PostgreSQL (PostgreSQL), Oracle (Oracle) et SQLite (SQLite) sont disponibles.
Le schéma de la base de données de Bugzilla est disponible est disponible sur Ravenbrook. Cet outil très utile peut générer une description écrite du schéma de la base de données de Bugzilla pour toute version de Bugzilla. Il peut aussi générer un diff entre deux versions pour aider quelqu'un à voir ce qui a changé.
Attention
La configuration par défaut de MySQL est peu sécurisée. Nous vous recommandons vivement d'exécuter mysql_secure_installation sous Linux ou l'installeur de MySQL sous Windows, et de suivre les instructions. Les points importants à noter sont :
Par défaut, MySQL ne vous autorisera à insérer dans la base de données, que des objets plus petits que 1 Mo. Les fichiers joints peuvent être plus gros que cela. De même, Bugzilla concatène tous les commentaires d'un bogue dans un seul champ pour la recherche plein texte, et la somme de tous les commentaires d'un bogue sera vraisemblablement supérieure à 1 Mo.
Pour changer ce paramètre par défaut de MySQL, vous devez modifier votre fichier de configuration MySQL, qui est habituellement /etc/my.cnf sous Linux. Nous vous recommandons d'autoriser au moins des packets de 4 Mo en ajoutant le paramètre max_allowed_packet dans votre fichier de configuration MySQL dans la section [mysqld], comme ceci :
[mysqld]
# Allow packets up to 4MB
max_allowed_packet=4M
Par défaut, les mots doivent avoir au moins quatre caractères afin d'être indéxés par les index texte intégral de MySQL. Ceci fait que beaucoup de mots clés spécifique peuvent être manqués, y compris cc, ftp et uri.
MySQL peut être configuré pour indexer ces mots en définissant le paramètre ft_min_word_len pour la taille minimale des mots à indexer. Ceci peut être fait en modifiant le fichier /etc/my.cnf comme l'indique l'exemple ci-dessous :
[mysqld]
# Allow small words in full-text indexes
ft_min_word_len=2
La reconstruction des index peut être faite en suivant les indications de la documentation sur http://www.mysql.com/doc/fr/Fulltext_Fine-tuning.html.
Vous avez besoin d'ajouter un nouvel utilisateur à MySQL pour Bugzilla. (Il n'est pas sûr de faire utiliser par Bugzilla le compte root de MySQL). Les instructions suivantes supposent que vous utilisez les options par défaut dans localconfig; si vous changez celles-ci, vous devez modifier la commande SQL en conséquence. Vous aurez besoin du mot de passe $db_pass que vous avez défini dans le fichier localconfig: localconfig.
Nous utilisons une commande SQL GRANT pour créer un utilisateur bugs. Ceci limite aussi l'utilisateur bugs aux opérations dans la base de données appelées bugs et ne permet à ce compte de se connecter qu'à partir de localhost. Modifiez-le pour refléter votre configuration si vous voulez vous connecter à partir d'une autre machine ou avec un utilisateur différent.
Exécutez le client en ligne de commande mysql et saisissez :
GRANT SELECT, INSERT,
UPDATE, DELETE, INDEX, ALTER, CREATE, LOCK TABLES,
CREATE TEMPORARY TABLES, DROP, REFERENCES ON bugs.*
TO bugs@localhost IDENTIFIED BY '*$db_pass*';
FLUSH PRIVILEGES;
Par défaut, MySQL limitera la table à 4 Go. Cette limite est présente même si le système d'exploitation sur lequel est exécuté MySQL n'a pas cette limite. Pour définir une limite plus haute, suivez ces instructions.
Après avoir terminé le reste de l'installation (ou au moins les parties concernant la configuration de la base de données), vous devez exécuter le client en ligne de commande MySQL et saisir les commandes suivantes, en remplaçant $bugs_db avec votre nom de base de données (bugs par défaut) :
use $bugs_db
ALTER TABLE attachments AVG_ROW_LENGTH=1000000, MAX_ROWS=20000;
La commande ci-dessus changera la limite à 20 Go. Mysql devra faire une copie temporaire de toute votre table pour faire ceci. Idéalement, vous devriez faire ceci quand la table des fichiers joint est encore petite.
Note
Ceci n'affecte pas le champ Gros fichiers, les fichiers qui sont stockés directement sur disque au lieu de la base de données.
Vous devez ajouter un nouvel utilisateur pour PostgreSQL pour que Bugzilla accède à la base de données. Les instructions suivantes supposent que vous utilisez les options par défaut dans localconfig; si vous changez celles-ci, vous devrez modifier les commandes en conséquence. Vous devrez utiliser le mot de passe $db_pass que vous vaez défini dans localconfig: localconfig.
Sur la plupart des systèmes, pour créer l'utilisateur dans PostgreSQL, vous devrez vous connecter en tant qu'utilisateur root et saisir la commande
# su - postgres
en tant qu'utilisateur postgres, vous devez créer un nouvel utilisateur :
$ createuser -U postgres -dRSP bugs
Quand un mot de passe vous sera demandé, fournissez le mot de passe qui sera défini pour $db_pass dans localconfig. L'utilisateur créé ne sera pas un super utilisateur (-S) et ne pourra pas créer de nouveaux utilisateurs (-R). Il aura seulement la possibilité de créer des bases de données (-d).
Note
Si vous utilisez PostgreSQL 8.0, vous devez remplacer -dRSP par -dAP.
Maintenant, vous devez modifier le fichier pg_hba.conf qui se trouve habituellement dans le répertoire /var/lib/pgsql/data/. Dans ce fichier, vous devez ajouter une nouvelle ligne, comme indiqué ci-dessous :
host all bugs 127.0.0.1 255.255.255.255 md5
Ceci signifie pour les connexions TCP/IP (hôte), de les autoriser pour 127.0.0.1 pour all (toutes) les bases de données de ce serveur pour l'utilisateur bugs, et d'utiliser l'authentification de mot de passe (md5) pour cet utilisateur.
Maintenant, vous devez redémarrer PostgreSQL, mais vous devrez arrêter complètement le serveur et le démarrer au lieu de seulement le redémarrer à cause de la possibilité d'un changement dans le fichier postgresql.conf. Après le redémarrage du serveur, vous devrez modifier le fichier localconfig, en cherchant la variable $db_driver et en la définissant à Pg et en changeant le mot de passe dans $db_pass pour celui que vous avez choisi précédemment, lors de la création du compte.
Vous pouvez utiliser un tablespace existant ou en créer un nouveau pour Bugzilla. Pour créer un nouveau tablespace, exécutez la commande suivante :
CREATE TABLESPACE bugs
DATAFILE '*$path_to_datafile*' SIZE 500M
AUTOEXTEND ON NEXT 30M MAXSIZE UNLIMITED
Ici, le nom du tablespace est 'bugs', mais vous pouvez choisir un autre nom. $path_to_datafile est le chemin d'accès au fichier contenant votre base de données, par exemple /u01/oradata/bugzilla.dbf. La taille initiale du fichier de base de données est défini dans cet exemple à 500 Mo, avec un incrément de 30 Mo chaque fois que la taille limite du fichier est atteinte.
Le nom d'utilisateur et le mot de passe doivent correspondre à ce que vous avez défini dans localconfig ($db_user et $db_pass, respectivement). Ici, nous supposons que l'utilisateur est 'bugs' et que le nom du tablespace est identique.
CREATE USER bugs
IDENTIFIED BY "$db_pass"
DEFAULT TABLESPACE bugs
TEMPORARY TABLESPACE TEMP
PROFILE DEFAULT;
-- GRANT/REVOKE ROLE PRIVILEGES
GRANT CONNECT TO bugs;
GRANT RESOURCE TO bugs;
-- GRANT/REVOKE SYSTEM PRIVILEGES
GRANT UNLIMITED TABLESPACE TO bugs;
GRANT EXECUTE ON CTXSYS.CTX_DDL TO bugs;
Si vous utilisez Apache, ajoutez ces lignes au fichier httpd.conf pour définir les variables ORACLE_HOME et LD_LIBRARY_PATH. Par exemple :
SetEnv ORACLE_HOME /u01/app/oracle/product/10.2.0/
SetEnv LD_LIBRARY_PATH /u01/app/oracle/product/10.2.0/lib/
Quand ceci est fait, redémarrez votre serveur Web.
Attention
En raison des limitations de concurrence de SQLite, nous ne le recommandons que pour des petites installations de Bugzilla ou des installations de développement.
Aucune configuration spéciale n'est requise pour exécuter Bugzilla avec SQLite. La base de données sera stockée dans data/db/$db_name, où $db_name est le nom de la base de données définie dans localconfig.
Ensuite, ré-exécutez checksetup.pl. Il confirmera à nouveau que tous les modules sont présents et remarquera la modification du fichier localconfig, en supposant que vous l'avez modifié à votre convenance. Il compile ensuite les modèles de l'interface utilisateur, se connecte à la base de données en utilisant l'utilisateur bugs que vous avez créé et le mot de passe que vous avez défini et crée enfin la base de données bugs et les tables à l'intérieur.
Après cela, il demande des détails sur le compte administrateur. Bugzilla peut avoir plusieurs administrateurs - vous pouvez en créer plus plus tard - mais il en a besoin d'un pour démarrer. Saisissez l'adresse électronique d'un administrateur, son nom complet, et un mot de passe approprié pour Bugzilla.
checksetup.pl se terminera alors. Vous pouvez relancer checksetup.pl à tous moments si vous le souhaitez.
Configurer votre serveur Web selon les instructions de la section appropriée. (Si cela peut faire une différence dans votre choix, l'équipe de Bugzilla recommande Apache). Pour vérifier si votre serveur Web est correctement configuré, essayez d'accéder à la page testagent.cgi à partir de votre serveur Web. Si OK est affiché, alors votre configuration est correcte. Peu importe le serveur Web que vous utilisez, assurez-vous que les informations sensibles ne sont pas accessibles à distance en appliquant des contrôles d'accès corrects dans Désactiver l'accès à distance aux fichiers de configuration. Vous pouvez exécuter testserver.pl pour vérifier si votre serveur Web sert les pages de Bugzilla comme prévu.
Vous avez deux options pour exécuter Bugzilla sur Apache : mod_cgi (par défaut) et mod_perl (nouveau à partir de Bugzilla 2.23)
Pour configurer votre serveur Web Apache pour fonctionner avec Bugzilla en utilisant mod_cgi, suivez les instructions suivantes :
<Directory /var/www/html/bugzilla>
AddHandler cgi-script .cgi
Options +ExecCGI
DirectoryIndex index.cgi index.html
AllowOverride Limit FileInfo Indexes Options
</Directory>
Ces instructions : autorisent Apache à exécuter les fichiers .cgi se trouvant dans le répertoire bugzilla; indiquent au serveur de chercher un fichier appelé index.cgi, ou s'il n'est pas trouvé, index.html, si quelqu'un saisit seulement le nom du répertoire dans le navigateur ; et autorisent les fichiers .htaccess de Bugzilla à outrepasser quelques permissions globales.
Note
Il est possible de faire ces changements globalement ou sur la directive contrôlant le répertoire parent de Bugzilla (par ex. <Directory /var/www/html/>). De tels changements s'appliquent aussi au répertoire de Bugzilla directory… mais ils s'appliqueraient aussi à plein d'autres endroits où cela pourrait ne pas être approprié. Dans la plupart des cas, y compris celui-ci, il est mieux d'être aussi restrictif que possible lors de l'affectation de droits d'accès supplémentaires.
Note
Sous Windows, vous pourriez aussi avoir à ajouter la ligne ScriptInterpreterSource Registry-Strict, voir les notes spécifiques pour Windows.
+FollowSymLinks
Sans cette directive, Apache ne suivra pas les liens symboliques aux emplacements extérieurs à sa propre structure de répertoires et vous ne pourrez pas exécuter Bugzilla.
Une certaine configuration est requise pour faire fonctionner Bugzilla avec Apache et mod_perl
Ouvrez httpd.conf dans votre éditeur. sous Fedora et Red Hat Linux, ce fichier se trouve dans /etc/httpd/conf.
Ajoutez les informations suivantes à votre fichier httpd.conf, en substituant où cela est approprié vos propres chemins d'accès locaux.
Note
Ceci doit être utilisé au lieu du bloc <Directory> indiqué plus haut. Ceci doit aussi être placé au-dessus de toute autre directive mod_perl dans le fichier httpd.conf et doit être spécifié dans l'ordre indiqué ci-dessous.
Attention
Vous devez aussi vous assurer que vous avez désactivé la gestion de KeepAlive dans votre installation Apache en utilisant Bugzilla avec mod_perl
PerlSwitches -w -T
PerlConfigRequire /var/www/html/bugzilla/mod_perl.pl
Au redémarrage d'Apache, Bugzilla devrait alors fonctionner en environnement mod_perl. Veuillez vous assurer d'avoir exécuté checksetup.pl pour définir les permissions avant de redémarrer Apache.
Note
Veuillez garder à l'esprit les points suivants quand vous cherchez à utiliser Bugzilla avec mod_perl :
Si vous voulez exécuter Bugzilla sur Windows et choisir d'utiliser Microsoft Internet Information Services ou Personal Web Server vous aurez besoin de réaliser d'autres étapes de configuration comme expliqué ci-dessous. Vous pouvez aussi vous référez aux articles de la base de connaissance de Microsoft : 245225 HOW TO: Configure and Test a PERL Script with IIS 4.0, 5.0, and 5.1 (pour Internet Information Services) et 231998 HOW TO: FP2000: How to Use Perl with Microsoft Personal Web Server on Windows 95/98 (pour Personal Web Server).
Vous devrez créer un répertoire virtuel pour l'installation de Bugzilla. Mettez les fichiers Bugzilla dans un répertoire appelé autrement que le nom que vous voulez que vos utilisateurs voient. C'est-à-dire, si vous voulez que vos utilisateurs accèdent à votre installation Bugzilla par http://<votre_nom_de_domaine>/Bugzilla, alors ne mettez pas vos fichiers Bugzilla dans un répertoire nommé Bugzilla. Au lieu de cela, placez les dans un emplacement différent et utilisez l'outil d'administration de IIS pour créer un répertoire virtuel nommé Bugzilla qui se comporte comme un alias pour l'emplacement réel des fichiers. Lors de la création du répertoire virtuel, assurez-vous d'ajouter les permissions Exécuter les scripts.
Vous devrez aussi indiquer à IIS comment Bugzilla doit manipuler les fichiers .cgi. Utilisez à nouveau l'outil d'administration de IIS, ouvrez les propriétés du nouveau répertoire virtuel et sélectionnez l'option Configuration pour accéder à l'association de fichiers. Créez une entrée .cgi ainsi :
<chemin d'accès complet à perl.exe>\perl.exe -x<chemin d'accès complet à Bugzilla> -wT "%s" %s
Par exemple :
c:\perl\bin\perl.exe -xc:\bugzilla -wT "%s" %s
Note
L'installation de ActiveState a peut-être déjà créé une entrée pour les fichiers .pl qui est limitée à GET,HEAD,POST. Si c'est le cas, cette association doit être retirée car les fichiers .pl de Bugzilla ne sont pas conçus pour être exécutés par un serveur Web.
IIS devra aussi savoir que le fichier index.cgi doit être traité comme le document par défaut. Dans l'onglet Documents dans la page de propriétés du répertoire virtuel, vous devez ajouter index.cgi comme type de document par défaut. si vous le souhaitez, vous pouvez retirer les autres types de document pour ce répertoire virtuel particulier, puisque Bugzilla ne les utilise pas.
Et aussi, nous ne le dirons jamais assez, assurez-vous que les fichiers tels que localconfig et votre répertoire data sont sécurisés comme indiqué dans Désactiver l'accès à distance aux fichiers de configuration.
Votre installation de Bugzilla devrait à présent fonctionner. Accédez à la page http://<votre-serveur-bugzilla>/ - vous devriez voir la page d'accueil de Bugzilla. Si ce n'est pas le cas, consultez la section Dépannage, Dépannage.
Note
L'URL ci-dessus peut être incorrecte si vous avez installé Bugzilla dans un sous-répertoire ou utilisé un lien symbolique depuis la racine de votre site Web vers le répertoire de Bugzilla.
Connectez-vous avec le compte administrateur que vous avez défini lors du dernier lancement de checksetup.pl. Rendez-vous sur la page des paramètres et regardez s'il y a des paramètres que vous souhaitez changer. Les paramètres clés sont documentés dans Configuration de Bugzilla; vous devriez certainement modifier les paramètres maintainer et urlbase; vous pourriez aussi vouloir modifier les paramètres cookiepath ou requirelogin.
Bugzilla comporte plusieurs fonctionnalités optionnelles qui nécessitent une configuration supplémentaire. Vous pouvez lire cela dans Configuration optionnelle supplémentaire.
Bugzilla a beaucoup de fonctionnalités optionnelles. Cette section décrit comment les configurer ou les activer.
Si vous avez installé les modules Perl nécessaires, vous pouvez commencer à collecter les statistiques pour les graphiques de Bugzilla.
# crontab -e
Ceci devrait ouvrir le fichier crontab dans votre éditeur. Ajoutez une entrée cron comme celle-ci pour exécuter collectstats.pl quotidiennement à minuit cinq :
5 0 * * * cd <votre-repertoire-bugzilla> && ./collectstats.pl
Après deux jours, vous pourrez consulter des graphiques de bogues à partir de la page Rapports.
Note
Windows ne dispose pas de l'outil cron, mais il dispose des Tâches programmées, qui accomplit les mêmes travaux. Il existe également des outils tiers qui peuvent être utilisés pour mettre en œuvre cron, tel que nncron.
À quoi servent les bogues s'ils ne sont pas ennuyeux ? Pour qu'ils le soient plus, vous pouvez paramétrer le système de notifications automatique de Bugzilla pour rappeler aux ingénieurs leurs bogues qui sont dans l'état CONFIRMÉ et qu'ils n'ont pas triés.
Ceci peut être réalisé en ajoutant la commande suivante dans le fichier crontab, de la même manière que pour les graphiques de bogue, expliqué ci-dessus. Cet exemple s'exécute quotidiennement à 12:55.
55 0 * * * cd <votre-repertoire-bugzilla> && ./whineatnews.pl
Note
Windows ne dispose pas de l'outil cron, mais il dispose des Tâches programmées, qui accomplit les mêmes travaux. Il existe également des outils tiers qui peuvent être utilisés pour mettre en œuvre cron, tel que nncron.
À partir de Bugzilla 2.20, les utilisateurs peuvent configurer Bugzilla pour qu'il vienne les ennuyer à intervalles réguliers en faisant exécuter à Bugzilla des recherches enregistrées à certains moments et envoyer les résultats par courriels à l'utilisateur. Ceci s'appelle les Notifications. La manière de les configurer est décrite dans Notifications, et pour que cela fonctionne, un script Perl doit être exécuté à intervalles réguliers.
Ceci peut être réalisé en ajoutant la commande suivante dans le fichier crontab, de la même manière que pour les graphiques de bogue, expliqué ci-dessus. Cet exemple s'exécute quotidiennement toutes les 15 minutes.
*/15 * * * * cd <votre-repertoire-bugzilla> && ./whine.pl
Note
Les notifications peuvent être exécutées toutes els 15 minutes, aussi, si vous spécifiez des intervalles plus longs pour l'exécution de whine.pl, certains utilisateurs peuvent ne pas être notifiés aussi souvent qu'ils le souhaiteraient. Selon les personnes, cela peut être une bonne chose ou une mauvaise chose.
Note
Windows ne dispose pas de l'outil cron, mais il dispose des Tâches programmées, qui accomplit les mêmes travaux. Il existe également des outils tiers qui peuvent être utilisés pour mettre en œuvre cron, tel que nncron.
Certaines pages de Bugzilla ont des formats alternatifs, autre que le HTML intégral. En particulier, quelques pages de Bugzilla peuvent offrir leur contenu soit en XUL (un format spécial de Mozilla, qui ressemble à un programme GUI) ou RDF (un type de XML structuré qui peut être lu par divers programmes).
Pour que vos utilisateurs voient ces pages correctement, Apache doit leur envoyer le bon type MIME. Pour faire cela, ajouter les lignes suivantes à votre fichier de configuration Apache, soit dans la section <VirtualHost> de votre Bugzilla soit dans la section <Directory> de votre Bugzilla :
AddType application/vnd.mozilla.xul+xml .xul
AddType application/rdf+xml .rdf
Les instructions précédentes se référaient à une installation standard, avec une seule base de données Bugzilla. Cependant, vous pourriez vouloir héberger plusieurs installations distinctes, sans avoir plusieurs copies du code. Ceci est possible en utilisant la variable d'environnement PROJECT. Quand il est accédé, Bugzilla vérifie l'existence de cette variable, et si elle est présente, utilise sa valeur pour vérifier la présence d'un fichier de configuration alternatif appelé localconfig.<PROJECT> au même emplacement que celui par défaut (localconfig). Il vérifie aussi la présence de modèles personnalisés dans le répertoire nommé <PROJECT> au même emplacement que celui par défaut (template/<langcode>). Par défaut, c'est le répertoire template/en/default donc les modèles de PROJECT se trouveraient dans template/en/PROJECT.
Pour définir une installation alternative, exporter la variable PROJECT=toto avant de lancer checksetup.pl pour la première fois. Il en résultera un fichier nommé localconfig.toto au lieu de localconfig. Modifiez ce fichier comme décrit plus haut, avec la référence à une nouvelle base de données, et relancez checksetup.pl pour la populer. C'est tout.
Maintenant, vous devez paramétrer le serveur Web pour lui passer cette variable d'environnement quand il est accédé via une URL alternative, comme un hôte virtuel par exemple. Ce qui suit est un exemple de ce que vous pouvez faire avec Apache, cela peut différer pour les autres serveurs Web.
<VirtualHost 212.85.153.228:80>
ServerName toto.titi.tata
SetEnv PROJECT toto
Alias /bugzilla /var/www/bugzilla
</VirtualHost>
N'oubliez pas aussi d'exporter cette variable avant d'accéder à Bugzilla par d'autres voies, comme les tâches programmées de cron par exemple.
Plusieurs aspects de l'installation de Bugzilla peuvent être affectés par le système d'exploitation que vous avez choisi. C'est parfois plus facile et d'autres fois plus difficile. Cette section tentera de vous aider à commprendre les difficultés de fonctionnement sur des systèmes d'exploitation spécifiques et les utilitaires disponibles pour que ce soit plus facile.
Si vous avez quelque chose à ajouter ou des notes pour un système d'exploitation non couvert par cette documentation, veuillez rapporter un bogue sur http://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla;component=Documentation.
Faire fonctionner Bugzilla sur Windows est plus difficile que sur Unix. Pour cette raison, nous vous recommandons encore de le faire sur un systèmecompatible Unix tel que GNU/Linux. Ceci dit, si vous voulez vraiment faire fonctionner Bugzilla sur Windows, vous devrez faire les ajustements suivants. Un guide d'installation pour Windows étape par étape est également disponible si vous avez besoin de plus d'aide pour votre installation.
Perl pour Windows peut être obtenu sur ActiveState. Vous devriez pouvoir trouver un binaire compilé sur http://aspn.activestate.com/ASPN/Downloads/ActivePerl/. Les intructions suivantes supposent que vous utilisez une version 5.10.1 de ActiveState.
Note
Ces instructions sont pour des versions 32-bits de Windows. Si vous utilisez une version 64-bits de Windows, vous aurez besoin d'installer Perl 32-bits pour installer les modules 32-bit comme décrit ci-dessous.
Bugzilla sur Windows nécessite les mêmes modules Perl que sur Modules Perl. La différence principale est que Windows utilise PPM au lieu de CPAN. ActiveState fournit une interface graphique pour gérer les modules Perl. Nous vous recommandons fortement de l'utiliser. Si vous préférez utiliser ppm en ligne de commande, saisissez :
C:\perl> ppm install <nom_du_module>
Si vous utilisez Perl 5.10.1, la meilleure source pour les modules PPM Windows nécessaires pour Bugzilla est probablement le site Web theory58S, que vous pouvez ajouter à votre liste de dépôts comme suit :
ppm repo add theory58S http://cpan.uwinnipeg.ca/PPMPackages/10xx/
Si vous utiliser Perl 5.12 ou plus récent, vous n'avez plus besoin d'ajouter ce dépôt. Tous les modules dont vous avez besoin sont déjà disponibles dans le dépôt ActiveState.
Note
Le référentiel PPM stocke les modules en paquets qui peuvent avoir un nom légèrement différent de celui du module. Si vous récupérez les modules d'ici, vous devrez prêter attention aux informations fournies lorsque vous exécutez checksetup.pl car il vous dira quel paquet vous aurez besoin d'installer.
Note
Si vous êtes derrière un pare-feu, vous devrez indiquer à l'utilitaire ActiveState PPM comment le passer pour accéder aux référentiels en définissant la variable d'environnement HTTP_proxy. Pour plus d'informations sur la définition de cette variable, consultez la documentation de ActiveState.
Comme c'est le cas pour les systèmes compatibles Unix, tout serveur Web doit être capable de faire fonctionner Bugzilla ; cependant, l'équipe de Bugzilla recommande l'utilisation d'Apache quand on lui demande. Peu importe le serveur Web que vous avez choisi, assurez-vous de lire les recommandations de sécurité dans Désactiver l'accès à distance aux fichiers de configuration. Vous pourrez trouver des informations sur la configurations de serveurs Web spécifiques dans Le serveur Web.
Note
Le serveur Web cherche /usr/bin/perl pour invoquer Perl. Si vous utilisez Apache sur Windows, vous pouvez définir la directive ScriptInterpreterSource pour qu'Apache regarde au bon endroit. Insérez la ligne
dans votre fichier httpd.conf et créez la clé de registre
avec la valeur C:\\Perl\\bin\\perl.exe -T (adaptez le chemin si nécessaire). Quand ceci est fait, redémarrez Apache.
Pour permettre à Bugzilla d'envoyer des courriels sur Windows, le serveur sur lequel s'exécute le code de Bugzilla doit pouvoir se connecter à un serveur SMTP ou être un serveur SMTP lui-même.
Faire fonctionner Bugzilla sur Mac OS X nécessite les ajustements suivants.
Sur Mac OS X 10.3 et supérieur, Postfix est utilisé en tant que serveur de courriels intégré. Postfix fournit un exécutable qui imite suffisamment sendmail pour tromper Bugzilla, tant que Bugzilla peut le trouver. Bugzilla est capable de trouver le faux exécutable sendmail sans assistance.
Apple ne fournit pas la bibliothèque GD avec Mac OS X. Bugzilla en a besoin pour les graphiques de bogues.
Vous pouvez utiliser MacPorts (http://www.macports.org/) ou Fink (http://sourceforge.net/projects/fink/), qui sont de nature semblable à l'installeur CPAN, mais installent les utilitaires GNU courants.
Suivez les instructions pour paramétrer MacPorts ou Fink. Une fois installée, vous voudrez utiliser une de ces applications pour installer le paquet gd2.
Fink vous demandera d'installer un certain nombre de dépendances, saisissez y et appuyez sur la touche Entrée pour installer toutes les dépendances puis vérifiez que cela fonctionne. vous serez alors en mesure d'utiliser CPAN pour installer le module Perl GD.
Note
Pour empêcher la création de conflits avec les logiciels installés par défaut par Apple, Fink crée sa propre arborescence de répertoires dans /sw où il installe la plupart des logiciels qu'il installe. Ceci signifie que les bibliothèques et en-têtes se trouveront dans /sw/lib et /sw/include au lieu de /usr/lib et /usr/include. Quand le script du module de configuration Perl demande où se trouve votre fichier libgd, assurez-vous d'indiquer /sw/lib.
expat est aussi disponible via MacPorts ou Fink. Après avoir installé le paquet expat, vous pourrez installer le module XML::Parser en utilisant CPAN. Si vous utilisez Fink, il faut faire attention. Contrairement aux versions récentes du module GD, XML::Parser ne demande pas l'emplacement des bibliothèques requises. Lors de l'utilisation de CPAN, vous devrez utiliser la séquence de commandes suivante :
# perl -MCPAN -e'look XML::Parser'
# perl Makefile.PL EXPATLIBPATH=/sw/lib EXPATINCPATH=/sw/include
# make; make test; make install
# exit
La commande look téléchargera le module et engendrera un nouveau shell avec les fichiers extraits dans le répertoire courant. La commande exit vous renverra dans le shell d'origine.
Vous devrez surveiller la sortie de ces commandes make, et particulièrement make test car des erreurs peuvent empêcher XML::Parser de fonctionner correctement avec Bugzilla.
Beaucoup de distributions GNU Linux/BSD incluent Bugzilla et ses dépendances dans leur système de gestion de paquets natif. Installer Bugzilla avec un accès root sur tout système GNU Linux/BSD devrait être aussi facile que de trouver le paquet Bugzilla dans l'application de gestion de paquet et de l'installer en utilisant la syntaxe de commande normale. Plusieurs distributions réalisent automatiquement la configuration correcte du serveur Web lors de l'installation.
Veuillez consulter la documentation de votre distribution GNU Linux/BSD pour des instructions sur la façon d'installer les paquets, ou pour des instructions spécifiques pour installer Bugzilla avec les outils de gestion de paquets natifs. Il existe également la page wiki de Bugzilla pour des notes d'installation spécifiques à certaines distributions.
Si vous utilisez un système d'exploitation *NIX en n'étant pas root, soit par manque d'accès (serveurs Web, par exemple) soit pour raisons de sécurité, ceci détaillera comment installer Bugzilla sur ce type de configuration. Il est recommandé de lire la partie Installation d'abord pour avoir une idée des étapes d'installation nécessaires. (Ces notes se référeront aux étapes de ce guide.)
Vous avez peut-être MySQL installé en tant que root. Si vous définissez un compte avec un hôte Web, un compte MySQL doit être créé pour vous. De là, vous pouvez créer le compte bugs ou utiliser le compte qui vous a été donné.
Attention
Vous pouvez avoir des problèmes en définissant des permissions GRANT dans la base de données. Si vous utilisez un hôte Web, il y a des chances que vous ayez une base de données séparée qui est déjà verrouillée (ou une grosse base de données sans accès ou avec des accès limités sur d'autres zones), mais vous pouvez demander à votre administrateur système les paramètres de sécurité définis et/ou lui demander d'exécuter la commande GRANT pour vous. Vous pourriez aussi ne pas être en mesure de changer le mot de passe de l'utilisateur root de MySQL (pour des raisons évidentes), aussi, sautez cette étape.
Créez un fichier .my.cnf dans votre répertoire home (/home/foo dans cet exemple) comme suit…
[mysqld]
datadir=/home/toto/mymysql
socket=/home/toto/mymysql/thesock
port=8081
[mysql]
socket=/home/toto/mymysql/thesock
port=8081
[mysql.server]
user=mysql
basedir=/var/lib
[safe_mysqld]
err-log=/home/toto/mymysql/the.log
pid-file=/home/toto/mymysql/the.pid
Vous pouvez installer MySQL zn n'étant pas root, si vous en avez vraiment besoin. créez-le avec la variable PREFIX définié à /home/toto/mysql, ou utilisez des exécutables pré-installés en spécifiant que vous voulez mettre tous les fichiers de données dans /home/toto/mysql/data. S'il y a un autre serveur MySQL qui s'exécute sur le système qui ne vous appartient pas, utilisez l'option -P pour spécifier un port TCP qui n'est pas utilisé.
Après avoir créé votre programme mysqld et votre fichier .my.cnf, vous devez initialiser les bases de données (UNE FOIS).
$ mysql_install_db
Puis démarrez le démon avec
$ safe_mysql &
après avoir lancé mysqld la première fois, connectez vous en tant que root et donnez les permissions (GRANT) aux autres utilisateurs. (Le compte root de MySQL n'a rien à voir avec le compte root des systèmes *NIX).
Note
Vous devrez démarrer les démons vous-mêmes. Vous pouvez soit demander à votre administrateur système de les ajouter aux fichiers de démarrage du système, soit ajouter une entrée dans le fichier crontab qui exécute un script vérifiant que ces démons sont lancés et les redémarre si nécessaire.
Attention
Ne lancez pas de démons ou autres services sur un serveur sans avoir d'abord consulter votre administrateur système ! Les démons utilisent des ressources système et en exécuter peut être en violation des conditions de service pour toute machine sur laquelle vous êtes utilisateur !
Dans le cas très rare où vous n'auriez pas Perl sur la machine, vous devrez construire les sources vous mêmes. Les commandes suivantes devraient installer sur votre système votre propre version de Perl :
$ wget http://perl.org/CPAN/src/stable.tar.gz
$ tar zvxf stable.tar.gz
$ cd perl-5.8.1 (ou la version de Perl que vous avez)
$ sh Configure -de -Dprefix=/home/toto/perl
$ make && make test && make install
Dès que vous avez installé Perl dans un répertoire (probablement dans ~/perl/bin), vous devrez installer les modules Perl comme détaillé plus bas dans cette page.
Installer les modules Perl sans être utilisateur root est réalisé en exécutant le script install-module.pl. Pour plus de détails sur ce script, consultez la documentation de :file:`install-module.pl <api/install-module.html>`_.
Idéalement, ceci nécessite aussi d'être installé avec l'utilisateur root et s'exécuter sous un compte spécial pour le serveur Web. Tant que le serveur autorise l'exécution des fichiers *.cgi en dehors de cgi-bin et refuser l'accès à certains fichiers (comme le fichier .htaccess), ça devrait aller.
Vous pouvez exécuter Apache sans être root, mais le port devra être supérieur à 1024. Si vous saisissez la commande httpd -V, vous obtiendrez une liste des variables que votre copie système de httpd utilise. Une de celles-ci, HTTPD_ROOT, vous indique où cette installation va rechercher ses informations de configuration.
De là, vous pouvez copier les fichiers de configuration vers votre répertoire home pour les modifier. Quand vous éditez ceux-ci et que vous utilisez l'option -d pour outrepasser la valeur de la variable HTTPD_ROOT compilée dans votre serveur Web, vous prenez le contrôle de votre propre serveur Web personnalisé.
Note
Vous devrez démarrer les démons vous-mêmes. Vous pouvez soit demander à votre administrateur système de les ajouter aux fichiers de démarrage du système, soit ajouter une entrée dans le fichier crontab qui exécute un script vérifiant que ces démons sont lancés et les redémarre si nécessaire.
Attention
Ne lancez pas de démons ou autres services sur un serveur sans avoir d'abord consulter votre administrateur système ! Les démons utilisent des ressources système et en exécuter peut être en violation des conditions de service pour toute machine sur laquelle vous êtes utilisateur !
Quand vous exécutez ./checksetup.pl pour créer le fichier localconfig, il listera les modules Perl qu'il trouve. S'il en manque, revenez en arrière et revérifier l'installation du module depuis Modules Perl, puis supprimez le fichier localconfig et essayez à nouveau.
Attention
L'option dans le fichier localconfig avec laquelle vous pourriez avoir des problèmes est le groupe du serveur Web. Si vous ne pouvez pas afficher la page index.cgi (une erreur d'accès refusé par exemple), vous aurez sans doute à relâcher vos permissions et à vider le groupe du serveur Web. Bien sûr, ceci peut poser des problèmes de sécurité. Avoir un shell correctement emprisonné et/ou un accès limité aux comptes du shell peut diminuer les risques de sécurité, mais utilisez ceci à vos risques et périls.
Si vous êtes sur un système qui utilise suexec (la plupart des environnements d'hébergement le font), vous aurez besoin de définir la valeur de webservergroup dans le fichier localconfig pour qu'elle corresponde à votre groupe principal, plutôt que celui avec lequel le serveur Web est exécuté. Vous devrez lancer les commandes suivantes après avoir exécuté ./checksetup.pl, chaque fois que vous le lancez (ou modifiez checksetup.pl pour qu'il le fasse pour vous grâce à la commande system()).
for i in docs graphs images js skins; do find $i -type d -exec chmod o+rx {} \\; ; done
for i in jpg gif css js png html rdf xul; do find . -name \\*.$i -exec chmod o+r {} \\; ; done
find . -name .htaccess -exec chmod o+r {} \\;
chmod o+x . data data/webdot
Faites particulièrement attention au nombre de point-virgules et de points. Ils sont tous importants. Une prochaine version de Bugzilla sera, avec un peu de chance, capable de faire ceci pour vous automatiquement.
Mettre à jour vers une nouvelle version de Bugzilla est très facile. Il y a un script checksetup.pl inclus dans Bugzilla qui fera automatiquement toute la migration de la base de données pour vous.
Les sections suivantes expliquent comment mettre à jour d'une version Bugzilla à une autre. Que vous mettiez à jour d'une version corrective à une autre (comme par exemple de 4.2 à 4.2.1) ou d'une version majeure à une autre (comme par exemple de 4.0 à 4.2), les instructions sont toujours les mêmes.
Note
Les exemples des sections suivantes sont écrits pour un utilisateur faisant une mise à jour à partir d'une version 4.2.1, mais les procédures sont les mêmes quelle que soit la version. Également, dans les exemples, l'installation Bugzilla de l'utilisateur se trouve dans /var/www/html/bugzilla. Si ce n'est pas le même emplacement que pour votre installation, substituez simplement les chemins d'installation quand c'est approprié.
Avant de démarrer la mise à jour, il y a quelques étapes importantes à réaliser :
Lisez les Notes de version de la version vers laquelle vous allez mettre à jour, particulièrement la section Comment migrer à partir d'une version précédente.
Consultez la page de Contrôle d'intégrité (Vérifier et maintenir l'intégrité de la base de données) de votre installation avant de mettre à jour. Essayez de corriger tous les avertissements produits sur cette page avant d'aller plus loin ou vous pourriez avoir des problèmes pendant la mise à jour.
Arrêter votre installation Bugzilla en ajoutant du texte ou du code HTML dans le paramètre shutdownhtml (voir Configuration de Bugzilla).
Faites une sauvegarde de votre base de données Bugzilla. CECI EST TRÈS IMPORTANT. Si quelque chose se passe mal pendant la mise à jour, votre installation peut être corrompue et irrécupérable. Avoir une sauvegarde est une sécurité.
Attention
La mise à jour ne fonctionne que dans un sens. Vous ne pouvez pas descendre d'une version de Bugzilla. Si vous voulez revenir à l'ancienne version de Bugzilla pour quelque raison que ce soit, vous devrez restaurer votre base de données à partir de cette sauvegarde.
Voici quelques exemples de commandes que vous pourriez utiliser pour sauvegarder votre base de données, en fonction du système de gestion de base de données que vous utilisez. Vous pourriez avoir à modifier ces commandes en fonction de vos paramètres d'installation.
mysqldump --opt -u bugs -p bugs > bugs.sql
pg_dump --no-privileges --no-owner -h localhost -U bugs > bugs.sql
Il existe trois moyens d'obtenir la nouvelle version de Bugzilla. Nous allons les lister brièvement ici, puis nous les expliquerons plus en détail ensuite.
si vous avez modifié le code ou les templates de votre installation Bugzilla, alors la mise à jour nécessite un peu plus d'effort et de réflexion. Une discussion sur les diverses méthodes de mise à jour en fonction du degré et des méthodes de personnalisation locaux se trouve dans Choisir une méthode de personnalisation.
Plus l'écart de version est important, plus il sera difficile de mettre à jour si vous avez fait des personnalisations locales. Une mise à jour d'une version 4.2. vers une version 4.2.1 devrait se faire sans peine, même si vous avez fortement personnalisé votre installation. Mais passer d'une version 2.18 à une version 4.2 un gros travail de ré-écriture de vos changements locaux pour utiliser les nouveaux fichiers, logique, templates, etc. Si vous n'avez pas fait de changement locaux du tout cependant, alors la mise à jour devrait représenter approximativement la même quantité de travail, quelle que soit la version que vous utilisez actuellement.
Ceci nécessite que bzr soit installé (c'est le cas pour la plupart des machines Unix), et aussi que vous puissiez accéder à bzr.mozilla.org, ce qui peut ne pas être une option si vous n'avez pas d'accès à Internet.
Ci-dessous, la séquence des commandes nécessaires pour mettre à jour une installation Bugzilla par Bzr, et les résultats typiques obtenus. En supposant que Bugzilla a déjà éé installé en utilisant Bzr.
Attention
Si votre installation utilise encore CVS, vous devez d'abord la convertir vers Bzr. Une documentation très détaillée est disponible sur wiki.mozilla.org.
$ cd /var/www/html/bugzilla
$ bzr switch 4.2 (n'utilisez cette commande que si vous n'utilisez pas déjà la version 4.2)
$ bzr up -r tag:bugzilla-4.2.1
+N extensions/MoreBugUrl/
+N extensions/MoreBugUrl/Config.pm
+N extensions/MoreBugUrl/Extension.pm
…
M Bugzilla/Attachment.pm
M Bugzilla/Attachment/PatchReader.pm
M Bugzilla/Bug.pm
…
All changes applied successfully.
Attention
Si une ligne de résultat de bzr update mentionne un conflit, cela représente alors un fichier avec des changements locaux que Bzr n'est pas capable de fusionner correctement. Vous devez résoudre manuellement ces conflits avant que Bugzilla (ou tout au moins la portion utilisant ce fichier) ne soit utilisable.
Si vous ne pouvez (ou ne voulez) pas utiliser Bzr, une autre option est toujours disponible pour obtenir la dernière archive à partir de la Page de téléchargements pour créer une nouvelle installation de Bugzilla à partir de celle-ci.
Cette séquence de commandes montre comment obtenir l'archive en ligne de commande ; il est aussi possible de la télécharger à partir du site directement dans le navigateur. Si vous procédez ainsi, enregistrez le fichier dans le répertoire /var/www/html (ou son équivalent, si vous utilisez autre chose) et passez les trois premières lignes de l'exemple.
$ cd /var/www/html
$ wget http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-4.2.1.tar.gz
…
$ tar xzvf bugzilla-4.2.1.tar.gz
bugzilla-4.2.1/
bugzilla-4.2.1/colchange.cgi
…
$ cd bugzilla-4.2.1
$ cp ../bugzilla/localconfig* .
$ cp -r ../bugzilla/data .
$ cd ..
$ mv bugzilla bugzilla.old
$ mv bugzilla-4.2.1 bugzilla
Attention
Les commandes cp se terminent toutes deux avec un point (.), ce qui est un détail important (cela signifie que le répertoire de destination est le répertoire de travail courant).
Attention
Si vous avez des extensions installées, vous devrez aussi les copier dans le nouveau répertoire bugzilla. Les extensions sont situées dans bugzilla/extensions/. Ne copiez que celles que vous avez installées, pas celles gérées par l'équipe de Bugzilla.
Cette méthode de mise à jour vous donnera une installation propre de Bugzilla. Ce qui est très bien si vous n'avez pas de personnalisations locales que vous voulez maintenir. Si vous avez des personnalisations, vous devrez alors les réappliquer manuellement dans les fichiers appropriés.
Un correctif est un ensemble de corrections de bogues qui ont été faites depuis la version mineure précédente.
Si vous faites une mise à jour par correctif (c'est-à-dire, où seule le dernier numéro de révsion change, comme par exemple de 4.2 à 4.2.1), alors vous pouvez obtenir et appliquer le fichier correctif à partir de la Page de téléchargements.
Comme précédemment, cet exemple commence par l'obtention du fichier en ligne de commande. Si vous l'avez déjà téléchargé, vous pouvez passer les deux premières commandes.
$ cd /var/www/html/bugzilla
$ wget http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-4.2-to-4.2.1.diff.gz
…
$ gunzip bugzilla-4.2-to-4.2.1.diff.gz
$ patch -p1 < bugzilla-4.2-to-4.2.1.diff
patching file Bugzilla/Constants.pm
patching file enter_bug.cgi
…
Attention
Soyez conscient que la mise à jour à partir d'un fichier correctif ne change pas les entrées dans votre répertoire .bzr. Ceci pourrait rendre plus difficile une mise à jour en utilisant Bzr (Mettre à jour en utilisant Bzr) dans le futur.
Maintenant que vous avez le nouveau code de Bugzilla, il reste quelques étapes à accomplir pour terminer votre mise à jour.
Si votre nouvelle installation Bugzilla est dans un répertoire différent ou sur une machine différente de celle de votre ancienne installation Bugzilla, assurez-vous d'avoir copié le répertoire data et le fichier localconfig de votre ancienne installation Bugzilla. (Si vous avez suivi les instructions d'installation via l'archive ci-dessus, c'est déjà fait).
S'il s'agit d'une mise à jour majeure, vérifiez que la configuration (Configuration) pour votre nouvelle installation de Bugzilla est à jour. Quelquefois, les prérequis de configuration changent entre une version majeure et une autre.
Si vous ne l'avez pas fait dans l'étape de configuration ci-dessus, vous devez maintenant exécuter checksetup.pl, qui fera tout ce qui est nécessaire pour convertir votre base de données existante et les paramètres pour la nouvelle version :
$ cd /var/www/html/bugzilla $ ./checksetup.pl
Attention
Le point (.) au début de la commande ./checksetup.pl est important et ne peut pas être omis.
Attention
S'il s'agit d'une mise à jour majeure (disons de 3.6 à 4.2 ou similaire), l'exécution de checksetup.pl sur une grosse installation (75 000 bogues ou plus) peut prendre un long moment, parfois plusieurs heures.
Effacez tout texte ou code HTML saisi dans le paramètre shutdownhtml pour ré-activer Bugzilla.
Consultez la page (Vérifier et maintenir l'intégrité de la base de données) Contrôle d'intégrité dans votre installation de Bugzilla mise à jour. Il est recommandé, dans la mesure du possible, de corriger immédiatement tout problème que vous voyez. Ne pas le faire peut signifier que Bugzilla ne fonctionnera pas correctement. Veuillez noter que si la page de contrôle d'intégrité contient plus d'erreurs après une mise à jour, cela ne veut pas nécessairement dire qu'il y a plus d'erreurs dans votre base de données qu'auparavant, car des tests additionnels sont ajoutés au contrôle d'intégrité avec le temps et il est possible que ces erreurs nétaient pas vérifiées dans la version précédente.
Bugzilla 3.0 a introduit la possibilité de notifier automatiquement les administrateurs lorsque de nouvelles versions sont disponibles, en fonction du paramètre upgrade_notification, voir Configuration de Bugzilla. Les administrateurs verront ces notifications en accédant à la page index.cgi, c-à-d. généralement lors de la connexion. Bugzilla vérifie une fois par jour la présence de nouvelles versions, à moins que le paramètre soit défini à désactivé. Si vous êtes placé derrière un proxy, vous pourriez avoir à définir le paramètre proxy_url de façon appropriée. Si le proxy nécessite une authentification, utilisez la synatxe http://utilisateur:mot_de_passe@url_proxy/.