Le livre de Bugzilla — version 2.18

Test de la version installée : perl -v

Toute machine qui ne possède pas Perl est une machine bien malheureuse. Si vous ne l'avez pas et que votre système d'exploitation ne fournit pas de paquetages officiels, allez sur http://www.perl.com. Bien que Bugzilla fonctionne avec Perl 5.6.0, c'est une bonne idée d'utiliser la dernière version stable. Au moment où ces lignes sont écrites, c'est Perl 5.8.3.

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 paquetages officiels, allez sur http://www.mysql.com. Vous avez besoin de MySQL version 3.23.41 ou supérieure.

Note

De nombreuses versions binaires de MySQL stockent leurs fichiers de données dans le répertoire /var. Sur certains systèmes UNIX, ce répertoire se trouve dans la partition principale (root). Si celle-ci est trop petite, il peut ne pas y avoir assez de place pour contenir la base de données des bogues. Pour changer le répertoire de données, vous devez compiler MySQL vous-même à partir des sources, et le mettre comme option à configure.

Si vous installez à partir d'autre chose qu'un packaging/installation du système, comme un .rpm (Paquetage Redhat), .deb (Paquetage Debian), .exe (Executable Windows) ou .msi (Installateur Microsoft), assurez vous que le serveur MySQL soit lancé au démarrage de la machine.

Test de la version installée : regardez la page de bienvenue par défaut à http://<votre-machine>/

Là, vous avez le choix, à peu près tous les serveurs web capables de faire fonctionner les scripts CGI conviennent. Cependant, nous recommandons fortement d'utiliser le serveur web Apache (soit 1.3.x ou 2.x), et les instructions d'installation supposent généralement que vous l'employez. Si vous avez Bugzilla qui fonctionne en utilisant un autre serveur web, n'hésitez pas à partager votre expérience avec nous en utilisant la procédure de soumission de bogues dans Bugzilla Documentation.

Si vous n'avez pas Apache et que votre système d'exploitation ne fournit pas de paquetage officiel, allez sur http://httpd.apache.org/.

Téléchargez une archive tar Bugzilla (ou jetez un œil sur CVS) et placez la dans un répertoire approprié, accessible par l'utilisateur du serveur web par défaut (probablement « apache » ou « www »). Le mieux est de la mettre soit directement dans l'espace web principal de votre ou peut être dans /usr/local avec un lien symbolique provenant de l'espace web.

	Attention
	La distribution Bugzilla par défaut n'est PAS conçue pour être placée dans un répertoire cgi-bin. Ceci est valable pour chaque répertoire configuré à l'aide de l'instruction du ScriptAlias d'Apache.

Une fois que tous les fichiers sont dans un répertoire accessible du web, faites en sorte que le répertoire soit accessible en écriture pour votre utilisateur du serveur web. Il s'agit là d une étape provisoire en attendant de lancer le script checksetup.pl, ce qui terminera votre installation.

Le processus d'installation de Bugzilla s'appuie sur un script nommé checksetup.pl. vérifie en premier lieu si vous avez les bonnes versions de tous les modules Perl obligatoires. Cette section a pour but de mener à bien cette vérification. Lorsque que c'est le cas, ne l'exécutez pas à nouveau, mais passez à Section 2, « Configuration ».

À ce stade, vous devez vous identifier comme administrateur (vous connecter en tant que root). Il vous faudra poursuivre la totalité de l'installation comme administrateur. Ensuite exécutez :

bash# ./checksetup.pl

checksetup.pl va imprimer une liste de modules de Perl obligatoires et optionnels, en même temps que les versions (si il y en a) installés sur votre machine. La liste des modules obligatoires est relativement longue; cependant, vous pouvez déjà en avoir plusieurs d'installés.

Il y a un méta-module nommé Bundle::Bugzilla, qui installe tous les autres modules avec une simple commande. Vous devriez l'utiliser si vous installez Perl 5.6.1 ou une version au dessus.

Le mode préféré pour installer des modules de Perl est via CPAN sur UNIX, ou PPM sur Windows (voir Section 4.1.2, « Perl Modules on Win32 »). Ces instructions supposent que vous utilisez CPAN ; si pour une raison ou une autre vous devez installer les modules de Perl manuellement, consultez Annexe D, Installation manuelle des modules Perl.

bash# perl -MCPAN -e 'install "<modulename>"'

Si vous utilisez Bundle::Bugzilla, invoquez la commande magique CPAN. Sinon, vous devez parcourir la liste des modules que checksetup.pl dit être obligatoires, dans l'ordre donné, en invoquant la commande pour chacun d'eux.

Astuce

Beaucoup d'utilisateurs se plaignent que les modules Perl ne s'installent pas chez eux. La plupart du temps, les messages d'erreur indiquent ne pas trouver un fichier dans « @INC ». À chaque fois ou presque, cette erreur se déclare soit parce que vous n'avez pas les droits suffisants pour compiler les modules Perl, soit parce que les bibliothèques de développement de Perl nécessaires ne sont pas installées sur votre système. Demandez à votre administrateur UNIX de vous accorder les droits d'accès suffisants. Si vous êtes l'administrateur UNIX, veuillez consulter le forum ou la liste de diffusion pour une aide plus poussée, ou faites appel à quelqu'un pour vous aider.

Voici une liste complète de modules et de leur version minimum. Quelques modules ont des notes d'installation spéciales; celles-ci sont indiquées juste après.

Modules Perl obligatoires :

1.5.3. GD (1.20)

Le module GD n'est nécessaire que si vous voulez des rapports graphiques.

	Note
	Le module Perl GD nécessite d'autres bibliothèques qui peuvent ou non être installées sur votre système, telles que libpng et libgd. La liste complète des bibliothèques nécessaires se trouve dans le fichier README du module Perl GD. Si la compilation de GD échoue, c'est probablement parce qu'il manque une des bibliothèques demandées.

	Astuce
	La version du module GD dont vous avez besoin est très étroitement liée à la version de libgd installée sur votre système. Si vous avez une version 1.x de libgd, les versions 2.x du module GD ne fonctionneront pas chez vous.

Bugzilla s'appuie sur la possibilité d'accès à un système de messagerie électronique pour son authentification utilisateur et pour d'autres tâches.

Sous Linux, tout MTA compatible avec Sendmail suffira. Sendmail, Postfix, qmail et Exim font partie des MTA courants. Sendmail est le MTA d'origine d'UNIX, mais les autres sont plus faciles à configurer, ce qui fait que beaucoup de personnes remplacent Sendmail par Postfix ou Exim. Le remplacement se fait sous forme d'échange standard, si bien que Bugzilla ne fera pas la différence entre eux.

Si vous utilisez Sendmail, la version 8.7 ou supérieure est nécessaire. Si vous utilisez un MTA compatible avec Sendmail, il doit être conforme au minimum à la version 8.7 de Sendmail.

Consultez les instructions d'installation détaillées dans le manuel correspondant au MTA que vous choisissez. Chacun de ces programmes aura son propre fichier de configuration où vous devrez configurer certains paramètres pour vous assurez que le message électronique est transmis correctement. Ils sont exécutés comme utilitaires, et vous devez vous assurer que le MTA est dans la liste de démarrage automatique des utilitaires de la machine.

Si un simple message électronique envoyé avec la ligne de commande mail fonctionne, alors Bugzilla devrait également être opérationnel.

Dès que vous exécutez checksetup.pl avec tous les bons modules installés, il affiche un message concernant un fichier nommé localconfig qu'il crée. Ce fichier contient les réglages par défaut pour un certain nombre de paramètres de Bugzilla.

Chargez ce fichier dans votre éditeur. La seule valeur que vous devez changer est $db_pass, mot de passe utilisateur que vous allez créer pour votre base de données. Tapez à cet endroit le mot de passe adéquate (pour simplifier, il ne devrait pas contenir le caractère « guillemet unique ») que vous avez choisi.

Les commentaires fournis dans le fichier localconfig donnent des informations sur les autres options. Si vous avez une installation de MySQL légèrement non standard, vous aurez la possibilité de changer un ou plusieurs des autres paramètres « $db_* ».

Si vous le souhaitez, vous pouvez changer le nom des priorités, les niveaux de gravité, les systèmes d'exploitation et les plates-formes pour votre installation. Cependant, vous pouvez toujours changer tout ça après que l'installation soit finie ; si vous re-exécutez checksetup.pl, les changements seront mis à jour.

Ensuite, réexécutez checksetup.pl. Il reconfirme que tous les modules sont présents et fait remarquer que le fichier localconfig a changé, qu'il considère comme ayant été édité à votre satisfaction. Il compile les modèles UI [User Interface templates], 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 il crée la base de données de « bugs » et les tables incluses.

Après cela, il demande des informations sur un compte administrateur. Bugzilla peut avoir plusieurs administrateurs — vous pouvez encore en créer d'autres plus tard — mais il en a besoin d'un pour commencer. Entrez l'adresse de courrier électronique d'un administrateur, son nom complet et un mot de passe Bugzilla approprié.

checksetup.pl a maintenant fini. Vous pouvez réexécuter checksetup.pl quand vous le souhaitez.

Configurez votre serveur web selon les instructions données dans la section appropriée. (Si cela peut influencer votre choix, l'équipe de Bugzilla recommande Apache.) Quel que soit le serveur web que vous utilisez, cependant, faites en sorte que les informations sensibles ne soient pas disponibles à distance en appliquant correctement les contrôles d'accès indiqués dans Section 3.1, « Désactivation des accès à distance pour les fichiers de configuration Bugzilla ».

  AddHandler cgi-script .cgi

Options +ExecCGI +FollowSymLinks
AllowOverride Limit

2.4.2. Internet Information Services™ de Microsoft

Si vous êtes en train d'exécuter Bugzilla sous Windows et que vous choisissez d'utiliser Internet Information Services™ ou Personal Web Server™ de Microsoft, vous devrez exécuter un certain nombre d'autres étapes de configuration comme expliqué ci-dessous. Vous aurez peut-être également besoin de consulter les articles suivants 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™) (N.D.T. : « HOW TO : configurez et testez un script PERL avec IIS 4.0, 5.0 et 5.1 ») et 231998 « HOW TO: FP2000: How to Use Perl with Microsoft Personal Web Server on Windows 95/98 » (pour Personal Web Server™) (N.D.T. : « HOW TO : FP2000 : Perl utilisation avec serveur Web personnel Microsoft sous Windows 95/98 »).

Vous aurez besoin de créer un répertoire virtuel pour l'installation de Bugzilla. Mettez les fichiers de Bugzilla dans un répertoire dont le nom est différent du répertoire que vous voulez rendre accessible à l'utilisateur final. C'est-à-dire, si vous voulez que vos utilisateurs accèdent à l'installation de Bugzilla par « http://<lenomdevotredomaine>/Bugzilla », ne mettez pas les fichiers de Bugzilla dans un répertoire appelé « Bugzilla ». Mettez les plutôt dans un endroit différent, puis utilisez l'outil d'administration de IIS pour créer un répertoire virtuel appelé « Bugzilla » qui joue le rôle d'alias pour l'emplacement réel des fichiers. En créant ce fichier virtuel, assurez vous que vous avez ajouté les droits d'accès « Execute (comme les applications ISAPI ou CGI) ».

Vous devrez aussi dire à IIS comment s'y prendre avec les fichiers .cgi de Bugzilla. Utilisez de nouveau l'outil d'administration de IIS, ouvrez les propriétés pour le nouveau répertoire virtuel et choisissez l'option de configuration pour accéder aux scripts d'applications [Script Mapping]. Créez une entrée d'application .cgi à l'adresse :

<chemin complet vers perl.exe >\perl.exe -x<chemin complet vers Bugzilla> -wT "%s" %s
        

Par exemple :

c:\perl\bin\perl.exe -xc:\bugzilla -wT "%s" %s
        

	Note
	L'installation d'ActiveState peut avoir déjà créé une entrée pour les fichiers .pl qui est limitée à « GET,HEAD,POST ». Si c'est le cas, cette application doit être supprimée car les fichiers .pl de Bugzilla ne sont pas conçus pour être exécutés via un serveur web.

IIS devra également savoir que l'index.cgi doit être traité comme un document par défaut. Sur la page onglets de Documents des propriétés du répertoire virtuel, vous devez ajouter index.cgi comme type de document par défaut. Si vous le voulez, vous pouvez effacer les autres types de document par défaut de ce répertoire virtuel particulier, puisque Bugzilla n'utilise aucun d'eux.

De plus, et on ne le soulignera jamais assez, assurez-vous que les fichiers tels que localconfig et votre répertoire data sont sécurisés comme décrit dans Section 3.1, « Désactivation des accès à distance pour les fichiers de configuration Bugzilla ».

2.4.3. Serveur AOL

Ben FrantzDale que l'utilisation du serveur AOL avec Bugzilla a donné d'excellents résultats. Il a fait part de son expérience et celle-ci nous permet de proposer ce qui suit.

Le serveur AOL devra être configuré pour pouvoir exécuter les scripts CGI, veuillez consulter la documentation qui va avec votre serveur pour plus d'information sur la façon de procéder.

Parce que les serveurs AOL ne supportent pas les fichiers .htaccess, vous devrez créer un script TCL. Vous devrez créer un aolserver/modules/tcl/filter.tcl (le nom du fichier sera sans importance) avec le contenu suivant (remplacez /bugzilla/ par le chemin web de votre instance Bugzilla) :

  ns_register_filter preauth GET /bugzilla/localconfig filter_deny
  ns_register_filter preauth GET /bugzilla/localconfig~ filter_deny
  ns_register_filter preauth GET /bugzilla/\#localconfig\# filter_deny
  ns_register_filter preauth GET /bugzilla/*.pl filter_deny
  ns_register_filter preauth GET /bugzilla/syncshadowdb filter_deny
  ns_register_filter preauth GET /bugzilla/runtests.sh filter_deny
  ns_register_filter preauth GET /bugzilla/data/* filter_deny
  ns_register_filter preauth GET /bugzilla/template/* filter_deny

  proc filter_deny { why } {
      ns_log Notice "filter_deny"
      return "filter_return"
  }
        

	Avertissement
	Ceci ne fonctionne probablement pas pour tous les fichiers de sauvegarde d'éditeur possibles alors vous aurez peut-être envie d'ajouter quelques variations supplémentaires de localconfig. Pour plus d'informations, voyez le bogue 186383 ou Bugtraq ID 6501.

	Note
	Si vous utilisez le logiciel webdot depuis research.att.com (la configuration par défaut pour le paramètre webdotbase), vous devrez autoriser l'accès à data/webdot/*.dot pour la machine reasearch.att.com. Si vous utilisez une installation locale de GraphViz, vous devrez autoriser tout le monde à accéder aux *.png, *.gif, *.jpg et *.map dans le répertoire data/webdot.

Votre Bugzilla devrait maintenant fonctionner. Allez sur http://<your-bugzilla-server>/ — vous devriez voir la page d'accueil de Bugzilla. Si ce n'est pas le cas, consultez la section Dépannage, Annexe B, Résolution des problèmes.

Identifiez vous avec le compte administrateur que vous avez défini lors de la dernière exécution de checksetup.pl. Vous devriez parcourir les options sur la page « Edit Parameters » (le lien est en bas de page) et voir s'il n'y en pas certaines que vous aimeriez changer. Les options importantes sont documentées dans Section 1, « Configuration de Bugzilla »; vous devrez certainement modifier maintainer et urlbase; vous pouvez aussi modifier cookiepath ou requirelogin.

Cela pourrait être l'occasion de refaire un tour sur le fichier localconfig et de vous assurer que les noms des priorités, degrés de gravité [severities], plate-formes et systèmes d'exploitation sont ceux que vous souhaitez utiliser quand vous commencez à créer un bug. N'oubliez pas de réexécuter checksetup.pl si vous changez ce dernier.

Bugzilla a plusieurs options facultatives qui nécessitent des configurations supplémentaires. Vous pouvez vous documenter à ce sujet dans Section 3, « Configuration supplémentaire facultative ».

Si vous avez installé les modules Perl nécessaires, vous pouvez commencer à collecter des statistiques pour les superbes graphes Bugzilla.

bash# crontab -e

Ceci devrait afficher le fichier crontab dans votre éditeur. Ajoutez une entrée « cron » comme ceci pour exécuter collectstats.pl tous les jours à minuit 5 :

5 0 * * * cd <your-bugzilla-directory> ; ./collectstats.pl

Deux jours après, vous pourrez visualiser les graphiques de bogues depuis la page de rapport de bogue.

	Note
	Windows n'a pas de 'cron', mais il a un planificateur de tâches, qui fournit les mêmes fonctions. Il y a également des outils conçus par des tiers qui peuvent être utilisés pour exécuter cron, tels que nncron.

Tout comme les arborescences de dépendance en mode texte, Bugzilla permet également des aperçus graphiques, en utilisant un logiciel appelé « dot ». C'est le paramètre webdotbase qui en assure précisément le fonctionnement ; il peut prendre l'une de ces trois valeurs :

La façon la plus simple de le faire fonctionner est d'installer GraphViz. Dans ce cas, vous devez activer les cartes d'image côté serveur dans Apache. Autrement, vous pouvez installer un serveur webdot ou utiliser le serveur public webdot AT&T. C'est le choix par défaut pour l'option webdotbase mais il est souvent surchargé et lent. Notez que le serveur de AT&T ne fonctionnera pas si Bugzilla n'est accessible que par HARTS. Note du rédacteur : Mais bon sang, qu'est ce que c'est que ce HARTS ? Google ne sait pas...

Les meilleurs bogues ne sont-ils pas aussi les plus énervants ? Pour vous aider à rendre ces bogues encore plus agaçants, vous pouvez activer le système automatique de plainte de Bugzilla pour vous plaindre des ingénieurs qui laissent leur bogues dans un état NEW ou REOPENED sans faire de triage.

Pour ce faire, ajoutez la commande suivante en tant qu'entrée crontab quotidienne, de la même manière que cela a été fait plus haut pour les diagrammes de bogue. Dans cet exemple, le planificateur s'active à minuit 55 :

55 0 * * * cd <your-bugzilla-directory> ; ./whineatnews.pl

	Note
	Windows n'a pas de 'cron', mais il a un planificateur de tâches, qui fournit les mêmes fonctions. Il y a également des outils conçus par des tiers qui peuvent être utilisés pour exécuter cron, tel que nncron.

Patch Viewer est le moteur qui permet l'affichage graphique des correctifs. Vous pouvez l'intégrer avec des copies des outils cvs, lxr et bonsai si vous les avez, en donnant l'emplacement de votre installation de ces outils dans editparams.cgi.

Patch Viewer pourra aussi éventuellement utiliser les utilitaires de ligne de commande cvs, diff et interdiff s'ils existent sur le système. On peut obtenir Interdiff sur http://cyberelk.net/tim/patchutils/. Si ces programmes ne sont pas dans le chemin du système, vous pouvez configurer leurs emplacements dans localconfig.

L'authentification LDAP est un module pour l'architecture d'authentification de plugin de Bugzilla.

Le schéma d'authentification traditionnel de Bugzilla utilise les adresses de courrier électronique comme identifiant utilisateur primaire et un mot de passe pour identifier l'utilisateur. Tous les endroits de Bugzilla qui traitent les utilisateurs (par exemple pour assigner un bogue) utilisent l'adresse de courrier électronique. L'authentification LDAP se place au dessus de ce schéma au lieu de le remplacer. L'utilisateur se connecte au début avec un nom d'utilisateur et un mot de passe pour l'annuaire LDAP. L'adresse de courrier électronique est récupérée depuis LDAP et l'utilisateur est identifié par le système traditionnel d'une façon cohérente en utilisant son adresse de courrier électronique. Si un compte pour cette adresse de courrier électronique existe déjà dans votre système Bugzilla, il s'y connectera. Si aucun compte pour cette adresse de courrier électronique n'existe, un compte est créé au cours de la connexion. (Dans ce cas, Bugzilla essaie d'utiliser les attributs « displayName » ou « cn » pour déterminer le nom complet de l'utilisateur). Après l'authentification, toutes les tâches liées à cet utilisateur sont gérées par l'adresse de courrier électronique et non par le nom d'utilisateur LDAP. Vous continuez d'assigner des bogues par adresse de courrier électronique, de rechercher des utilisateurs par adresse de courrier électronique, etc.

Attention

Du fait que le compte Bugzilla ne se crée qu'à la première connexion d'un utilisateur, un utilisateur qui ne s'est pas encore connecté est inconnu de Bugzilla. Ceci signifie qu'ils ne peuvent pas être utilisés comme propriétaire d'un bogue ou contact QA (que ce soit par défaut ou autrement), ajoutés à une liste cc, ou toute autre opération de ce genre. Une solution de rechange possible est le script bugzilla_ldapsync.rb dans le répertoire contrib. Une autre solution possible est de corriger le bogue 201069.

Paramètres requis pour utiliser l'authentification LDAP :

Certaines pages de Bugzilla ont des formats différents, autres que le HTML ordinaire. En particulier, quelques pages peuvent produire leur contenu soit en XUL (un format spécial de Bugzilla, qui ressemble à un programme GUI) soit en RDF (un genre d'XML structuré qui peut être lu par de nombreux programmes).

Pour que vos utilisateurs voient ces pages correctement, Apache doit les envoyer avec le type MIME adéquat. Pour ce faire, ajoutez les lignes suivantes à la configuration d'Apache, soit dans la section <VirtualHost> pour votre Bugzilla, soit dans la section <Directory> pour votre Bugzilla :

AddType application/vnd.mozilla.xul+xml .xul
AddType text/xml .rdf

Faire fonctionner Bugzilla sous Windows est plus difficile que de le faire fonctionner sous Unix. Pour cette raison, nous recommandons toujours de le faire sur un système basé sur Unix tel que GNU/Linux. Ceci dit, si vous voulez que Bugzilla fonctionne sous Windows, vous devrez faire les réglages suivants.

4.1.2. Perl Modules on Win32

Bugzilla sous Windows nécessite l'utilisation des mêmes modules Perl que ceux de Section 1.5, « Modules Perl ». La principale différence est que Windows utilise PPM au lieu de CPAN.

C:\perl> ppm install <module name>
        

La meilleure source pour les modules PPM de Windows nécessaires pour Bugzilla est probablement le serveur de test de Bugzilla (alias 'landfill') donc vous devriez ajouter l'ensemble des PPM de landfill comme suit :

ppm repository add landfill http://www.landfill.bugzilla.org/ppm/
        

	Note
	Sur landfill, les modules PPM sont regroupés en 'paquetages' qui peuvent avoir un nom légèrement différent de celui du module. Si vous récupérez ces modules à partir de là, vous devrez faire attention aux informations fournies lorsque vous exécutez checksetup.pl car il vous dira quel package vous devrez installer.

	Astuce
	Si vous êtes derrière un pare-feu d'entreprise, vous devrez informer l'utilitaire PPM ActiveState sur la façon de le contourner afin d'accéder aux fichiers contenant les PPM en configurant la variable d'environnement du système HTTP_proxy. Pour plus d'information sur la configuration de cette variable, voir la documentation de ActiveState.

open(SENDMAIL, "|/usr/lib/sendmail $sendmailparam -t -i") ||
  die "Can't open sendmail";

print SENDMAIL trim($msg) . "\n";
close SENDMAIL;
        

use Net::SMTP;
my $smtp_server = 'smtp.mycompany.com';  # changez ceci

# Utiliser die en cas d'erreur pour que le mail aille dans les 'mails non envoyés' et
# puisse être envoyé de la page sanitycheck.
my $smtp = Net::SMTP->new($smtp_server) ||
  die 'Cannot connect to server \'$smtp_server\'';

$smtp->mail('bugzilla-daemon@mycompany.com');  # changez ceci
$smtp->to($person);
$smtp->data();
$smtp->datasend($msg);
$smtp->dataend();
$smtp->quit;
        

4.1.4.  Traitement des pages Web

Comme c'est le cas sur les systèmes basés sur Unix, tous les serveurs web devraient supporter Bugzilla ; toutefois, si on lui demande son avis, l'équipe de Bugzilla recommande toujours Apache. Peu importe quel serveur web vous choisissez, surtout faites attention aux notes de sécurité de Section 3.1, « Désactivation des accès à distance pour les fichiers de configuration Bugzilla ». On trouvera plus d'informations sur la configuration de serveurs web particuliers dans la section Section 2.4, « Web server ».

	Note
	Si vous utilisez Apache sous Windows, vous pouvez mettre les instructions ScriptInterpreterSource dans votre configuration d'Apache pour éviter d'avoir à modifier la première ligne de chaque script afin qu'il contienne votre chemin vers perl au lieu de /usr/bin/perl.

Apple n'a pas inclus la bibliothèque GD dans MacOS X. Bugzilla en a besoin pour les graphes de bogues.

Vous pouvez l'installer en utilisant un programme appelé Fink, qui est proche de l'installeur CPAN mais il installe les utilitaires GNU courants. Fink est disponible à l'adresse http://sourceforge.net/projects/fink/.

Suivez les instructions pour configurer Fink. Une fois qu'il est installé, vous devez l'utiliser pour installer le paquetage gd2.

Fink va alors vous demander s'il doit résoudre un certain nombre de dépendances. Saisissez « y » et appuyez sur la touche Entrée pour installer toutes les dépendances et surveillez alors que tout se passe bien. Vous pourrez alors utiliser CPAN pour installer le module Perl GD.

Note

Pour ne pas entrer en conflit avec les logiciels installés par défaut par Apple, Fink crée sa propre arborescence dans /sw et y place la plupart des logiciels qu'il installe. Cela signifie que vos bibliothèques et vos entêtes seront dans /sw/lib et /sw/include au lieu de /usr/lib et /usr/include. Quand le script de configuration du module Perl vous demande où est votre libgd, dites lui bien /sw/lib.

Expat est également disponible via Fink. Après avoir utilisé fink pour installer le paquetage expat, vous pourrez installer XML::Parser en utilisant CPAN. Il y a une restriction. À la différence des versions récentes du module GD, XML::Parser n'invite pas à indiquer l'emplacement des bibliothèques nécessaires. Quand vous utilisez CPAN, vous devrez utiliser l'enchaînement des commandes suivant :

# 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 créera un nouveau shell avec les fichiers extraits comme répertoire de travail courant. La commande exit vous renverra à votre shell d'origine.
	Il vous faudra surveiller le résultat de ces commandes make, surtout « make test » dont les erreurs peuvent empêcher XML::Parser de fonctionner correctement avec Bugzilla.

Linux-Mandrake 8.0 comporte toutes les bibliothèques obligatoires et facultatives pour Bugzilla. La manière la plus simple de les installer consiste à utiliser l'utilitaire urpmi. Si vous suivez ces commandes, vous devriez avoir tout ce qu'il vous faut pour Bugzilla et ./checksetup.pl ne devrait pas se plaindre de bibliothèques manquantes. Il se peut que vous ayez certaines de ces bibliothèques déjà installées.

bash# urpmi perl-mysql
bash# urpmi perl-chart
bash# urpmi perl-gd
bash# urpmi perl-MailTools             
bash# urpmi apache-modules
      

pour l'intégration de la messagerie Bugzilla

Si vous exécutez un *NIX OS avec un compte limité (non administrateur), soit en raison d'un manque d'accès (les hôtes web, par exemple) ou pour des raisons de sécurité, cette partie vous indiquera comment installer Bugzilla sur une telle installation. Il est recommandé que vous lisiez d'abord la Section 1, « Installation » pour avoir une idée des étapes d'installation nécessaires (ces notes renverront à des étapes de ce guide).

Il se peut que MySQL soit installé en tant qu'administrateur. Si vous êtes en train d'installer un compte avec un hôte web, un compte MySQL devra être créé pour vous. À partir de là, vous pouvez créer le compte bugs ou utiliser le compte qui vous est fourni.

Avertissement

Vous pourriez avoir des problèmes en essayant de régler les permissions GRANT à la base de données. Si vous utilisez un hôte web, il y a de grandes 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 aux autres zones) mais vous pouvez demander à votre administrateur système comment les réglages de sécurité ont été fixés, et/ou qu'il exécute la commande GRANT pour vous. En plus, vous ne pourrez sans doute pas changer le mot de passe administrateur de MySQL (pour des raisons évidentes) alors sautez cette étape.