<?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é&nbsp;!</title>
      
    <para>Cela peut avoir l'une des deux causes suivantes&nbsp;:</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)&nbsp;:
    
    </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>&lt;chemin-vers-perl&gt;/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&nbsp;:
    </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&nbsp;: <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&nbsp;:
    
    </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&nbsp;?
   
  </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&nbsp;: <ulink url="http://bugzilla.mozilla.org/"/>
        cookiepath&nbsp;: /

        urlbase&nbsp;: <ulink url="http://tools.mysite.tld/bugzilla/"/>
                mais vous avez http://tools.mysite.tld/someotherapp/ partageant
                l'authentification avec Bugzilla
        cookiepath&nbsp;: /
      </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&nbsp;: <ulink url="http://landfill.bugzilla.org/bugzilla-tip/"/>
        cookiepath&nbsp;: /bugzilla-tip/

        urlbase&nbsp;: <ulink url="http://landfill.bugzilla.org/bugzilla-2.16-branch/"/>
        cookiepath&nbsp;: /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: -->