<?xml version="1.0" encoding="UTF-8"?>
<!-- <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"> -->
<!-- $Id: troubleshooting.xml,v 1.1.1.1.2.2 2005/11/02 22:09:23 seyman Exp $ -->
<appendix id="troubleshooting">
<title>Résolution des problèmes</title>
<para>
Cette section propose des solutions aux problèmes d'installation de
Bugzilla. Si aucune des têtes de chapitres ne semble correspondre à
votre problème, lisez les conseils généraux.
</para>
<section id="general-advice">
<title>Conseils généraux</title>
<para>Normalement, si <filename>checksetup.pl</filename> ne parvient pas à s'exécuter
complètement, il vous explique ce qui ne va pas et comment régler le problème.
Si vous n'arrivez pas à vous en sortir, ou si le logiciel fait preuve de mutisme, publiez
ces erreurs sur le <ulink url="news://news.mozilla.org/netscape.public.mozilla.webtools">site
de diffusion netscape.public.mozilla.webtools</ulink>
</para>
<para>Si vous avez franchi avec succès toutes les étapes de
<xref linkend="installation"/> (Installation) et
<xref linkend="configuration"/> (Configuration) mais que l'accès à l'URL de
Bugzilla ne fonctionne pas, la première chose à vérifier est le journal d'erreur de votre
serveur Web. Dans le cas d'Apache, il se situe souvent dans
<filename>/etc/logs/httpd/error_log</filename>. Les messages d'erreur que
vous y trouverez seront peut-être suffisamment explicites pour vous permettre de diagnostiquer et
corriger le problème. Si ce n'est pas le cas, regardez ce qui est dit ci-dessous sur certaines erreurs
fréquemment rencontrées. Si cela ne vous aide toujours pas, publiez ces erreurs sur le groupe de diffusion.
</para>
</section>
<section>
<title>Le serveur Web Apache ne m'ouvre pas les pages de Bugzilla</title>
<para>Après avoir lancé <command>checksetup.pl</command> deux fois,
lancez <command>testserver.pl http://votre_site.votredomaine/votre_url</command>
afin de confirmer que votre serveur Web est correctement configuré pour
Bugzilla.
</para>
<programlisting>
<prompt>bash$</prompt> ./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.
</programlisting>
</section>
<section>
<title>J'ai installé un module Perl mais
<filename>checksetup.pl</filename> affirme qu'il n'est pas installé !</title>
<para>Cela peut avoir l'une des deux causes suivantes :</para>
<orderedlist>
<listitem>
<para>Vous avez deux versions de Perl sur votre machine. Vous installez
les modules sous l'une, alors que Bugzilla en utilise une autre. Exécutez à nouveau
les commandes CPAN (ou recompilez manuellement) en donnant le chemin complet vers Perl depuis
le répertoire de <filename>checksetup.pl</filename>. Ainsi vous serez sûr que les
modules sont installés au bon endroit.
</para>
</listitem>
<listitem>
<para>Les permissions de répertoires des bibliothèques ne sont pas paramétrées correctement.
Ils doivent, à tout le moins, être lisibles par l'utilisateur ou
le groupe serveur Web. Il est conseillé qu'ils soient accessibles à tous.
</para>
</listitem>
</orderedlist>
</section>
<section>
<title>Bundle::Bugzilla met à niveau Perl à la version 5.6.1</title>
<para>Exécutez la commande <command>perl -MCPAN -e 'install CPAN'</command>
pour voir et continuez.
</para>
<para>Certaines versions plus anciennes des outils CPAN étaient un peu naïves quand
elles mettaient à jour des modules Perl. Quand des modules entraient dans la
distribution Perl 5.6.1, CPAN pensait que le meilleur moyen de les garder
à jour était de récupérer la distribution Perl elle-même et
de la reconstruire. Inutile de vous dire que cela a causé un mal de tête à presque
tout le monde. Une mise à niveau vers la nouvelle version de CPAN grâce à la
commande ci-dessus devrait régler le problème.
</para>
</section>
<section>
<title>
<quote>La préparation de DBD::Sponge::db a échoué</quote>
[DBD::Sponge::db prepare failed]
</title>
<para>
Le message suivant peut apparaître à cause d'un bogue dans
DBD::mysql (sur lequel l'équipe Bugzilla n'a aucun contrôle) :
</para>
<programlisting><![CDATA[ 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)
]]></programlisting>
<para>
Pour régler le problème, éditez le fichier
<filename><chemin-vers-perl>/lib/DBD/sponge.pm</filename> dans
votre répertoire d'installation de Perl et remplacez
</para>
<programlisting><![CDATA[ my $numFields;
if ($attribs->{'NUM_OF_FIELDS'}) {
$numFields = $attribs->{'NUM_OF_FIELDS'};
} elsif ($attribs->{'NAME'}) {
$numFields = @{$attribs->{NAME}};
]]></programlisting>
<para>par</para>
<programlisting><![CDATA[ my $numFields;
if ($attribs->{'NUM_OF_FIELDS'}) {
$numFields = $attribs->{'NUM_OF_FIELDS'};
} elsif ($attribs->{'NAMES'}) {
$numFields = @{$attribs->{NAMES}};
]]></programlisting>
<para>(notez le S ajouté à NAME.)</para>
</section>
<section id="paranoid-security">
<title>
<quote>Impossible d'exécuter chdir...</quote> [cannot
chdir(/var/spool/mqueue)]</title>
<para>
Si vous installez Bugzilla sur SuSE Linux ou sur une autre
distribution avec des options de sécurité
<quote>paranoïaques</quote>, le script checksetup.pl peut se bloquer
avec l'erreur suivante :
</para>
<programlisting><![CDATA[cannot chdir(/var/spool/mqueue): Permission denied
]]></programlisting>
<para>
Cette erreur se produit parce que votre répertoire
<filename>/var/spool/mqueue</filename> a des droits
insuffisants : <computeroutput>drwx------</computeroutput>.
Tapez <command>chmod 755
<filename>/var/spool/mqueue</filename></command> sous root pour
régler le problème. Cela permettra à n'importe quel processus
s'exécutant sur votre machine de <emphasis>lire</emphasis> le
répertoire <filename>/var/spool/mqueue</filename>.
</para>
</section>
<section id="trouble-filetemp">
<title>
<quote>Votre fournisseur n'a pas défini...</quote> [Your vendor has
not defined Fcntl macro O_NOINHERIT]
</title>
<para>
Cette erreur est provoquée par un bogue dans la version de
<productname>File::Temp</productname> distribuée avec Perl 5.6.0. De
nombreuses variantes légèrement différentes de cette erreur ont été
signalées :
</para>
<programlisting>
Your vendor has not defined Fcntl macro O_NOINHERIT, used
at /usr/lib/perl5/site_perl/5.6.0/File/Temp.pm line 208.
Your vendor has not defined Fcntl macro O_EXLOCK, used
at /usr/lib/perl5/site_perl/5.6.0/File/Temp.pm line 210.
Your vendor has not defined Fcntl macro O_TEMPORARY, used
at /usr/lib/perl5/site_perl/5.6.0/File/Temp.pm line 233.
</programlisting>
<para>
Beaucoup d'utilisateurs ont signalé qu'une mise à niveau vers la
version 5.6.1 et suivantes a réglé leur problème. Une solution moins
définitive consiste à appliquer le correctif suivant, également
disponible sous forme d'un <ulink
url="&chemin-des-outils;filetemp.patch">correctif</ulink>.
</para>
<programlisting><![CDATA[
--- File/Temp.pm.orig Thu Feb 6 16:26:00 2003
+++ File/Temp.pm Thu Feb 6 16:26:23 2003
@@ -205,6 +205,7 @@
# eg CGI::Carp
local $SIG{__DIE__} = sub {};
local $SIG{__WARN__} = sub {};
+ local *CORE::GLOBAL::die = sub {};
$bit = &$func();
1;
};
@@ -226,6 +227,7 @@
# eg CGI::Carp
local $SIG{__DIE__} = sub {};
local $SIG{__WARN__} = sub {};
+ local *CORE::GLOBAL::die = sub {};
$bit = &$func();
1;
};
]]></programlisting>
</section>
<section id="trbl-relogin-everyone">
<title>On est constamment obligés de se reconnecter</title>
<para>
La cause la plus probable est que le paramètre
<quote>cookiepath</quote> n'est pas correctement réglé dans la
configuration de Bugzilla. Ça peut s'arranger (si vous êtes
administrateur Bugzilla) sur la page editparams.cgi par le web.
</para>
<para>
La valeur du paramètre cookiepath doit être précisément le répertoire
contenant votre installation de Bugzilla, <emphasis>telle que la voit
le navigateur Internet d'un utilisateur</emphasis>. Les slash de début
et de fin sont obligatoires. Vous pouvez également paramétrer le
cookiepath vers n'importe quel répertoire parent du répertoire
Bugzilla (comme <quote>/</quote>, le répertoire racine). Mais vous ne
pouvez pas indiquer un chemin qui ne correspond pas au moins
partiellement, car cela ne marchera pas. Ce que l'on fait là, en fait,
c'est de limiter l'action du navigateur utilisateur au renvoi de
cookies uniquement dans ce répertoire.
</para>
<para>
Comment savoir si vous avez besoin de votre répertoire Bugzilla
particulier ou du site complet ?
</para>
<para>
Si vous n'avez qu'un seul Bugzilla installé sur votre serveur, que
cela ne vous dérange pas d'avoir d'autres applications sur le même
serveur et qu'il soit capable de voir les cookies (ça pourrait être
fait exprès si vous avez d'autres outils sur votre site qui partagent
l'authentification avec Bugzilla), vous n'aurez qu'a régler le
cookiepath à <quote>/</quote>, ou à un répertoire suffisamment élevé
dans l'arborescence afin que toutes les applications concernées
puissent voir les cookies.
</para>
<example id="trbl-relogin-everyone-share">
<title>Exemples de paires urlbase/cookiepath pour le partage des cookies d'ouverture de session</title>
<blockquote>
<literallayout>
urlbase : <ulink url="http://bugzilla.mozilla.org/"/>
cookiepath : /
urlbase : <ulink url="http://tools.mysite.tld/bugzilla/"/>
mais vous avez http://tools.mysite.tld/someotherapp/ partageant
l'authentification avec Bugzilla
cookiepath : /
</literallayout>
</blockquote>
</example>
<para>D'un autre côté, si vous avez plus d'une version de Bugzilla installée sur votre
serveur (quelques utilisateurs le font; nous le faisons pour landfill), il faut que le
cookiepath soit suffisamment restreint afin que les différents Bugzilla ne
confondent pas leurs cookies avec ceux d'un autre.
</para>
<example id="trbl-relogin-everyone-restrict">
<title>Exemples de paires urlbase/cookiepath pour la restriction du cookie d'ouverture de session</title>
<blockquote>
<literallayout>
urlbase : <ulink url="http://landfill.bugzilla.org/bugzilla-tip/"/>
cookiepath : /bugzilla-tip/
urlbase : <ulink url="http://landfill.bugzilla.org/bugzilla-2.16-branch/"/>
cookiepath : /bugzilla-2.16-branch/
</literallayout>
</blockquote>
</example>
<para>Si vous aviez paramétré votre cookiepath à <quote>/</quote> auparavant
et que vous devez le régler à un niveau plus restrictif
(c'est à dire <quote>/bugzilla/</quote>), vous pouvez effectuer cela de manière sûre sans
demander aux utilisateurs de supprimer dans leur navigateur Internet leurs cookies
relatifs à Bugzilla (ceci est vrai depuis
Bugzilla 2.18 et Bugzilla 2.16.5).
</para>
</section>
<section>
<title>Certains utilisateurs sont constamment obligés de se reconnecter</title>
<para>Tout d'abord, assurez vous que les cookies sont activés dans le navigateur de l'utilisateur.
</para>
<para>Si cela ne règle pas le problème, il se peut que le fournisseur d'accès Internet de
l'utilisateur implémente un serveur proxy tournant. Cela provoque un changement périodique
de l'adresse IP réelle de l'utilisateur (l'adresse d'où provient l'utilisateur du point de
vue du serveur Bugzilla). Puisque les cookies de Bugzilla sont liés à une adresse IP spécifique,
chaque fois que cette adresse réelle change, l'utilisateur devra se connecter à nouveau.
</para>
<para>Si vous utilisez la version 2.18, il y a un
paramètre appelé <quote>loginnetmask</quote> que vous pouvez utiliser afin de régler
le nombre de bits que nécessite l'adresse IP de l'utilisateur lors de l'authentification
des cookies. Si vous indiquez un nombre inférieur à 32, une case à cocher sera mise à
disposition de l'utilisateur sur l'écran de connexion pour <quote>Restreindre cet accès à
mon adresse IP</quote> [Restrict this login to my IP address], case cochée par défaut. Si
l'utilisateur laisse la case cochée, Bugzilla se comportera de la même manière
qu'auparavant, exigeant que l'adresse IP corresponde exactement afin de rester connecté.
Si l'utilisateur décoche la case, alors seule la partie gauche de son adresse IP (à hauteur
du nombre de bits que vous avez spécifié dans le paramètre) devra correspondre pour
rester connecté.
</para>
</section>
<section id="trbl-index">
<title><filename>index.cgi</filename> ne s'affiche pas à moins qu'il ne soit spécifié dans l'URL</title>
<para>
Il vous faut probablement paramétrer votre serveur Web de sorte qu'il
considère la page index.cgi comme une page d'index.
</para>
<para>
Si vous utilisez Apache, vous pouvez faire ceci en ajoutant
<filename>index.cgi</filename> à la fin de la ligne
<computeroutput>DirectoryIndex</computeroutput> comme
indiqué dans <xref linkend="http-apache"/>.
</para>
</section>
</appendix>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-always-quote-attributes:t
sgml-auto-insert-required-elements:t
sgml-balanced-tag-edit:t
sgml-exposed-tags:nil
sgml-general-insert-case:lower
sgml-indent-data:t
sgml-indent-step:2
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
sgml-minimize-attributes:nil
sgml-namecase-general:t
sgml-omittag:t
sgml-parent-document:("Bugzilla-Guide.xml" "book" "chapter")
sgml-shorttag:t
sgml-tag-region-if-active:t
End: -->
