Apache: L'essentiel du code et des commandes

L’ESSENTIEL DU CODE ET DES COMMANDES Ce Guide de survie est le compagnon indispensable pour ne jamais vous sentir perdu ...

Author: Daniel Lopez | Jesus Blanco

183 downloads 1412 Views 1MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

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 et lignes de code pour amener un serveur Web 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 !

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

ISBN : 978-2-7440-2126-6

LE GUIDE DE SUR VIE

Apache

Apache

LE GUIDE DE SURVIE

Daniel Lopez

LE GUIDE DE SURVIE

Apache L’ESSENTIEL DU CODE ET DES COMMANDES

Lopez

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 illustrer 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 47 bis, rue des Vinaigriers 75010 PARIS Tél : 01 72 74 90 00 Réalisation PAO : Léa B Auteur : Daniel Lopez et Jesus Blanco ISBN : 978-2-7440-4001-6 Copyright © 2009 CampusPress est une marque de Pearson Education France

Titre original : Apache Phrasebook Traduit de l’américain par : Nathalie Le Guillou de Penanros ISBN original : 0-672-32836-4 Copyright © 2006 by Sams Publishing www.samspublishing.com Tous droits réservés Sams Publishing 800 East 96th, 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

1

2

Introduction

1

Les bases d'Apache

3

Découverte d'Apache Pour savoir si Apache est déjà installé Installation d'Apache 1.3 sous Linux et UNIX Installation d'Apache 2.0 sous Linux et UNIX Installation d'Apache sous Windows Configuration de base des fichiers Utilisation de plusieurs fichiers de configuration Démarrage, arrêt et redémarrage d'Apache Modification de l'adresse et du port utilisés par Apache Modification de l'utilisateur Apache Spécification d'un nom de serveur Création d'une icône pour "Ma page Web" Découverte des modules disponibles sur le serveur Activation et désactivation de modules individuels Ajout de modules après la compilation d'Apache sans recompilation Publication de contenu

3 5 6 7 8 9 11 12 14 15 16 16 17 18 19 20

Dépannage

25

A l'aide ! Mon serveur Apache ne fonctionne pas ! Le journal d'erreurs Connexion au démon du journal système Contrôle de la quantité des informations consignées Test de la configuration Apache à la recherche de problèmes Test d'Apache à partir de la ligne de commande

25 26 27 27 29 29

IV

APACHE

3

Vérification du fonctionnement d'Apache Autres manières d'arrêter Apache Utilisation d'Apache… pour déboguer Apache Erreurs de démarrage Erreurs de refus d'accès Erreurs internes au serveur Autres fichiers pour la journalisation des erreurs Les redirections ne fonctionnent pas Liste de vérification pour le dépannage Si tout le reste a échoué

31 32 33 34 37 38 40 40 41 44

Journaux et surveillance

45

Introduction à la consignation des erreurs dans Apache Fichiers journaux Apache par défaut Création des formats de journaux Création d'un fichier journal personnalisé Redirection des journaux vers un programme externe Consignation conditionnelle de requêtes Surveillance des personnes se connectant à votre site Surveillance d'Apache avec mod_status Surveillance d'Apache avec SNMP Analyse des journaux à l'aide d'outils Open Source Surveillance de vos journaux en temps réel Consignation des requêtes dans une base de données Rotation et archivage des journaux Contrôle de la résolution des adresses IP Traitement d'adresses IP consignées Redémarrage automatique d'Apache en cas de panne Fusion et séparation de fichiers journaux Conservation de fichiers séparés pour chaque hôte virtuel Entrées de journaux communes

45 46 46 48 49 49 50 51 52 53 53 54 55 56 56 57 58 59 60

Table des matières

4

Mappage d'URL et contenu dynamique

63

Mappage d'URL Mappage d'URL et de fichiers avec Alias Mappage de motifs d'URL à des fichiers avec AliasMatch Redirection d'une page vers un autre emplacement Redirection vers la dernière version d'un fichier Echec de la redirection ou requêtes non autorisées Définition des gestionnaires de contenu Les types MIME Configuration des types MIME Les bases de l'exécution des scripts CGI Désignation de ressources comme des CGI exécutables Association de scripts à des méthodes HTTP et des types MIME Dépannage relatif à l'exécution des scripts CGI Amélioration des performances du script CGI SSI Configuration de SSI Paramétrage des variables d'environnement Paramétrage dynamique des variables d'environnement Variables d'environnement spéciales Négociation du contenu Configuration de la négociation du contenu Affectation de jeux de caractères par défaut et de priorités de langue Mappage avancé d'URL avec mod_rewrite Problème de l'oubli de la barre oblique finale Correction des fautes de frappe Résolution des problèmes de casse Validation de pages avec Tidy

63 64 64 65 66 67 67 68 69 69 70 71 72 72 73 74 74 75 76 77 78 80 81 81 82 83 84

V

VI

APACHE

5

6

Hébergement virtuel

87

Définition de l'hébergement virtuel Hébergement virtuel basé sur IP Configuration de l'hébergement virtuel basé sur IP Hébergement virtuel basé sur le nom Configuration de l'hébergement virtuel basé sur le nom Que se passe-t-il si une requête ne correspond à aucun hôte virtuel ? Mélange d'hôtes basés sur IP et basés sur le nom Débogage des configurations d'hôtes virtuels Utilisation de SSL avec des hôtes virtuels basés sur le nom

87 88 89 90 91 92 94 95 96

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

101

Le contrôle d'accès, une exigence ? Différences existant entre les versions d'Apache L'authentification basique et digest Présentation du contrôle d'accès Apache Configuration des autorisations et des authentifications Apache Création d'une base de données utilisateur Emploi de Require pour autoriser des utilisateurs et des groupes Gestion d'un grand nombre d'utilisateurs Autorisation d'accès à des adresses IP spécifiques uniquement Refuser l'accès à des adresses IP spécifiques Combinaison des méthodes de contrôle d'accès Personnalisation de la page de refus d'accès Donner le pouvoir aux utilisateurs Refus d'accès aux fichiers système et sensibles Restriction d'exécution de programmes Eviter les abus

101 102 102 104 105 106 107 108 108 109 110 111 112 113 114 115

Table des matières

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 Fonctionnement de SSL Compilation d'OpenSSL Clés de cryptage Création d'une paire de clés Création d'une paire de clés protégées par mot de passe Suppression du mot de passe d'une clé Certificats Création d'une requête de signature de certificat Affichage du contenu d'une requête de signature de certificat Création d'un certificat autosigné Compilation de la prise en charge SSL dans Apache 1.3 Compilation de la prise en charge SSL dans Apache 2.x

129 130 131 132 133 133 134 134 135 137 137 138 140

VII

VIII

APACHE

8

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

140 141 142 143 144 144 145

149 150 150

Publication de contenu avec DAV

151

Apache et la publication de contenu Présentation de WebDAV Avantages de l'utilisation de mod_dav WebDAV et le protocole HTTP Installation de mod_dav sous Apache 2.0 Installation de mod_dav sous Apache 1.3 Configuration WebDAV de base Sécurisation de votre configuration WebDAV Accès aux ressources DAV depuis Microsoft Office Accès aux ressources DAV depuis Microsoft Windows Accès aux ressources DAV depuis Firefox Accès à DAV depuis la ligne de commande

151 152 153 154 155 156 156 157 158 159 161 162

146 146 147 148 148

Table des matières

9

Gestion des clients présentant des bogues mod_speling et DAV Contenu dynamique et DAV Activation des pages par utilisateur Autres répertoires utilisateur Résolution des problèmes avec DAVLockDB

164 165 165 166 167 168

Performances et évolutivité

169

Personnalisation d'Apache Les performances et l'évolutivité Personnalisation du matériel Elargissement des limites du système d'exploitation Elargissement des limites du système d'exploitation sur les processus Augmentation des descripteurs de fichiers du système d'exploitation Contrôle des processus externes Amélioration des performances du système de fichiers Gestion de liens symboliques Personnalisation du réseau et des paramètres de statut Eviter les abus Restriction des connexions et de la bande passante Gestion des robots Proxy inverses et systèmes d'équilibrage des charges Mise en cache et compression Optimisations spécifiques aux modules Alternatives à Apache

169 170 170 171

10 Proxy Apache et mise en cache De l'utilité de la mise en cache et des proxy Proxy ordinaires et inverses Différences entre Apache 1.3, 2.0 et 2.2

172 173 173 174 175 178 180 181 183 184 185 186 186 187 187 188 188

IX

X

APACHE

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

189 189 191 192 193 193 195 195 196 197 198 199 200 201 201 203

Evolution de l'architecture Apache Sélection d'un module multitraitement Découverte des MPM basés sur les processus Configuration de MPM Prefork MPM basés sur des threads et MPM hybrides Configuration de MPM Worker Autres MPM Description des filtres Apache 2 Utilisation d'Apache comme serveur FTP Utilisation d'Apache comme serveur POP3 Compression de contenu à la volée

203 204 204 205 207 207 208 209 210 211 212

Index

215

A propos des auteurs

A propos des auteurs Daniel Lopez est le fondateur de la société BitRock qui élabore des outils d'installation et de gestion multiplates-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 Comanche, un outil de configuration de GUI pour Apache. Daniel Lopez intervient régulièrement dans des conférences sur l'Open Source, comme LinuxWorld, ApacheCon 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 Universitet. 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'administration des affaires (université de Séville) et un master en informatique (UNED).

XI

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 centaines d'options du produit. Ce livre vous servira également 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'étranger, 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 versions (1.3 et 2.x). Nous expliquerons comment télécharger 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 extensible, 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 fonctionnalité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 Apache 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 traitement en threads sous UNIX. b Vous avez besoin de l'une de ses nouvelles fonctionnalité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é

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 certainement déjà installé. Si votre distribution fait appel au systè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 commandes 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 programmes du Panneau de configuration. Le chemin d'installation est le suivant : C:\Program Files\Apache Group

5

6


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.apachefrance.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 exemple, 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 version 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.

Installation d'Apache 2.0 sous Linux et UNIX

Vous pouvez maintenant décompresser, configurer, compiler 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 pouvez 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.

7

8


Installation d'Apache sous Windows L'installation d'Apache sous Windows est encore plus simple 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

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'installation 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 simultané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 Apache 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 principal 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.

9

10


Tableau 1.1. Emplacement du fichier httpd.conf sur différents systèmes Emplacement du fichier de configuration

Plate-forme

/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 /usr/local/apache/conf

Lors de la compilation à partir du source, comme indiqué précédemment dans ce chapitre.

c:\Program Files\Apache Group\Apache2\conf\ httpd.conf c:\Program Files\Apache Group\Apache2\conf\ httpd.conf

Windows

/private/etc/httpd/ httpd.conf

Mac OS X

Le principal fichier de configuration Apache est appelé httpd.conf. Son emplacement varie selon que vous utilisiez 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 sections. Pour y placer des commentaires, faites-les précéder

Utilisation de plusieurs fichiers de configuration

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'installation 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 serveur 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.

11

12


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 apachectl apachectl apachectl

start stop restart graceful

Pour démarrer, arrêter ou redémarrer Apache, vous pouvez émettre n'importe laquelle de ces commandes. Selon votre installation, vous devrez peut-être fournir un chemin absolu pour apachectl, comme /usr/sbin/apachectl ou /usr/local/apache/bin/apachectl. Même s'il est possible 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 privilè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

Apache relira alors sa configuration. Pour connaître la diffé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 directement, à 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 service, 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.

13

14


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 douceur" 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écifié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

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 autoré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 lesquels 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'utilisateur 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.

15

16


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'utilisation 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 inversé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

Vous pouvez utiliser la directive AliasMatch pour rediriger 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.

17

18


Activation et désactivation de modules individuels ./configure (...) --enable-status ./configure (...) --disable-status

Vous pouvez activer ou désactiver des modules individuels 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 fonctionnement 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 disponible dans Apache 2.x. Si vous désactivez un module, n'oubliez pas de le supprimer des directives du fichier httpd.conf qu'il apporte ou de l'inclure dans une section (comme indiqué), faute de quoi le serveur risque de ne pas démarrer : ExtendedStatus On

Ajout de modules après la compilation d'Apache sans recompilation

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 automatiquement, 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 modules tiers plus complexes, comme PHP, il existe généralement des commutateurs --with-apxs ou --with-apxs2 à transférer dans le script de configuration. Si vous possédez une version binaire du module disponible, inutile d'entreprendre ces étapes liées à apxs. Cela vaut en particulier si vous avez déjà compilé de nombreux

19

20


modules optionnels lors de la construction du serveur ou si le module est déjà fourni dans le cadre de votre distribution Linux ou de votre package d'installation Windows. Si vous utilisez Apache 1.3, vous pouvez ajouter le nouveau 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 LoadModule, ici avec modules/ au lieu de libexec/, dans le répertoire 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épertoire 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

Il n'est pas obligatoire de placer le contenu dans le répertoire 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 Chapitre 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 (configuration du serveur) et s'y appliquent : ... ... ...

21

22


Sections de directives Apache par défaut Les sections de directives suivantes correspondent aux sections par défaut utilisées dans les fichiers de configuration Apache : . 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 Chapitre 5). et . Ces sections appliquent des directives à un répertoire (ou groupe de répertoires) donné dans le système de fichiers. La section permet d'utiliser des motifs d'expressions régulières comme arguments. et . Appliquent des directives à certaines URL ou à certains motifs d'URL demandés. Elles sont semblables aux sections Directory. et . 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 propres 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 à condition 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 Sections de directives Apache

Ainsi, par exemple, l'expression régulière concordera avec toutes les requêtes demandant 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 raisons 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 conditionnelles. Les directives qui y figurent seront traitées uniquement si certaines conditions sont remplies : . Les directives de cette section seront traitées si un argument de ligne de commande spécifique 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 , de sorte que les directives s'appliquent si l'argument n'est pas transféré. . Les directives d'une section IfModule ne seront traitées que si le module transféré comme argument est présent dans le serveur Web. Le fichier de configuration Apache par défaut comprend des exemples de ce type pour différents modules MPM. Par exemple, dans le fichier httpd.conf, vous verriez : LoadModule ssl_module modules/mod_ssl.so que vous activeriez à la ligne de commande, comme ceci : # httpd –DSSL

23

2 Dépannage C

e chapitre traite des problèmes les plus communs rencontré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 explorerons 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 importants survenant dans la vie du serveur, comme les démarrages, 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ésoudre 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 souvent 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 chemin 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

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.

27

28


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 être entreprise immédiatement.

crit

Conditions critiques. socket: Failed to get a socket, exiting child.

error

Situation d'erreur.

Premature end of script headers.

warn

Situation d'avertissement.

Child process 1234 did not 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 débogage.

Opening config file...

getpwuid: couldn't determine user name from uid.

Test de la configuration Apache à la recherche de problèmes

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 procè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.

29

30


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 à distance, 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

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 TCP www.exemple.com:http (LISTEN) httpd 30277 nobody 3u IPv4 136524 TCP www.exemple.com:http (LISTEN) ... 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 quelques-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.

31

32


Sous Windows, vous pouvez faire appel au Gestionnaire des tâches (raccourci clavier : Ctrl+Alt+Suppr) pour vérifier que le processus Apache.exe fonctionne. Vous pouvez également utiliser l'application de la barre des tâches figurant 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 commande 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érique, 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 processus 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

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 cliquant 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 application 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 lorsque des problèmes d'en-tête ou de cookies surviennent.

33

34


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 configuration, indiquée dans le message d'erreur. Reportez-vous au Chapitre 1 pour en savoir plus sur l'utilisation d'une directive , 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 problè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

Apache écoute les requêtes, en ajustant les valeurs donné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 systè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 Apache 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 compatible") 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

35

36


du source du module, vous pourrez peut-être le recompiler à l'aide de votre installation Apache actuelle (voir Chapitre 1). Si vous ne disposez pas du source ou que vous soyez incapable de recompiler un module dont la fonctionnalité est essentielle pour vous, mettez à niveau (ou rétrogradez) votre serveur Apache avec une version compatible 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 .

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 autorisations suffisantes pour lire le ou les fichiers de configuration Apache ou pour écrire dans les fichiers de journal Apache.

Erreurs de refus d'accès

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 superutilisateur (ou de l'utilisateur) qui l'a installé ou, si vous disposez des autorisations, employez chmod pour modifier la proprié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 problè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 proprié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 provient des directives de contrôle d'accès – comme Allow (Autoriser) et Deny (Refuser) – dans les sections ou 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épertoire dans lequel ne se trouvait aucun fichier d'index.

37

38


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 question. 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 suivants : 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 interdite 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

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 dispose 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 terminer le processus s'il consomme trop de ressources (mémoire, temps d'unité centrale), comme nous le verrons 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éralement du fait d'une erreur de programmation). Le serveur Apache attend une réponse de script commençant par zéro, ou plusieurs en-têtes, suivis d'une ligne vide.

39

40


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

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 appartiennent 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 possible que le serveur ne s'exécute pas du tout. Vérifiez ensuite que vous pouvez vous connecter à Apache à 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

41

42


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 netstat 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 correctement 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'exploitation 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 problè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 connectez à l'aide de versions plus anciennes du navigateur ou que vous exécutez des configurations inhabituelles, consultez 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 obtenez une erreur de type "Document Not Found" (Document introuvable), vérifiez que le document existe bien dans le système de fichiers.

Liste de vérification pour le dépannage

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épertoire 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 dispose 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épertoire sont interdits dans le fichier de configuration Apache. Vérifiez que la requête répond à toutes les exigences stipulé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.

43

44


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 premiè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 serveur 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 fonctionnement 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 configuration 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

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 +0500] "GET /exemple.png HTTP/1.0" 200 1234 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 exemple, ce qui signifie que la requête s'est terminée avec succès).

47

48


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 document 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 navigateur 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édemment 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

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 programme 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 programme 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 ; assurez-vous que le programme est sécurisé. De même, lorsque vous entrez un chemin de fichier sur des plates- formes différentes d'UNIX, prenez soin de n'employer que des barres obliques (même si les barres obliques inversées sont autorisées). D'une façon générale, il est conseillé de toujours utiliser 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 variable peut avoir été précédemment définie en fonction de

49

50


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 accepter une variable d'environnement comme troisième argument. 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 consigner 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 exemple montre comment utiliser une variable d'environnement 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

Surveillance d'Apache avec mod_status SetHandler server-status Order Deny,Allow Deny from all Allow from 192.168.0

Le module mod_status fournit à l'administrateur des informations sur l'activité et les performances du serveur. Une page HTML s'affiche, proposant les statistiques 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 supplémentaires peut considérablement ralentir le serveur. Cet exemple montre comment activer la surveillance mod_status, tout en limitant l'accès aux informations à certaines 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.

51

52


Surveillance d'Apache avec SNMP Il existe deux modules Open Source qui ajoutent des fonctionnalités SNMP (Simple Network Management Protocol) 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 desservis, ainsi que de nombreux autres paramètres. Les modules 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

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

53

54


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 surveiller 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/software).

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

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 rotation 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 trouverez un programme analogue à l'adresse http://cronolog.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 journaux 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.

55

56


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 correspondant à 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 +0500] "GET /exemple.png HTTP/1.0" 200 1234

Si la directive est réglée sur on, cette même entrée ressemblera à ceci : unit12.exemple.com - utilisateur [12/Jun/2005:08:33:34 +0500] "GET /exemple.png HTTP/1.0" 200 1234

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

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 serveur 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 service, sachez que vous pouvez le redémarrer automatiquement, 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.

57

58


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 processus httpd spécifiques. La plupart des distributions de Linux comprennent également 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 journaux de tous les serveurs en un seul fichier journal avant de le transférer aux outils d'analyse. De même, si un seul serveur 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épertoire support/ de la distribution de la source Apache.

Conservation de fichiers séparés pour chaque hôte virtuel

Le projet logtool propose une suite d'outils de manipulation 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 ServerName vhost1.exemple.com CustomLog logs/vhost1.exemple.com_log combined ErrorLog logs/vhost2.exemple.com_log .......

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

59

60


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 à certaines 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'affichage d'une icône personnalisée près de la barre d'emplacement 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 programmes, 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 recherche. 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

httpd.pid écrasé (httpd.pid Overwritten) Sous UNIX, le fichier httpd.pid contient le PID (identifiant de processus) du processus Apache en cours d'exécution. 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'existent pas sur votre site, comme cmd.exe, root.exe, dir, etc. Certaines entrées de journal naissent de tentatives automatisé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).

61

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 expliquerons également comment utiliser le CGI et les fonctionnalité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 corresponde à 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 à rechercher 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 suivante : 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 analogue à 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

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 concerne 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 configurer 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 serveur différent. Dans cet exemple, une requête pour http://www.exemple.com/news/today/index.html sera redirigée vers http://news.exemple.com/today/index.html.

65

66


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 correspondront au numéro principal et au numéro secondaire, 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 remplacé dans l'URL de destination.

Echec de la redirection ou requêtes non autorisées

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 plusieurs 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 Redirect, certaines se termineront tout de même par la terrible réponse "404 Document Not Found". Il peut donc être souhaitable de modifier la page d'erreur par défaut d'Apache et de diriger vos utilisateurs vers un emplacement particulier 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 Options +ExecCGI SetHandler cgi-script

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

67

68


être configuré pour associer un contenu à des gestionnaires 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 gestionnaire 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 documents 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 gestionnaire 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éterminer 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 identifier et afficher correctement le contenu à destination de l'utilisateur final.

Configuration des types MIME

Configuration des types MIME AddType text/xml .xml .schema ForceType text/xml

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 comprend les types MIME les plus communs et leurs extensions associées.

Les bases de l'exécution des scripts CGI CGI signifie Common Gateway Interface (interface de passerelle commune). Il s'agit d'un protocole standard utilisé par les serveurs Web pour communiquer avec des programmes 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).

69

70


Attention ! Des programmes CGI d'exemple ou mal écrits peuvent constituer 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 utiliser n'importe laquelle des sections , et 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 toutes les URL se terminant par une extension de fichier .pl comme des scripts CGI : Options +ExecCGI SetHandler cgi-script

Association de scripts à des méthodes HTTP et des types MIME

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'association 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 distribution 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 (chemin de document). Comme dans l'exemple de la section précédente, le répertoire 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.

71

72


Dépannage relatif à l'exécution des scripts CGI ScriptLog logs/cgi_log

En plus des modules et des techniques présentés aux Chapitres 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 rapidement 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 programmes à 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 automatiquement 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 compatibilité CGI, dans lequel les CGI Perl existants peuvent

SSI

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 popularité après avoir été utilisé dans les structures de développement Web comme Ruby-on-Rails.

SSI Document on disk This document, 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 indiquant la date et l'heure auxquelles la page a été servie. Autre exemple, la distribution Apache 2.0 utilise SSI pour personnaliser 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.

73

74


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 indiqué dans l'exemple.

Paramétrage des variables d'environnement SetEnv foo bar UnSetEnv foo PassEnv foo

Les variables d'environnement sont des variables qui peuvent être partagées entre des modules et qui sont également disponibles pour des processus externes, comme les CGI et les documents SSI. Les variables d'environnement peuvent également être utilisées pour la communication 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 disponibles 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

A l'inverse, vous pouvez supprimer des variables spécifiques, à 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.

75

76


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

des clients qui présentent des bogues. Par exemple, la variable nokeepalive désactive la prise en charge du maintien en activité dans Apache, qui réduit les performances du serveur (plusieurs requêtes ne pouvant pas être transmises sur la même connexion). De fait, elle ne doit être paramé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-Encoding: de la réponse.

77

78


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 Multiviews 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 chaque 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 contenu et le jeu de caractères, puis pour renvoyer le contenu approprié.

Configuration de la négociation du contenu

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 concernant. 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 directive AddHandler (comme indiqué dans la configuration d'exemple). Le fichier peut contenir plusieurs entrées. Chacune commence par URI: (c'est-à-dire le nom du document, suivi de plusieurs attributs comme Content-Type:, Content-Language: 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.

79

80


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 AddDefaultCharset, 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 adresses 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

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 illimité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 redirections ne fonctionnent pas", au Chapitre 2. N'oubliez pas, lorsque vous accédez à certaines URL correspondant à des répertoires, d'ajouter une barre oblique ("/") à la fin de l'URL. Le répertoire peut contenir

81

82


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

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, toutefois ! 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 à renvoyer 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

83

84


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 configuration 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 marquage, il est possible qu'elles ne s'affichent pas correctement 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 standards. Vous le trouverez à l'adresse http://tidy.sourceforge.net/. Vous pouvez exécuter Tidy à partir de la ligne de commande 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

comment employer TidyOption pour configurer le comportement 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/.

85

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 utilisateurs, 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 desservir 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ébergement pour des sites Web commerciaux peuvent répondre à 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 (…)

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 . Chaque section 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 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

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.exemple.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 diffé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 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 , 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 ServerName www.exemple.com DocumentRoot /usr/local/Apache/sites/exemple.com

89

90


ServerName www.exemple.com DocumentRoot /usr/local/Apache/sites/staging ServerName www.exemple.net DocumentRoot /usr/local/Apache/sites/exemple.net

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 notamment le cas si vous souhaitez gérer plusieurs sites Web personnels sur votre propre serveur via une ligne DSL. L'hébergement virtuel basé sur le nom est utile car la plupart des navigateurs réputés (et la quasi-totalité des navigateurs 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

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 correspondance, 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 ServerName www.exemple.com ServerAlias exemple.com Web.exemple.com DocumentRoot /usr/local/Apache/sites/exemple.com ServerName www.exemple.net DocumentRoot /usr/local/Apache/sites/exemple.net

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 *

91

92


Bien entendu, vos serveurs DNS doivent être correctement 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ébergement virtuel basé sur le nom, c'est le premier hôte virtuel 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 * ...

Nous l'avons indiqué dans la section précédente, c'est le premier hôte virtuel présent dans le fichier de configuration qui répond aux requêtes du domaine non explicitement 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 ?

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 ServerName default.exemple.com DocumentRoot /usr/local/Apache/sites/default AliasMatch /* /default.html

Configurer un hôte virtuel par défaut basé sur IP ServerName default.exemple.com DocumentRoot /usr/local/Apache/sites/default

La syntaxe spéciale _default_ permet de définir un hôte virtuel 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

93

94


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 : SSLEngine on ServerName secure.exemple.com:443 DocumentRoot /usr/local/Apache/sites/default ...

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éparé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 ServerName www.exemple.com DocumentRoot /usr/local/Apache/sites/exemple.com ServerName staging.exemple.com DocumentRoot /usr/local/Apache/sites/staging

Débogage des configurations d'hôtes virtuels

ServerName www.exemple.net DocumentRoot /usr/local/Apache/sites/exemple.net

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 complexes. 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 (/usr/local/www/conf/httpd.conf:1055) port * namevhost exemple.org (/usr/local/www/conf/httpd.conf:1082) port * namevhost exemple.net (/usr/local/www/conf/httpd.conf:1094) Syntax Ok

95

96


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. Reportez-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 ellemê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 chemin). 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

basé sur le nom d'hôte référencé dans la requête. Si un utilisateur envoie une requête pour /manual/index.html sur l'hôte www.exemple.com, cette directive sera mise en correspondance avec /usr/local/Apache/vhosts/www.exemple.com/ manual/index.html. De la même manière, vous pouvez effectuer la correspondance 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épertoire 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/.

97

98


Le Chapitre 11 traite de plusieurs modules de multitraitement (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 plusieurs 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 configurations. De plus, puisque les fichiers sont analysés à la volée, le serveur n'a pas à être redémarré après chaque modification. Inconvénient : cette opération pénalise les performances. En effet, Apache doit procéder à des opérations lourdes sur disque pour rechercher ces fichiers dans chaque 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

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 documents. b Indexes. Directives contrôlant l'indexation du répertoire. b Limit. Directives de contrôle de l'accès à l'hôte. b Options. Directives contrôlant les fonctions spécifiques 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épertoire pour cette arborescence de répertoires.

99

100


Désactivation des fichiers de configuration par répertoire AllowOverride None

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 performances 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 certaines zones) du site Web soit accessible aux clients provenant d'une plage d'adresses particulière, d'une part, et que ceux-ci fournissent, par exemple, un nom d'utilisateur et un mot de passe valables, d'autre part. Le contrôle d'accès peut être implémenté à divers niveaux : notamment 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 modules Apache intégrés. Il explique également en quoi les diffé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 mentionné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 visibles 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

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'utilisateur 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 malveillante pourrait facilement espionner la conversation entre le serveur et le navigateur, intercepter le nom d'utilisateur 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 renvoie un autre qui identifie uniquement le texte d'origine.

103

104


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 Order Allow, Deny Allow from 192.168.0 exemple.com Deny from guest-terminal.exemple.com

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'évaluation 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

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îtriser une fois que vous avez compris comment sont évalué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

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 authentification 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 contextuelle séparée). AuthUserFile pointe vers la base de données utilisateur. Enfin, la directive Require spécifie un utilisateur auquel sera accordé un accès en cas d'authentification 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'utilisateur et sur IP, comme indiqué à la section "Combinaison des méthodes de contrôle d'accès".

105

106


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épertoire 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

Emploi de Require pour autoriser des utilisateurs et des groupes AuthType Basic AuthName "Password Protected Area" AuthUserFile /usr/local/apache2/conf/htusers AuthGroupFile /usr/local/apache2/conf/groups Require group administrators

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 arguments de Require : Require user idutil1 idutil2

En revanche, si vous disposez d'un grand nombre d'utilisateurs, 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 utilisateurs ayant réussi à s'authentifier et appartenant au groupe administrators. Dans cet exemple, il s'agirait des utilisateurs admin et patron.

107

108


Gestion d'un grand nombre d'utilisateurs AuthType Basic AuthName "Zone privee" AuthDBMUserFile /usr/local/apache2/conf/dbmusers AuthDBMGroupFile /usr/local/apache2/conf/dbmusers AuthDBMAuthoritative on Require group student faculty

Le module mod_auth_dbm équivaut, en termes de fonctionnalité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 directives, 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 Allow from 192.168.0

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

d'un réseau interne. Cet exemple donne accès au répertoire /usr/local/apache2/htdocs/private et à ses sous-répertoires 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éralement 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'adresses IP. Consultez la référence de la directive pour en savoir plus. Vous pouvez également autoriser l'accès à quelques adresses IP spécifiques seulement, qui utilisent le même code, dans un fichier .htaccess, à l'adresse /usr/local/apache2/ htdocs/private : Order Allow,Deny Allow from 192.168.0

Refuser l'accès à des adresses IP spécifiques Order Deny,Allow Deny from 192.168.0.2 192.168.0.5

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.

109

110


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 Allow from 192.168.200.0/255.255.255.0 AuthType Basic AuthUserFile /usr/local/apache2/conf/htusers AuthName "Ressource restreinte" AuthAuthoritative on Require valid-user Satisfy any

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 utilisateurs 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

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'attention 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 chemin 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 oblique (/), 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

111

112


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 exemple, 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) ignorent 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écifier 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 connaissances 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éjudice 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 chaque 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 propres contrôles d'accès et directives liées aux autorisations.

Refus d'accès aux fichiers système et sensibles

A l'inverse, vous pouvez interdire les changements de configuration par répertoire, grâce au paramètre global suivant : AllowOverride none

Cela présente comme autre avantage d'améliorer les performances. 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 Order allow,deny Deny from all

Il existe certains types de fichiers auxquels les visiteurs ne doivent pas avoir accès, quelles que soient les circonstances, 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.

113

114


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 activer 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ésactivé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 uniquement, et notamment pas par l'utilisateur sous lequel Apache 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

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 comportement indélicat consomme trop de ressources. Ces méthodes 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

Apache permet de définir des fichiers d'index spéciaux, avec la directive DirectoryIndex. Lorsqu'une requête réalisée par un client correspond à un chemin de répertoire,

115

116


Apache recherche l'un de ces fichiers d'index (généralement nommés index.html ou accueil.html) et le renvoie au navigateur. Si aucun fichier n'est trouvé, Apache renvoie 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 souhaitez 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ésactivant 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)

sécurité supplémentaire. En effet, la plupart des outils d'analyse et d'attaque automatisés ignorent ces informations ; 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 programmes 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énomène, appelé hotlinking (vol de bande passante), peut être contré. Vous pouvez empêcher que des utilisateurs ne se connectent à vos images en exigeant que ce type de requête provienne 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 RewriteRule) dont l'en-tête HTTP_REFERER ne correspond pas à votre nom de domaine (première ligne RewriteCond). En outre,

117

118


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 AllowOverride FileInfo AuthConfig Limit Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec Order allow,deny Allow from all Order deny,allow Deny from all

Vous pouvez contrôler l'accès à votre serveur en fonction de la méthode HTTP de la requête, à l'aide des directives et . 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 modifier le contenu du système de fichiers, comme PUT. La section 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 permet l'accès par défaut aux méthodes HTTP

Restriction d'accès basée sur le type du navigateur

qui sont en lecture seule, comme GET et POST. La section 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 utilisateurs à administrer leur propre contenu (voir Chapitre 8).

Restriction d'accès basée sur le type du navigateur SetEnvIf User-Agent ^EvilSearchEngine broken_crawler Order Deny,Allow Deny from env=broken_crawler

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'environnement, avec Allow et Deny. Dans ce cas, l'accès sera refusé pour les navigateurs disposant d'un en-tête User-Agent commençant par EvilSearchingEngine, 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 souvent, les en-têtes étant envoyés par le client, ils ne peuvent donc pas être totalement fiables.

119

120


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 sera toujours évaluée après une directive Allow (ou Deny) apparaissant dans une section ou un fichier .htaccess, quel que soit le paramètre de la directive Order. Prenez en compte que les liens symboliques et les directives Alias peuvent affecter le paramétrage de l'authentification. Les restrictions peuvent ainsi être contournées si les directives de contrôle d'accès sont placées dans une section , 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 utilisateurs par rapport à un répertoire LDAP. b mod_ssl. Ce module permet d'utiliser une authentification du client basée sur un certificat (voir Chapitre 7).

Autres modules d'authentification

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 informations 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'utilisateur 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 portail 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érations 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 transversal. Vous en saurez plus sur ce module en vous rendant à l'adresse http://www.modsecurity.org.

121

122


Apache 2.2 AuthType Basic AuthName "Restricted Access" AuthBasicProvider file ldap AuthUserFile /usr/local/apache2/conf/htusers AuthLDAPURL ldap://exemple.com/o=Sample Require valid-user

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 clairement 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 donné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 fonction 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 configurations d'authentification complexes pouvant être référencé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

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 également 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.

123

124


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 transformer 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ésactivez 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 navigateur 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

De plus, dans Apache 1.3, vous pouvez désactiver explicitement 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éveloppement 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 correctement la saisie de l'utilisateur. Ces inconvénients permettent 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éveloppement 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 capacité à exécuter des scripts à des répertoires spécifiques.

125

126


Par exemple, vous pouvez analyser votre configuration à la recherche des directives ScriptAlias et Options avec les arguments ExecCGI et vous assurer qu'elles sont correctement 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 fonctionnalité 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'identifiant 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 configuration, 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écutables 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

Limiter ou désactiver la fonctionnalité de proxy Comme avec les CGI, vous devez désactiver ou restreindre 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 configuration suivant, tiré de la documentation Apache, montre comment procéder : Order Deny,Allow Deny from all Order Deny,Allow Allow from all

Consultez les sections précédentes pour savoir comment désactiver les listings de répertoires.

127

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 problè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 communications entre deux points d'extrémité, généralement un serveur 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 certificat du serveur. Un certificat est une donnée électronique qui décrit l'identité d'un point d'extrémité dans la communication SSL (voir plus loin). La validité du certificat est alors testée.

Compilation d'OpenSSL

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 processus 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 proposent à 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 cryptographiques de base employées par mod_ssl, ainsi que des utilitaires de ligne de commande pour créer et manipuler des certificats de serveur.

131

132


Vous pouvez télécharger une version du binaire Windows, dans la section des binaires du site Web OpenSSL, à l'adresse http://www.openssl.org. La plupart des systè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 disponible 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 distribution 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 destinataire 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

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 donné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

133

134


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 émettant cette commande. Cela présentant certains risques pour la sécurité, veuillez consulter la section "SSLPassPhraseDialog".

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. Comment, en effet, pouvez-vous authentifier des correspondants 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

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 concernant son propriétaire, par exemple un nom et une adresse. Les certificats sont signés numériquement avec la clé privé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 Explorer, 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'utilisateur 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.

135

136


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 []:[email protected] 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" correspond à 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 distant. 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

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 organismes. 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 connues, mais il existe aussi d'autres autorités communautaires, 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.exemple.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

137

138


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 raisons historiques liées aux restrictions d'exportation sur la cryptographie, la version Apache 1.3 est distribuée séparé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

Cela est réalisé dans le cadre du processus de construction mod_ssl, présenté au Listing 7.1. L'exemple construit Apache 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 Chapitre 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.

139

140


Compilation de la prise en charge SSL dans Apache 2.x Apache 2 étant sorti après les réglementations d'exportation 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 autosigné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 ServerName www.exemple.com SSLEngine on SSLCertificateFile \ /usr/local/ssl/openssl/certs/www.exemple.com.cert SSLCertificateKeyFile \ /usr/local/ssl/openssl/certs/www.exemple.com.key

Démarrage d'Apache avec prise en charge SSL

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 SSLCertificateFile et SSLCertificateKeyFile pointent vers le certificat 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 . 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é Apache en tant qu'utilisateur ordinaire, il est possible qu'il ait été configuré pour écouter par défaut sur le port 8443.

141

142


Comme expliqué au Chapitre 2, le port 443 est un port à privilèges et il n'est accessible que par le superutilisateur. Vous pouvez tester l'installation en accédant au serveur, à l'adresse https://www.exemple.com (ou https://www.exemple.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émarrage. Vous pouvez contrôler ce comportement avec SSLPassPhraseDialog. Sa valeur par défaut, builtin, signifie 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 manuellement le mot de passe à chaque redémarrage). Attention, cependant ! Dans ce cas, si le serveur rencontre un problème, il en ira de même pour la clé. Vous pouvez également 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 davantage de sécurité que si vous laissiez la clé sans protection (mais pas beaucoup plus).

Amélioration des performances SSL

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 simultané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.

143

144


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 ServerName private.exemple.com Redirect / https://private.exemple.com/

Si vous disposez d'un site Web particulier qui ne doit être desservi que par SSL, vous pouvez utiliser un Redirect dans une section 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 utilisateurs 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 virtuels 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

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 connecter 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 valables. Vous devrez modifier certains paramètres dans vos bases de données utilisateur.

145

146


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 utilisateurs voient s'afficher une fenêtre contextuelle d'avertissement 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 certification 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 première étape consiste à créer une CA racine. Pour cela, utilisez 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

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 navigateur. 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 validation SSL pour les clients. Cette directive SSLVerifyClient exige des clients qu'ils fournissent un certificat valide pour

147

148


pouvoir se connecter. SSLCACertificateFile fournit le chemin 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 commerciales, 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

détails sur le protocole SSL et le certificat de serveur pour la connexion. Vous pouvez également émettre une commande 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'environnement peuvent être réglées pour forcer des comportements spécifiques. Cela est particulièrement utile si vous disposez 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.

149

150


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} = 8 and %{TIME_HOUR} open http://exemple.com

Plusieurs clients à la ligne de commande sont disponibles pour accéder aux ressources activées par DAV, ce qui simplifie l'interactivité et l'intégration dans des scripts administratifs. 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

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.

163

164

CHAPITRE 8 Publication de contenu avec DAV

sitecopy permet de maintenir la synchronisation entre

une arborescence de documents locale et un serveur distant, à 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'anciennes versions de dossiers virtuels Gnome, et que vous obteniez 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 WebDAV. 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 variable 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

mod_speling et DAV Si vous utilisez DAV, vous devrez obligatoirement désactiver mod_speling. En effet, ce module interfère avec plusieurs 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 DAV On ForceType text/plain

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.

165

166


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 concordance 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 configuration 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 disabled, 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

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 utiliser mod_rewrite pour faire concorder des requêtes destinées à utilisateur.exemple.com au répertoire HTML par utilisateur qui convient.

167

168


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 contenant 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 chemin 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 risquent 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é proviennent généralement du moteur de génération de contenu dynamique ou de la couche de la base de données, et non du serveur Web Apache lui-même. A noter que certains 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écifiques à 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 performances permettent de répondre plus rapidement aux requêtes, tandis que l'évolutivité consiste à desservir un grand nombre 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

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 performances 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'évolutivité des serveurs Web basés sur les processus. Ce type de machine est recommandé pour les hébergements de charges 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.

171

172


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 nombre de connexions simultanées au serveur Web, ce qui réduit ensuite le nombre de visiteurs auxquels vous pouvez 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 systè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 processus, analogue pour le système d'exploitation. Sous Solaris, ces paramètres peuvent être modifiés dans le fichier /etc/system. Ces modifications n'exigent pas de reconstruire 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

de processus en modifiant l'entrée max_nprocs et le nombre 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'exploitation 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 systè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émarrage pour prendre effet. Vous trouverez des informations complémentaires à l'adresse : http://httpd.apache.org/docs/misc/descriptors.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.

173

174


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 malveillants ou mal écrits ne soient hors de contrôle.

Amélioration des performances 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

Gestion de liens symboliques

traitent de certains des paramètres que vous pouvez personnaliser 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 systè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 lourdement 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

175

176


offrent un accès indésirable à des parties de votre système de fichiers. Par exemple, vous pouvez créer un lien symbolique, à 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 SymLinksIfOwnerMatch 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 directive 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 AllowOverride none

Nous l'avons vu aux précédents chapitres, les fichiers de configuration par répertoire offrent une manière commode 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 document desservi. Vous pouvez désactiver cette fonction en ajoutant AllowOverride à votre configuration.

Gestion de liens symboliques

Configurer la négociation du contenu Nous l'avons vu à la section "Configuration de la négociation 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, Apache doit accéder au système de fichiers à plusieurs reprises, à la recherche de fichiers possédant les extensions appropriées. Si vous devez utiliser la négociation du contenu, assurez-vous au moins d'utiliser un fichier de correspondance 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 directive 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.

177

178


Personnalisation du réseau et des paramètres de statut Plusieurs paramètres Apache liés au réseau peuvent dégrader 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 toujours 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écifique 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

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 obtenir 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 performances. 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

179

180


(en secondes) pendant lequel le serveur attend avant de terminer une connexion inactive. Augmenter la temporisation 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édemment. La directive MaxKeepAliveRequest permet de spécifier 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 ralentit 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 bloquer 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 nombre de connexions simultanées. Vous pouvez également

Restriction des connexions et de la bande passante

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 plusieurs directives permettent de contrôler la taille du corps de la requête et des en-têtes : LimitRequestBody, LimitRequestFields, 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 performances 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 ensemble 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écifique, le nombre de requêtes simultanées, etc. Le module mod_bandwidth d'Apache 1.3 autorise le paramé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.

181

182


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 trouverez 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 simultané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

Gestion des robots http://www.robotstxt.org/

Les "robots du Web" désignent une catégorie de programmes 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 programmes pour parcourir Internet à la recherche de serveurs 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 connexion ultérieurement. Généralement, ces programmes se comportent bien, mais ils peuvent parfois être très agressifs 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.

183

184


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 charges sur plusieurs serveurs Web correspond à l'évolutivité horizontale. Dans cet ensemble d'architectures, vous pouvez 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 statique 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émentent 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 disponibles.

Mise en cache et compression

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 ressources demandées. De cette manière, certaines ressources qui figurent sur plusieurs pages mais ne sont pas souvent modifié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 images. Vous pouvez automatiser une partie du traitement en employant les outils de ligne de commande ImageMagick (http://www.imagemagick.org). De plus, vous pouvez 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 filtrage 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 processus sera libéré plus tôt pour répondre aux autres requêtes.

185

186


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 modules 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 chapitre 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 permet 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ésormais considérée mature.

Activation de la prise en charge de mod_proxy

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 transiter 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 Order deny,allow Deny from all Allow from 10.0.0.0/255.255.255.0

189

190


Les proxy ordinaires ont connu une grande popularité aux premiers jours d'Internet, puisqu'ils permettaient à plusieurs machines de partager facilement une connexion 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érablement réduit les besoins de proxy ordinaires. De nos jours, ils sont plus souvent implémentés dans des entreprises 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 à changer. A mesure que se multiplient les virus et les logiciels espion, les entreprises mettent en place des proxy de filtrage qui éliminent ces menaces avant qu'elles ne parviennent 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 ordinaires 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 Chapitre 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

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-guichet 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 application, il leur faut taper une adresse différente. Vous pouvez 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 , ainsi que le montre l'exemple suivant : ProxyPass http://crm.exemple.com/

Au final, vous pourrez utiliser ProxyPass simultanément avec ProxyPassReverse, décrit à la section suivante.

191

192


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 ProxyPassReverseCookiePath 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 serveur proxy, remplaçant ainsi les pages d'erreur reçues de l'arrière-guichet. Cela permet de mieux masquer l'existence 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

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.

Amélioration des performances 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 connexion au serveur à la fin d'une transmission. On appelle ce phénomène un "problème de fermeture persistante".

193

194


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 quelques 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 desservir 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 pouvez 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

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 optimisé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 éventuellement faire les authentifications basées sur des certificats 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 ressources) 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 correspondre au nom d'hôte spécifié dans la directive ProxyPass. 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.

195

196


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 Header, fournie par le module mod_headers. Ce module peut être utilisé pour ajouter ou supprimer des en-têtes arbitraires 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 montré 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

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'environnement dans l'argument headervalue, à l'aide de la chaîne de format %{nomvariable}e. Ce fonctionnement est semblable à celui de la directive LogFormat (voir Chapitre 3, "Journaux et surveillance"). Par exemple, vous pouvez l'utiliser pour transmettre des informations sur une connexion 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'environnement, 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 fonctionnalité 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.

197

198


CacheGcInterval permet de spécifier la fréquence (en heures) à laquelle le cache sera périodiquement "purgé", afin d'être en adéquation avec le réglage CacheSize. CacheMaxExpire spécifie le temps maximal pendant lequel un document peut rester dans le cache et être toujours considé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-guichet 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 possible de recourir à l'utilitaire de ligne de commande htcacheclean, afin de réduire le cache à intervalles prédéfinis lors de l'utilisation de l'arrière-guichet disk.

Equilibrage des charges

De même, si certains de vos fichiers sont fréquemment demandés et si vous savez qu'ils ne changeront pas pendant la durée de vie du serveur, vous pouvez utiliser mod_file_cache pour dire à Apache de mettre en correspondance les fichiers spécifiques en mémoire ou de mettre 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 SetHandler balancer-manager Order deny,allow Deny from all Allow from localhost BalancerMember http://www1.exemple.com/ BalancerMember http://www2.exemple.com/ BalancerMember http://www3.exemple.com/ ProxyPass /content balancer://balancer/

Disponible depuis Apache 2.2, mod_proxy inclut un nouvel 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 protocoles 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.

199

200


Une fois défini, vous pouvez utiliser l'ID du système d'équilibrage avec une directive ProxyPass régulière. Chaque identifiant et élément du système d'équilibrage peut prendre des options pour spécifier des stratégies d'équilibrage (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 configuration, à l'aide de la commande régulière status, et la manipuler, à 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èreguichet 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 remplacer 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 configuration 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

Autres proxy Squid http://www.squid-cache.org/ Pound http://www.apsis.ch/pound/

Nous l'expliquions au Chapitre 9, "Performances et évolutivité", Apache n'est pas forcément le meilleur choix dans tous les scénarios. Il existe ainsi plusieurs autres serveurs 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'Apache. 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 "transparents". Ces machines interceptent les requêtes HTTP au niveau de la couche réseau. Ensuite, de manière "transparente", 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 organisations 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").

201

202


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 système d'exploitation. Pour plus d'informations sur la configuration 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 fonctionnalités avancées. De même, des modules existants peuvent 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 desservent 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 facteurs (dont la prise en charge de modules et de fonctionnalité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 traitement 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. Actuellement, 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 plusieurs 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épendamment des autres. Cette approche présente l'avantage

Configuration de MPM Prefork

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'exploitation 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. Apache 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 possibles (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 serveurs à 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é.

205

206


MaxClients permet de contrôler le nombre maximal de

processus engendrés, dans la limite des capacités du système d'exploitation ou en fonction du nombre maximal d'enfants possibles. Dans Apache 1.3, le nombre maximal d'enfants possible est codé en dur à 256. Pour modifier cette valeur, vous devez intervenir sur le réglage HARD_SERVER_LIMIT dans httpd.h, puis recompiler le serveur. 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 serveurs 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 directive 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 processus ne soient arrêtés après un nombre défini de requêtes.

MPM basés sur des threads et MPM hybrides

MPM basés sur des threads et MPM hybrides Les threads sont semblables aux processus, mais ils peuvent 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éveloppeurs d'Apache ont créé un MPM basé sur des threads, MPM Worker, qui autorise une approche mixte. Un serveur peut engendrer différents processus, chacun contenant plusieurs threads.

Configuration de MPM Worker StartServers 2 MaxClients 150 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0

Le MPM Worker est un MPM Apache 2 qui permet de combiner les processus et les threads. Vous pouvez spécifier 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.

207

208


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 contreparties 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 maximal de processus. Dans le MPM Worker, chaque processus 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

é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 alternative à 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 SetOutputFilter INCLUDES;PHP 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, AddOutputFilterByType peut être utilisé pour associer des filtres à des types de fichiers spécifiques.

209

210


Si plusieurs directives, comme AddOutputFilter et SetOutputFilter, 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 AddInputFilter, 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 FTP On DocumentRoot /usr/local/apache/ftpdocs ErrorLog /usr/local/apache/logs/ftp_error_log AuthName "FTP" AuthType basic AuthUserFile /usr/local/apache/conf/htusers Require valid-user

Comme indiqué précédemment dans ce chapitre, Apache 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 infrastructure 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

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 activer 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 fonctions 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 POP3Protocol on POP3MailDrops /usr/local/apache/pop AuthUserFile /usr/local/apache/conf/htusers AuthName pop3 AuthType Basic Require valid-user

Ce module permet à Apache 2 d'agir comme serveur POP3. POP3 (Post Office Protocol, version 3) est fréquemment 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.

211

212


Sachez que ce module n'autorise pas les systèmes de lecture 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 utilisateurs. L'utilisateur sous lequel Apache s'exécute doit pouvoir 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 considérablement compressé, comme avec les pages HTML.

Compression de contenu à la volée

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 fonctionne, 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 traiter un contenu compressé d'un certain type, vous pouvez paramétrer la variable d'environnement no-gzip, en utilisant 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/.

213

215

Index A

INDEX

AcceptFilter 179 Accès contrôler 101, 104, 110, 150 interdire 43, 109 limiter 108, 119 protéger 115 protéger pour DAV 157 refus 111 refus pour les fichiers sensibles 113 serveur 127 access_log 46 AccessFilename 99 Action 68, 71 Activation d'un proxy 189 AddDefaultCharset 80 AddHandler 68 AddModule 18 Adresse IP autoriser l'accès 108 consigner 56 déjà utilisée 34 interdire l'accès 109 modifier 14 résoudre 56 Affectation jeux de caractères 80 langue 80 Affichage du contenu d'une requête 137 Alias 64

AliasMatch 17, 64 Allow 104, 119 AllowOverride 99 Amélioration évolutivité 170 performances 170, 193 Analyse du journal 53 Apache authentification 122 autres solutions 186 caractéristiques 3 enfants 205 installation 5 sous UNIX et Linux 6, 7 sous Windows 8 POP3 211 versions 4 apachetop 53 Application, authentification 121 apxs 19 Architecture Apache 203 Archivage des journaux 55 Arguments FollowSymLinks 175 SymLinksIfOwnerMatch 175 Arrêt du serveur 12 serveur 32 Arrière-guichet CONNECT 189 FTP 189 HTTP 189 masquer 192

INDEX

216

Authentification

Authentification 102, 105 Apache 2.2 122 application 121 certificats 147 de base 103 digest 103 modules 120 processus 102 AuthGroupFile 107 AuthName 105 AuthType 105 AuthUserFile 105 Autorisation 105 fichier 126 Require 107 Autorité de certification 134, 146 Auto-signé, certificat 137 Avertissement (accès par SSL) 146

B Bande passante restreindre 181 vol 117 bandwidth_share 182 Barre oblique finale 81 Base de données consigner dans 54 utilisateur 106 BindAddress 15 Bogues clients 164 contourner pour SSL 149 BrowserMatch 76 BufferedLogs 177

C CA 134 Cache 185 Apache 2 198 mise en 188 mod_cache 198 proxy 197 cadaver 162 Caractères, jeux de 80 Carte (cryptographie) 144 Casse, problèmes de 83 Certificat 130, 134 authentifier 147 auto-signé 137 créer 146 importer 147 requête de signature 135 CGI améliorer les performances 72 dépannage 72 exécutables 70 exécution 69 Charges (équilibrage) 199 Clé cryptage 132 cryptographie symétrique 132 openssl 133 paire 133 privée 132 protégée 134 publique 132, 134 supprimer le mot de passe 134 ClearModuleList 18 Client comportant des bogues 164 préférences 77

DAVLockDB

dynamique et DAV 165 gestionnaire 67 négociation 77 publier 20, 151 Contrôle accès 101, 104, 110, 119, 150 processus externes 173 Correction URL erronée 82 Correspondance de type 79 Création base de données utilisateur 106 CA 146 certificat client 146 icône 16 Cryptage 132 Cryptographie asymétrique 132 carte 144 clé publique 132 symétrique 132 CustomLog 48, 59

D DAV 153 accès depuis Firefox 161 accès depuis la ligne de commande 162 accès depuis Office 158 accès depuis Windows 159 cadaver 162 configurer 156 contenu dynamique 165 mod_speling 165 protéger l'accès 157 sécuriser la configuration 157 sitecopy 164 DAVLockDB 168

INDEX

Commande configure 18 killall 32 status 200 ulimit 171 Compilation (SSL) 140 Compression des données sortantes 212 Configuration désactiver les fichiers 100 fichier principal 9, 10 fichiers multiples 11 fichiers par répertoire 98 hébergement virtuel 89, 91 hôte virtuel 92, 93 minimale 140 négociation du contenu 78 sécuriser pour DAV 157 SSI 74 tester 29 WebDAV 156 configure, commande 18 CONNECT 189 Connexion démon du journal système 27 restreindre 181 serveur 41 surveiller 50 Tomcat 200 Consignation adresses IP 56 conditionnelle 49 désactiver 177 format combiné 48 format commun 47 requête 46 vers une base de données 54 Contenu configurer la négociation 177 desservi par SSL 144

217

INDEX

218

Débogage

Débogage 33 hôtes virtuels 95 mod_logio 33 mod_loopback 33 mod_tee 33 mod_trace_output 33 Déchargement (SSL) 195 Décryptage 132 _default_ 93 DefaultLanguage 80 Démarrage avec SSL 141 du serveur 12 serveur 41 Démon (journal système) 27 Deny 104, 119 Dépannage 33 accès interdit 43 connexion au serveur 41 démarrage du serveur 41 document introuvable 42 erreur interne 44 scripts CGI 72 Désactivation consignation 177 exécution CGI 125 exécution SSI 125 fichiers de configuration 100 fichiers de configuration par répertoire 176 listings de répertoire 115 Descripteur de fichier 173 Digest, authentification 103 Directives 11 AcceptFilter 179 AccessFilename 99 Action 68, 71 AddDefaultCharset 80 AddHandler 68 AddModule 18

Alias 64 AliasMatch 17, 64 Allow 104, 119 AllowOverride 99 AuthGroupFile 107 AuthName 105 AuthType 105 AuthUserFile 105 BindAddress 15 BrowserMatch 76 BufferedLogs 177 ClearModuleList 18 CustomLog 48, 59 DefaultLanguage 80 Deny 104, 119 DirectoryIndex 115 DirectorySlash 82 DocumentRoot 20, 89 ErrorDocument 93, 111 ErrorLog 26 ExtendedStatus On 51 Group 15 Header 196 HostNameLookups 56 Include 11 KeepAliveTimeout 179 LanguagePriority 80 Listen 14, 141 LoadModule 17, 20, 155 LogFormat 46 LogLevel 27 MaxRequestsPerChild 206 MaxSpareServers 206 MinSpareServers 206 NameVirtualHost 91 Options 114 Options +ExecCGI 70 Options +Multiviews 78 Order 104, 120 PassEnv 75

Event

Document introuvable 42 DocumentRoot 20, 89

E Echec de la redirection 67 En-tête fin prématurée 39 Host 90, 195 malformé 39 manipuler 196 proxy 196 Server 116 Entrée de journal 60 Environnement, variables 74 accéder à 75 paramétrer 75 spéciales 76 Equilibrage des charges 199 Erreur adresse déjà utilisée 34 de segmentation 38 de syntaxe 34 en-tête malformé 39 fin prématurée d'en-tête 39 interne 38, 44 journal 26 journalisation 40 liaison impossible 35 module non compatible 35 niveau 27 ouverture de fichier 36 quantité d'informations 27 redirection 40 refus d'accès 37 résolution de nom 36 error_log 46 ErrorDocument 93, 111 ErrorLog 26 Event 208

INDEX

POP3Protocol On 212 Port 15 ProxyPass 191 ProxyPassReverse 192 ProxyRequests 190 Redirect 65 RedirectMatch 66 RemoveHandler 68 RequestHeader 197 Require 105 RLimitCPU 174 RLimitMem 174 RLimitNProc 174 Satisfy 110 Satisfy all 110 Script 71 ScriptAlias 70 ScriptLog 72 sections 22, 23 ServerName 16, 89 ServerRoot 11 ServerTokens 116 SetEnv 74 SetEnvIf 75 SetFilter 84 SetHandler 68 SSLCryptoDevice 144 SSLEngine 141 SSLRequire 150 SSLVerifyClient 147 StartServers 205 TimeOut 181 TransferLog 48 UnsetEnv 75 User 15, 126 VirtualDocumentRootIP 97 VirtualScriptAliasIP 97 DirectoryIndex 115 DirectorySlash 82 Disque, vitesse 170

219

220

Evolutivité du système

Evolutivité du système 170 Exécution désactiver CGI 125 SSI 125 restreindre de programmes 114 Exemples, supprimer 125 Expression régulière 66 Expressions régulières 22 ExtendedStatus On 51

INDEX

F FastCGI 73 Fautes de frappe, corriger 82 favicon.ico 16, 60 Fichier améliorer les performances du système 174 configuration 9, 10, 11 configuration par répertoire désactiver 176 favicon.ico 16, 60 htaccess 98 httpd.pid 61 journal 46 robots.txt 60 sensibles refuser l'accès 113 vérifier les autorisations 126 Filtres 209 Firefox, accès à DAV 161 FollowSymLinks 175 Format combiné 48 consignation 47 FTP 189 Fusion de journaux 58

G Gestionnaire contenu 67 Graceful, redémarrage (en douceur) 14 Group 15

H Header 196 Hébergement virtuel 87 sur IP 88, 89 sur le nom 90, 91 Host 90 en-têtes 195 HostNameLookups 56 HostnameLookups 178 Hôte journal 59 mélanger 94 SSL 96 virtuel sur IP 93 sur le nom 92 virtuels 96 déboguer 95 SSL 144 Hotlinking 117 htaccess 98 htpasswd 106 HTTP 189 et WebDAV 154 proxy transparent 201 restreindre les méthodes 118 httpd.pid 61 HTTPS130

lsof

I Icône, créer 16 ImageMagick 185 Images hotlinking 117 Importation certificat 147 Include 11 Informations sécurité 123 Installation 5 mod_dav 155, 156 sous UNIX et Linux 6, 7 sous Windows 8 Inverse, proxy 184, 188, 191

J

K KeepAliveTimeout 179 kill 32 killall 32

L LanguagePriority 80 Langue affecter 80 par défaut 80 Liaison impossible 35 Liens symboliques 175 Ligne de commande accès à DAV 162 cadaver 162 sitecopy 164 tester 30 Limiter proxy 127 refus de service 180 Limites système d'exploitation 171, 172 Liste de contrôle de sécurité 123 Listen 14, 141 Listing, désactiver 115 LoadModule 17, 20, 155 LogFormat 46 LogLevel 27 logresolve 57 lsof 31

INDEX

Jeux de caractères 80 Journal access_log 46 analyser 53 archiver 55 entrées communes 60 erreurs 26, 40 error_log 46 fichier 46 fusion 58 personnalisé 48 pour chaque hôte 59 quantité d'informations 27 rediriger 49 requête inhabituelle 61 rotation 55 séparation 58 surveillance en temps réel 53 système 27

221

222

Manipulation des en-têtes

INDEX

M Manipulation des en-têtes 196 Mappage URL 64, 81 Masquage des serveurs d'arrière-guichet 192 Matériel, personnaliser 170 MaxRequestsPerChild 206 MaxSpareServers 206 Mécanisme d'acceptation 178 Mélange d'hôtes 94 Méthode HTTP, restriction 118 MIME 68 configurer 69 MinSpareServers 206 Mise en cache 185, 188 mod_actions 71 mod_apache_snmp 52 mod_auth 157 mod_auth_dbm 108 mod_authn_alias 122 mod_autoindex 116 mod_backhand 184 mod_bandwidth 181 mod_cache 185, 198 mod_cgi 72 mod_choke 182 mod_dav 153 installer 155, 156 mod_deflate 185, 212 mod_dir 81 mod_filter 210 mod_ftp 211 mod_include 74 mod_log_spread 177 mod_logio 33 mod_loopback 33 mod_nocase 83 mod_perl 72 mod_proxy 197 mod_require_host 182

mod_rewrite 40, 81, 117, 167 mod_security 121 mod_snmp 52 mod_speling 82, 83, 165 mod_ssl 131, 138, 140, 148 mod_status 51, 179 mod_tee 33 mod_throttle 182 mod_trace_output 33 mod_tsunami 182 mod_userdir 166 mod_vhost_alias 97 mod_virtualhost_alias 96 Modification de site Web 152 Modules activer 18 ajouter sans recompilation 19 Auth 145 authentification 120 bandwidth_share 182 désactiver 18, 124 effacer la liste 18 hébergement virtuel 97 mod_actions 71 mod_apache_snmp 52 mod_auth 157 mod_auth_dbm 108 mod_authn_alias 122 mod_autoindex 116 mod_backhand 184 mod_bandwidth 181 mod_cache 185, 198 mod_cgi 72 mod_choke 182 mod_dav 153 mod_deflate 185, 212 mod_dir 81 mod_filter 210 mod_ftp 211 mod_include 74 mod_log_spread 177 mod_nocase 83

Performances

N NameVirtualHost 91 Navigateur, accès limité 119 Négociation configurer 78 contenu 77, 177 netstat 31 noatime 175 Nom de serveur 16

O Office, accès à DAV 158 openssl 132, 133, 135 Options 114 +ExecCGI 70 +Multiviews 78 noatime 175 Order 104, 120 Outils apachetop 53 apxs 19 ImageMagick 185 logresolve 57 lsof 31 netstat 31 openssl 132 ps 31 rotatelogs 55 vérifier le fonctionnement 31 vlogger 59 vmstat 170 Ouverture avec erreur 36

P Page par utilisateur 166 rediriger 65, 66 valider 84 Paire de clés 133 Paramètres HostnameLookups 178 PassEnv 75 Perchild 209 Performances améliorer 170, 193 CGI 72 RAM 170 SSL 143 système de fichiers 174 vitesse du disque 170

INDEX

mod_perl 72 mod_proxy 197 mod_require_host 182 mod_rewrite 40, 81, 117, 167 mod_security 121 mod_snmp 52 mod_speling 82, 83, 165 mod_ssl 131, 138, 140, 148 mod_status 51, 179 mod_throttle 182 mod_tsunami 182 mod_userdir 166 mod_vhost_alias 97 mod_virtualhost_alias 96 non compatible 35 rechercher 17 Robotcop 182, 183 Mot de passe clé 134 supprimer pour une clé 134 MPM 172, 203, 208 basé sur les processus 204 basé sur les threads 207 Event 208 Perchild 209 Prefork 205 sélectionner 204 Worker 207 Multiview 78

223

INDEX

224

Personnalisation

Personnalisation journal 48 matériel 170 refus d'accès 111 réseau 178 POP3 211 POP3Protocol On 212 Port 15 modifier 14 Pound 201 Préférences client 77 Prefork 205 Problèmes de casse 83 Processus externes contrôler 173 MPM 204 Programme, exécution restreinte 114 Protection de l'accès DAV 157 Protocole CGI 69 DAV 153 HTTPS 130 Proxy activer 189 de cache 197 en-têtes 196 HTTP transparents 201 inverse 184, 188, 191 limiter 127 ordinaire 188, 190 activer 190 Pound 201 Squid 201 URL 193 ProxyPass 191 ProxyPassReverse 192 ProxyRequests 190 ps 31 Publication contenu 20, 151

R RAM, augmenter 170 Redémarrage automatique 57 du serveur 12 en douceur (graceful) 14 Redirect 65 Redirection échec 67 erreur 40 expression régulière 66 journal 49 page 65, 66 RedirectMatch 66 Refus d'accès 37 personnaliser 111 de service 180 RemoveHandler 68 Répertoire fichiers de configuration 98 listings 115 Répertoire utilisateur 167 RequestHeader 197 Requête afficher le contenu 137 consignation conditionnelle 49 consigner 46 inhabituelle 61 signature 135 Require 105, 107 Réseau, personnaliser 178 Résolution adresses IP 56 de nom 36 de problèmes avec DAVLockDB 168 Ressources ( CGI exécutables) 70 Restriction bande passante 181 connexions 181

SSL

RLimitCPU 174 RLimitMem 174 RLimitNProc 174 Robotcop 182, 183 Robots 183 robots.txt 60, 183 rotatelogs 55 Rotation des journaux 55

S

INDEX

Satisfy 110 Satisfy all 110 Script 71 CGI 69 ScriptAlias 70 ScriptLog 72 Sections 21 conditionnelles 23 directives 22, 23 emplacement 120 répertoires 120 VirtualHost 88, 89 Sécurisation configuration de DAV 157 serveur 114 SSL 129 Sécurité désactiver les modules 124 informations 123 liste de contrôle 123 Segmentation 38 Sélection du MPM 204 Séparation des journaux 58 ServerName 16, 89 ServerRoot 11 ServerTokens 116 Serveur arrêt 12 arrêter 32 configuration minimale 140

connexion 41 démarrage 12 démarrage avec SSL 141 en-tête 116 erreur interne 38 limiter l'accès 127 redémarrage 12 redémarrage automatique 57 restreindre l'envoi de contenu 114 sécurité 114 spécifier le nom 16 vérifier le fonctionnement 31 SetEnv 74 SetEnvIf 75 SetFilter 84 SetHandler 68 Signature afficher le contenu de la requête 137 requête 135 Site, modifier 152 sitecopy 164 SNMP 52 Squid 201 SSI 73 configurer 74 SSL 129 améliorer les performances 143 avertissement à l'accès 146 certificat 130 compiler 140 contourner les bogues 149 contrôle d'accès complexe 150 décharger 195 desservir le contenu 144 et démarrage 141 fonctionnement 130 hôtes virtuels 96 hôtes virtuels sur le nom 144 tester les sites 148

225

INDEX

226

SSLCryptoDevice

SSLCryptoDevice 144 SSLEngine 141 SSLPassPhraseDialog 142 SSLRequire 150 SSLVerifyClient 147 StartServers 205 status 200 stunnel 148 Suppression exemples de script 125 mot de passe d'une clé 134 Surveillance connexions 50 en temps réel 53 mod_status 51 SNMP 52 Symboliques, liens 175 SymLinksIfOwnerMatch 175 Syntaxe, erreur 34 Système d'exploitation augmenter les limites 171, 172 modifier les limites 172 Système de fichiers et noatime 175 Système, journal 27

T tail 54 Telnet, client 30 Test à la ligne de commande 30 configuration 29 sites SSL 148 Threads MPM 207 Tidy (validation des pages) 84 TimeOut 181 Tomcat, connexion 200

traceroute (tracert) 42 TransferLog 48 Type correspondances 79 MIME 68

U ulimit 171 UnsetEnv 75 URL auto-référentielle 16 en proxy 193 mappage 64, 81 User 15, 126 Utilisateur autoriser 112 base de données 106 modifier 15 nombreux 108 page personnelle 166 répertoires 167 Utilitaires htpasswd 106 kill 32 stunnel 148 tail 54 traceroute (tracert) 42

V Validation de pages 84 Variables d'environnement 74 accès 75 paramétrer 75 d'environnement spéciales 76 Versions 4

Worker

VirtualDocumentRootIP 97 VirtualHost 88, 89 VirtualScriptAliasIP 97 Virtuel hébergement 87, 88 basé sur le nom 90 configurer 89, 91 modules 97 hôte 96 configurer 92, 93 déboguer 95 vlogger 59 vmstat 170 Vol de bande passante 117

227

W WebDAV 152, 153 et HTTP 154 Windows, accès à DAV 159 Worker 207

INDEX

INDEX

228

Worker

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 et lignes de code pour amener un serveur Web 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 !

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

ISBN : 978-2-7440-4001-6

LE GUIDE DE SUR VIE

Apache

Apache

LE GUIDE DE SURVIE

Daniel Lopez

LE GUIDE DE SURVIE

Apache L’ESSENTIEL DU CODE ET DES COMMANDES

Lopez

11/05/09 15:38:50

Apache: L'essentiel du code et des commandes

Java: L'essentiel du code et des commandes

Futur des Retraites et Retraites du Futur

Espaces du droit et droits des espaces

Analyse des liquidites et theorie du portefeuille

Du vin et du haschisch

Performance des comites executifs : Jeu des affinites et du hasard

Apache: Phrase Book: Essential Code and Commands

Optimiser SQL Server : Dimensionnement, supervision, performances du moteur et du code SQL

Les Tuniques bleues, tome 43 : Des bleus et du blues

Parlons yipunu : Langue et culture des punu du Gabon-Congo

Netsukes Okimonos du Japon des XVIII et XIX siecles.Arts dAsie

Okimonos Netsukes du Japon des XVIII et XIX siecles

Okimonos Netsukes du Japon des XVIII et XIX siecles.Arts dAsie

L'univers du temps libre et des valeurs chez les jeunes

Théorie et Traitement du signal, tome 1 : Représentation des signaux et des systèmes - Cours et exercices corrigés

Fondements et limites du capitalisme

Des ruines du développement

EJB 3 : Des concepts à l'écriture du code - Guide du développeur

Le code mystérieux des pyramides

Technologie Des Ordinateurs Et Des Reseaux, Cours Et Exercices Corriges

La microstructure des aciers et des fontes : genèse et interprétation

Technologie des ordinateurs et des réseaux : Cours et exercices corrigés

Les Jumeaux Africains et leur Culte: Chansons des Jumeaux du Sud-Est du Katanga

Futur des Retraites et Retraites du Future Tome 2 : les Retraites du Futur: Capitalisation

Difficultés du français: des clés pratiques pour éviter et expliquer les pièges du français

Traite de psychologie du travail et des organisations, 2e edition revue et augmentee

Gestion budgétaire et dépenses publiques: Description comparée des processus, évolutions et enjeux budgétaires du Québec

Le dépistage du cancer colorectal : État des lieux et perspectives (Dépistage et cancer)

Apache Tomcat 6 - Guide d administration du serveur Java EE sous Windows et Linux

Apache: L'essentiel du code et des commandes

Java: L'essentiel du code et des commandes

Futur des Retraites et Retraites du Futur

Espaces du droit et droits des espaces

Analyse des liquidites et theorie du portefeuille

Du vin et du haschisch

Performance des comites executifs : Jeu des affinites et du hasard

Apache: Phrase Book: Essential Code and Commands

Optimiser SQL Server : Dimensionnement, supervision, performances du moteur et du code SQL

Les Tuniques bleues, tome 43 : Des bleus et du blues

Parlons yipunu : Langue et culture des punu du Gabon-Congo

Netsukes Okimonos du Japon des XVIII et XIX siecles.Arts dAsie

Okimonos Netsukes du Japon des XVIII et XIX siecles

Okimonos Netsukes du Japon des XVIII et XIX siecles.Arts dAsie

L'univers du temps libre et des valeurs chez les jeunes

Théorie et Traitement du signal, tome 1 : Représentation des signaux et des systèmes - Cours et exercices corrigés

Fondements et limites du capitalisme

Des ruines du développement

EJB 3 : Des concepts à l'écriture du code - Guide du développeur

Le code mystérieux des pyramides

Technologie Des Ordinateurs Et Des Reseaux, Cours Et Exercices Corriges

La microstructure des aciers et des fontes : genèse et interprétation

Technologie des ordinateurs et des réseaux : Cours et exercices corrigés

Les Jumeaux Africains et leur Culte: Chansons des Jumeaux du Sud-Est du Katanga

Futur des Retraites et Retraites du Future Tome 2 : les Retraites du Futur: Capitalisation

Difficultés du français: des clés pratiques pour éviter et expliquer les pièges du français

Traite de psychologie du travail et des organisations, 2e edition revue et augmentee

Gestion budgétaire et dépenses publiques: Description comparée des processus, évolutions et enjeux budgétaires du Québec

Le dépistage du cancer colorectal : État des lieux et perspectives (Dépistage et cancer)

Apache Tomcat 6 - Guide d administration du serveur Java EE sous Windows et Linux

Recommend Documents