Apache Phrasebook

LE GUIDE DE SUR VIE
Daniel Lopez LE GUIDE DE SURVIE

LE GUIDE DE SURVIE
Apache
L’ESSENTIEL DU CODE ET DES COMMANDES
Ce Guide de survie est le compagnon indispensable pour ne
jamais vous sentir perdu dans un environnement Apache.
Vous y trouverez en un clin d’œil les principales commandes
Apache
et lignes de code pour amener un serveur Web Apache à
Apache
répondre à vos besoins, que vous exécutiez des domaines
virtuels complexes desservant des millions de pages par
jour ou un simple serveur de test tournant sur un portable.
CONCIS ET MANIABLE
Facile à transporter, facile à utiliser — finis les livres
encombrants ! L’ESSENTIEL DU CODE ET DES COMMANDES
PRATIQUE ET FONCTIONNEL
Plus de 100 fragments de code et commandes
personnalisables pour gérer efficacement un serveur
Apache dans toutes les situations.
Daniel Lopez est président et directeur technique de

BitRock, une société qui élabore des outils d’installation
et de gestion multi-plateformes, en mettant l’accent sur
les produits open source. C’est l’auteur du module Apache
mod_mono et de l’outil de configuration Comanche.
Niveau : Intermédiaire
Catégorie : Web
Configuration : Multi-plateforme
Pearson Education France ISBN : 978-2-7440-2126-6 Lopez

47 bis, rue des Vinaigriers
75010 Paris
Tél. : 01 72 74 90 00
Fax : 01 42 05 22 17
www.pearson.fr
2126-MP Apache.indd 1 11/05/09 15:38:50

Apache
Daniel Lopez
Jesus Blanco
CampusPress a apporté le plus grand soin à la réalisation de ce livre afin de vous
fournir une information complète et fiable. Cependant, CampusPress n’assume de
responsabilités, ni pour son utilisation, ni pour les contrefaçons de brevets ou
atteintes aux droits de tierces personnes qui pourraient résulter de cette utilisation.
Les exemples ou les programmes présents dans cet ouvrage sont fournis pour illus-
trer les descriptions théoriques. Ils ne sont en aucun cas destinés à une utilisation
commerciale ou professionnelle.
CampusPress ne pourra en aucun cas être tenu pour responsable des préjudices ou
dommages de quelque nature que ce soit pouvant résulter de l’utilisation de
ces exemples ou programmes.
Tous les noms de produits ou autres marques cités dans ce livre sont des marques
déposées par leurs propriétaires respectifs.
Publié par CampusPress Titre original : Apache Phrasebook

75010 PARIS Traduit de l’américain par :
Tél : 01 72 74 90 00 Nathalie Le Guillou de Penanros
Réalisation PAO : Léa B

ISBN original : 0-672-32836-4
Copyright © 2006 by Sams Publishing
Auteur : Daniel Lopez et Jesus Blanco
www.samspublishing.com
Tous droits réservés
ISBN : 978-2-7440-4001-6
Copyright © 2009 Sams Publishing

CampusPress est une marque 800 East 96th,
de Pearson Education France Indianapolis, Indiana 46240 USA
Tous droits réservés
All rights reserved. No part of this book may be reproduced or transmitted in any
form or by any means, electronic or mechanical, including photocopying,
recording or by any information storage retrieval system, without permission from
Pearson Education, Inc.
Aucune représentation ou reproduction, même partielle, autre que celles prévues
à l’article L. 122-5 2˚ et 3˚ a) du code de la propriété intellectuelle ne peut être
faite sans l’autorisation expresse de Pearson Education France ou, le cas échéant,
sans le respect des modalités prévues à l’article L. 122-10 dudit code.
Table des matières
Introduction 1
1 Les bases d'Apache 3

Découverte d'Apache 3
Pour savoir si Apache est déjà installé 5
Installation d'Apache 1.3 sous Linux et UNIX 6
Installation d'Apache sous Windows 8
Configuration de base des fichiers 9
Utilisation de plusieurs fichiers de configuration 11
Démarrage, arrêt et redémarrage d'Apache 12
Modification de l'adresse et du port utilisés par Apache 14
Modification de l'utilisateur Apache 15
Spécification d'un nom de serveur 16
Création d'une icône pour "Ma page Web" 16
Découverte des modules disponibles sur le serveur 17
Activation et désactivation de modules individuels 18
Ajout de modules après la compilation d'Apache
sans recompilation 19
Publication de contenu 20
2 Dépannage 25
A l'aide ! Mon serveur Apache ne fonctionne pas ! 25
Le journal d'erreurs 26
Connexion au démon du journal système 27
Contrôle de la quantité des informations consignées 27
Test de la configuration Apache à la recherche
de problèmes 29
Test d'Apache à partir de la ligne de commande 29
IV APACHE
Vérification du fonctionnement d'Apache 31

Autres manières d'arrêter Apache 32
Utilisation d'Apache… pour déboguer Apache 33
Erreurs de démarrage 34
Erreurs de refus d'accès 37
Erreurs internes au serveur 38
Autres fichiers pour la journalisation des erreurs 40
Les redirections ne fonctionnent pas 40
Liste de vérification pour le dépannage 41
Si tout le reste a échoué 44
3 Journaux et surveillance 45
Introduction à la consignation des erreurs dans Apache 45
Fichiers journaux Apache par défaut 46
Création des formats de journaux 46
Création d'un fichier journal personnalisé 48
Redirection des journaux vers un programme externe 49
Consignation conditionnelle de requêtes 49
Surveillance des personnes se connectant à votre site 50
Surveillance d'Apache avec mod_status 51
Surveillance d'Apache avec SNMP 52
Analyse des journaux à l'aide d'outils Open Source 53
Surveillance de vos journaux en temps réel 53
Consignation des requêtes dans une base de données 54
Rotation et archivage des journaux 55
Contrôle de la résolution des adresses IP 56
Traitement d'adresses IP consignées 56
Redémarrage automatique d'Apache en cas de panne 57
Fusion et séparation de fichiers journaux 58
Conservation de fichiers séparés pour chaque
hôte virtuel 59
Entrées de journaux communes 60
Table des matières V
4 Mappage d'URL et contenu dynamique 63

Mappage d'URL 63
Mappage d'URL et de fichiers avec Alias 64
Mappage de motifs d'URL à des fichiers
avec AliasMatch 64
Redirection d'une page vers un autre emplacement 65
Redirection vers la dernière version d'un fichier 66
Echec de la redirection ou requêtes non autorisées 67
Définition des gestionnaires de contenu 67
Les types MIME 68
Configuration des types MIME 69
Les bases de l'exécution des scripts CGI 69
Désignation de ressources comme des CGI exécutables 70
Association de scripts à des méthodes HTTP
et des types MIME 71
Dépannage relatif à l'exécution des scripts CGI 72
Amélioration des performances du script CGI 72
SSI 73
Configuration de SSI 74
Paramétrage des variables d'environnement 74
Paramétrage dynamique des variables d'environnement 75
Variables d'environnement spéciales 76
Négociation du contenu 77
Configuration de la négociation du contenu 78
Affectation de jeux de caractères par défaut
et de priorités de langue 80
Mappage avancé d'URL avec mod_rewrite 81
Problème de l'oubli de la barre oblique finale 81
Correction des fautes de frappe 82
Résolution des problèmes de casse 83
Validation de pages avec Tidy 84
VI APACHE
5 Hébergement virtuel 87
Définition de l'hébergement virtuel 87
Hébergement virtuel basé sur IP 88
Configuration de l'hébergement virtuel basé sur IP 89
Hébergement virtuel basé sur le nom 90
Configuration de l'hébergement virtuel basé sur le nom 91
Que se passe-t-il si une requête ne correspond
à aucun hôte virtuel ? 92
Mélange d'hôtes basés sur IP et basés sur le nom 94
Débogage des configurations d'hôtes virtuels 95
Utilisation de SSL avec des hôtes virtuels basés
sur le nom 96
6 Sécurité et contrôle d'accès 101

Le contrôle d'accès, une exigence ? 101
Différences existant entre les versions d'Apache 102
L'authentification basique et digest 102
Présentation du contrôle d'accès Apache 104
Configuration des autorisations
et des authentifications Apache 105
Création d'une base de données utilisateur 106
Emploi de Require pour autoriser des utilisateurs
et des groupes 107
Gestion d'un grand nombre d'utilisateurs 108
Autorisation d'accès à des adresses IP
spécifiques uniquement 108
Refuser l'accès à des adresses IP spécifiques 109
Combinaison des méthodes de contrôle d'accès 110
Personnalisation de la page de refus d'accès 111
Donner le pouvoir aux utilisateurs 112
Refus d'accès aux fichiers système et sensibles 113
Restriction d'exécution de programmes 114
Eviter les abus 115
Table des matières VII
Désactivation des listings de répertoire 115

Modification de l'en-tête Server: 116
Empêcher le vol de vos images (hotlinking) 117
Restriction de méthodes HTTP spécifiques 118
Restriction d'accès basée sur le type du navigateur 119
Utilisation des sections d'emplacement et de répertoire 120
Autres modules d'authentification 120
Apache 2.2 122
Mise à jour de la sécurité Apache 123
Liste de contrôle de sécurité 123
Désactiver les modules inutiles 124
Suppression des échantillons de script 125
Restreindre ou désactiver l'exécution de CGI et de SSI 125
Vérifier les autorisations de fichiers 126
Limiter ou désactiver la fonctionnalité de proxy 127
Restreindre l'accès à votre serveur par défaut 127
7 SSL et TLS 129

Définition de SSL 129
Fonctionnement de SSL 130
Compilation d'OpenSSL 131
Clés de cryptage 132
Création d'une paire de clés 133
Création d'une paire de clés protégées
par mot de passe 133
Suppression du mot de passe d'une clé 134
Certificats 134
Création d'une requête de signature de certificat 135
Affichage du contenu d'une requête de signature
de certificat 137
Création d'un certificat autosigné 137
Compilation de la prise en charge SSL dans Apache 1.3 138
Compilation de la prise en charge SSL dans Apache 2.x 140
VIII APACHE
Configuration minimale d'Apache 140

Démarrage d'Apache avec prise en charge SSL 141
SSLPassPhraseDialog 142
Amélioration des performances SSL 143
Forcer le contenu à être desservi par SSL 144
SSL et hôtes virtuels SSL basés sur le nom 144
Utilisation des modules Auth d'Apache avec SSL 145
Messages d'avertissement lors de l'accès
à un site Web activé par SSL 146
Création de certificats client 146
Authentification à l'aide des certificats client 147
Alternatives à mod_ssl 148
Test de sites Web activés par SSL
à partir de la ligne de commande 148
Contourner les implémentations SSL
présentant des bogues 149
Contrôle d'accès complexe avec mod_ssl 150
Chapitres annexes 150
8 Publication de contenu avec DAV 151

Apache et la publication de contenu 151
Présentation de WebDAV 152
Avantages de l'utilisation de mod_dav 153
WebDAV et le protocole HTTP 154
Installation de mod_dav sous Apache 2.0 155
Configuration WebDAV de base 156
Sécurisation de votre configuration WebDAV 157
Accès aux ressources DAV depuis Microsoft Office 158
Accès aux ressources DAV depuis Microsoft Windows 159
Accès aux ressources DAV depuis Firefox 161
Accès à DAV depuis la ligne de commande 162
Table des matières IX
Gestion des clients présentant des bogues 164

mod_speling et DAV 165
Contenu dynamique et DAV 165
Activation des pages par utilisateur 166
Autres répertoires utilisateur 167
Résolution des problèmes avec DAVLockDB 168
9 Performances et évolutivité 169

Personnalisation d'Apache 169
Les performances et l'évolutivité 170
Personnalisation du matériel 170
Elargissement des limites du système d'exploitation 171
Elargissement des limites du système d'exploitation
sur les processus 172
Augmentation des descripteurs de fichiers
du système d'exploitation 173
Contrôle des processus externes 173
Amélioration des performances du système de fichiers 174
Gestion de liens symboliques 175
Personnalisation du réseau et des paramètres de statut 178
Eviter les abus 180
Restriction des connexions et de la bande passante 181
Gestion des robots 183
Proxy inverses et systèmes d'équilibrage des charges 184
Mise en cache et compression 185
Optimisations spécifiques aux modules 186
Alternatives à Apache 186
10 Proxy Apache et mise en cache 187

De l'utilité de la mise en cache et des proxy 187
Proxy ordinaires et inverses 188
Différences entre Apache 1.3, 2.0 et 2.2 188
X APACHE
Activation de la prise en charge de mod_proxy 189

Activation de la prise en charge des proxy ordinaires 189
Utilisation d'un proxy inverse pour unifier
un espace URL 191
Masquage des serveurs d'arrière-guichet 192
Eviter l'inversion des URL en proxy 193
Amélioration des performances 193
Déchargement du processus SSL 195
Transfert des informations de proxy dans les en-têtes 195
Manipulation des en-têtes 196
Implémentation d'un proxy de cache 197
Mise en cache dans Apache 2 198
Equilibrage des charges 199
Connexion à Tomcat 200
Autres proxy 201
Proxy HTTP transparents 201
11 Multitraitement et modules de protocole 203

Evolution de l'architecture Apache 203
Sélection d'un module multitraitement 204
Découverte des MPM basés sur les processus 204
Configuration de MPM Prefork 205
MPM basés sur des threads et MPM hybrides 207
Configuration de MPM Worker 207
Autres MPM 208
Description des filtres Apache 2 209
Utilisation d'Apache comme serveur FTP 210
Utilisation d'Apache comme serveur POP3 211
Compression de contenu à la volée 212
Index 215
A propos des auteurs XI
A propos des auteurs

Daniel Lopez est le fondateur de la société BitRock
qui élabore des outils d'installation et de gestion multi-
plates-formes pour divers logiciels commerciaux et Open
Source. Il y occupe actuellement le poste de directeur
technique.
Il a fait partie de la première équipe d'ingénieurs de
Covalent Technologies, Inc., qui propose des services et
une assistance logicielle Apache aux entreprises. Il a écrit
plusieurs guides populaires sur Apache et Linux. Il est
également l'auteur du module Apache mod_mono pour
l'intégration d'Apache et de .NET, ainsi que de Coman-
che, un outil de configuration de GUI pour Apache.
Daniel Lopez intervient régulièrement dans des confé-
rences sur l'Open Source, comme LinuxWorld, Apache-
Con et la Convention Open Source O'Reilly. Il possède
un master en télécommunications de la Escuela Superior
de Ingenieros de Séville et du Danmarks Tekniske Uni-
versitet. Il est d'autre part membre de l'Apache Software
Foundation.
Jesus Blanco est responsable de projets auprès de la
société BitRock, précédemment citée. Il a travaillé pour
le Spanish Institute of Foreign Commerce, ce qui l'a conduit à
exercer ses talents au Brésil, en France, en Allemagne, au
Portugal et en Asie du Sud-Est. Jesus Blanco a participé au
projet de documentation Apache, dont il a traduit une
grande partie en espagnol. Il a obtenu un diplôme d'admi-
nistration des affaires (université de Séville) et un master
en informatique (UNED).
Introduction
Apache s'est toujours trouvé au cœur du Web, depuis ses

débuts modestes où il n'était qu'un fork, une "bifurcation"
du serveur NCSA, jusqu'à sa dernière version qui regorge
de fonctions. Au fil du temps, ses capacités ont augmenté
autant que sa complexité, à tel point que son approche
peut se révéler très intimidante pour les novices. L'objectif
de cet ouvrage est de vous aider à naviguer parmi les cen-
taines d'options du produit. Ce livre vous servira éga-
lement d'aide-mémoire pratique pour les tâches les plus
fréquentes. De la même façon qu'un guide linguistique se
révèle un compagnon précieux pour qui voyage à l'étran-
ger, ce Guide de survie Apache vous sera d'un grand secours
pour configurer vos serveurs Web.
Le Guide de survie Apache propose des conseils et des
extraits de code qui vous aideront à personnaliser Apache,
afin que celui-ci réponde à vos besoins particuliers. Sachez
toutefois que cet ouvrage ne couvre pas tous les aspects de
ce très vaste sujet.
1
Les bases d'Apache
Découverte d'Apache
Ce chapitre propose une introduction rapide au serveur
Web Apache. Nous examinerons son architecture, ainsi
que les différences qui existent entre ses principales ver-
sions (1.3 et 2.x). Nous expliquerons comment téléchar-
ger et compiler Apache à partir de la source ou à l'aide de
packages binaires et comment activer ou désactiver les
modules communs. Nous parlerons de la mise en forme
des fichiers de serveur, ainsi que de la structure et de la
syntaxe des fichiers de configuration du serveur. Vous
apprendrez également ici à démarrer, à arrêter, puis à
redémarrer Apache. Enfin, vous pourrez modifier la
configuration minimale nécessaires pour faire fonctionner
le serveur comme vous le souhaitez.
Avec près de 68 % de parts de marché, selon Netcraft
(http://www.netcraft.com), Apache est actuellement
le serveur Web le plus populaire sur Internet.
Voici ses principales caractéristiques :
b Portable. Apache s'exécute sous Linux, Windows,
Mac OS X, ainsi que d'autres systèmes d'exploitation.
4 CHAPITRE 1 Les bases d'Apache
b Flexible. Son architecture étant modulaire et extensi-

ble, Apache peut être configuré de diverses manières.
b Open Source. Vous pouvez télécharger et utiliser
Apache gratuitement. La disponibilité du code source
vous permet d'en créer des versions personnalisées.
Il existe deux versions principales d'Apache, largement

utilisées aujourd'hui : la série 1.3 et la série 2.x.
Apache 2.0 propose certaines améliorations et fonction-
nalités qui faisaient défaut à la version 1.3 ; il est toutefois
incompatible avec tous les modules écrits pour cette pré-
cédente mouture. En règle générale, vous utiliserez Apa-
che 2.x dans les cas suivants :
b Vous disposez d'un système d'exploitation Windows.
b Vous devez desservir une grande quantité de contenu
statique qui pourrait bénéficier d'un module de traite-
ment en threads sous UNIX.
b Vous avez besoin de l'une de ses nouvelles fonction-
nalités (non disponible dans Apache 2.0).
b Vous ne connaissez pas du tout Apache.
En revanche, vous opterez pour Apache 1.3 dans les cas

suivants :
b Vous avez besoin d'exécuter des modules internes ou
tiers n'ayant pas été adaptés à Apache 2.x.
b Vous devez exécuter un logiciel, par exemple PHP,
dont les extensions ne sont pas compatibles avec les
threads ou processus légers (bien qu'un même code
s'exécutera probablement de façon satisfaisante sous
Apache 2.0 avec le MPM Prefork).
b Vous connaissez déjà Apache 1.3 et n'avez pas de
besoins spécifiques de mise à niveau.
Pour savoir si Apache est déjà installé 5
Pour savoir si Apache est déjà

installé
rpm –q httpd
rpm –q apache
rpm –q apache2
Si vous utilisez un système Linux, Apache est certaine-

ment déjà installé. Si votre distribution fait appel au sys-
tème de gestion de package rpm, tapez les commandes qui
précèdent pour le vérifier. Il existe des commandes diffé-
rentes, car les distributions n'adoptent pas toutes le même
nom de package.
Avec la plupart des systèmes de type UNIX, notamment
Mac OS X, vous pouvez aussi vérifier directement que le
binaire Apache est installé, en recourant à l'une des com-
mandes suivantes :
httpd –v
/usr/sbin/httpd -v
Si la réponse est positive, le résultat renvoyé ressemblera à

ceci :
Server version: Apache/2.0.54
Server built: Apr 16 2005 14:25:31
Vous obtiendrez une réponse encore plus détaillée avec

cette commande :
httpd -V
Sur les systèmes Windows, pour savoir si Apache est

installé, accédez à la partie Ajout/Suppression de pro-
grammes du Panneau de configuration. Le chemin d'ins-
tallation est le suivant :
C:\Program Files\Apache Group
Pour se procurer Apache

Par défaut, Apache est présent dans la plupart des versions de
Linux et dans Mac OS X. Vous pouvez télécharger les binaires
et le source pour diverses plates-formes, notamment Windows,
sur le site Web officiel d'Apache, à l'adresse http://www.apa-
chefrance.com.
Installation d'Apache 1.3

sous Linux et UNIX
tar xvfz apache_1.3.33.tar.gz
cd apache_1.3.33
./configure --prefix=/usr/local/apache --enable-shared=max
make
make install
Vous pouvez utiliser les outils de gestion de package de
votre système d'exploitation pour installer des versions
pré-implantées du serveur. Cette solution est souvent pré-
férable, car elle s'intègre bien avec le système de fichiers
existant ou d'autres packages fournis par des tiers. Il est
toutefois important de savoir construire sa propre version
d'Apache à partir du code source. Cela permet, par exem-
ple, de créer un serveur personnalisé selon les besoins ou
bien d'appliquer rapidement des correctifs de sécurité dès
leur publication.
La première étape consiste à vous rendre sur le site Web
http://httpd.apache.org et à télécharger l'archive tar
du source approprié. Dans cet ouvrage, lorsque nous
ferons référence à une fonctionnalité spécifique de la ver-
sion 1.3, nous supposerons que vous avez installé la version
Apache 1.3.33. Il s'agit en fait de la version la plus récente
de la série 1.3 à l'heure où nous rédigeons ces lignes.
L'archive tar du source s'intitule apache_1.3.33.tar.gz.
Vous pouvez maintenant décompresser, configurer, com-

piler et installer Apache en appliquant les commandes du
listing précédent.
L'option - -prefix indique le chemin sous lequel doit être
installé le serveur. --enable-shared=max active la prise en
charge du module chargeable, nécessaire pour prolonger
ou personnaliser les fonctionnalités par la suite, sans avoir
à recompiler le serveur.
Info
Certaines versions d'Apache se terminent par .tar.bz2. Cela
signifie qu'elles ont été compressées à l'aide de l'outil bzip2.
Bien qu'il soit plus lent à compresser et à décompresser, ce
format permet de réduire la taille des fichiers de distribution ;
il est désormais fréquemment utilisé dans de nombreux projets
Open Source. Pour décompresser ce type de fichier, vous pou-
vez effectuer l'une des opérations suivantes sur la plupart des
systèmes Linux modernes :
bunzip2 < apache_1.3.33.tar.bz2 | tar xvf -
tar xvfj apache_1.3.33.tar.bz2
Installation d'Apache 2.0

sous Linux et UNIX
tar xvfz apache_2.0.54.tar.gz
cd apache_2.0.54
./configure --prefix=/usr/local/apache --enable-so
--enable-mods-shared=most
make
make install
Ce processus est analogue à celui décrit précédemment

pour la version 1.3, même si les options d'activation de
prise en charge des modules chargeables sont différentes.
Installation d'Apache
sous Windows
L'installation d'Apache sous Windows est encore plus sim-
ple que sous UNIX. Le processus est quasiment identique
pour Apache 1.3 et 2.x. Il vous suffit de télécharger le
package, à l'adresse http://httpd.apache.org, puis de
lancer l'installation du binaire.
L'assistant vous demande ensuite où installer le serveur,
ainsi que d'autres informations :
b le nom de domaine du réseau ;
b le nom de domaine totalement qualifié du serveur ;
b l'adresse e-mail de l'administrateur.
Le nom du serveur est celui utilisé par vos clients pour

accéder à votre serveur. L'adresse e-mail sera affichée dans
les messages d'erreur, afin que vos visiteurs sachent qui
contacter en cas de problème. Vous aurez également la
possibilité d'exécuter Apache sous forme de service. Cette
option est utile, par exemple si Apache doit s'exécuter à
chaque démarrage du serveur. Dans les autres cas, vous
pourrez toujours relancer Apache à partir de la ligne de
commande.
Configuration de base des fichiers 9
Est-il possible d'installer différentes versions d'Apache sur la

même machine ?
Oui, cela est tout à fait possible, et les raisons de le faire sont
nombreuses. Il suffit simplement de choisir des préfixes d'instal-
lation différents. Ainsi, par exemple, vous pouvez installer un
serveur Apache 1.3 sous /usr/local/apache et une version 2.0
sous /usr/local/apache2. Pour exécuter les serveurs simulta-
nément, attribuez-leur des combinaisons d'adresses et de ports
différentes.
Souvenez-vous qu'il n'est pas obligatoire d'installer plusieurs
serveurs Apache pour exécuter plusieurs sites Web. Un seul
serveur Apache peut suffire, grâce à la fonction d'hôte virtuel
(voir Chapitre 5).
Il est également possible de disposer de plusieurs serveurs,
chacun desservant une partie séparée d'un site Web. Vous
pouvez, par exemple, amener un serveur Apache 2.0 à fournir
le contenu principal du site www.exemple.com et déléguer le
contenu de www.exemple.com/connexion à un serveur Apa-
che 1.3 exécutant une application mod_perl existante. Vous
utiliserez alors un proxy inverse (voir Chapitre 10).
Configuration de base des fichiers

Le Tableau 1.1 indique l'emplacement par défaut du prin-
cipal fichier de configuration Apache sous divers systèmes
d'exploitation. Puisque dans certains cas les versions 1.3
et 2 du serveur devront coexister côte à côte, le nom du
fichier peut différer pour chaque version.
Tableau 1.1. Emplacement du fichier httpd.conf sur différents

systèmes
Emplacement du fichier Plate-forme

de configuration
/etc/httpd/httpd.conf Suse, Mandrake, anciens

/etc/httpd/httpd2.conf systèmes Red Hat, systèmes
/etc/httpd/conf/httpd.conf Newer Red, Fedora Core
/etc/httpd/conf/httpd2.conf
/usr/local/apache2/conf Lors de la compilation à partir
/usr/local/apache/conf du source, comme indiqué
précédemment dans ce
chapitre.
c:\Program Files\Apache Windows
Group\Apache2\conf\
httpd.conf
c:\Program Files\Apache
Group\Apache2\conf\
httpd.conf
/private/etc/httpd/ Mac OS X
httpd.conf
Le principal fichier de configuration Apache est appelé

httpd.conf. Son emplacement varie selon que vous utili-
siez Windows ou Linux d'une part, et selon que vous ayez
compilé Apache à partir du code source ou utilisé le
binaire fourni par votre distribution, d'autre part. Vous
trouverez des suggestions d'emplacements au Tableau 1.1.
Apache utilise, pour sa configuration, des fichiers en texte
brut. Ceux-ci peuvent contenir des directives et des sec-
tions. Pour y placer des commentaires, faites-les précéder
Utilisation de plusieurs fichiers de configuration 11
du signe dièse (#) au début de la ligne (ils seront ignorés

par Apache). Sachez également qu'une directive peut
s'étendre sur plusieurs lignes à condition de terminer la
ligne précédente par une barre oblique inversée (\).
Les directives gèrent tous les aspects du serveur. Vous
pouvez en placer dans des sections, de sorte qu'elles ne
s'appliquent qu'au contenu desservi par un répertoire ou
un emplacement particulier, aux requêtes desservies par
un hôte virtuel particulier, etc.
Lorsqu'un argument vers une directive correspond à un
chemin relatif, on suppose qu'il est relatif au chemin d'ins-
tallation du serveur (racine du serveur). Ainsi, par exemple,
si vous avez installé Apache à partir de la source (voir
précédemment), la racine du serveur est /usr/local/apache
ou /usr/local/apache2. Vous pouvez modifier la valeur
par défaut avec la directive ServerRoot.
Utilisation de plusieurs fichiers

de configuration
Include /etc/httpd/conf/perl.conf
Include conf.d/*.conf
Include siteconf/
Il est quelquefois utile de répartir la configuration du ser-

veur dans plusieurs fichiers. La directive Include permet
d'inclure des fichiers individuels, tous les fichiers d'un
répertoire particulier ou les fichiers correspondant à un
certain motif (nous le voyons dans ces exemples). Si un
chemin relatif est indiqué, il sera considéré comme étant
relatif au chemin spécifié par la directive ServerRoot.
Cela survient généralement avec les distributions Linux

qui concernent des modules Apache, tels que les RPM.
Chacun de ces packages peut placer son propre fichier de
configuration dans un répertoire spécifique où Apache ira
le chercher directement.
Démarrage, arrêt et redémarrage

d'Apache
apachectl start
apachectl stop
apachectl restart
apachectl graceful
Pour démarrer, arrêter ou redémarrer Apache, vous pou-

vez émettre n'importe laquelle de ces commandes. Selon
votre installation, vous devrez peut-être fournir un che-
min absolu pour apachectl, comme /usr/sbin/apachectl
ou /usr/local/apache/bin/apachectl. Même s'il est pos-
sible de contrôler directement Apache sous UNIX à l'aide
du binaire httpd, nous recommandons l'outil apachectl.
Le programme de prise en charge apachectl est distribué
dans le cadre d'Apache ; il englobe les fonctionnalités
communes dans un script simple à utiliser.
Sous UNIX, si Apache se connecte à un port privilégié
(ceux compris entre 1 et 1 024), vous aurez besoin de pri-
vilèges racine pour démarrer le serveur.
Si vous modifiez les fichiers de configuration, il faut le
signaler à Apache, de sorte que ces modifications soient
prises en compte. Pour cela, vous pouvez arrêter, puis
redémarrer le serveur, envoyer un signal de redémarrage
ou réaliser un redémarrage "en douceur" (dit "graceful").
Démarrage, arrêt et redémarrage d'Apache 13
Apache relira alors sa configuration. Pour connaître la dif-

férence entre un redémarrage ordinaire et un redémarrage
"en douceur", consultez la section suivante.
Outre l'utilisation du script apachectl, vous pouvez
employer la commande kill pour envoyer directement
des signaux au processus Apache parent. Nous verrons
cela en détail à la section "Autres méthodes pour arrêter
Apache", au Chapitre 2.
Sous Windows, vous pouvez informer Apache directe-
ment, à l'aide de l'exécutable apache.exe :
apache.exe -k restart
apache.exe -k graceful
apache.exe -k stop
Vous avez accès à des raccourcis de ces commandes dans

les entrées du menu Start que crée le système d'installation
d'Apache. Si vous avez installé Apache en tant que ser-
vice, vous pouvez le démarrer ou l'arrêter à l'aide des
outils de gestion du service de Windows, comme suit :
dans le Panneau de configuration, sélectionnez Outils
d'administration, puis cliquez sur l'icône Services.
Apache 2.0 est en outre capable de placer un programme,
Apache Monitor, dans la barre des tâches. Il s'agit d'une
simple interface graphique utilisateur pouvant servir à
démarrer et à arrêter le serveur directement ou sous forme
de service. Ce programme est installé au démarrage, mais
vous pouvez aussi le lancer à partir de l'entrée Apache du
menu Démarrer.
Qu'est-ce qu'un redémarrage "en douceur" ?

Un redémarrage "ordinaire" arrête le serveur Apache, puis le
relance. En conséquence, les requêtes en cours sont abandonnées
et aucune nouvelle requête n'est desservie tant que le serveur
est à l'arrêt. Un redémarrage normal peut donc entraîner une
interruption momentanée du service.
Un redémarrage "en douceur" ("graceful") adopte une approche
différente. Chaque thread (ou processus) desservant un client
continue à traiter la requête en cours. Une fois cela terminé, il
est arrêté et remplacé par un nouveau thread (ou processus)
contenant la nouvelle configuration. Cela assure l'homogénéité
de fonctionnement du serveur Web, sans qu'il y ait interruption.
La manière la plus pratique de réaliser un redémarrage "en dou-
ceur" sous UNIX consiste à émettre la commande suivante :
# apachectl graceful
Sous Windows, utilisez :
Apache.exe –k graceful
Modification de l'adresse
et du port utilisés par Apache
Listen 192.168.200.4:80
Listen 8080
Apache doit connaître l'adresse IP et le port à écouter

pour les requêtes entrantes. Vous pouvez les préciser à l'aide
de la directive Listen. Celle-ci prend un port à écouter et,
en option, une adresse IP. Si aucune adresse IP n'est spéci-
fiée, Apache écoute toutes les adresses disponibles. Dans
cet exemple, Apache écoute les requêtes du port 81 et de
l'adresse IP 192.168.200.4, puis celles du port 8080 à toutes
les adresses disponibles. Plusieurs directives Listen peuvent
permettre de préciser différents ports et adresses IP à écouter.
Modification de l'utilisateur Apache 15
Vous pouvez également utiliser la directive Port pour

préciser le port qu'Apache doit écouter, mais si une
directive Listen est spécifiée, Port n'aura aucun effet.
Reportez-vous au Chapitre 4 pour en savoir plus sur la
directive Port employée pour construire des URL auto-
référentielles.
La configuration est plus importante quand vous devez
supporter des hôtes virtuels fondés sur des noms. Pour
plus de détail, voyez le Chapitre 5.
Outre Listen, Apache 1.3 propose une directive annexe,
appelée BindAddress. Celle-ci étant devenue obsolète,
nous déconseillons son emploi.
Modification de l'utilisateur
Apache
User nobody
Group nobody
Vous pouvez préciser le groupe et l'utilisateur sous les-

quels s'exécute Apache, grâce aux directives User et
Group. Pour des raisons de sécurité, il est déconseillé
d'exécuter n'importe quel serveur sous forme de racine,
car un problème de configuration ou de programmation
peut exposer la totalité du serveur. Quand Apache est
exécuté sous forme de racine, il réalise toutes les actions
nécessitant des privilèges de superutilisateur (comme la
liaison au port 80) et dessert les requêtes réelles que l'uti-
lisateur et le groupe ont spécifiées dans la configuration
Apache. Les privilèges et capacités de l'ID utilisateur sont
généralement réduits.
Spécification d'un nom de serveur

ServerName www.exemple.com
Dans certains cas, Apache doit construire des URL

autoréférentielles. Il s'agit d'URL qui font référence au
serveur lui-même. Il est parfois nécessaire, par exemple,
de rediriger une requête vers une autre page ou d'afficher
l'adresse du site Web à la fin d'une page d'erreur. Par défaut,
on utilise le domaine spécifié avec la directive ServerName.
Reportez-vous au Chapitre 2 pour en savoir plus sur l'uti-
lisation des directives UseCanonicalName et Port destinées
à contrôler ce comportement.
Si aucun nom de serveur n'est spécifié, Apache tente d'en
trouver un valide en réalisant une recherche DNS inver-
sée sur l'adresse IP du serveur. Si le serveur DNS n'est pas
correctement configuré, l'opération peut être longue ;
l'auteur de la demande devra patienter un certain temps.
Création d'une icône

pour "Ma page Web"
AliasMatch /favicon.ico/usr/local/apache2/icons/site.ico
De nombreux navigateurs récents, notamment Internet

Explorer, Mozilla et Konqueror vous permettent d'associer
une icône à un signet. Quand vous placez un signet sur
une page, le navigateur demande un fichier favicon.ico
vers le répertoire contenant des documents porteurs de
signets. Le fichier favicon.ico représente une icône au
format Windows.
Découverte des modules disponibles sur le serveur 17
Vous pouvez utiliser la directive AliasMatch pour rediri-

ger toutes les requêtes de fichiers favicon.ico vers un seul
emplacement contenant l'icône de votre site (nous le
voyons dans cet exemple).
Découverte des modules

disponibles sur le serveur
# httpd -l
Cette commande répertorie les modules compilés dans

votre binaire de serveur ; elle doit renvoyer un résultat
analogue à ceci :
Compiled in modules:
core.c
prefork.c
http_core.c
mod_so.c
Si vous avez compilé Apache avec une prise en charge de

module chargeable, vos modules seront intégrés sous
forme de bibliothèques partagées et placés par défaut dans
un répertoire nommé modules/ (Apache 2.x) ou libexec/
(Apache 1.3). Pour voir les modules partagés chargés dans
le serveur au moment de l'exécution, vous devrez étudier le
fichier httpd.conf et rechercher les directives LoadModule
appropriées. Cela n'est pas nécessaire avec Apache 2.1/2.2,
car httpd -M répertorie tous les modules, y compris ceux
chargés au moment de l'exécution.
Activation et désactivation
de modules individuels
./configure (...) --enable-status
./configure (...) --disable-status
Vous pouvez activer ou désactiver des modules indivi-

duels au moment de la compilation, à l'aide des options
--enable-module et --disable-module de la commande
configure. L'exemple précédent explique le fonctionne-
ment du module mod_status distribué dans le cadre
d'Apache.
Si votre serveur a été compilé avec une prise en charge de
module chargeable, vous pouvez désactiver un module en
transformant simplement en commentaire la ligne qui
charge le module d'un serveur :
#LoadModule mod_status modules/mod_status.so
Sous Apache 1.3, vous pouvez effacer la liste des modules

actifs, notamment ceux compilés, à l'aide d'une directive
ClearModuleList. Vous devrez ensuite employer une
directive AddModule pour chaque module à utiliser. La
fonctionnalité prévue par ClearModuleList n'est pas dis-
ponible dans Apache 2.x.
Si vous désactivez un module, n'oubliez pas de le suppri-
mer des directives du fichier httpd.conf qu'il apporte ou
de l'inclure dans une section <ifModule> (comme indi-
qué), faute de quoi le serveur risque de ne pas démarrer :
<ifModule mod_status.c>
ExtendedStatus On
</ifModule>
Ajout de modules après la compilation d'Apache sans recompilation 19
Ajout de modules après

la compilation d'Apache
sans recompilation
# apxs –cia mod_usertrack.c
Eh oui, vous pouvez ajouter des modules à Apache sans

recompiler, mais uniquement si mod_so est déjà compilé
dans votre serveur. Pour savoir si c'est le cas, consultez
la section "Découverte des modules disponibles sur le
serveur".
Vous pouvez construire un module à partir des sources, à
l'aide d'apxs, un outil permettant de construire et d'installer
des modules d'extension inclus par défaut dans Apache.
Pour compiler et installer un module avec apxs, il suffit de
passer du répertoire courant à celui qui contient le module,
puis de taper :
# apxs –c mod_usertrack.c
Une fois que le module est compilé, il faut le copier dans

le répertoire des modules Apache et modifier le fichier de
configuration. apxs peut gérer tout cela automatique-
ment, grâce à cette ligne de code :
# apxs –cia mod_usertrack.c
Cette approche fonctionne pour les modules simples, tels

que ceux inclus dans la distribution Apache. Pour des modu-
les tiers plus complexes, comme PHP, il existe générale-
ment des commutateurs --with-apxs ou --with-apxs2 à
transférer dans le script de configuration.
Si vous possédez une version binaire du module disponi-
ble, inutile d'entreprendre ces étapes liées à apxs. Cela
vaut en particulier si vous avez déjà compilé de nombreux
modules optionnels lors de la construction du serveur ou

si le module est déjà fourni dans le cadre de votre distribu-
tion Linux ou de votre package d'installation Windows.
Si vous utilisez Apache 1.3, vous pouvez ajouter le nou-
veau module au serveur, en ajoutant les lignes suivantes à
votre fichier httpd.conf :
LoadModule usertrack_module libexec/mod_usertrack.so
AddModule mod_usertrack.c
Avec Apache 2.2, il suffira d'ajouter la directive LoadMo-

dule, ici avec modules/ au lieu de libexec/, dans le répe-
rtoire dans lequel sont installés par défaut les modules
chargeables.
Publication de contenu
DocumentRoot /usr/local/apache/htdocs
Par défaut, Apache dessert un contenu à partir du réper-

toire htdocs/ (qui, historiquement, signifie "document
html") dans le répertoire d'installation. Vous pouvez y
placer des documents qui apparaîtront automatiquement
dans l'espace URL du document. Ainsi, par exemple, si
vous créez un répertoire, dans htdocs, nommé foo, et que
vous y placez le fichier bar.html, celui-ci sera accessible
de l'extérieur par l'adresse suivante :
http://www.exemple.com/foo/bar.html
Vous pouvez modifier l'emplacement du répertoire de

documents à l'aide d'une directive DocumentRoot, comme
indiqué. Si un chemin relatif est précisé, il sera considéré
comme étant relatif au chemin spécifié par la directive
ServerRoot.
Publication de contenu 21
Il n'est pas obligatoire de placer le contenu dans le réper-

toire racine des documents. Apache propose en effet
plusieurs mécanismes puissants et flexibles pour faire
correspondre les URL demandées par les clients avec des
fichiers présents sur des disques ou des ressources fournies
par des modules. Pour plus de détails, consultez le Cha-
pitre 4.
Sections
Les sections, sortes de conteneurs de directives, limitent
la portée d'application des directives. Si les directives ne
se trouvent pas dans une section, cela signifie qu'elles
concernent l'ensemble du serveur par défaut (configu-
ration du serveur) et s'y appliquent :
<Directory "/usr/local/apache/htdocs">
...
</Directory>
<Location "/downloads/*.html">
...
</Location>
<FilesMatch "\.(gif|jpg)">
...
</FilesMatch>
Sections de directives Apache

par défaut
Les sections de directives suivantes correspondent aux
sections par défaut utilisées dans les fichiers de configu-
ration Apache :
<VirtualHost>. Directive qui spécifie un serveur vir-
tuel. Sachez qu'il est possible d'héberger différents sites
Web à l'aide d'une seule installation Apache (voir Cha-
pitre 5).
<Directory> et <DirectoryMatch>. Ces sections appli-
quent des directives à un répertoire (ou groupe de
répertoires) donné dans le système de fichiers. La sec-
tion <DirectoryMatch> permet d'utiliser des motifs
d'expressions régulières comme arguments.
<Location> et <LocationMatch>. Appliquent des directives
à certaines URL ou à certains motifs d'URL deman-
dés. Elles sont semblables aux sections Directory.
<Files> et <FilesMatch>. Identiques aux conteneurs
Directory et Location, les sections Files appliquent des
directives à certains fichiers ou motifs de fichiers.
Ces sections ne sont pas les seules disponibles. Des
modules, comme mod_proxy, peuvent fournir leurs pro-
pres sections (voir Chapitre 10). Consultez également
le Chapitre 8 pour en savoir plus sur les sections qui
restreignent l'accès en fonction des méthodes http.
Info
Les sections Directory, Files et Location peuvent aussi
prendre des expressions régulières comme arguments à con-
dition de les faire précéder d'un signe ~. Les expressions
régulières sont des chaînes qui décrivent un jeu de chaînes ou
y correspondent, en fonction de certaines règles de syntaxe.
Sections de directives Apache 23
Sections de directives Apache
Ainsi, par exemple, l'expression régulière <Files ~

"\.(gif|jpg)"> concordera avec toutes les requêtes deman-
dant un fichier image dont l'extension est .jpg ou .gif.
Toutefois, il vaut mieux les remplacer par les directives
DirectoryMatch, LocationMatch et FilesMatch pour des rai-
sons de clarté. Vous en saurez plus sur les expressions réguliè-
res en vous rendant à l'adresse http://fr.wikipedia.org/wiki/
Expression_r%C3%A9guli%C3%A8re.
Sections de directives
pour l'évaluation conditionnelle
Apache assure la prise en charge de sections condition-
nelles. Les directives qui y figurent seront traitées uni-
quement si certaines conditions sont remplies :
<IfDefine>. Les directives de cette section seront
traitées si un argument de ligne de commande spécifi-
que est transféré à l'exécutable Apache. Dans l'exemple
suivant, le paramètre de ligne de commande doit
être -DSSL. Vous pouvez également nier l'argument à
l'aide du signe "!", comme dans <IfDefine !SSL>, de
sorte que les directives s'appliquent si l'argument n'est
pas transféré.
<IfModule>. Les directives d'une section IfModule ne
seront traitées que si le module transféré comme argu-
ment est présent dans le serveur Web. Le fichier de
configuration Apache par défaut comprend des exem-
ples de ce type pour différents modules MPM.
Par exemple, dans le fichier httpd.conf, vous verriez :
<IfDefine SSL>
LoadModule ssl_module modules/mod_ssl.so
</IfDefine>
que vous activeriez à la ligne de commande, comme ceci :
# httpd –DSSL
2
Dépannage
C e chapitre traite des problèmes les plus communs ren-

contrés lors de l'exécution d'Apache, par exemple au
cours des procédures d'autorisation de fichiers ou lorsqu'il
est impossible d'effectuer une liaison avec un port donné.
Nous expliquerons comment les résoudre. Nous explore-
rons d'ailleurs plusieurs outils et ressources disponibles
pour isoler la cause de la plupart des problèmes.
A l'aide ! Mon serveur Apache

ne fonctionne pas !
Quoi de plus frustrant que de ne pas pouvoir avancer sur
un ouvrage technique à cause d'un logiciel déficient ? Il
n'est pas question que ce soit le cas pour ce livre, bien sûr.
C'est pourquoi nous avons placé ce chapitre vers le début
de l'ouvrage. Il couvre à la fois des sujets de base et des
sujets avancés. N'hésitez donc pas à sauter ce qui ne vous
concerne pas si vous venez tout juste de découvrir Apache !
26 CHAPITRE 2 Dépannage
Le journal d'erreurs
ErrorLog logs/error_log
Le journal d'erreurs assure le suivi des événements impor-

tants survenant dans la vie du serveur, comme les démar-
rages, redémarrages, avertissements ou erreurs liés à son
fonctionnement, ainsi que les requêtes interdites ou non
valides. C'est le premier endroit où chercher pour résou-
dre un problème lié au serveur.
Sur les systèmes UNIX, le fichier error_log est placé par
défaut dans le répertoire logs/ de votre installation Apache.
Si vous utilisez une installation Apache livrée avec votre
distribution, ce fichier peut se trouver ailleurs, le plus sou-
vent sous /var/log/httpd.
Sous Windows, le fichier est intitulé error.log et se situe
également sous le répertoire logs.
Vous utiliserez la directive ErrorLog pour préciser le che-
min du fichier journal d'erreurs. Préfixez-le avec un tiret,
afin de consigner les erreurs sur l'entrée standard d'un
autre programme. Cette technique est décrite plus en
détail au Chapitre 3.
Sachez que le fichier d'erreurs ne sera créé qu'une fois
qu'Apache aura été démarré pour la première fois.
Connexion au démon du journal système 27
Connexion au démon du journal

système
ErrorLog syslog
ErrorLog syslog:local7
Sous UNIX, passez l'argument syslog à ErrorLog, de sorte

qu'Apache utilise le démon du journal système, afin de
consigner les erreurs Apache (comme le montre l'exemple).
Vous pouvez, en option, y joindre une facilité (par défaut
local7), comme indiqué. Une facilité syslog est un champ
d'informations associé à un message syslog qui indique la
source du message de journal. Les facilités local0 à local10
sont réservées aux administrateurs et aux applications
comme Apache.
Contrôle de la quantité
des informations consignées
LogLevel notice
Les informations d'erreur fournies par Apache peuvent

être classées en fonction de leur degré d'importance. La
directive LogLevel, avec l'un des arguments présentés au
Tableau 2.1, permet de choisir les messages à recevoir.
Seules les erreurs de ce niveau d'importance (ou supé-
rieur) seront consignées.
Le niveau d'erreur par défaut, "warn" (avertir), convient
pour la plupart des installations Apache. En revanche, si
vous tentez de dépanner une configuration spécifique, vous
pouvez abaisser le niveau jusqu'à "debug" (déboguer) pour
obtenir des informations de consignation plus détaillées.
Tableau 2.1 Options LogLevel telles que décrites

dans la documentation Apache
Paramètre Description Exemple
emerg Situation d'urgence, Child cannot open lock file.

le système est Exiting.
inutilisable.
alert Une action doit getpwuid: couldn't determine

être entreprise user name from uid.
immédiatement.
crit Conditions critiques. socket: Failed to get a

socket, exiting child.
error Situation d'erreur. Premature end of script

headers.
warn Situation Child process 1234 did not

d'avertissement. exit, sending another SIGHUP.
notice Situation normale,

mais méritant d'être
signalée.
info Informatif. Server seems busy, (You may

need to increase StarServers,
or Min/MaxSpareServers)...
debug Messages de Opening config file...

débogage.
Test de la configuration Apache à la recherche de problèmes 29
Test de la configuration Apache

à la recherche de problèmes
# apachectl configtest
Cette commande sert à tester le fichier de configuration

Apache, à la recherche de problèmes communs, avant de
l'utiliser sur un serveur en situation réelle. Apache pro-
cède de la même manière pour tester votre configuration
chaque fois que vous émettez une commande de redé-
marrage, à l'aide d'apachectl. Vous êtes certain, de cette
manière, qu'un serveur en état de marche pourra redé-
marrer grâce à ce nouveau fichier de configuration.
Test d'Apache à partir de la ligne

de commande
$ telnet www.apache.org 80
Trying 192.87.106.226...
Connected to ajax-1.apache.org (192.87.106.226).
Escape character is '^]'.
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Date: Sun, 04 Sep 2005 20:42:02 GMT
Server: Apache/2.0.54 (Unix) mod_ssl/2.0.54
OpenSSL/0.9.7a DAV/2 SVN/1.2.0-dev
Last-Modified: Sat, 03 Sep 2005 11:35:42 GMT
ETag: "203a8-2de2-3ffdc7a6d3f80"
Accept-Ranges: bytes
Content-Length: 11746
Cache-Control: max-age=86400
Expires: Mon, 05 Sep 2005 20:42:02 GMT
Connection: close
Content-Type: text/html; charset=ISO-8859-1
Connection closed by foreign host.
HTTP étant un protocole fondé sur du texte simple, vous

pouvez utiliser un client Telnet (programme permettant
de connecter directement un serveur à un port donné)
pour rechercher la présence d'un serveur Apache actif à
partir de la ligne de commande. Si vous ne recevez pas de
réponse à une requête Telnet distante alors que votre
réseau est correctement configuré, cela signifie qu'Apache
n'écoute pas sur l'adresse et le port en question. Cela peut
être utile pour dépanner un environnement dans lequel il
n'existe pas de navigateur Web, comme le cas peut se pré-
senter lorsque vous accédez à un serveur à distance sur
SSH. Ainsi, si vous pouvez accéder à Apache sur une
machine distante à partir de l'adresse localhost en utilisant
Telnet, mais que vous n'utilisez pas de navigateur à dis-
tance, le problème peut provenir d'un pare-feu ou d'un
paramètre incorrect de la directive Listen d'Apache.
Connectez-vous, via Telnet, à l'adresse www.apache.org
(ou à votre site préféré) sur le port 80, puis tapez :
HEAD / HTTP/1.0
ou
GET / HTTP/1.0
Appuyez deux fois sur la touche Entrée. Vous devriez

recevoir une réponse semblable à celle de l'exemple.
Si un navigateur de ligne de commande Lynx est installé
sur votre système UNIX, vous pouvez obtenir un résultat
analogue en émettant la commande :
lynx –head –dump http://www.apache.org
Le Chapitre 7 traite de mod_ssl et donne une autre

méthode pour se connecter à un serveur Web activé par
SSL à l'aide de l'outil de ligne de commande openssl.
Vérification du fonctionnement d'Apache 31
Vérification du fonctionnement
d'Apache
ps –aux | grep httpd
25297 ? S 0:00 /usr/local/www/bin/
httpd -k start
15874 ? S 0:06 /usr/local/www/bin
/httpd -k start
14441 ? S 0:02 /usr/local/www/bin
/httpd -k start
...
/usr/sbin/lsof | grep httpd |grep IPv
httpd 14441 nobody 3u IPv4 136524
TCP www.exemple.com:http (LISTEN)
httpd 25297 root 3u IPv4 136524
httpd 30277 nobody 3u IPv4 136524
...
netstat -ltnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign
Address State PID/Program name
tcp 0 0 192.168.1.151:80 0.0.0.0:
* LISTEN 25297/httpd
tcp 0 0 0.0.0.0:22 0.0.0.0:
* LISTEN 1038/sshd
Il pourra arriver que vous ne puissiez pas vous connecter
au serveur. Vous ne serez donc pas en mesure de savoir s'il
fonctionne ou si un problème est survenu sur le réseau.
Les systèmes UNIX proposent plusieurs outils de ligne de
commande pour vous aider ; l'exemple en montre quel-
ques-uns.
L'outil ps indique si le processus httpd fonctionne ou non
sur le système.
Les outils netstat et lsof désignent le port et l'adresse sur
lesquels le serveur Apache écoute.
Sous Windows, vous pouvez faire appel au Gestionnaire

des tâches (raccourci clavier : Ctrl+Alt+Suppr) pour véri-
fier que le processus Apache.exe fonctionne. Vous pouvez
également utiliser l'application de la barre des tâches figu-
rant dans la plupart des versions récentes pour connaître la
situation d'Apache.
Autres manières d'arrêter Apache

# kill –HUP 25297
# kill –9 25297
Il peut quelquefois être nécessaire ou pratique d'arrêter le
serveur directement à l'aide de l'utilitaire de ligne de com-
mande kill au lieu d'utiliser le script apachectl. Pour
cela, vous devez d'abord trouver l'identifiant du processus
du serveur Apache actif, à l'aide de ps ou de lsof, comme
indiqué. Terminez ensuite le processus à l'aide de l'outil
de ligne de commande kill, en spécifiant le signal à
envoyer comme premier argument, et l'identifiant du
processus du serveur Apache (25 297 dans cet exemple)
comme second argument. HUP servira de signal pour arrê-
ter le serveur et SIGHUP pour le redémarrer. Vous pouvez
également remplacer le signal par son équivalent numéri-
que, comme indiqué dans l'exemple. Consultez la page du
manuel traitant de kill pour en savoir plus.
Sous Linux, vous pouvez envoyer un signal à tous les pro-
cessus nommés httpd, avec la commande killall. Vous
pouvez, par exemple, arrêter tous les processus httpd en
utilisant ceci :
# killall –HUP httpd
Soyez attentif toutefois : si vous exécutez plusieurs instances

d'Apache, cette commande les arrêtera toutes.
Utilisation d'Apache… pour déboguer Apache 33
N'oubliez pas qu'il vous faut disposer des autorisations

appropriées pour que ces commandes fonctionnent. Dans
presque tous les cas, vous devez être superutilisateur ou
propriétaire du processus Apache pour être autorisé à y
mettre fin et à le redémarrer.
Sous Windows, vous pouvez forcer l'arrêt d'Apache en cli-
quant sur le bouton Fin de tâche du Gestionnaire des tâches.
Utilisation d'Apache…
pour déboguer Apache
Plusieurs modules Apache peuvent vous aider à dépanner
ou à déboguer une configuration Apache ou une applica-
tion Web.
mod_loopback est un outil de débogage de clients Web. Il
renvoie simplement en écho au navigateur tout ce qu'il a
reçu concernant une requête HTTP, notamment des
données POST ou PUT :
http://www.snert.com/Software/mod_loopback/index.shtml
mod_tee et mod_trace_output sont des modules tiers qui

stockent le contenu lorsqu'il est desservi. Ils se trouvent
aux URL suivantes :
http://apache.webthing.com/mod_tee/
http://trace-output.sourceforge.net/
mod_logio, qui est distribué avec Apache 2, envoie toutes

les données reçues ou renvoyées par le serveur vers un
journal d'erreurs à des fins de débogage.
Tous ces modules affectent les performances mais peuvent
se révéler très utiles pour le débogage, par exemple lors-
que des problèmes d'en-tête ou de cookies surviennent.
Erreurs de démarrage
De nombreuses causes peuvent empêcher Apache de
démarrer. Dans cette section, nous examinons certains des
problèmes qui peuvent survenir et les erreurs que vous
recevez pour chacun d'entre eux.
Erreur de syntaxe
Syntax error on line xxx of /etc/httpd/httpd.conf:
La commande "PiidFile" n'est pas valide. Elle est peut-être

mal orthographiée ou bien définie par un module qui ne
figure pas dans la configuration du serveur.
Une erreur de syntaxe ("syntax error") signale soit que vous
avez mal orthographié une directive (ici, PidFile) dans le
fichier de configuration, soit que vous avez fait figurer une
ou plusieurs directives utilisées par un module qui n'a pas
été ajouté au serveur. Vérifiez la syntaxe du fichier de con-
figuration, indiquée dans le message d'erreur. Repor-
tez-vous au Chapitre 1 pour en savoir plus sur l'utilisation
d'une directive <ifModule>, afin d'exclure des directives de
manière conditionnelle. Ainsi, le fichier de configuration
pourra être traité, même si un module n'est pas disponible.
Adresse déjà utilisée

"Address already in use: make_sock: could not bind to port"
Une erreur d'adresse déjà utilisée ("address already in use")

indique qu'un autre programme emploie le port auquel
Apache tente de se connecter. Pour résoudre le pro-
blème, vous devez soit stopper le programme qui utilise
ce port avant de démarrer Apache soit modifier, dans le
fichier de configuration httpd.conf, le port sur lequel
Erreurs de démarrage 35
Apache écoute les requêtes, en ajustant les valeurs don-

nées après les directives Listen et Port.
Dans la plupart des cas, ce type d'erreur survient quand
un autre serveur Apache fonctionne déjà sur votre sys-
tème. Dans le cas de Windows, cela peut signifier qu'une
instance d'Internet Information Server ou de Microsoft
Personal Web Server s'exécute sur le port sur lequel Apa-
che est configuré. D'autres programmes populaires,
comme Skype, sont aussi connus pour utiliser le port 80
à certaines occasions.
Impossible de se connecter au port

[Mon Jan 9 20:09:50 2005] [crit] (13)Permission
denied: make_sock: could not bind to port 80
Ce type d'erreur indique que vous ne disposez pas des

autorisations nécessaires pour qu'Apache se connecte au
port spécifié dans le fichier de configuration Apache. Sous
UNIX, seuls les utilisateurs disposant de droits peuvent se
connecter aux ports compris entre 1 et 1 024. Pour
résoudre ce problème, connectez-vous en tant que racine
et émettez la commande su. Ensuite, tentez à nouveau de
démarrer le serveur. Si vous ne disposez pas d'un accès
racine, faites passer, dans votre fichier httpd.conf, le port
utilisé par Apache sur un nombre supérieur à 1 024.
Module non compatible

"module xxx is not compatible with this version of Apache"
Une erreur de module non compatible ("module is not com-

patible") survient quand Apache tente de charger un module
qui a été compilé pour un serveur plus récent (ou plus
ancien) que celui actuellement installé. Si vous disposez
du source du module, vous pourrez peut-être le recompiler

à l'aide de votre installation Apache actuelle (voir Chapi-
tre 1). Si vous ne disposez pas du source ou que vous
soyez incapable de recompiler un module dont la fonc-
tionnalité est essentielle pour vous, mettez à niveau (ou
rétrogradez) votre serveur Apache avec une version com-
patible avec le module.
Résolution de nom
"Cannot determine hostname"
Plusieurs directives Apache, notamment ServerName et

Listen, acceptent des noms d'hôtes comme arguments.
Toutefois, si Apache n'est pas capable de résoudre un nom
d'hôte fourni sur une adresse IP au démarrage à l'aide du
DNS (service de nom de domaine) de la liste d'hôtes de
votre système, une erreur s'affiche, signalant l'impossibilité
de déterminer le nom d'hôte. Pour résoudre ce problème,
vérifiez votre DNS et les paramètres /etc/hosts, ainsi que
l'orthographe des noms d'hôtes fournis dans httpd.conf.
Chaque fois que cela est possible, utilisez les adresses IP au
lieu des noms d'hôtes pour des directives comme Listen
et <VirtualHost>.
Impossible d'ouvrir un journal

ou un fichier de configuration
(13)Permission denied: httpd: could not open error
log file /usr/local/apache/logs/error_log.
Ce type d'erreur signale que vous ne disposez pas des auto-

risations suffisantes pour lire le ou les fichiers de configu-
ration Apache ou pour écrire dans les fichiers de journal
Apache.
Erreurs de refus d'accès 37
Ce problème survient souvent quand Apache est lancé par

un utilisateur autre que celui qui l'a construit et installé.
Dans ce cas, démarrez Apache sous l'identité du superutili-
sateur (ou de l'utilisateur) qui l'a installé ou, si vous disposez
des autorisations, employez chmod pour modifier la pro-
priété du fichier nommé dans le message d'erreur.
Erreurs de refus d'accès

"Forbidden/You don't have permission to access /xxx
on this server"
Si votre navigateur Web renvoie un message du type "403

Forbidden/Access Denied" lorsque vous tentez de charger
une page Web via votre serveur Apache, cela signifie que
l'URL demandée est soumise à des restrictions d'accès
auxquelles vous ne satisfaites pas. Pour résoudre ce pro-
blème, modifiez les autorisations du contenu Web ou des
fichiers que vous avez demandés. Ensuite, vérifiez que
tous les répertoires menant au document en question sont
accessibles à la fois en lecture et en exécution pour le pro-
priétaire du processus Apache. Sous UNIX, vous pouvez
employer l'utilitaire chmod pour définir ces autorisations.
Le message "Client denied by server configuration" (Client
refusé par la configuration du serveur) peut apparaître
dans le journal des erreurs. Cela signifie que le refus pro-
vient des directives de contrôle d'accès – comme Allow
(Autoriser) et Deny (Refuser) – dans les sections <Direc-
tory> ou <Location> de cette URL, figurant dans les
fichiers de configuration Apache.
Une déclaration "Directory index forbidden by rule" (Index
de répertoire interdit par la règle) dans le journal des
erreurs signale que vous avez tenté de consulter un réper-
toire dans lequel ne se trouvait aucun fichier d'index.
Pour en savoir plus sur l'indexation des répertoires et les

fichiers d'index, consultez l'option Indexes de la directive
Options (voir Chapitre 6).
Options ExecCGI is off in this directory
Quand vous tentez d'exécuter un script CGI, le message

"Options ExecCGI is off in this directory" (Options ExecCGI
désactivées dans ce répertoire) peut s'afficher. Cela signifie
que le CGI n'est pas signalé comme exécutable dans le
fichier de configuration Apache ou que les scripts CGI ne
peuvent pas être exécutés à partir du répertoire en ques-
tion. Renseignez-vous sur les directives ScriptAlias ou
Options pour en savoir plus.
Erreurs internes au serveur

Les erreurs internes au serveur sont celles qui empêchent
Apache de répondre à une requête.
Erreurs de segmentation
"child pid xxx exit signal Segmentation Fault (11)"
Une erreur de segmentation peut survenir dans les cas sui-

vants : le serveur Apache tente d'accéder à des zones de
mémoire appartenant à d'autres processus système, ou bien
le système rencontre une instruction malformée ou inter-
dite dans le processus Apache. La situation est due soit à
un bogue (généralement présent dans des bibliothèques
ou des modules expérimentaux mal écrits), soit à une
panne matérielle (habituellement dans la mémoire, le
chipset, le bus ou le processeur).
Erreurs internes au serveur 39
Fin prématurée des en-têtes de script

[error] [client 192.168.200.3] Premature end of
script headers: /usr/local/apache/cgi-bin/test-cgi
Une erreur "Premature end of script headers" (Fin prématurée

d'en-tête de script) est due à l'exécution incomplète d'un
script CGI. En effet, il faut que le programme CGI dis-
pose des autorisations d'exécution et que l'interpréteur de
la première ligne du script pointe vers le bon programme.
Cette erreur peut apparaître, par exemple, si votre script
affiche #!/usr/local/bin/perl sur sa première ligne alors
que l'interpréteur Perl est situé à /usr/bin/perl.
Ces erreurs sont généralement dues à un arrêt anormal du
programme, avant même que le script n'ait renvoyé des
données. Les pannes peuvent également relever d'autres
éléments, notamment des erreurs dans le code ou l'absence
de certaines bibliothèques auxquelles le programme est lié.
Parfois, le système d'exploitation ou Apache peuvent ter-
miner le processus s'il consomme trop de ressources
(mémoire, temps d'unité centrale), comme nous le ver-
rons au Chapitre 9.
En-têtes "mal formés"

[error] [client 192.168.200.3] malformed header from script.
Bad header=xxx: /usr/local/apache/cgi-bin/exemple.cgi
Une erreur "en-tête mal formé" apparaît dans un script

lorsque les en-têtes n'ont pas le format approprié (généra-
lement du fait d'une erreur de programmation). Le ser-
veur Apache attend une réponse de script commençant
par zéro, ou plusieurs en-têtes, suivis d'une ligne vide.
Autres fichiers pour la

journalisation des erreurs
RewriteLog /usr/local/apache/logs/rewrite_log
RewriteLogLevel warn
SSLLog /usr/local/apache/logs/ssl_log
SSLLogLevel warn
ScriptLog logs/cgi_log
Plusieurs modules, notamment le module Apache 1.3 SSL,
mod_rewrite et mod_cgifournissent leurs propres directives
pour consigner des données spécifiques au module dans
un fichier séparé.
Les redirections
ne fonctionnent pas
UseCanonicalName off
Si votre serveur Apache devient inaccessible dès que le
serveur émet une redirection, cela peut être dû au fait que
le nom canonique de votre hôte est inaccessible depuis
l'extérieur de votre réseau, ou est incorrect.
Par exemple, un ServerName réglé sur localhost, 127.0.0.1,
ou sur une adresse privée, sera inaccessible si le serveur
redirige l'utilisateur vers une URL fondée sur ces valeurs.
Pour résoudre ce problème, fournissez un ServerName
valide, ou réglez UseCanonicalName sur "off", de sorte que
les URL autoréférentielles se construisent avec le nom
d'hôte fourni par le client. Ce problème survient fré-
quemment sur les machines se trouvant derrière un proxy
inverse (voir Chapitre 10).
Liste de vérification
pour le dépannage
Cette section résume certains des problèmes les plus fré-
quents survenant lors du dépannage d'Apache.
Démarrage du serveur
Si vous ne parvenez pas à démarrer le serveur, consultez
le journal des erreurs pour obtenir des informations sur les
causes de la panne.
Si un autre serveur fonctionne déjà à cette adresse, optez
pour une combinaison port/adresse différente.
Si vous ne disposez pas des autorisations nécessaires pour
vous connecter au port demandé, lancez Apache en tant
que superutilisateur (racine), de sorte à accéder aux ports
privilégiés. Si Apache ne parvient pas à ouvrir les fichiers
de configuration ou de journal, vérifiez qu'ils appartien-
nent bien à l'utilisateur qui a installé Apache et que
celui-ci possède l'autorisation d'y écrire.
Connexion au serveur
Si vous tentez d'accéder à une page du serveur et qu'elle
ne s'affiche pas, vous devez d'abord déterminer si l'erreur
provient du serveur, du réseau ou du navigateur.
Vérifiez qu'Apache s'exécute à l'aide de ps, netstat ou du
Gestionnaire de tâches (sous Windows). Il est aussi possi-
ble que le serveur ne s'exécute pas du tout.
Vérifiez ensuite que vous pouvez vous connecter à Apa-
che à partir de la machine locale. Pour cela, utilisez Telnet
pour vous connecter directement au serveur et émettre
une requête test. Vérifiez ensuite qu'Apache fonctionne
sur la combinaison adresse/port correcte. Si vous pouvez

accéder au serveur au niveau local, mais pas à distance, il
est probable qu'Apache écoute sur une adresse ou un port
locaux qui ne sont pas accessibles à distance. Utilisez nets-
tat ou lsof pour déterminer les adresses sur lesquelles
Apache écoute et vous assurer qu'elles sont correctes.
Vérifiez que votre pare-feu ou votre routeur sont correc-
tement configurés. Si Apache écoute sur l'adresse correcte
mais qu'il soit inaccessible en dehors de votre réseau, il est
possible que le trafic réseau vers votre serveur Apache soit
bloqué. Servez-vous de l'utilitaire traceroute (tracert
sous Windows) pour tester la connectivité du réseau entre
les hôtes en question. De nombreux systèmes d'exploita-
tion empêchent par défaut l'accès depuis l'extérieur,
excepté sur certains ports sélectionnés. Si vous exécutez
Apache sur un port non standard, il y a des chances que
vous vous retrouviez bloqué. La résolution de ce pro-
blème varie selon les distributions. Vous pouvez, par
exemple, utiliser l'outil system-config-securitylevel sur
les systèmes Fedora, et l'outil Windows Firewall dans le
Panneau de configuration Windows.
Enfin, si vous utilisez Secure Sockets Layer (SSL) pour accé-
der au serveur (voir Chapitre 7) et que vous vous connec-
tez à l'aide de versions plus anciennes du navigateur ou
que vous exécutez des configurations inhabituelles, con-
sultez le journal d'erreurs à la recherche de problèmes liés
au cryptage de données SSL.
Documents introuvables
Si vous parvenez à accéder au serveur mais que vous obte-
nez une erreur de type "Document Not Found" (Document
introuvable), vérifiez que le document existe bien dans le
système de fichiers.
Vérifiez ensuite que la requête a atteint le serveur, en

consultant le fichier access_log. Si plusieurs instances
d'Apache s'exécutent simultanément, prenez garde à ne
pas vous connecter au mauvais serveur.
Vérifiez ensuite que vos directives Alias pointent vers le
bon endroit, c'est-à-dire l'emplacement où se trouvent
vos documents cibles. Assurez-vous que vous n'avez pas
mal orthographié ou accidentellement supprimé le réper-
toire cible.
Enfin, partez à la recherche des redirections incorrectes.
Vérifiez notamment que les barres obliques de fin sont
bien présentes et testez les problèmes liés à ServerName
décrits plus tôt dans ce chapitre.
Accès interdit
Si un document existe bel et bien mais que son accès vous
est refusé ("Access Forbidden"), vérifiez quelques points de
base.
Assurez-vous que le propriétaire du processus Apache dis-
pose de l'autorisation de lire le fichier.
Vérifiez que le propriétaire du processus Apache possède
des autorisations de lecture et d'énumération pour tous les
répertoires figurant sur le chemin menant au fichier.
Vérifiez que vous ne tentez pas d'accéder à un répertoire ne
contenant pas de fichier d'index alors que les listings de réper-
toire sont interdits dans le fichier de configuration Apache.
Vérifiez que la requête répond à toutes les exigences sti-
pulées par les directives de contrôle d'accès du fichier de
configuration Apache.
Si vous tentez d'accéder à un script CGI, vérifiez qu'il a
reçu des autorisations en lecture et en exécution.
Erreurs internes au serveur

Si vous obtenez une "Internal Server Error" (Erreur interne
au serveur) dans votre navigateur lorsque vous tentez de
charger une page du serveur Web, consultez le fichier
error_log d'Apache pour tenter d'en trouver la cause. Et
posez-vous les questions suivantes :
Tentez-vous d'accéder à un programme CGI ? Possède-t-il
les autorisations de lecture et d'exécution appropriées ? Le
chemin vers l'interpréteur à la première ligne du script
est-il correct ? L'interpréteur est-il désigné comme étant
un script CGI par une directive ScriptAlias ou une
directive de même type ?
Si tout le reste a échoué

Vous avez découvert dans ce chapitre les problèmes les
plus communs rencontrés par les utilisateurs d'Apache. Si
toutefois une erreur non répertoriée ici survient, la pre-
mière chose à faire est de vérifier les journaux d'erreurs.
Si nécessaire, augmentez le LogLevel du serveur Apache
pour trouver des indices sur la nature du problème.
Consultez la documentation Apache, les listes de diffusion
et la base de données des bogues. En dernier ressort, vous
pouvez envoyer votre question à la liste de diffusion des
utilisateurs Apache, à l'adresse suivante :
http://httpd.apache.org/lists.html#http-users
Toutefois, essayez de respecter le "règlement" qui stipule

que vous devez d'abord essayer de trouver vous-même
une solution, puis regrouper suffisamment d'informations
pour que les autres puissent vous aider !
3
Journaux et
surveillance
Introduction à la consignation
des erreurs dans Apache
Outre la fonction de consignation des erreurs décrite au
Chapitre 2, Apache propose diverses possibilités pour
enregistrer des informations concernant tous les aspects
d'une requête. Ce chapitre décrit les problèmes les plus
fréquents survenant lors de la consignation des requêtes :
consignation conditionnelle, rotation des journaux,
résolution des adresses IP et consignation de type "pipe".
Il traite également de plusieurs modules et utilitaires inté-
grés et tiers, destinés à surveiller la situation de votre ser-
veur Apache et à analyser ses journaux.
46 CHAPITRE 3 Journaux et surveillance
Fichiers journaux Apache

par défaut
Apache propose plusieurs fonctions de surveillance et de
consignation qui permettent de s'assurer du bon fonction-
nement du serveur. La configuration par défaut d'Apache
propose deux fichiers journaux, placés dans le répertoire
logs du répertoire d'installation :
b Le fichier access_log (access.log dans Windows).
Contient des informations sur les requêtes ayant été
desservies par le serveur, comme l'URL demandée ou
l'adresse IP du client, et indique si la requête a réussi
ou a échoué.
b Le fichier error_log (error.log dans Windows).
Contient des informations liées aux conditions de
l'erreur, ainsi que différents événements du cycle de
vie du serveur.
Création des formats de journaux

LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%h %l %u %t \"%r\" %>s %b"
\"%{Referer}i\" \"%{User-agent}i\"" combined
La directive LogFormat permet de signaler à Apache les

aspects de la requête à enregistrer. Des directives supplé-
mentaires sont requises pour indiquer à Apache l'endroit
où ces informations doivent être consignées, mais cela sera
traité à la section suivante. Cet exemple montre la confi-
guration des deux formats les plus populaires, Common
Log Format (Format de journal commun) et Combined Log
Format (Format de journal combiné). Quand Apache reçoit
une requête, il remplace chacun des champs dont le pré-
fixe est un signe % par l'attribut de requête correspondant.
Création des formats de journaux 47
Si vous utilisez CLF (Combined Log Format), chaque

entrée de votre fichier journal ressemblera à ceci :
192.168.200.4 - utilisateur [12/Jun/2005:08:33:34
+0500] "GET /exemple.png HTTP/1.0" 200 1234
Si vous employez le format commun combiné, chaque

entrée de votre fichier journal ressemblera à ceci :
192.168.200.4 – utilisateur [12/Jun/2005:08:33:34
http://www.exemple.com/index.html "Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.7.7)"
Voici la description des champs les plus importants :

b %h. L'adresse IP du client qui a envoyé la requête au
serveur Web, ou le nom d'hôte du client si vous avez
activé HostNameLookups (192.168.200.4 dans cet
exemple).
b %u. L'identifiant de l'utilisateur qui a envoyé la requête
déterminée par l'authentification HTTP (utilisateur
dans cet exemple). Consultez le Chapitre 6 pour en
savoir plus sur la configuration de l'authentification
fondée sur HTTP.
b %t. L'heure à laquelle la requête est parvenue au
serveur.
b %r. Le texte de la ligne de requête initiale du client
comprenant la méthode HTTP utilisée, la ressource
demandée et la version du protocole HTTP employée
par le navigateur du client ("GET /exemple.png
HTTP/1.0" ici).
b %>s. Le code de statut de la requête HTTP finale que
le serveur Web envoie au client (200 dans cet exem-
ple, ce qui signifie que la requête s'est terminée avec
succès).
b %b. La taille, en octets, de l'objet envoyé au client en

réponse à la requête, en excluant les en-têtes de
réponse (1234 dans cet exemple).
Le format de journal combiné contient deux champs de

plus que le format de journal commun :
b %{Referer}i. L'en-tête de la requête HTTP Referer,
c'est-à-dire la page Web qui a fait référence au docu-
ment actuel (http://www.exemple.com/index.html
dans cet exemple).
b %{User-agent}i. L'en-tête de la requête HTTP
User-agent. Il contient des informations sur le naviga-
teur du client ("Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.7.7)" dans cet exemple).
Création d'un fichier journal

personnalisé
CustomLog logs/access_log common
TransferLog logs/sample.log
Vous pouvez créer de nouveaux fichiers journaux, en

complément de ceux proposés dans Apache. Cet exemple
utilise CustomLog pour créer un nouveau fichier journal et
stocker les informations d'un fichier journal précédem-
ment défini appelé common (vu à la section précédente).
Vous pouvez remplacer le nom par la définition du format
elle-même. Une directive supplémentaire plus simple,
TransferLog, extraira simplement la définition fournie par
la dernière directive LogFormat.
Redirection des journaux vers un programme externe 49
Redirection des journaux

vers un programme externe
TransferLog "|bin/rotatelogs /var/logs/apachelog 86400"
Vous pouvez également utiliser CustomLog ou TransferLog

pour rediriger ("pipe") le résultat du journal vers un pro-
gramme externe plutôt que vers un fichier. Pour cela,
commencez par le caractère pipe ("|"), suivi du chemin
vers le programme qui recevra les informations de journal
sur son entrée standard. Cet exemple met en œuvre le pro-
gramme rotatelogs, livré avec Apache (qui sera décrit dans
une section ultérieure).
Lorsque vous employez un programme externe, il s'exécute
sous le nom de l'utilisateur qui a démarré httpd. Il s'agit de
la racine si le serveur a été démarré par la racine ; assu-
rez-vous que le programme est sécurisé. De même, lorsque
vous entrez un chemin de fichier sur des plates- formes dif-
férentes d'UNIX, prenez soin de n'employer que des barres
obliques (même si les barres obliques inversées sont autori-
sées). D'une façon générale, il est conseillé de toujours uti-
liser des barres obliques dans les fichiers de configuration.
Consignation conditionnelle
de requêtes
SetEnvIf Request_URI "(\.gif|\.jpg)$" image
CustomLog logs/access_log common env=!image
SetEnvIf Remote_Addr 192\.168\.200\.5 specialmachine
CustomLog logs/special_access_log common env=specialmachine
Vous pouvez décider de consigner une requête selon qu'il

existe ou non une variable d'environnement. Cette varia-
ble peut avoir été précédemment définie en fonction de
plusieurs paramètres, notamment l'adresse IP du client ou

la présence d'un en-tête donné dans la requête. Nous le
voyons dans l'exemple, la directive CustomLog peut accep-
ter une variable d'environnement comme troisième argu-
ment. L'entrée ne sera consignée que si la variable existe.
Si la variable d'environnement est niée par un préfixe "!",
l'entrée ne sera consignée que dans le cas où la variable est
absente. L'exemple montre comment éviter de consigner
des images aux formats GIF et JPEG, et comment consi-
gner des requêtes d'une adresse IP particulière dans un
fichier journal séparé. Consultez la section suivante pour
en découvrir un autre exemple.
Surveillance des personnes

se connectant à votre site
SetEnvIfNoCase Referer www\.exemple\.com internalreferral
LogFormat "%{Referer}i -> %U" referer
CustomLog logs/referer.log referer env=!internalreferral
Pour surveiller les personnes qui se connectent à votre

site Web, vous pouvez consigner l'en-tête Referer: de la
requête. Cet en-tête contient l'URL pointant vers la
page demandée. Même s'il n'est pas toujours présent ni
précis, il fonctionne dans la majorité des cas. Cet exem-
ple montre comment utiliser une variable d'environne-
ment pour consigner les informations de la référence
(referrer) dans un fichier séparé. Dans ce cas particulier,
nous souhaitons simplement consigner les références
externes, et non celles provenant d'une page Web interne.
Pour cela, nous vérifions ici que la référence correspond
à notre propre domaine.
Surveillance d'Apache avec mod_status 51
Surveillance d'Apache
avec mod_status
<Location /server-status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from 192.168.0
</Location>
Le module mod_status fournit à l'administrateur des

informations sur l'activité et les performances du ser-
veur. Une page HTML s'affiche, proposant les statisti-
ques du serveur sous une forme facilement lisible (le
nombre de workers répondant à des requêtes, le nombre
de workers inactifs, l'heure à laquelle le serveur a été
démarré ou redémarré, etc.).
La directive ExtendedStatus On permet d'obtenir d'autres
informations, par exemple la situation de chaque worker,
le nombre total d'accès, les requêtes actuelles traitées, etc.
N'oubliez pas que cet enregistrement de statistiques sup-
plémentaires peut considérablement ralentir le serveur.
Cet exemple montre comment activer la surveillance
mod_status, tout en limitant l'accès aux informations à cer-
taines adresses IP uniquement. Vous pouvez alors accéder
aux statistiques du serveur à l'aide d'un navigateur Web, en
vous rendant sur la page http://www.exemple.com/
server-status.
Surveillance d'Apache avec SNMP

Il existe deux modules Open Source qui ajoutent des
fonctionnalités SNMP (Simple Network Management Proto-
col) au serveur Web Apache. Ce protocole sert souvent à
gérer les serveurs réseau et l'équipement d'une console
centrale, comme HP OpenView et Tivoli. Le module
permet de surveiller facilement les performances d'Apache
en temps réel, notamment le temps de fonctionnement du
serveur, la charge moyenne, le nombre d'erreurs sur une
période donnée, le nombre d'octets et de requêtes desser-
vis, ainsi que de nombreux autres paramètres. Les modu-
les SNMP peuvent aussi générer des alarmes lorsque l'on
atteint un certain seuil ou une condition d'erreur, par
exemple en cas d'augmentation soudaine du nombre
simultané de connexions client.
Pour Apache 1.3, vous pouvez utiliser mod_snmp, qui se
trouve à l'adresse http://www.mod-snmp.com/. Ce
module prend en charge SNMP versions 1 et 2. Il nécessite
un correctif sur le cœur ("core") d'Apache.
Pour Apache 2, il existe un module analogue, appelé
mod_apache_snmp. Vous le trouverez à l'adresse http://
www.mod-apache-snmp.sourceforge.net/. Il prend
en charge les versions 1, 2 et 3 du protocole SNMP et
peut être compilé sous forme de DSO, sans qu'il soit
besoin de placer un correctif sur Apache.
Plusieurs outils et structures Open Source permettent de
gérer les ressources SNMP. Voyez notamment ceux qui
se trouvent aux adresses http://www.net-snmp.org,
OpenNMS (http://www.opennms.org) et Nagios
(http://www.nagios.org).
Analyse des journaux à l'aide d'outils Open Source 53
Analyse des journaux

à l'aide d'outils Open Source
Il existe plusieurs outils commerciaux et Open Source
permettant de traiter et d'afficher les données du journal.
Ils procèdent souvent de cette manière : ils extraient un
fichier journal, analysent son contenu, puis créent une
série de pages Web présentant les statistiques pertinentes.
Voici quelques applications très connues, disponibles gra-
tuitement et en Open Source, pour analyser les journaux :
b Webalizer (http://www.mrunix.net/webalizer/) ;
b AWStats (http://awstats.sf.net).
D'autres outils permettent de traiter les journaux plus en

détail, par exemple en affichant visuellement le chemin
emprunté par vos visiteurs :
b Visitors (http://www.hping.org/visitors/) ;
b Pathalizer (http://pathalizer.bzzt.net/).
Surveillance de vos journaux

en temps réel
En plus de mod_status et des divers modules SNMP
décrits précédemment, un outil de ligne de commande,
dénommé apachetop, peut être téléchargé à l'adresse
http://clueful.shagged.org/apachetop.
Il fonctionne à la manière de l'outil de ligne de commande
top d'UNIX. Cependant, au lieu d'afficher la situation du
système d'exploitation, il montre celle du serveur Web en
temps réel.
Si vous exécutez Apache sur un système UNIX et que

vous disposiez d'un site Web connaissant peu de trafic,
l'utilitaire de ligne de commande tail suffit pour sur-
veiller les entrées de vos journaux d'accès et d'erreurs,
mais de manière rudimentaire et en temps réel :
tail -f fichierjournal
D'autres programmes permettent d'identifier rapidement

les problèmes en analysant les journaux d'erreur, à la
recherche d'erreurs spécifiques, de requêtes mal formées,
etc., puis de les signaler :
b Logscan (http://www.garand.net/security.php) ;
b ScanErrLog (http://www.librelogiciel.com/soft-
ware).
Consignation des requêtes

dans une base de données
Apache ne dispose pas d'outils permettant de consigner
des informations vers des bases de données, mais il existe
quelques scripts et modules tiers :
b mod_log_sql vous permet de consigner des requêtes
directement dans une base de données MySQL. Vous le
trouverez à l'adresse http://www.outoforder.cc/
projects/apache/mod_log_sql/.
b Vous pouvez ensuite interroger la base de données à
l'aide de l'outil LogView SQL d'Apache (http://
freshmeat.net/projects/apachelogviewsql/).
b pglogd collecte les journaux et conserve les entrées dans
une base de données PostgreSQL. Vous le trouverez à
l'adresse http://www.digitalstratum.com/pglogd/.
Rotation et archivage des journaux 55
Rotation et archivage des journaux

CustomLog "|bin/rotatelogs /var/logs/apachelog
86400" common
Si votre site Web fait l'objet d'un trafic important, vos
fichiers journaux vont grossir. Vous pouvez bien sûr les
archiver manuellement. Cependant, vous disposez de
plusieurs mécanismes permettant de procéder à une rota-
tion périodique, d'archiver et de compresser les anciens
journaux à intervalles définis.
Pour éviter d'arrêter ou redémarrer le serveur lorsque
vous manipulez les fichiers journaux, vous pouvez utiliser
un programme intermédiaire qui consignera les requêtes.
Il se chargera ensuite de la rotation, de la compression et
de l'archivage des journaux.
Pour cela, Apache propose l'outil rotatelogs. Vous trou-
verez un programme analogue à l'adresse http://crono-
log.org/.
Cet exemple fait appel à l'outil rotatelogs pour créer un
nouveau fichier journal et déplacer quotidiennement le
journal actuel vers le répertoire /var/logs (il y a 86 400
secondes dans une journée). Consultez la documentation
Apache pour en savoir plus sur l'utilisation de rotatelogs
et la façon de procéder à la rotation des journaux, en
fonction de la taille et du nom des fichiers archivés en se
basant sur un modèle.
Attention
Si le chemin pointant vers le programme de rotation des jour-
naux comprend des espaces, vous devrez peut-être les annuler
en les faisant préfixer par une barre oblique inversée (\). Cela
est particulièrement courant sous Windows.
Contrôle de la résolution
des adresses IP
HostNameLookups on
Si la directive HostNameLookups est réglée sur on, Apache

tente de déterminer (résoudre) le nom d'hôte correspon-
dant à l'adresse IP du client lorsqu'il consigne la requête.
Avec HostNameLookups réglé sur off, une entrée access_log
peut ressembler à ceci :
192.168.200.4 – utilisateur [12/Jun/2005:08:33:34
Si la directive est réglée sur on, cette même entrée ressem-

blera à ceci :
unit12.exemple.com - utilisateur [12/Jun/2005:08:33:34
La section suivante explique le processus inverse,

c'est-à-dire comment remplacer des adresses IP dans des
journaux par des noms d'hôtes.
Traitement d'adresses IP
consignées
$ logresolve < access_log > resolved_log
Régler HostNameLookups sur on peut avoir un effet sur les

performances du serveur, notamment en allongeant les
délais de réponse. Pour éviter d'utiliser ce paramètre, vous
pouvez désactiver la résolution des noms et adopter un
utilitaire de post-traitement indépendant, capable d'analyser
les fichiers journaux et de remplacer les adresses IP par des
Redémarrage automatique d'Apache en cas de panne 57
noms d'hôtes. Ces outils sont plus efficaces, car ils placent
les résultats en cache et n'entraînent pas de délais lors de la
réponse aux requêtes des clients.
Apache propose un outil de ce type, intitulé logresolve
(logresolve.exe dans Windows), qui lit les entrées du
journal à partir de l'entrée standard et produit le résultat
inverse sur la sortie standard. Pour lire de et vers un
fichier, vous pouvez utiliser la redirection, sous UNIX et
Windows, comme indiqué dans l'exemple.
N'oubliez pas que le résultat d'une résolution d'adresse IP
ne correspondra pas toujours au nom de l'hôte qui a
véritablement envoyé la requête. Ainsi, par exemple, s'il
existe un proxy ou une passerelle entre le client et le ser-
veur Web, l'adresse IP signalée par HostNameLookups ou
logresolve correspondra à l'adresse IP du proxy ou de la
passerelle. Vous obtiendrez alors le nom d'hôte du serveur
proxy ou du bloc IP géré par la passerelle, plutôt que le
nom d'un hôte réel.
Redémarrage automatique
d'Apache en cas de panne
#!/bin/bash
if [ `ps -waux | grep -v grep | grep -c httpd` -lt 1 ];
then apachectl restart; fi
Si vous installez Apache sous Windows sous forme de ser-

vice, sachez que vous pouvez le redémarrer automatique-
ment, en cas de panne, à l'aide du gestionnaire de services.
Sous UNIX, vous pouvez installer cette fonctionnalité
au moyen d'un script de surveillance ("watchdog", ou chien
de garde) qui contrôle le statut d'un autre programme.
Si, pour quelque raison que ce soit, le programme s'arrête

le script de surveillance le redémarre. L'exemple montre
un simple script Linux qui surveille la liste des processus
système, afin de s'assurer qu'il existe un processus httpd ;
en cas d'arrêt, un redémarrage est effectué. Pour l'utiliser,
vous devez lui attribuer des autorisations d'exécution, puis
l'ajouter à votre configuration cron de sorte qu'il soit exé-
cuté à intervalles prédéfinis.
Sous Solaris, utilisez ps -ef au lieu de ps -waux.
Vous trouverez à l'URL http://perl.apache.org/docs/
general/control/control.html un script de surveillance
plus sophistiqué, capable d'envoyer un e-mail lorsque le
serveur est tombé et de surveiller les identifiants de proces-
sus httpd spécifiques.
La plupart des distributions de Linux comprennent égale-
ment leur propre script de surveillance générique, pouvant
être adapté à Apache.
Fusion et séparation de fichiers

journaux
Lorsqu'une grappe de serveurs Web dessert un même
contenu, il est souvent nécessaire de fusionner tous les jour-
naux de tous les serveurs en un seul fichier journal avant de
le transférer aux outils d'analyse. De même, si un seul ser-
veur Apache gère plusieurs hôtes virtuels, il faut parfois
diviser un fichier journal en plusieurs fichiers différents, un
pour chaque hôte virtuel. Cela peut être réalisé au niveau
du serveur Web (nous le verrons à la section suivante) ou
par un post-traitement du fichier journal. Apache 1.3 et 2.x
sont livrés avec un fichier de script de prise en charge,
nommé split-logfile. Celui-ci se trouve dans le réper-
toire support/ de la distribution de la source Apache.
Conservation de fichiers séparés pour chaque hôte virtuel 59
Le projet logtool propose une suite d'outils de manipula-

tion des journaux, qui se trouve à l'adresse http://www
.coker.com.au/logtools/.
L'outil vlogger permet de séparer un flux de journal en
plusieurs fichiers journaux spécifiques à un hôte virtuel,
ainsi que de remplacer des outils comme cronolog (nous
l'avons fait à la section précédente). Il se trouve à l'adresse
http://n0rp.chemlab.org/vlogger/.
Conservation de fichiers séparés

pour chaque hôte virtuel
<VirtualHost 192.168.200.3>
ServerName vhost1.exemple.com
CustomLog logs/vhost1.exemple.com_log combined
ErrorLog logs/vhost2.exemple.com_log
.......
</Virtual Host>
Vous pouvez conserver des journaux d'accès séparés pour

chaque hôte virtuel, à l'aide d'une directive CustomLog
insérée dans une section <VirtualHost> (nous le voyons
dans l'exemple).
Vous pouvez aussi choisir de consigner les opérations de
tous les hôtes virtuels dans le fichier access_log défini
dans le contexte du serveur global :
LogFormat "%v %h %l %u %t \"%r\" %>s %b"
common_virtualhost
CustomLog logs/access_log common_virtualhost
%v consignera le nom de l'hôte virtuel qui dessert la

requête.
Vous pouvez ensuite utiliser les outils décrits à la section
précédente pour traiter le fichier journal de résultat,
notamment si vous disposez d'un grand nombre d'hôtes
virtuels.
Si vous ne voulez pas assurer le suivi des opérations d'un

hôte particulier, vous pouvez simplement employer :
CustomLog /dev/null
Entrées de journaux communes

En plus des informations indiquées au Chapitre 2, cette
section décrit plusieurs entrées de journal relatives à cer-
taines erreurs communes pouvant apparaître lorsque vous
consultez vos fichiers journaux. La plupart peuvent être
ignorées sans problème.
Fichier favicon.ico introuvable

(File favicon.ico Not Found)
La plupart des navigateurs Web récents acceptent l'affi-
chage d'une icône personnalisée près de la barre d'empla-
cement du navigateur ou lors du stockage d'un signet.
Pour cela, le navigateur exige un fichier spécifique du site
Web (favicon.ico). Si ce fichier n'existe pas, il renvoie
une erreur. Vous en saurez plus sur cette icône en vous
reportant au Chapitre 1.
Fichier robots.txt introuvable

(File robots.txt Not Found)
Le fichier robots.txt est nécessaire à certains program-
mes, comme les outils de téléchargement automatique
et les robots Web, lorsqu'ils accèdent à votre site Web.
Ces programmes analysent les sites Web, en suivant et en
téléchargeant tous les liens qu'ils trouvent de manière
récursive. Ils sont souvent associés à des moteurs de recher-
che. Leur principal objectif est de stocker et d'indexer le
contenu récupéré. Si le fichier robots.txt est absent, une
erreur de ce type est renvoyée.
Entrées de journaux communes 61
httpd.pid écrasé (httpd.pid Overwritten)

Sous UNIX, le fichier httpd.pid contient le PID (identi-
fiant de processus) du processus Apache en cours d'exécu-
tion. Il est créé au démarrage d'Apache et supprimé à sa
fermeture. Si Apache n'est pas correctement fermé (par
exemple si le serveur a dû être arrêté manuellement), ou
en cas d'erreur, le fichier n'est pas supprimé. Il subsistera
donc au prochain démarrage du serveur et cette erreur
sera renvoyée.
Requêtes "longues et étranges"

Il est possible que vous rencontriez des requêtes étranges,
comme celle-ci, dans votre journal d'erreurs :
"SEARCH /\x90\x02\xb1\x02\xb1\x02\xb1\x02 ..."
"GET /scripts/..%252f../winnt/system32/cmd.exe?/
c+dir HTTP/1.0..."
"GET /default.ida?NNNNNNN NNNNNNNNNNNNNNNNNN ..."
Ou encore des requêtes de fichiers exécutables qui n'exis-

tent pas sur votre site, comme cmd.exe, root.exe, dir, etc.
Certaines entrées de journal naissent de tentatives auto-
matisées pour exploiter les vulnérabilités des serveurs
Web. Par chance, la plupart étant générées par des vers ou
d'autres applications malveillantes spécifiques à Microsoft
Internet Information Server sous Windows, Apache n'en
est pas affecté. Toutefois, de temps en temps, des défauts
sont découverts dans Apache ; cela peut le rendre vulné-
rable à des attaques distantes. Il est donc recommandé
d'actualiser votre serveur Apache (voir Chapitre 6).
4
Mappage d'URL et
contenu dynamique
Mappage d'URL
Ce chapitre explique comment configurer Apache pour
mapper (mettre en correspondance) des requêtes avec des
fichiers et des répertoires, ou les rediriger vers des pages
ou des serveurs spécifiques. Ces informations sont utiles
pour résoudre des problèmes habituels, par exemple :
continuer à travailler avec des URL lorsque la structure
du site change, traiter les sites Web sensibles à la casse,
prendre en charge plusieurs langues, etc. Nous explique-
rons également comment utiliser le CGI et les fonction-
nalités SSI présentes dans Apache de manière à fournir un
contenu généré de manière dynamique.
64 CHAPITRE 4 Mappage d'URL et contenu dynamique
Mappage d'URL et de fichiers

avec Alias
Alias /icons/ /usr/local/apache2/icons/
Il n'est pas nécessaire que la structure d'un site Web cor-

responde à la disposition des fichiers sur disque. En effet,
la directive Alias permet d'effectuer la correspondance
entre des répertoires sur disque et des URL spécifiques.
Grâce à cette directive, une requête pour http://www
.exemple.com/icons/image.gif amène Apache à recher-
cher le fichier du répertoire /usr/local/apache2/icons/
image.gif (au lieu de la racine des documents par défaut
dans /usr/local/apache2/htdocs/icons/image.gif).
Attention, les barres obliques de fin de la directive Alias
sont importantes. Si vous les incluez, la requête client doit
également les faire figurer, faute de quoi la directive n'aura
aucun effet. Par exemple, si vous utilisez la directive sui-
vante :
Alias /icons/ /usr/local/apache2/icons/
et que vous demandez http://www.exemple.com/icons, le

serveur renverra une erreur "404 Document Not Found".
Mappage de motifs d'URL

à des fichiers avec AliasMatch
AliasMatch ^/(docs|help) /usr/local/apache/htdocs/manual
La directive AliasMatch présente un comportement ana-

logue à Alias, mais elle permet de préciser une expression
régulière pour l'URL. Les correspondances peuvent être
Redirection d'une page vers un autre emplacement 65
remplacées dans le chemin de destination. Par exemple,

cette directive désignera n'importe quelle URL sous
/help ou /docs pointant vers les chemins du système de
fichiers du répertoire manual. Les expressions régulières
sont des chaînes permettant de décrire un jeu de chaînes
ou qui concordent avec lui, et ce en fonction de certaines
règles de syntaxe. Vous en saurez plus sur les expressions
régulières à l'adresse http://fr.wikipedia.org/wiki/
Expression_r%C3%A9guli%C3%A8re.
Redirection d'une page

vers un autre emplacement
Redirect /news http://news.exemple.com
Redirect /latest /3.0
La structure d'un site Web ordinaire change avec le temps.

Vous ne pouvez pas toujours contrôler la manière dont les
autres sites se lient au vôtre, par exemple en ce qui con-
cerne les moteurs de recherche présentant des liens cassés.
Pour éviter les erreurs lorsque des personnes accèdent à
votre site Web à l'aide de liens anciens, vous pouvez confi-
gurer Apache avec la directive Redirect qui redirige ces
requêtes vers la ressource correcte, qu'elle se trouve sur le
serveur actuel ou un autre. Même si la directive Redirect
peut prendre des arguments optionnels indiquant le type
de redirection (temporaire ou permanente), la syntaxe la
plus commune consiste à fournir une URL d'origine et
une URL de destination. L'URL de destination peut se
trouver sur le même serveur Web ou pointer vers un ser-
veur différent. Dans cet exemple, une requête pour
http://www.exemple.com/news/today/index.html sera redi-
rigée vers http://news.exemple.com/today/index.html.
Redirection vers la dernière

version d'un fichier
RedirectMatch myapp-(1|2)\.([0-9])(\.[0-9])?-(.*)
/myapp-3.0-$4
La directive RedirectMatch est identique à Redirect, mais

elle permet d'utiliser une expression régulière comme
chemin de l'URL d'origine. Cela apporte beaucoup plus
de flexibilité. Prenons l'exemple d'un éditeur de logiciels
qui distribue des téléchargements sur son site Web et
publie les nouvelles versions d'un produit au fil du temps.
Il peut arriver qu'un certain pourcentage d'utilisateurs
continuent à télécharger d'anciennes versions du logiciel
sur des sites Web tiers n'ayant pas encore mis à jour leurs
liens. Grâce à RedirectMatch, ces utilisateurs peuvent
être facilement redirigés vers la version la plus récente.
Supposons que le nom de la dernière version du fichier
téléchargeable soit myapp-3.0. Cet exemple redirige les
requêtes pour http://www.exemple.com/myapp-2.5.1-demo.tgz
vers http://www.exemple.com/myapp-3.0-demo.tgz et les
requêtes pour http://www.exemple.com/myapp-1.2-manual
.pdf vers http://www.exemple.com/myapp-3.0-manual.pdf.
Les trois premiers éléments de l'expression régulière cor-
respondront au numéro principal et au numéro secon-
daire, puis à un numéro de correctif optionnel. Ceux-ci
seront remplacés par 3.0. Le reste du nom du fichier est
extrait du dernier groupe de l'expression régulière et rem-
placé dans l'URL de destination.
Echec de la redirection ou requêtes non autorisées 67
Echec de la redirection
ou requêtes non autorisées
ErrorDocument 404 /search.html
Si vous gérez un site Web populaire ou complexe, quelles

que soient les précautions prises, vous allez recevoir plu-
sieurs requêtes d'URL concernant des documents non
valides ou qui n'existent plus. Même si nombre d'entre
elles peuvent être traitées en faisant bon usage des Redi-
rect, certaines se termineront tout de même par la terrible
réponse "404 Document Not Found". Il peut donc être sou-
haitable de modifier la page d'erreur par défaut d'Apache
et de diriger vos utilisateurs vers un emplacement particu-
lier sur votre site Web. Il peut s'agir d'une page qui aide
vos visiteurs à trouver la ressource demandée, d'une page
de recherche ou d'une carte du site (comme on le voit
dans l'exemple). Dans une note, le Chapitre 6 propose des
informations complémentaires sur la personnalisation
des pages de refus d'accès.
Définition des gestionnaires

de contenu
AddHandler cgi-script .pl .cgi
<Location "/cgi-bin/*.pl">
Options +ExecCGI
SetHandler cgi-script
</Location>
Les gestionnaires permettent à Apache de déterminer les

actions à réaliser sur le contenu demandé. Ce sont les
modules qui proposent des gestionnaires ; Apache doit
être configuré pour associer un contenu à des gestionnai-

res spécifiques. Cette fonctionnalité est souvent annexée
aux modules de génération de contenu, comme PHP et
mod_cgi. L'exemple montre comment associer le gestion-
naire cgi-handler aux fichiers que vous souhaitez exécuter
sous forme de CGI.
La directive AddHandler associe un gestionnaire à certaines
extensions de noms de fichiers. RemoveHandler peut servir
à supprimer des associations préalables. Dans cet exemple,
AddHandler indique à Apache de traiter tous les docu-
ments présentant des extensions cgi ou pl comme des
scripts CGI.
La directive SetHandler permet d'associer un gestionnaire
à tous les fichiers d'un répertoire ou d'un emplacement
particulier. La directive Action, que vous verrez plus loin
dans ce chapitre, associe un type MIME ou un gestion-
naire particulier à un script CGI.
Les types MIME

MIME est un ensemble de normes qui définissent, entre
autres choses, un moyen d'indiquer le type de contenu
d'un document. Des exemples de types MIME sont
text/html et audio/mpeg. Le premier composant du type
MIME correspond à la catégorie principale du contenu
(texte, son, image, vidéo) et le second au type spécifique.
Apache utilise les types MIME, d'une part pour déter-
miner ceux des modules ou des filtres qui traiteront un
certain contenu, d'autre part pour ajouter des en-têtes
HTTP à la réponse, afin d'identifier son type de contenu.
Ces en-têtes serviront à l'application cliente pour identi-
fier et afficher correctement le contenu à destination de
l'utilisateur final.
Configuration des types MIME 69
Configuration des types MIME

AddType text/xml .xml .schema
<Location /xml-schemas/>
ForceType text/xml
</Location>
Comme pour les gestionnaires de contenu, les types
MIME peuvent être associés à certaines extensions de
fichiers ou URL. Cet exemple montre comment associer
le type MIME text/xml aux fichiers se terminant par .xml
et .schema et au contenu de l'URL /xml -schemas/. Par
défaut, Apache contient un fichier mime.types qui com-
prend les types MIME les plus communs et leurs exten-
sions associées.
Les bases de l'exécution

des scripts CGI
CGI signifie Common Gateway Interface (interface de passe-
relle commune). Il s'agit d'un protocole standard utilisé
par les serveurs Web pour communiquer avec des pro-
grammes externes. Le serveur Web fournit toutes les
informations nécessaires sur la requête à un programme
externe, qui la traite et renvoie une réponse. La réponse
est alors envoyée au client. CGI ayant été le premier
mécanisme à générer un contenu unique pour chaque
requête à la volée ("contenu dynamique"), il est pris en
charge par la quasi-totalité des serveurs Web. Apache
accepte les CGI, grâce au module Apache mod_cgi
(mod_cgid lors de l'exécution d'un serveur Apache avec
des threads).
Attention !
Des programmes CGI d'exemple ou mal écrits peuvent consti-
tuer un risque pour la sécurité. Si vous n'utilisez pas cette
fonctionnalité, il est recommandé de la désactiver globalement
(voir Chapitre 6).
Désignation de ressources
comme des CGI exécutables
ScriptAlias /cgi-bin/ /usr/local/apache2/cgi-bin
Cette section présente plusieurs manières d'indiquer à

Apache que le fichier cible d'une requête particulière est
un script CGI. Cela est nécessaire pour éviter qu'Apache
n'envoie directement le contenu d'un fichier au client,
mais renvoie plutôt le résultat de son exécution.
La directive ScriptAlias est semblable à la directive
Alias (décrite plus tôt dans ce chapitre), à la seule diffé-
rence qu'Apache traite chaque fichier du répertoire cible
comme étant un script CGI. De même, vous pouvez uti-
liser n'importe laquelle des sections <Files>, <Location> et
<Directory> en combinaison avec la directive SetHandler
pour indiquer à Apache que le contenu de ces sections
constitue des programmes CGI. Dans ce cas, vous devrez
également fournir une directive Options +ExecCGI pour
indiquer à Apache que l'exécution du CGI est autorisée.
L'exemple suivant demande à Apache de considérer tou-
tes les URL se terminant par une extension de fichier .pl
comme des scripts CGI :
<Location "/cgi-bin/*.pl">
Options +ExecCGI
SetHandler cgi-script
</Location>
Association de scripts à des méthodes HTTP et des types MIME 71
Association de scripts à des

méthodes HTTP et des types MIME
# Traitement de toutes les images GIF via un script CGI
# avant de les servir
Action image/gif /cgi-bin/filter.cgi
# Association de méthodes HTTP spécifiques à un script
# CGI
Script PUT /cgi-bin/upload.cgi
Outre les directives mentionnées dans la section précé-

dente, Apache en propose certaines qui simplifient l'asso-
ciation de types MIME spécifiques, d'extensions de
fichiers, voire de méthodes HTTP spécifiques, à un CGI
particulier. Le module mod_actions, qui figure dans la dis-
tribution de base et qui est compilé par défaut, propose les
directives Action et Script, présentées dans cet exemple :
b La directive Action accepte deux arguments. Le
premier est un gestionnaire ou un type de contenu
MIME ; le second pointe vers le programme CGI
pour gérer la requête.
b La directive Script associe certaines méthodes de
requête HTTP à un programme CGI.
Les informations concernant le document demandé sont

transmises au CGI par les variables d'environnement
PATH_INFO (URL de document) et PATH_TRANSLATED (che-
min de document).
Comme dans l'exemple de la section précédente, le réper-
toire contenant le CGI de destination doit être désigné
comme autorisant l'exécution de CGI avec une directive
ScriptAlias ou le paramètre ExecCGI de la directive Options.
Dépannage relatif à l'exécution

des scripts CGI
ScriptLog logs/cgi_log
En plus des modules et des techniques présentés aux Cha-

pitres 2 et 3, il est à noter que le module mod_cgi propose
la directive ScriptLog pour aider au débogage des scripts
CGI. S'il est activé, il conservera des informations pour
chaque échec d'exécution CGI, notamment les en-têtes
HTTP, les variables POST, etc. Le fichier peut rapide-
ment grossir, mais vous pouvez en limiter la taille grâce
aux directives ScriptLogBuffer et ScriptLogLength.
Amélioration des performances

du script CGI
L'un des principaux inconvénients du développement de
CGI réside dans l'impact qu'il a sur les performances, en
plus de la nécessité de démarrer et d'arrêter des program-
mes à chaque requête. mod_perl et FastCGI sont deux
solutions à ce problème. Tous deux exigent toutefois un
examen minutieux du code existant. En effet, vous ne
pourrez plus supposer que les ressources seront automati-
quement libérées par le système d'exploitation après que la
requête aura été desservie.
mod_perl est un module, disponible pour Apache 1.3
et 2.0. Il intègre un interpréteur Perl dans le serveur Web
Apache. En plus d'une API puissante pour les éléments
internes à Apache, mod_perl bénéficie d'un mode de com-
patibilité CGI, dans lequel les CGI Perl existants peuvent
SSI 73
s'exécuter avec peu, voire pas, de modification. Les scripts

s'exécutant à l'intérieur d'un interpréteur qui persiste dans
le processus, aucune pénalité n'est appliquée au démarrage.
FastCGI est un standard qui permet à une même instance
d'un programme CGI de répondre à plusieurs requêtes au
fil du temps. Vous trouverez les spécifications et pourrez
télécharger les modules pour Apache 1.3 et 2.x à l'adresse
http://www.fastcgi.com. FastCGI a regagné de la popu-
larité après avoir été utilisé dans les structures de dévelop-
pement Web comme Ruby-on-Rails.
SSI
Document on disk
This document, ,
was last modified 
Content received by the browser
This document, sample.shtml,
was last modified Sunday, 14-Sep-2005 12:03:20 PST
SSI est une technologie Web simple, de la "vieille école",

un prédécesseur d'autres langages intégrés HTML, comme
PHP. SSI fournit un mécanisme simple et efficace pour
ajouter facilement des éléments de contenu dynamique, par
exemple un pied de page commun à chaque page indi-
quant la date et l'heure auxquelles la page a été servie. Autre
exemple, la distribution Apache 2.0 utilise SSI pour per-
sonnaliser les messages d'erreur. SSI fonctionne en inté-
grant des instructions de traitement spécifiques dans des
pages Web et en les évaluant avant que le contenu ne soit
renvoyé au client. Vous en saurez plus sur la prise en charge
de SSI par Apache à l'adresse http://httpd.apache.org/
docs/2.0/howto/ssi.html.
Configuration de SSI
AddType text/html .shtml
AddHandler server-parsed .shtml
La fonctionnalité SSI est apportée par le module

mod_include, distribué avec Apache. La manière la plus
simple de le configurer consiste à associer une extension
au gestionnaire de contenu server-parsed, comme indi-
qué dans l'exemple.
Paramétrage des variables

d'environnement
SetEnv foo bar
UnSetEnv foo
PassEnv foo
Les variables d'environnement sont des variables qui peu-
vent être partagées entre des modules et qui sont éga-
lement disponibles pour des processus externes, comme
les CGI et les documents SSI. Les variables d'environne-
ment peuvent également être utilisées pour la communi-
cation entre modules et pour baliser certaines requêtes à
des fins de traitement spécifique.
Vous pouvez paramétrer les variables d'environnement à
l'aide de la directive SetEnv. Ainsi, les variables seront dis-
ponibles pour les scripts CGI et les pages SSI et pourront
être consignées ou ajoutées à un en-tête. Par exemple :
SetEnv foo bar
créera la variable d'environnement foo et lui affectera la
valeur bar.
Paramétrage dynamique des variables d'environnement 75
A l'inverse, vous pouvez supprimer des variables spécifi-

ques, à l'aide de la directive UnsetEnv.
Enfin, la directive PassEnv permet d'exposer des variables
à partir de l'environnement de traitement du serveur. Par
exemple :
PassEnv LD_LIBRARY_PATH
mettra la variable d'environnement LD_LIBRARY_PATH à
disposition des scripts CGI et des pages SSI. Cette variable
contient un chemin vers des bibliothèques dynamiques
chargeables dans certains systèmes UNIX, comme Linux.
Accès à une variable d'environnement

Pour accéder à une variable d'environnement nommée foo
dans une page SSI, tapez :

Sa valeur peut être consignée avec l'option de mise en forme
%{foo}e (voir Chapitre 3) ou ajoutée à un en-tête HTTP (voir
Chapitre 10), avec :
RequestHeader set X-Foo "%{foo}e"
Paramétrage dynamique
des variables d'environnement
SetEnvIf HTTP_USER_AGENT MSIE iexplorer
SetEnvIf HTTP_USER_AGENT MSIE iexplorer=foo
SetEnvIf HTTP_USER_AGENT MSIE !JavaScript
La directive SetEnvIf permet de paramétrer des variables

d'environnement en fonction des informations de la
requête, comme le nom d'utilisateur, le fichier demandé
ou une valeur d'en-tête HTTP spécifique.
Cette directive prend un paramètre de requête, une

expression régulière et un ensemble de variables, qui
sera modifié si le paramètre correspond à l'expression.
Cet exemple concerne les navigateurs Microsoft Internet
Explorer. Il montre comment paramétrer une variable, lui
affecter une valeur arbitraire foo et même lui affecter une
expression de négation.
Par la suite, vous pourrez rechercher l'existence et la
valeur de cette variable pour réaliser diverses actions,
comme la consignation d'une requête spécifique ou l'envoi
d'un contenu différent en fonction du type de navigateur.
Il est possible, par exemple, d'envoyer des pages HTML
simplifiées à des navigateurs texte, comme Lynx, ou à des
navigateurs sur téléphones portables et assistants personnels.
En réalité, la recherche de l'agent utilisateur du client est
tellement commune que le module mod_setenvif propose
la directive BrowserMatch, qui permet d'écrire simplement :
BrowserMatch MSIE iexplorer=1
Info
SetEnvIf et BrowserMatch proposent des versions non sensibles
à la casse (SetEnvIfNoCase et BrowserMatchNoCase) qui peuvent
être utilisées pour simplifier les expressions régulières dans
certaines situations.
Variables d'environnement
spéciales
BrowserMatch "Mozilla/2" nokeepalive
Apache propose un ensemble de variables d'environnement

spéciales. Si l'une d'elles est définie, Apache modifie son
comportement. Elles servent généralement à passer outre
Négociation du contenu 77
des clients qui présentent des bogues. Par exemple, la

variable nokeepalive désactive la prise en charge du main-
tien en activité dans Apache, qui réduit les performances
du serveur (plusieurs requêtes ne pouvant pas être transmi-
ses sur la même connexion). De fait, elle ne doit être para-
métrée que lorsque la requête est réalisée par un client qui
ne prend pas correctement en charge cette fonctionnalité,
généralement à l'aide de l'une des directives BrowserMatch
ou SetEnvIf, comme on le voit dans l'exemple.
Les Chapitres 7 et 8 proposent des exemples de variables
spéciales utilisées pour contourner des problèmes dans les
implémentations SSL et DAV.
Négociation du contenu
AddCharset UTF-8 .utf8
AddLanguage en .en
AddEncoding gzip .gzip .gz
Le protocole HTTP propose des mécanismes permettant

de conserver différentes versions d'une ressource donnée et
de renvoyer le contenu approprié en fonction des capacités
et des préférences du client. Par exemple, un client peut
vous informer qu'il est capable d'accepter un contenu
compressé (même si sa langue de préférence est l'anglais, il
comprendra également les pages écrites en espagnol). Les
trois principaux aspects négociés sont les suivants :
b Le codage. Il s'agit du format dans lequel une
ressource est conservée ou représentée. Il peut géné-
ralement être déterminé à partir de l'extension du
fichier. Ainsi, le fichier listing.txt.gz possède un
type MIME text/plain et un codage gzip. Le codage
de la ressource sera annexé à l'en-tête Content-Enco-
ding: de la réponse.
b Le jeu de caractères. Cette propriété décrit le jeu de

caractères utilisé par un document. Le jeu de caractè-
res de la ressource sera annexé à l'en-tête Content-Type:
de la réponse, avec le type MIME.
b La langue. Vous pouvez proposer différentes versions
de la même ressource. Par exemple, la documentation
Apache propose index.html.en, index.html.es, index
.html.de, etc. La langue de la ressource sera annexée
à l'en-tête Content-Language: de la réponse.
L'exemple montre comment associer des jeux de caractè-

res, des langues et des codages à des extensions de fichiers
particulières.
Configuration de la négociation
du contenu
Options +Multiviews
AddHandler type-map .var
Il existe deux méthodes principales pour configurer la
négociation du contenu dans Apache : le mode Multi-
views et les correspondances de type (type maps).
Le mode Multiviews peut être activé en ajoutant une
directive Options +Multiviews à une configuration. Nous
déconseillons cette méthode, excepté pour les sites Web
simples, car elle n'est pas très efficace. En effet, pour cha-
que requête, elle analyse le répertoire contenant le fichier,
à la recherche de documents analogues contenant d'autres
extensions. Elle construit alors une liste de ces fichiers et
utilise des extensions pour déterminer le codage du con-
tenu et le jeu de caractères, puis pour renvoyer le contenu
approprié.
Configuration de la négociation du contenu 79
Il vaut mieux employer les correspondances de type, qui

limitent les recherches sur le système de fichiers. Il s'agit de
fichiers spéciaux qui mettent en correspondance les noms
de fichiers et les informations (métadonnées) les concer-
nant. Vous pouvez configurer une correspondance de type
pour une ressource donnée en créant un fichier portant le
même nom et l'extension .var, puis en ajoutant une direc-
tive AddHandler (comme indiqué dans la configuration
d'exemple).
Le fichier peut contenir plusieurs entrées. Chacune com-
mence par URI: (c'est-à-dire le nom du document, suivi de
plusieurs attributs comme Content-Type:, Content-Lan-
guage: et Content-Encoding:). Le Listing 4.1 montre un
exemple de fichiers de correspondance de type.
Listing 4.1 Contenu d'un fichier de correspondance de type
URI: page.html.en
Content-type: text/html
Content-language: en
URI: page.html.fr
Content-type: text/html; charset=iso-8859-2
Content-language: fr
Astuce
N'oubliez pas que l'utilisation d'un type de négociation de
contenu affecte les performances du serveur Web, car cela
nécessite des accès supplémentaires au système de fichiers.
Affectation de jeux de caractères

par défaut et de priorités de
langue
DefaultLanguage en
AddDefaultCharset iso-8859-1
LanguagePriority en es de
Il est possible de désigner un jeu de caractères par défaut

pour les documents n'en disposant pas, à l'aide de AddDe-
faultCharset, comme indiqué dans l'exemple. Une autre
option consiste à spécifier AddDefaultCharset Off pour
désactiver l'ajout d'un jeu de caractères aux documents
qui n'en possèdent pas.
Vous pouvez également choisir une langue par défaut
grâce à la directive DefaultLanguage. Pour un site Web en
anglais, le paramètre serait en, comme indiqué dans
l'exemple.
Enfin, si le client n'adopte aucune préférence de langue,
vous pouvez utiliser LanguagePriority pour déterminer
l'ordre de préférence des langues. Dans cet exemple, si un
document en anglais est trouvé, il sera envoyé ; sinon,
Apache recherchera un document en espagnol. S'il n'en
trouve pas, il recherchera un document en allemand.
Vous en saurez plus sur ce sujet en vous rendant aux adres-
ses suivantes : http://httpd.apache.org/docs/2.0/mode
/mod_negotiation.html et http://httpd.apache.org
/docs/2.0/mod/mod_mime.html.
Mappage avancé d'URL avec mod_rewrite 81
Mappage avancé d'URL

avec mod_rewrite
Apache propose un module très puissant, mod_rewrite,
qui permet de manipuler les URL de manière quasi illi-
mitée à l'aide des expressions régulières. Du fait de sa
complexité, ce module ne sera pas traité dans cet ouvrage
autrement que dans une référence spécifique ou dans des
exemples d'autres chapitres. Il est mentionné ici pour
information, au cas où vous atteigniez un jour les limites
des directives Redirect, ErrorDocument et Alias.
Vous en saurez plus sur mod_rewrite en vous rendant
à l'adresse http://httpd.apache.org/docs/2.0/mod/
mod_rewrite.html.
Problème de l'oubli de la barre

oblique finale
DirectorySlash On
Certaines URL ne peuvent fonctionner que si elles possè-

dent une barre oblique de fin. Cette situation apparaît si
vous ne chargez pas mod_dir dans le serveur ou lorsque
les redirections réalisées par mod_dir ne fonctionnent pas
correctement avec la valeur spécifiée dans la directive
ServerName, comme expliqué dans la section "Les redirec-
tions ne fonctionnent pas", au Chapitre 2.
N'oubliez pas, lorsque vous accédez à certaines URL cor-
respondant à des répertoires, d'ajouter une barre obli-
que ("/") à la fin de l'URL. Le répertoire peut contenir
un fichier d'index ou un index de répertoire. Cet oubli est

une erreur courante. Ainsi, quand mod_dir "imagine" que
cela peut être le cas, il procède à la redirection appropriée.
Par exemple, si mod_dir est activé sur le serveur et que
vous disposez d'un répertoire nommé foo sous la racine de
document, une requête pour http://exemple.com/foo
sera redirigée vers http://exemple.com/foo/.
Il s'agit du comportement par défaut sous Apache 1.3
et 2.0 lorsque mod_dir est chargé dans le serveur. Sous
Apache 2, vous pouvez désactiver cette redirection, à
l'aide d'une directive DirectorySlash :
DirectorySlash Off
Correction des fautes de frappe

CheckSpelling on
mod_speling est un module Apache qui reconnaît les

URL mal orthographiées et redirige l'utilisateur vers
l'emplacement correct du document. mod_speling est
capable de corriger les URL dont la casse est erronée ou
dont une lettre manque (ou est incorrecte). Cela est très
fréquent lorsque les utilisateurs tapent l'URL dans le navi-
gateur.
Par exemple, supposons qu'un utilisateur demande le
fichier file.html mais que celui-ci ne soit pas présent.
mod_speling recherche alors un document analogue
(comme FILE.HTML, file.htm, etc.) et le renvoie s'il le
trouve. Cela affecte les performances, mais peut être assez
utile, et évite les requêtes vers des liens cassés.
Résolution des problèmes de casse 83
Pour activer la vérification orthographique, vous pouvez

ajouter CheckSpelling on à votre configuration Apache,
comme indiqué dans l'exemple.
Info
S'il existe plusieurs documents ressemblant à une adresse mal
orthographiée, le module en renvoie une liste. Attention, tou-
tefois ! Cela pourrait présenter des risques pour la sécurité, ces
fichiers ne pouvant pas tous être proposés au public.
Résolution des problèmes de casse

NoCase on
Windows possède un système de fichiers non sensible à
la casse, à la différence de la plate-forme UNIX. Cela
crée généralement des problèmes lors de la migration de
sites Web entre les deux systèmes. Des URL, comme
http://www.exemple.com/images/icon.PNG, qui
fonctionnaient bien sous Windows, commencent à ren-
voyer des erreurs du type "Document Not Found". En
effet, le fichier sur disque s'intitule icon.png et n'est pas
équivalent, sous UNIX, au fichier icon.PNG demandé. Ce
problème peut être résolu en vérifiant et en réécrivant
manuellement chaque lien, ou en activant le module
mod_speling, comme indiqué à la section précédente.
Il existe également un autre module, à objectif unique,
pouvant être utilisé dans ce but : mod_nocase. Ce module,
initialement fondé sur mod_speling, crée une requête
GET pour des URL non sensibles à la casse. Il recherche
une correspondance exacte ; s'il ne la trouve pas, il tente
une correspondance non sensible à la casse. Si plusieurs

fichiers correspondent à la recherche non sensible à la
casse, le premier est automatiquement sélectionné. Pour
activer mod_nocase, vous devez le charger dans le serveur
et inclure une directive NoCase dans votre fichier de confi-
guration Apache, comme indiqué dans l'exemple.
mod_nocase peut être téléchargé à l'adresse http://www
.misterblue.com/Software/mod_nocase.htm.
Attention, l'activation de mod_speling ou de mod_nocase
diminue les performances du serveur.
Validation de pages avec Tidy

AddOutputFilterByType TIDY text/html application/
xhtml+xml
TidyOption char-encoding utf8
Indépendamment du fait que vous ayez généré vos pages

HTML de manière dynamique ou que vous les ayez
codées à la main, si elles contiennent des erreurs de mar-
quage, il est possible qu'elles ne s'affichent pas correcte-
ment dans tous les navigateurs. Tidy est un outil de ligne
de commande utile, capable de traiter les codes HTML et
XML mal formés, de corriger de nombreuses erreurs
communes et de produire une sortie conforme aux stan-
dards. Vous le trouverez à l'adresse http://tidy.source-
forge.net/.
Vous pouvez exécuter Tidy à partir de la ligne de com-
mande sur des fichiers statiques, grâce à mod_tidy et à
l'architecture de filtre Apache 2, le contenu traité étant
desservi à la volée. Cet exemple montre, d'une part,
comment utiliser la directive SetFilter pour associer un
filtre Tidy à des fichiers XML et HTML, et d'autre part
Validation de pages avec Tidy 85
comment employer TidyOption pour configurer le com-

portement du moteur Tidy. L'architecture de filtre et la
configuration d'Apache sont décrites au Chapitre 11.
Vous pouvez télécharger mod_tidy à l'adresse http://
home.snafu.de/tusk/mod_tidy/.
Un autre module d'Apache 2, mod_validator, peut être
téléchargé à l'adresse http://www.webthing.com/
software/mod_validator/.
5
Hébergement
virtuel
Ce chapitre explique comment héberger plusieurs sites

Web grâce à une seule instance du serveur Apache, en
utilisant à la fois un hébergement virtuel fondé sur le nom
et un hébergement virtuel fondé sur l'adresse IP. Il traite
également de sujets liés à l'hébergement de plusieurs utili-
sateurs, par exemple avec les répertoires d'accueil et les
fichiers de configuration par répertoire.
Définition de l'hébergement
virtuel
L'hébergement virtuel est une fonction que proposent la
plupart des serveurs Web modernes. Cela permet de des-
servir des sites Web variés, chacun étant identifié par un
ou plusieurs domaines, à l'aide d'une seule instance d'un
serveur. Un autre avantage réside dans la possibilité de
centraliser l'administration et d'optimiser l'utilisation des
88 CHAPITRE 5 Hébergement virtuel
ressources du système. De nombreux fournisseurs d'héber-

gement pour des sites Web commerciaux peuvent répon-
dre à des centaines de clients à l'aide d'une seule instance
de serveur, évitant ainsi de gérer des centaines de serveurs
Apache en arrière-plan.
Hébergement virtuel basé sur IP

<VirtualHost 192.168.200.4:80>
(…)
</VirtualHost>
La manière la plus facile d'assurer un hébergement virtuel

consiste à employer une combinaison adresse IP/port à
laquelle le client se connecte. Apache peut être configuré
pour accepter un hébergement virtuel basé sur IP à l'aide
des sections <VirtualHost>. Chaque section <Virtual-
Host> contient des directives de configuration qui seront
appliquées aux requêtes envoyées à l'adresse IP (et, en
option, au numéro de port) spécifiée dans la balise
ouvrante. Bien entendu, le serveur Apache qui s'exécute
doit avoir été configuré avec ces adresses IP.
Info
En cas d'écoute sur des ports non standard, n'oubliez pas de
fournir une directive Listen pour chacun d'entre eux. Attention,
il ne suffit pas qu'ils soient listés dans la section <VirtualHost>
pour qu'Apache écoute leurs requêtes.
L'hébergement virtuel basé sur IP présente toutefois

l'inconvénient de devoir affecter une adresse IP différente
à chaque hôte virtuel.
Configuration de l'hébergement virtuel basé sur IP 89
Configuration de l'hébergement
virtuel basé sur IP
L'exemple du Listing 5.1 montre trois hôtes virtuels
basés sur IP, desservant un contenu pour trois sites Web :
www.exemple.com, une version intermédiaire de www.exem-
ple.com et www.exemple.net. La directive ServerName
figurant dans chaque section sert à construire des URL
autoréférentielles. La directive DocumentRoot précise
l'emplacement du contenu du site Web pour chaque hôte
virtuel. Il est également possible de consigner les requêtes
et les erreurs pour chaque hôte virtuel dans un fichier dif-
férent. Pour cela, il convient de placer des directives de
consignation, comme TransferLog et ErrorLog, dans la
section d'hôte virtuel (voir Chapitre 3).
Les adresses et les ports répertoriés dans la balise ouvrante
d'une définition <VirtualHost> n'auront pas d'effet sur les
adresses ou les ports qu'écoute Apache. Vous devrez donc
toujours fournir les directives Listen appropriées. Si aucun
port n'est spécifié dans une définition <VirtualHost>,
celui précisé dans la directive Apache la plus récente sera
utilisé. Il est également possible de préciser un caractère
joker ("*") pour écouter les requêtes dans tous les ports
qu'écoute Apache, comme indiqué dans l'hôte virtuel
exemple.net.
Listing 5.1 Configuration d'hôtes virtuels basés sur IP
Listen 8080
Listen 80
DocumentRoot /usr/local/Apache/sites/exemple.com
</VirtualHost>
<VirtualHost 192.168.200.2:8080>
DocumentRoot /usr/local/Apache/sites/staging
</VirtualHost>
<VirtualHost 192.168.200.4:*>
ServerName www.exemple.net
DocumentRoot /usr/local/Apache/sites/exemple.net
</VirtualHost>
Hébergement virtuel basé

sur le nom
Nous l'avons vu, l'hébergement virtuel IP nécessite une
adresse IP différente pour chaque site Web. Cela génère
un certain nombre de problèmes si vous devez héberger un
grand nombre de sites ou que vous ne puissiez pas ou ne
vouliez pas payer plusieurs adresses IP. Cela sera notam-
ment le cas si vous souhaitez gérer plusieurs sites Web per-
sonnels sur votre propre serveur via une ligne DSL.
L'hébergement virtuel basé sur le nom est utile car la plu-
part des navigateurs réputés (et la quasi-totalité des navi-
gateurs récents) transmettent un en-tête Host: dans leur
requête HTTP. C'est une exigence du protocole
HTTP/1.1, mais cela apparaît également dans la plupart
des implémentations de HTTP/1.0. Il est ainsi possible
de choisir les informations à présenter à l'utilisateur en
fonction des données de la requête HTTP, plutôt que
d'afficher les données de la connexion elle-même. Cela
permet à plusieurs hôtes virtuels de partager la même
combinaison adresse IP/port.
Configuration de l'hébergement virtuel basé sur le nom 91
Configuration de l'hébergement
virtuel basé sur le nom
La configuration des hôtes virtuels par noms est semblable
à celle des hôtes virtuels IP. L'exemple du Listing 5.2
montre deux hôtes virtuels partageant l'adresse IP
192.168.200.2.
Apache déterminera l'hôte virtuel vers lequel"router" la
requête, en fonction de la valeur de l'en-tête Host: de la
requête HTTP. Elle sera comparée, à des fins de corres-
pondance, au nom d'hôte fourni par ServerName, ainsi
qu'à tous les noms d'hôtes supplémentaires fournis par la
directive ServerAlias, qui sont optionnels.
Listing 5.2 Configuration d'hôte virtuel basée sur le nom
Listen 80
NameVirtualHost 192.168.200.2
ServerAlias exemple.com Web.exemple.com
</VirtualHost>
</VirtualHost>
La directive NameVirtualHost est nécessaire pour indiquer

à Apache qu'une adresse IP particulière servira pour les
hôtes virtuels basés sur le nom. Vous pouvez indiquer à
Apache d'utiliser n'importe quelle adresse IP disponible
pour l'hébergement virtuel basé sur le nom, avec :
NameVirtualHost *
Bien entendu, vos serveurs DNS doivent être correcte-

ment configurés pour que les domaines www.exemple.com,
exemple.com et Web.exemple.com soient résolus sur l'adresse
192.168.200.2.
Que se passe-t-il si une requête ne

correspond à aucun hôte virtuel ?
Si une requête ne correspond à aucun hôte virtuel, elle
sera desservie par le serveur principal dans le cas d'un
hébergement virtuel basé sur IP. Dans le cas d'un héber-
gement virtuel basé sur le nom, c'est le premier hôte vir-
tuel basé sur le nom qui prendra le pas. Consultez les deux
sections suivantes pour en savoir plus sur la configuration
d'un hôte virtuel "tous usages" par défaut.
Configurer un hôte virtuel par défaut,

basé sur le nom
NameVirtualHost *
<VirtualHost *>
...
</VirtualHost>
Nous l'avons indiqué dans la section précédente, c'est le

premier hôte virtuel présent dans le fichier de configura-
tion qui répond aux requêtes du domaine non explicite-
ment gérées par d'autres hôtes virtuels. Si vous hébergez
plusieurs sites, il peut être utile de configurer cet hôte
virtuel. Il renverra ainsi une page proposant une liste des
sites Web disponibles dans la machine, ou bien donnera
les raisons pour lesquelles ce site Web particulier n'est
pas reconnu. Pour cela, vous pouvez placer ce fichier
(default.html, dans l'exemple du Listing 5.3) à la racine
Que se passe-t-il si une requête ne correspond à aucun hôte virtuel ? 93
du document, puis rediriger toutes les requêtes qui lui

sont adressées à l'aide d'une directive AliasMatch. Vous
obtiendrez un effet analogue en remplaçant la directive
par une directive ErrorDocument :
ErrorDocument 404 /default.html
Vous pouvez également diriger les utilisateurs vers un

autre de vos sites Web, à l'aide d'une directive Redirect.
Listing 5.3 Configuration d'un hôte virtuel par défaut basé

sur le nom
NameVirtualHost *
# La section ci-après doit être placée au-dessus de
toute
autre section d'hôte virtuel
<VirtualHost *>
ServerName default.exemple.com
DocumentRoot /usr/local/Apache/sites/default
AliasMatch /* /default.html
</VirtualHost>
Configurer un hôte virtuel par défaut

basé sur IP
<VirtualHost _default_ >
ServerName default.exemple.com
</VirtualHost>
La syntaxe spéciale _default_ permet de définir un hôte vir-

tuel qui desservira les requêtes de combinaisons adresse/port
qui ne sont pas traitées par d'autres hôtes virtuels. Vous
pouvez également préciser un numéro de port dans la
combinaison, à l'aide du mot clé _default_ (comme dans
l'exemple suivant, extrait de la configuration mod_ssl par
défaut d'Apache). Cet exemple spécifie un hôte virtuel qui

écoutera les requêtes sur ce port particulier, pour toutes les
adresses qui ne sont pas explicitement gérées par d'autres
hôtes virtuels :
<VirtualHost _default_:443>
SSLEngine on
ServerName secure.exemple.com:443
...
</VirtualHost>
Mélange d'hôtes basés sur IP

et basés sur le nom
Sachez qu'il est également possible de spécifier à la fois
des hôtes virtuels basés sur IP et d'autres basés sur le nom
(voir Listing 5.4). Au lieu d'utiliser NameVirtualHost *,
vous devrez fournir des directives NameVirtualHost sépa-
rées pour chaque adresse IP qui sera associée à des hôtes
virtuels basés sur le nom. Cet exemple montre deux
hôtes virtuels basés sur le nom, associés à l'adresse IP
192.168.200.2, et un hôte virtuel basé sur IP, associé à
l'adresse IP 192.168.200.4.
Listing 5.4 Mélange d'hôtes basés sur IP et basés sur le nom
NameVirtualHost 192.168.200.2
</VirtualHost>
ServerName staging.exemple.com
DocumentRoot /usr/local/Apache/sites/staging
Débogage des configurations d'hôtes virtuels 95
</VirtualHost>
</VirtualHost>
Débogage des configurations

d'hôtes virtuels
Vous pouvez appeler le binaire httpd assorti de l'option -S
(voir Listing 5.5) pour qu'Apache analyse le fichier de
configuration. Une fois que toutes les informations liées à
l'hôte virtuel ont été traitées, ile binaire httpd fournit des
informations sur chaque hôte virtuel configuré et chaque
valeur d'hôte par défaut. Il s'agit là d'un outil très pratique
pour déboguer des configurations d'hôtes virtuels com-
plexes.
Listing 5.5 Vérification de la configuration d'un hôte virtuel
# httpd -S
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:* is a NameVirtualHost
default server exemple.com
(/usr/local/www/conf/httpd.conf:1055)
port * namevhost exemple.com
port * namevhost exemple.org
port * namevhost exemple.net
Syntax Ok
Utilisation de SSL avec des hôtes

virtuels basés sur le nom
En bref, SSL ne peut pas être utilisé avec les hôtes virtuels
basés sur le nom, car il n'existe pas aujourd'hui de grand
navigateur capable de le prendre en charge. Repor-
tez-vous à la section du même nom dans le Chapitre 7
pour en savoir plus.
Alternative à l'hébergement virtuel

UseCanonicalName Off
VirtualDocumentRoot /usr/local/Apache/vhosts/%0
VirtualScriptAlias \
/usr/local/Apache/vhosts/%0/cgi-bin
Pour les utilisateurs qui disposent d'un grand nombre

d'hôtes virtuels, il peut être souhaitable d'adopter une
approche différente d'hébergement. Cela est particuliè-
rement vrai pour les FAI, qui hébergent des milliers de
clients. Dans le cas contraire, ils devront enregistrer des
informations pour chacun des hôtes virtuels dans le fichier
de configuration, puis redémarrer le serveur à chaque
modification.
mod_virtualhost_alias vous permet de configurer une
racine de document différente pour chaque hôte virtuel,
et ce de manière dynamique. Ainsi, la requête est mise en
correspondance avec un chemin donné dans le système de
fichiers, en fonction des informations de la requête elle-
même (comme l'adresse IP ou le nom d'hôte). Cet exemple
met en correspondance les requêtes pour un nom d'hôte
particulier avec un chemin dans le système de fichiers qui
comprend ce nom d'hôte (représenté par %0 dans le che-
min). De même, la directive VirtualScriptAlias permet
d'exécuter des scripts CGI dans un chemin de répertoire
Utilisation de SSL avec des hôtes virtuels basés sur le nom 97
basé sur le nom d'hôte référencé dans la requête. Si un uti-

lisateur envoie une requête pour /manual/index.html sur
l'hôte www.exemple.com, cette directive sera mise en corres-
pondance avec /usr/local/Apache/vhosts/www.exemple.com/
manual/index.html.
De la même manière, vous pouvez effectuer la correspon-
dance avec des adresses IP plutôt que les noms d'hôtes,
pour un hébergement virtuel basé sur IP, à l'aide des
directives VirtualDocumentRootIP et VirtualScriptAliasIP.
Vous pouvez choisir de mettre en correspondance des
requêtes en fonction de certaines parties seulement du
nom d'hôte ou de l'adresse IP, ou en fonction du port de
la requête. Pour cela, vous utiliserez différentes séquences
basées sur %, comme %p pour le numéro de port, %1 pour
la première partie du domaine, %2 pour la deuxième, et
ainsi de suite.
Autres modules d'hébergement virtuel

Le module mod_vhost_alias est probablement l'un des
plus populaires parmi les hôtes virtuels de masse, du fait
qu'il est intégré dans Apache. Il existe toutefois d'autres
solutions, par exemple :
b mod_vhost_ldap. Ce module Apache 2 permet de
stocker des informations d'hôte virtuel dans un réper-
toire LDAP. Il peut être téléchargé à l'adresse http://
alioth.debian.org/projects/modvhostldap/.
b mod_vhost_dbi. Ce module permet de stocker une
configuration d'hôte virtuel dans une base de données
SQL, ce qui assure une grande flexibilité. Il s'exécute sur
Apache 2. Pour le télécharger, rendez-vous à l'adresse
http://www.outforder.cc/projects/Apache/
mod_vhost_dbi/.
Le Chapitre 11 traite de plusieurs modules de multitraite-

ment (MPM), comme mod_perchild, qui permettent
d'exécuter différents hôtes virtuels sous divers identifiants
utilisateur.
Fichiers de configuration par répertoire

AccessFilename .htaccess
L'hébergement de plusieurs sites Web pose un problème

lié, relatif aux services d'hébergement qui concernent plu-
sieurs clients. Si le nombre de clients est important, il est
possible de faire appel à des fichiers de configuration par
répertoire. Ce sont généralement des fichiers htaccess
(auparavant principalement utilisés pour les tâches de
contrôle d'accès). Lorsque cette fonctionnalité est activée,
Apache recherche des fichiers de configuration spéciaux
dans tous les répertoires menant au fichier demandé. Par
exemple, si Apache reçoit une requête pour /usr/local/
apache2/htdocs/index.html, il recherche les fichiers de
configuration par répertoire dans /, /usr/, /usr/local/,
/usr/local/apache2 et /usr/local/apache2/htdocs, dans
cet ordre.
S'il en trouve, leur contenu est traité et fusionné avec la
configuration principale de httpd.conf au démarrage.
Cela est assez pratique pour l'administrateur système, car
les utilisateurs peuvent gérer eux-mêmes leurs configura-
tions. De plus, puisque les fichiers sont analysés à la volée,
le serveur n'a pas à être redémarré après chaque modifica-
tion. Inconvénient : cette opération pénalise les perfor-
mances. En effet, Apache doit procéder à des opérations
lourdes sur disque pour rechercher ces fichiers dans cha-
que requête, et ce, même si les fichiers n'existent pas.
Utilisation de SSL avec des hôtes virtuels basés sur le nom 99
La directive AccessFilename permet de fournir une liste

de noms de fichiers qu'Apache étudiera, à la recherche des
fichiers de configuration par répertoire.
Contrôle de la portée des fichiers

de configuration par répertoire
AllowOverride Indexes Limit AuthConfig
Lorsque .htaccess est présent dans le champ Context: de

la description de la syntaxe de référence de la directive,
que vous trouverez dans la documentation Apache, cela
signifie que la directive peut être placée dans des fichiers
de configuration par répertoire.
La directive AllowOverride permet de contrôler le type de
directives de configuration pouvant apparaître dans des
fichiers de configuration par répertoire. Vous pouvez, par
exemple, autoriser les utilisateurs à modifier les directives
d'indexation de répertoire, mais pas celles liées à une
autorisation. Les valeurs possibles sont les suivantes :
b Authconfig. Directives d'autorisation.
b FileInfo. Directives contrôlant les types de docu-
ments.
b Indexes. Directives contrôlant l'indexation du réper-
toire.
b Limit. Directives de contrôle de l'accès à l'hôte.
b Options. Directives contrôlant les fonctions spécifi-
ques du répertoire.
b All. Toutes les directives appartenant aux groupes
mentionnés précédemment peuvent être employées.
b None. Désactiver les fichiers de configuration par réper-
toire pour cette arborescence de répertoires.
Désactivation des fichiers de

configuration par répertoire
<Directory />
AllowOverride None
</Directory>
Si vous n'avez pas l'utilité des fichiers de configuration par

répertoire, vous pouvez les désactiver à l'aide de la syntaxe
présentée ici. Cela augmentera la sécurité et les perfor-
mances du serveur, aux dépens toutefois de la flexibilité et
de la commodité que ces fichiers procurent.
6
Sécurité et
contrôle d'accès
Le contrôle d'accès, une exigence ?

Le contrôle d'accès est une exigence pour de nombreux
sites Web. Cela implique qu'un certain contenu (ou cer-
taines zones) du site Web soit accessible aux clients pro-
venant d'une plage d'adresses particulière, d'une part, et
que ceux-ci fournissent, par exemple, un nom d'utilisa-
teur et un mot de passe valables, d'autre part. Le contrôle
d'accès peut être implémenté à divers niveaux : notam-
ment celui du système d'exploitation, avec des règles de
filtrage des paquets, et celui de l'application Web, avec des
formulaires, des sessions et des cookies. Ce chapitre traite
exclusivement de l'implémentation du contrôle d'accès,
de l'authentification et de l'autorisation à l'aide des modu-
les Apache intégrés. Il explique également en quoi les dif-
férents paramètres de configuration peuvent affecter la
sécurité de votre serveur et montre plusieurs étapes que
vous pouvez entreprendre pour l'améliorer.
102 CHAPITRE 6 Sécurité et contrôle d'accès
Apache propose plusieurs modules permettant de contrô-

ler l'accès au contenu d'un site. Les deux principaux sont
mod_access (qui permet de contrôler l'accès en fonction
de l'adresse IP d'origine et d'autres caractéristiques de la
requête) et mod_auth (qui authentifie les utilisateurs en
fonction d'un nom d'utilisateur et d'un mot de passe).
D'autres modules, moins utilisés, seront également men-
tionnés dans ce chapitre, mais ne seront pas traités en détail.
Différences existant
entre les versions d'Apache
La structure des autorisations et des authentifications
d'Apache a été totalement remaniée dans Apache 2.2.
Même si la plupart des modifications ont été apportées au
niveau du code source, plusieurs changements sont visi-
bles pour l'utilisateur.
Pour des raisons de clarté, et parce que la plupart des
concepts de base continuent de s'appliquer, ce chapitre
décrit principalement les configurations Apache 1.3 et
Apache 2.0.
Toutefois, si vous souhaitez connaître les changements spé-
cifiques à la version 2.2, consultez la section "Apache 2.2",
plus loin dans ce chapitre.
L'authentification basique
et digest
L'authentification des utilisateurs d'un site Web sert pour
des raisons de suivi ou d'autorisation. La spécification HTTP
propose deux mécanismes d'authentification : basique et
digest.
L'authentification basique et digest 103
Dans les deux cas, le processus est le suivant :

1. Un client tente d'accéder à un contenu protégé sur le
serveur Web.
2. Apache examine si le client fournit un nom d'utilisa-
teur et un mot de passe. Si ce n'est pas le cas, il renvoie
un code de situation "HTTP 401", indiquant que
l'utilisateur doit s'authentifier.
3. Le client lit la réponse et demande à l'utilisateur son
nom et son mot de passe (généralement dans une
fenêtre contextuelle).
4. Le client tente à nouveau d'accéder à la page Web,
cette fois en transmettant le nom d'utilisateur et le mot
de passe dans le cadre de la requête HTTP. Le client
retient le nom d'utilisateur et le mot de passe et les
transmet dans les prochaines requêtes vers le même
site, pour que l'utilisateur n'ait pas besoin de les saisir à
chaque requête.
5. Apache vérifie la validité des informations, puis
accorde ou refuse l'accès selon l'identité de l'utilisateur
et d'autres règles d'accès.
Dans l'authentification de base, le nom d'utilisateur et le

mot de passe sont transmis en texte clair, dans le cadre des
en-têtes de la requête HTTP. Cette situation implique un
risque pour la sécurité. En effet, une personne mal-
veillante pourrait facilement espionner la conversation
entre le serveur et le navigateur, intercepter le nom d'uti-
lisateur et le mot de passe, et les réutiliser librement par la
suite. L'authentification digest assure un niveau de sécurité
supérieur, car elle ne transmet qu'un résumé (digest), et
non le mot de passe en clair. Un algorithme digest est une
opération mathématique qui extrait un texte et en ren-
voie un autre qui identifie uniquement le texte d'origine.
Si le texte change, le digest change également. Le digest

est fondé sur une combinaison de plusieurs paramètres,
comme le nom d'utilisateur, le mot de passe et la méthode
de requête. Le serveur peut calculer le digest lui-même et
vérifier que le client connaît le mot de passe, même quand
celui-ci n'est pas transmis sur le réseau.
Malheureusement, même si cette spécification existe
depuis un certain temps, les navigateurs n'acceptent pas
tous l'authentification digest ou le font de manière non
compatible.
Dans tous les cas, à la fois pour l'authentification basique
ou digest, les informations demandées sont transmises sans
protection sur le réseau. Pour mieux sécuriser l'accès à
votre site Web, utilisez plutôt SSL (voir Chapitre 7).
Présentation du contrôle d'accès

Apache
<Directory /usr/local/apache2/htdocs/private>
Order Allow, Deny
Allow from 192.168.0 exemple.com
Deny from guest-terminal.exemple.com
</Directory>
L'exemple montre un extrait de configuration utilisant un

contrôle d'accès basé sur le nom d'hôte et IP, avec
mod_access. Les directives Allow précisent les adresses IP
individuelles, les réseaux et les noms d'hôtes qui ont accès
au contenu. Les directives Deny précisent celles qui seront
refusées. La directive Order indique la méthode d'évalua-
tion des directives Allow et Deny.
Dans cet exemple, la directive Order Allow,Deny précise
que les directives Allow doivent être évaluées en premier,
et les directives Deny en dernier. Cet ordre est important !
Configuration des autorisations et des authentifications Apache 105
Order Allow,Deny s'assure que si le client ne correspond

pas à une directive Allow, l'accès lui sera refusé par défaut.
Le fonctionnement du contrôle d'accès peut vous laisser
perplexe. Ne vous inquiétez pas, il est très facile à maîtri-
ser une fois que vous avez compris comment sont éva-
luées les directives.
Configuration des autorisations

et des authentifications Apache
AuthType Basic
AuthName "Password Protected Area"
AuthUserFile /usr/local/apache2/conf/htusers
Require user admin
</Directory>
Ce listing présente un extrait de configuration qui protège
un répertoire à l'aide d'un mot de passe. AuthType définit
le type d'authentification : dans ce cas, c'est une authenti-
fication HTTP basique. AuthName associe un texte à la
zone qui sera protégée par le mot de passe. Ce texte sera
présenté à l'utilisateur lorsque le navigateur lui demandera
un mot de passe (généralement dans une fenêtre contex-
tuelle séparée). AuthUserFile pointe vers la base de don-
nées utilisateur. Enfin, la directive Require spécifie un
utilisateur auquel sera accordé un accès en cas d'authenti-
fication réussie.
Les sections suivantes donnent plus de détails sur cet
exemple. Vous y trouverez également des instructions
pour créer et manipuler la base de données utilisateur, et
d'autres pour combiner un contrôle d'accès basé sur l'uti-
lisateur et sur IP, comme indiqué à la section "Combinai-
son des méthodes de contrôle d'accès".
Création d'une base de données

utilisateur
htpasswd -c file userid
Pour créer une base de données utilisateur (aussi appelée

fichier de mots de passe), vous pouvez employer l'utilitaire
htpasswd inclus dans Apache. La syntaxe permettant de
créer un nouveau fichier de mots de passe et d'y ajouter
un utilisateur sous UNIX est présentée dans l'exemple.
Sous Windows, vous devrez utiliser :
htpasswd.exe -cm file userid
Pour ajouter un nouvel utilisateur à un fichier de mots de
passe existant, voici la syntaxe sous UNIX :
htpasswd file userid
et sous Windows :
htpasswd.exe -m file userid
Vous devrez également faire figurer le mot de passe qui
sera ajouté à la base de données des utilisateurs.
Ne conservez pas le fichier de mots de passe dans un réper-
toire accessible par le Web. N'utilisez pas non plus -c
lorsque vous ajoutez des utilisateurs à un fichier existant ;
cela détruirait le contenu précédent.
A titre d'exemple, la ligne suivante crée un fichier de mots
de passe nommé htusers et ajoute un utilisateur nommé
admin :
htpasswd -c /usr/local/apache2/conf/htusers admin
Emploi de Require pour autoriser des utilisateurs et des groupes 107
Emploi de Require pour autoriser

des utilisateurs et des groupes
AuthType Basic
AuthName "Password Protected Area"
AuthGroupFile /usr/local/apache2/conf/groups
Require group administrators
</Directory>
Vous pouvez demander à Apache d'autoriser l'accès à tout

utilisateur valide dans la base de données, qui s'identifie
avec succès, en tapant :
Require valid-user
S'il ne s'agit que d'un certain groupe d'utilisateurs, vous
pouvez les répertorier de manière explicite dans les argu-
ments de Require :
Require user idutil1 idutil2
En revanche, si vous disposez d'un grand nombre d'utili-
sateurs, employez la directive AuthGroupFile. Elle pointe
vers un fichier contenant des informations de groupe, au
format suivant :
nomgroupe: idutil1 idutil2 idutil3 [..]
Par exemple :
administrators: admin patron
users: admin patron util1 util2
L'exemple affiché au début de cette section montre un
extrait de configuration qui offre l'accès aux seuls utilisa-
teurs ayant réussi à s'authentifier et appartenant au groupe
administrators. Dans cet exemple, il s'agirait des utilisa-
teurs admin et patron.
Gestion d'un grand nombre

d'utilisateurs
<DirectoryMatch /home/*/public_html>
AuthType Basic
AuthName "Zone privee"
AuthDBMUserFile /usr/local/apache2/conf/dbmusers
AuthDBMGroupFile /usr/local/apache2/conf/dbmusers
AuthDBMAuthoritative on
Require group student faculty
</DirectoryMatch>
Le module mod_auth_dbm équivaut, en termes de fonction-

nalités, à mod_auth, mais il conserve les données utilisateur
dans une base de données fondée sur un fichier. Cela
accélère la recherche des données lorsqu'il existe un grand
nombre d'utilisateurs. Ce module propose plusieurs direc-
tives, comme AuthDBMAuthoritative, AuthDBMUserFile et
AuthDBMGroupFile, dont la syntaxe et les fonctionnalités
sont équivalentes aux directives en texte brut prévues
par mod_auth. Pour manipuler les fichiers utilisateur et
de groupe, adoptez htdbm et dbmmanage, les contreparties de
l'outil mod_auth. Sachez que les données de groupe et
d'utilisateur peuvent être stockées dans la même base de
données, comme indiqué ici.
Autorisation d'accès à des adresses

IP spécifiques uniquement
Order Allow, Deny
</Directory>
Il est quelquefois souhaitable de limiter l'accès à un certain
contenu (comme le site Web interne d'une entreprise) à
des adresses IP spécifiques, notamment celles provenant
Refuser l'accès à des adresses IP spécifiques 109
d'un réseau interne. Cet exemple donne accès au répertoire

/usr/local/apache2/htdocs/private et à ses sous-réper-
toires uniquement pour les clients dont les adresses IP
sont comprises dans la plage 192.168.0.1 à 192.168.0.254.
L'argument transmis à la section Directory doit littérale-
ment correspondre au chemin du système de fichiers
qu'utilise Apache pour accéder aux fichiers.
La ligne Order Allow, Deny refuse l'accès par défaut ; seuls
les clients correspondant à la directive Allow se verront
accorder l'accès. La directive Allow peut accepter plusieurs
adresses IP individuelles ou une certaine plage d'adres-
ses IP. Consultez la référence de la directive pour en
savoir plus.
Vous pouvez également autoriser l'accès à quelques adres-
ses IP spécifiques seulement, qui utilisent le même code,
dans un fichier .htaccess, à l'adresse /usr/local/apache2/
htdocs/private :
Order Allow,Deny
Refuser l'accès à des adresses IP

spécifiques
Order Deny,Allow
Deny from 192.168.0.2 192.168.0.5
</Directory>
A l'inverse, il est possible d'autoriser un accès général,
mais avec des restrictions. Vous pouvez, par exemple,
refuser l'accès lorsque la requête provient d'une adresse
figurant dans une plage d'adresses IP spécifiques. Cela
peut servir à bloquer certaines machines ou robots Web
responsables de problèmes ou d'abus de bande passante.
Cet exemple autorise l'accès au répertoire /usr/local/

apache2/htdocs/private et à ses sous-répertoires à n'importe
quelle personne, à l'exception des clients dont les adresses IP
portent les numéros 192.168.0.2 et 192.168.0.5.
Allow et Deny peuvent également restreindre l'accès selon
qu'il existe ou non une variable d'environnement, comme
expliqué à la section "Restriction d'accès fondée sur le
type du navigateur", plus loin dans ce chapitre.
Le Chapitre 9 propose d'autres manières de restreindre ou
de limiter l'accès aux clients dont le comportement est
inadapté.
Combinaison des méthodes

de contrôle d'accès
<Location /restricted>
Allow from 192.168.200.0/255.255.255.0
AuthType Basic
AuthName "Ressource restreinte"
AuthAuthoritative on
Require valid-user
Satisfy any
</Location>
Vous pouvez associer différentes méthodes de contrôle

d'accès, à l'aide de la directive Satisfy. Par exemple, le
fichier de configuration montré ici nécessite que les utili-
sateurs proviennent d'une adresse interne autorisée OU
qu'ils fournissent un nom d'utilisateur et un mot de passe
valables.
Pour limiter l'accès aux utilisateurs provenant d'une adresse
interne spécifique ET fournissant un nom d'utilisateur et
un mot de passe, vous devrez utiliser Satisfy all.
Personnalisation de la page de refus d'accès 111
Personnalisation de la page
de refus d'accès
Lorsqu'une requête reçoit un refus d'accès du serveur
Web, l'utilisateur obtient un message d'erreur généré par
le serveur et codé en dur. Vous pouvez personnaliser ce
message, à l'aide de la directive ErrorDocument, de trois
manières différentes.
Vous pouvez afficher un message personnalisé à l'atten-
tion de l'utilisateur, comme dans les exemples suivants :
Avec Apache 2 :
ErrorDocument 403 "Vous n'êtes pas autorisé à
accéder à ce fichier"
Avec Apache 1.3 (remarquez ici l'absence de guillemets

en fin de chaîne) :
ErrorDocument 403 "Vous n'êtes pas autorisé à
accéder à ce fichier
Vous pouvez également rediriger la requête vers un che-

min d'URL local avec un message personnalisé :
ErrorDocument 401 /login_failed.html
Dans ce cas, le fichier transmis à la directive en second

argument est un chemin commençant par une barre obli-
que (/), relativement à la valeur spécifiée dans la directive
DocumentRoot.
Enfin, vous pouvez rediriger la requête vers une URL
externe :
ErrorDocument 404 http://www.exemple.com/page
_not_found.html
Ces exemples font référence à des codes de retour

400 HTTP différents, ce qui indique qu'une erreur a été
rencontrée lors de la résolution de la requête (par exem-
ple, l'utilisateur n'a pas fourni le nom et le mot de passe
corrects). Vous pouvez bien sûr procéder de la même
manière pour d'autres codes HTTP communs, comme
des erreurs de serveur interne.
Info
Certaines versions de Microsoft Internet Explorer (MSIE) igno-
rent par défaut les messages d'erreur générés par le serveur
lorsqu'ils font moins de 512 octets. N'oubliez donc pas de spéci-
fier un message supérieur à cette valeur. Vous en saurez plus sur
ce problème en vous référant à un article de la base de connais-
sances de Microsoft, à l'adresse http://support.microsoft.com/
default.aspx?scid=kb;en-us;Q294807.
Donner le pouvoir aux utilisateurs

Si plusieurs utilisateurs publient du contenu dans votre
installation Apache, vous pouvez les autoriser à protéger
leur propre répertoire par mot de passe, à l'aide de fichiers
.htaccess (voir Chapitre 1). Ce mécanisme porte préju-
dice aux performances, mais il vous évite de donner
l'accès aux fichiers de configuration Apache ou aux bases
de données utilisateur, ou encore de les mettre à jour cha-
que fois qu'un changement est nécessaire.
Dans les sections de répertoire appropriées de votre fichier
de configuration Apache, vous devrez ajouter :
AllowOverride AuthConfig Limit
L'instruction permet aux utilisateurs de créer leurs propres

fichiers de configuration .htaccess et de placer leurs pro-
pres contrôles d'accès et directives liées aux autorisations.
Refus d'accès aux fichiers système et sensibles 113
A l'inverse, vous pouvez interdire les changements de

configuration par répertoire, grâce au paramètre global
suivant :
<Directory />
AllowOverride none
</Directory>
Cela présente comme autre avantage d'améliorer les per-

formances. En effet, Apache n'a pas besoin de rechercher
l'existence de fichiers de configuration par répertoire
pour chaque fichier demandé. Vous pouvez également
restreindre le type d'options de configuration autorisées.
Pour en savoir plus, consultez la documentation sur
AllowOverride.
Refus d'accès aux fichiers

système et sensibles
<Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>
Il existe certains types de fichiers auxquels les visiteurs ne

doivent pas avoir accès, quelles que soient les circonstan-
ces, car ils peuvent contenir des mots de passe ou d'autres
informations sensibles. Ce sont les fichiers de sauvegarde
d'exemple créés par les éditeurs de texte UNIX, les
fichiers de configuration par répertoire, etc. Vous pouvez
en refuser l'accès à l'aide de paramètres de configuration
explicites (tels que ceux présentés ici), inclus par défaut
dans la configuration Apache, et refuser l'accès aux
fichiers .htaccess et .htpasswd.
Il est également possible d'empêcher le serveur de desservir

un certain contenu en le configurant de manière qu'il ne
suive pas des liens symboliques. Dans ce but, utilisez les
arguments FollowSymLinks et SymLinksIfOwnerMatch avec
la directive Options, tel qu'indiqué dans la documentation.
Vous pouvez également désactiver mod_spelling (voir
Chapitre 4). En effet, ce module peut quelquefois exposer
"par inadvertance" des noms de fichiers non destinés à être
publiés, comme cela peut être le cas si une URL mal
orthographiée correspond à plusieurs documents.
Consultez également la section relative à la restriction
d'accès aux listings de répertoires, plus loin dans ce chapitre.
Restriction d'exécution
de programmes
Les programmes CGI peuvent présenter un risque pour la
sécurité. Il est conseillé de désactiver leur exécution, ou
du moins de la restreindre à des répertoires spécifiques.
Pour cela, n'utilisez pas les directives AddHandler pour acti-
ver globalement l'exécution CGI de certaines extensions
de fichiers.
De même, mod_include autorise l'exécution de CGI et
de commandes externes à l'aide de SSI. Ils sont désac-
tivés par défaut par la directive Options -IncludesNoExec.
Si possible, vérifiez que les répertoires contenant des
scripts CGI inscriptibles par le superutilisateur unique-
ment, et notamment pas par l'utilisateur sous lequel Apa-
che s'exécute.
Sur le même thème, assurez-vous chaque fois que possible
que l'arborescence de documents soit en lecture seule.
Eviter les abus 115
Cela empêchera une personne malveillante de créer un

fichier pouvant ensuite être exécuté (par exemple, un fichier
contenant du code PHP qui serait introduit dans un serveur
activé pour PHP). De même, n'oubliez pas de protéger les
répertoires activés par DAV avec un mot de passe et ne
mettez surtout pas le contenu du site à disposition par le
biais d'autres services, comme le FTP.
Eviter les abus

Il existe plusieurs manières de restreindre ou de limiter
l'accès à tout ou partie de votre site Web. Cela peut être
nécessaire, par exemple, pour protéger un contenu des
moteurs de recherche ou lorsqu'un robot au comporte-
ment indélicat consomme trop de ressources. Ces métho-
des sont expliquées en détail au Chapitre 9, qui traite aussi
de la manière d'éviter ou de réduire les attaques de refus de
service. Ces attaques ont pour but d'empêcher le serveur
de répondre aux requêtes des utilisateurs, ou de le limiter.
Plusieurs modules et paramètres Apache aident à résoudre
ces problèmes en partie.
Désactivation des listings

de répertoire
Options -Indexes
</Directory>
Apache permet de définir des fichiers d'index spéciaux,

avec la directive DirectoryIndex. Lorsqu'une requête réa-
lisée par un client correspond à un chemin de répertoire,
Apache recherche l'un de ces fichiers d'index (générale-

ment nommés index.html ou accueil.html) et le renvoie
au navigateur. Si aucun fichier n'est trouvé, Apache ren-
voie une page HTML contenant un listing de répertoire.
Même si cela peut être utile au cours du développement
ou lors de la mise à disposition d'un référentiel de fichiers,
il est possible que des noms de fichiers que vous ne sou-
haitez pas voir publier ni indexer par des moteurs de
recherche (comme les fichiers de sauvegarde) le soient.
Vous pouvez désactiver les listings de répertoire en désacti-
vant le module mod_autoindex ou en utilisant la directive
Options, comme indiqué ici.
Si les fichiers de configuration par répertoire sont activés,
vous pouvez également placer l'exemple dans un fichier
.htaccess.
Modification de l'en-tête Server:

ServerTokens Prod
Apache renvoie un en-tête Server: avec chaque requête.

Par défaut, cet en-tête contient des informations sur le nom
du serveur, sa version et sa plate-forme. D'autres modules
présents dans le serveur, comme SSL, PHP ou mod_perl,
peuvent ajouter des entrées supplémentaires à la chaîne de
serveurs contenant le nom et la version du module.
Sachez que vous pouvez aussi modifier ou restreindre les
informations d'en-tête du serveur, à l'aide de la directive
ServerTokens. Nous recommandons sans cesse de réduire
la quantité d'informations concernant la configuration du
serveur, qui sont vues par le monde extérieur. Toutefois,
modifier la chaîne du serveur n'apportera que peu de
Empêcher le vol de vos images (hotlinking) 117
sécurité supplémentaire. En effet, la plupart des outils

d'analyse et d'attaque automatisés ignorent ces informa-
tions ; ils recherchent les scripts et les modules vulnérables
les uns après les autres, quels que soient la version et le
module signalés.
Empêcher le vol de vos images

(hotlinking)
RewriteEngine On
RewriteCond %{HTTP_REFERER}
!^http://(www\.)?exemple\.com/ [NC]
RewriteCond %{HTTP_REFERER} ^http:// [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(jpg|jpeg|gif|png|bmp)$ - [F]
Il arrive que des personnes se connectent directement

depuis leur site Web à des ressources présentes sur votre
serveur, comme des images, des logos ou des fichiers de pro-
grammes binaires. Par exemple, un commerçant en ligne
a remarqué que la moitié de son trafic (et de sa facture de
bande passante) provenait d'autres sites qui se connectaient
à ses images (sociétés de cartes de crédit, pays...). Ce phéno-
mène, appelé hotlinking (vol de bande passante), peut être
contré.
Vous pouvez empêcher que des utilisateurs ne se connec-
tent à vos images en exigeant que ce type de requête pro-
vienne de votre serveur. Vous y parviendrez à l'aide de
mod_rewrite. L'exemple de ce listing renverra une réponse
Forbidden à toute requête réalisée sur les fichiers image
(identifiés par leurs extensions à la quatrième ligne Rewrite-
Rule) dont l'en-tête HTTP_REFERER ne correspond pas à votre
nom de domaine (première ligne RewriteCond). En outre,
certains navigateurs ne pouvant pas envoyer de champ de

référence valide (voire aucun), d'autres vérifications sont
réalisées pour voir si le champ de référence commence par
http:// et s'il n'est pas vide (deuxième et troisième lignes
RewriteCond).
Restriction de méthodes HTTP

spécifiques
<Directory /home/*/public_html>
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch
IncludesNoExec
<Limit GET POST OPTIONS PROPFIND>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS PROPFIND>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>
Vous pouvez contrôler l'accès à votre serveur en fonction

de la méthode HTTP de la requête, à l'aide des directives
<Limit> et <LimitExcept>. Cet exemple (extrait du fichier
de configuration Apache par défaut) montre comment
autoriser des méthodes en lecture seule et refuser des
requêtes pour toute autre méthode susceptible de modi-
fier le contenu du système de fichiers, comme PUT. La sec-
tion <Directory> identifie les répertoires par utilisateur
qui peuvent contenir des pages Web (voir Chapitre 8).
Les deux lignes suivantes restreignent les paramètres de
configuration pouvant être modifiés par les utilisateurs,
ainsi que d'autres paramètres de sécurité. La section
<Limit> permet l'accès par défaut aux méthodes HTTP
Restriction d'accès basée sur le type du navigateur 119
qui sont en lecture seule, comme GET et POST. La section

<LimitExcept> fait le contraire : elle refuse l'accès à toute
autre méthode, sans avoir explicitement à les énumérer.
Cela est particulièrement utile pour autoriser vos utilisa-
teurs à administrer leur propre contenu (voir Chapitre 8).
Restriction d'accès basée

sur le type du navigateur
SetEnvIf User-Agent ^EvilSearchEngine broken_crawler
<Directory /usr/local/apache2/htdocs>
Order Deny,Allow
Deny from env=broken_crawler
</Directory>
Vous pouvez restreindre l'accès en fonction du type du

navigateur ou de toute autre information d'en-tête ou
propriété de connexion, grâce aux variables d'environne-
ment, avec Allow et Deny.
Dans ce cas, l'accès sera refusé pour les navigateurs dispo-
sant d'un en-tête User-Agent commençant par EvilSear-
chingEngine, et tous les autres seront autorisés. Cela
s'accomplit à l'aide de la directive SetEnvIf pour définir de
manière conditionnelle une variable d'environnement,
nommée broken_crawler, si l'en-tête User-Agent de la
requête (premier argument) correspond à une expression
régulière donnée (second argument). Plus tard, vous
pourrez appliquer de manière conditionnelle les directives
Deny et Allow en fonction de l'existence de cette variable
d'environnement, identifiée par un préfixe env=. N'oubliez
pas que, même si cette technique fonctionne le plus sou-
vent, les en-têtes étant envoyés par le client, ils ne peu-
vent donc pas être totalement fiables.
Utilisation des sections

d'emplacement et de répertoire
La directive Order contrôle l'ordre de traitement des
directives d'accès, uniquement au sein de chaque phase du
traitement de la configuration du serveur. Cela implique,
par exemple, qu'une directive Allow (ou Deny) apparaissant
dans une section <Location> sera toujours évaluée après
une directive Allow (ou Deny) apparaissant dans une sec-
tion <Directory> ou un fichier .htaccess, quel que soit le
paramètre de la directive Order.
Prenez en compte que les liens symboliques et les directi-
ves Alias peuvent affecter le paramétrage de l'authentifi-
cation. Les restrictions peuvent ainsi être contournées si
les directives de contrôle d'accès sont placées dans une
section <Location>, mais le contenu est aussi accessible par
le biais de mappages d'URL supplémentaires.
Autres modules d'authentification

Outre les principaux modules proposant un contrôle
d'accès basé sur IP, ainsi que l'authentification digest et de
base standard, Apache est livré avec plusieurs autres
modules d'authentification, par exemple :
b mod_auth_anon. Fournit un accès utilisateur "anonyme"
de style FTP aux zones de téléchargement de fichiers.
b mod_auth_ldap. Ce module, disponible dans Apache 2
et versions ultérieures, permet d'authentifier les utili-
sateurs par rapport à un répertoire LDAP.
b mod_ssl. Ce module permet d'utiliser une authentifica-
tion du client basée sur un certificat (voir Chapitre 7).
Autres modules d'authentification 121
L'un des avantages d'Apache réside dans le fait que c'est un

système modulaire et extensible. Plusieurs modules tiers
ont été développés pour lui permettre de s'interfacer avec
des structures d'authentification existantes (comme les
domaines Windows, LDAP, PAM et NIS) et des infor-
mations utilisateur stockées dans une série de bases de
données (MySQL, PostgreSQL, Oracle et autres). Vous
en saurez plus sur ces modules en visitant les adresses
http://modules.apache.org et http://freshmeat.net.
L'authentification peut aussi être gérée au niveau de
l'application. On demande généralement le nom d'utilisa-
teur et le mot de passe dans un formulaire Web. Après
validation, un cookie est affecté ; il authentifie l'utilisateur
pour le reste de la session. C'est ainsi que les sites de por-
tail et de commerce électronique gèrent généralement les
fonctions de personnalisation.
mod_security
Ce module mérite une mention spéciale. C'est, par essence,
un pare-feu de niveau HTTP. Il vous permet d'inspecter
les requêtes HTTP et de réaliser toutes sortes d'opéra-
tions de surveillance, de reporting et de contrôle d'accès.
Il peut détecter et bloquer des attaques communes au
niveau de l'application, notamment celles impliquant une
injection SQL et une vulnérabilité de type chemin trans-
versal. Vous en saurez plus sur ce module en vous rendant
à l'adresse http://www.modsecurity.org.
Apache 2.2
<Location /combined>
AuthType Basic
AuthName "Restricted Access"
AuthBasicProvider file ldap
AuthLDAPURL ldap://exemple.com/o=Sample
Require valid-user
</Location>
Apache 2.2 intègre des modifications significatives dans la

mise en place de l'authentification et de l'autorisation. Ces
changements font principalement référence au travail qui
a été réalisé dans les modules existants pour séparer claire-
ment les méthodes (authentifications de base et digest) et
les fournisseurs (fichiers, arrière-guichets LDAP ou SQL,
par exemple). Avant cela, les deux fonctions étaient
mélangées dans chaque implémentation de module.
Par exemple, mod_authn_file implémente l'authentification
par rapport aux fichiers texte et mod_authn_dbm réalise
l'authentification par rapport aux fichiers de base de don-
nées. Ils peuvent être associés à mod_auth_basic et mod_auth
_digest qui implémentent à leur tour des authentifications
HTTP de base et digest. D'autres modules propose des
fonctionnalités d'autorisation pour les utilisateurs en fonc-
tion de données stockées dans des bases de données ou en
fonction de fichiers LDAP ou SQL, et d'autres basés sur la
propriété des fichiers ou les adresses IP d'origine.
Les fournisseurs peuvent être mélangés, comme indiqué
dans l'exemple au début de cette section. Un nouveau
module, mod_authn_alias, permet de définir des configu-
rations d'authentification complexes pouvant être référen-
cées par leur nom partout ailleurs dans le fichier de
configuration. Cela permet, par exemple, d'authentifier la
même ressource sur deux serveurs LDAP différents.
Mise à jour de la sécurité Apache 123
Mise à jour de la sécurité Apache

Comme avec tous les autres logiciels de serveur, vous
devez vous informer sur les nouvelles versions d'Apache,
en vous tenant au fait des problèmes de sécurité, mais éga-
lement des correctifs ou des "contournements" qui existent
pour y remédier. Ces URL vous aideront dans cette tâche :
b Liste de diffusion des annonces Apache :
http://httpd.apache.org/lists.hml
b Problèmes de sécurité Apache :
http://httpd.apache.org/security_report.html
b La semaine Apache :
http://www.apacheweek.com
b Conseils sur la sécurité Apache :
http://httpd.apache.org/docs-2.0/misc/
security_tips.html
Liste de contrôle de sécurité

On dit souvent que la sécurité est un processus, et non
une fonction. Pour que votre installation reste sécurisée,
vous devez suivre les "conseils de sécurité sur Apache" et
surveiller les journaux d'accès et d'erreurs. Etant donné
qu'Apache s'exécute en symbiose avec son environnement,
procédez de même pour le système d'exploitation et les
applications. En fait, la plupart des problèmes exploitables à
distance avec Apache naissent au niveau de l'application :
wiki vulnérable, bibliothèques PHP, composants, etc.
Cela dit, vous trouverez ici une liste détaillée de mesures
à entreprendre pour sécuriser une installation Apache par
défaut.
Désactiver les modules inutiles

La première étape consiste à désactiver tous les modules que
vous n'utilisez pas. Si vous avez compilé Apache avec une
prise en charge de modules chargeables, vous pouvez trans-
former en commentaires les directives qui chargent des
modules spécifiques. Vous devrez peut-être procéder de
même pour d'autres directives présentes dans le fichier
de configuration et faisant référence au module désactivé.
Voici une courte liste des premiers modules à retirer si vous
ne les utilisez pas, à peu près dans leur ordre d'importance :
b PHP, mod_python, mod_mono, mod_perl et tous les autres
modules de langage côté serveur. Bien sûr, ne désac-
tivez PHP que si vous n'utilisez pas Apache pour exé-
cuter des applications à base de PHP.
b mod_include, qui fournit la prise en charge SSI.
b mod_cgi, qui fournit la prise en charge de l'appel des
programmes externes.
b mod_ssl, utilisé pour apporter une assistance SSL et
TLS, et sécuriser les communications entre le naviga-
teur et Apache.
b mod_proxy, qui, s'il est mal configuré, peut permettre
aux personnes extérieures d'utiliser votre serveur pour
relayer des requêtes.
b mod_deflate, un filtre Apache 2 pour compresser la
sortie à la volée.
b mod_suexec, employé pour exécuter des programmes
externes sous des identifiants utilisateur différents de
celui sous lequel s'exécute Apache.
b mod_userdir, qui permet aux utilisateurs des systèmes
UNIX d'héberger leurs propres pages.
b mod_rewrite, qui autorise un mappage arbitraire et la
réécriture des URL entrantes.
Suppression des échantillons de script 125
De plus, dans Apache 1.3, vous pouvez désactiver expli-

citement des modules compilés spécifiques, en utilisant la
directive ClearModuleList, puis en activant explicitement
des modules, à l'aide de la directive AddModule.
Suppression des échantillons

de script
La plupart des logiciels et des environnements de déve-
loppement côté serveur Web proposent des exemples
d'applications et de scripts à des fins de démonstration ou
de test. Même s'ils sont utiles, ces exemples ne sont géné-
ralement pas codés en tenant compte de la sécurité. Ils
peuvent donc être vulnérables à plusieurs attaques, la
plupart liées au fait que le programme n'efface pas correc-
tement la saisie de l'utilisateur. Ces inconvénients permet-
tent souvent à un délinquant d'exécuter des commandes
système arbitraires, affichant le contenu des autres fichiers,
ou de modifier la base de données.
N'oubliez pas de supprimer tous les exemples de scripts et
les comptes de démonstration livrés avec vos serveurs
d'application, ainsi que votre environnement de dévelop-
pement et autres logiciels basés sur le Web que vous
pourriez avoir installés.
Restreindre ou désactiver
l'exécution de CGI et de SSI
Si la prise en charge des scripts CGI ne vous concerne pas,
désactivez mod_cgi. Dans le cas contraire, limitez la capa-
cité à exécuter des scripts à des répertoires spécifiques.
Par exemple, vous pouvez analyser votre configuration à

la recherche des directives ScriptAlias et Options avec les
arguments ExecCGI et vous assurer qu'elles sont correcte-
ment configurées. Vérifiez que des tiers ne peuvent pas
écrire dans les répertoires marqués comme contenant des
scripts exécutables. Vous pouvez également envisager
d'utiliser l'enveloppe CGI suExec comprise avec Apache.
Le même raisonnement peut s'appliquer à la fonctionna-
lité SSI, prévue par mod_include, qui permet l'exécution
de commandes externes, à moins qu'elle ne soit désactivée
par Options -IncludesNoExec.
Vérifier les autorisations

de fichiers
Sous UNIX, Apache est généralement démarré à partir de
la racine. Il effectue un certain nombre d'opérations, par
exemple la liaison au port approprié, puis change d'iden-
tifiant utilisateur pour celui spécifié dans la directive User.
Puisque certaines opérations sont réalisées à partir de la
racine, il faut s'assurer que les fichiers journal et de confi-
guration, ainsi que les répertoires qui les contiennent, ne
sont pas inscriptibles par d'autres. Assurez-vous que les
répertoires marqués comme contenant des scripts exécu-
tables ou qui peuvent contenir des scripts PHP ne sont ni
inscriptibles par tous, ni accessibles par FTP ou WebDAV,
par exemple.
Limiter ou désactiver la fonctionnalité de proxy 127
Limiter ou désactiver la
fonctionnalité de proxy
Comme avec les CGI, vous devez désactiver ou restrein-
dre la prise en charge des proxy dans votre installation
Apache, faute de quoi un proxy ouvert pourrait servir à
lancer des attaques ciblées sur d'autres sites, voire à relayer
du spam. Si vous exécutez Apache sous forme de proxy
inverse, vous pouvez désactiver le proxy "ordinaire", ou
classique, avec ProxyRequests off.
Restreindre l'accès
à votre serveur par défaut
Le serveur doit être configuré de manière à refuser l'accès
par défaut aux documents qu'il contient, à moins que
l'accès ne soit explicitement activé. L'extrait de configura-
tion suivant, tiré de la documentation Apache, montre
comment procéder :
<Directory />
Order Deny,Allow
Deny from all
</Directory>
<Directory /usr/local/apache2/htdocs>
Order Deny,Allow
Allow from all
</Directory>
Consultez les sections précédentes pour savoir comment

désactiver les listings de répertoires.
7
SSL et TLS
Ce chapitre propose une brève introduction aux concepts

qui sous-tendent SSL. Il se présente comme un guide
détaillé pour l'installation et la configuration du module
Apache mod_ssl. Vous verrez comment résoudre les pro-
blèmes communs liés à SSL. D'autre part, vous apprendrez
à créer, à signer et à installer vos clés et certificats de serveur.
Définition de SSL
La famille de protocoles SSL/TLS (Secure Sockets Layer/
Transport Layer Security) sert à sécuriser les communica-
tions entre deux points d'extrémité, généralement un ser-
veur et un client. Lorsqu'un navigateur accède à un
serveur Web à l'aide du protocole HTTP, les données
sont transmises de manière ouverte. Un tiers capable
d'intercepter cette conversation à un point du réseau
pourra accéder aux données transmises, voire les modifier.
Plusieurs applications, notamment celles destinées aux
paiements électroniques sur le Web, ainsi que l'accès à des
informations d'entreprise sensibles nécessitent un niveau de
sécurité qui n'est pas disponible avec le protocole HTTP.
130 CHAPITRE 7 SSL et TLS
Le protocole HTTPS, ou HTTP sécurisé, a été développé

pour répondre à ces préoccupations. Il améliore la sécurité
du protocole HTTP en apportant :
b La confidentialité. Il crypte les données de sorte
qu'elles ne soient pas lisibles par des tiers.
b L'intégrité. Il s'assure que les données n'ont pas été
modifiées pendant leur transit.
b L'authentification. Il vérifie l'identité du serveur
(ou du client).
HTTPS encapsule HTTP sur les protocoles SSL/TLS

(Secure Sockets Layer/Transport Layer Security), que nous
appellerons "SSL" dans la suite de ce chapitre. Le port par
défaut du protocole HTTPS est 443 ; les URL HTTPS
sont préfixées par https://.
Vous le savez probablement déjà, la plupart des navigateurs
proposent des indices visuels, généralement sous la forme
d'un cadenas placé près de la barre d'adresses, lorsque vous
êtes connecté à un site utilisant le protocole HTTPS.
Fonctionnement de SSL
Lorsqu'un utilisateur tape https://www.exemple.com, le
navigateur reconnaît le préfixe https:// et emploie donc
le protocole HTTPS pour se connecter au serveur. Si
aucun port n'est spécifié, c'est le port HTTPS par défaut
(443) qui est utilisé.
Lorsqu'une connexion est établie, le client demande le cer-
tificat du serveur. Un certificat est une donnée électroni-
que qui décrit l'identité d'un point d'extrémité dans la
communication SSL (voir plus loin). La validité du certifi-
cat est alors testée.
Compilation d'OpenSSL 131
Si le processus de validation réussit, la connexion se

poursuit. S'il échoue, l'utilisateur en est informé et il doit
fournir une confirmation. En option, le client peut aussi
apporter un certificat ; le serveur suivra alors un processus
de validation semblable.
Une fois l'identité du serveur (et, si nécessaire, du client)
établie, l'étape suivante consiste à convenir d'une clé de
cryptage commune. Dans ce but, les clés publiques de
chaque partie sont utilisées dans un algorithme pour
s'accorder en toute sécurité sur une clé symétrique. Plus
loin dans ce chapitre, vous en apprendrez davantage sur
les clés de cryptage et la manière de les générer. Le pro-
cessus d'accord est sécurisé contre les espions. En effet,
lorsque vous cryptez des informations avec la clé publique
du serveur, seul le serveur peut les décrypter.
Enfin, le client et le serveur peuvent procéder à l'échange
ordinaire d'informations. Ici, la plupart des navigateurs pro-
posent à l'utilisateur des indices visuels (généralement un
cadenas fermé) montrant que la connexion est sécurisée.
Compilation d'OpenSSL
# gunzip < openssl*.tar.gz | tar xvf -
# cd openssl*
# ./config --prefix=/usr/local/ssl --
openssldir=/usr/local/ssl/openssl
# make
# make install
mod_ssl est le module Apache qui implémente HTTPS.

Le projet OpenSSL propose les bibliothèques cryptogra-
phiques de base employées par mod_ssl, ainsi que des uti-
litaires de ligne de commande pour créer et manipuler des
certificats de serveur.
Vous pouvez télécharger une version du binaire Win-

dows, dans la section des binaires du site Web OpenSSL,
à l'adresse http://www.openssl.org. La plupart des sys-
tèmes modernes de type UNIX incluent OpenSSL par
défaut, mais vous pouvez également utiliser les outils de
gestion de packages système. Si ce n'est pas le cas ou que
vous ayez besoin d'une version plus récente que celle dis-
ponible sur votre système, téléchargez le source OpenSSL
et installez-le comme indiqué au début de cette section.
Dans la suite de ce chapitre, nous supposerons que vous
avez installé OpenSSL dans le répertoire /usr/local/ssl.
L'outil de ligne de commande openssl figure dans la distri-
bution OpenSSL. Il sera placé dans /usr/local/ssl/bin/.
Clés de cryptage
Le cryptage est un processus qui consiste à convertir un
message existant, en texte brut, en un nouveau message
totalement inintelligible pour un espion. Le décryptage
correspond au processus inverse : il transforme le message
crypté en texte brut original.
Généralement, le processus de cryptage et de décryptage
nécessite d'autres informations, à savoir une clé. Si l'expé-
diteur et le destinataire partagent la même clé, le processus
est appelé cryptographie symétrique. Si l'expéditeur et le des-
tinataire possèdent des clés différentes et complémentaires,
on parle alors de cryptographie asymétrique ou cryptographie de
clé publique. La cryptographie de clé publique implique
une paire de clés, dont l'une est publique et l'autre privée.
La clé publique peut être mise librement à disposition,
tandis que le propriétaire conserve la clé secrète privée.
Ces deux clés sont complémentaires ; un message crypté
avec l'une des clés ne peut être décrypté qu'avec l'autre.
Création d'une paire de clés 133
Création d'une paire de clés

# ./usr/local/ssl/bin/openssl genrsa -rand
fichier1:fichier2:fichier3 \
-out www.exemple.com.key 1024
625152 semi-random bytes loaded
Generating RSA private key, 1024 bit long modulus
.....++++++
.........................++++++
e is 65537 (0x10001)
L'exemple montre comment créer une paire de clés en

utilisant l'outil de ligne de commande openssl.
genrsa indique à OpenSSL que vous souhaitez générer
une paire de clés à l'aide de l'algorithme RSA.
Le commutateur rand sert à fournir à OpenSSL des don-
nées aléatoires pour s'assurer que les clés générées sont
uniques et impossibles à deviner. Remplacez ensuite
fichier1, fichier2, etc. par le chemin menant à plusieurs
grands fichiers, relativement aléatoires (image de kernel,
fichiers journaux compressés, etc.). Ce commutateur n'est
pas nécessaire sous Windows, car les données aléatoires
sont automatiquement générées par d'autres moyens.
Le commutateur out indique où conserver les résultats.
1024 signale le nombre de bits de la clé générée.
Création d'une paire de clés

protégées par mot de passe
# ./usr/local/ssl/bin/openssl genrsa –des3 -rand
fichier1:fichier2:fichier3 \
-out www.exemple.com.key 1024
Ici, l'option des3 indique que la clé privée doit être cryptée
et protégée par un mot de passe qui vous sera demandé dès
que vous souhaiterez lancer le serveur, comme indiqué à la
section "SSLPassPhraseDialog".
Suppression du mot de passe

d'une clé
# ./usr/local/ssl/bin/openssl rsa -in
www.exemple.com.key \
-out www.exemple.com.key.unsecure
Vous pouvez choisir d'ôter la protection de la clé en émet-
tant cette commande. Cela présentant certains risques pour
la sécurité, veuillez consulter la section "SSLPassPhraseDia-
log".
Certificats
La cryptographie par clé publique peut servir à signer des
messages numériquement. Si, par exemple, vous cryptez
un message avec une clé secrète, le destinataire peut être
assuré qu'il provient de vous en le décryptant simplement
avec la clé publique. Il manque toutefois une étape. Com-
ment, en effet, pouvez-vous authentifier des correspon-
dants que vous n'avez jamais rencontrés en personne ?
Autrement dit, comment pouvez-vous vérifier à qui
appartient réellement une clé publique ?
La solution consiste à impliquer un tiers de confiance,
c'est-à-dire une autorité de certification (Certification
Authority, CA). La CA peut être interne à une société ou
à une université, ou encore être un organisme commercial
Création d'une requête de signature de certificat 135
proposant des services de certification aux entreprises qui

réalisent des transactions sur Internet. Une CA délivre des
certificats, à savoir des documents électroniques qui lient
une clé publique particulière à des informations concer-
nant son propriétaire, par exemple un nom et une adresse.
Les certificats sont signés numériquement avec la clé pri-
vée de la CA, ce qui garantit que les informations sont
correctes.
Pour que l'ensemble de ce processus fonctionne, vous
devez faire confiance à l'autorité qui a délivré le certificat.
Vous devez aussi pouvoir obtenir la clé publique pour
cette autorité particulière, fournie par son certificat racine.
La plupart des grands navigateurs, comme Internet Explo-
rer, Firefox et Safari, contiennent plusieurs certificats
racine, provenant des autorités de certification les plus
courantes. Cela permet aux navigateurs de reconnaître et
de valider un grand nombre de sites Web sans que l'utili-
sateur n'ait à intervenir.
Création d'une requête

de signature de certificat
# ./usr/local/ssl/bin/openssl req -new -key
www.exemple.com.key -out www.exemple.com.csr
Pour obtenir un certificat délivré par une autorité, vous

devez d'abord soumettre ce que l'on appelle une requête de
signature de certificat. Comme expliqué précédemment, la
requête contient des données sur l'organisme qui demande
le certificat et la clé publique. Cette commande crée une
requête de ce type. Sachez qu'il faudra fournir plusieurs
informations, comme indiqué au Listing 7.1.
Listing 7.1 Utilisation d'openssl pour générer une requête

de certificat
Using configuration from

/usr/local/ssl/openssl/openssl.cnf
Enter PEM pass phrase:
You are about to be asked to enter information that
will be incorporated
into your certificate request.
What you are about to enter is what is called a
Distinguished Name or a DN.
There are quite a few fields but you can leave some
blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:CA
Locality Name (eg, city) []: San Francisco
Organization Name (eg, company) [Internet Widgits
Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (eg, YOUR name) []:www.exemple.com
Email Address []:administrator@exemple.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Il faut savoir que l'entrée de champ "Common Name" corres-

pond à l'adresse que taperont les visiteurs de votre site
Web dans leur navigateur. C'est l'une des vérifications
réalisées par le navigateur pour le certificat de serveur dis-
tant. Si le nom diffère, un avertissement est affiché pour
l'utilisateur, précisant l'absence de concordance.
Affichage du contenu d'une requête de signature de certificat 137
Vous pouvez maintenant soumettre les fichiers de requête

de signature du certificat à une autorité de certification, à
des fins de traitement. Le processus varie selon les organis-
mes. Vous trouverez une liste complète des autorités de
certification à l'adresse http://www.pki-page.org/.
VeriSign, Thawte, GeoTrust et Equifax sont les plus con-
nues, mais il existe aussi d'autres autorités communautai-
res, comme Cacert (http://www.cacert.org/).
Affichage du contenu d'une

requête de signature de certificat
# ./usr/local/ssl/bin/openssl req -noout \
-text -in www.exemple.com.csr
Les requêtes de signature de certificat sont conservées dans

un formulaire spécial et compact. Cette commande affiche
le contenu du certificat conservé à l'adresse www.exem-
ple.com.csr dans un format lisible. Comme indiqué pré-
cédemment dans ce chapitre, le certificat contient des
informations sur l'entité qui le demande, le contenu de la
clé publique et une signature créée avec la clé privée.
Création d'un certificat

autosigné
Outre soumettre votre demande de signature de certificat
à une CA commerciale, vous pouvez toujours créer un
certificat autosigné, c'est-à-dire être à la fois l'émetteur et
l'objet du certificat. Même si cela n'est pas très utile pour
un site Web commercial, l'opération permet de tester
votre installation de mod_ssl ou de disposer d'un serveur

Web sécurisé, tout en attendant le certificat officiel de
l'autorité de certification.
# ./usr/local/ssl/bin/openssl x509 -req \
-days 30 -in www.exemple.com.csr -signkey \
www.exemple.com.key -out www.exemple.com.cert
Vous devez ensuite copier votre certificat www.exemple.com

.cert (celui renvoyé par l'autorité ou celui autosigné) à
/usr/local/ssl/openssl/certs et votre clé à /usr/local/
ssl/openssl/private/.
Protégez votre fichier de clés en émettant la commande
suivante :
# chmod 400 www.exemple.com.key
Compilation de la prise en charge

SSL dans Apache 1.3
$ gunzip < mod_ssl-2.8.23-1.3.33.tar.gz | tar xvf -
$ gunzip < apache_1.3.33.tar.gz | tar xvf -
$ cd mod_ssl-2.8.23-1.3.33
$ ./configure --with-apache=../apache_1.3.33
$ cd ../apache_1.3.x
$ SSL_BASE=/usr/local/ssl/ ./configure --enable-module=
ssl --prefix=/usr/local/apache
$ make
# make install
mod_ssl est un module très populaire qui assure la prise en

charge SSL à la fois pour Apache 1.3 et 2.x. Pour des rai-
sons historiques liées aux restrictions d'exportation sur la
cryptographie, la version Apache 1.3 est distribuée sépa-
rément du serveur. De plus, le code source d'Apache 1.3
doit être corrigé pour prendre en charge mod_ssl.
Compilation de la prise en charge SSL dans Apache 1.3 139
Cela est réalisé dans le cadre du processus de construction

mod_ssl, présenté au Listing 7.1. L'exemple construit Apa-
che 1.3.33 et mod_ssl 2.8.23 et suppose que les deux
répertoires source sont situés au même niveau. L'option
de ligne de commande --with-apache pointe vers
l'emplacement du répertoire du source Apache 1.3, qui
est ensuite recompilé pour inclure la prise en charge
mod_ssl.
Si vous élaborez votre installation par rapport à une
bibliothèque OpenSSL système, vous pouvez supprimer
SSL_BASE=/usr/local/ssl/ de l'étape de configuration
d'Apache.
Si Apache contient déjà les correctifs EAPI et la prise en
charge de modules chargeables, vous pouvez enfin utiliser
le mécanisme de construction APXS commun (voir Cha-
pitre 1). Il est utile, par exemple, pour mettre à niveau
une installation mod_ssl existante.
Attention
Si vous tentez de lancer Apache maintenant, vous obtiendrez
un message d'erreur indiquant qu'il est impossible de lire le
certificat du serveur. Consultez les sections précédentes pour
savoir comment créer votre certificat et vos clés de serveur et
la section "Configuration minimale d'Apache", plus loin dans
ce chapitre, pour savoir comment démarrer votre serveur. En
option, mod_ssl peut créer un certificat de serveur à des fins de
test lors du processus de construction. Pour cela, lancez un
make certificate avant make install.
Compilation de la prise en charge

SSL dans Apache 2.x
Apache 2 étant sorti après les réglementations d'exporta-
tion américaines sur la cryptographie, il propose mod_ssl
en complément des autres modules.
Si vous montez Apache à partir du source, vous pouvez
activer mod_ssl au moment de la construction, avec
l'option de configuration --enable-ssl. Si vous montez
également OpenSSL à partir de la source, vous devrez
ajouter --with-ssl=/usr/local/ssl/openssl.
Configuration minimale d'Apache

Une fois les clés et certificats générés, qu'ils soient autosi-
gnés ou certifiés par un tiers, vous allez configurer Apache.
Dans le cadre du processus d'installation, mod_ssl crée une
configuration SSL d'exemple. Apache 1.3 l'ajoute au fichier
httpd.conf par défaut ; quant à Apache 2.0, il comprend
un fichier ssl.conf séparé, référencé par une directive
Include dans httpd.conf. Il existe un grand nombre
d'options de configuration, ce qui peut être déroutant.
En réalité, seules quelques-unes vous seront nécessaires
pour la configuration, comme indiqué ici :
Listen 80
Listen 443
<VirtualHost _default_:443>
SSLEngine on
SSLCertificateFile \
/usr/local/ssl/openssl/certs/www.exemple.com.cert
SSLCertificateKeyFile \
/usr/local/ssl/openssl/certs/www.exemple.com.key
</VirtualHost>
Démarrage d'Apache avec prise en charge SSL 141
L'une des directives Listen indique à Apache d'écouter

sur le port HTTPS par défaut, 443. SSLEngine On active
SSL pour cet hôte particulier. Les directives SSLCertifi-
cateFile et SSLCertificateKeyFile pointent vers le certi-
ficat et la clé privée.
Démarrage d'Apache
avec prise en charge SSL
Une fois mod_ssl installé et configuré, vous pouvez lancer
à Apache avec :
apachectl start
Si vous utilisez des fichiers de configuration SSL par défaut

(ou ceux fournis par votre vendeur), les directives SSL
seront probablement entourées d'un bloc <IfDefine SSL>.
Vous pouvez, soit retirer ces blocs, soit démarrer Apache
avec :
apachectl startssl
Cela transfère la balise -DSSL au binaire du serveur et

active la configuration SSL.
Attention
Cela ne doit être réalisé que dans Apache 1.3 et 2.0. En effet,
Apache 2.2 n'intégrant plus l'option startssl, les directives
SSL ne sont plus considérées différemment des autres.
Si vous avez protégé votre clé privée par un mot de

passe, indiquez-le maintenant. Si vous avez installé Apa-
che en tant qu'utilisateur ordinaire, il est possible qu'il ait
été configuré pour écouter par défaut sur le port 8443.
Comme expliqué au Chapitre 2, le port 443 est un port

à privilèges et il n'est accessible que par le superutilisa-
teur.
Vous pouvez tester l'installation en accédant au serveur, à
l'adresse https://www.exemple.com (ou https://www.exem-
ple.com:8443, nous venons de l'expliquer).
SSLPassPhraseDialog
SSLPassPhraseDialog builtin
Si vous avez protégé votre clé privée du serveur par mot

de passe, vous devrez le saisir au moment du démar-
rage. Vous pouvez contrôler ce comportement avec
SSLPassPhraseDialog. Sa valeur par défaut, builtin, signi-
fie qu'Apache demandera le mot de passe directement, à
chaque démarrage du serveur. Vous pouvez aussi choisir
de ne pas protéger la clé (notamment pour des raisons de
commodité ; vous n'aurez ainsi pas besoin de saisir manuel-
lement le mot de passe à chaque redémarrage). Attention,
cependant ! Dans ce cas, si le serveur rencontre un pro-
blème, il en ira de même pour la clé. Vous pouvez éga-
lement configurer SSLPassPhraseDialog pour appeler un
programme externe, qui fournira le mot de passe sur son
entrée standard lorsqu'il sera appelé par Apache.
Avec un script correctement rédigé, vous obtenez davan-
tage de sécurité que si vous laissiez la clé sans protection
(mais pas beaucoup plus).
Amélioration des performances SSL 143
Amélioration
des performances SSL
Les algorithmes impliqués dans SSL sont gourmands en
unité centrale et peuvent considérablement ralentir le
serveur, en particulier en cas de connexions client simul-
tanées. La phase d'échange d'informations peut également
retarder la requête. Plusieurs options peuvent cependant
améliorer la capacité de réponse d'un site.
Vérifiez de bien avoir activé la mise en cache de la session.
Cela accélère les situations où il existe plusieurs connexions
à partir du même client. En cas de grappe de serveurs SSL,
utilisez distcache, de sorte que les données de connexion
puissent être mises en cache même si le client se connecte
à plusieurs serveurs dans la grappe. Apache 2.2 assure la
prise en charge du distcache dès l'installation. Vous en
saurez plus sur ce projet en vous rendant à l'adresse
http://www.distcache.org.
Vous pouvez aussi envisager de disposer d'une machine
dédiée, réservée au traitement SSL. Selon vos besoins, il
peut s'agir d'un équilibreur de charge commercial (élément
matériel) ou d'une machine dédiée exécutant un proxy
inverse (un serveur Web qui se fie à des requêtes vers
d'autres serveurs Web au nom du client). Cela permet
d'apporter des améliorations dans la configuration d'Apache
et du système d'exploitation qui ne seraient pas possibles si
la machine servait également à d'autres objectifs, comme
l'exécution de PHP, de Tomcat et de MySQL. Un proxy
inverse peut offrir des avantages supplémentaires, comme
l'équilibrage des charges et la connexion unique, avec
possibilité d'utiliser des certificats client, sur plusieurs sites
Web d'arrière-guichet. Consultez le Chapitre 10 pour en
savoir plus.
Enfin, vous pouvez installer une carte de cryptographie,

un matériel conçu pour décharger le serveur de la majeure
partie du traitement SSL. Apache 2.2 prend en charge
cette fonctionnalité ; consultez pour cela la directive
SSLCryptoDevice.
Forcer le contenu à être desservi

par SSL
<VirtualHost 192.168.200.4:80>
ServerName private.exemple.com
Redirect / https://private.exemple.com/
</Virtualhost>
Si vous disposez d'un site Web particulier qui ne doit être
desservi que par SSL, vous pouvez utiliser un Redirect
dans une section <VirtualHost> qui écoute les requêtes
HTTP et les redirige vers un site Web sécurisé (comme
indiqué dans l'exemple). L'opération est utile, car les utilisa-
teurs oublient parfois de taper https:// au lieu de http://.
SSL et hôtes virtuels SSL basés

sur le nom
Une question revient souvent chez les utilisateurs de
mod_ssl : "Est-il possible de disposer de plusieurs hôtes vir-
tuels basés sur le nom et activés par SSL ?" La réponse est
non. Le problème est que l'hébergement virtuel basé sur le
nom repose sur des informations fournies par le client dans
l'en-tête Host: de la requête HTTP, puisque tous les hôtes
virtuels basés sur le nom partagent la même adresse IP.
Utilisation des modules Auth d'Apache avec SSL 145
Toutefois, la connexion SSL a lieu au niveau TCP, avant

que la requête HTTP ne puisse être envoyée. Le serveur
n'est donc pas capable de déterminer, au moment de la
connexion, l'hôte virtuel auquel le client veut se connec-
ter et donc le certificat et la clé à utiliser. A noter qu'il
existe une spécification (RFC 2817) qui autorise la mise à
niveau d'une connexion HTTP existante vers HTTPS.
Cela permet de contourner le problème mais, à l'heure où
nous écrivons ces lignes, elle n'est implémentée par aucun
grand navigateur. Le module mod_ssl d'Apache 2.2
implémente la prise en charge de RFC 2817, tout comme
mod_nw_ssl, le module SSL Apache de Netware.
Utilisation des modules Auth

d'Apache avec SSL
SSLOptions +FakeBasicAuth
Lorsque cette option est activée, le nom distinctif (ou

Subject Distinguished Name) du certificat client est traduit
en un nom d'utilisateur avec autorisation de base HTTP.
Cela signifie que les méthodes d'authentification Apache
standard (voir Chapitre 6) peuvent être utilisées pour le
contrôle d'accès. Ces modules d'authentification "croient"
que l'utilisateur a fourni un nom et un mot de passe vala-
bles. Vous devrez modifier certains paramètres dans vos
bases de données utilisateur.
Messages d'avertissement
lors de l'accès à un site Web
activé par SSL
Parfois, lors de l'accès à un site Web activé par SSL, les uti-
lisateurs voient s'afficher une fenêtre contextuelle d'aver-
tissement indiquant que quelque chose ne va pas avec le site
Web. Voici quelques-unes des causes les plus fréquentes :
b Le certificat a expiré. Les certificats commerciaux sont
généralement valables pendant une période donnée,
après quoi ils expirent.
b Le domaine du certificat ne correspond pas au
domaine du serveur. Cela survient si le certificat a été
délivré pour un site Web différent.
b Le certificat a été signé par une autorité de certifica-
tion inconnue ou en laquelle le navigateur n'a pas
confiance. Cela peut survenir, par exemple, si vous
utilisez un certificat autosigné à des fins de test.
Création de certificats client

Lorsque vous utilisez l'autorisation de certificat client, le
serveur vérifie, lors de la phase d'échange de données, que
le client présente un certificat valide et que ce dernier a été
signé par une autorité de confiance. Même si cela est lourd
à gérer et à distribuer, les certificats client protègent l'accès
aux sites ou aux services Web de la société. Ils sont souvent
davantage sécurisés que les noms d'utilisateur et les mots de
passe, car ils ne peuvent être ni devinés ni interceptés.
Pour devenir votre propre autorité de certification, la pre-
mière étape consiste à créer une CA racine. Pour cela, uti-
lisez l'argument ca de l'outil de ligne de commande ou
bien le script d'enveloppe CA.pl, intégré avec openssl.
Authentification à l'aide des certificats client 147
Pour créer une nouvelle autorité de certification, vous

pouvez émettre la commande suivante :
CA.pl -newca
Le script génère alors une clé privée, un certificat de
serveur, etc., ainsi qu'une structure de répertoires qui
contient les fichiers générés.
Vous pouvez maintenant créer une demande de signature
de certificat (CSR) et signer votre certificat avec :
CA.pl -newreq
CA.pl -signreq
Le fichier de CA généré aura le format PEM. Pour le
convertir dans un format autre qui le rende plus commode
à importer dans les navigateurs, exécutez la commande
suivante :
CA.pl -pkcs12
La méthode exacte pour importer le certificat vers la
machine de l'utilisateur final varie selon le type du naviga-
teur. Les utilisateurs d'Internet Explorer n'ont qu'à cliquer
sur le fichier de certificat et à suivre les instructions.
Authentification à l'aide
des certificats client
SSLVerifyClient require
SSLCACertificateFile \
/usr/local/ssl/openssl/certs/ca.crt
Une fois que vous avez installé des certificats dans vos
clients, vous devez demander à Apache d'activer la valida-
tion SSL pour les clients. Cette directive SSLVerifyClient
exige des clients qu'ils fournissent un certificat valide pour
pouvoir se connecter. SSLCACertificateFile fournit le che-

min vers le fichier contenant le certificat CA de confiance
qui servira à vérifier la validité du certificat client.
Alternatives à mod_ssl
Il existe plusieurs alternatives à mod_ssl. Pour Apache 1.3,
vous pouvez utiliser Apache-SSL, le module qui se trouve
être à l'origine de mod_ssl. Vous le trouverez à l'adresse
http://www.apache-ssl.org. Plusieurs sociétés com-
merciales, comme IBM, disposent de leurs propres modules
SSL, inclus dans leurs packages de serveur Web basés sur
Apache, et utilisant généralement des boîtes à outils autres
que OpenSSL.
Enfin, vous pouvez choisir un utilitaire indépendant,
comme stunnel (http://www.stunnel.org), pour placer
en proxy les connexions SSL à un serveur Apache existant.
Même s'il n'est pas aussi flexible que mod_ssl, il peut être
pratique pour certains scénarios lorsqu'il n'est pas possible
ni souhaitable de modifier une configuration de serveur
en fonctionnement.
Test de sites Web activés par SSL

à partir de la ligne de commande
# openssl s_client -connect www.ibm.com:443
Vous pouvez utiliser openssl ou d'autres outils basés sur

SSL, comme stunnel (http://www.stunnel.org), pour
tester des serveurs Web sécurisés. Il est notamment possible
d'employer cette commande pour vous connecter au site
Web d'IBM à l'aide de HTTPS. Vous obtiendrez des
Contourner les implémentations SSL présentant des bogues 149
détails sur le protocole SSL et le certificat de serveur pour

la connexion. Vous pouvez également émettre une com-
mande GET / HTTP/1.0 et appuyer sur Entrée pour obtenir
une réponse, comme si vous aviez utilisé Telnet pour
vous connecter à un serveur Web ordinaire sur le port 80
pour émettre des requêtes HTTP manuellement (voir
Chapitre 1).
Contourner les implémentations

SSL présentant des bogues
SetEnvIf User-Agent ".*MSIE.*" nokeepalive \
ssl-unclean-shutdown downgrade-1.0 \
force-response-1.0
Certains navigateurs (ou serveurs, s'ils opèrent dans une

configuration de proxy inverse) présentent des problèmes
connus avec des versions spécifiques du protocole SSL ou
de certaines fonctions. Certaines variables d'environne-
ment peuvent être réglées pour forcer des comportements
spécifiques. Cela est particulièrement utile si vous dispo-
sez d'un site commercial et que vous deviez prendre en
charge des navigateurs plus anciens. Ainsi, l'extrait pré-
senté ici, qui figure dans le fichier de configuration par
défaut, contourne les bogues de l'implémentation SSL des
navigateurs Internet Explorer. Si le navigateur client
contient la chaîne MSIE, la prise en charge de maintien
en activité (keep-alive) sera mise en service, pour porter son
choix sur une précédente version du protocole HTTP.
Contrôle d'accès complexe

avec mod_ssl
SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)-/ \
and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}\
and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
Cet exemple montre comment utiliser la directive SSLRe-

quire pour implémenter les restrictions d'accès arbitraires
fondées sur plusieurs paramètres. Comme cela arrive avec
mod_rewrite, SSLRequire peut être complexe à configurer,
mais il offre des possibilités quasi illimitées. L'extrait de
configuration qui précède vérifie que :
b La connexion SSL n'utilise pas un chiffrage d'exporta-
tion (faible) ou un chiffrage NULL, que le certificat a
été émis par une CA particulière et pour un groupe
particulier et que l'accès a lieu pendant les jours de
travail (du lundi au vendredi), aux heures de travail
(de 8 h 00 à 20 h 00).
b Le client provient d'un réseau interne, de confiance
(comme indiqué par REMOTE_ADDR).
Veuillez vous reporter à la documentation de SSLRequire

pour plus d'informations.
Chapitres annexes
Si vous utilisez Apache comme proxy inverse, sachez que
les informations relatives au certificat et aux connexions
liées à SSL pour les clients ne sont pas disponibles pour les
serveurs d'arrière-guichet. Vous apprendrez à résoudre ce
problème au Chapitre 10.
8
Publication de
contenu avec DAV
Apache et la publication
de contenu
Si vous proposez des services d'hébergement à d'autres
utilisateurs, il faut leur fournir une méthode efficace pour
charger et entretenir leurs sites Web. Ce chapitre traite du
module mod_dav et indique comment le mettre en œuvre
pour offrir aux utilisateurs un moyen de gérer leur
contenu. Nous donnons ici des explications sur les
méthodes qui restreignent l'accès en écriture à des res-
sources particulières, sur la manière de configurer diffé-
rents clients (y compris des dossiers Web de Windows),
ainsi que sur certains des problèmes les plus fréquents.
Vous trouverez également des informations sur la façon
d'activer des répertoires par utilisateur, de sorte que cha-
que utilisateur dispose de son propre espace sur le Web.
152 CHAPITRE 8 Publication de contenu avec DAV
Présentation de WebDAV
WebDAV signifie Web-based Distributed Authoring and
Versioning. C'est un protocole qui prolonge HTTP et
permet aux utilisateurs de charger et de modifier leur
contenu à distance. Pour apprécier la fabuleuse avancée
procurée par WebDAV, il est nécessaire de comprendre
les limitations des précédentes méthodes de publication.
Aux premiers temps du Web, les Webmestres et les admi-
nistrateurs système éditaient le contenu d'un serveur
directement à partir de la coque (shell) en utilisant des édi-
teurs de texte, comme vi ou emacs. A mesure que le Web
a grandi, différents postes sont apparus : les administrateurs
entretenaient le serveur et les utilisateurs et les program-
meurs fournissaient le contenu. Des mécanismes étaient
nécessaires aux utilisateurs pour envoyer et modifier leur
contenu. Or, cette séparation des tâches nécessitait des
règles de restriction d'accès et des méthodes simples à uti-
liser pour des non-techniciens. Les moyens permettant de
générer un contenu Web sont passés de simples éditeurs
de texte à des outils de publication sophistiqués, plus pro-
ches des traitements de texte en termes de fonctionnalités
et de simplicité d'utilisation.
Malheureusement, il n'existait pas de méthode standard
permettant aux uns comme aux autres de charger du con-
tenu. Les solutions étaient diverses : autoriser les utilisa-
teurs à accéder à la coque du système, ou bien employer
le protocole FTP ou d'autres protocoles propriétaires.
L'accès à la coque exige que vos utilisateurs connaissent les
bases de la ligne de commande UNIX. Cela entraîne des
complexités et des problèmes de sécurité liés à l'autorisa-
tion de l'accès direct au serveur. L'emploi d'un client FTP
exige, d'une part que les utilisateurs téléchargent et installent
un outil supplémentaire, d'autre part qu'un serveur FTP
soit installé. Enfin, les scripts personnalisés, le chargement
Avantages de l'utilisation de mod_dav 153
des fichiers par l'intermédiaire de formulaires HTML et

les protocoles propriétaires (notamment ceux utilisés par
Microsoft FrontPage) soulèvent plusieurs problèmes de
fonctionnement croisé et de sécurité.
WebDAV permet de contourner ces problèmes en pro-
posant un protocole standard qui peut être implémenté
dans le cadre du serveur Web. WebDAV prolonge le pro-
tocole HTTP avec de nouvelles méthodes pour permettre,
entre autres, la création, la suppression et le verrouillage
de ressources à des fins d'édition. WebDAV est implé-
menté dans Apache avec mod_dav, qui est distribué sous
forme de module tiers pour Apache 1.3 et sous forme de
module intégré pour Apache 2.0.
Avantages de l'utilisation
de mod_dav
Nous l'avons vu à la section précédente, mod_dav est
implémenté sous forme de module Apache qui prolonge
le protocole HTTP. Il peut profiter de plusieurs fonctions
intégrées d'Apache, comme SSL pour le cryptage et
l'authentification basée sur le certificat, l'authentification
de base HTTP, les serveurs proxy, etc. L'intégration dans
Apache offre de nombreuses autres possibilités, comme le
partage des mécanismes de contrôle d'accès et l'interaction
avec les moteurs de script, comme mod_perl et PHP.
Le protocole DAV lui-même est extensible. Même si les
ressources accessibles par DAV résident généralement
dans le système de fichiers, DAV peut agir comme un
frontal fondé sur les normes pour toute une série de réfé-
rentiels d'arrière-guichet (comme les bases de données, les
systèmes de contrôle des versions et les structures de ges-
tion documentaire propriétaires).
Par exemple, DAV intègre le concept des collections (à

savoir des groupes de fichiers), qui permet généralement
d'opérer un transfert vers un répertoire du serveur. Atten-
tion, cependant, cela peut prendre une signification tota-
lement différente pour d'autres systèmes d'arrière-guichet.
Enfin, WebDAV a été implémenté par la plupart des
structures de publication Web modernes, les suites Office
et les environnements de bureau.
WebDAV et le protocole HTTP

DAV est implémenté au-dessus du protocole HTTP stan-
dard qui permet aux navigateurs et aux serveurs Web de
communiquer. Il prolonge les méthodes HTTP existantes
et en inclut de nouvelles, comme indiqué ici. Ces informa-
tions vous seront nécessaires pour implémenter le contrôle
d'accès et écrire sur des ressources activées pour DAV :
b COPY. Copie des fichiers ou des collections (l'équiva-
lent des répertoires du système de fichiers). Des en-têtes
supplémentaires permettent de spécifier la copie
récursive de collections imbriquées.
b MOVE. Déplace des fichiers et des collections.
b MKCOL. Crée une nouvelle collection. Si les collections
parentes n'existent pas, une erreur est renvoyée. Les
collections parentes doivent être explicitement créées
à l'aide de la méthode PUT.
b PROPFIND. Nous avons vu précédemment que les
ressources DAV pouvaient être associées à des infor-
mations de métadonnées. La méthode PROPFIND permet
d'interroger ces métadonnées.
b PROPPATCH. Cette méthode permet de supprimer, de

créer et de modifier des métadonnées de ressources.
b LOCK et UNLOCK. Ces méthodes permettent de verrouiller
une ressource. Elles servent, par exemple, à éviter
qu'une ressource ne soit modifiée alors que vous l'éditez.
Le protocole DAV prolonge les méthodes HTTP existan-

tes, comme GET et PUT, principalement pour les avertir des
nouvelles fonctions de verrouillage. La méthode OPTIONS
est prolongée pour rapporter les capacités DAV.
Installation de mod_dav
sous Apache 2.0
./configure --enable-dav
Apache 2.0 inclut mod_dav, même s'il n'est pas activé par
défaut. Vous pouvez l'activer comme vous le feriez avec
n'importe lequel des autres modules intégrés. Par défaut, il
compile également l'arrière-guichet du système de fichiers
(--enable-dav-fs). Il est également possible de disposer
d'autres arrière-guichets pour DAV, comme le système de
gestion de source et les bases de données Subversion.
Si vous utilisez la distribution Apache 2 Windows, sachez
que mod_dav y figure déjà sous forme de DLL. Il suffit
donc d'activer les directives LoadModule dans le fichier de
configuration httpd.conf :
LoadModule dav_module modules/mod_dav.so
LoadModule dav_fs_module modules/mod_dav_fs.so
Installation de mod_dav
sous Apache 1.3
tar xvfz mod_dav-1.0.3-1.3.6.tar.gz
cd mod_dav-1.0.3-1.3.6
./configure --with-apxs=/usr/local/apache/bin/apxs
make
make install
Apache 1.3 ne dispose pas d'une prise en charge intégrée
de DAV. Il vous faut télécharger et installer mod_dav,
comme vous le feriez avec n'importe quel autre module
tiers (voir l'extrait de configuration). Vous pouvez télé-
charger le code source UNIX et les binaires Windows
aux adresses http://www.webdav.org/mod_dav/ et
http://www.webdav.org/mod_dav/win32/.
Configuration WebDAV de base

DAVLockDB /usr/local/apache/var/DAVLock
<Location />
Dav On
La configuration de DAV est très simple. Il suffit de faire
figurer DAV on à l'emplacement (ou dans la section de
répertoire) qui doit être accessible par DAV. L'exemple
montre comment activer DAV sur un site Web. DAV
possède son propre mécanisme de verrouillage et ne repose
pas sur la fonctionnalité du système de fichiers sous-jacent.
A noter qu'il est possible de préciser l'emplacement du
fichier de verrouillage DAV, grâce à la directive DAVLockDB.
Il existe toutefois d'autres aspects de la configuration DAV
qui doivent être traités dans un environnement DAV de
production. Ils concernent la sécurité et le fonctionne-
ment croisé avec des clients tiers contenant des bogues.
Ces questions seront traitées aux sections suivantes.
Sécurisation de votre configuration WebDAV 157
Sécurisation de votre
configuration WebDAV
<LimitExcept GET HEAD OPTIONS>
require user davuser
</LimitExcept>
Par défaut, l'activation de DAV présente un risque grave

pour la sécurité. Les utilisateurs seront en effet en mesure
de lire et de modifier le contenu Web (dont le source des
scripts CGI ou PHP, qui peut contenir des noms d'utili-
sateur et des mots de passe sensibles). Il est donc nécessaire
de protéger l'accès aux ressources activées par DAV. DAV
étant placé au-dessus du HTTP, cette procédure peut être
accomplie à l'aide de modules de contrôle d'accès Apache
standard. L'exemple montre comment exiger un mot de
passe et un nom d'utilisateur valides pour accéder en écri-
ture à une ressource DAV, comme MKCOL. L'opération est
réalisée à l'aide de mod_auth (voir Chapitre 6) et de la
directive <LimitExcept>.
Listing 8.1 : Protection de l'accès DAV
<Location />
Dav On
AuthType basic
AuthName "DAV Resource"
<LimitExcept GET HEAD OPTIONS>
require user davuser
</LimitExcept>
</Location>
<Limit> et <LimitExcept> sont deux directives de sections

permettant d'appliquer des paramètres de configuration
donnés à certaines méthodes de requête spécifiques. Même
si elles ne sont pas très utiles pour du HTTP ordinaire,
elles peuvent servir pour des configurations DAV. L'exem-
ple permet à tout le monde d'accéder au contenu Web en
employant des méthodes HTTP pures, mais restreint l'accès
DAV aux seuls utilisateurs autorisés.
Il existe d'autres mesures, comme l'exécution de DAV sur
une instance séparée et à usage unique d'Apache. Ce ser-
veur Apache peut s'exécuter sur un port séparé, et être
facilement divisé et sécurisé. Vous pouvez également le
configurer pour qu'il exige un contrôle d'accès basé sur
SSL ou IP, et ce afin d'obtenir une protection supplémen-
taire.
Accès aux ressources DAV

depuis Microsoft Office
Les versions récentes de Microsoft Office (comme
Office 2000 et Office XP) permettent d'ouvrir et d'éditer
des documents à partir des serveurs activés par DAV,
notamment dans des versions récentes d'Exchange. Il suf-
fit de spécifier l'URL d'un emplacement activé par DAV
dans la boîte de dialogue Ouvrir de l'application, ou d'uti-
liser la boîte de dialogue d'ajout d'un nouvel emplacement
réseau (voir Figure 8.1). Une fois fait, vous pourrez faci-
lement créer, modifier et partager des documents sur le
serveur distant.
Accès aux ressources DAV depuis Microsoft Windows 159
Figure 8.1 Ajout d'un favori réseau sous Microsoft Office.

depuis Microsoft Windows
Les versions récentes des systèmes d'exploitation Microsoft
(comme Windows 2000 et Windows XP) assurent la prise
en charge de DAV par le biais des dossiers Web. Ceux-ci
assurent un accès transparent aux serveurs activés par DAV
en les présentant sous forme de dossiers du Bureau Win-
dows. Les utilisateurs de Windows peuvent alors faire
glisser les fichiers vers ces dossiers, double-cliquer pour les
modifier, etc. Il est également possible d'accéder à une
ressource DAV sous forme de dossier Web sur une machine
Windows 2000, directement depuis Explorer ou en utili-
sant un assistant.
Dans la suite de cette section, nous supposerons qu'un ser-

veur Apache dessert le domaine www.exemple.com avec
une prise en charge DAV activée sous la section /davdocs
du site. Assurez-vous que la directive RedirectCarefully
appropriée soit en place (voir, plus loin, la section "Ges-
tion des clients présentant des bogues").
Ouvrez une fenêtre Internet Explorer. Cliquez sur le menu
Fichier et sélectionnez Ouvrir. Une fenêtre contextuelle
s'affiche (voir Figure 8.2).
Figure 8.2 Ouverture d'une ressource

DAV depuis Explorer.
Tapez l'URL suivante : http://www.exemple.com/

davdocs/. Cochez l'option Ouvrir en tant que dossier
Web, et cliquez sur OK. Explorer se connecte à la ressource.
Vous devriez maintenant pouvoir créer des répertoires,
faire glisser des fichiers et les modifier (voir Figure 8.3).
L'emplacement est automatiquement ajouté au dossier
Favoris réseau. Vous pouvez y accéder en cliquant sur
l'icône de Bureau portant ce nom.
Vous pouvez également ajouter un dossier Web à l'aide
d'un assistant. Pour cela, accédez d'abord au dossier Favo-
ris réseau mentionné à la section précédente, cliquez sur
l'icône Ajouter un favori réseau, puis suivez les instruc-
tions à l'écran.
Accès aux ressources DAV depuis Firefox 161
Figure 8.3 Vue d'une ressource DAV.

depuis Firefox
A l'heure où nous écrivons ces lignes, Firefox n'assure
aucune prise en charge native pour accéder aux ressources
DAV. Toutefois, l'extension openwebfolder (sous Win-
dows uniquement) permet de se connecter au composant
Microsoft Windows WebDAV, ce qui procure l'accès aux
ressources DAV depuis Firefox. L'outil est disponible à
l'adresse http://openwebfolder.mozdev.org/.
Pour l'installer, cliquez simplement sur le lien http://
open-webfolder.mozdev.org/installation.html
depuis Firefox et suivez les instructions. Une fois que
vous avez redémarré Firefox, cliquez du bouton droit sur
n'importe quelle page, puis sélectionnez "Open as Web

Folder" dans le menu contextuel pour y accéder par le
biais de WebDAV (voir Figure 8.4).
Figure 8.4
Ouverture d'un dossier
Web depuis Firefox.
Accès à DAV depuis la ligne

de commande
./cadaver
dav:!> open http://exemple.com
Plusieurs clients à la ligne de commande sont disponibles

pour accéder aux ressources activées par DAV, ce qui sim-
plifie l'interactivité et l'intégration dans des scripts adminis-
tratifs. Ils peuvent servir de remplacements pour leurs
contreparties FTP et scp. cadaver et sitecopy sont deux
des clients à la ligne de commande Open Source les plus
populaires. cadaver est une "coque interactive" qui propose
des commandes de style FTP, comme ls, put, get, etc.
Accès à DAV depuis la ligne de commande 163
L'exemple montre comment utiliser cadaver pour accéder

à un serveur Web activé par DAV, répertorier les ressources
disponibles et modifier un fichier distant :
./cadaver
dav:!> open http://exemple.com
dav:/> ls
Listing collection `/': succeeded.
Coll: images 0
Dec 7 2004
Coll: styles 0
Dec 12 2004
Home.html 4816
Aug 14 14:19
company.html 5352
Dec 7 2004
partners.html 6087
Dec 7 2004
solutions.html 3037
Dec 7 2004
dav:/> edit solutions.html
Locking `solutions.html': succeeded.
Downloading `/solutions.html' to
/tmp/cadaver-editzEzdL9.
html
Progress: [=============================>] 100.0% of
6230 bytes succeeded.
Running editor: `vi /tmp/cadaver-editzEzdL9.
html'...
Changes were made.
Uploading changes to `/solutions.html'
Progress: [=============================>] 100.0% of
6232 bytes succeeded.
Unlocking `solutions.html': succeeded.
dav:/>
cadaver peut être téléchargé à l'adresse http://www.

webdav.org/cadaver.
sitecopy permet de maintenir la synchronisation entre

une arborescence de documents locale et un serveur dis-
tant, à l'aide de plusieurs protocoles, notamment DAV. Il
peut être téléchargé à l'adresse http://www.lyra.org/
sitecopy.
Gestion des clients présentant

des bogues
BrowserMatch "Microsoft Data Access Internet
Publishing Provider" redirect-carefully
BrowserMatch "^gnome-vfs" redirect-carefully
Si vous ne parvenez pas à vous connecter à votre serveur

DAV à l'aide des dossiers Web de Microsoft ou d'ancien-
nes versions de dossiers virtuels Gnome, et que vous obte-
niez une mention semblable à :
"OPTIONS /davdocs HTTP/1.1" 301
dans votre journal d'accès, c'est que vous avez rencontré

un bogue avec certaines implémentations client de Web-
DAV. Apache envoie une redirection (HTTP code 301)
au client, mais celui-ci, dans la confusion, ne suit pas la
redirection. Apache propose un contournement à ce
comportement, en ignorant la redirection lorsque la varia-
ble d'environnement redirect-carefully est paramétrée.
Cet exemple (proposé dans le fichier de configuration
Apache par défaut) définit la variable d'environnement
redirect_carefully pour deux clients WebDAV connus
pour rencontrer les problèmes mentionnés.
mod_speling et DAV 165
mod_speling et DAV
Si vous utilisez DAV, vous devrez obligatoirement désac-
tiver mod_speling. En effet, ce module interfère avec plu-
sieurs opérations liées à DAV (comme la création de
nouvelles ressources) en les faisant correspondre par
erreur à des fichiers existants si les noms sont similaires.
mod_speling sert à corriger les erreurs ou les fautes
d'orthographe de l'utilisateur (voir Chapitre 4).
Contenu dynamique et DAV

Alias /php /usr/local/apache/php_files
Alias /php-source /usr/local/apache/php_files
<Location /php-source>
DAV On
ForceType text/plain
</Location>
Si vous accédez à des ressources générées dynamiquement

(comme des pages PHP ou des script CGI), vous risquez
de rencontrer ce problème : Apache renvoie ce contenu
généré dynamiquement, et non le code source du fichier.
Autrement dit, vous obtenez le contenu du fichier après
qu'il a été traité par le serveur Web, et non le code source.
Pour contourner cela, vous pouvez lancer un serveur
Web ou un hôte virtuel indépendant, sur lesquels la prise
en charge de PHP n'est pas activée (voir précédemment).
Vous pouvez aussi mettre en correspondance le chemin
du système de fichiers avec différentes URL et activer ou
désactiver les modules de manière sélective. L'exemple
(extrait de la documentation DAV) montre comment
procéder. On oblige ici tout le contenu desservi par l'URL
/php-source à adopter le type text/plain, ce qui évite
l'exécution par le moteur PHP.
Activation des pages

par utilisateur
UserDir enabled
UserDir public_html
Avez-vous déjà accédé à une URL du type http://www
.exemple.com/~joe ?
C'est ce que l'on appelle une "page Web par utilisateur".
Chaque utilisateur du système se voit affecter une URL
qui commence par le signe ~, suivi de son nom. Quand
Apache trouve une requête de ce type, il la met en con-
cordance avec un chemin spécial dans le répertoire
d'accueil de l'utilisateur. Cette fonctionnalité permet à
chacun des utilisateurs de publier son propre contenu.
Elle est fournie par mod_userdir. Sachez que vous pouvez
l'activer ou la désactiver avec les directives de configura-
tion UserDir enabled et UserDir disabled. Vous pouvez
également spécifier une liste supplémentaire de noms
d'utilisateurs à activer ou à désactiver de manière sélective,
comme dans UserDir disabled mysql root.
Si le premier argument est différent de enabled ou disa-
bled, il sert à spécifier l'endroit où sont stockés les sites par
utilisateur. Par exemple, UserDir public_html fera concorder
une requête pour http://www.exemple.com/~utilisateur
avec /home/utilisateur/public_html/.
Le chemin peut aussi contenir un motif tel que :
UserDir /home/*/Web
qui correspondra à http://www.exemple.com/~utilisateur/

index.thml, à l'adresse :
/home/utilisateur/Web/index.html
Autres répertoires utilisateur 167
Les répertoires par utilisateur doivent être lisibles pour

l'utilisateur sous lequel Apache s'exécute.
Enfin, vous pouvez choisir de rediriger le client vers une
certaine URL. Par exemple :
UserDir http://www.exemple.com
fera concorder http://www.exemple.com/~utilisateur/

index.thml avec :
http://www.exemple/user/index.html
Autres répertoires utilisateur

RewriteEngine On
RewriteCond %{HTTP_HOST} !^(www\.)
RewriteCond %{HTTP_HOST} ^([^.]+)\.exemple\.com
RewriteRule ^(.*)$ /home/%1/public_html$1
Si vous ne souhaitez pas activer mod_dir ou que vous ayez

besoin d'une fonctionnalité légèrement différente de ce qui
est proposé, vous pouvez envisager d'utiliser mod_vhost
_alias ou mod_rewrite. L'exemple montre comment uti-
liser mod_rewrite pour faire concorder des requêtes desti-
nées à utilisateur.exemple.com au répertoire HTML par
utilisateur qui convient.
Résolution des problèmes

avec DAVLockDB
No such file or directory: A lock database was not
specified with the DAVLockDB directive. One must be
specified to use the locking functionality. [500,#401]
Si vous rencontrez un message de ce type, cela signifie

que vous devez fournir une directive DavLockDB dans le
fichier de configuration, comme indiqué :
DAVLockDB /usr/local/apache/var/DAVLock
Si la directive est spécifiée mais que le répertoire conte-

nant le fichier de verrouillage ne soit pas inscriptible, vous
obtiendrez un message analogue à celui-ci :
The lock database could not be opened, preventing
access to the various lock properties for the
PROPFIND. [500, #0]
Vous devez résoudre les autorisations, de sorte que le che-

min de la directive DavLockDB possède des autorisations en
écriture, destinées à l'utilisateur sous lequel Apache s'exé-
cute.
9
Performances
et évolutivité
Personnalisation d'Apache
Ce chapitre décrit les options de configuration qui ris-
quent d'affecter les performances et l'évolutivité d'Apache
et indique la manière de les personnaliser. Heureusement,
dans la plupart des cas, cela ne sera pas nécessaire. En effet,
la plupart des problèmes de vitesse et d'évolutivité pro-
viennent généralement du moteur de génération de con-
tenu dynamique ou de la couche de la base de données, et
non du serveur Web Apache lui-même. A noter que cer-
tains des problèmes et des solutions traités dans ce chapitre
sont suffisamment génériques pour s'appliquer à la plupart
des logiciels de serveurs, tandis que d'autres sont spécifi-
ques à Apache.
170 CHAPITRE 9 Performances et évolutivité
Les performances et l'évolutivité

Améliorer les performances et l'évolutivité de n'importe
quel système informatique implique un mélange d'expé-
rience, de travail de profilage et de compréhension du
fonctionnement interne du serveur. Ce chapitre propose
plusieurs suggestions et idées pratiques pour vous aider à
démarrer. Pour clarifier les choses, sachez que les performan-
ces permettent de répondre plus rapidement aux requêtes,
tandis que l'évolutivité consiste à desservir un grand nom-
bre de requêtes simultanément.
Personnalisation du matériel
vmstat
Il est probable que l'action la plus importante qu'il soit

possible de réaliser pour améliorer les performances d'un
serveur consiste à augmenter la quantité de RAM. Cette
RAM supplémentaire permet au système d'exploitation
de mettre en cache des fichiers disque d'accès fréquent,
ainsi que de prendre en charge plusieurs enfants Apache
s'exécutant simultanément.
Autre aspect à prendre en compte : la vitesse du disque.
Des disques rapides englobant de grandes quantités de
cache peuvent améliorer considérablement le problème
des charges. Vous pouvez également modifier différents
paramètres de commande, notamment en activant la prise
en charge de Direct Memory Access pour votre lecteur. Sous
Linux, faites appel à l'utilitaire hdparm.
vmstat est un outil UNIX servant à dénicher les goulots
d'étranglement. Cet outil donne des informations sur les
procédures, la mémoire, le paging, les entrées-sorties de
blocs, les pièges et l'activité de l'unité centrale.
Elargissement des limites du système d'exploitation 171
Si vous utilisez SSL sur votre serveur et que vous deviez

prendre en charge plusieurs utilisateurs simultanés, l'opé-
ration peut consommer une grosse partie des ressources
de l'unité centrale. Un processeur plus rapide ou une carte
de cryptographie dédiée vous aideront dans ce cas.
Reportez-vous au Chapitre 7 et ("Amélioration des per-
formances SSL"), ainsi qu'au Chapitre 10, pour en savoir
plus sur les paramètres à appliquer. Enfin, une machine
équipée de plusieurs unités centrales (ou d'unités centrale
à cœurs multiples) améliore considérablement l'évoluti-
vité des serveurs Web basés sur les processus. Ce type de
machine est recommandé pour les hébergements de char-
ges moyennes à lourdes.
Elargissement des limites

du système d'exploitation
ulimit
Plusieurs facteurs du système d'exploitation peuvent empê-

cher l'adaptation d'Apache. Ces facteurs sont liés à la création
de processus, aux limitations de la mémoire et au nombre
simultané maximal de fichiers de connexion ouverts.
La commande ulimit d'UNIX permet de fixer plusieurs
des limites traitées dans les prochaines sections en fonction
du processus. Reportez-vous à la documentation de votre
système d'exploitation pour plus de détails sur la syntaxe
de ulimit.
Elargissement des limites

du système d'exploitation
sur les processus
Apache propose des paramètres pour éviter que le nombre
de processus et de threads n'excède certaines limites. Ces
paramètres affectent l'évolutivité, car ils limitent le nom-
bre de connexions simultanées au serveur Web, ce qui
réduit ensuite le nombre de visiteurs auxquels vous pou-
vez répondre simultanément. Ces paramètres varient
selon les MPM (modules multitraitement). Ils sont décrits
en détail au Chapitre 11.
Les paramètres MPM d'Apache sont ensuite contraints par
les paramètres du système d'exploitation, qui restreignent
le nombre de processus et de threads. Les étapes
nécessaires pour modifier les limites varient selon les sys-
tèmes d'exploitation. Sous les kernels Linux 2.4 et 2.6,
vous pouvez accéder à la limite est accessible ; elle peut
être paramétrée au moment de l'exécution, en modifiant
le fichier /proc/sys/kernel/threads-max. Vous trouverez
le contenu de ce fichier à l'adresse :
cat /proc/sys/kernel/threads-max
et pourrez écrire dessus en utilisant :
echo valeur > /proc/sys/kernel/threads-max
Sous Linux (à la différence de la plupart des autres versions

d'UNIX), il existe un mappage entre les threads et les pro-
cessus, analogue pour le système d'exploitation. Sous Sola-
ris, ces paramètres peuvent être modifiés dans le fichier
/etc/system. Ces modifications n'exigent pas de recons-
truire le kernel, mais peuvent demander un redémarrage
pour prendre effet. Vous pourrez modifier le nombre total
Augmentation des descripteurs de fichiers du système d'exploitation 173
de processus en modifiant l'entrée max_nprocs et le nom-

bre de processus autorisés pour un utilisateur donné, avec
maxuproc.
Augmentation des descripteurs de

fichiers du système d'exploitation
Dès qu'un processus ouvre un fichier (ou un socket), une
structure (appelée "descripteur de fichiers") est affectée
jusqu'à ce que le fichier soit fermé. Le système d'exploita-
tion limite le nombre de descripteurs de fichiers qu'un
processus donné peut ouvrir, ce qui restreint le nombre
de connexions simultanées sur le serveur. Le moyen à
employer pour modifier ces paramètres dépend du sys-
tème d'exploitation. Sous Linux, vous pouvez lire ou
modifier /proc/sys/fs/file-max (en utilisant echo et cat,
comme indiqué à la section précédente). Sous Solaris, vous
devez modifier la valeur de rlim_fd_max dans le fichier
/etc/system. Ces modifications nécessitent un redémar-
rage pour prendre effet.
Vous trouverez des informations complémentaires à
l'adresse : http://httpd.apache.org/docs/misc/des-
criptors.html.
Contrôle des processus externes

RlimitCPU
RLimitMem
RLimitNProc
Apache propose plusieurs directives pour contrôler la

quantité de ressources utilisées par les processus externes.
Cela concerne les scripts CGI engendrés par le serveur et

les programmes exécutés via SSI. La prise en charge des
directives suivantes est disponible uniquement sous
UNIX et varie selon les systèmes :
b RLimitCPU. Accepte deux paramètres, la limite souple
et la limite dure, concernant le temps d'unité centrale
(en secondes) auquel un processus a droit. Si le mot
clé max est utilisé, il signale le paramètre maximal
autorisé par le système d'exploitation. La limite dure
est optionnelle. La limite souple peut être modifiée
entre les redémarrages. La limite dure précise la valeur
maximale autorisée pour ce paramètre. Si cela vous
semble confus, consultez le Chapitre 11, qui donne
des informations sur ServerLimit et MaxClients.
b RLimitMem. La syntaxe est identique à RLimitCPU, mais
cette directive précise la quantité (en octets) de
mémoire utilisée pour chaque processus.
b RLimitNProc. La syntaxe est identique à RLimitCPU,
mais cette directive précise le nombre de processus.
Ces trois directives évitent que des programmes mal-

veillants ou mal écrits ne soient hors de contrôle.

du système de fichiers
L'accès au disque est une opération onéreuse en termes de
ressources ; c'est l'un des facteurs de ralentissement pour
n'importe quel serveur. Si vous réduisez le nombre de fois
où Apache (ou le système d'exploitation) doit lire à partir
du disque et écrire sur le disque, les performances peuvent
être considérablement améliorées. Les sections suivantes
traitent de certains des paramètres que vous pouvez per-

sonnaliser pour y parvenir. En outre, la plupart des systè-
mes d'exploitation modernes présentent des fonctions très
efficaces de mise en cache du système de fichiers, laissant
ainsi suffisamment de RAM à disposition ; ceci peut aussi
considérablement améliorer la vitesse d'accès aux fichiers
souvent appelés.
Montage de systèmes de fichiers,

grâce à l'option noatime
De nombreux systèmes de fichiers Linux peuvent être
montés, grâce à l'option noatime. Cela signifie que le sys-
tème d'exploitation n'enregistre pas le dernier accès à un
fichier lors de sa lecture, même s'il conserve la trace de sa
dernière écriture. L'opération peut considérablement
augmenter la vitesse, en particulier pour des serveurs lour-
dement chargés. La ligne suivante montre un exemple
d'entrée /etc/fstab :
/dev/hda3 /www ext2 defaults,noatime 1 1
Gestion de liens symboliques

Options FollowSymLinks
Sous UNIX, un lien symbolique (symlink) est un type de

fichier spécial qui pointe vers un autre fichier. Il est créé
avec la commande ln d'UNIX. Il permet de faire apparaî-
tre un fichier donné à différents endroits.
FollowSymLinks et SymLinksIfOwnerMatch sont deux des
paramètres autorisés par la directive Options. Par défaut,
Apache ne suit pas les liens symboliques. En effet, ceux-ci
peuvent servir à contourner les paramètres de sécurité et
offrent un accès indésirable à des parties de votre système

de fichiers. Par exemple, vous pouvez créer un lien sym-
bolique, à partir d'une partie publique du site Web, vers
un fichier (ou un répertoire) restreint qui ne serait pas
autrement accessible par le Web. Ainsi, Apache doit, par
défaut, procéder à une vérification pour s'assurer que le
fichier n'est pas un lien symbolique. Quand SymLinks-
IfOwnerMatch est présent, il suit un lien symbolique si le
fichier de destination appartient à l'utilisateur qui a créé ce
lien. Ces tests devant être réalisés pour chaque élément
du chemin ainsi que chaque chemin faisant référence à un
objet du système de fichiers, ils peuvent être onéreux. Si
vous contrôlez la création du contenu, ajoutez une direc-
tive Options +FollowSymLinks à votre configuration et
évitez l'argument SymLinksIfOwnerMatch. De cette manière,
les tests n'auront pas lieu, et les performances ne seront pas
affectées.
Désactiver les fichiers de configuration

par répertoire
<Directory />
AllowOverride none
</Directory>
Nous l'avons vu aux précédents chapitres, les fichiers de

configuration par répertoire offrent une manière com-
mode de configurer le serveur et laissent un certain degré
de liberté à l'administration déléguée. Toutefois, si cette
fonction est activée, Apache doit rechercher les fichiers
dans chaque répertoire, dans le chemin menant au docu-
ment desservi. Vous pouvez désactiver cette fonction en
ajoutant AllowOverride à votre configuration.
Configurer la négociation du contenu

Nous l'avons vu à la section "Configuration de la négocia-
tion du contenu", au Chapitre 4, Apache peut desservir
différentes versions d'un fichier en fonction de la langue
ou des préférences du client. Cela peut être accompli avec
les extensions de fichiers mais, pour chaque requête, Apa-
che doit accéder au système de fichiers à plusieurs reprises,
à la recherche de fichiers possédant les extensions appro-
priées. Si vous devez utiliser la négociation du contenu,
assurez-vous au moins d'utiliser un fichier de correspon-
dance de type, ce qui réduit les accès au disque.
Désactiver ou réduire la consignation

BufferedLogs On
Sur les sites Web lourdement chargés, la consignation

peut considérablement ralentir le serveur. Vous pouvez
réduire son impact en ne consignant pas les accès à tout
ou partie des images (comme les boutons de navigation).
De plus, vous pouvez mettre les journaux en tampon
avant qu'ils ne soient écrits sur disque, à l'aide de la direc-
tive BufferedLogs (comprise dans mod_log_config pour
Apache 2 et versions ultérieures). Enfin, vous pouvez
décider d'utiliser des modules comme mod_log_spread
qui permettent de consigner sur le réseau plutôt que sur
un disque local, ce qui améliore les performances. Vous
pouvez télécharger le module mod_log_spread à l'adresse
http://wwwbackhand.org/mod_log_spread.
Personnalisation du réseau
et des paramètres de statut
Plusieurs paramètres Apache liés au réseau peuvent dégra-
der les performances. Les sections suivantes traitent des
plus importants.
HostnameLookups
HostnameLookups off
Quand HostnameLookups est paramétré sur on ou double,

Apache réalise une recherche DNS pour capturer le nom
d'hôte du client, introduisant un délai dans la réponse au
client. Le paramètre par défaut vaut HostnameLookups off.
Si vous devez utiliser les noms d'hôtes, vous pouvez tou-
jours traiter les journaux de requête avec un système de
résolution de journaux par la suite (voir Chapitre 3).
D'autres paramètres peuvent déclencher une recherche
DNS, même si HostnameLookups est réglé sur off, par
exemple lorsqu'un nom d'hôte est utilisé dans des règles
Allow ou Deny (voir Chapitre 6).
Demander un mécanisme d'acceptation

Apache peut utiliser différents mécanismes pour contrôler
la manière dont les enfants Apache arbitrent les requêtes.
Le mécanisme optimal dépend de la plate-forme spécifi-
que et du nombre de processeurs. Vous trouverez d'autres
informations à l'adresse http://httpd.apache.org/docs/
2.0/misc/perf-tuning.html.
Personnalisation du réseau et des paramètres de statut 179
mod_status
Ce module collecte des statistiques sur le serveur, les
connexions et les requêtes. Même s'il peut être utile pour
dépanner Apache, il peut aussi ralentir le serveur. Pour obte-
nir des performances optimales, désactivez ce module, ou
vérifiez au moins que ExtendedStatus soit réglé sur off, le
paramètre par défaut.
AcceptFilter
AcceptFilter http data
AcceptFilter https data
Plusieurs systèmes d'exploitation, comme Linux et

FreeBSD, vous permettent de désigner certains sockets
d'écoute comme gérant des protocoles spécifiques. Il est
ainsi possible de demander au kernel de ne transférer une
requête à Apache qu'une fois que tout le contenu de la
requête HTTP a été reçu, ce qui améliore les performan-
ces. Cette capacité n'est implémentée que dans Apache 2.1
et versions ultérieures, même s'il existe une version précé-
dente de la directive AcceptFilter, spécifique à BSD et
présente dans Apache 1.3.22 et versions ultérieures.
KeepAlive
KeepAlive On
KeepAliveTimeout 5
MaxKeepAliveRequests 500
HTTP 1.1 permet de desservir plusieurs requêtes sur une

seule connexion. HTTP 1.0 offre la même chose avec des
extensions de maintien en activité (keep alive). La directive
KeepAliveTimeout permet de spécifier le délai maximal
(en secondes) pendant lequel le serveur attend avant de

terminer une connexion inactive. Augmenter la tempori-
sation signifie que vous augmenterez les chances que la
connexion soit réutilisée. D'autre part, la connexion et le
processus Apache sont liés pendant le temps d'attente, ce
qui peut gêner l'évolutivité, comme indiqué précédem-
ment. La directive MaxKeepAliveRequest permet de spéci-
fier le nombre maximal de fois où la connexion sera
réutilisée.
Eviter les abus

TimeOut
LimitRequestBody
LimitRequestFields
LimitRequestFieldSize
LimitRequestLine
LimitXMLRequestBody
Les attaques de refus de service submergent votre site

d'un grand nombre de requêtes simultanées, ce qui ralen-
tit le serveur et empêche d'accéder aux clients légitimes.
Ces attaques sont difficiles à éviter ; la manière la plus
efficace de les traiter consiste généralement à agir au
niveau du réseau ou du système d'exploitation. Vous
pouvez, par exemple, empêcher des adresses spécifiques
de générer des requêtes sur le serveur ; vous pouvez blo-
quer ces adresses au niveau du serveur Web, mais il vaut
mieux procéder au niveau du pare-feu ou du routeur du
réseau, ou encore avec les filtres réseau installés au niveau
du système d'exploitation.
Citons comme autres types d'abus l'envoi de requêtes
extrêmement volumineuses ou l'ouverture d'un grand nom-
bre de connexions simultanées. Vous pouvez également
Restriction des connexions et de la bande passante 181
limiter la taille des requêtes et des temporisations pour

réduire l'effet des attaques. La temporisation par défaut
des requêtes est de 300 secondes, mais vous pouvez la
modifier à l'aide de la directive TimeOut. A noter que plu-
sieurs directives permettent de contrôler la taille du corps
de la requête et des en-têtes : LimitRequestBody, LimitRe-
questFields, LimitRequestFieldSize, LimitRequestLine
et LimitXMLRequestBody.
Restriction des connexions

et de la bande passante
Si vous fournissez des services d'hébergement à plusieurs
clients, il est possible qu'un site Web dégrade les perfor-
mances du service dans son ensemble. Cela peut être dû
au fait que le site Web provient d'une page d'actualités à
fort trafic (effet dit "Slashdot") ou qu'il héberge un ensem-
ble très demandé de fichiers musique ou vidéo. Plusieurs
modules Apache permettent de mesurer et de contrôler la
bande passante et le nombre de connexions, de sorte à
s'assurer que l'impact sur d'autres clients et sur le serveur
dans son ensemble soit minimal. L'étranglement, dans ce
contexte, ralentit généralement la livraison du contenu
selon le fichier demandé, une adresse IP de client spécifi-
que, le nombre de requêtes simultanées, etc.
Le module mod_bandwidth d'Apache 1.3 autorise le para-
métrage des limites de bande passante sur tout le serveur ou
par connexions, en fonction du répertoire spécifique, de la
taille des fichiers, de l'adresse IP ou du domaine distant. Vous
trouverez ce module à l'adresse http://www.cohprog
.com/mod_bandwidth.html.
Le module bandwidth share s'occupe de l'étranglement de

la bande passante et de l'équilibrage, en fonction de l'adresse
IP du client. Il est compatible avec Apache 1.3 et versions
antérieures d'Apache 2. Vous trouverez ce module à
l'adresse : http://www.topology.org/src/bwshare/
README .html.
Le module mod_throttle réduit la bande passante pour
chaque hôte virtuel ou utilisateur, pour Apache 1.3. Vous
trouverez ce module à l'adresse : http://www.snert.com/
Software/mod_throttle/index.shtml.
Le module Robotcop permet d'éviter que des robots n'accè-
dent à des parties de sites possédant des limites. Vous trouve-
rez ce module à l'adresse : http://www.robotcop.org/.
mod_require_host permet de limiter l'accès à ces clients
(par exemple à de nombreux vers IIS) qui ne fournissent
pas d'en-tête d'hôte et tentent simplement de se connecter
à votre adresse IP. Vous trouverez ce module à l'adresse :
http://www.snert.com/Software/mod_require
_host/index.shtml.
mod_choke est un module destiné à Apache, qui restreint
l'utilisation en fonction du nombre de connexions simul-
tanées par adresses IP et limite le débit auquel Apache
envoie des données au client. Vous trouverez ce module
à l'adresse : http://os.cyberheatinc.com/modules
.php?name= Content&pa=showpage&pid =7.
mod_tsunami permet de limiter le nombre d'enfants
Apache pour chaque hôte virtuel. Vous trouverez ce
module à l'adresse : http://sourceforge.net/projects/
mod-tsunami/.
Gestion des robots 183
Gestion des robots

http://www.robotstxt.org/
Les "robots du Web" désignent une catégorie de pro-

grammes qui téléchargent des pages de votre site Web, en
suivant, de manière récursive, les liens qu'il contient. Des
moteurs de recherche sur le Web font appel à ces pro-
grammes pour parcourir Internet à la recherche de ser-
veurs Web ; ils téléchargent leur contenu et l'indexent.
Un utilisateur lambda les exploite pour télécharger tout
ou partie d'un site Web, afin de le consulter hors con-
nexion ultérieurement. Généralement, ces programmes se
comportent bien, mais ils peuvent parfois être très agres-
sifs et inonder votre site d'un nombre de connexions
simultanées trop important ou s'enfermer dans des boucles
cycliques.
Les robots traditionnels demandent un fichier particulier,
appelé robots.txt, qui contient des instructions sur la
manière d'accéder à votre site et sur les parties du site qui
ne seront pas disponibles.
La syntaxe du fichier se trouve à l'adresse http://www
.robotstxt.org. Vous pouvez faire cesser les requêtes au
niveau du routeur ou du système d'exploitation.
Parfois cependant, les robots Web ne respectent pas le
fichier robots.txt. Vous pouvez alors utiliser le module
Apache Robotcop (mentionné à la section précédente) qui
permet d'arrêter les robots au comportement indélicat.
Proxy inverses et systèmes

d'équilibrage des charges
mod_proxy_http
mod_backhand http://www.backhand.org/mod_backhand/
Nous avons parlé jusqu'à présent de l'évolutivité verticale,

qui montre comment améliorer les performances d'une
configuration de serveur unique. La distribution des char-
ges sur plusieurs serveurs Web correspond à l'évolutivité
horizontale. Dans cet ensemble d'architectures, vous pou-
vez prolonger les capacités en ajoutant simplement de
nouvelles machines et en améliorant la quantité de trafic
auquel vous pouvez répondre, ainsi que la fiabilité de
votre configuration.
Le Chapitre 10 est consacré à l'utilisation d'Apache sous
forme de proxy inverse. Dans cette configuration, un ou
plusieurs serveurs frontaux légers traitent le contenu sta-
tique et gèrent les requêtes SSL et les connexions lentes,
tout en relayant les requêtes vers des URL spécifiques à
des serveurs d'arrière-guichet spécialisés. Plusieurs socié-
tés proposent des produits commerciaux qui implémen-
tent cette fonctionnalité, en s'appuyant sur des structures
matérielles.
Enfin, le module mod_backhand (qui provient d'Apache 1.3)
assure une redirection dynamique des requêtes HTTP dans
une grappe de machines, en fonction des ressources dispo-
nibles.
Mise en cache et compression 185
Mise en cache et compression

Le moyen le plus rapide de desservir du contenu consiste…
à ne pas le desservir du tout ! Vous pouvez pour cela
employer les en-têtes HTTP appropriés, qui indiquent
aux clients et aux proxy la validité temporelle des ressour-
ces demandées. De cette manière, certaines ressources qui
figurent sur plusieurs pages mais ne sont pas souvent modi-
fiées, comme les logos ou les boutons de navigation, sont
transmises une fois seulement pendant une période donnée.
De plus, vous pouvez utiliser mod_cache (voir Chapitre 10)
pour mettre en cache un contenu dynamique, de sorte
qu'il ne soit pas nécessaire de le créer pour chaque requête.
Cela peut considérablement améliorer les performances,
car le contenu dynamique doit généralement accéder aux
bases de données, traiter des modèles, etc., ce qui peut
consommer des ressources considérables.
Autre moyen de réduire la charge sur le serveur : diminuer
la somme de données transférées au client. Cela accélère
ensuite l'accès au site Web de vos clients, en particulier
pour ceux disposant de liens lents. Pour vous aider à réaliser
cela, vous pouvez réduire le nombre et la taille de vos ima-
ges. Vous pouvez automatiser une partie du traitement en
employant les outils de ligne de commande ImageMagick
(http://www.imagemagick.org). De plus, vous pou-
vez compresser les fichiers téléchargeables volumineux
(voire les fichiers HTML statiques) et utiliser la négociation
du contenu, comme indiqué aux précédents chapitres. Le
Chapitre 11 explique comment utiliser le module de fil-
trage mod_deflate pour compresser le contenu HTML.
Cela peut être utile si les ressources d'unité centrale sont
disponibles et que des clients se connectent sur des liens
ralentis. Le contenu sera livré plus rapidement et le proces-
sus sera libéré plus tôt pour répondre aux autres requêtes.
Optimisations spécifiques
aux modules
Comme indiqué au début de ce chapitre, la plupart des
étranglements ont lieu aux niveaux de l'accès à la base de
données et de la génération du contenu. Plusieurs modu-
les peuvent vous aider.
Ainsi, par exemple, FastCGI et mod_perl peuvent servir à
accélérer l'exécution d'un script CGI (voir la section "Amé-
lioration des performances du script CGI", au Chapitre 4).
D'autre part, plusieurs systèmes de codage et d'optimisation
ont été créés pour PHP, le langage de développement Web
le plus populaire qui s'exécute sous Apache.
Alternatives à Apache
b lighttpd : http://www.lighttpd.net/
b thttpd : http://www.acme.com/software/thttpd/
b Boa : http://www.boa.org
Apache est un serveur Web portable, sûr et extrêmement
flexible. Pour cela précisément, ce n'est pas toujours la
meilleure solution dans toutes les situations. Les serveurs
indiqués ici sont optimisés et légers ; ils fonctionnent ou
évoluent souvent mieux qu'Apache concernant certaines
tâches. Ainsi, par exemple, des sites Web populaires
(comme Slashdot) emploient Apache exécutant mod_perl
pour générer du contenu et un serveur différent (comme
Boa) pour desservir des images statiques. Cela s'accomplit
facilement en envoyant les images à partir d'un domaine
différent, par exemple images.slashdot.org.
Certains des projets comprennent également d'autres
fonctions populaires d'Apache, comme la réécriture des
URL et la prise en charge du PHP.
10
Proxy Apache et
mise en cache
De l'utilité de la mise en cache

et des proxy
HTTP est un protocole aussi simple que puissant. Ce cha-
pitre explique comment profiter de la mise en cache et des
fonctions de proxy qui permettent d'implémenter des
architectures flexibles et évolutives. La mise en cache per-
met de réduire simultanément la charge des serveurs et
d'allouer un accès plus rapide à votre site par un retour plus
rapide aux contenus fréquemment demandés. L'installation
d'un proxy permet de créer un point de contrôle pour
toute requête HTTP, qui peut être utilisé pour unifier les
contenus provenant de divers serveurs d'arrière-guichet,
de manière à améliorer les performances.
188 CHAPITRE 10 Proxy Apache et mise en cache
Proxy ordinaires et inverses

Il existe différents types de proxy Web. Un proxy HTTP
traditionnel, aussi appelé proxy ordinaire, accepte des
requêtes de clients (généralement des navigateurs Web),
contacte le serveur distant et renvoie la réponse.
Un proxy inverse est un serveur Web placé devant les
autres serveurs, qui propose une façade unifiée et agit ainsi
comme une passerelle. Pour les navigateurs Web, le proxy
inverse est le "vrai" serveur, car il est le seul à interagir
avec lui. Il relaye les requêtes lorsque c'est nécessaire
jusqu'aux serveurs d'arrière-guichet.
Différences entre Apache 1.3, 2.0

et 2.2
Dans Apache 1.3, la prise en charge de la mise en cache
faisait partie de mod_proxy et ne pouvait pas être utilisée
séparément. Dans la version 2.0, la fonction a été divisée
en deux modules distincts, même si le code en résultant
est considéré comme expérimental. La situation a changé
avec les versions 2.1 et 2.2, où la fonctionnalité est désor-
mais considérée mature.
Activation de la prise en charge de mod_proxy 189
Activation de la prise en charge

de mod_proxy
Apache 1.3
--enable-module=proxy
--enable-proxy
--enable-proxy-connect
--enable-proxy-ftp
--enable-proxy-http
--enable-proxy-balancer (Apache versions 2.1 et ultérieures)
--enable-proxy-ajp (Apache versions 2.1 et ultérieures)
Pour activer la prise en charge des proxy dans Apache, vous
devez activer le module proxy principal et tout ou partie
des trois arrière-guichets pris en charge : HTTP, CONNECT et
FTP. L'option CONNECT permet aux connexions SSL de tran-
siter sans perte d'intégrité via le proxy. L'arrière-guichet
FTP permet au serveur proxy d'agir en tant que passerelle
pour accéder aux serveurs FTP distants via un navigateur
HTTP normal. Les versions 2.1 et supérieures d'Apache
incluent deux modules proxy additionnels : balancer, qui
fournit la prise en charge de l'équilibrage des charges, et
ajp, qui assure la prise en charge du protocole AJP, fré-
quemment utilisé pour communiquer avec Tomcat et
d'autres moteurs de servlet.
Activation de la prise en charge

des proxy ordinaires
ProxyRequests on
<Proxy *>
Order deny,allow
Deny from all
Allow from 10.0.0.0/255.255.255.0
</Proxy>
Les proxy ordinaires ont connu une grande popularité

aux premiers jours d'Internet, puisqu'ils permettaient à
plusieurs machines de partager facilement une con-
nexion vers le monde extérieur. La plupart des serveurs
proxy incluaient des fonctions de mise en cache, utiles
lors du partage de connexions lentes, et offraient une
isolation par rapport au monde extérieur. Les connexions
rapides et les NAT (Network Address Translation) intégrés
dans la plupart des dispositifs de passerelle ont considéra-
blement réduit les besoins de proxy ordinaires. De nos
jours, ils sont plus souvent implémentés dans des entre-
prises qui doivent contrôler la navigation de leurs
employés, utilisant le proxy pour consigner, filtrer et
autoriser les accès aux sites web. Cela commence à chan-
ger. A mesure que se multiplient les virus et les logiciels
espion, les entreprises mettent en place des proxy de fil-
trage qui éliminent ces menaces avant qu'elles ne par-
viennent sur le bureau des utilisateurs. Les proxy ont
trouvé une nouvelle jeunesse dans le monde des réseaux
sans-fil, où ils servent de passerelles.
Vous pouvez activer les fonctionnalités des proxy ordi-
naires en utilisant ProxyRequests On, comme indiqué dans
l'exemple. Il est conseillé de retreindre la prise en charge
du proxy uniquement aux clients autorisés (voir Chapi-
tre 6). Vous pouvez y parvenir en utilisant la directive de
section <proxy>. L'exemple montre comment restreindre
l'accès du proxy à un espace réseau spécifique.
Utilisation d'un proxy inverse pour unifier un espace URL 191
Utilisation d'un proxy inverse

pour unifier un espace URL
ProxyPass /crm http://crm.exemple.com/
ProxyPass /bugzilla
http://backend.exemple.com/bugzilla
Un proxy inverse peut offrir un frontal unifié pour plusieurs

ressources d'arrière-guichet, en associant certaines URL
sur la machine frontale à des serveurs Web d'arrière-gui-
chet spécifiques. Vous pouvez, par exemple, disposer d'un
serveur sur lequel tourne une application CRM et d'un
autre sur lequel tourne un outil de recherche de bogues.
Chaque fois que les utilisateurs doivent utiliser une appli-
cation, il leur faut taper une adresse différente. Vous pou-
vez intégrer ces services dans votre site principal, en
utilisant ProxyPass, comme indiqué dans l'exemple.
Désormais, lorsque la machine de proxy inverse recevra
une requête pour http://www.exemple.com/crm/login/
index.html, elle demandera http://crm.exemple.com/login/
index.html au serveur d'arrière-guichet et renverra le
document au navigateur.
La directive ProxyPass peut être utilisée seule ou à l'inté-
rieur d'une section <Location>, ainsi que le montre l'exem-
ple suivant :
<Location /crm>
ProxyPass http://crm.exemple.com/
</Location>
Au final, vous pourrez utiliser ProxyPass simultanément

avec ProxyPassReverse, décrit à la section suivante.
Masquage des serveurs

d'arrière-guichet
ProxyPass /crm http://crm.exemple.com
ProxyPassReverse /crm http://crm.exemple.com
ProxyErrorOverride On
Au cours du processus décrit à la section précédente, le

client n'a contacté que le serveur de proxy inverse ; il ne
soupçonne pas l'existence des serveurs d'arrière-guichet.
Parfois cependant, le serveur d'arrière-guichet émet des
pages de redirection ou d'erreur qui contiennent des réfé-
rences à lui-même, par exemple dans l'en-tête Location:.
La directive ProxyPassReverse intercepte ces en-têtes et
les réécrit de manière qu'ils contiennent une référence au
proxy inverse (www.exemple.com). Les directives Proxy-
PassReverseCookiePath et ProxyPassReverseCookieDomain
opèrent de façon analogue, mais sur le chemin et les chaî-
nes de domaine situés sur les en-têtes Set-Cookie:.
De plus, ProxyErrorOverride (uniquement disponible
dans Apache 2) permet d'afficher la page d'erreur du ser-
veur proxy, remplaçant ainsi les pages d'erreur reçues de
l'arrière-guichet. Cela permet de mieux masquer l'exis-
tence de ce serveur et d'obtenir un frontal constant, même
en cas de messages d'erreur.
Info
Sachez que la directive ProxyPassReverse opère seulement au
niveau de l'en-tête HTTP. Elle ne vérifie pas, ni ne réécrit les
liens qui sont contenus à l'intérieur des documents HTML. Afin
de réaliser cela, vous pouvez utiliser mod_proxy_html, un module
Apache 2 qui permet de parcourir les documents desservis via le
proxy et de réécrire le code HTML à la volée. Vous pouvez télé-
charger ce module à l'adresse http://apache.webthing.com/
mod_proxy_html/.
Eviter l'inversion des URL en proxy 193
Eviter l'inversion des URL en proxy

ProxyPass /images/ !
ProxyPass / http://crm.exemple.com
Certaines URL peuvent ne pas être mises en proxy si
vous placez un point d'exclamation (!) sur l'URL du site
distant dans les directives ProxyPass. Il est important que
ces directives soient placées en aval des autres directives
ProxyPass.
Par exemple, la configuration montrée ici enverra toutes
les requêtes à un site d'arrière-guichet, à l'exception des
requêtes d'images, qui seront desservies localement.

ProxyIOBufferSize 1024000
Les proxy inverses peuvent également être très utiles si
vous disposez de serveurs Web et de serveurs d'application
complexes et surchargés. Les clients lents des lignes par
modem, les navigateurs présentant des bogues et les gros
fichiers multimédias peuvent mobiliser des ressources pré-
cieuses des serveurs créateurs de contenu. Si un client
requiert un gros fichier statique et le télécharge lentement,
un thread (ou un processus) enfant d'Apache sera occupé à
le desservir jusqu'au terme du téléchargement. Un scénario
analogue survient lorsqu'une implémentation TCP/IP
boguée ne parvient pas à fermer correctement une con-
nexion au serveur à la fin d'une transmission. On appelle
ce phénomène un "problème de fermeture persistante".
Cela entraîne une mobilisation excessive des ressources

jusqu'à ce que la connexion soit fermée pour cause de
dépassement du délai. Cependant, même si ces situations
sont rarement évitables, le vrai problème survient lorsque
vous utilisez des MPM basés sur les processus (tel le MPM
Prefork). Ainsi, si vous employez mod_perl dans Apache 1.3
avec de nombreux autres modules Perl chargés et quel-
ques données mises en cache, les enfants Apache qui en
résultent auront probablement une taille de quelques
mégaoctets. Si l'un d'eux "perd du temps" à vouloir des-
servir un fichier statique ou attendre la fermeture d'une
connexion, moins de ressources seront disponibles pour
servir les requêtes restantes. Un proxy inverse peut aider
dans ce cas. Vous pouvez avoir un ou plusieurs frontaux
Apache légers, avec des threads, qui desservent des contenus
statiques et s'occupent des clients lents et bogués, ainsi que
des serveurs toutes fonctionnalités en arrière-guichet qui
s'occupent de générer le contenu dynamique. Vous pou-
vez personnaliser ProxyIOBufferSize de manière que les
gros fichiers soient transférés rapidement au proxy inverse
et que la connexion au serveur d'arrière-guichet soit libé-
rée aussi tôt que possible. Cela réduit la charge imposée au
serveur d'arrière-guichet mais accroît la consommation
de mémoire de la machine du proxy. Dans Apache 2.1,
de récents MPM permettent à un même enfant Apache de
gérer plusieurs connexions, avec possibilité d'avoir un
thread dédié dont la tâche consiste à attendre la fermeture
des connexions. Ces MPM, à mesure qu'ils mûrissent,
permettent à Apache de mieux évoluer dans bon nombre
de situations.
Déchargement du processus SSL 195
Déchargement du processus SSL

Nous l'avons vu au Chapitre 7, "SSL et TLS", les calculs
requis font de SSL un protocole gourmand en ressources.
Cela peut avoir un impact sur les performances de votre
serveur d'arrière-guichet d'une manière similaire à celle
décrite dans la section précédente. Un moyen de résoudre
ce problème consiste à disposer de boîtes dédiées et opti-
misées faisant fonctionner un proxy inverse avec une prise
en charge SSL. Le proxy inverse réalise l'ensemble des
opérations lourdes : il traite les requêtes SSL, peut éven-
tuellement faire les authentifications basées sur des certifi-
cats et transmet les requêtes en HTTP brut aux serveurs
d'arrière-guichet. Le contenu est généré et renvoyé au
proxy inverse, qui réalise la tâche (gourmande en ressour-
ces) consistant à le crypter. Puisque le point final du SSL
est le proxy inverse, certaines informations (telles que celles
liées au certificat) sont perdues et n'atteignent pas le serveur
d'arrière-guichet. La manière de réaliser cela est décrite
aux deux sections suivantes.
Transfert des informations

de proxy dans les en-têtes
ProxyPreserveHost on
Quand Apache agit en tant que proxy inverse, l'en-tête

Host: est modifié dans la requête de proxy pour corres-
pondre au nom d'hôte spécifié dans la directive Proxy-
Pass. L'en-tête Host: original est placé dans un autre
en-tête, XForwarded-Host. Dans certaines situations, il est
préférable de préserver la valeur originale de l'en-tête.
Cela peut être fait en activant ProxyPreserveHost on dans

le fichier de configuration.
Certaines informations de la requête sont perdues lorsqu'un
proxy inverse est installé. Celui-ci enregistre quelques-unes
de ces informations dans de nouveaux en-têtes qui sont
ajoutés à la requête faite au serveur d'arrière-guichet :
b X-Forwarded-For. Adresse IP ou nom d'hôte du client.
b X-Forwarded-Host. Hôte original demandé.
b X-Forwarded-Server. Nom d'hôte pour le serveur
proxy.
Vous pouvez envoyer des informations supplémentaires

en utilisant les directives Header et RequestHeader, comme
indiqué à la section suivante.
Manipulation des en-têtes

Header set nom-en-tete valeur-en-tete
Vous pouvez envoyer des informations supplémentaires à

un serveur d'arrière-guichet en utilisant la directive Hea-
der, fournie par le module mod_headers. Ce module peut
être utilisé pour ajouter ou supprimer des en-têtes arbi-
traires dans les requêtes et réponses HTTP.
Vous pouvez ajouter un en-tête HTTP de réponse, en
supprimant tout autre en-tête HTTP ayant le même nom et
pouvant être présent, en utilisant Header set, comme mon-
tré dans l'exemple. Si vous voulez ajouter un nouvel en-tête
plutôt qu'en remplacer un existant, employez Header add.
Pour ajouter la valeur à un en-tête existant, effacer certains
en-têtes ou ajouter un en-tête de requête à la réponse,
adoptez respectivement append, unset et echo.
Implémentation d'un proxy de cache 197
Vous pouvez modifier les en-têtes des requêtes envoyées

au client en utilisant RequestHeader au lieu de Header.
Vous pouvez ajouter le contenu de variables d'environne-
ment dans l'argument headervalue, à l'aide de la chaîne de
format %{nomvariable}e. Ce fonctionnement est sembla-
ble à celui de la directive LogFormat (voir Chapitre 3,
"Journaux et surveillance"). Par exemple, vous pouvez
l'utiliser pour transmettre des informations sur une con-
nexion SSL et des certificats au serveur d'arrière-guichet.
Pour cela, vous devrez tout d'abord indiquer à mod_ssl de
stocker ces informations dans des variables d'environne-
ment, avec SSLOptions +StdEnvVars. Dans Apache 2.1,
vous pouvez passer cette étape et accéder directement aux
variables d'environnement SSL, avec %{nom-variable}s.
Implémentation d'un proxy

de cache
CacheRoot /usr/local/apache/cache
CacheSize 500000
CacheGcInterval 6
CacheMaxExpire 12
L'un des avantages d'un proxy réside dans le fait qu'il est
capable de mettre en cache les informations qu'il dessert.
La prochaine fois que ce contenu sera demandé, le proxy
pourra vérifier qu'il est déjà présent dans son cache, et le
desservira alors directement. Dans Apache 1.3, la fonc-
tionnalité de mise en cache est implémentée dans le cadre
du module mod_proxy. Ces directives représentent un
exemple de configuration. CacheRoot permet de spécifier
la localisation des fichiers mis en cache et CacheSize la
taille totale du cache (en kilo-octets). Il existe plusieurs
autres directives de configuration que vous pouvez utiliser
pour modifier le comportement de la mise en cache.
CacheGcInterval permet de spécifier la fréquence (en heu-

res) à laquelle le cache sera périodiquement "purgé", afin
d'être en adéquation avec le réglage CacheSize. Cache-
MaxExpire spécifie le temps maximal pendant lequel un
document peut rester dans le cache et être toujours consi-
déré comme étant valable, sans avoir à être comparé à la
source originale.
Mise en cache dans Apache 2

CacheEnable disk /
CacheRoot /usr/local/apache/cache
La fonctionnalité de mise en cache et de mise en proxy

dans Apache a été séparée en deux modules distincts
depuis Apache 2. Considérée comme étant expérimentale
dans Apache 2.0, la mise en cache est reconnue en tant
que fonctionnalité de qualité dans Apache 2.1/2.2.
Dans Apache 2, la principale fonctionnalité de mise en
cache est implémentée par mod_cache. Ce module possède
à son tour deux arrière-guichets : mod_mem_cache, qui stocke
les ressources mises en cache directement en mémoire et
mod_disk_cache, qui utilise le système de fichiers. La
directive CacheEnable prend un paramètre d'arrière-gui-
chet de mise en cache (mem ou disk), ainsi qu'un préfixe
d'URL. Les requêtes qui contiennent le préfixe URL
seront mises en cache par l'arrière-guichet spécifique.
Vous pouvez utiliser CacheDisable pour désactiver la
mise en cache d'URL spécifiques. Il est également possi-
ble de recourir à l'utilitaire de ligne de commande htca-
checlean, afin de réduire le cache à intervalles prédéfinis
lors de l'utilisation de l'arrière-guichet disk.
Equilibrage des charges 199
De même, si certains de vos fichiers sont fréquemment

demandés et si vous savez qu'ils ne changeront pas pen-
dant la durée de vie du serveur, vous pouvez utiliser
mod_file_cache pour dire à Apache de mettre en corres-
pondance les fichiers spécifiques en mémoire ou de met-
tre en cache les gestions de fichiers :
CacheFile /usr/local/apache/htdocs/navigationbar.gif
MMapFile /usr/local/apache/htdocs/button_left.png
Si vous modifiez l'un des fichiers statiques, vous devrez

redémarrer le serveur pour que les changements prennent
effet.
Equilibrage des charges

<Location /balancer-manager>
SetHandler balancer-manager
Order deny,allow
Deny from all
Allow from localhost
</Location>
<Proxy balancer://balancer/ stickysession=PHPSESSIONID>
BalancerMember http://www1.exemple.com/
</Proxy>
ProxyPass /content balancer://balancer/
Disponible depuis Apache 2.2, mod_proxy inclut un nou-

vel arrière-guichet qui offre des capacités d'équilibrage
des charges. Le code d'équilibrage des charges est géné-
rique et permet d'équilibrer de multiples autres protoco-
les en plus du HTTP. Pour le configurer, vous devez
d'abord définir un groupe de serveurs d'arrière-guichet avec
une section <proxy balancer://...>, comme indiqué ici.
Une fois défini, vous pouvez utiliser l'ID du système

d'équilibrage avec une directive ProxyPass régulière. Cha-
que identifiant et élément du système d'équilibrage peut
prendre des options pour spécifier des stratégies d'équili-
brage (en fonction du trafic), des pannes, du pooling des
connexions (leur mise en commun) et de la prise en charge
des sessions.
Enfin, vous pouvez vérifier le niveau de votre configura-
tion, à l'aide de la commande régulière status, et la mani-
puler, à l'aide de la commande balancer-manager.
Connexion à Tomcat
ProxyPass /myapp ajp://127.0.0.1:8009/myapp
ProxyPassReverse /myapp ajp://127.0.0.1:8009/myapp
Depuis Apache 2, mod_proxy inclut un protocole d'arrière-

guichet AJP. Ce protocole est généralement utilisé par un
autre module Apache, mod_jk, pour communiquer avec
des serveurs d'applications et des moteurs de servlet, tels
que Tomcat et Jetty. Il est désormais possible de rempla-
cer mod_jk par les modules mod_proxy et mod_proxy_ajp.
Vous bénéficiez ainsi de quelques-unes de leurs nouvelles
fonctionnalités dans mod_proxy, par exemple l'équilibrage
des charges. Comme indiqué dans l'exemple, la configu-
ration du support AJP dans mod_proxy est aussi facile que
de remplacer http:// par ajp:// dans les configurations
de proxy (y compris dans les configurations d'équilibrage
des charges).
Autres proxy 201
Autres proxy
Squid http://www.squid-cache.org/
Pound http://www.apsis.ch/pound/
Nous l'expliquions au Chapitre 9, "Performances et évo-
lutivité", Apache n'est pas forcément le meilleur choix
dans tous les scénarios. Il existe ainsi plusieurs autres ser-
veurs proxy spécialisés qui pourraient fonctionner de façon
plus satisfaisante, selon vos besoins. Deux des serveurs
proxy Open Source les plus populaires se nomment
Pound et Squid :
b Squid est sorti à peu près au même moment qu'Apa-
che. Il est fortement configurable et excelle dans la
mise en cache.
b Pound est un serveur proxy léger, souvent utilisé
comme proxy inverse SSL.
Proxy HTTP transparents

Nous l'avons vu, un proxy ordinaire de mise en cache
requiert que chaque client soit correctement configuré. Il
est aussi possible d'implémenter des proxy dits "transpa-
rents". Ces machines interceptent les requêtes HTTP au
niveau de la couche réseau. Ensuite, de manière "transpa-
rente", elles les desservent au travers d'un serveur proxy
sans que l'utilisateur final ne s'en aperçoive. Les proxy
transparents sont toujours populaires auprès des FAI qui
veulent réduire les coûts de bande passante ou contrôler les
habitudes de navigation de leurs clients. Certaines organi-
sations utilisent aussi des proxy transparents pour filtrer les
logiciels espion et les virus (voir, plus haut, la section
"Activation de la prise en charge des proxy ordinaires").
Une configuration type d'un proxy transparent fait appel à

un serveur averti de la mise en proxy transparente, tel que
Squid, et modifie les règles de transfert des paquets du sys-
tème d'exploitation. Pour plus d'informations sur la confi-
guration de proxy HTTP transparents, suivez ce lien de la
documentation de projet Linux :
http://www.tldp.org/HOWTO/Transparentproxy.html.
11
Multitraitement
et modules de
protocole
Evolution de l'architecture Apache

Apache n'est pas un serveur monolithique. De nouveaux
modules peuvent y être ajoutés, afin de fournir des fonc-
tionnalités avancées. De même, des modules existants peu-
vent en être retirés, de sorte à réduire la taille du serveur,
et ainsi améliorer les performances. Apache 2 prolonge ce
concept de modularité et introduit trois nouvelles voies
d'extension du serveur :
b Modules multitraitement (MPM). Permettent de
modifier la manière dont les serveurs Apache desser-
vent les requêtes. Améliorent les performances et
l'évolutivité du serveur.
b Modules de Filtrage. Permettent aux modules de
traiter le contenu fourni par d'autres modules.
b Modules de Protocole. La couche de protocole a été
analysée. Il est donc possible pour Apache de desservir
un contenu utilisant d'autres protocoles, tels que FTP.
204 CHAPITRE 11 Multitraitement et modules de protocole
Sélection d'un module

multitraitement
--with-mpm=worker
--with-mpm=prefork
Même si la sélection du MPM dépend de plusieurs fac-

teurs (dont la prise en charge de modules et de fonction-
nalités tiers spécifiques), certains MPM se comportent
mieux sur certaines plates-formes. Ainsi, les processus sur
AIX étant "lourds", un MPM avec des threads sera préfé-
rable pour l'évolutivité qu'il apporte. Sachez toutefois
qu'il n'est pas possible de modifier le mécanisme de traite-
ment des requêtes dans Apache 1.3. Avec Apache 2, vous
sélectionnez un MPM pendant la configuration et vous
montez le processus avec l'option --with-mpm. Actuelle-
ment, Windows possède ses propres MPM basés sur des
threads. Pour sa part, UNIX possède deux MPM stables :
prefork et worker. Plusieurs autres modules sont distribués
avec le serveur et utilisés à titre expérimental. Les sections
suivantes décrivent les fonctions des différents MPM et
indiquent la manière de les configurer.
Découverte des MPM

basés sur les processus
Avec une configuration de serveur basé sur les processus,
le serveur procède à une "bifurcation" (un fork) sur plu-
sieurs enfants. Cela signifie qu'un processus parent réalise
des copies identiques de lui-même, appelées des enfants.
Chacun des enfants peut desservir une requête indépen-
damment des autres. Cette approche présente l'avantage
Configuration de MPM Prefork 205
d'améliorer la stabilité : si l'un des enfants se comporte

mal, par exemple en perdant de la mémoire, il peut être
arrêté sans que cela n'affecte le reste du serveur.
L'amélioration de la stabilité s'accompagne d'une pénalité
au niveau des performances : chacun des enfants mobilise
de la mémoire supplémentaire, et le système d'exploita-
tion perd un certain temps à changer de contexte. De
plus, cette approche complique la communication entre
les processus et le partage de fichiers.
Apache 1.3 est un serveur basé sur les processus. Apa-
che 2, quant à lui, propose un MPM prefork qui lui permet
de fonctionner comme un serveur basé sur les processus.
Prefork signifie qu'un enfant peut être créé au démarrage,
plutôt que lorsqu'une requête arrive. A noter qu'Apache
permet de configurer le nombre d'enfants à établir au
démarrage, ainsi que le nombre maximal d'enfants possi-
bles (voir section suivante).
Configuration de MPM Prefork

StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
Vous pouvez contrôler le nombre de processus créés au

démarrage, à l'aide de la directive StartServers. Celle-ci
prend un argument unique, indiquant le nombre de ser-
veurs à faire bifurquer lorsque le serveur démarre. La
valeur par défaut est 5 ; elle convient pour la plupart des
sites web. Ne modifiez ce réglage que si vous gérez un site
Web très fréquenté.
MaxClients permet de contrôler le nombre maximal de

processus engendrés, dans la limite des capacités du sys-
tème d'exploitation ou en fonction du nombre maximal
d'enfants possibles. Dans Apache 1.3, le nombre maxi-
mal d'enfants possible est codé en dur à 256. Pour modi-
fier cette valeur, vous devez intervenir sur le réglage
HARD_SERVER_LIMIT dans httpd.h, puis recompiler le ser-
veur. Dans Apache 2, cette valeur peut être modifiée dans
la configuration, en utilisant la directive ServerLimit.
La directive MinSpareServers définit le nombre maximal
de processus pouvant rester inactifs (les requêtes ne sont
pas traitées) à un moment donné. Si le nombre de ser-
veurs inactifs descend sous cette valeur, Apache engendre
de nouveaux enfants. A l'inverse, MaxSpareServers fixe
le nombre maximal de processus inactifs autorisés.Si le
nombre de serveurs inactifs dépasse ce réglage, certains
d'entre eux sont arrêtés. La valeur par défaut, présentée
dans l'exemple, devrait être suffisante pour la plupart des
serveurs.
Au final, vous pouvez limiter le nombre de requêtes
traitées par un processus spécifique, en utilisant la direc-
tive MaxRequestsPerChild. Sachez qu'elle ne dénombre pas
les requêtes multiples qui réutilisent la même connexion.
Comme expliqué précédemment dans ce chapitre, cela
permet d'éviter les fuites de mémoire pour des processus
qui fonctionnent depuis un long moment. Le serveur
arrête le processus et le remplace par un nouveau, après
le nombre spécifié de requêtes. Vous pouvez fixer la valeur
de MaxRequestsPerChild sur 0 pour empêcher que les pro-
cessus ne soient arrêtés après un nombre défini de requêtes.
MPM basés sur des threads et MPM hybrides 207
MPM basés sur des threads

et MPM hybrides
Les threads sont semblables aux processus, mais ils peu-
vent partager de la mémoire et des données avec d'autres
threads. Cela présente l'avantage de ne pas nécessiter de
changement de contexte (les threads font partie du même
processus). Toutefois, l'inconvénient est qu'un code mal
écrit peut faire tomber le serveur. En effet, un thread se
comportant mal est capable d'écraser et de corrompre des
données ainsi que du code appartenant à d'autres threads.
Le MPM Apache, destiné à la plate-forme Windows, est
un exemple de MPM de serveur basé sur les threads. Les
serveurs basés sur des processus ou des threads présentent
chacun des avantages et des inconvénients. Les déve-
loppeurs d'Apache ont créé un MPM basé sur des threads,
MPM Worker, qui autorise une approche mixte. Un ser-
veur peut engendrer différents processus, chacun conte-
nant plusieurs threads.
Configuration de MPM Worker

StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
Le MPM Worker est un MPM Apache 2 qui permet de

combiner les processus et les threads. Vous pouvez spéci-
fier le nombre de processus qui seront créés au démarrage,
en utilisant la directive StartServers, comme avec le MPM
Prefork. Chacun des processus possédera plusieurs threads ;
ce nombre sera spécifié par la directive ThreadsPerChild.
Le nombre de threads dans chaque processus est fixé, mais

les processus sont créés ou détruits, afin de maintenir le
nombre total de threads dans les limites spécifiées. Ces
limites peuvent être configurées en utilisant les directives
MinSpareThreads et MaxSpareThreads. Ce sont les contre-
parties des directives MaxSpareServers et MinSpareServers
dans les serveurs basés sur les processus.
Apache surveille le nombre total de threads sur tous les
processus et crée ou détruit les processus en conséquence.
A l'instar du Prefork, MaxClients spécifie le nombre maxi-
mal de processus. Dans le MPM Worker, chaque proces-
sus possède plusieurs threads. Le nombre maximal de
clients simultanés est donc MaxClients fois le réglage de
ThreadsPerChild. MaxThreadsPerChild spécifie le nombre
maximal de threads par processus ; il peut être modifié
entre chaque redémarrage. ThreadLimit spécifie une
limite supérieure qui ne peut être modifiée entre les redé-
marrages. Les directives StartServers et MaxClients sont
identiques à celles décrites à la section "Configuration de
MPM Prefork".
Autres MPM
--with-mpm=event
--with-mpm=perchild
Apache 2 comprend plusieurs MPM supplémentaires,

désignés comme étant expérimentaux. Deux des plus
intéressants sont le MPM Event et le MPM Perchild. Le
MPM Event, présent uniquement dans Apache 2.1, est
une variante du MPM Worker. Dans ce MPM, un thread
séparé gère tous les sockets d'écoute et les connexions
de maintien en activité. Cela accroît considérablement
l'évolutivité, les threads restants pouvant traiter des requêtes
au lieu d'attendre que le client ferme une connexion ou
Description des filtres Apache 2 209
émette une nouvelle requête. Ce MPM résout certains

problèmes décrits au Chapitre 10, "Proxy Apache et mise
en cache". Le MPM Perchild permet à Apache de faire
tourner différents hôtes virtuels sous divers ID utilisateurs.
Cela peut aider à améliorer la sécurité et fournit une alter-
native à l'exécution d'instances de serveurs séparées.
Enfin, le MPM Metux fournit une alternative au MPM
Perchild. Il peut être téléchargé à l'adresse http://www
.metux.de/mpm.
Description des filtres Apache 2

<Directory /usr/local/apache/htdocs/>
SetOutputFilter INCLUDES;PHP
</Directory>
AddOutputFilter INCLUDES .inc .shtml
Vous pouvez vous représenter l'architecture de filtrage

dans Apache comme une ligne d'assemblage d'usine. Les
filtres correspondent à des employés ; les requêtes et les
réponses sont les objets transportés sur la ligne. Chaque
filtre traite le contenu et transmet le résultat au filtre suivant.
Les filtres peuvent traiter de l'information de diverses
manières. Nombre de modules Apache sont implémentés
sous forme de filtres, tels que SSL, SSI et sous forme de
compression. Les filtres peuvent être automatiquement
ajoutés par les modules au moment de l'exécution ou
réglés dans le fichier de configuration.
L'exemple montre comment utiliser SetOutputFilter pour
ajouter deux filtres à tous les documents d'un répertoire
particulier et AddOutputFilter pour associer des filtres à
des extensions de fichier particulières. De plus, AddOut-
putFilterByType peut être utilisé pour associer des filtres à
des types de fichiers spécifiques.
Si plusieurs directives, comme AddOutputFilter et SetOut-

putFilter, s'appliquent au même fichier, les listes de filtres
des deux directives sont fusionnées. Les filtres d'entrée
peuvent être configurés par le biais des directives AddInput-
Filter, AddInputFilterBytype et SetInputFilter, qui
présentent une syntaxe identique aux filtres de sortie
équivalents.
Apache 2.1 et 2.2 proposent le module mod_filter qui
offre une plus grande flexibilité pour définir et manipuler
les chaînes de filtres. Cela peut être réalisé, par exemple,
en fonction de l'existence d'un en-tête HTTP particulier
ou d'une variable d'environnement.
Utilisation d'Apache
comme serveur FTP
Listen 10.0.0.1:21
<VirtualHost 10.0.0.1:21>
FTP On
DocumentRoot /usr/local/apache/ftpdocs
ErrorLog /usr/local/apache/logs/ftp_error_log
<Location />
AuthName "FTP"
AuthType basic
AuthUserFile /usr/local/apache/conf/htusers
Require valid-user
</Location>
</VirtualHost>
Comme indiqué précédemment dans ce chapitre, Apa-

che 2 est bien plus qu'un simple serveur Web, c'est une
structure de serveur générique. En montant un serveur
par-dessus Apache, un développeur bénéficie d'une infra-
structure solide et portable, d'un mécanisme d'extension
et de la possibilité d'utiliser de nombreux modules tiers
Utilisation d'Apache comme serveur POP3 211
créés pour Apache. C'est le cas de mod_ftp, qui ajoute des

capacités FTP à Apache. La plupart des paramètres de
configuration (notamment les directives d'authentification)
sont partagés avec le reste du serveur. Vous pouvez acti-
ver la prise en charge FTP en ajoutant simplement FTP On
dans la section Virtual Host appropriée. D'autres directives,
comme FTPUmask, FTPTimeoutLogin, FTPBannerMessage et
FTPMaxLoginAttempts, permettent de configurer des fonc-
tions communes avec d'autres serveurs FTP.
A l'heure où nous écrivons ces lignes, mod_ftp est en passe
de devenir un projet ASF officiel. Il peut dorénavant être
téléchargé à l'adresse http://incubator.apache.org/
projects/mod_ftp.html.
Utilisation d'Apache comme

serveur POP3
Listen 110
<VirtualHost *:110>
POP3Protocol on
POP3MailDrops /usr/local/apache/pop
<Directory /usr/local/apache/pop>
AuthUserFile /usr/local/apache/conf/htusers
AuthName pop3
AuthType Basic
Require valid-user
</directory>
</VirtualHost>
Ce module permet à Apache 2 d'agir comme serveur

POP3. POP3 (Post Office Protocol, version 3) est fréquem-
ment utilisé, notamment parce qu'il permet aux clients de
messagerie (comme Outlook, Eudora ou Netscape Mail)
de récupérer des messages à partir d'un serveur central.
Sachez que ce module n'autorise pas les systèmes de lec-

ture de courrier d'envoyer des messages. Pour cela, il vous
faudra un serveur SMTP (Simple Mail Transfer Protocol),
comme Sendmail ou PostFix. Pour activer la prise en
charge de POP3, placez une directive POP3Protocol On
dans la section d'hôte virtuel appropriée. POP3MailDrops
précise l'emplacement des boîtes de réception des utilisa-
teurs. L'utilisateur sous lequel Apache s'exécute doit pou-
voir lire et écrire sur ces boîtes de réception.
Vous pouvez télécharger mod_pop3 à l'adresse http://svn
.apache.org/viewcvs.cgi/httpd/mod_pop3/.
Compression de contenu
à la volée
#Apache 2 mod_deflate
AddOutputFilterByType DEFLATE text/html text/plain
text/xml
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$
no-gzip dont-vary
BrowserMatch ^Mozilla/4 gzip-only-text/html
#Apache 1.3 mod_gzip
mod_gzip_static_suffix .gz
AddEncoding gzip .gz
mod_gzip_item_include file \.html$
Le module de filtrage mod_deflate (Apache 2) propose un

filtre, DEFLATE, capable de compresser les données sortantes.
La compression peut consommer beaucoup de ressources
de l'unité centrale, mais elle présente l'avantage de réduire
la quantité de données qui seront transférées vers le client.
Cela est utile lorsque les clients se connectent à Internet par
le biais de liens lents et que le contenu peut être consi-
dérablement compressé, comme avec les pages HTML.
Compression de contenu à la volée 213
D'autres contenus déjà compressés, comme des fichiers

ZIP ou des images JPEG, ne profiteront que très peu
(voire pas du tout) d'une compression supplémentaire.
Bien entendu, pour que la compression du contenu fonc-
tionne, le client doit prendre en charge la fonctionnalité
opposée : la décompression. Cela vaut également pour les
navigateurs les plus modernes.
Si un client spécifique rencontre des problèmes pour trai-
ter un contenu compressé d'un certain type, vous pouvez
paramétrer la variable d'environnement no-gzip, en utili-
sant les directives SetEnvIf ou BrowserMatch. Cela empê-
chera mod_deflate de compresser le contenu délivré au
client, comme indiqué dans l'exemple.
Apache 1.3 propose un module équivalent, mod_gzip,
capable de compresser un contenu dynamique et statique.
Vous le trouverez à l'adresse http://sourceforge.net/
projects/mod-gzip/.
215
Index
A AliasMatch 17, 64
Allow 104, 119
AllowOverride 99
AcceptFilter 179
Amélioration
Accès
évolutivité 170
contrôler 101, 104, 110, 150
performances 170, 193
interdire 43, 109
Analyse du journal 53
limiter 108, 119
Apache
protéger 115
authentification 122
protéger pour DAV 157
autres solutions 186
refus 111
caractéristiques 3
INDEX
refus pour les fichiers sensibles
enfants 205
113
installation 5
serveur 127
sous UNIX et Linux 6, 7
access_log 46
sous Windows 8
AccessFilename 99
POP3 211
Action 68, 71
versions 4
Activation d'un proxy 189
apachetop 53
AddDefaultCharset 80
Application, authentification
AddHandler 68
121
AddModule 18
apxs 19
Adresse IP
Architecture Apache 203
autoriser l'accès 108
Archivage des journaux 55
consigner 56
Arguments
déjà utilisée 34
FollowSymLinks 175
interdire l'accès 109
SymLinksIfOwnerMatch 175
modifier 14
Arrêt
résoudre 56
du serveur 12
Affectation
serveur 32
jeux de caractères 80
Arrière-guichet
langue 80
CONNECT 189
Affichage du contenu d'une
FTP 189
requête 137
HTTP 189
Alias 64
masquer 192
216 Authentification
Authentification 102, 105 C

Apache 2.2 122
application 121
CA 134
certificats 147
Cache 185
de base 103
Apache 2 198
digest 103
mise en 188
modules 120
mod_cache 198
processus 102
proxy 197
AuthGroupFile 107
cadaver 162
AuthName 105
Caractères, jeux de 80
AuthType 105
Carte (cryptographie) 144
AuthUserFile 105
Casse, problèmes de 83
Autorisation 105
Certificat 130, 134
fichier 126
authentifier 147
Require 107
auto-signé 137
Autorité de certification 134, 146
créer 146
Auto-signé, certificat 137
importer 147
Avertissement (accès par
requête de signature 135
SSL) 146
INDEX
CGI
améliorer les performances 72
B dépannage 72
exécutables 70
Bande passante exécution 69
restreindre 181 Charges (équilibrage) 199
vol 117 Clé
bandwidth_share 182 cryptage 132
Barre oblique finale 81 cryptographie symétrique 132
Base de données openssl 133
consigner dans 54 paire 133
utilisateur 106 privée 132
BindAddress 15 protégée 134
Bogues publique 132, 134
clients 164 supprimer le mot de passe 134
contourner pour SSL 149 ClearModuleList 18
BrowserMatch 76 Client
BufferedLogs 177 comportant des bogues 164
préférences 77
DAVLockDB 217
Commande dynamique et DAV 165

configure 18 gestionnaire 67
killall 32 négociation 77
status 200 publier 20, 151
ulimit 171 Contrôle
Compilation (SSL) 140 accès 101, 104, 110, 119, 150
Compression des données processus externes 173
sortantes 212 Correction URL erronée 82
Configuration Correspondance de type 79
désactiver les fichiers 100 Création
fichier principal 9, 10 base de données utilisateur 106
fichiers multiples 11 CA 146
fichiers par répertoire 98 certificat client 146
hébergement virtuel 89, 91 icône 16
hôte virtuel 92, 93 Cryptage 132
minimale 140 Cryptographie
négociation du contenu 78 asymétrique 132
sécuriser pour DAV 157 carte 144
SSI 74 clé publique 132
INDEX
tester 29 symétrique 132
WebDAV 156 CustomLog 48, 59
configure, commande 18
CONNECT 189 D
Connexion
démon du journal système 27 DAV 153
restreindre 181 accès depuis Firefox 161
serveur 41 accès depuis la ligne de
surveiller 50 commande 162
Tomcat 200 accès depuis Office 158
Consignation accès depuis Windows 159
adresses IP 56 cadaver 162
conditionnelle 49 configurer 156
désactiver 177 contenu dynamique 165
format combiné 48 mod_speling 165
format commun 47 protéger l'accès 157
requête 46 sécuriser la configuration 157
vers une base de données 54 sitecopy 164
Contenu DAVLockDB 168
configurer la négociation 177
desservi par SSL 144
218 Débogage
Débogage 33 Alias 64
hôtes virtuels 95 AliasMatch 17, 64
mod_logio 33 Allow 104, 119
mod_loopback 33 AllowOverride 99
mod_tee 33 AuthGroupFile 107
mod_trace_output 33 AuthName 105
Déchargement (SSL) 195 AuthType 105
Décryptage 132 AuthUserFile 105
_default_ 93 BindAddress 15
DefaultLanguage 80 BrowserMatch 76
Démarrage BufferedLogs 177
avec SSL 141 ClearModuleList 18
du serveur 12 CustomLog 48, 59
serveur 41 DefaultLanguage 80
Démon (journal système) 27 Deny 104, 119
Deny 104, 119 DirectoryIndex 115
Dépannage 33 DirectorySlash 82
accès interdit 43 DocumentRoot 20, 89
connexion au serveur 41 ErrorDocument 93, 111
INDEX
démarrage du serveur 41 ErrorLog 26

document introuvable 42 ExtendedStatus On 51
erreur interne 44 Group 15
scripts CGI 72 Header 196
Désactivation HostNameLookups 56
consignation 177 Include 11
exécution CGI 125 KeepAliveTimeout 179
exécution SSI 125 LanguagePriority 80
fichiers de configuration 100 Listen 14, 141
fichiers de configuration par LoadModule 17, 20, 155
répertoire 176 LogFormat 46
listings de répertoire 115 LogLevel 27
Descripteur de fichier 173 MaxRequestsPerChild 206
Digest, authentification 103 MaxSpareServers 206
Directives 11 MinSpareServers 206
AcceptFilter 179 NameVirtualHost 91
AccessFilename 99 Options 114
Action 68, 71 Options +ExecCGI 70
AddDefaultCharset 80 Options +Multiviews 78
AddHandler 68 Order 104, 120
AddModule 18 PassEnv 75
Event 219
POP3Protocol On 212 Document introuvable 42

Port 15 DocumentRoot 20, 89
ProxyPass 191
ProxyPassReverse 192 E
ProxyRequests 190
Redirect 65 Echec de la redirection 67
RedirectMatch 66 En-tête
RemoveHandler 68 fin prématurée 39
RequestHeader 197 Host 90, 195
Require 105 malformé 39
RLimitCPU 174 manipuler 196
RLimitMem 174 proxy 196
RLimitNProc 174 Server 116
Satisfy 110 Entrée de journal 60
Satisfy all 110 Environnement, variables 74
Script 71 accéder à 75
ScriptAlias 70 paramétrer 75
ScriptLog 72 spéciales 76
sections 22, 23 Equilibrage des charges 199
INDEX
ServerName 16, 89 Erreur
ServerRoot 11 adresse déjà utilisée 34
ServerTokens 116 de segmentation 38
SetEnv 74 de syntaxe 34
SetEnvIf 75 en-tête malformé 39
SetFilter 84 fin prématurée d'en-tête 39
SetHandler 68 interne 38, 44
SSLCryptoDevice 144 journal 26
SSLEngine 141 journalisation 40
SSLRequire 150 liaison impossible 35
SSLVerifyClient 147 module non compatible 35
StartServers 205 niveau 27
TimeOut 181 ouverture de fichier 36
TransferLog 48 quantité d'informations 27
UnsetEnv 75 redirection 40
User 15, 126 refus d'accès 37
VirtualDocumentRootIP 97 résolution de nom 36
VirtualScriptAliasIP 97 error_log 46
DirectoryIndex 115 ErrorDocument 93, 111
DirectorySlash 82 ErrorLog 26
Disque, vitesse 170 Event 208
220 Evolutivité du système
Evolutivité du système 170 G

Exécution
désactiver
Gestionnaire
CGI 125
contenu 67
SSI 125
Graceful, redémarrage (en
restreindre de programmes 114
douceur) 14
Exemples, supprimer 125
Group 15
Expression régulière 66
Expressions régulières 22
H
ExtendedStatus On 51
F Header 196
Hébergement
virtuel 87
FastCGI 73
sur IP 88, 89
Fautes de frappe, corriger 82
sur le nom 90, 91
favicon.ico 16, 60
Host 90
Fichier
en-têtes 195
améliorer les performances
HostNameLookups 56
du système 174
INDEX
HostnameLookups 178
configuration 9, 10, 11
Hôte
configuration par répertoire
journal 59
désactiver 176
mélanger 94
favicon.ico 16, 60
SSL 96
htaccess 98
virtuel
httpd.pid 61
sur IP 93
journal 46
sur le nom 92
robots.txt 60
virtuels 96
sensibles
déboguer 95
refuser l'accès 113
SSL 144
vérifier les autorisations 126
Hotlinking 117
Filtres 209
htaccess 98
Firefox, accès à DAV 161
htpasswd 106
FollowSymLinks 175
HTTP 189
Format
et WebDAV 154
combiné 48
proxy transparent 201
consignation 47
restreindre les méthodes 118
FTP 189
httpd.pid 61
Fusion de journaux 58
HTTPS130
lsof 221
I K
Icône, créer 16 KeepAliveTimeout 179

ImageMagick 185 kill 32
Images killall 32
hotlinking 117
Importation L
certificat 147
Include 11 LanguagePriority 80
Informations Langue
sécurité 123 affecter 80
Installation 5 par défaut 80
mod_dav 155, 156 Liaison impossible 35
sous UNIX et Linux 6, 7 Liens symboliques 175
sous Windows 8 Ligne de commande
Inverse, proxy 184, 188, 191 accès à DAV 162
cadaver 162
J sitecopy 164
INDEX
tester 30
Jeux de caractères 80 Limiter
Journal proxy 127
access_log 46 refus de service 180
analyser 53 Limites
archiver 55 système d'exploitation 171,
entrées communes 60 172
erreurs 26, 40 Liste de contrôle de sécurité 123
error_log 46 Listen 14, 141
fichier 46 Listing, désactiver 115
fusion 58 LoadModule 17, 20, 155
personnalisé 48 LogFormat 46
pour chaque hôte 59 LogLevel 27
quantité d'informations 27 logresolve 57
rediriger 49 lsof 31
requête inhabituelle 61
rotation 55
séparation 58
surveillance en temps réel 53
système 27
222 Manipulation des en-têtes
M mod_rewrite 40, 81, 117, 167

mod_security 121
mod_snmp 52
Manipulation des en-têtes 196
mod_speling 82, 83, 165
Mappage URL 64, 81
mod_ssl 131, 138, 140, 148
Masquage des serveurs
mod_status 51, 179
d'arrière-guichet 192
mod_tee 33
Matériel, personnaliser 170
mod_throttle 182
mod_trace_output 33
MaxSpareServers 206
mod_tsunami 182
Mécanisme d'acceptation 178
mod_userdir 166
Mélange d'hôtes 94
mod_vhost_alias 97
Méthode HTTP, restriction 118
mod_virtualhost_alias 96
MIME 68
Modification de site Web 152
configurer 69
Modules
MinSpareServers 206
activer 18
Mise en cache 185, 188
ajouter sans recompilation 19
mod_actions 71
Auth 145
mod_apache_snmp 52
authentification 120
INDEX
mod_auth 157
bandwidth_share 182
mod_auth_dbm 108
désactiver 18, 124
mod_authn_alias 122
effacer la liste 18
mod_autoindex 116
hébergement virtuel 97
mod_backhand 184
mod_actions 71
mod_bandwidth 181
mod_apache_snmp 52
mod_cache 185, 198
mod_auth 157
mod_cgi 72
mod_auth_dbm 108
mod_choke 182
mod_authn_alias 122
mod_dav 153
mod_autoindex 116
installer 155, 156
mod_backhand 184
mod_deflate 185, 212
mod_bandwidth 181
mod_dir 81
mod_cache 185, 198
mod_filter 210
mod_cgi 72
mod_ftp 211
mod_choke 182
mod_include 74
mod_dav 153
mod_log_spread 177
mod_deflate 185, 212
mod_logio 33
mod_dir 81
mod_loopback 33
mod_filter 210
mod_nocase 83
mod_ftp 211
mod_perl 72
mod_include 74
mod_proxy 197
mod_log_spread 177
mod_require_host 182
mod_nocase 83
Performances 223
mod_perl 72 O
mod_proxy 197
mod_require_host 182
Office, accès à DAV 158
mod_rewrite 40, 81, 117, 167
openssl 132, 133, 135
mod_security 121
Options 114
mod_snmp 52
+ExecCGI 70
mod_speling 82, 83, 165
+Multiviews 78
mod_ssl 131, 138, 140, 148
noatime 175
mod_status 51, 179
Order 104, 120
mod_throttle 182
Outils
mod_tsunami 182
apachetop 53
mod_userdir 166
apxs 19
mod_vhost_alias 97
ImageMagick 185
mod_virtualhost_alias 96
logresolve 57
non compatible 35
lsof 31
rechercher 17
netstat 31
Robotcop 182, 183
openssl 132
Mot de passe
ps 31
clé 134
INDEX
rotatelogs 55
supprimer pour une clé 134
vérifier le fonctionnement 31
MPM 172, 203, 208
vlogger 59
basé sur les processus 204
vmstat 170
basé sur les threads 207
Ouverture avec erreur 36
Event 208
Perchild 209
P
Prefork 205
sélectionner 204
Worker 207 Page
Multiview 78 par utilisateur 166
rediriger 65, 66
N valider 84
Paire de clés 133
Paramètres
NameVirtualHost 91
HostnameLookups 178
Navigateur, accès limité 119
PassEnv 75
Négociation
Perchild 209
configurer 78
Performances
contenu 77, 177
améliorer 170, 193
netstat 31
CGI 72
noatime 175
RAM 170
Nom de serveur 16
SSL 143
système de fichiers 174
vitesse du disque 170
224 Personnalisation
Personnalisation R
journal 48
matériel 170
RAM, augmenter 170
refus d'accès 111
Redémarrage
réseau 178
automatique 57
POP3 211
du serveur 12
POP3Protocol On 212
en douceur (graceful) 14
Port 15
Redirect 65
modifier 14
Redirection
Pound 201
échec 67
Préférences client 77
erreur 40
Prefork 205
expression régulière 66
Problèmes de casse 83
journal 49
Processus
page 65, 66
externes
RedirectMatch 66
contrôler 173
Refus
MPM 204
d'accès 37
Programme, exécution restreinte
personnaliser 111
114
INDEX
de service 180
Protection de l'accès DAV 157
RemoveHandler 68
Protocole
Répertoire
CGI 69
fichiers de configuration 98
DAV 153
listings 115
HTTPS 130
Répertoire utilisateur 167
Proxy
RequestHeader 197
activer 189
Requête
de cache 197
afficher le contenu 137
en-têtes 196
consignation conditionnelle 49
HTTP transparents 201
consigner 46
inverse 184, 188, 191
inhabituelle 61
limiter 127
signature 135
ordinaire 188, 190
Require 105, 107
activer 190
Réseau, personnaliser 178
Pound 201
Résolution
Squid 201
adresses IP 56
URL 193
de nom 36
ProxyPass 191
de problèmes avec
ProxyPassReverse 192
DAVLockDB 168
ProxyRequests 190
Ressources ( CGI exécutables) 70
ps 31
Restriction
Publication
bande passante 181
contenu 20, 151
connexions 181
SSL 225
RLimitCPU 174 connexion 41

RLimitMem 174 démarrage 12
RLimitNProc 174 démarrage avec SSL 141
Robotcop 182, 183 en-tête 116
Robots 183 erreur interne 38
robots.txt 60, 183 limiter l'accès 127
rotatelogs 55 redémarrage 12
Rotation des journaux 55 redémarrage automatique 57
restreindre l'envoi de
S contenu 114
sécurité 114
Satisfy 110 spécifier le nom 16
Satisfy all 110 vérifier le fonctionnement 31
Script 71 SetEnv 74
CGI 69 SetEnvIf 75
ScriptAlias 70 SetFilter 84
ScriptLog 72 SetHandler 68
Sections 21 Signature
conditionnelles 23 afficher le contenu de la
INDEX
directives 22, 23 requête 137
emplacement 120 requête 135
répertoires 120 Site, modifier 152
VirtualHost 88, 89 sitecopy 164
Sécurisation SNMP 52
configuration de DAV 157 Squid 201
serveur 114 SSI 73
SSL 129 configurer 74
Sécurité SSL 129
désactiver les modules 124 améliorer les performances 143
informations 123 avertissement à l'accès 146
liste de contrôle 123 certificat 130
Segmentation 38 compiler 140
Sélection du MPM 204 contourner les bogues 149
Séparation des journaux 58 contrôle d'accès complexe 150
ServerName 16, 89 décharger 195
ServerRoot 11 desservir le contenu 144
ServerTokens 116 et démarrage 141
Serveur fonctionnement 130
arrêt 12 hôtes virtuels 96
arrêter 32 hôtes virtuels sur le nom 144
configuration minimale 140 tester les sites 148
226 SSLCryptoDevice
SSLCryptoDevice 144 traceroute (tracert) 42

SSLEngine 141 TransferLog 48
SSLPassPhraseDialog 142 Type
SSLRequire 150 correspondances 79
SSLVerifyClient 147 MIME 68
StartServers 205
status 200 U
stunnel 148
Suppression ulimit 171
exemples de script 125 UnsetEnv 75
mot de passe d'une clé 134 URL
Surveillance auto-référentielle 16
connexions 50 en proxy 193
en temps réel 53 mappage 64, 81
mod_status 51 User 15, 126
SNMP 52 Utilisateur
Symboliques, liens 175 autoriser 112
SymLinksIfOwnerMatch 175 base de données 106
Syntaxe, erreur 34 modifier 15
INDEX
Système d'exploitation nombreux 108

augmenter les limites 171, 172 page personnelle 166
modifier les limites 172 répertoires 167
Système de fichiers et Utilitaires
noatime 175 htpasswd 106
Système, journal 27 kill 32
stunnel 148
T tail 54
traceroute (tracert) 42
tail 54
Telnet, client 30 V
Test
à la ligne de commande 30 Validation de pages 84
configuration 29 Variables
sites SSL 148 d'environnement 74
Threads MPM 207 accès 75
Tidy (validation des pages) 84 paramétrer 75
TimeOut 181 d'environnement spéciales 76
Tomcat, connexion 200 Versions 4
Worker 227
VirtualDocumentRootIP 97 W
VirtualHost 88, 89
VirtualScriptAliasIP 97
WebDAV 152, 153
Virtuel
et HTTP 154
hébergement 87, 88
Windows, accès à DAV 159
basé sur le nom 90
Worker 207
configurer 89, 91
modules 97
hôte 96
configurer 92, 93
déboguer 95
vlogger 59
vmstat 170
Vol de bande passante 117
INDEX
228 Worker
INDEX
LE GUIDE DE SUR VIE
Daniel Lopez LE GUIDE DE SURVIE
LE GUIDE DE SURVIE
Apache
L’ESSENTIEL DU CODE ET DES COMMANDES
Ce Guide de survie est le compagnon indispensable pour ne
jamais vous sentir perdu dans un environnement Apache.
Vous y trouverez en un clin d’œil les principales commandes
Apache
et lignes de code pour amener un serveur Web Apache à
Apache
répondre à vos besoins, que vous exécutiez des domaines
virtuels complexes desservant des millions de pages par
jour ou un simple serveur de test tournant sur un portable.
CONCIS ET MANIABLE
Facile à transporter, facile à utiliser — finis les livres
encombrants ! L’ESSENTIEL DU CODE ET DES COMMANDES
PRATIQUE ET FONCTIONNEL
Plus de 100 fragments de code et commandes
personnalisables pour gérer efficacement un serveur
Apache dans toutes les situations.
Daniel Lopez est président et directeur technique de

BitRock, une société qui élabore des outils d’installation
et de gestion multi-plateformes, en mettant l’accent sur
les produits open source. C’est l’auteur du module Apache
mod_mono et de l’outil de configuration Comanche.
Niveau : Intermédiaire
Catégorie : Web
Configuration : Multi-plateforme
Pearson Education France ISBN : 978-2-7440-4001-6 Lopez

75010 Paris
Tél. : 01 72 74 90 00
Fax : 01 42 05 22 17
www.pearson.fr
2126-MP Apache.indd 1 11/05/09 15:38:50

Apache Phrasebook

Transféré par

Droits d'auteur :

Formats disponibles

Apache Phrasebook

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Apache Phrasebook

Transféré par

Droits d'auteur :

Formats disponibles

LE GUIDE DE SUR VIE

Daniel Lopez LE GUIDE DE SURVIE

Daniel Lopez est président et directeur technique de

Pearson Education France ISBN : 978-2-7440-2126-6 Lopez

2126-MP Apache.indd 1 11/05/09 15:38:50

Publié par CampusPress Titre original : Apache Phrasebook

Réalisation PAO : Léa B

Copyright © 2009 Sams Publishing

Tous droits réservés

1 Les bases d'Apache 3

Vérification du fonctionnement d'Apache 31

4 Mappage d'URL et contenu dynamique 63

6 Sécurité et contrôle d'accès 101

Désactivation des listings de répertoire 115

7 SSL et TLS 129

Configuration minimale d'Apache 140

8 Publication de contenu avec DAV 151

Gestion des clients présentant des bogues 164

9 Performances et évolutivité 169

10 Proxy Apache et mise en cache 187

Activation de la prise en charge de mod_proxy 189

11 Multitraitement et modules de protocole 203

A propos des auteurs

Apache s'est toujours trouvé au cœur du Web, depuis ses

b Flexible. Son architecture étant modulaire et extensi-

Il existe deux versions principales d'Apache, largement

En revanche, vous opterez pour Apache 1.3 dans les cas

Pour savoir si Apache est déjà

Si vous utilisez un système Linux, Apache est certaine-

Si la réponse est positive, le résultat renvoyé ressemblera à

Vous obtiendrez une réponse encore plus détaillée avec

Sur les systèmes Windows, pour savoir si Apache est

Pour se procurer Apache

Installation d'Apache 1.3

Vous pouvez maintenant décompresser, configurer, com-

Installation d'Apache 2.0

Ce processus est analogue à celui décrit précédemment

Le nom du serveur est celui utilisé par vos clients pour

Est-il possible d'installer différentes versions d'Apache sur la

Configuration de base des fichiers

Tableau 1.1. Emplacement du fichier httpd.conf sur différents

Emplacement du fichier Plate-forme

/etc/httpd/httpd.conf Suse, Mandrake, anciens

Le principal fichier de configuration Apache est appelé

du signe dièse (#) au début de la ligne (ils seront ignorés

Utilisation de plusieurs fichiers

Il est quelquefois utile de répartir la configuration du ser-

Cela survient généralement avec les distributions Linux

Démarrage, arrêt et redémarrage

Pour démarrer, arrêter ou redémarrer Apache, vous pou-

Apache relira alors sa configuration. Pour connaître la dif-

Vous avez accès à des raccourcis de ces commandes dans

Qu'est-ce qu'un redémarrage "en douceur" ?

Apache doit connaître l'adresse IP et le port à écouter

Vous pouvez également utiliser la directive Port pour

Vous pouvez préciser le groupe et l'utilisateur sous les-

Spécification d'un nom de serveur

Dans certains cas, Apache doit construire des URL

Création d'une icône

De nombreux navigateurs récents, notamment Internet