You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by gr...@apache.org on 2008/10/26 17:38:53 UTC
svn commit: r708014 [1/2] - in /httpd/httpd/trunk/docs/manual: dso.xml.fr
glossary.xml.fr logs.xml.fr new_features_2_4.xml.fr sections.xml.fr
server-wide.xml.fr suexec.xml.fr upgrading.xml.fr urlmapping.xml.fr
Author: gryzor
Date: Sun Oct 26 09:38:53 2008
New Revision: 708014
URL: http://svn.apache.org/viewvc?rev=708014&view=rev
Log:
Adding .fr translations for suexec logs server-wide sections new_features_2_4 urlmapping dso upgrading glossary
Added:
httpd/httpd/trunk/docs/manual/dso.xml.fr
httpd/httpd/trunk/docs/manual/glossary.xml.fr
httpd/httpd/trunk/docs/manual/logs.xml.fr
httpd/httpd/trunk/docs/manual/new_features_2_4.xml.fr
httpd/httpd/trunk/docs/manual/sections.xml.fr
httpd/httpd/trunk/docs/manual/server-wide.xml.fr
httpd/httpd/trunk/docs/manual/suexec.xml.fr
httpd/httpd/trunk/docs/manual/upgrading.xml.fr
httpd/httpd/trunk/docs/manual/urlmapping.xml.fr
Added: httpd/httpd/trunk/docs/manual/dso.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/dso.xml.fr?rev=708014&view=auto
==============================================================================
--- httpd/httpd/trunk/docs/manual/dso.xml.fr (added)
+++ httpd/httpd/trunk/docs/manual/dso.xml.fr Sun Oct 26 09:38:53 2008
@@ -0,0 +1,328 @@
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+<!-- English Revision : 587444 -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="dso.xml.meta">
+
+ <title>Support des objets dynamiques partagés (DSO)</title>
+
+ <summary>
+ <p>La conception modulaire du serveur HTTP Apache permet à l'administrateur
+ de choisir les fonctionnalités à inclure dans le serveur en sélectionnant
+ un certain nombre de modules. Les modules peuvent être soit intégrés
+ statiquement dans le binaire <program>httpd</program> lors de la
+ compilation du serveur, soit compilés en tant qu'objets
+ dynamiques partagés (DSOs) qui existeront indépendamment du binaire
+ principal <program>httpd</program>. Les modules DSO peuvent être compilés
+ au moment de la construction du serveur, ou bien compilés séparément,
+ à l'aide de l'utilitaire des extensions d'Apache (<program>apxs</program>),
+ et associés au serveur ultérieurement.</p>
+
+ <p>Ce document décrit l'utilisation des modules DSO ainsi que les dessous
+ de leur fonctionnement.</p>
+ </summary>
+
+
+<section id="implementation"><title>Implémentation</title>
+
+<related>
+<modulelist>
+<module>mod_so</module>
+</modulelist>
+<directivelist>
+<directive module="mod_so">LoadModule</directive>
+</directivelist>
+</related>
+
+ <p>Le support DSO pour le chargement de modules individuels d'Apache est
+ assuré par un module nommé <module>mod_so</module> qui doit être compilé
+ statiquement dans le coeur d'Apache. Il s'agit du seul module avec le
+ module <module>core</module> à ne pas pouvoir être compilé en tant que
+ module DSO lui-même. Pratiquement tous les autres modules d'Apache
+ distribués peuvent être compilés en tant que modules DSO en sélectionnant
+ pour chacun d'entre eux le mode de construction DSO à l'aide de l'option
+ <code>--enable-<em>module</em>=shared</code> du script
+ <program>configure</program>, comme décrit dans la
+ <a href="install.html">Documentation de l'installation</a>. Une fois
+ compilé en tant que module DSO, un module peut être chargé en mémoire au
+ démarrage ou redémarrage du serveur à l'aide de la commande
+ <directive module="mod_so">LoadModule</directive> du module
+ <module>mod_so</module>, placée
+ dans votre fichier <code>httpd.conf</code>.</p>
+
+ <p>Un nouvel utilitaire a été introduit afin de simplifier la création de
+ fichiers DSO pour les modules d'Apache
+ (particulièrement pour les modules tiers) ; il s'agit du programme nommé
+ <program>apxs</program> (<dfn>APache
+ eXtenSion</dfn>). On peut l'utiliser pour construire des modules de type
+ DSO <em>en dehors</em> de l'arborescence des sources d'Apache. L'idée est
+ simple : à l'installation d'Apache, la procédure <code>make install</code>
+ du script <program>configure</program> installe les fichiers d'en-têtes
+ d'Apache et positionne, pour la plateforme de compilation, les drapeaux du compilateur et de
+ l'éditeur de liens à l'intérieur du programme
+ <program>apxs</program>, qui sera utilisé pour la construction de fichiers DSO.
+ Il est ainsi possible d'utiliser le programme <program>apxs</program>
+ pour compiler ses sources de modules Apache sans avoir besoin de
+ l'arborescence des sources de la distribution d'Apache, et sans avoir à
+ régler les drapeaux du compilateur et de l'éditeur de liens pour le support DSO.</p>
+</section>
+
+<section id="usage"><title>Mode d'emploi succinct</title>
+
+ <p>Afin que vous puissiez vous faire une idée des fonctionnalités DSO
+ d'Apache 2.x, en voici un résumé court et concis :</p>
+
+ <ol>
+ <li>
+ Construire et installer un module Apache <em>faisant partie de la
+ distribution</em>, par exemple <code>mod_foo.c</code>,
+ en tant que module DSO <code>mod_foo.so</code> :
+
+<example>
+$ ./configure --prefix=/chemin/vers/répertoire-installation
+--enable-foo=shared<br />
+$ make install
+</example>
+ </li>
+
+ <li>
+ Construire et installer un module Apache <em>tiers</em>, par exemple
+ <code>mod_foo.c</code>, en tant que module DSO <code>mod_foo.so</code> :
+
+<example>
+$ ./configure --add-module=<var>type_de_module</var>:
+/chemin/vers/module_tiers/mod_foo.c \<br />
+<indent>
+ --enable-foo=shared<br />
+</indent>
+$ make install
+</example>
+ </li>
+
+ <li>
+ Configurer Apache pour <em>pouvoir installer ultérieurement</em> des
+ modules partagés :
+
+<example>
+$ ./configure --enable-so<br />
+$ make install
+</example>
+ </li>
+
+ <li>
+ Construire et installer un module Apache <em>tiers</em>, par exemple
+ <code>mod_foo.c</code>, en tant que module DSO
+ <code>mod_foo.so</code> <em>en dehors</em> de l'arborescence des sources
+ d'Apache à l'aide du programme <program>apxs</program> :
+
+<example>
+$ cd /chemin/vers/module_tiers<br />
+$ apxs -c mod_foo.c<br />
+$ apxs -i -a -n foo mod_foo.la
+</example>
+ </li>
+ </ol>
+
+ <p>Dans tous les cas, une fois le module partagé compilé, vous devez
+ ajouter une directive <directive module="mod_so">LoadModule</directive>
+ dans le fichier <code>httpd.conf</code> pour qu'Apache active le module.</p>
+</section>
+
+<section id="background"><title>Les dessous du fonctionnement des DSO</title>
+
+ <p>Les clônes modernes d'UNIX proposent un astucieux mécanisme
+ communément appelé édition de liens et chargement dynamiques d'
+ <em>Objets Dynamiques Partagés</em> (DSO), qui permet de construire un
+ morceau de programme dans un format spécial pour le rendre chargeable
+ à l'exécution dans l'espace d'adressage d'un programme exécutable.</p>
+
+ <p>Ce chargement peut s'effectuer de deux manières : automatiquement par
+ un programme système appelé <code>ld.so</code> quand un programme
+ exécutable est démarré, ou manuellement à partir du programme en cours
+ d'exécution via sa propre interface système vers le chargeur Unix à l'aide
+ des appels système <code>dlopen()/dlsym()</code>.</p>
+
+ <p>Dans la première méthode, les DSO sont en général appelés
+ <em>bibliothèques partagées</em> ou encore <em>bibliothèques DSO</em>, et
+ possèdent des noms du style
+ <code>libfoo.so</code> ou <code>libfoo.so.1.2</code>. Ils résident dans un
+ répertoire système (en général <code>/usr/lib</code>)
+ et le lien avec le programme exécutable est établi à la compilation en
+ ajoutant <code>-lfoo</code> à la commande de l'éditeur de liens. Les
+ références à la bibliothèque sont ainsi codées en dur dans le fichier du
+ programme exécutable de façon à ce qu'au démarrage du programme, le
+ chargeur Unix soit capable de localiser <code>libfoo.so</code> dans
+ <code>/usr/lib</code>, dans des chemins codés en dur à l'aide d'options de
+ l'éditeur de liens comme <code>-R</code> ou dans des chemins définis par la
+ variable d'environnement
+ <code>LD_LIBRARY_PATH</code>. Le chargeur peut dès lors résoudre tous les symboles
+ (jusque là non encore résolus) du DSO dans le programme exécutable.</p>
+
+ <p>Les symboles du programme exécutable ne sont en général pas
+ référencés par le DSO (car c'est une bibliothèque de code à usage général
+ et réutilisable),
+ et ainsi aucune résolution supplémentaire n'est nécessaire. De son côté,
+ le programme exécutable ne doit accomplir aucune action particulière
+ pour utiliser les
+ symboles du DSO car toutes les résolutions sont effectuées par le chargeur
+ Unix. En fait, le code permettant d'invoquer
+ <code>ld.so</code> fait partie du code de démarrage pour l'exécution qui
+ est lié dans tout programme exécutable non statiquement lié.
+ L'avantage du chargement dynamique du code d'une bibliothèque partagée est
+ évident : le code de la bibliothèque ne doit être stocké qu'une seule fois
+ dans une bibliothèque système telle que <code>libc.so</code>, ce qui permet
+ d'économiser de l'espace disque pour les autres programmes.</p>
+
+ <p>Dans la seconde méthode, les DSO sont en général appelés <em>objets
+ partagés</em> ou <em>fichiers DSO</em>, et peuvent être nommés avec
+ l'extension de son choix (bien que le nom conseillé soit du style
+ <code>foo.so</code>). Ces fichiers résident en général dans un répertoire
+ spécifique à un programme, et aucun lien n'est automatiquement établi avec
+ le programme exécutable dans lequel ils sont utilisés.
+ Le programme exécutable charge manuellement le DSO à l'exécution dans son
+ espace d'adressage à l'aide de l'appel système <code>dlopen()</code>.
+ A ce moment, aucune résolution de symboles du DSO n'est effectuée pour le
+ programme exécutable. Par contre le chargeur Unix
+ résoud automatiquement tout symbole du DSO (non encore résolu)
+ faisant partie de l'ensemble de symboles exporté par le programme
+ exécutable et ses bibliothèques DSO déjà chargées (et en particulier tous
+ les symboles de la bibliothèque à tout faire <code>libc.so</code>).
+ De cette façon, le DSO prend connaissance de l'ensemble de symboles du
+ programme exécutable comme s'il avait été lié statiquement avec lui
+ auparavant.</p>
+
+ <p>Finalement, pour tirer profit de l'API des DSO, le programme exécutable
+ doit résoudre certains symboles du DSO à l'aide de l'appel système
+ <code>dlsym()</code> pour une utilisation ultérieure dans les tables de
+ distribution, <em>etc...</em> En d'autres termes, le programme exécutable doit
+ résoudre manuellement tous les symboles dont il a besoin pour pouvoir les
+ utiliser.
+ Avantage d'un tel mécanisme : les modules optionnels du programme n'ont pas
+ besoin d'être chargés (et ne gaspillent donc pas de ressources mémoire)
+ tant qu'il ne sont pas nécessaires au programme en question. Si nécessaire,
+ ces modules peuvent être chargés dynamiquement afin d'étendre les
+ fonctionnalités de base du programme.</p>
+
+ <p>Bien que ce mécanisme DSO paraisse évident, il comporte au moins une
+ étape difficile : la résolution des symboles depuis le programme exécutable
+ pour le DSO lorsqu'on utilise un DSO pour étendre les fonctionnalités d'un
+ programme (la seconde méthode). Pourquoi ? Parce que la "résolution
+ inverse" des symboles DSO à partir du jeu de symboles du programme
+ exécutable dépend de la conception de la bibliothèque (la bibliothèque n'a
+ aucune information sur le programme qui l'utilise) et n'est ni standardisée
+ ni disponible sur toutes les plateformes. En pratique, les symboles globaux
+ du programme exécutable ne sont en général pas réexportés et donc
+ indisponibles pour l'utilisation dans un DSO. Trouver une méthode pour
+ forcer l'éditeur de liens à exporter tous les symboles globaux est le
+ principal problème que l'on doit résoudre lorsqu'on utilise un DSO pour
+ étendre les fonctionnalités d'un programme au moment de son exécution.</p>
+
+ <p>L'approche des bibliothèques partagées est la plus courante, parce que
+ c'est dans cette optique que le mécanisme DSO a été conçu ; c'est cette
+ approche qui est ainsi
+ utilisée par pratiquement tous les types de bibliothèques que fournit le
+ système d'exploitation. Par contre, les objets partagés sont relativement
+ peu utilisés pour étendre les fonctionnalités d'un programme.</p>
+
+ <p>En 1998, seule une poignée de logiciels distribués
+ utilisaient le mécanisme DSO pour réellement étendre leurs fonctionnalités
+ au moment de l'exécution : Perl 5 (via son mécanisme XS et le module
+ DynaLoader), le serveur Netscape, <em>etc...</em> A partir de la
+ version 1.3, Apache rejoignit ce groupe, car Apache
+ présentait déjà un concept modulaire pour étendre ses fonctionnalités, et
+ utilisait en interne une approche basée sur une liste de distribution pour
+ relier des modules externes avec les fonctionnalités de base d'Apache.
+ Ainsi, Apache était vraiment prédestiné à l'utilisation des DSO pour
+ charger ses modules au moment de l'exécution.</p>
+</section>
+
+<section id="advantages"><title>Avantages et inconvénients</title>
+
+ <p>Les fonctionnalités ci-dessus basées sur les DSO présentent les
+ avantages suivants :</p>
+
+ <ul>
+ <li>Le paquetage du serveur est plus flexible à l'exécution car le
+ processus serveur effectif peut être assemblé à l'exécution via la
+ directive <directive module="mod_so">LoadModule</directive> du fichier de
+ configuration <code>httpd.conf</code> plutôt que par des options du script
+ <program>configure</program> à la compilation. Par exemple,
+ on peut ainsi exécuter différentes instances du serveur
+ (standard et version SSL, version minimale et version étoffée
+ [mod_perl, PHP], <em>etc...</em>) à partir d'une seule installation
+ d'Apache.</li>
+
+ <li>Le paquetage du serveur peut être facilement étendu avec des modules
+ tiers, même après l'installation. Ceci présente en tout cas un gros
+ avantage pour les mainteneurs de paquetages destinés aux distributions,
+ car ils peuvent créer un paquetage Apache de base, et des paquetages
+ additionnels contenant des extensions telles que PHP, mod_perl, mod_fastcgi,
+ <em>etc...</em></li>
+
+ <li>Une facilité de prototypage des modules Apache car la paire
+ DSO/<program>apxs</program> vous permet d'une part de travailler en
+ dehors de l'arborescence des sources d'Apache, et d'autre part de n'avoir
+ besoin que de la commande <code>apxs -i</code>
+ suivie d'un <code>apachectl restart</code> pour introduire une nouvelle
+ version de votre module fraîchement développé dans le serveur Apache
+ en cours d'exécution.</li>
+ </ul>
+
+ <p>Inconvénients des DSO :</p>
+
+ <ul>
+ <li>Le mécanisme DSO n'est pas disponible sur toutes les plates-formes
+ car tous les systèmes d'exploitation ne supportent pas le chargement
+ dynamique de code dans l'espace d'adressage d'un programme.</li>
+
+ <li>Le serveur est environ 20 % plus lent au démarrage
+ à cause des résolutions de symboles supplémentaires que le chargeur
+ Unix doit effectuer.</li>
+
+ <li>Le serveur est environ 5 % plus lent à l'exécution
+ sur certaines plates-formes, car le code indépendant de la position (PIC)
+ nécessite parfois des manipulations compliquées en assembleur pour
+ l'adressage relatif qui ne sont pas toujours aussi rapides que celles
+ que permet l'adressage absolu.</li>
+
+ <li>Comme les modules DSO ne peuvent pas être liés avec d'autres
+ bibliothèques basées sur DSO (<code>ld -lfoo</code>) sur toutes les
+ plates-formes
+ (par exemple, les plates-formes basées sur a.out ne fournissent en
+ général pas cette fonctionnalité alors que les plates-formes basées sur
+ ELF le font), vous ne pouvez pas utiliser le mécanisme DSO pour tous les
+ types de modules. Ou en d'autres termes, les modules compilés comme
+ fichiers DSO sont contraints de n'utiliser que les symboles du coeur
+ d'Apache, de la bibliothèque C
+ (<code>libc</code>) et toutes autres bibliothèques statiques ou
+ dynamiques utilisées par le coeur d'Apache, ou d'archives statiques
+ (<code>libfoo.a</code>) contenant du code indépendant de la
+ position (PIC).
+ Il y a deux solutions pour utiliser un autre type de code : soit le
+ coeur d'Apache contient déjà lui-même une référence au code, soit vous
+ chargez le code vous-même via <code>dlopen()</code>.</li>
+ </ul>
+
+</section>
+
+</manualpage>
Added: httpd/httpd/trunk/docs/manual/glossary.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/glossary.xml.fr?rev=708014&view=auto
==============================================================================
--- httpd/httpd/trunk/docs/manual/glossary.xml.fr (added)
+++ httpd/httpd/trunk/docs/manual/glossary.xml.fr Sun Oct 26 09:38:53 2008
@@ -0,0 +1,567 @@
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+<!--English Revision : 664361 -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="glossary.xml.meta">
+
+ <title>Glossaire</title>
+
+ <summary>
+ <p>Ce glossaire définit la terminologie courante relative à Apache en
+ particulier, et aux serveurs web en général. Vous trouverez plus
+ d'informations sur chaque concept dans les liens fournis.</p>
+ </summary>
+
+<section id="definitions"><title>Définitions</title>
+
+<dt><a name="algorithm" id="algorithm">Algorithme</a></dt>
+
+ <dd>Une formule sans ambiguité ou un jeu de règles destinées à
+ résoudre un problème en un nombre fini d'étapes. Les algorithmes de
+ chiffrement sont en général appelés
+ <dfn>Ciphers</dfn>.
+ </dd>
+
+ <dt><a name="cipher" id="cipher">Algorithme de chiffrement
+ (Cipher)</a></dt>
+ <dd>Un algorithme ou un système de chiffrement des données.
+ Quelques exemples : DES, IDEA, RC4, etc.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="tarball" id="tarball">Archive Tar (Tarball)</a></dt>
+ <dd>Un paquetage de fichiers rassemblés dans une archive
+ à l'aide de l'utilitaire <code>tar</code>.
+ Les distributions d'Apache sont stockées dans des Archives Tar compressées
+ ou en utilisant pkzip.
+ </dd>
+
+ <dt><a name="authentication" id="authentication">Authentification </a></dt>
+ <dd>L'identification formelle d'une entité du réseau comme un serveur, un
+ client, ou un utilisateur.<br />
+ Voir : <a href="howto/auth.html">Authentification, Autorisation, et
+ contrôle d'accès</a>
+ </dd>
+
+ <dt><a name="certificationauthority"
+ id="certificationauthority">Autorité de Certification
+ (Certification Authority)</a>
+ <a name="ca" id="ca">(CA)</a></dt>
+ <dd>Un tiers de confiance habilité à signer des certificats pour des entités
+ du réseau qu'il a authentifiées selon des critères basés sur la sécurité.
+ Les autres entités du réseau peuvent alors utiliser la signature pour
+ vérifier qu'une CA a authentifié le porteur du certificat.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+
+<dt><a name="certificate" id="certificate">Certificat (Certificate)</a></dt>
+ <dd>Un ensemble de données servant à authentifier des entités du
+ réseau comme un serveur ou un client. Un certificat contient des ensembles
+ d'informations X509 à propos de son propriétaire (appelé sujet/subject)
+ et de l'<glossary
+ ref="certificationauthority">Autorité de Certification
+ (Certification Authority) ou CA</glossary> signataire (appelée
+ le fournisseur/issuer), ainsi que la
+ <glossary ref="publickey">clé publique (public
+ key)</glossary> du propriétaire et la
+ signature de la CA. Les entités du réseau vérifient ces signatures
+ en utilisant les certificats des Autorités de Certification.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="publickeycryptography"
+ id="publickeycryptography">Chiffrement à Clé Publique
+ (Public Key Cryptography)</a></dt>
+ <dd>L'étude et l'application des systèmes de chiffrement asymétriques,
+ qui utilisent une clé pour le chiffrement et une autre pour le
+ déchiffrement. Les deux clés correspondantes constituent une paire de clés.
+ Appelé aussi chiffrement asymétrique.
+ <br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="privatekey" id="privatekey">Clé Privée (Private Key)</a></dt>
+ <dd>La clé secrète dans un système de
+ <glossary ref="publickeycryptography">chiffrement à clé publique</glossary>,
+ utilisée pour déchiffrer les messages entrants et signer
+ les messages sortants.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+<dt><a name="publickey" id="publickey">Clé Publique (Public Key)</a></dt>
+ <dd>La clé accessible au public dans un système de <glossary
+ ref="publickeycryptography">Chiffrement à clé publique</glossary>,
+ utilisée pour chiffrer les messages destinés uniquement à son
+ propriétaire et déchiffrer les signatures
+ faites par son propriétaire.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+<dt><a name="connect" id="connect">CONNECT</a></dt>
+ <dd>Une <glossary ref="method">méthode</glossary> HTTP pour encapsuler
+ des données brutes dans HTTP. Elle peut aussi être utilisée pour encapsuler
+ d'autres protocoles, comme le protocole SSL.
+ </dd>
+
+ <dt><a name="context" id="context">Contexte (Context)</a></dt>
+ <dd>Une portion des <glossary ref="configurationfile">
+ fichiers de configuration</glossary> dans laquelle certains types de
+ <glossary ref="directive">directives</glossary> sont autorisés.<br />
+ Voir : <a href="mod/directive-dict.html#Context">Termes utilisés
+ pour décrire les directives d'Apache</a>
+ </dd>
+
+<dl>
+ <dt><a name="accesscontrol" id="accesscontrol">Contrôle d'accès
+ (Access Control)</a></dt>
+ <dd>La restriction d'accès à des zones du réseau. Habituellement
+ dans un contexte Apache,
+ la restriction d'accès à certaines <em>URLs</em>.<br />
+ Voir : <a
+ href="howto/auth.html">Authentification, Autorisation et
+ Contrôle d'accès</a>
+ </dd>
+
+ <dt><a name="securesocketslayer" id="securesocketslayer">
+ Couche des Points de connexion Sécurisés
+ (Secure Sockets Layer)
+ </a> <a name="ssl" id="ssl">(SSL)</a></dt>
+ <dd>Un protocole créé par Netscape Communications Corporation pour
+ l'authentification et le chiffrement généraux des communications dans les
+ réseaux TCP/IP. L'utilisation la plus connue est <em>HTTPS</em>, autrement dit
+ le Protocole de Transfert Hypertexte (HTTP) au dessus de SSL.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="symmetriccryptophraphy" id="symmetriccryptophraphy">
+ Cryptographie Symétrique (Symmetric Cryptography)</a></dt>
+ <dd>L'étude et l'application des <em>Algorithmes de chiffrement</em> qui
+ utilisent une clé secrète unique pour les opérations de chiffrement et de
+ déchiffrement.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+
+ <dt><a name="export-crippled" id="export-crippled">
+ Dégradé pour l'exportation
+ (Export-Crippled)</a></dt>
+ <dd>Diminué en terme de puissance cryptographique (et de sécurité)
+ afin de respecter les Règles de l'Administration des Exportations
+ des Etats-Unis (Export Administration Regulations ou EAR).
+ Les logiciels de cryptographie dégradés pour l'exportation sont limités
+ à une clé de petite taille, et produisent un
+ <em>Texte crypté</em> qui peut en général être décrypté
+ par force brute.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+
+ <dt><a name="certificatsigningrequest"
+ id="certificatsigningrequest">Demande de signature de certificat
+ (Certificate Signing Request)</a>
+ <a name="csr" id="csr">(CSR)</a></dt>
+ <dd>La soumission d'un <glossary ref="certificate">certificat</glossary>
+ non signé à une <glossary ref="certificationauthority">Autorité de
+ certification</glossary>, qui le signe avec la <glossary
+ ref="privatekey">Clé privée</glossary> de leur
+ <em>Certificat</em> de CA. Une fois le CSR signé, il devient un vrai
+ certificat.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="directive" id="directive">Directive</a></dt>
+ <dd>Une commande de configuration qui contrôle un ou plusieurs aspects du
+ comportement d'Apache. Les directives sont placées dans le <glossary
+ ref="configurationfile">Fichier de configuration</glossary><br />
+ Voir : <a href="mod/directives.html">Index des directives</a>
+ </dd>
+
+<dt><a name="configurationdirective"
+ id="configurationdirective">Directive de configuration
+ (Configuration Directive)</a></dt>
+ <dd>Voir : <glossary ref="directive">Directive</glossary></dd>
+
+ <dt><a name="header" id="header">En-tête (Header)</a></dt>
+ <dd>La partie de la requête et de la réponse
+ <glossary ref="http">HTTP</glossary> qui est envoyée avant le contenu
+ proprement dit, et contient des méta-informations décrivant le contenu.
+ </dd>
+
+ <dt><a name="regularexpresion" id="regularexpresion">Expression Rationnelle
+ (Regular Expression)</a>
+ <a name="regex" id="regex">(Regex)</a></dt>
+ <dd>Une méthode pour décrire un modèle sous forme de texte - par exemple,
+ "tous les mots qui commencent par la lettre A" ou "tous les numéros de
+ téléphone à 10 chiffres" ou encore "Toutes les phrases contenant 2 virgules,
+ et aucun Q majuscule". Les expressions rationnelles sont très utiles dans
+ Apache car elles vous permettent d'appliquer certains attributs à des
+ ensembles de fichiers ou ressources avec une grande flexibilité
+ - par exemple, tous les fichiers .gif et .jpg situés dans tout répertoire
+ nommé "images", pourraient être enregistrés comme
+ "<code>/images/.*(jpg|gif)$</code>". Apache utilise les Expressions
+ Rationnelles Compatibles avec Perl fournies par la librairie <a
+ href="http://www.pcre.org/">PCRE</a>.
+ </dd>
+
+ <dt><a name="configurationfile" id="configurationfile">
+ Fichier de configuration
+ (Configuration File)</a></dt>
+ <dd>Un fichier texte contenant des
+ <glossary ref="directive">Directives</glossary>
+ qui contrôlent la configuration d'Apache.<br />
+ Voir : <a href="configuring.html">Fichiers de configuration</a>
+ </dd>
+
+ <dt><a name="filter" id="filter">Filtre (Filter)</a></dt>
+ <dd>Un traitement appliqué aux données envoyées ou reçues par le serveur.
+ Les filtres en entrée traitent les données envoyées au serveur par le
+ client, alors que les filtres en sortie traitent les documents sur le
+ serveur avant qu'ils soient envoyés au client.
+ Par exemple, le filtre en sortie
+ <code>INCLUDES</code>
+ traite les documents pour les
+ <glossary ref="ssi">Server Side Includes (Inclusions côté Serveur)
+ </glossary>.<br />
+ Voir : <a href="filter.html">Filtres</a>
+ </dd>
+
+<dt><a name="handler" id="handler">Gestionnaire (Handler)</a></dt>
+ <dd>Une représentation interne à Apache de l'action à entreprendre
+ quand un fichier est appelé. En général, les fichiers ont des gestionnaires
+ implicites, basés sur le type de fichier. Normalement, tous les
+ fichiers sont directement servis par le serveur, mais certains
+ types de fichiers sont "gérés" séparément. Par exemple, le gestionnaire
+ <code>cgi-script</code> désigne les fichiers qui doivent être traités
+ comme <glossary ref="cgi">CGIs</glossary>.<br />
+ Voir : <a href="handler.html">Utilisation des gestionnaires d'Apache</a>
+ </dd>
+
+ <dt><a name="hash" id="hash">Hachage (Hash)</a></dt>
+ <dd>Un algorithme mathématique à sens unique, irréversible, générant une
+ chaîne de longueur fixe à partir d'une autre chaîne de longueur quelconque.
+ Des chaînes différentes en entrée vont normalement produire des chaînes
+ différentes en sortie (selon la fonction de hachage).
+ </dd>
+
+ <dt><a name="virtualhosting" id="virtualhosting">Hébergement Virtuel
+ (Virtual Hosting)</a></dt>
+ <dd>Servir des sites web multiples en utilisant une seule instance d'Apache.
+ Les <em>Hôtes virtuels basés sur IP</em> différencient les sites web en se
+ basant sur leur adresse IP, alors que les
+ <em>Hôtes virtuels basés sur le nom</em> utilisent uniquement le nom d'hôte
+ et peuvent en conséquence héberger de nombreux sites avec la même
+ adresse IP.<br />
+ Voir la <a href="vhosts/">Documentation des Hôtes Virtuels d'Apache</a>
+ </dd>
+
+
+ <dt><a name="htaccess" id="htaccess">.htaccess</a></dt>
+ <dd>Un <glossary ref="configurationfile">fichier de configuration</glossary>
+ placé à un certain niveau de l'arborescence du site web, et appliquant des
+ <glossary ref="directive">directives</glossary> de configuration au
+ répertoire dans lequel il est placé, ainsi qu'à tous ses sous-répertoires.
+ En dépit de son nom, ce fichier peut contenir pratiquement tout type de
+ directive, et pas seulement des directives de contrôle d'accès.<br />
+ Voir : <a href="configuring.html">Fichiers de configuration</a>
+ </dd>
+
+<dt><a name="httpd.conf" id="httpd.conf">httpd.conf</a></dt>
+ <dd>Le <glossary ref="configurationfile">fichier de configuration
+ </glossary> principal d'Apache. Sa localisation par défaut est
+ <code>/usr/local/apache2/conf/httpd.conf</code>, mais ceci peut être
+ changé en utilisant des options de compilation ou d'exécution.<br />
+ Voir : <a href="configuring.html">Fichiers de configuration</a>
+ </dd>
+
+ <dt><a name="https" id="https">HTTPS</a></dt>
+ <dd>Le Protocole de Transfert Hypertexte (Sécurisé), le mécanisme de
+ communication cryptée standard sur le World Wide Web.
+ Il s'agit en fait de HTTP au dessus de
+ <glossary ref="ssl">SSL</glossary>.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="uniformresourceidentifier"
+ id="uniformresourceidentifier">Identificateur de Ressource Uniformisé
+ (Uniform Resource Identifier)</a>
+ <a name="URI" id="URI">(URI)</a></dt>
+ <dd>Une chaîne de caractères compacte servant à identifier une ressource
+ abstraite ou physique. Elle est formellement définie par la <a
+ href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</a>. Les URIs
+ utilisées sur le world-wide web sont souvent appelées <glossary
+ ref="url">URLs</glossary>.
+ </dd>
+
+ <dt><a name="serversideincludes" id="serversideincludes">
+ Inclusions Côté Serveur
+ (Server Side Includes)</a> <a name="ssi" id="ssi">(SSI)
+ </a></dt>
+ <dd>Une technique permettant d'englober des directives de traitement dans
+ des fichiers HTML.<br />
+ Voir : <a href="howto/ssi.html">Introduction aux Inclusions Côté Serveur</a>
+ </dd>
+
+<dt><a name="commongatewayinterface" id="commongatewayinterface">
+Interface commune avec les programmes externes
+(Common Gateway Interface)</a>
+ <a name="cgi" id="cgi">(CGI)</a></dt>
+ <dd>La définition standard d'une interface entre un serveur web et un
+ programme externe pour permettre à ce dernier de traiter des requêtes.
+ L'interface a été initialement définie par <a
+ href="http://hoohoo.ncsa.uiuc.edu/cgi/overview.html">NCSA</a> mais il
+ existe aussi le projet
+ <a href="http://cgi-spec.golux.com/">RFC project</a>.<br />
+ Voir : <a href="howto/cgi.html">Contenu dynamique avec CGI</a>
+ </dd>
+
+
+ <dt><a name="apacheportableruntime"
+ id="apacheportableruntime">Bibliothèques pour la portabilité d'Apache
+ (Apache Portable Runtime)</a> <a
+ name="apr" id="apr">(APR)</a></dt>
+ <dd>Un jeu de bibliothèques qui fournit la plupart des interfaces de base
+ entre le serveur et le système d'exploitation. APR est développé
+ parallèlement au serveur HTTP Apache comme projet indépendant.<br />
+ Voir : <a href="http://apr.apache.org/">Apache Portable Runtime
+ Project</a>
+ </dd>
+<dt><a name="uniformresourcelocator" id="uniformresourcelocator">
+Localisation de Ressource Uniformisée
+(Uniform Resource Locator)
+ </a> <a name="url" id="url">(URL)</a></dt>
+ <dd>Le nom/adresse d'une ressource sur l'Internet. Il s'agit du terme
+ informel commun pour ce qui est formellement défini comme <glossary
+ ref="uniformresourceidentifier">
+ Identificateur de Ressource Uniformisé</glossary>.
+ Les URLs sont généralement construites selon un schéma, comme
+ <code>http</code> ou
+ <code>https</code>, un nom d'hôte, et un chemin. Une URL pour cette page
+ pourrait être
+ <code>http://httpd.apache.org/docs/&httpd.docs;/glossary.html</code>.
+ </dd>
+
+
+ <dt><a name="proxy" id="proxy">Mandataire (Proxy)</a></dt>
+ <dd>Un serveur intermédiaire qui se situe entre le client et le
+ <em>serveur d'origine</em>.
+ Il prend en compte les requêtes des clients, les transmet au serveur
+ d'origine, puis renvoie la réponse du serveur d'origine au client.
+ Si plusieurs clients demandent le même contenu, le mandataire peut l'extraire
+ de son cache, plutôt que le demander au serveur d'origine
+ à chaque fois, ce qui réduit le temps de réponse.<br />
+ Voir : <a href="mod/mod_proxy.html">mod_proxy</a>
+ </dd>
+
+ <dt><a name="reverseproxy" id="reverseproxy">Mandataire inverse
+ (Reverse Proxy)</a></dt>
+ <dd>Un serveur <glossary ref="proxy">mandataire</glossary> qui est vu du client
+ comme un <em>serveur d'origine</em>. Ceci peut s'avérer utile pour
+ dissimuler le serveur d'origine réel au client pour des raisons de sécurité,
+ ou pour répartir la charge.
+ </dd>
+
+ <dt><a name="method" id="method">Méthode (Method)</a></dt>
+ <dd>Dans le contexte <glossary ref="http">HTTP</glossary>, une action à
+ effectuer sur une ressource spécifiée dans la ligne de requête
+ par le client. Parmi les méthodes disponibles dans HTTP, on trouve
+ <code>GET</code>, <code>POST</code>,
+ et <code>PUT</code>.
+ </dd>
+
+ <dt><a name="module" id="module">Module</a></dt>
+ <dd>Une partie indépendante d'un programme. De nombreuses fonctionnalités
+ d'Apache sont fournies par des modules que vous pouvez choisir d'inclure
+ ou d'exclure. Les modules qui sont compilés dans le binaire
+ <program>httpd</program> sont appelés <dfn>modules statiques</dfn>, alors
+ que les modules qui existent séparément et peuvent être chargés
+ optionnellement à l'exécution sont appelés
+ <dfn>modules dynamiques</dfn> ou <glossary ref="dso">DSOs</glossary>.
+ Les modules qui sont inclus par défaut sont appelés
+ <dfn>modules de base</dfn>. De nombreux modules disponibles pour Apache
+ ne se trouvent pas dans l'<glossary ref="tarball">archive</glossary>
+ du Serveur HTTP Apache . Il sont appelés
+ <dfn>modules tiers</dfn>.<br />
+ Voir : <a href="mod/">Index des modules</a>
+ </dd>
+
+<dt><a name="passphrase" id="passphrase">Mot de Passe (Pass Phrase)</a></dt>
+ <dd>Le mot ou la phrase qui protège les fichiers de clés privées.
+ Il empêche les utilisateurs non autorisés de les déchiffrer. En général,
+ il s'agit simplement de la clé secrète de chiffrement/déchiffrement
+ utilisée pour les <glossary
+ ref="cipher">Algorithmes de chiffrement</glossary>.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="fully-qualifieddomain-name"
+ id="fully-qualifieddomain-name">Nom de domaine entièrement qualifié
+ (Fully-Qualified Domain-Name)</a>
+ <a name="fqdn" id="fqdn">(FQDN)</a></dt>
+ <dd>Le nom unique d'une entité du réseau, comprenant un nom d'hôte et un
+ nom de domaine qui peuvent être résolus en une adresse IP. Par exemple,
+ <code>www</code> est un nom d'hôte, <code>example.com</code> est un nom
+ de domaine, et <code>www.example.com</code> est un nom de domaine
+ entièrement qualifié.
+ </dd>
+
+ <dt><a name="modulemagicnumber" id="modulemagicnumber">
+ Nombre Magique des Modules
+ (Module Magic Number)</a>
+ (<a name="mmn" id="mmn">MMN</a>)</dt>
+ <dd>Le Nombre Magique des Modules est une constante définie dans le code
+ source d'Apache et associée à la compatibilité binaire des modules.
+ Sa valeur est modifiée quand des structures internes d'Apache, des appels
+ de fonctions et d'autres parties significatives de l'API sont modifiées
+ de telle façon que la compatibilité binaire ne peut plus être garantie.
+ En cas de changement de MMN, tous les modules tiers doivent être au
+ moins recompilés, et parfois même légèrement modifiés afin de pouvoir
+ fonctionner avec la nouvelle version d'Apache.
+ </dd>
+
+ <dt><a name="dynamicsharedobject" id="dynamicsharedobject">
+ Objet Dynamique Partagé (Dynamic Shared Object)
+ </a> <a name="dso" id="dso">(DSO)</a></dt>
+ <dd><glossary ref="module">Modules</glossary> compilés en dehors du binaire
+ Apache <program>httpd</program> et qui peuvent être
+ chargés à la demande.<br />
+ Voir : <a href="dso.html">Support des objets dynamiques partagés</a>
+ </dd>
+
+<dt><a name="openssl" id="openssl">OpenSSL</a></dt>
+ <dd>L'ensemble d'outils Open Source pour SSL/TLS<br />
+ Voir <a href="http://www.openssl.org/">http://www.openssl.org/</a>#
+ </dd>
+
+<dt><a name="apacheextensiontool" id="apacheextensiontool">
+ Outil de gestion des extensions Apache
+ (APache eXtension Tool)</a>
+ <a name="apxs" id="apxs">(apxs)</a></dt>
+ <dd>Un script Perl qui aide à la compilation des sources de <glossary
+ ref="module">module</glossary> sous forme d'Objets Dynamiques Partagés
+ (Dynamic Shared Objects ou
+ <glossary ref="dso">DSO</glossary>s) et facilite leur installation
+ dans le serveur Web Apache.<br />
+ Voir : Page de manuel : <program>apxs</program>
+ </dd>
+
+<dt><a name="plaintext" id="plaintext">Plein Texte (Plaintext)</a></dt>
+ <dd>Le texte non chiffré.</dd>
+
+
+
+ <dt><a name="hypertexttransferprotocol"
+ id="hypertexttransferprotocol">Protocole de Transfert Hypertexte
+ (HyperText Transfer Protocol)</a>
+ <a name="http" id="hhtp">(HTTP)</a></dt>
+ <dd>Le protocole de transmission standard utilisé sur le World Wide Web.
+ Apache implémente la version 1.1 du protocole, référencée comme HTTP/1.1 et
+ définie par la
+ <a href="http://ietf.org/rfc/rfc2616.txt">RFC 2616</a>.
+ </dd>
+
+ <dt><a name="messagedigest" id="messagedigest">Résumé de message
+ (Message Digest)</a></dt>
+ <dd>Un hachage du message, qui peut être utilisé pour vérifier
+ que son contenu n'a pas été altéré durant le transfert.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="transportlayersecurity" id="transportlayersecurity">
+ Sécurité de la couche Transport
+ (Transport Layer Security)
+ </a> <a name="tls" id="tls">(TLS)</a></dt>
+ <dd>Le protocole successeur de SSL, créé par l'Internet Engineering Task
+ Force (IETF) pour l'authentification et le chiffrement généraux des
+ communications dans les réseaux TCP/IP. TLS version 1 est pratiquement
+ identique à SSL version 3.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="session" id="session">Session</a></dt>
+ <dd>Les informations sur le contexte d'une communication en général.</dd>
+
+ <dt><a name="digitalsignature" id="digitalsignature">Signature numérique
+ (Digital Signature)</a></dt>
+ <dd>Un bloc de texte crypté qui valide un certificat ou un autre fichier.
+ Une <glossary ref="certificationauthority">Autorité de certification</glossary>
+ crée une signature en générant une empreinte de la <em>Clé publique</em>
+ fournie avec le <em>Certificat</em>; la CA chiffre ensuite l'empreinte
+ avec sa propre <em>Clé privée</em>. Seule la clé publique de la CA
+ peut décrypter la signature, ce qui permet de vérifier que la CA a bien
+ authentifié l'entité du réseau qui possède le
+ <em>Certificat</em>.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+<dt><a name="ssleay" id="ssleay">SSLeay</a></dt>
+ <dd>La bibliothèque originelle d'implémentation de SSL/TLS développée par
+ Eric A. Young
+ </dd>
+
+<dt><a name="ciphertext" id="ciphertext">Texte crypté
+(Ciphertext)</a></dt>
+ <dd>Le résultat du passage d'un document
+ <glossary ref="plaintext">Plaintext</glossary> (Plein texte) par un
+ <glossary ref="cipher">Cipher</glossary>.<br />
+ Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+
+ <dt><a name="mime-type" id="mime-type">Type MIME (MIME-type)</a></dt>
+ <dd>Une méthode pour décrire le type de document transmis. Son nom
+ vient du fait que son format est issu des Multipurpose
+ Internet Mail Extensions (Extensions Multi-usages de la
+ Messagerie par Internet) . Il comprend un type majeur et un type
+ mineur, séparés par un slash (barre oblique). On trouve
+ entre autres types <code>text/html</code>,
+ <code>image/gif</code>, et <code>application/octet-stream</code>. Dans
+ HTTP, le type MIME est transmis dans l'
+ <glossary ref="header">en-tête</glossary> <code>Content-Type</code>.<br />
+ Voir : <a href="mod/mod_mime.html">mod_mime</a>
+ </dd>
+
+
+ <dt><a name="environmentvariable" id="environmentvariable">
+ Variable d'environnement
+ (Environment Variable)</a> <a name="env-variable"
+ id="env-variable">(env-variable)</a></dt>
+ <dd>Ce sont des variables nommées gérées par le shell du système
+ d'exploitation, et servant au stockage d'informations et à la
+ communication entre les programmes. Apache possède aussi des variables
+ internes considérées comme variables d'environnement, mais stockées dans
+ des structures internes à Apache, et non dans l'environnement
+ du shell.<br />
+ Voir : <a href="env.html">Les variables d'environnement dans Apache</a>
+ </dd>
+
+ <dt><a name="x.509" id="x.509">X.509</a></dt>
+ <dd>Une norme de certificat d'authentification recommandée par l'International
+ Telecommunication Union (ITU-T) et utilisée pour
+ l'authentification SSL/TLS.<br
+ /> Voir : <a href="ssl/">chiffrement SSL/TLS</a>
+ </dd>
+</dl>
+</section>
+</manualpage>
+
+
Added: httpd/httpd/trunk/docs/manual/logs.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/logs.xml.fr?rev=708014&view=auto
==============================================================================
--- httpd/httpd/trunk/docs/manual/logs.xml.fr (added)
+++ httpd/httpd/trunk/docs/manual/logs.xml.fr Sun Oct 26 09:38:53 2008
@@ -0,0 +1,669 @@
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+<!-- English Revision: 659902 -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<manualpage metafile="logs.xml.meta">
+
+ <title>Fichiers journaux</title>
+
+ <summary>
+ <p>Pour véritablement gérer un serveur web,
+ il est nécessaire de disposer d'un
+ retour d'informations à propos de l'activité et des performances du
+ serveur, ainsi que de tout problème qui pourrait survenir. Le serveur HTTP
+ Apache propose des fonctionnalités de journalisation souples et très
+ complètes. Ce document décrit comment configurer ces fonctionnalités de
+ journalisation et interpréter le contenu des journaux.</p>
+ </summary>
+
+ <section id="security">
+ <title>Avertissement à propos de la sécurité</title>
+
+ <p>Tout utilisateur qui a les droits en écriture sur le répertoire dans
+ lequel Apache écrit ses journaux pourra quasi
+ certainement avoir accès à l'uid sous lequel le serveur est démarré, en
+ l'occurrence habituellement root. N'accordez <em>PAS</em> aux utilisateurs
+ l'accès en écriture au répertoire dans lequel les journaux sont stockés
+ sans savoir exactement quelles en seraient les conséquences ; voir le
+ document <a href="misc/security_tips.html">conseils sur la sécurité</a>
+ pour plus de détails.</p>
+
+ <p>En outre, les journaux peuvent contenir des informations fournies
+ directement par un client, sans caractères d'échappement. Des clients mal
+ intentionnés peuvent donc insérer des caractères de contrôle dans les
+ journaux, et il convient par conséquent d'être très prudent lors de la
+ manipulation des journaux bruts.</p>
+ </section>
+
+ <section id="errorlog">
+ <title>Journal des erreurs</title>
+
+ <related>
+ <directivelist>
+ <directive module="core">ErrorLog</directive>
+ <directive module="core">LogLevel</directive>
+ </directivelist>
+ </related>
+
+ <p>Le journal des erreurs du serveur, dont le nom et la localisation sont
+ définis par la directive <directive module="core">ErrorLog</directive>,
+ est le journal le plus important. C'est dans celui-ci
+ que le démon Apache httpd va envoyer les informations de diagnostic et
+ enregistrer toutes les erreurs qui surviennent lors du traitement des
+ requêtes. Lorsqu'un problème survient au démarrage du serveur ou pendant
+ son fonctionnement, la première chose à faire est de regarder dans ce
+ journal, car il vous renseignera souvent sur le problème rencontré et
+ la manière d'y remédier.</p>
+
+ <p>Le journal des erreurs est habituellement enregistré dans un fichier
+ (en général <code>error_log</code> sur les systèmes de type Unix et
+ <code>error.log</code> sur Windows et OS/2). Sur les systèmes de type Unix,
+ le serveur peut aussi enregistrer ses erreurs dans
+ <code>syslog</code> ou les
+ <a href="#piped">rediriger vers un programme</a> par l'intermédiaire d'un
+ tube de communication (pipe).</p>
+
+ <p>Le format du journal des erreurs est descriptif et de forme
+ relativement libre. Certaines informations apparaissent cependant dans la
+ plupart des entrées du journal. Voici un message typique
+ à titre d'exemple : </p>
+
+ <example>
+ [Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1]
+ client denied by server configuration:
+ /export/home/live/ap/htdocs/test
+ </example>
+
+ <p>Le premier champ de l'entrée du journal est la date et l'heure du
+ message. Le second champ indique la sévérité de l'erreur rapportée. La
+ directive <directive module="core">LogLevel</directive> permet de
+ restreindre le type des erreurs qui doivent être enregistrées
+ dans le journal des erreurs en définissant leur niveau de sévérité. Le
+ troisième champ contient l'adresse IP du client qui a généré l'erreur.
+ Vient ensuite le message proprement dit, qui indique dans ce cas que le
+ serveur a été configuré pour interdire l'accès au client. Le serveur
+ indique le chemin système du document requis (et non
+ son chemin web).</p>
+
+ <p>Une grande variété de messages différents peuvent apparaître dans le
+ journal des erreurs. La plupart d'entre eux sont similaires à l'exemple
+ ci-dessus. Le journal des erreurs peut aussi contenir des informations de
+ débogage en provenance de scripts CGI. Toute information qu'un script CGI
+ écrit sur la sortie d'erreurs standard <code>stderr</code> sera recopiée
+ telle quelle dans le journal des erreurs.</p>
+
+ <p>Il n'est pas possible de personnaliser le journal des erreurs en ajoutant ou en
+ supprimant des informations. Cependant, les entrées du journal des erreurs
+ qui concernent certaines requêtes possèdent des entrées correspondantes
+ dans le <a href="#accesslog">journal des accès</a>. Ainsi, l'entrée de
+ l'exemple ci-dessus correspond à une entrée du journal des accès avec un
+ code de statut 403. Etant donné qu'il est possible de personnaliser le
+ journal des accès, vous pouvez obtenir d'avantage d'informations sur les
+ circonstances d'une erreur en consultant ce journal.</p>
+
+ <p>Pendant la phase de test, il est souvent utile de visualiser en continu
+ le journal des erreurs afin de détecter tout problème éventuel. Sur les
+ systèmes de type Unix, ceci s'effectue à l'aide de la commande :</p>
+
+ <example>
+ tail -f error_log
+ </example>
+ </section>
+
+ <section id="accesslog">
+ <title>Journal des accès</title>
+
+ <related>
+ <modulelist>
+ <module>mod_log_config</module>
+ <module>mod_setenvif</module>
+ </modulelist>
+ <directivelist>
+ <directive module="mod_log_config">CustomLog</directive>
+ <directive module="mod_log_config">LogFormat</directive>
+ <directive module="mod_setenvif">SetEnvIf</directive>
+ </directivelist>
+ </related>
+
+ <p>Le journal des accès au serveur
+ enregistre toutes les requêtes que traite
+ ce dernier. La localisation et le contenu du journal des accès sont définis
+ par la directive <directive module="mod_log_config">CustomLog</directive>.
+ La directive <directive module="mod_log_config">LogFormat</directive>
+ permet de simplifier la sélection du contenu du journal. Cette section
+ décrit comment configurer le serveur pour l'enregistrement des informations
+ dans le journal des accès.</p>
+
+ <p>Bien évidemment, le stockage d'informations dans le journal des accès
+ n'est que le point de départ de la gestion de la journalisation. L'étape
+ suivante consiste à analyser ces informations de façon à pouvoir en
+ extraire des statistiques utiles. L'analyse de journaux en général est en
+ dehors du sujet de ce document et ne fait pas vraiment partie intégrante
+ du travail du serveur web lui-même. Pour plus d'informations à propos de ce
+ sujet et des applications dédiées à l'analyse de journaux, vous pouvez vous
+ référer à <a href="http://dmoz.org/Computers/Software/Internet/
+ Site_Management/Log_analysis/">Open Directory</a> ou
+ <a href="http://dir.yahoo.com/Computers_and_Internet/Software/
+ Internet/World_Wide_Web/Servers/Log_Analysis_Tools/">Yahoo</a>.</p>
+
+ <p>Différentes versions du démon Apache httpd utilisaient d'autres modules
+ et directives pour contrôler la journalisation des accès, à l'instar de
+ mod_log_referer, mod_log_agent, et de la directive
+ <code>TransferLog</code>. La directive
+ <directive module="mod_log_config">CustomLog</directive> rassemble
+ désormais les fonctionnalités de toutes les anciennes directives.</p>
+
+ <p>Le format du journal des accès est hautement configurable. Il est
+ défini à l'aide d'une chaîne de format qui ressemble sensiblement à la
+ chaîne de format de style langage C de printf(1). Vous trouverez quelques
+ exemples dans les sections suivantes. Pour une liste exhaustive de ce que
+ peut contenir une chaîne de format, vous pouvez vous référer au chapitre
+ <a href="mod/mod_log_config.html#formats">chaînes de format</a> de la
+ documentation du module <module>mod_log_config</module>.</p>
+
+ <section id="common">
+ <title>Format habituel du journal</title>
+
+ <p>Voici une configuration typique pour le journal des accès :</p>
+
+ <example>
+ LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
+ CustomLog logs/access_log common
+ </example>
+
+ <p>Ici est définie l'<em>identité</em> <code>common</code> qui est
+ ensuite associée à une chaîne de format de journalisation particulière.
+ La chaîne de format est constituée de directives débutant par le
+ caractère %, chacune d'entre elles indiquant au serveur d'enregistrer
+ un élément particulier d'information. Des caractères littéraux peuvent
+ aussi être insérés dans la chaîne de format ; il seront copiés tels
+ quels dans le flux de sortie destiné à la journalisation.
+ Les guillemets (<code>"</code>) doivent être échappées en les faisant
+ précéder d'un anti-slash (<code>\</code>) afin qu'elles ne soient pas
+ interprétées comme la fin de la chaîne de format. La chaîne de format
+ peut aussi contenir les caractères de contrôle spéciaux
+ "<code>\n</code>" et "<code>\t</code>" pour insérer respectivement
+ un passage à la ligne et une tabulation.</p>
+
+ <p>La directive <directive module="mod_log_config">CustomLog</directive>
+ définit un nouveau fichier journal en l'associant à l'identité
+ précédemment définie. Le chemin du nom de fichier associé au journal
+ des accès est relatif au chemin défini par la directive
+ <directive module="core">ServerRoot</directive>, sauf s'il
+ débute par un slash.</p>
+
+ <p>La configuration ci-dessus va enregistrer les entrées de
+ journalisation selon un format connu sous le nom de
+ Common Log Format (CLF) pour "Format de journalisation standard".
+ Ce format standard peut être produit par de nombreux serveurs web
+ différents et lu par de nombreux programmes d'analyse de journaux.
+ Les entrées de fichier journal générées selon le format CLF
+ ressemblent à ceci :</p>
+
+ <example>
+ 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
+ /apache_pb.gif HTTP/1.0" 200 2326
+ </example>
+
+ <p>Chaque partie de cette entrée de journal est décrite
+ dans ce qui suit.</p>
+
+ <dl>
+ <dt><code>127.0.0.1</code> (<code>%h</code>)</dt>
+
+ <dd>Il s'agit de l'adresse IP du client (l'hôte distant) qui a envoyé
+ la requête au serveur. Si la directive
+ <directive module="core">HostnameLookups</directive> est positionnée à
+ <code>On</code>, le serveur va essayer de déterminer le nom de l'hôte
+ et de l'enregistrer à la place de l'adresse IP. Cette configuration
+ n'est cependant pas recommandée car elle peut ralentir le serveur de
+ manière significative. Il est par conséquent préférable d'utiliser un
+ processeur d'analyse de journaux a posteriori
+ tel que <program>logresolve</program>
+ pour déterminer les noms d'hôte. L'adresse IP indiquée ici n'est pas
+ nécessairement l'adresse IP de la machine devant laquelle se trouve
+ l'utilisateur. Si un serveur mandataire s'intercale entre le serveur
+ et l'utilisateur, l'adresse indiquée sera celle du mandataire et non
+ celle de la machine à l'origine de la requête.</dd>
+
+ <dt><code>-</code> (<code>%l</code>)</dt>
+
+ <dd>Le "trait d'union" indique que la portion d'information
+ correspondante n'est pas disponible. Dans le cas présent, l'information
+ non disponible est l'identité (RFC 1413) du client telle que déterminée
+ par <code>identd</code> sur la machine cliente. Cette information est
+ très peu fiable et ne devrait jamais être utilisée, sauf dans le cas
+ de réseaux internes étroitement contrôlés. Le démon httpd ne cherchera
+ d'ailleurs à obtenir cette information que si la directive
+ <directive module="core">IdentityCheck</directive> est positionnée
+ à <code>On</code>.</dd>
+
+ <dt><code>frank</code> (<code>%u</code>)</dt>
+
+ <dd>Il s'agit de l'identifiant utilisateur de la personne qui a
+ demandé le document, issu d'une authentification HTTP.
+ Ce même identifiant est en général fourni aux scripts CGI par
+ l'intermédiaire de la valeur de la variable d'environnement
+ <code>REMOTE_USER</code>. Si le statut de la requête (voir plus loin)
+ est 401, cette identifiant n'est pas fiable car l'utilisateur n'est
+ pas encore authentifié. Si le document n'est pas protégé par
+ mot de passe, cette partie d'information sera représentée par
+ "<code>-</code>", comme la partie précédente.</dd>
+
+ <dt><code>[10/Oct/2000:13:55:36 -0700]</code>
+ (<code>%t</code>)</dt>
+
+ <dd>
+ L'heure à laquelle la requête a été reçue.
+ Le format est le suivant :
+
+ <p class="indent">
+ <code>[jour/mois/année:heure:minutes:secondes zone]<br />
+ jour = 2*chiffre<br />
+ mois = 3*lettre<br />
+ année = 4*chiffre<br />
+ heure = 2*chiffre<br />
+ minutes = 2*chiffre<br />
+ secondes = 2*chiffre<br />
+ zone = (`+' | `-') 4*chiffre</code>
+ </p>Il est possible de modifier le format d'affichage de l'heure
+ en spécifiant <code>%{format}t</code> dans la chaîne de format du
+ journal, où <code>format</code> est une chaîne de format de même
+ forme que celle de la fonction <code>strftime(3)</code> de la
+ bibliothèque C standard.
+ </dd>
+
+ <dt><code>"GET /apache_pb.gif HTTP/1.0"</code>
+ (<code>\"%r\"</code>)</dt>
+
+ <dd>La ligne de la requête du client est placée entre guillemets.
+ Elle contient de nombreuses informations utiles. Tout d'abord, la
+ méthode utilisée par le client est <code>GET</code>. Ensuite, le
+ client a demandé la ressource <code>/apache_pb.gif</code>, et enfin,
+ le client a utilisé le protocole <code>HTTP/1.0</code>. Il est aussi
+ possible d'enregistrer séparément une ou plusieurs parties de la
+ requête. Par exemple, la chaîne de format "<code>%m %U %q %H</code>"
+ va enregistrer la méthode, le chemin, la chaîne de la requête et le
+ protocole, ce qui donnera le même résultat que
+ "<code>%r</code>".</dd>
+
+ <dt><code>200</code> (<code>%>s</code>)</dt>
+
+ <dd>C'est le code de statut que le serveur retourne au client. Cette
+ information est très importante car elle indique si la requête a fait
+ l'objet d'une réponse positive (codes commençant par 2), une
+ redirection (codes commençant par 3), une erreur due au client (codes
+ commençant par 4), ou une erreur due au serveur (codes commençant
+ par 5). Vous trouverez la liste complète des codes de statut possibles
+ dans la <a href="http://www.w3.org/Protocols/rfc2616/
+ rfc2616.txt">specification HTTP</a> (RFC2616 section 10).</dd>
+
+ <dt><code>2326</code> (<code>%b</code>)</dt>
+
+ <dd>La dernière partie indique la taille de l'objet retourné au client,
+ en-têtes non compris. Si aucun contenu n'a été retourné au client, cette
+ partie contiendra "<code>-</code>". Pour indiquer l'absence de contenu
+ par "<code>0</code>", utilisez <code>%B</code> au lieu de
+ <code>%b</code>.</dd>
+ </dl>
+ </section>
+
+ <section id="combined">
+ <title>Combined Log Format (Format de journalisation combiné)</title>
+
+ <p>Une autre chaîne de format couramment utilisée est le
+ "Combined Log Format" (Format de journalisation combiné). Il s'utilise
+ comme suit :</p>
+
+ <example>
+ LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
+ \"%{User-agent}i\"" combined<br />
+ CustomLog log/access_log combined
+ </example>
+
+ <p>Ce format est identique au Common Log Format, avec deux champs
+ supplémentaires. Chacun de ces deux champs utilise la directive
+ commençant par le caractère "%" <code>%{<em>header</em>}i</code>,
+ où <em>header</em> peut être n'importe quel en-tête de requête HTTP.
+ Avec ce format, le journal des accès se présentera comme suit :</p>
+
+ <example>
+ 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
+ /apache_pb.gif HTTP/1.0" 200 2326
+ "http://www.example.com/start.html" "Mozilla/4.08 [en]
+ (Win98; I ;Nav)"
+ </example>
+
+ <p>Les champs supplémentaires sont :</p>
+
+ <dl>
+ <dt><code>"http://www.example.com/start.html"</code>
+ (<code>\"%{Referer}i\"</code>)</dt>
+
+ <dd>L'en-tête "Referer" (sic) de la requête HTTP. Il indique le site
+ depuis lequel le client prétend avoir lancé sa requête. (Ce doit être
+ la page qui contient un lien vers <code>/apache_pb.gif</code> ou
+ inclut ce dernier fichier).</dd>
+
+ <dt><code>"Mozilla/4.08 [en] (Win98; I ;Nav)"</code>
+ (<code>\"%{User-agent}i\"</code>)</dt>
+
+ <dd>L'en-tête User-Agent de la requête HTTP. C'est une information
+ d'identification que le navigateur du client envoie à propos
+ de lui-même.</dd>
+ </dl>
+ </section>
+
+ <section id="multiple">
+ <title>Journaux d'accès multiples</title>
+
+ <p>Plusieurs journaux d'accès peuvent être créés en spécifiant tout
+ simplement plusieurs directives
+ <directive module="mod_log_config">CustomLog</directive> dans le
+ fichier de configuration. Par exemple, les directives suivantes vont
+ créer trois journaux d'accès. Le premier contiendra les informations
+ de base CLF, le second les informations du Referer, et le troisième
+ les informations sur le navigateur. Les deux dernières directives
+ <directive module="mod_log_config">CustomLog</directive> montrent
+ comment simuler les effets des directives <code>ReferLog</code> et
+ <code>AgentLog</code>.</p>
+
+ <example>
+ LogFormat "%h %l %u %t \"%r\" %>s %b" common<br />
+ CustomLog logs/access_log common<br />
+ CustomLog logs/referer_log "%{Referer}i -> %U"<br />
+ CustomLog logs/agent_log "%{User-agent}i"
+ </example>
+
+ <p>Cet exemple montre aussi qu'il n'est pas obligatoire d'associer
+ une chaîne de format à un alias au moyen de la directive
+ <directive module="mod_log_config">LogFormat</directive>. Elle peut
+ être définie directement dans la ligne de la directive
+ <directive module="mod_log_config">CustomLog</directive>.</p>
+ </section>
+
+ <section id="conditional">
+ <title>Journalisation conditionnelle</title>
+
+ <p>Il est parfois souhaitable d'exclure certaines entrées des journaux
+ d'accès en fonction des caractéristiques de la requête du client. On
+ peut aisément accomplir ceci à l'aide des
+ <a href="env.html">variables d'environnement</a>. Tout d'abord, une
+ variable d'environnement doit être définie pour indiquer que la
+ requête remplit certaines conditions. Pour ceci, on utilise en général
+ la directive <directive module="mod_setenvif">SetEnvIf</directive>,
+ puis la clause <code>env=</code> de la directive
+ <directive module="mod_log_config">CustomLog</directive> pour inclure
+ ou exclure les requêtes pour lesquelles
+ la variable d'environnement est définie.
+ Quelques exemples :</p>
+
+ <example>
+ # Marque les requêtes en provenance de l'interface loop-back<br />
+ SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog<br />
+ # Marque les requêtes pour le fichier robots.txt<br />
+ SetEnvIf Request_URI "^/robots\.txt$" dontlog<br />
+ # Journalise toutes les autres requêtes<br />
+ CustomLog logs/access_log common env=!dontlog
+ </example>
+
+ <p>Autre exemple, imaginons l'enregistrement des requêtes en provenance
+ d'utilisateurs de langue anglaise dans un journal, et celles des autres
+ utilisateurs dans un autre journal.</p>
+
+ <example>
+ SetEnvIf Accept-Language "en" english<br />
+ CustomLog logs/english_log common env=english<br />
+ CustomLog logs/non_english_log common env=!english
+ </example>
+
+ <p>Bien que nous venions de montrer que la journalisation conditionnelle
+ est souple et très puissante, cette méthode de contrôle du contenu des
+ journaux n'est pas la seule. Les fichiers journaux sont plus utiles
+ quand ils contiennent un enregistrement complet de l'activité du serveur,
+ et il est souvent plus aisé de simplement traiter à posteriori les fichiers
+ journaux pour supprimer les requêtes que vous ne voulez pas y voir
+ apparaître.</p>
+ </section>
+ </section>
+
+ <section id="rotation">
+ <title>Rotation des journaux</title>
+
+ <p>Même dans le cas d'un serveur modérément sollicité, la quantité
+ d'informations stockées dans les fichiers journaux est très importante.
+ Le fichier journal des accès grossit en général d'1 Mo ou plus toutes
+ les 10000 requêtes. Il est par conséquent nécessaire d'effectuer
+ périodiquement la rotation des journaux en déplaçant ou supprimant les
+ fichiers correspondants. On ne peut pas le faire pendant que le serveur
+ est en cours d'exécution, car Apache va continuer à écrire dans l'ancien
+ fichier journal aussi longtemps qu'il le maintiendra ouvert.
+ C'est pourquoi le serveur doit être
+ <a href="stopping.html">redémarré</a> après le déplacement ou la
+ suppression des fichiers journaux de façon à ce qu'il en ouvre
+ de nouveaux.</p>
+
+ <p>Avec un redémarrage <em>graceful</em>, on peut faire en sorte que le
+ serveur ouvre de nouveaux fichiers journaux sans perdre de connexions
+ existantes ou en cours avec les clients. Cependant, pour que ceci soit
+ possible, le serveur doit continuer à écrire dans les anciens fichiers
+ journaux pendant qu'il termine le traitement des requêtes en cours.
+ Il est donc nécessaire d'attendre un certain temps après le rédémarrage
+ avant d'effectuer tout traitement sur les fichiers journaux. Voici un
+ scénario typique dans lequel on effectue une simple rotation des
+ journaux en compressant les anciens fichiers correspondants afin
+ de gagner de l'espace disque :</p>
+
+ <example>
+ mv access_log access_log.old<br />
+ mv error_log error_log.old<br />
+ apachectl graceful<br />
+ sleep 600<br />
+ gzip access_log.old error_log.old
+ </example>
+
+ <p>La section suivante présente une autre méthode de rotation des journaux
+ qui consiste à utiliser les
+ <a href="#piped">journaux redirigés</a>.</p>
+ </section>
+
+ <section id="piped">
+ <title>Journaux redirigés</title>
+
+ <p>Nous avons vu que le démon httpd écrivait les informations de
+ journalisation des erreurs et des accès dans un fichier journal ;
+ il peut aussi
+ rediriger ces informations vers un autre processus par l'intermédiaire d'un
+ tube de communication (pipe). Cette fonctionnalité améliore
+ considérablement la souplesse de la journalisation, sans ajouter de code
+ au serveur principal. Pour rediriger les informations de journalisation
+ vers un tube de communication, remplacez simplement le nom de fichier
+ journal par
+ le caractère pipe "<code>|</code>", suivi du nom de l'exécutable qui va
+ recueillir les entrées de journal sur son entrée standard. Apache va
+ lancer le processus de redirection des journaux au moment du démarrage du
+ serveur, et le relancera s'il cesse de fonctionner
+ pendant l'exécution du serveur.
+ (Nous dénommons cette technique "journalisation
+ redirigée fiable" grâce à cette dernière fonctionnalité.)</p>
+
+ <p>Les processus de journalisation redirigée sont lancés par le processus
+ httpd parent, et héritent de l'UID de ce dernier. Cela signifie que les
+ programmes de journalisation dirigée s'exécutent généralement en tant que
+ root. Il est donc très important que ces programmes soient simples et
+ sécurisés.</p>
+
+ <p>Un des grands avantages de la journalisation redirigée est la possibilité
+ d'effectuer la rotation des journaux sans avoir à redémarrer le serveur. Pour
+ accomplir cette tâche, le serveur HTTP Apache fournit un programme simple
+ appelé <program>rotatelogs</program>. Par exemple, pour une rotation des
+ journaux toutes les 24 heures, ajoutez ces lignes :</p>
+
+ <example>
+ CustomLog "|/usr/local/apache/bin/rotatelogs
+ /var/log/access_log 86400" common
+ </example>
+
+ <p>Notez que l'ensemble de la commande qui sera appelée par le tube de
+ communication a été placée entre guillemets. Bien que cet exemple
+ concerne le journal des accès, la même technique peut être utilisée
+ pour le journal des erreurs.</p>
+
+ <p>Il existe un autre programme de rotation des journaux similaire mais
+ beaucoup plus souple : il s'agit de "cronolog", non fourni par Apache,
+ mais disponible <a href="http://www.cronolog.org/">ici</a>.</p>
+
+ <p>Comme la journalisation conditionnelle, la journalisation redirigée est
+ un outil très puissant, mais si elle existe, il est préférable d'utiliser
+ une solution plus simple comme le traitement à posteriori hors ligne.</p>
+ </section>
+
+ <section id="virtualhost">
+ <title>Hôtes virtuels</title>
+
+ <p>Lorsqu'un serveur possède plusieurs <a href
+ ="vhosts/">hôtes virtuels</a>, il existe de nombreuses solutions pour gérer
+ les fichiers journaux. Par exemple, on peut utiliser les journaux comme
+ s'il s'agissait d'un serveur avec un seul hôte. Il suffit pour cela de
+ placer les directives de journalisation en dehors des sections
+ <directive module="core" type="section">VirtualHost</directive> au niveau
+ du serveur principal, ce qui a pour effet de journaliser toutes les
+ requêtes dans le même journal des accès et des erreurs. Cette technique
+ est cependant inappropriée pour recueillir des statistiques sur chaque
+ hôte virtuel individuellement.</p>
+
+ <p>Si des directives <directive module=
+ "mod_log_config">CustomLog</directive> ou
+ <directive module="core">ErrorLog</directive> sont placées dans une section
+ <directive module="core" type="section">VirtualHost</directive>, toutes les
+ requêtes ou erreurs pour cet hôte virtuel ne seront enregistrées que dans
+ le fichier spécifié. Tout hôte virtuel qui ne possède pas de directives de
+ journalisation verra ses requêtes enregistrées dans le journal du serveur
+ principal. Cette technique est appropriée pour un petit nombre d'hôtes
+ virtuels, mais si ce nombre est important, elle peut devenir compliquée à
+ gérer. En outre, des problèmes de <a
+ href="vhosts/fd-limits.html">nombre de descripteurs
+ de fichiers insuffisant</a> peuvent rapidement apparaître.</p>
+
+ <p>Il existe un très bon compromis pour le journal des accès. En intégrant
+ les informations à propos de l'hôte virtuel à la chaîne de format du
+ journal, il est possible de journaliser tous les hôtes dans le même
+ journal, puis de séparer ultérieurement le journal en plusieurs journaux
+ individuels. Considérons par exemple les directives suivantes :</p>
+
+ <example>
+ LogFormat "%v %l %u %t \"%r\" %>s %b"
+ comonvhost<br />
+ CustomLog logs/access_log comonvhost
+ </example>
+
+ <p>Le champ <code>%v</code> sert à enregistrer le nom de l'hôte virtuel qui
+ traite la requête. Un programme tel que <a
+ href="programs/other.html">split-logfile</a> peut ensuite être utilisé
+ pour générer "à froid" autant de journaux que d'hôtes virtuels.</p>
+ </section>
+
+ <section id="other">
+ <title>Autres fichiers journaux</title>
+
+ <related>
+ <modulelist>
+ <module>mod_logio</module>
+ <module>mod_log_forensic</module>
+ <module>mod_cgi</module>
+ <module>mod_rewrite</module>
+ </modulelist>
+ <directivelist>
+ <directive module="mod_log_config">LogFormat</directive>
+ <directive module="mod_log_forensic">ForensicLog</directive>
+ <directive module="mpm_common">PidFile</directive>
+ <directive module="mod_rewrite">RewriteLog</directive>
+ <directive module="mod_rewrite">RewriteLogLevel</directive>
+ <directive module="mod_cgi">ScriptLog</directive>
+ <directive module="mod_cgi">ScriptLogBuffer</directive>
+ <directive module="mod_cgi">ScriptLogLength</directive>
+ </directivelist>
+ </related>
+
+ <section>
+ <title>Enregistrement du nombre réel d'octets envoyés et reçus</title>
+
+ <p>Le module <module>mod_logio</module> fournit deux champs
+ <directive module="mod_log_config">LogFormat</directive> supplémentaires
+ (%I et %O) qui permettent d'enregistrer le nombre réel d'octets reçus et
+ envoyés sur le réseau.</p>
+ </section>
+
+ <section>
+ <title>Journalisation de style investigation judiciaire (forensic logging)</title>
+
+ <p>Le module <module>mod_log_forensic</module> permet la journalisation
+ à des fins d'investigation judiciaire des requêtes des clients. La
+ journalisation est effectuée avant et après le traitement de la requête,
+ qui fait donc l'objet de deux entrées dans le journal. Le générateur de
+ journaux d'investigation est très strict et ne permet aucune
+ personnalisation. C'est un inestimable outil de débogage et de sécurité.</p>
+ </section>
+
+ <section id="pidfile">
+ <title>Fichier PID</title>
+
+ <p>Au démarrage, le démon httpd Apache enregistre l'identifiant du
+ processus httpd parent dans le fichier <code>logs/httpd.pid</code>.
+ Le nom de ce fichier peut être modifié à l'aide de la directive
+ <directive module="mpm_common">PidFile</directive>. Cet identifiant
+ permet à l'administrateur de redémarrer et arrêter le démon en
+ envoyant des signaux au processus parent ; sous Windows, vous devez
+ utiliser l'option de ligne de commande -k. Pour plus de détails,
+ consulter la page <a href="stopping.html">Arrêt et redémarrage</a>.</p>
+ </section>
+
+ <section id="scriptlog">
+ <title>Journal des scripts</title>
+
+ <p>Afin de faciliter le débogage, la directive
+ <directive module="mod_cgi">ScriptLog</directive> vous permet
+ d'enregistrer les entrées et sorties des scripts CGI. Elle ne doit être
+ utilisée que pendant la phase de test, et en aucun cas sur un
+ serveur en production. Vous trouverez plus d'informations dans la
+ documentation du module <a href="mod/mod_cgi.html">mod_cgi</a>.</p>
+ </section>
+
+ <section id="rewritelog">
+ <title>Journal de réécriture</title>
+
+ <p>Lorsqu'on utilise les fonctionnalités puissantes et complexes du
+ module <a href="mod/mod_rewrite.html">mod_rewrite</a>, il est presque
+ toujours nécessaire d'utiliser la directive
+ <directive module="mod_rewrite">RewriteLog</directive> afin de
+ faciliter le débogage. Ce fichier journal fournit une analyse détaillée
+ de la transformation des requêtes par le moteur de réécriture. Le niveau
+ de détail est contrôlé par la directive
+ <directive module="mod_rewrite">RewriteLogLevel</directive>.</p>
+ </section>
+ </section>
+</manualpage>
+
+
+
+