Cette section donne les solutions aux problèmes d'installation courants de Bugzilla. Si aucun des titres ne semble correspondre à votre problème, veuillez lire la notice générale.
Si vous n'arrivez pas à exécuter checksetup.pl jusqu'à son terme, il explique généralement ce qui ne va pas et comment le corriger. Si vous ne vous en sortez pas ou si l'explication de correction n'est pas indiquée, veuillez poster les erreurs dans le forum mozilla.support.bugzilla.
Si vous avez effectué ce qui est indiqué dans Installation (Installation) et Configuration (Configuration) mais que l'accès à l'URL de Bugzilla ne fonctionne pas, la première chose à faire est de vérifier le journal des erreurs de votre serveur Web. Pour Apache, il se trouve souvent sur /etc/logs/httpd/error_log. Les messages d'erreur que vous voyez peuvent être suffisamment explicites pour vous permettre de diagnostiquer et corriger le problème. Si ce n'est pas le cas, veuillez consulter ci-dessous les erreurs communément rencontrées. Si cela ne vous aide pas, veuillez poster les erreurs dans le forum.
Bugzilla peut également journaliser les erreurs utilisateur (et beaucoup d'erreurs de code) qui surviennent sans polluer le journal des erreurs du serveur Web. Pour activer la journalisation des erreurs de Bugzilla, créez un fichier dans lequel Bugzilla peut écrire nommé errorlog, dans le répertoire data de Bugzilla. Les erreurs seront consignées au fur et à mesure en indiquant le type d'erreur, l'adresse IP et le nom d'utilisateur (si disponible) de l'utilisateur qui a déclenché l'erreur et les valeurs de toutes les variables d'environnement ; si un formulaire a été soumis, les données de celui-ci seront aussi incluses. Pour désactiver la journalisation d'erreur, supprimez ou renommez le fichier errorlog.
après avoir exécuté deux fois le script checksetup.pl, exécuter la commande testserver.pl http://votresite.votredomaine/votrerurl pour confirmer que votre serveur Web est configuré correctement pour Bugzilla.
$ ./testserver.pl http://landfill.bugzilla.org/bugzilla-tip
TEST-OK Webserver is running under group id in $webservergroup.
TEST-OK Got ant picture.
TEST-OK Webserver is executing CGIs.
TEST-OK Webserver is preventing fetch of http://landfill.bugzilla.org/bugzilla-tip/localconfig.
Cela peut être dû à l'une des deux causes suivantes :
Le message d'erreur suivant peut apparaître à cause d'un bogue de DBD::mysql (sur lequel l'équipe de Bugzilla n'a pas de contrôle) :
DBD::Sponge::db prepare failed: Cannot determine NUM_OF_FIELDS at D:/Perl/site/lib/DBD/mysql.pm line 248.
SV = NULL(0x0) at 0x20fc444
REFCNT = 1
FLAGS = (PADBUSY,PADMY)
Pour corriger cela, rendez-vous dans <chemin-vers-perl>/lib/DBD/sponge.pm dans votre installation de Perl et remplacez
my $numFields;
if ($attribs->{'NUM_OF_FIELDS'}) {
$numFields = $attribs->{'NUM_OF_FIELDS'};
} elsif ($attribs->{'NAME'}) {
$numFields = @{$attribs->{NAME}};
}
par
my $numFields;
if ($attribs->{'NUM_OF_FIELDS'}) {
$numFields = $attribs->{'NUM_OF_FIELDS'};
} elsif ($attribs->{'NAMES'}) {
$numFields = @{$attribs->{NAMES}};
}
(veuillez noter le S ajouté à NAME.)
Si vous avez installé Bugzilla sur une distribution SuSE Linux ou toute autre distribution avec les options de sécurité en mode paranoïaque, il est possible que le script checksetup.pl échoue avec l'erreur :
cannot chdir(/var/spool/mqueue): Permission denied
Ceci est provoqué par votre répertoire /var/spool/mqueue qui a les permissions drwx------. Saisissez la commande chmod 755 :file:/var/spool/mqueue`` en tant que root pour corriger ce problème. Ceci permettra à tout processus s'exécutant sur votre machine de lire le répertoire /var/spool/mqueue.
La cause la plus probable est que le paramètre cookiepath n'est pas défini correctement dans la configuration de Bugzilla. Vous pouvez changer ceci (si vous êtes un administrateur de Bugzilla) à partir de la page editparams.cgi dans votre navigateur Web.
La valeur du paramètre cookiepath doit être le répertoire actuel contenant votre installation de Bugzilla, comme le voit le navigateur Web du simple utilisateur. Les barres de fraction / ouvrante et fermante sont obligatoires. Vous pouvez définir cookiepath pour n'importe quel répertoire parent de Bugzilla (comme /, le répertoire racine). Mais vous ne pouvez pas indiquer un répertoire qui n'a pas au moins une correspondance partielle sans quoi cela ne fonctionnera pas. Vous êtes en fait en train d'empêcher le navigateur de l'utilisateur de renvoyer les cookies seulement vers ce répertoire.
Comment savoir si vous voulez votre répertoire Bugzilla spécifique ou tout le site ?
Si vous n'avez qu'une seule installation de Bugzilla sur le serveur et si ça vous est égal d'avoir d'autres applications sur le même serveur capables de voir les cookies (vous pourriez faire ceci volontairement si vous avez d'autres choses sur votre site qui partagent l'authentification avec Bugzilla), alors vous voudrez que cookiepath soit défini à /, ou un répertoire suffisamment haut pour que toutes les applications concernées puissent voir les cookies.
D'un autre côté, si vous avez plus d'une installation Bugzilla sur votre serveur (certains le font - nous le faisons pour landfill) vous devrez avoir le paramètre cookiepath suffisamment restreint pour que les différentes installations de Bugzilla ne confondent pas leurs cookies l'une et l'autre.
Si vous aviez cookiepath défini à / auparavant et que vous voulez le définir pour quelque chose de plus restrictif (par ex. /bugzilla/), vous pouvez faire cela en toute sécurité sans demander à vos utilisateurs de supprimer leurs cookies relatifs à Bugzilla dans leur navigateur (ceci est vrai dès Bugzilla 2.18 et Bugzilla 2.16.5).
Vous devrez vraisemblablement paramétrer votre serveur Web de sorte qu'il serve la page comme une page d'index.
Si vous utilisez Apache, vous pouvez faire cela en ajoutant index.cgi à la fin de la ligne DirectoryIndex comme c'est indiqué dans Bugzilla utilisant Apache.
Cette erreur survient car vous utilisez le nouveau chiffrement de mot de passe fourni avec MySQL 4.1 alors que votre module DBD::mysql a été compilé pour une version antérieure de MySQL. Si vous recompilez DBD::mysql avec les bibliothèques actuelles de MySQL (ou si vous obtenez un nouvelle version de ce module) alors l'erreur peut disparaître.
Si cela ne corrige pas votre problème ou si vous ne pouvez pas recompiler le module existant (par ex. si vous utilisez Windows) et/ou que vous ne voulez pas le remplacer (par ex. vous voulez conserver une version empaquetée), alors, un moyen de contournement est disponible sur la documentation de MySQL : http://dev.mysql.com/doc/mysql/en/Old_client.html