3.3. Windows

Faire fonctionner Bugzilla sous Windows est plus difficile que sous GNU/Linux. Cependant, peu de développeurs utilisent Windows pour tester Bugzilla et nous vous recommandons donc d’utiliser GNU/Linux pour des installations conséquentes pour avoir un meilleur support.

3.3.1. Perl

Vous avez deux possibilités principales pour installer Perl sur Windows : ActivePerl et Strawberry Perl.

L’installeur ActivePerl pour Windows peut être téléchargé sur le site Web de ActiveState.

Perl sera installé par défaut dans le répertoire C:\Perl. Il n’est pas recommandé d’installer Perl dans un répertoire dont le nom contient une espace, tel que C:\Program Files. Une fois l’installation terminée, fermez votre session Windows et reconnectez-vous pour que les changements dans la variable d’environnement PATH soient pris en compte.

L’installeur Strawberry Perl pour Windows peut être téléchargé sur le site de Strawberry Perl. Perl sera installé par défaut dans C:\Strawberry.

Un des gros avantages de Strawberry Perl par rapport à ActivePerl, c’est qu’avec Strawberry Perl, vous pouvez utiliser les outils habituels disponibles dans d’autres systèmes d’exploitation pour installer des modules Perl manquants directement à partir de CPAN, alors que ActivePerl nécessite d’utiliser son propre outil ppm pour télécharger les modules Perl pré-compilés d’ActiveState. Les modules du dépôt d’ActivePerl peuvent être un peu moins récents que ceux disponibles sur CPAN.

3.3.2. Bugzilla

Le meilleur moyen de récupérer Bugzilla est de l’obtenir avec Git. Téléchargez et installez Git à partir du site Web de Git, puis exécutez la commande suivante :

git clone --branch release-X.X-stable https://github.com/bugzilla/bugzilla C:\bugzilla

où X.X est le numéro de version à deux chiffres de la version stable que vous voulez installer (par ex. : 5.0).

La suite de cette documentation suppose que vous avez installé Bugzilla dans le répertoire C:\bugzilla. Ajustez les chemins d’accès en conséquence si ce n’est pas le cas.

S’il n’est pas possible d’utiliser Git (par ex. parce que votre machine n’a pas d’accès à Internet), vous pouvez télécharger une archive de Bugzilla et la recopier sur votre machine. Bugzilla est livré sous forme d’archive (extension .tar.gz), qui peut être décompressée par tout archiveur Windows reconnaissant ce format.

3.3.3. Modules Perl

Bugzilla nécessite de nombreux modules Perl. Certains sont obligatoires et d’autres, activant des fonctionnalités supplémentaires, sont optionnels.

Si vous utilisez ActiveState, ces modules sont disponibles dans le dépôt d’ActiveState et sont installés avec l’outil ppm. Vous pouvez l’utiliser en ligne de commande, comme ci-dessous, ou saisir la commande ppm pour obtenir l’interface graphique.

Si vous utilisez un proxy ou un pare-feu, vous pourriez rencontrer des difficultés pour utiliser PPM. Ceci est abordé dans la FAQ ActivePerl.

Installez les modules obligatoires suivants avec la commande :

ppm install <nom_du_module>

  • CGI.pm

  • Digest-SHA

  • TimeDate

  • DateTime

  • DateTime-TimeZone

  • DBI

  • Template-Toolkit

  • Email-Sender

  • Email-MIME

  • URI

  • List-MoreUtils

  • Math-Random-ISAAC

  • File-Slurp

  • JSON-XS

  • Win32

  • Win32-API

  • DateTime-TimeZone-Local-Win32

Les modules suivants activent diverses fonctionnalités optionnelles de Bugzilla :

  • GD

  • Chart

  • Template-GD

  • GDTextUtil

  • GDGraph

  • MIME-tools

  • libwww-perl

  • XML-Twig

  • PatchReader

  • perl-ldap

  • Authen-SASL

  • Net-SMTP-SSL

  • RadiusPerl

  • SOAP-Lite

  • XMLRPC-Lite

  • JSON-RPC

  • Test-Taint

  • HTML-Parser

  • HTML-Scrubber

  • Encode

  • Encode-Detect

  • Email-Reply

  • HTML-FormatText-WithLinks

  • TheSchwartz

  • Daemon-Generic

  • mod_perl

  • Apache-SizeLimit

  • File-MimeInfo

  • IO-stringy

  • Cache-Memcached

  • File-Copy-Recursive

Si vous utilisez Strawberry Perl, vous devez utiliser le script install-module.pl pour installer les modules, qui est le même que celui utilisé pour Linux. Certains des modules obligatoires sont déjà installés par défaut. Pour les modules restants, utilisez la commande suivante :

perl install-module.pl <modulename>

La liste des modules à installer sera affichée par le script checksetup.pl ; voir ci-dessous.

3.3.4. Serveur Web

Tout serveur Web capable d’exécuter des scripts CGI peut fonctionner. Nous avons des instructions spécifiques pour les suivants :

3.3.5. Moteurs de base de données

Bugzilla peut fonctionner avec MySQL, PostgreSQL, Oracle et SQLite. Un seul de ces moteurs de base de données est nécessaire pour utiliser Bugzilla. MySQL est le plus couramment utilisé et c’est le seul avec lequel les instructions pour Windows ont été testées. SQLite est pratique pour des installations de tests car il ne nécessite par de configuration. Configurez votre serveur selon les instructions ci-dessous :

3.3.6. localconfig

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 devrait pas contenir d’apostrophe) et saisissez-le dans le fichier. $db_driver peut être mysql, Pg (PostgreSQL), oracle ou SQLite.

Définissez la valeur de $webservergroup avec le nom groupe avec lequel votre serveur Web s’exécute.

  • Fedora/Red Hat : apache

  • Debian/Ubuntu : www-data

  • Mac OS X : _www

  • Windows : ignorez ce paramètre car il n’est pas utile pour ce système d’exploitation

Les autres options dans le fichier localconfig sont documentées avec leurs commentaires. Si vous avez une configuration de base de données non standard, vous aurez peut-être besoin de modifier d’autres paramètres $db_*.

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).

3.3.7. checksetup.pl

Ensuite, exécutez checksetup.pl une nouvelle fois :

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 d’autres 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 à tout moment si vous le souhaitez.

3.3.8. Bravo

Votre installation Bugzilla devrait à présent fonctionner. Vérifiez-le en exécutant la commande suivante :

testserver.pl http://<your-bugzilla-server>/

Si elle passe sans erreur, accédez à http://<your-bugzilla-server>/ dans votre navigateur –vous devriez alors voir la page d’accueil de Bugzilla. Bien sûr, si vous avez installé Bugzilla dans un sous-répertoire, assurez-vous que celui-ci figure dans URL.

Si vous ne voyez pas la page d’accueil de Bugzilla, mais « It works!!! », c’est qu’Apache n’a pas pris en compte vos modifications dans le fichier httpd.conf. Si vous êtes sous Windows 7 ou versions suivantes, cela peut être dû à une nouvelle fonctionnalité appelée « VirtualStore ». Ce billet de blog peut vous aider à résoudre ce problème.

Si vous obtenez un message « Internal Error… », c’est peut-être parce que ScriptInterpreterSource Registry-Strict n’est pas défini dans votre Configuration Apache. Vérifiez à nouveau si ce paramètre est correctement défini.

Ensuite, consultez Configuration post-installation essentielle.

Cette documentation contient très probablement des bogues ; si vous en découvrez, veuillez les signaler ici.