From: Vincent Deffontaines Date: Sun, 26 Oct 2008 16:38:53 +0000 (+0000) Subject: Adding .fr translations for suexec logs server-wide sections new_features_2_4 urlmapp... X-Git-Tag: 2.3.0~231 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=391e0a19779b399d42a55dfcd5a2823fdbc044ef;p=apache Adding .fr translations for suexec logs server-wide sections new_features_2_4 urlmapping dso upgrading glossary git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@708014 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/dso.xml.fr b/docs/manual/dso.xml.fr new file mode 100644 index 0000000000..9557fc38b4 --- /dev/null +++ b/docs/manual/dso.xml.fr @@ -0,0 +1,328 @@ + + + + + + + + + + + + Support des objets dynamiques partagés (DSO) + + +

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 httpd lors de la + compilation du serveur, soit compilés en tant qu'objets + dynamiques partagés (DSOs) qui existeront indépendamment du binaire + principal httpd. 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 (apxs), + et associés au serveur ultérieurement.

+ +

Ce document décrit l'utilisation des modules DSO ainsi que les dessous + de leur fonctionnement.

+ + + +
Implémentation + + + +mod_so + + +LoadModule + + + +

Le support DSO pour le chargement de modules individuels d'Apache est + assuré par un module nommé mod_so qui doit être compilé + statiquement dans le coeur d'Apache. Il s'agit du seul module avec le + module core à 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 + --enable-module=shared du script + configure, comme décrit dans la + Documentation de l'installation. 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 + LoadModule du module + mod_so, placée + dans votre fichier httpd.conf.

+ +

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é + apxs (APache + eXtenSion). On peut l'utiliser pour construire des modules de type + DSO en dehors de l'arborescence des sources d'Apache. L'idée est + simple : à l'installation d'Apache, la procédure make install + du script configure 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 + apxs, qui sera utilisé pour la construction de fichiers DSO. + Il est ainsi possible d'utiliser le programme apxs + 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.

+
+ +
Mode d'emploi succinct + +

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 :

+ +
    +
  1. + Construire et installer un module Apache faisant partie de la + distribution, par exemple mod_foo.c, + en tant que module DSO mod_foo.so : + + +$ ./configure --prefix=/chemin/vers/répertoire-installation +--enable-foo=shared
    +$ make install +     +
    2. + +
  2. + Construire et installer un module Apache tiers, par exemple + mod_foo.c, en tant que module DSO mod_foo.so : + + +$ ./configure --add-module=type_de_module: +/chemin/vers/module_tiers/mod_foo.c \
    + + --enable-foo=shared
    +     +$ make install +     +
    3. + +
  3. + Configurer Apache pour pouvoir installer ultérieurement des + modules partagés : + + +$ ./configure --enable-so
    +$ make install +     +
    4. + +
  4. + Construire et installer un module Apache tiers, par exemple + mod_foo.c, en tant que module DSO + mod_foo.so en dehors de l'arborescence des sources + d'Apache à l'aide du programme apxs : + + +$ cd /chemin/vers/module_tiers
    +$ apxs -c mod_foo.c
    +$ apxs -i -a -n foo mod_foo.la +     +
    5. +
+ +

Dans tous les cas, une fois le module partagé compilé, vous devez + ajouter une directive LoadModule + dans le fichier httpd.conf pour qu'Apache active le module.

+
+ +
Les dessous du fonctionnement des DSO + +

Les clônes modernes d'UNIX proposent un astucieux mécanisme + communément appelé édition de liens et chargement dynamiques d' + Objets Dynamiques Partagés (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.

+ +

Ce chargement peut s'effectuer de deux manières : automatiquement par + un programme système appelé ld.so 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 dlopen()/dlsym().

+ +

Dans la première méthode, les DSO sont en général appelés + bibliothèques partagées ou encore bibliothèques DSO, et + possèdent des noms du style + libfoo.so ou libfoo.so.1.2. Ils résident dans un + répertoire système (en général /usr/lib) + et le lien avec le programme exécutable est établi à la compilation en + ajoutant -lfoo à 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 libfoo.so dans + /usr/lib, dans des chemins codés en dur à l'aide d'options de + l'éditeur de liens comme -R ou dans des chemins définis par la + variable d'environnement + LD_LIBRARY_PATH. Le chargeur peut dès lors résoudre tous les symboles + (jusque là non encore résolus) du DSO dans le programme exécutable.

+ +

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 + ld.so 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 libc.so, ce qui permet + d'économiser de l'espace disque pour les autres programmes.

+ +

Dans la seconde méthode, les DSO sont en général appelés objets + partagés ou fichiers DSO, et peuvent être nommés avec + l'extension de son choix (bien que le nom conseillé soit du style + foo.so). 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 dlopen(). + 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 libc.so). + 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.

+ +

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 + dlsym() pour une utilisation ultérieure dans les tables de + distribution, etc... 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.

+ +

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.

+ +

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.

+ +

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, etc... 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.

+
+ +
Avantages et inconvénients + +

Les fonctionnalités ci-dessus basées sur les DSO présentent les + avantages suivants :

+ +
    +
  • Le paquetage du serveur est plus flexible à l'exécution car le + processus serveur effectif peut être assemblé à l'exécution via la + directive LoadModule du fichier de + configuration httpd.conf plutôt que par des options du script + configure à 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], etc...) à partir d'une seule installation + d'Apache.
    • + +
  • 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, + etc...
    • + +
  • Une facilité de prototypage des modules Apache car la paire + DSO/apxs 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 apxs -i + suivie d'un apachectl restart pour introduire une nouvelle + version de votre module fraîchement développé dans le serveur Apache + en cours d'exécution.
    • +
+ +

Inconvénients des DSO :

+ +
    +
  • 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.
    • + +
  • Le serveur est environ 20 % plus lent au démarrage + à cause des résolutions de symboles supplémentaires que le chargeur + Unix doit effectuer.
    • + +
  • 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.
    • + +
  • Comme les modules DSO ne peuvent pas être liés avec d'autres + bibliothèques basées sur DSO (ld -lfoo) 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 + (libc) et toutes autres bibliothèques statiques ou + dynamiques utilisées par le coeur d'Apache, ou d'archives statiques + (libfoo.a) 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 dlopen().
    • +
+ +
+ + diff --git a/docs/manual/glossary.xml.fr b/docs/manual/glossary.xml.fr new file mode 100644 index 0000000000..18942c030c --- /dev/null +++ b/docs/manual/glossary.xml.fr @@ -0,0 +1,567 @@ + + + + + + + + + + + + Glossaire + + +

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.

+ + +
Définitions + +
Algorithme
+ +
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 + Ciphers. +
+ +
Algorithme de chiffrement + (Cipher)
+
Un algorithme ou un système de chiffrement des données. + Quelques exemples : DES, IDEA, RC4, etc.
+ Voir : chiffrement SSL/TLS +
+ +
Archive Tar (Tarball)
+
Un paquetage de fichiers rassemblés dans une archive + à l'aide de l'utilitaire tar. + Les distributions d'Apache sont stockées dans des Archives Tar compressées + ou en utilisant pkzip. +
+ +
Authentification
+
L'identification formelle d'une entité du réseau comme un serveur, un + client, ou un utilisateur.
+ Voir : Authentification, Autorisation, et + contrôle d'accès +
+ +
Autorité de Certification + (Certification Authority) + (CA)
+
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.
+ Voir : chiffrement SSL/TLS +
+ + +
Certificat (Certificate)
+
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'Autorité de Certification + (Certification Authority) ou CA signataire (appelée + le fournisseur/issuer), ainsi que la + clé publique (public + key) 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.
+ Voir : chiffrement SSL/TLS +
+ +
Chiffrement à Clé Publique + (Public Key Cryptography)
+
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. +
+ Voir : chiffrement SSL/TLS +
+ +
Clé Privée (Private Key)
+
La clé secrète dans un système de + chiffrement à clé publique, + utilisée pour déchiffrer les messages entrants et signer + les messages sortants.
+ Voir : chiffrement SSL/TLS +
+ +
Clé Publique (Public Key)
+
La clé accessible au public dans un système de Chiffrement à clé publique, + utilisée pour chiffrer les messages destinés uniquement à son + propriétaire et déchiffrer les signatures + faites par son propriétaire.
+ Voir : chiffrement SSL/TLS +
+ +
CONNECT
+
Une méthode HTTP pour encapsuler + des données brutes dans HTTP. Elle peut aussi être utilisée pour encapsuler + d'autres protocoles, comme le protocole SSL. +
+ +
Contexte (Context)
+
Une portion des + fichiers de configuration dans laquelle certains types de + directives sont autorisés.
+ Voir : Termes utilisés + pour décrire les directives d'Apache +
+ +
+
Contrôle d'accès + (Access Control)
+
La restriction d'accès à des zones du réseau. Habituellement + dans un contexte Apache, + la restriction d'accès à certaines URLs.
+ Voir : Authentification, Autorisation et + Contrôle d'accès +
+ +
+ Couche des Points de connexion Sécurisés + (Secure Sockets Layer) + (SSL)
+
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 HTTPS, autrement dit + le Protocole de Transfert Hypertexte (HTTP) au dessus de SSL.
+ Voir : chiffrement SSL/TLS +
+ +
+ Cryptographie Symétrique (Symmetric Cryptography)
+
L'étude et l'application des Algorithmes de chiffrement qui + utilisent une clé secrète unique pour les opérations de chiffrement et de + déchiffrement.
+ Voir : chiffrement SSL/TLS +
+ + +
+ Dégradé pour l'exportation + (Export-Crippled)
+
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 + Texte crypté qui peut en général être décrypté + par force brute.
+ Voir : chiffrement SSL/TLS +
+ + +
Demande de signature de certificat + (Certificate Signing Request) + (CSR)
+
La soumission d'un certificat + non signé à une Autorité de + certification, qui le signe avec la Clé privée de leur + Certificat de CA. Une fois le CSR signé, il devient un vrai + certificat.
+ Voir : chiffrement SSL/TLS +
+ +
Directive
+
Une commande de configuration qui contrôle un ou plusieurs aspects du + comportement d'Apache. Les directives sont placées dans le Fichier de configuration
+ Voir : Index des directives +
+ +
Directive de configuration + (Configuration Directive)
+
Voir : Directive
+ +
En-tête (Header)
+
La partie de la requête et de la réponse + HTTP qui est envoyée avant le contenu + proprement dit, et contient des méta-informations décrivant le contenu. +
+ +
Expression Rationnelle + (Regular Expression) + (Regex)
+
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 + "/images/.*(jpg|gif)$". Apache utilise les Expressions + Rationnelles Compatibles avec Perl fournies par la librairie PCRE. +
+ +
+ Fichier de configuration + (Configuration File)
+
Un fichier texte contenant des + Directives + qui contrôlent la configuration d'Apache.
+ Voir : Fichiers de configuration +
+ +
Filtre (Filter)
+
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 + INCLUDES + traite les documents pour les + Server Side Includes (Inclusions côté Serveur) + .
+ Voir : Filtres +
+ +
Gestionnaire (Handler)
+
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 + cgi-script désigne les fichiers qui doivent être traités + comme CGIs.
+ Voir : Utilisation des gestionnaires d'Apache +
+ +
Hachage (Hash)
+
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). +
+ +
Hébergement Virtuel + (Virtual Hosting)
+
Servir des sites web multiples en utilisant une seule instance d'Apache. + Les Hôtes virtuels basés sur IP différencient les sites web en se + basant sur leur adresse IP, alors que les + Hôtes virtuels basés sur le nom utilisent uniquement le nom d'hôte + et peuvent en conséquence héberger de nombreux sites avec la même + adresse IP.
+ Voir la Documentation des Hôtes Virtuels d'Apache +
+ + +
.htaccess
+
Un fichier de configuration + placé à un certain niveau de l'arborescence du site web, et appliquant des + directives 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.
+ Voir : Fichiers de configuration +
+ +
httpd.conf
+
Le fichier de configuration + principal d'Apache. Sa localisation par défaut est + /usr/local/apache2/conf/httpd.conf, mais ceci peut être + changé en utilisant des options de compilation ou d'exécution.
+ Voir : Fichiers de configuration +
+ +
HTTPS
+
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 + SSL.
+ Voir : chiffrement SSL/TLS +
+ +
Identificateur de Ressource Uniformisé + (Uniform Resource Identifier) + (URI)
+
Une chaîne de caractères compacte servant à identifier une ressource + abstraite ou physique. Elle est formellement définie par la RFC 2396. Les URIs + utilisées sur le world-wide web sont souvent appelées URLs. +
+ +
+ Inclusions Côté Serveur + (Server Side Includes) (SSI) +
+
Une technique permettant d'englober des directives de traitement dans + des fichiers HTML.
+ Voir : Introduction aux Inclusions Côté Serveur +
+ +
+Interface commune avec les programmes externes +(Common Gateway Interface) + (CGI)
+
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 NCSA mais il + existe aussi le projet + RFC project.
+ Voir : Contenu dynamique avec CGI +
+ + +
Bibliothèques pour la portabilité d'Apache + (Apache Portable Runtime) (APR)
+
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.
+ Voir : Apache Portable Runtime + Project +
+
+Localisation de Ressource Uniformisée +(Uniform Resource Locator) + (URL)
+
Le nom/adresse d'une ressource sur l'Internet. Il s'agit du terme + informel commun pour ce qui est formellement défini comme + Identificateur de Ressource Uniformisé. + Les URLs sont généralement construites selon un schéma, comme + http ou + https, un nom d'hôte, et un chemin. Une URL pour cette page + pourrait être + http://httpd.apache.org/docs/&httpd.docs;/glossary.html. +
+ + +
Mandataire (Proxy)
+
Un serveur intermédiaire qui se situe entre le client et le + serveur d'origine. + 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.
+ Voir : mod_proxy +
+ +
Mandataire inverse + (Reverse Proxy)
+
Un serveur mandataire qui est vu du client + comme un serveur d'origine. 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. +
+ +
Méthode (Method)
+
Dans le contexte HTTP, 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 + GET, POST, + et PUT. +
+ +
Module
+
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 + httpd sont appelés modules statiques, alors + que les modules qui existent séparément et peuvent être chargés + optionnellement à l'exécution sont appelés + modules dynamiques ou DSOs. + Les modules qui sont inclus par défaut sont appelés + modules de base. De nombreux modules disponibles pour Apache + ne se trouvent pas dans l'archive + du Serveur HTTP Apache . Il sont appelés + modules tiers.
+ Voir : Index des modules +
+ +
Mot de Passe (Pass Phrase)
+
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 Algorithmes de chiffrement.
+ Voir : chiffrement SSL/TLS +
+ +
Nom de domaine entièrement qualifié + (Fully-Qualified Domain-Name) + (FQDN)
+
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, + www est un nom d'hôte, example.com est un nom + de domaine, et www.example.com est un nom de domaine + entièrement qualifié. +
+ +
+ Nombre Magique des Modules + (Module Magic Number) + (MMN)
+
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. +
+ +
+ Objet Dynamique Partagé (Dynamic Shared Object) + (DSO)
+
Modules compilés en dehors du binaire + Apache httpd et qui peuvent être + chargés à la demande.
+ Voir : Support des objets dynamiques partagés +
+ +
OpenSSL
+
L'ensemble d'outils Open Source pour SSL/TLS
+ Voir http://www.openssl.org/# +
+ +
+ Outil de gestion des extensions Apache + (APache eXtension Tool) + (apxs)
+
Un script Perl qui aide à la compilation des sources de module sous forme d'Objets Dynamiques Partagés + (Dynamic Shared Objects ou + DSOs) et facilite leur installation + dans le serveur Web Apache.
+ Voir : Page de manuel : apxs +
+ +
Plein Texte (Plaintext)
+
Le texte non chiffré.
+ + + +
Protocole de Transfert Hypertexte + (HyperText Transfer Protocol) + (HTTP)
+
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 + RFC 2616. +
+ +
Résumé de message + (Message Digest)
+
Un hachage du message, qui peut être utilisé pour vérifier + que son contenu n'a pas été altéré durant le transfert.
+ Voir : chiffrement SSL/TLS +
+ +
+ Sécurité de la couche Transport + (Transport Layer Security) + (TLS)
+
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.
+ Voir : chiffrement SSL/TLS +
+ +
Session
+
Les informations sur le contexte d'une communication en général.
+ +
Signature numérique + (Digital Signature)
+
Un bloc de texte crypté qui valide un certificat ou un autre fichier. + Une Autorité de certification + crée une signature en générant une empreinte de la Clé publique + fournie avec le Certificat; la CA chiffre ensuite l'empreinte + avec sa propre Clé privée. 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 + Certificat.
+ Voir : chiffrement SSL/TLS +
+ +
SSLeay
+
La bibliothèque originelle d'implémentation de SSL/TLS développée par + Eric A. Young +
+ +
Texte crypté +(Ciphertext)
+
Le résultat du passage d'un document + Plaintext (Plein texte) par un + Cipher.
+ Voir : chiffrement SSL/TLS +
+ +
Type MIME (MIME-type)
+
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 text/html, + image/gif, et application/octet-stream. Dans + HTTP, le type MIME est transmis dans l' + en-tête Content-Type.
+ Voir : mod_mime +
+ + +
+ Variable d'environnement + (Environment Variable) (env-variable)
+
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.
+ Voir : Les variables d'environnement dans Apache +
+ +
X.509
+
Une norme de certificat d'authentification recommandée par l'International + Telecommunication Union (ITU-T) et utilisée pour + l'authentification SSL/TLS.
Voir : chiffrement SSL/TLS +
+
+
+ + + diff --git a/docs/manual/logs.xml.fr b/docs/manual/logs.xml.fr new file mode 100644 index 0000000000..e57f7742d8 --- /dev/null +++ b/docs/manual/logs.xml.fr @@ -0,0 +1,669 @@ + + + + + + + + + + + + Fichiers journaux + + +

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.

+ + +
+ Avertissement à propos de la sécurité + +

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 PAS 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 conseils sur la sécurité + pour plus de détails.

+ +

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.

+
+ +
+ Journal des erreurs + + + + ErrorLog + LogLevel + + + +

Le journal des erreurs du serveur, dont le nom et la localisation sont + définis par la directive ErrorLog, + 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.

+ +

Le journal des erreurs est habituellement enregistré dans un fichier + (en général error_log sur les systèmes de type Unix et + error.log sur Windows et OS/2). Sur les systèmes de type Unix, + le serveur peut aussi enregistrer ses erreurs dans + syslog ou les + rediriger vers un programme par l'intermédiaire d'un + tube de communication (pipe).

+ +

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 :

+ + + [Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] + client denied by server configuration: + /export/home/live/ap/htdocs/test + + +

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 LogLevel 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).

+ +

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 stderr sera recopiée + telle quelle dans le journal des erreurs.

+ +

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 journal des accès. 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.

+ +

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 :

+ + + tail -f error_log + +
+ +
+ Journal des accès + + + + mod_log_config + mod_setenvif + + + CustomLog + LogFormat + SetEnvIf + + + +

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 CustomLog. + La directive LogFormat + 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.

+ +

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 à Open Directory ou + Yahoo.

+ +

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 + TransferLog. La directive + CustomLog rassemble + désormais les fonctionnalités de toutes les anciennes directives.

+ +

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 + chaînes de format de la + documentation du module mod_log_config.

+ +
+ Format habituel du journal + +

Voici une configuration typique pour le journal des accès :

+ + + LogFormat "%h %l %u %t \"%r\" %>s %b" common
+ CustomLog logs/access_log common + + +

Ici est définie l'identité common 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 (") doivent être échappées en les faisant + précéder d'un anti-slash (\) 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 + "\n" et "\t" pour insérer respectivement + un passage à la ligne et une tabulation.

+ +

La directive CustomLog + 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 + ServerRoot, sauf s'il + débute par un slash.

+ +

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 :

+ + + 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET + /apache_pb.gif HTTP/1.0" 200 2326 + + +

Chaque partie de cette entrée de journal est décrite + dans ce qui suit.

+ +
+
127.0.0.1 (%h)
+ +
Il s'agit de l'adresse IP du client (l'hôte distant) qui a envoyé + la requête au serveur. Si la directive + HostnameLookups est positionnée à + On, 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 logresolve + 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.
+ +
- (%l)
+ +
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 identd 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 + IdentityCheck est positionnée + à On.
+ +
frank (%u)
+ +
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 + REMOTE_USER. 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 + "-", comme la partie précédente.
+ +
[10/Oct/2000:13:55:36 -0700] + (%t)
+ +
+ L'heure à laquelle la requête a été reçue. + Le format est le suivant : + +

+ [jour/mois/année:heure:minutes:secondes zone]
+ jour = 2*chiffre
+ mois = 3*lettre
+ année = 4*chiffre
+ heure = 2*chiffre
+ minutes = 2*chiffre
+ secondes = 2*chiffre
+ zone = (`+' | `-') 4*chiffre +

Il est possible de modifier le format d'affichage de l'heure + en spécifiant %{format}t dans la chaîne de format du + journal, où format est une chaîne de format de même + forme que celle de la fonction strftime(3) de la + bibliothèque C standard. +
+ +
"GET /apache_pb.gif HTTP/1.0" + (\"%r\")
+ +
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 GET. Ensuite, le + client a demandé la ressource /apache_pb.gif, et enfin, + le client a utilisé le protocole HTTP/1.0. Il est aussi + possible d'enregistrer séparément une ou plusieurs parties de la + requête. Par exemple, la chaîne de format "%m %U %q %H" + 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 + "%r".
+ +
200 (%>s)
+ +
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 specification HTTP (RFC2616 section 10).
+ +
2326 (%b)
+ +
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 "-". Pour indiquer l'absence de contenu + par "0", utilisez %B au lieu de + %b.
+
+
+ +
+ Combined Log Format (Format de journalisation combiné) + +

Une autre chaîne de format couramment utilisée est le + "Combined Log Format" (Format de journalisation combiné). Il s'utilise + comme suit :

+ + + LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" + \"%{User-agent}i\"" combined
+ CustomLog log/access_log combined + + +

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 "%" %{header}i, + où header 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 :

+ + + 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)" + + +

Les champs supplémentaires sont :

+ +
+
"http://www.example.com/start.html" + (\"%{Referer}i\")
+ +
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 /apache_pb.gif ou + inclut ce dernier fichier).
+ +
"Mozilla/4.08 [en] (Win98; I ;Nav)" + (\"%{User-agent}i\")
+ +
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.
+
+
+ +
+ Journaux d'accès multiples + +

Plusieurs journaux d'accès peuvent être créés en spécifiant tout + simplement plusieurs directives + CustomLog 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 + CustomLog montrent + comment simuler les effets des directives ReferLog et + AgentLog.

+ + + LogFormat "%h %l %u %t \"%r\" %>s %b" common
+ CustomLog logs/access_log common
+ CustomLog logs/referer_log "%{Referer}i -> %U"
+ CustomLog logs/agent_log "%{User-agent}i" + + +

Cet exemple montre aussi qu'il n'est pas obligatoire d'associer + une chaîne de format à un alias au moyen de la directive + LogFormat. Elle peut + être définie directement dans la ligne de la directive + CustomLog.

+
+ +
+ Journalisation conditionnelle + +

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 + variables d'environnement. 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 SetEnvIf, + puis la clause env= de la directive + CustomLog pour inclure + ou exclure les requêtes pour lesquelles + la variable d'environnement est définie. + Quelques exemples :

+ + + # Marque les requêtes en provenance de l'interface loop-back
+ SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
+ # Marque les requêtes pour le fichier robots.txt
+ SetEnvIf Request_URI "^/robots\.txt$" dontlog
+ # Journalise toutes les autres requêtes
+ CustomLog logs/access_log common env=!dontlog + + +

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.

+ + + SetEnvIf Accept-Language "en" english
+ CustomLog logs/english_log common env=english
+ CustomLog logs/non_english_log common env=!english + + +

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.

+
+
+ +
+ Rotation des journaux + +

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 + redémarré après le déplacement ou la + suppression des fichiers journaux de façon à ce qu'il en ouvre + de nouveaux.

+ +

Avec un redémarrage graceful, 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 :

+ + + mv access_log access_log.old
+ mv error_log error_log.old
+ apachectl graceful
+ sleep 600
+ gzip access_log.old error_log.old + + +

La section suivante présente une autre méthode de rotation des journaux + qui consiste à utiliser les + journaux redirigés.

+
+ +
+ Journaux redirigés + +

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 "|", 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é.)

+ +

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.

+ +

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é rotatelogs. Par exemple, pour une rotation des + journaux toutes les 24 heures, ajoutez ces lignes :

+ + + CustomLog "|/usr/local/apache/bin/rotatelogs + /var/log/access_log 86400" common + + +

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.

+ +

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 ici.

+ +

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.

+
+ +
+ Hôtes virtuels + +

Lorsqu'un serveur possède plusieurs hôtes virtuels, 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 + VirtualHost 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.

+ +

Si des directives CustomLog ou + ErrorLog sont placées dans une section + VirtualHost, 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 nombre de descripteurs + de fichiers insuffisant peuvent rapidement apparaître.

+ +

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 :

+ + + LogFormat "%v %l %u %t \"%r\" %>s %b" + comonvhost
+ CustomLog logs/access_log comonvhost + + +

Le champ %v sert à enregistrer le nom de l'hôte virtuel qui + traite la requête. Un programme tel que split-logfile peut ensuite être utilisé + pour générer "à froid" autant de journaux que d'hôtes virtuels.

+
+ +
+ Autres fichiers journaux + + + + mod_logio + mod_log_forensic + mod_cgi + mod_rewrite + + + LogFormat + ForensicLog + PidFile + RewriteLog + RewriteLogLevel + ScriptLog + ScriptLogBuffer + ScriptLogLength + + + +
+ Enregistrement du nombre réel d'octets envoyés et reçus + +

Le module mod_logio fournit deux champs + LogFormat supplémentaires + (%I et %O) qui permettent d'enregistrer le nombre réel d'octets reçus et + envoyés sur le réseau.

+
+ +
+ Journalisation de style investigation judiciaire (forensic logging) + +

Le module mod_log_forensic 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é.

+
+ +
+ Fichier PID + +

Au démarrage, le démon httpd Apache enregistre l'identifiant du + processus httpd parent dans le fichier logs/httpd.pid. + Le nom de ce fichier peut être modifié à l'aide de la directive + PidFile. 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 Arrêt et redémarrage.

+
+ +
+ Journal des scripts + +

Afin de faciliter le débogage, la directive + ScriptLog 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 mod_cgi.

+
+ +
+ Journal de réécriture + +

Lorsqu'on utilise les fonctionnalités puissantes et complexes du + module mod_rewrite, il est presque + toujours nécessaire d'utiliser la directive + RewriteLog 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 + RewriteLogLevel.

+
+
+ + + + + diff --git a/docs/manual/new_features_2_4.xml.fr b/docs/manual/new_features_2_4.xml.fr new file mode 100644 index 0000000000..aa80460103 --- /dev/null +++ b/docs/manual/new_features_2_4.xml.fr @@ -0,0 +1,77 @@ + + + + + + + + + + + +Vue d'ensemble des nouvelles fonctionnalités d'Apache 2.4 + + +

Ce document décrit certaines modifications majeures entre les versions + 2.2 et 2.4 du serveur HTTP Apache. Pour les nouvelles fonctionnalités + ajoutées depuis la version 2.0, se référer au document + nouvelles fonctionnalités + de la version 2.2.

+ + +
+ Améliorations du noyau + +
+ +
+ Améliorations des modules + +
+ +
+ Améliorations des programmes + +
+ +
+ Modifications pour le développeur de modules +
+
Ajout de code pour la vérification de la configuration
+ +
Une nouvelle fonction, check_config, a été ajoutée et + s'exécute entre les fonctions pre_config et + open_logs. Elle s'exécute aussi avant la fonction + test_config si l'option -t est passée au + démon httpd. La fonction check_config + permet aux modules de vérifier l'interdépendance des valeurs des + directives de configuration et d'ajuster ces valeurs, alors que les + messages du serveur peuvent encore être affichés sur la console. + L'utilisateur est ainsi averti des erreurs de configuration avant que la + fonction du noyau open_logs ne redirige les sorties de la + console vers le journal des erreurs.
+
Ajout d'un analyseur syntaxique d'expressions
+
Nous disposons à présent d'un analyseur générique d'expressions, dont l'API + est décrite dans ap_expr.h. Il s'agit d'une adaptation de + l'analyseur qu'on trouvait auparavant dans mod_include.
+
+
+ diff --git a/docs/manual/sections.xml.fr b/docs/manual/sections.xml.fr new file mode 100644 index 0000000000..920448cf9c --- /dev/null +++ b/docs/manual/sections.xml.fr @@ -0,0 +1,564 @@ + + + + + + + + + + + +Sections de configuration + +

Les directives des fichiers de configuration peuvent s'appliquer +au serveur dans son ensemble, ou seulement à des répertoires, fichiers, hôtes, +ou URLs particuliers. Ce document décrit comment utiliser les conteneurs de +sections de configuration ou les fichiers .htaccess pour +modifier la portée des directives de configuration.

+ + +
Types de conteneurs de sections de +configuration + + + +core +mod_version +mod_proxy + + +Directory +DirectoryMatch +Files +FilesMatch +IfDefine +IfModule +IfVersion +Location +LocationMatch +Proxy +ProxyMatch +VirtualHost + + + +

Il existe deux grands types de conteneurs. La plupart des conteneurs sont +évalués pour chaque requête. Les directives qu'ils contiennent s'appliquent +seulement aux requêtes qui sont concernées par le conteneur. En revanche, +les conteneurs +IfDefine, IfModule, et +IfVersion sont +évalués seulement au démarrage et au redémarrage du serveur. +Si leurs conditions sont vérifiées au démarrage, les directives qu'ils contiennent +s'appliqueront à toutes les requêtes. Si leurs conditions ne sont pas vérifiées, les +directives qu'ils contiennent seront ignorées.

+ +

Le conteneur IfDefine +contient des directives qui ne seront appliquées que si un paramètre +approprié a été défini dans la ligne de commande de httpd. +Par exemple, +avec la configuration suivante, toutes les requêtes seront redirigées vers +un autre site si le serveur est démarré en utilisant la ligne de commande : +httpd -DClosedForNow:

+ + +<IfDefine ClosedForNow>
+Redirect / http://otherserver.example.com/
+</IfDefine> + + +

Le conteneur IfModule +est similaire; les directives qu'il contient ne s'appliqueront que si +un module particulier est disponible au niveau du serveur. +Le module doit être soit compilé statiquement dans le serveur, soit +dynamiquement et dans ce cas, la ligne LoadModule correspondante doit apparaître +plus haut dans le fichier de configuration. Ce conteneur ne doit être +utilisé que dans le cas où votre fichier de configuration doit fonctionner +indépendamment de la présence ou de l'absence de certains modules. +Il ne doit pas contenir de directives que vous souhaitez voir s'appliquer +systématiquement, car vous pouvez perdre ainsi de précieux messages d'erreur +à propos de modules manquants.

+ +

Dans l'exemple suivant, la directive MimeMagicFiles ne s'appliquera que si le +module mod_mime_magic est disponible.

+ + +<IfModule mod_mime_magic.c>
+MimeMagicFile conf/magic
+</IfModule> + + +

Le conteneur +IfVersion +est similaire aux conteneurs IfDefine et IfModule; les directives qu'il contient ne +s'appliqueront que si une version particulière du serveur s'exécute. Ce +conteneur a été conçu pour une utilisation dans les suites de tests +et les grands réseaux qui doivent prendre en compte différentes versions +et configurations de httpd.

+ + + <IfVersion >= 2.1>
+ + # les directives situées ici ne s'appliquent que si la version
+ # est supérieure ou égale à 2.1.0.
+ + </IfVersion> + + +

IfDefine, +IfModule, et +IfVersion +peuvent inverser leur test conditionnel en le faisant précéder d'un "!". +De plus, ces sections peuvent être imbriquées afin de définir des restrictions +plus complexes.

+
+ +
Système de fichiers et +arborescence du site web + +

Les conteneurs de sections de configuration les plus couramment utilisés +sont ceux qui modifient la configuration de points particuliers du système de +fichiers ou de l'arborescence du site web. Tout d'abord, il est important de +comprendre la différence entre les deux. Le système de fichiers est une vue +de vos disques tels qu'ils sont perçus par votre système d'exploitation. +Par exemple, avec une installation par défaut, +Apache est situé dans /usr/local/apache2 pour le système de +fichiers UNIX, ou "c:/Program Files/Apache Group/Apache2" pour +le système de fichiers Windows. (Notez que des slashes directs doivent +toujours être utilisés comme séparateur de chemin dans Apache, même sous +Windows.) Quant à +l'arborescence du site web, il s'agit d'une vue de votre site +tel que présenté par le +serveur web et perçue par le client. Ainsi le chemin /dir/ dans +l'arborescence du site web correspond au chemin +/usr/local/apache2/htdocs/dir/ dans le système de fichiers pour +une installation d'Apache par défaut sous UNIX. +En outre, l'arborescence du site web n'a pas besoin de correspondre en permanence au +système de fichiers, car les pages web peuvent être générées dynamiquement +à partir de bases de données ou d'autres emplacements.

+ +
Conteneurs de système de fichiers + +

Les conteneurs Directory +et Files, +ainsi que leurs équivalents acceptant les +expressions rationnelles, +appliquent des directives à certaines parties du système de fichiers. +Les directives contenues dans une section Directory s'appliquent au répertoire +précisé, ainsi qu'à tous ses sous-répertoires. +Le même effet peut être obtenu en utilisant les fichiers .htaccess. Par exemple, avec la +configuration suivante, l'indexation sera activée pour le répertoire +/var/web/dir1 et tous ses sous-répertoires.

+ + +<Directory /var/web/dir1>
+Options +Indexes
+</Directory> + + +

Les directives contenues dans une section Files s'appliquent à tout fichier +avec le nom spécifié, quel que soit le répertoire dans lequel il se trouve. +Ainsi par exemple, les directives de configuration suivantes, si elles sont +placées dans la section principale du fichier de configuration, vont interdire +l'accès à tout fichier nommé private.html quel que soit +l'endroit où il se trouve.

+ + +<Files private.html>
+Order allow,deny
+Deny from all
+</Files> + + +

Pour faire référence à des fichiers qui se trouvent en des points +particuliers du système de fichiers, les sections +Files et +Directory +peuvent être combinées. Par exemple, la configuration suivante va interdire +l'accès à /var/web/dir1/private.html, +/var/web/dir1/subdir2/private.html, +/var/web/dir1/subdir3/private.html, ainsi que toute instance de +private.html qui se trouve dans l'arborescence +/var/web/dir1/.

+ + +<Directory /var/web/dir1>
+<Files private.html>
+Order allow,deny
+Deny from all
+</Files>
+</Directory> + +
+ +
Conteneurs de l'arborescence du site web + +

le conteneur Location +et son équivalent acceptant les +expressions rationnelles, modifient quant à eux la +configuration de parties de l'arborescence du site web. Par exemple, la +configuration suivante interdit l'accès à toute URL dont la partie chemin +commence par /private. +En particulier, l'interdiction s'appliquera aux requêtes pour : +http://yoursite.example.com/private, +http://yoursite.example.com/private123, et +http://yoursite.example.com/private/dir/file.html ainsi qu'à +toute requête commençant par la chaîne de caractères /private.

+ + +<Location /private>
+Order Allow,Deny
+Deny from all
+</Location> + + +

Le conteneur Location +n'a pas besoin de faire référence à un élément du système de fichiers. +Par exemple, l'exemple suivant montre comment faire référence à une URL +particulière vers un gestionnaire interne d'Apache fourni par le module +mod_status. +Il n'est pas nécessaire de trouver un fichier nommé server-status +dans le système de fichiers.

+ + +<Location /server-status>
+SetHandler server-status
+</Location> + +
+ +
Caractères de remplacement +et expressions rationnelles + +

Les conteneurs +Directory, +Files, et +Location +peuvent utiliser des caractères de remplacement de style shell comme dans +la fonction fnmatch de la bibliothèque C standard. +Le caractère "*" +correspond à toute séquence de caractères, "?" à un caractère seul, +et "[seq]" à tout caractère contenu dans seq. +Le caractère "/" +ne peut pas faire l'objet d'un remplacement; +il doit être spécifié explicitement.

+ +

Si une définition des critères de correspondance +encore plus souple est nécessaire, chaque conteneur +possède son équivalent acceptant les expressions rationnelles : DirectoryMatch, FilesMatch, et LocationMatch acceptent les +expressions rationnelles compatibles Perl +pour définir les critères de correspondance. Mais voyez plus loin la section +à propos de la combinaison des sections de configuration +pour comprendre comment l'utilisation de +conteneurs avec des expressions rationnelles va modifier la manière +dont les directives sont appliquées.

+ +

Un conteneur qui modifie la configuration de tous les +répertoires utilisateurs à l'aide de caractères de remplacement +mais sans utiliser +les expressions rationnelles pourrait ressembler à ceci :

+ + +<Directory /home/*/public_html>
+Options Indexes
+</Directory> + + +

Avec les conteneurs utilisant les expressions rationnelles, +on peut interdire l'accès à de nombreux types de fichiers d'images +simultanément :

+ +<FilesMatch \.(?i:gif|jpe?g|png)$>
+Order allow,deny
+Deny from all
+</FilesMatch> + + +
+ +
Que faut-il utiliser et quand ? + +

Choisir entre des conteneurs de système de fichiers et des conteneurs +d'arborescence du site web est vraiment très simple. +Pour appliquer des directives à des objets qui résident dans le système de +fichiers, utilisez toujours un conteneur Directory ou Files. Pour appliquer des directives à des objets +qui ne résident pas dans le système de fichiers (comme une page web générée +par une base de données), utilisez un conteneur Location.

+ +

Il ne faut jamais utiliser un conteneur Location pour restreindre l'accès à des +objets du système de fichiers, car plusieurs localisations de +l'arborescence du site web (URLs) peuvent correspondre à la même localisation +du système de fichier, ce qui peut permettre de contourner vos restrictions. +Par exemple, imaginez la configuration suivante :

+ + +<Location /dir/>
+Order allow,deny
+Deny from all
+</Location> + + +

Elle fonctionne correctement si la requête appelle +http://yoursite.example.com/dir/. Mais que va-t-il se passer si +votre système de fichiers est insensible à la casse ? +Votre restriction va pouvoir être tout simplement contournée en envoyant une +requête sur +http://yoursite.example.com/DIR/. Le conteneur Directory, quant à lui, s'appliquera +à tout contenu servi à partir de cette localisation, +sans tenir compte de la manière dont il est appelé. +(Les liens du système de fichiers constituent une exception. +Le même répertoire peut être placé dans plusieurs parties du système de +fichiers en utilisant des liens symboliques. Le conteneur +Directory va suivre le +lien symbolique sans modifier le nom du chemin. Par conséquent, pour plus de +sécurité, les liens symboliques doivent être désactivés à l'aide de la +directive +Options appropriée.)

+ +

Si vous pensez que vous n'êtes pas concerné par ce problème +parceque vous utilisez un système de fichiers sensible à la casse, +gardez à l'esprit qu'il y a de nombreuses autres manières pour faire +correspondre plusieurs localisations de l'arborescence du site web à la même +localisation du système de fichiers. C'est pourquoi vous devez autant que +possible toujours utiliser les conteneurs de système de fichiers. +Il y a cependant une exception à cette règle. Placer des restrictions de +configuration dans un conteneur <Location +/> est tout à fait sans rique car ce conteneur va s'appliquer à +toutes les requêtes sans tenir compte de l'URL spécifique.

+
+ +
+ +
Hôtes virtuels + +

Le conteneur VirtualHost +contient des directives qui s'appliquent à des hôtes spécifiques. +Ceci s'avère utile pour servir des hôtes multiples à partir de la même machine, +chacun d'entre eux possédant une configuration différente. Pour de plus amples +informations, +voir la Documentation sur les hôtes virtuels.

+
+ +
Mandataire + +

Les conteneurs +Proxy +et ProxyMatch +appliquent les directives de configuration qu'ils contiennent uniquement aux +sites qui correspondent à l'URL spécifiée et auxquels on a +accédé via le serveur mandataire du module mod_proxy. +Par exemple, la configuration suivante +va interdire l'utilisation du serveur proxy pour accéder au site +cnn.com.

+ + +<Proxy http://cnn.com/*>
+Order allow,deny
+Deny from all
+</Proxy> + +
+ +
Quelles sont les directives autorisées ? + +

Pour déterminer quelles sont les directives autorisées pour tel type de +section de configuration, vérifiez le Contexte de la directive. +Tout ce qui est autorisé dans les sections +Directory +l'est aussi d'un point de vue syntaxique dans les sections +DirectoryMatch, +Files, +FilesMatch, +Location, +LocationMatch, +Proxy, +et ProxyMatch. +Il y a cependant quelques exceptions :

+ +
    +
  • La directive AllowOverride +ne fonctionne que dans les sections +Directory.
    • + +
  • Les Options FollowSymLinks et +SymLinksIfOwnerMatch ne fonctionnent que dans les sections +Directory ou les fichiers +.htaccess.
    • + +
  • La directive Options ne peut pas être +utilisée dans les sections +Files +et FilesMatch.
    • +
+
+ +
Comment les sections sont combinées entre elles + +

Les sections de configuration sont appliquées dans un ordre très particulier. +Il est important de savoir comment cet ordre est défini car il peut avoir +des effets importants sur la manière dont les directives de configuration +sont interprétées.

+ +

L'ordre dans lequel les sections sont combinées est :

+ +
    +
  1. Les sections Directory (à l'exception des + expressions rationnelles) + et les fichiers .htaccess sont appliqués simultanément (avec + la possibilité pour .htaccess, s'il y est autorisé, de + prévaloir sur + Directory)
    2. + +
  2. Les sections + DirectoryMatch + (et <Directory ~>)
    3. + +
  3. Les sections Files et FilesMatch sont appliquées + simultanément
    4. + +
  4. Les sections + Location + et LocationMatch sont appliquées + simultanément
    5. +
+ +

Mises à part les sections Directory, chaque groupe est traité selon + l'ordre dans lequel il apparaît dans les fichiers de configuration. + Les sections Directory (groupe 1 ci-dessus) + sont traitées dans l'ordre du répertoire le plus court vers le plus long. + Par exemple, <Directory /var/web/dir> sera + traité avant <Directory + /var/web/dir/subdir>. Si plusieurs sections Directory s'appliquent au même + répertoire, elles sont traitées selon l'ordre dans lequel elles + apparaissent dans le fichier de configuration. + Les sections de configuration incluses via la directive Include sont traitées comme si elles se + trouvaient réellement dans le fichier qui les inclut à la position de la + directive + Include.

+ +

Les sections situées à l'intérieur de sections VirtualHost + sont appliquées après les sections correspondantes situées en + dehors de la définition de l'hôte virtuel, ce qui permet à l'hôte virtuel + de prévaloir sur la configuration du serveur principal.

+ +

Quand la requête est servie par le module mod_proxy, + le conteneur Proxy + prend la place du conteneur Directory dans l'ordre de traitement.

+ +

Les sections situées plus loin dans le fichier de configuration prévalent + sur celles qui les précèdent.

+ +Note technique + Une séquence + <Location>/<LocationMatch> + est réellement traitée juste avant la phase de traduction du nom + (où Aliases et DocumentRoots + sont utilisés pour faire correspondre les URLs aux noms de fichiers). + Les effets de cette séquence disparaissent totalement lorsque + la traduction est terminée. + + +
Quelques exemples + +

Voici un exemple imaginaire qui montre l'ordre de combinaison des sections. +En supposant qu'elles s'appliquent toutes à la requête, les directives de +cet exemple seront appliquées dans l'ordre suivant : A > B > C > D > +E.

+ + +<Location />
+E
+</Location>
+
+<Files f.html>
+D
+</Files>
+
+<VirtualHost *>
+<Directory /a/b>
+B
+</Directory>
+</VirtualHost>
+
+<DirectoryMatch "^.*b$">
+C
+</DirectoryMatch>
+
+<Directory /a/b>
+A
+</Directory>
+
+ + +

Pour un exemple plus concret, considérez ce qui suit. Sans tenir compte +de toute restriction d'accès placée dans les sections Directory, la section Location sera +évaluée en dernier et permettra un accès au serveur sans aucune restriction. +En d'autres termes, l'ordre de la combinaison des sections est important, +soyez donc prudent !

+ + +<Location />
+Order deny,allow
+Allow from all
+</Location>
+
:if expand("%") == ""|browse confirm w|else|confirm w|endif + +# Arrghs! Cette section <Directory> n'aura aucun effet
+<Directory />
+Order allow,deny
+Allow from all
+Deny from badguy.example.com
+</Directory> + + +
+ +
+ diff --git a/docs/manual/server-wide.xml.fr b/docs/manual/server-wide.xml.fr new file mode 100644 index 0000000000..b69ae76930 --- /dev/null +++ b/docs/manual/server-wide.xml.fr @@ -0,0 +1,124 @@ + + + + + + + + + + + + Configuration à l'échelle du serveur + + +

Ce document explique le fonctionnement de certaines directives du serveur +de base qui sont utilisées pour configurer les opérations élémentaires du +serveur.

+ + +
+ Identification du serveur + + + + ServerName + ServerAdmin + ServerSignature + ServerTokens + UseCanonicalName + UseCanonicalPhysicalPort + + + +

Les directives ServerAdmin et + ServerTokens contrôlent la nature des + informations à propos du serveur qui seront affichées dans les documents + générés par le serveur comme les messages d'erreur. La directive + ServerTokens définit la valeur du + champ d'en-tête de la réponse du serveur HTTP.

+ +

Le serveur utilise les directives + ServerName, + UseCanonicalName et + UseCanonicalPhysicalPort pour + déterminer la manière de construire des URLs vers ses propres ressources. + Par exemple, quand un client émet une requête vers un répertoire, mais + n'ajoute pas le slash final au nom du répertoire, Apache doit rediriger le + client vers le nom complet incluant le slash final afin que le client + puisse résoudre correctement les références relatives présentes dans + le document.

+
+ +
+ Localisation des fichiers + + + + CoreDumpDirectory + DocumentRoot + ErrorLog + LockFile + PidFile + ScoreBoardFile + ServerRoot + + + +

Ces directives contrôlent la localisation des différents fichiers + nécessaires au bon fonctionnement d'Apache. Quand le chemin utilisé ne + commence pas par un slash (/), la localisation des fichiers est relative + à la valeur de la directive + ServerRoot. Soyez prudent avec la + localisation de fichiers dans des répertoires où les utilisateurs non root + ont les droits en écriture. Voir la documention sur les + Conseils à propos + de la sécurité pour plus de détails.

+
+ +
+ Limitation de l'utilisation des ressources + + + + LimitRequestBody + LimitRequestFields + LimitRequestFieldsize + LimitRequestLine + RLimitCPU + RLimitMEM + RLimitNPROC + ThreadStackSize + + + +

Les directives LimitRequest* permettent de + limiter la quantité de ressources consommées par Apache pour le traitement + des requêtes des clients. Cette limitation permet de minimiser les effets + de certains types d'attaques par déni de service.

+ +

Les directives RLimit* permettent de limiter la + quantité de ressources utilisable par les processus initiés (forked) par + les processus enfants Apache. Elles permettent en particulier de contrôler + les ressources utilisées par les scripts CGI et les commandes exec des + "Inclusions côté serveur" (Server Side Includes ou SSI).

+ +

La directive ThreadStackSize + permet sur certaines plates-formes de contrôler la taille de la pile.

+
+ diff --git a/docs/manual/suexec.xml.fr b/docs/manual/suexec.xml.fr new file mode 100644 index 0000000000..a9fc90ad1e --- /dev/null +++ b/docs/manual/suexec.xml.fr @@ -0,0 +1,655 @@ + + + + + + + + + + + + Support suEXEC + + +

La fonctionnalité suEXEC permet + l'exécution des programmes CGI et + SSI sous un utilisateur autre que celui sous + lequel s'exécute le serveur web qui appelle ces programmes. + Normalement, lorsqu'un programme CGI ou SSI est lancé, il + s'exécute sous le même utilisateur que celui du serveur web qui + l'appelle.

+ +

Utilisée de manière appropriée, cette fonctionnalité peut + réduire considérablement les risques de sécurité encourus + lorsqu'on autorise les utilisateurs à développer et faire + s'exécuter des programmes CGI ou SSI de leur cru. Cependant, mal + configuré, suEXEC peut causer de nombreux problèmes et même créer + de nouvelles failles dans la sécurité de votre ordinateur. Si + vous n'êtes pas familier avec la gestion des programmes + setuid root et les risques de sécurité qu'ils comportent, + nous vous recommandons vivement de ne pas tenter + d'utiliser suEXEC.

+ + +
Avant de commencer + +

Avant de foncer tête baissée dans la lecture de ce document, + vous devez tenir compte des hypothèses faites par le Groupe + Apache et dans ce document.

+ +

Premièrement, vous devez utiliser un système d'exploitation + UNIX ou dérivé, capable d'effectuer des opérations + setuid et setgid. Tous les + exemples de commande sont donnés en conséquence. D'autres + plates-formes, même si elles supportent suEXEC, peuvent + avoir une configuration différente.

+ +

Deuxièmement, vous devez être familier avec les concepts de base + relatifs à la sécurité de votre ordinateur et son administration. + Ceci implique la compréhension des opérations + setuid/setgid et des différents effets qu'elles + peuvent produire sur votre système et son niveau de sécurité.

+ +

Troisièmement, vous devez utiliser une version + non modifiée du code de suEXEC. L'ensemble du + code de suEXEC a été scruté et testé avec soin par les développeurs + et de nombreux bêta testeurs. Toutes les précautions ont été prises + pour s'assurer d'une base sûre de code non seulement simple, mais + aussi solide. La modification de ce code peut causer des problèmes + inattendus et de nouveaux risques de sécurité. Il est + vivement recommandé de ne pas modifier le code de + suEXEC, à moins que vous ne soyez un programmeur spécialiste des + particularités liées à la sécurité, et souhaitez partager votre + travail avec le Groupe Apache afin de pouvoir en discuter.

+ +

Quatrièmement et dernièrement, le Groupe Apache a décidé de ne + PAS inclure suEXEC dans l'installation par défaut + d'Apache. Pour pouvoir mettre en oeuvre suEXEC, l'administrateur + doit porter la plus grande attention aux détails. Après avoir bien + réfléchi aux différents points de la configuration de suEXEC, + l'administrateur peut l'installer selon les méthodes classiques. + Les valeurs des paramètres de configuration doivent être + déterminées et spécifiées avec soin par l'administrateur, afin de + maintenir la sécurité du système de manière appropriée lors de + l'utilisation de la fonctionnalité suEXEC. C'est par le biais de + ce processus minutieux que le Groupe Apache espère réserver + l'installation de suEXEC aux administrateurs prudents et + suffisamment déterminés à vouloir l'utiliser.

+ +

Vous êtes encore avec nous ? Oui ? Bien. + Alors nous pouvons continuer !

+
+ +
Modèle de sécurité de suEXEC + +

Avant d'installer et configurer suEXEC, nous allons tout d'abord + décrire le modèle de sécurité que vous êtes sur le point + d'implémenter. Vous devriez ainsi mieux comprendre ce qui se passe + vraiment à l'intérieur de suEXEC et quelles précautions ont été + prises pour préserver la sécurité de votre système.

+ +

suEXEC est basé sur un programme "conteneur" + (wrapper) setuid qui est appelé par le serveur web Apache principal. + Ce conteneur est appelé quand une requête HTTP concerne + un programme CGI ou SSI que l'administrateur + a décidé de faire s'exécuter + sous un utilisateur autre que celui du serveur principal. + Lorsqu'il reçoit une telle requête, Apache fournit au conteneur + suEXEC le nom du programme, ainsi que les identifiants utilisateur + et groupe sous lesquels le programme doit s'exécuter.

+ +

Le conteneur effectue ensuite les vérifications suivantes afin + de déterminer la réussite ou l'échec du processus -- si une seule + de ces conditions n'est pas vérifiée, le programme journalise + l'erreur et se termine en retournant un code d'erreur, sinon il + continue :

+ +
    +
  1. + L'utilisateur qui exécute le conteneur est-il un + utilisateur valide de ce système ? + +

    + Ceci permet de s'assurer que l'utilisateur qui exécute le + conteneur est vraiment un utilisateur appartenant au système. +

    +
    2. + +
  2. + Le conteneur a-t-il été appelé avec un nombre + d'arguments correct ? + +

    + Le conteneur ne s'exécutera que si on lui fournit un nombre + d'arguments correct. Le serveur web apache sait quel est le + bon format des arguments. Si le conteneur ne reçoit pas un + nombre d'arguments correct, soit il a été modifié, + soit quelque chose ne va pas dans la portion suEXEC de + votre binaire Apache. +

    +
    3. + +
  3. + Cet utilisateur valide est-il autorisé à exécuter le + conteneur ? + +

    + Cet utilisateur est-il celui autorisé à exécuter le + conteneur ? Un seul utilisateur (celui d'Apache) est + autorisé à exécuter ce programme. +

    +
    4. + +
  4. + Le chemin du programme CGI ou SSI cible est-il + non sûr ? + +

    + Le chemin du programme CGI ou SSI cible débute-t-il par un + '/' ou contient-il une référence arrière '..' ? Ceci est + interdit ; le programme CGI ou SSI cible doit se trouver dans + la hiérarchie de la racine des documents de suEXEC (voir + --with-suexec-docroot=DIR ci-dessous). +

    +
    5. + +
  5. + Le nom utilisateur cible est-il valide ? + +

    + L'utilisateur cible existe-t-il ? +

    +
    6. + +
  6. + Le nom du groupe cible est-il valide ? + +

    + Le groupe cible existe-t-il ? +

    +
    7. + +
  7. + L'utilisateur cible n'est-il PAS + superutilisateur ? + + +

    + Actuellement, suEXEc ne permet pas à + root d'exécuter des programmes CGI/SSI. +

    +
    8. + +
  8. + Le numéro de l'identifiant de l'utilisateur cible + est-il SUPERIEUR au numéro d'identifiant + minimum ? + +

    + Le numéro d'identifiant utilisateur minimum est défini à + l'exécution du script configure. Ceci vous permet de définir + le numéro d'identifiant utilisateur le plus bas qui sera + autorisé à éxécuter des programmes CGI/SSI. En particulier, + cela permet d'écarter les comptes système. +

    +
    9. + +
  9. + Le groupe cible n'est-il PAS le groupe + superutilisateur ? + +

    + Actuellement, suEXEC ne permet pas au groupe + root d'exécuter des programmes CGI/SSI. +

    +
    10. + +
  10. + Le numéro d'identifiant du groupe cible est-il + SUPERIEUR au numéro d'identifiant minimum ? + +

    + Le numéro d'identifiant de groupe minimum est spécifié lors + de l'exécution du script configure. Ceci vous permet de + définir l'identifiant de groupe le plus bas possible qui sera + autorisé à exécuter des programmes CGI/SSI, et est + particulièrement utile pour écarter les groupes "système". +

    +
    11. + +
  11. + Le conteneur peut-il obtenir avec succès l'identité + des utilisateur et groupe cibles ? + +

    + C'est ici que le programme obtient l'identité des utilisateur + et groupe cibles via des appels à setuid et setgid. De même, + la liste des accès groupe est initialisée avec tous les + groupes auxquels l'utilisateur cible appartient. +

    +
    12. + +
  12. + Peut-on se positionner dans le répertoire dans dequel + sont situés les programmes CGI/SSI ? + +

    + S'il n'existe pas, il ne peut pas contenir de fichier. Et si + l'on ne peut pas s'y positionner, il n'existe probablement + pas. +

    +
    13. + +
  13. + Le répertoire est-il dans l'espace web + d'Apache ? + +

    + Si la requête concerne une portion de la racine du serveur, + le répertoire demandé est-il dans la hiérarchie de la racine + des documents de suEXEC ? Si la requête concerne un + UserDir, le répertoire demandé est-il dans + la hiérarchie du répertoire défini comme le répertoire + utilisateur de suEXEC (voir les + options de configuration de suEXEC) ? +

    +
    14. + +
  14. + L'écriture dans le répertoire est-elle interdite pour + un utilisateur autre que le propriétaire + +

    + Le répertoire ne doit pas être ouvert aux autres + utilisateurs ; seul l'utilisateur propriétaire doit pouvoir + modifier le contenu du répertoire. +

    +
    15. + +
  15. + Le programme CGI/SSI cible existe-t-il ? + +

    + S'il n'existe pas, il ne peut pas être exécuté. +

    +
    16. + +
  16. + Les utilisateurs autres que le propriétaire n'ont-ils + PAS de droits en écriture sur le programme + CGI/SSI ? + +

    + Les utilisateurs autres que le propriétaire ne doivent pas + pouvoir modifier le programme CGI/SSI. +

    +
    17. + +
  17. + Le programme CGI/SSI n'est-il PAS setuid ou + setgid ? + +

    + Les programmes cibles ne doivent pas pouvoir modifier à + nouveau les identifiants utilisateur/groupe. +

    +
    18. + +
  18. + Le couple utilisateur/groupe cible est-il le même que + celui du programme ? + +

    + L'utilisateur est-il le propriétaire du fichier ? +

    +
    19. + +
  19. + Peut-on nettoyer avec succès l'environnement des + processus afin de garantir la sûreté des opérations ? + +

    + suExec nettoie l'environnement des processus en établissant + un chemin d'exécution sûr (défini lors de la configuration), + et en ne passant que les variables dont les noms font partie + de la liste de l'environnement sûr (créée de même lors de la + configuration). +

    +
    20. + +
  20. + Le conteneur peut-il avec succès se substituer au + programme CGI/SSI cible et s'exécuter ? + +

    + C'est là où l'exécution de suEXEC s'arrête et où commence + celle du programme CGI/ssi cible. +

    +
    21. +
+ +

Ce sont les opérations standards effectuées par le modèle de + sécurité du conteneur suEXEC. Il peut paraître strict et est + susceptible d'imposer de nouvelles limitations et orientations + dans la conception des programmes CGI/SSI, mais il a été développé + avec le plus grand soin, étape par étape, en se focalisant sur + la sécurité.

+ +

Pour plus d'informations sur la mesure dans laquelle ce modèle + de sécurité peut limiter vos possibilités au regard de la + configuration du serveur, ainsi que les risques de sécurité qui + peuvent être évités grâce à une configuration appropriée de suEXEC, + se référer à la section "Avis à la population !" de ce document.

+
+ +
Configurer et installer suEXEC + +

C'est ici que nous entrons dans le vif du sujet.

+ +

Options de configuration de suEXEC
+

+ +
+
--enable-suexec
+ +
Cette option active la fonctionnalité suEXEC qui n'est + jamais installée ou activée par défaut. Au moins une option + --with-suexec-xxxxx doit accompagner l'option + --enable-suexec pour qu'APACI (l'utilitaire de + configuration de la compilation d'Apache) accepte votre demande + d'utilisation de la fonctionnalité suEXEC.
+ +
--with-suexec-bin=PATH
+ +
Le chemin du binaire suexec doit être codé en + dur dans le serveur pour des raisons de sécurité. Cette option + vous permet de modifier le chemin par défaut. + Par exemple + --with-suexec-bin=/usr/sbin/suexec
+ +
--with-suexec-caller=UID
+ +
L'utilisateur sous + lequel Apache s'exécute habituellement. C'est le seul utilisateur + autorisé à utiliser suexec.
+ +
--with-suexec-userdir=DIR
+ +
Cette option définit le sous-répertoire de la hiérarchie des + répertoires utilisateurs dans lequel l'utilisation + de suEXEC sera autorisée. Tous les exécutables situés dans ce + répertoire seront exécutables par suEXEC sous l'utilisateur + cible ; ces programmes doivent donc être sûrs. Si vous utilisez + une directive UserDir + "simple" (c'est à dire ne contenant pas de + "*"), l'option --with-suexec-userdir + devra contenir la même valeur. SuEXEC ne fonctionnera pas + correctement si la directive UserDir contient une valeur + différente du répertoire home de l'utilisateur tel qu'il est + défini dans le fichier passwd. la valeur par défaut + est "public_html".
+ Si vous avez plusieurs hôtes virtuels avec une directive + UserDir différente + pour chacun d'entre eux, vous devrez faire en sorte que chaque + UserDir possède un répertoire parent commun ; donnez alors à + l'option --with-suexec-userdir le nom + de ce répertoire commun. Si tout ceci n'est pas défini + correctement, les requêtes CGI "~userdir" ne fonctionneront + pas !
+ +
--with-suexec-docroot=DIR
+ +
Cette option fonctionne comme la directive DocumentRoot pour + Apache. Il s'agit de la seule hiérarchie (en dehors des directives + UserDir) dans laquelle la fonctionnalité suEXEC + pourra être utilisée. La valeur par défaut est la valeur de + --datadir accompagnée du suffixe + "/htdocs" ; + Par exemple, si vous exécutez configure avec + "--datadir=/home/apache", la valeur + "/home/apache/htdocs" sera utilisée par défaut comme + racine des documents pour le conteneur suEXEC.
+ +
--with-suexec-uidmin=UID
+ +
Cette option définit l'identifiant utilisateur le plus bas + avec lequel un utilisateur pourra être la cible de + suEXEC. 500 ou 100 sont des valeurs courantes sur la plupart des + systèmes. la valeur par défaut est 100.
+ +
--with-suexec-gidmin=GID
+ +
Cette option définit l'identifiant de groupe le plus bas + avec lequel un utilisateur pourra être la cible de + suEXEC. 100 est une valeur courante sur la plupart des + systèmes et est par conséquent la valeur par défaut.
+ +
--with-suexec-logfile=FILE
+ +
Cette option permet de définir le fichier dans lequel + toutes les transactions et erreurs de suEXEC seront journalisées + (à des fins d'analyse ou de débogage). Par défaut, le fichier + journal se nomme "suexec_log" et se trouve dans votre + répertoire standard des fichiers journaux défini par + --logfiledir
+ +
--with-suexec-safepath=PATH
+ +
Cette option permet de définir une variable d'environnement + PATH sûre à passer aux exécutables CGI. La valeur par défaut + est "/usr/local/bin:/usr/bin:/bin".
+
+ +
+ Compilation et installation du conteneur suEXEC + +

Si vous avez activé la fonctionnalité suEXEC à l'aide de + l'option --enable-suexec, le binaire + suexec sera automatiquement construit (en même temps + qu'Apache) lorsque vous exécuterez la commande + make.

+ +

Lorsque tous les composants auront été construits, vous pourrez + exécuter la commande make install afin de les + installer. Le binaire suexec sera installé dans le + répertoire défini à l'aide de l'option --sbindir. La + localisation par défaut est "/usr/local/apache2/bin/suexec".

+

Veuillez noter que vous aurez besoin des + privilèges root pour passer l'étape de + l'installation. Pour que le conteneur puisse changer + l'identifiant utilisateur, il doit avoir comme propriétaire + root, et les droits du fichier doivent + inclure le bit d'exécution setuserid.

+
+ +
+ >Mise en place de permissions pour + paranoïaque +

Bien que le conteneur suEXEC vérifie que l'utilisateur qui + l'appelle correspond bien à l'utilisateur spécifié à l'aide de + l'option --with-suexec-caller du programme + configure, il subsiste toujours le risque qu'un + appel système ou une bibliothèque fasse appel à suEXEC avant que + cette vérification ne soit exploitable sur votre système. Pour + tenir compte de ceci, et parce que c'est en général la meilleure + pratique, vous devez utiliser les permissions du système de + fichiers afin de vous assurer que seul le groupe sous lequel + s'exécute Apache puisse faire appel à suEXEC.

+ +

Si, par exemple, votre serveur web est configuré pour + s'exécuter en tant que :

+ + + User www
+ Group webgroup
+ + +

et suexec se trouve à + "/usr/local/apache2/bin/suexec", vous devez exécuter les + commandes

+ + + chgrp webgroup /usr/local/apache2/bin/suexec
+ chmod 4750 /usr/local/apache2/bin/suexec
+ + +

Ceci permet de s'assurer que seul le groupe sous lequel Apache + s'exécute (ici webgroup) puisse faire appel au conteneur + suEXEC.

+
+
+ +
Activation et désactivation +de suEXEC + +

Au démarrage, Apache vérifie la présence du fichier + suexec dans le répertoire défini par + l'option --sbindir du script configure (le + répertoire par défaut est "/usr/local/apache/sbin/suexec"). Si + Apache trouve un conteneur suEXEC correctement configuré, il + enregistrera le message suivant dans le journal des erreurs :

+ + + [notice] suEXEC mechanism enabled (wrapper: /path/to/suexec) + + +

Si ce message n'est pas généré au démarrage du serveur, ce + dernier ne trouve probablement pas le programme conteneur à + l'endroit où il est sensé être, ou l'exécutable suexec n'est pas + installé en setuid root.

+ +

Si le serveur Apache est déjà en cours d'exécution, et si + vous activez le mécanisme suEXEC pour la première fois, vous + devez arrêter et redémarrer Apache. Un redémarrage + à l'aide d'un simple signal HUP ou USR1 suffira.

+

Pour désactiver suEXEC, vous devez supprimer le fichier + suexec, puis arrêter et redémarrer + Apache.

+
+ +
Utilisation de suEXEC + +

Les requêtes pour des programmes CGI ne feront appel au + conteneur suEXEC que si elles concernent un hôte virtuel + contenant une directive SuexecUserGroup, ou si elles sont + traitées par mod_userdir.

+ +

Hôtes virtuels :
Une des méthodes + d'utilisation du conteneur suEXEC consiste à insérer une + directive SuexecUserGroup dans une section + VirtualHost. En définissant + des valeurs différentes de celles du serveur principal, toutes les + requêtes pour des ressources CGI seront exécutées sous + les User et Group définis pour cette section + VirtualHost. Si cette + directive est absente de la section VirtualHost, l'utilisateur du + serveur principal sera pris par défaut

+ +

Répertoires des utilisateurs :
Avec + cette méthode, les + requêtes traitées par mod_userdir appelleront le + conteneur suEXEC pour exécuter le programme CGI sous l'identifiant + utilisateur du répertoire utilisateur concerné. Seuls prérequis + pour pouvoir accéder à cette fonctionnalité : l'exécution des CGI + doit être activée pour l'utilisateur concerné, et le script doit + passer avec succès le test des vérifications de + sécurité décrit plus haut. Voir aussi l' + option de compilation + --with-suexec-userdir.

+ +
Débogage de suEXEC + +

Le conteneur suEXEC va écrire ses informations de journalisation + dans le fichier défini par l'option de compilation + --with-suexec-logfile comme indiqué plus haut. Si vous + pensez avoir configuré et installé correctement le conteneur, + consultez ce journal, ainsi que le journal des erreurs du serveur + afin de déterminer l'endroit où vous avez fait fausse route.

+ +
+ +
Avis à la population ! + Avertissements et exemples + +

NOTE ! Cette section est peut-être incomplète. + Pour en consulter la dernière révision, voir la version de la Documentation en ligne du Groupe Apache.

+ +

Quelques points importants du conteneur peuvent + imposer des contraintes du point de vue de la configuration du + serveur. Veuillez en prendre connaissance avant de soumettre un + rapport de bogue à propos de suEXEC.

+ +
    +
  • Points importants de suEXEC
    • + +
  • + Limitations concernant la hiérarchie. + +

    + Pour des raisons de sécurité et d'efficacité, toutes les + requêtes suEXEC ne doivent concerner que des ressources + situées dans la racine des documents définie pour les + requêtes concernant un hôte virtuel, ou des ressources + situées dans la racine des documents définies pour les + requêtes concernant un répertoire utilisateur. Par exemple, + si vous avez configuré quatre hôtes virtuels, vous devrez + définir la structure des racines de documents de vos hôtes + virtuels en dehors d'une hiérarchie de documents principale + d'Apache, afin de tirer parti de suEXEC dans le contexte des + hôtes virtuels (Exemple à venir). +

    +
    • + +
  • + La variable d'environnement PATH de suEXEC + +

    + Modifier cette variable peut s'avérer dangereux. Assurez-vous + que tout chemin que vous ajoutez à cette variable est un + répertoire de confiance. Vous n'avez + probablement pas l'intention d'ouvrir votre serveur de façon + à ce que l'on puisse y exécuter un cheval de Troie. +

    +
    • + +
  • + Modification de suEXEC + +

    + Encore une fois, ceci peut vous causer de + graves ennuis si vous vous y essayez sans + savoir ce que vous faites. Evitez de vous y risquer dans la + mesure du possible. +

    +
    • +
+ +
+ + diff --git a/docs/manual/upgrading.xml.fr b/docs/manual/upgrading.xml.fr new file mode 100644 index 0000000000..f9c2f1b6e5 --- /dev/null +++ b/docs/manual/upgrading.xml.fr @@ -0,0 +1,74 @@ + + + + + + + + + + + +Mise à jour vers 2.4 depuis 2.2 + + +

Afin d'assister les utilisateurs lors de leurs opérations de mise à + jour, nous maintenons un document + qui comporte des informations critiques à l'attention des personnes qui + utilisent déjà Apache. Ces informations ne sont que de brèves notes, et vous + devriez trouver plus d'informations dans le document Nouvelles fonctionnalités, ou dans + le fichier src/CHANGES.

+ +

Ce document ne décrit que les modifications intervenues entre les versions + 2.2 et 2.4. Si vous effectuez une mise à jour depuis la version 2.0, vous + devez aussi consulter le + document de mise + à jour de 2.0 vers 2.2.

+ + +Vue d'ensemble des nouvelles +fonctionnalités de Apache 2.4 + +
+ Modifications de la configuration au moment de la compilation + + +
+ +
+ Modifications de la configuration à l'exécution + + + +
+ +
+ Changements divers + +
+ +
+ Modules tiers + + + +
+ diff --git a/docs/manual/urlmapping.xml.fr b/docs/manual/urlmapping.xml.fr new file mode 100644 index 0000000000..3d1247ae62 --- /dev/null +++ b/docs/manual/urlmapping.xml.fr @@ -0,0 +1,330 @@ + + + + + + + + + + + + Mise en correspondance des URLs avec le système de fichiers + + +

Ce document explique comment Apache utilise l'URL contenue dans une + requête pour déterminer le noeud du système de fichier à partir duquel le + fichier devra être servi.

+ + + + +
Racine des documents (DocumentRoot) + +

La méthode par défaut d'Apache pour déterminer quel fichier servir pour + une requête donnée, consiste à extraire le chemin du fichier de la requête + (la partie de l'URL qui suit le nom d'hôte et le port), puis de l'ajouter + à la fin de la valeur de la directive + DocumentRoot définie dans vos fichiers + de configuration. + Ainsi, les fichiers et répertoires + situés en dessous de DocumentRoot + constituent l'arborescence de base des documents qui seront visibles + depuis le web.

+ +

Par exemple, si la directive + DocumentRoot contient + /var/www/html, une requête pour + http://www.example.com/fish/guppies.html retournera le + fichier /var/www/html/fish/guppies.html au client.

+ +

Apache supporte aussi les Hôtes virtuels, + ce qui lui permet de traiter des requêtes pour plusieurs hôtes. + Dans ce cas, un DocumentRoot + différent peut être défini pour chaque hôte virtuel; + les directives fournies par le module + mod_vhost_alias peuvent aussi être utilisées afin de + déterminer dynamiquement le noeud approprié du système de fichiers + à partir duquel servir un contenu en fonction de l'adresse IP + ou du nom d'hôte.

+ +

La directive DocumentRoot est + définie dans le fichier de configuration de votre serveur principal + (httpd.conf), mais peut aussi être redéfinie pour chaque + Hôte virtuel supplémentaire que vous avez créé.

+
+ +
Fichiers situés en dehors de +l'arborescence DocumentRoot + +

Il existe de nombreuses circonstances pour lesquelles il est nécessaire + d'autoriser l'accès web à des portions du système de fichiers qui ne se + trouvent pas dans l'arborescence DocumentRoot. Apache propose de nombreuses + solutions pour réaliser cela. Sur les systèmes Unix, les liens + symboliques permettent de rattacher d'autres portions du système de + fichiers au DocumentRoot. Pour des raisons de sécurité, + Apache ne suivra les liens symboliques que si les Options pour le répertoire concerné contiennent + FollowSymLinks ou SymLinksIfOwnerMatch.

+ +

Une autre méthode consiste à utiliser la directive Alias pour rattacher toute portion + du système de fichiers à l'arborescence du site web. Par exemple, avec

+ +Alias /docs /var/web + +

l'URL http://www.example.com/docs/dir/file.html + correspondra au fichier /var/web/dir/file.html. La + directive + ScriptAlias + fonctionne de la même manière, excepté que tout contenu localisé dans le + chemin cible sera traité comme un script CGI.

+ +

Pour les situations qui nécessitent plus de flexibilité, vous disposez + des directives AliasMatch + et ScriptAliasMatch + qui permettent des substitutions et comparaisons puissantes basées + sur les expressions rationnelles. + Par exemple,

+ +ScriptAliasMatch ^/~([a-zA-Z0-9]+)/cgi-bin/(.+) + /home/$1/cgi-bin/$2 + +

fera correspondre une requête du style + http://example.com/~user/cgi-bin/script.cgi au chemin + /home/user/cgi-bin/script.cgi, et traitera le fichier résultant + comme un script CGI.

+
+ +
Répertoires des utilisateurs + +

Sur les systèmes Unix, on peut traditionnellement faire référence + au répertoire personnel d'un utilisateur particulier à l'aide de + l'expression ~user/. + Le module mod_userdir + étend cette idée au web en autorisant l'accès aux fichiers situés dans les + répertoires home des utilisateurs à l'aide d'URLs + comme dans ce qui suit :

+ +http://www.example.com/~user/file.html + +

Pour des raisons de sécurité, il est déconseillé de permettre un accès + direct à un répertoire home d'utilisateur depuis le web. A cet effet, la + directive UserDir + spécifie un répertoire où sont situés les fichiers accessibles depuis le web + dans le répertoire home de l'utilisateur. + Avec la configuration par défaut + Userdir public_html, l'URL ci-dessus correspondra à un fichier + dont le chemin sera du style + /home/user/public_html/file.html où + /home/user/ est le répertoire home de l'utilisateur tel qu'il + est défini dans /etc/passwd.

+ +

La directive Userdir met à votre disposition de nombreuses + formes différentes pour les systèmes où /etc/passwd ne + spécifie pas la localisation du répertoire home.

+ +

Certains jugent le symbole "~" (dont le code sur le web est souvent + %7e) inapproprié et préfèrent utiliser une chaîne de + caractères différente pour représenter les répertoires utilisateurs. + mod_userdir ne supporte pas cette fonctionnalité. Cependant, si les + répertoires home des utilisateurs sont structurés de manière rationnelle, + il est possible d'utiliser la directive + AliasMatch + pour obtenir l'effet désiré. Par exemple, pour faire correspondre + http://www.example.com/upages/user/file.html à + /home/user/public_html/file.html, utilisez la directive + AliasMatch suivante :

+ +AliasMatch ^/upages/([a-zA-Z0-9]+)/?(.*) + /home/$1/public_html/$2 +
+ +
Redirection d'URL + +

Les directives de configuration décrites dans les sections précédentes + demandent à Apache d'extraire un contenu depuis un emplacement spécifique + du système de fichiers + et de la retourner au client. Il est cependant parfois + souhaitable d'informer le + client que le contenu demandé est localisé à une URL différente, et de + demander au client d'élaborer une nouvelle requête avec la nouvelle URL. + Ce processus se nomme redirection et est implémenté par la + directive Redirect. + Par exemple, si le contenu du répertoire /foo/ sous + DocumentRoot est déplacé vers le + nouveau répertoire /bar/, vous pouvez demander aux clients + de le requérir à sa nouvelle localisation comme suit :

+ +Redirect permanent /foo/ http://www.example.com/bar/ + +

Ceci aura pour effet de rediriger tout chemin d'URL commençant par + /foo/ vers le même chemin d'URL sur le serveur + www.example.com en remplaçant /foo/ par + /bar/. Vous pouvez rediriger les clients non seulement sur le + serveur d'origine, mais aussi vers n'importe quel autre serveur.

+ +

Apache propose aussi la directive RedirectMatch pour traiter les problèmes + de réécriture d'une plus grande complexité. Par exemple, afin de rediriger + les requêtes pour la page d'accueil du site vers un site différent, mais + laisser toutes les autres requêtes inchangées, utilisez la + configuration suivante :

+ +RedirectMatch permanent ^/$ + http://www.example.com/startpage.html + +

De même, pour rediriger temporairement toutes les pages d'un site + vers une page particulière d'un autre site, utilisez ce qui suit :

+ +RedirectMatch temp .* + http://othersite.example.com/startpage.html +
+ +
Mandataire inverse (Reverse Proxy) + +

Apache vous permet aussi de rapatrier des documents distants +dans l'espace des URL du serveur local. +Cette technique est appelée mandataire inverse ou reverse +proxying car le serveur web agit comme un serveur mandataire en +rapatriant les documents depuis un serveur distant puis les renvoyant +au client. Ceci diffère d'un service de proxy usuel car, pour le client, +les documents semblent appartenir au serveur mandataire inverse.

+ +

Dans l'exemple suivant, quand les clients demandent des documents situés +dans le répertoire +/foo/, le serveur rapatrie ces documents depuis le répertoire +/bar/ sur internal.example.com +et les renvoie au client comme s'ils appartenaient au serveur local.

+ + +ProxyPass /foo/ http://internal.example.com/bar/
+ProxyPassReverse /foo/ http://internal.example.com/bar/ +ProxyPassReverseCookieDomain internal.example.com public.example.com +ProxyPassReverseCookiePath /foo/ /bar/ + + +

La directive ProxyPass configure +le serveur pour rapatrier les documents appropriés, alors que la directive +ProxyPassReverse +réécrit les redirections provenant de +internal.example.com de telle manière qu'elles ciblent le +répertoire approprié sur le serveur local. De manière similaire, les directives +ProxyPassReverseCookieDomain +et ProxyPassReverseCookiePath +réécrivent les cookies élaborés par le serveur d'arrière-plan.

+

Il est important de noter cependant, que les liens situés dans les documents +ne seront pas réécrits. Ainsi, tout lien absolu sur +internal.example.com fera décrocher le client +du serveur mandataire et effectuer sa requête directement sur +internal.example.com. Un module tiers +mod_proxy_html +permet de réécrire les liens dans les documents HTML et XHTML.

+
+ +
Moteur de réécriture + +

Le moteur de réécriture mod_rewrite peut s'avérer + utile lorsqu'une substitution plus puissante est nécessaire. + Les directives fournies par ce module utilisent des caractéristiques de la + requête comme le type de navigateur ou l'adresse IP source afin de décider + depuis où servir le contenu. En outre, mod_rewrite peut utiliser des + fichiers ou programmes de bases de données externes pour déterminer comment + traiter une requête. Le moteur de réécriture peut effectuer les trois types + de mise en correspondance discutés plus haut : + redirections internes (aliases), redirections externes, et services mandataires. + De nombreux exemples pratiques utilisant mod_rewrite sont discutés dans le + Guide de réécriture des URLs.

+
+ +
Fichier non trouvé (File Not Found) + +

Inévitablement, apparaîtront des URLs qui ne correspondront à aucun + fichier du système de fichiers. + Ceci peut arriver pour de nombreuses raisons. + Il peut s'agir du déplacement de documents d'une + localisation vers une autre. Dans ce cas, le mieux est d'utiliser la + redirection d'URL pour informer les clients de la + nouvelle localisation de la ressource. De cette façon, vous êtes sur que + les anciens signets et liens continueront de fonctionner, même si la + ressource est déplacée.

+ +

Une autre cause fréquente d'erreurs "File Not Found" est l'erreur de + frappe accidentelle dans les URLs, soit directement dans le navigateur, + soit dans les liens HTML. Apache propose le module + mod_speling (sic) pour tenter de résoudre ce problème. + Lorsque ce module est activé, il intercepte les erreurs + "File Not Found" et recherche une ressource possédant un nom de fichier + similaire. Si un tel fichier est trouvé, mod_speling va envoyer une + redirection HTTP au client pour lui communiquer l'URL correcte. + Si plusieurs fichiers proches sont trouvés, une liste des alternatives + possibles sera présentée au client.

+ +

mod_speling possède une fonctionnalité particulièrement utile : + il compare les noms de fichiers sans tenir compte de la casse. + Ceci peut aider les systèmes où les utilisateurs ne connaissent pas la + sensibilité des URLs à la casse et bien sûr les systèmes de fichiers unix. + Mais l'utilisation de mod_speling pour toute autre chose que la correction + occasionnelle d'URLs peut augmenter la charge du serveur, car chaque + requête "incorrecte" entraîne une redirection d'URL et une nouvelle requête + de la part du client.

+ +

Si toutes les tentatives pour localiser le contenu échouent, Apache + retourne une page d'erreur avec le code de statut HTTP 404 + (file not found). L'apparence de cette page est contrôlée à l'aide de la + directive ErrorDocument + et peut être personnalisée de manière très flexible comme discuté dans le + document + Réponses personnalisées aux erreurs.

+
+ +