[Bugzilla-fr-cvs] docs/xml troubleshooting.xml

[Emmanuel S. <se...@us...>]

Update of /cvsroot/bugzilla-fr/docs/xml
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv32345

Modified Files:
      Tag: BUGZILLA-2_18-BRANCH
	troubleshooting.xml 
Log Message:
traduction de troubleshooting.xml

Index: troubleshooting.xml
===================================================================
RCS file: /cvsroot/bugzilla-fr/docs/xml/troubleshooting.xml,v
retrieving revision 1.1.1.1
retrieving revision 1.1.1.1.2.1
diff -C2 -d -r1.1.1.1 -r1.1.1.1.2.1
*** troubleshooting.xml	22 Jul 2005 21:08:42 -0000	1.1.1.1
--- troubleshooting.xml	27 Jul 2005 22:48:47 -0000	1.1.1.1.2.1
***************
*** 3,40 ****
  
  <appendix id="troubleshooting">
! <title>Troubleshooting</title>
  
!   <para>This section gives solutions to common Bugzilla installation
!   problems. If none of the section headings seems to match your
!   problem, read the general advice.
    </para>
      
    <section id="general-advice">
!   <title>General Advice</title>
!     <para>If you can't get <filename>checksetup.pl</filename> to run to 
!     completion, it normally explains what's wrong and how to fix it.
!     If you can't work it out, or if it's being uncommunicative, post 
!     the errors in the 
!     <ulink url="news://news.mozilla.org/netscape.public.mozilla.webtools">netscape.public.mozilla.webtools</ulink>
!     newsgroup.
      </para>
  
!     <para>If you have made it all the way through
!     <xref linkend="installation"/> (Installation) and
!     <xref linkend="configuration"/> (Configuration) but accessing the Bugzilla
!     URL doesn't work, the first thing to do is to check your webserver error
!     log. For Apache, this is often located at
!     <filename>/etc/logs/httpd/error_log</filename>. The error messages
!     you see may be self-explanatory enough to enable you to diagnose and
!     fix the problem. If not, see below for some commonly-encountered 
!     errors. If that doesn't help, post the errors to the newsgroup.
      </para>
    </section>
          
    <section>
!   <title>The Apache webserver is not serving Bugzilla pages</title>
!     <para>After you have run <command>checksetup.pl</command> twice,
!     run <command>testserver.pl http://yoursite.yourdomain/yoururl</command>
!     to confirm that your webserver is configured properly for
      Bugzilla.
      </para>
--- 3,39 ----
  
  <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>
***************
*** 49,69 ****
  
    <section>
!   <title>I installed a Perl module, but 
!       <filename>checksetup.pl</filename> claims it's not installed!</title>
        
!     <para>This could be caused by one of two things:</para>
      <orderedlist>
        <listitem>
!         <para>You have two versions of Perl on your machine. You are installing
!         modules into one, and Bugzilla is using the other. Rerun the CPAN
!         commands (or manual compile) using the full path to Perl from the 
!         top of <filename>checksetup.pl</filename>. This will make sure you 
!         are installing the modules in the right place.
          </para>
        </listitem>
        <listitem>
! 	<para>The permissions on your library directories are set incorrectly.
! 	They must, at the very least, be readable by the webserver user or
! 	group. It is recommended that they be world readable.
          </para>
        </listitem>
--- 48,68 ----
  
    <section>
!   <title>J'ai installé un module Perl mais
!       <filename>checksetup.pl</filename> affirme qu'il n'est pas installé&#160;!</title>
        
!     <para>Cela peut avoir l'une des deux causes suivantes&#160;:</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>
***************
*** 72,88 ****
      
    <section>
!   <title>Bundle::Bugzilla makes me upgrade to Perl 5.6.1</title>
  
!     <para>Try executing <command>perl -MCPAN -e 'install CPAN'</command>
!     and then continuing.
      </para>
        
!     <para>Certain older versions of the CPAN toolset were somewhat naive about
!     how to upgrade Perl modules. When a couple of modules got rolled into the
!     core Perl distribution for 5.6.1, CPAN thought that the best way to get
!     those modules up to date was to haul down the Perl distribution itself and
!     build it. Needless to say, this has caused headaches for just about
!     everybody. Upgrading to a newer version of CPAN with the
!     commandline above should fix things.
      </para>
    </section>
--- 71,87 ----
      
    <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>
***************
*** 90,97 ****
  
    <section>
!   <title>DBD::Sponge::db prepare failed</title>
        
!     <para>The following error message may appear due to a bug in DBD::mysql
!     (over which the Bugzilla team have no control):
      </para>
        
--- 89,96 ----
  
    <section>
!   <title>"La préparation de DBD::Sponge::db a échoué" [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)&#160;:
      </para>
        
***************
*** 102,108 ****
  ]]></programlisting>
  
!     <para>To fix this, go to 
!     <filename>&lt;path-to-perl&gt;/lib/DBD/sponge.pm</filename> 
!     in your Perl installation and replace
      </para>
          
--- 101,107 ----
  ]]></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>
          
***************
*** 114,118 ****
  ]]></programlisting>
  
!     <para>with</para>
  
  <programlisting><![CDATA[ my $numFields;
--- 113,117 ----
  ]]></programlisting>
  
!     <para>par</para>
  
  <programlisting><![CDATA[ my $numFields;
***************
*** 123,154 ****
  ]]></programlisting>
  
!      <para>(note the S added to NAME.)</para>
    </section>
      
    <section id="paranoid-security">
!   <title>cannot chdir(/var/spool/mqueue)</title>
  
!     <para>If you are installing Bugzilla on SuSE Linux, or some other
!     distributions with <quote>paranoid</quote> security options, it is
!     possible that the checksetup.pl script may fail with the error: 
  <programlisting><![CDATA[cannot chdir(/var/spool/mqueue): Permission denied
  ]]></programlisting>
      </para>
        
!     <para>This is because your <filename>/var/spool/mqueue</filename>
!     directory has a mode of <computeroutput>drwx------</computeroutput>.
!     Type <command>chmod 755 <filename>/var/spool/mqueue</filename></command>
!     as root to fix this problem. This will allow any process running on your
!     machine the ability to <emphasis>read</emphasis> the
!     <filename>/var/spool/mqueue</filename> directory.
      </para>
    </section>    
  
    <section id="trouble-filetemp">
!   <title>Your vendor has not defined Fcntl macro O_NOINHERIT</title>
  
!     <para>This is caused by a bug in the version of
!     <productname>File::Temp</productname> that is distributed with perl
!     5.6.0. Many minor variations of this error have been reported:
      </para>
  
--- 122,153 ----
  ]]></programlisting>
  
!      <para>(notez le S ajouté à NAME.)</para>
    </section>
      
    <section id="paranoid-security">
!   <title>"Impossible d'exécuter chdir..." [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&#160;:
  <programlisting><![CDATA[cannot chdir(/var/spool/mqueue): Permission denied
  ]]></programlisting>
      </para>
        
!     <para>Cette erreur se produit parce que votre répertoire <filename>/var/spool/mqueue</filename>
!     a des droits insuffisants&#160;: <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>"Votre revendeur n'a pas défini ..." [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&#160;:
      </para>
  
***************
*** 162,169 ****
  at /usr/lib/perl5/site_perl/5.6.0/File/Temp.pm line 233.</programlisting>
  
!     <para>Numerous people have reported that upgrading to version 5.6.1
!     or higher solved the problem for them. A less involved fix is to apply
!     the following patch, which is also
!     available as a <ulink url="../xml/filetemp.patch">patch file</ulink>.
      </para>
  
--- 161,168 ----
  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="../xml/filetemp.patch">correctif</ulink>.
      </para>
  
***************
*** 189,291 ****
  
    <section id="trbl-relogin-everyone">
!   <title>Everybody is constantly being forced to relogin</title>
    
!   <para>The most-likely cause is that the <quote>cookiepath</quote> parameter
!   is not set correctly in the Bugzilla configuration.  You can change this (if
!   you're a Bugzilla administrator) from the editparams.cgi page via the web.
    </para>
  
!   <para>The value of the cookiepath parameter should be the actual directory
!   containing your Bugzilla installation, <emphasis>as seen by the end-user's
!   web browser</emphasis>. Leading and trailing slashes are mandatory. You can
!   also set the cookiepath to any directory which is a parent of the Bugzilla
!   directory (such as '/', the root directory). But you can't put something
!   that isn't at least a partial match or it won't work. What you're actually
!   doing is restricting the end-user's browser to sending the cookies back only
!   to that directory.
    </para>
  
!   <para>How do you know if you want your specific Bugzilla directory or the
!   whole site?
    </para>
  
!   <para>If you have only one Bugzilla running on the server, and you don't
!   mind having other applications on the same server with it being able to see
!   the cookies (you might be doing this on purpose if you have other things on
!   your site that share authentication with Bugzilla), then you'll want to have
!   the cookiepath set to "/", or to a sufficiently-high enough directory that
!   all of the involved apps can see the cookies.
    </para>
  
    <example id="trbl-relogin-everyone-share">
!   <title>Examples of urlbase/cookiepath pairs for sharing login cookies</title>
  
      <blockquote>
        <literallayout>
!         urlbase is <ulink url="http://bugzilla.mozilla.org/"/>
!         cookiepath is /
  
!         urlbase is <ulink url="http://tools.mysite.tld/bugzilla/"/>
!                 but you have http://tools.mysite.tld/someotherapp/ which shares
!                 authentication with your Bugzilla
!         cookiepath is /
        </literallayout>
      </blockquote>
    </example>
            
!    <para>On the other hand, if you have more than one Bugzilla running on the
!    server (some people do - we do on landfill) then you need to have the
!    cookiepath restricted enough so that the different Bugzillas don't
!    confuse their cookies with one another.
     </para>
  
  
     <example id="trbl-relogin-everyone-restrict">
!    <title>Examples of urlbase/cookiepath pairs to restrict the login cookie</title>
        <blockquote>
          <literallayout>
!         urlbase is <ulink url="http://landfill.bugzilla.org/bugzilla-tip/"/>
!         cookiepath is /bugzilla-tip/
  
!         urlbase is <ulink url="http://landfill.bugzilla.org/bugzilla-2.16-branch/"/>
!         cookiepath is /bugzilla-2.16-branch/
          </literallayout>
        </blockquote>
      </example>
  
!     <para>If you had cookiepath set to <quote>/</quote> at any point in the
!     past and need to set it to something more restrictive
!     (i.e. <quote>/bugzilla/</quote>), you can safely do this without
!     requiring users to delete their Bugzilla-related cookies in their
!     browser (this is true starting with 
!     Bugzilla 2.18 and Bugzilla 2.16.5).
      </para>
    </section>
  
    <section>
!   <title>Some users are constantly being forced to relogin</title>
  
!     <para>First, make sure cookies are enabled in the user's browser.
      </para>
  
!     <para>If that doesn't fix the problem, it may be that the user's ISP
!      implements a rotating proxy server. This causes the user's effective IP
!      address (the address which the Bugzilla server perceives him coming from)
!      to change periodically. Since Bugzilla cookies are tied to a specific IP
!      address, each time the effective address changes, the user will have to
!      log in again.
       </para>
  
!      <para>If you are using 2.18, there is a
!      parameter called <quote>loginnetmask</quote>, which you can use to set
!      the number of bits of the user's IP address to require to be matched when
!      authenticating the cookies. If you set this to something less than 32,
!      then the user will be given a checkbox for <quote>Restrict this login to
!      my IP address</quote> on the login screen, which defaults to checked. If
!      they leave the box checked, Bugzilla will behave the same as it did
!      before, requiring an exact match on their IP address to remain logged in.
!      If they uncheck the box, then only the left side of their IP address (up
!      to the number of bits you specified in the parameter) has to match to
!      remain logged in.
       </para>
  
--- 188,289 ----
  
    <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 '/', 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&#160;?
    </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 à "/", 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&#160;: <ulink url="http://bugzilla.mozilla.org/"/>
!         cookiepath&#160;: /
  
!         urlbase&#160;: <ulink url="http://tools.mysite.tld/bugzilla/"/>
!                 mais vous avez http://tools.mysite.tld/someotherapp/ partageant
!                 l'autentification avec Bugzilla
!         cookiepath&#160;: /
        </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&#160;: <ulink url="http://landfill.bugzilla.org/bugzilla-tip/"/>
!         cookiepath&#160;: /bugzilla-tip/
  
!         urlbase&#160;: <ulink url="http://landfill.bugzilla.org/bugzilla-2.16-branch/"/>
!         cookiepath&#160;: /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'utilsateur 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>
  
***************
*** 293,306 ****
  
    <section id="trbl-index">
!   <title><filename>index.cgi</filename> doesn't show up unless specified in the URL</title>
      <para>
!       You probably need to set up your web server in such a way that it
!       will serve the index.cgi page as an index page.
      </para>
      <para>
!       If you are using Apache, you can do this by adding 
!       <filename>index.cgi</filename> to the end of the 
!       <computeroutput>DirectoryIndex</computeroutput> line
!       as mentioned in <xref linkend="http-apache"/>.
      </para>
  
--- 291,304 ----
  
    <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>