Le serveur HTTP Apache
jouit d'une notoriété indiscutable dans le monde d'Internet. D'après
la société Netcraft,
qui étudie chaque mois les "parts de marché" des différents
type de serveurs Web, Apache domine largement ses concurrents avec une utilisation
sur plus de 60% des serveurs HTTP publics dans le monde. Ce succès est
non seulement dû à sa gratuité, mais également à
sa robustesse et à son extensibilité. Apache est également
une plate-forme de choix pour un intranet, et est très répandu
dans les universités et les écoles.
Actuellement en version 1.3.22, Apache connaît des développements
réguliers. Les plus grandes évolutions devraient venir de la version
2.0 (actuellement en bêta) qui apporte entre autres un support très
poussé des processus légers (threads) pour une meilleure efficacité
d'ensemble.
Pour installer Apache, décompactez tout d'abord les sources et placez-vous
dans le répertoire nouvellement créé :
# tar xvfz apache_1.3.22.tar.gz
# cd apache_1.3.22
Tout comme MySQL, Apache accepte un nombre conséquent de paramètres
lors de sa préconfiguration. Voici un exemple de commande, vous trouverez
le détail de ses paramètres ci-après :
# ./configure \
--prefix=/usr/local/apache-1.3.22 \
--htdocsdir=/data/www/html \
--cgidir=/data/www/cgi-bin \
--enable-module=rewrite \
--enable-shared=max
N.B. : les backslashes en fin de ligne permettent, en tapant sur la touche "Entrée",
de continuer la saisie de la commande à la ligne suivante et non pas
de la valider.
Quelques explications sur les options :
Tout d'abord, --prefix=/usr/local/apache-1.3.22 indique que l'ensemble
des composants d'Apache (binaires, modules, fichiers de configuration, etc.)
seront placés dans le répertoire /usr/local/apache-1.3.22 ou ses
sous-répertoires (bin, conf, libexec, etc.). Si vous souhaitez installer
Apache dans un autre endroit de votre arborescence, il suffit de jouer sur ce
paramètre.
Les paramètres --htdocsdir et --cgidir permettent de spécifier
des répertoires où les pages HTML et les programmes CGI seront
stockés. Pour info, si vous souhaitez placer les fichiers de configuration dans un endroit précis, vous pouvez spécifier le paramètre --sysconfdir=répertoire, comme par exemple --sysconfdir=/etc/apache-conf pour placer les fichiers de configuration dans le répertoire /etc/apache-conf.
Ensuite, --enable-module=rewrite spécifie d'ajouter le module
permettant la réécriture automatique d'URL (il n'est pas disponible
par défaut). Les modules de bases sont normalement suffisants et ne nécessitent
pas de librairies complémentaires. Vous pouvez choisir l'option --enable-module=all,
ainsi l'ensemble des modules complémentaires (authentification, redirection,
etc.) vont être compilés et seront actifs, c'est-à-dire
prêt à être chargés au besoin par Apache pour utiliser
leurs fonctions. Pour avoir l'ensemble des fonctionnalités, on préfèrera
en général l'option --enable-module=most qui ajoute et
active tous les modules sauf les suivants : auth_db (car tous les systèmes
n'ont pas la librairie db), mmap_static (toutes les systèmes n'ont pas accès
à la fonction mmap() - de plus ce module est considéré comme expérimental),
so (pas de gestion dynamique des modules - voir un peu plus bas), example (utile
uniquement aux développeurs de modules), auth_digest (car ce module peut
entraîner des conflits avec le module digest - de plus il est considéré
expérimental), log_agent et log_referer (qui sont obsolètes, leurs
fonctionnalités ont été intégrées dans le
module log_config).
Le paramètre --disable-module permet de spécifier certains
modules optionnels fournis avec les sources d'Apache à ne pas compiler
(et donc indisponibles). Par exemple, si vous spécifiez --enable-module=all,
il vaut mieux malgré tout désactiver certains modules. Ainsi,
ajouter les options
--disable-module=mmap_static \
--disable-module=auth_digest \
--disable-module=example \
spécifie de ne pas utiliser les modules mod_mmap_static, mod_auth_digest
et mod_example.
La dernière option est certainement la plus intéressante car elle
indique au configurateur que l'on souhaite utiliser les modules dynamiques.
En effet, tout comme le noyau de Linux est capable d'utiliser des modules qui
ne sont chargés que si besoin est, Apache est capable d'utiliser un mécanisme
similaire.
Les avantages sont doubles. Tout d'abord, Apache ne charge en mémoire
que les modules dont il a besoin à un instant précis, et cela
libère donc la mémoire centrale du serveur pour d'autres tâches.
Ensuite, on dispose d'une plus grande souplesse. Installer un nouveau module
ne nécessite que la compilation du dit module et ne nécessite
donc plus les sources d'Apache. De plus, une mise à jour de version de
PHP est bien plus aisée puisqu'il suffit de recompiler la nouvelle version
sous forme de module et ne nécessite donc pas d'interruption du serveur
HTTP. La légère contrepartie par rapport à une intégration
des composants au sein d'Apache est une légère augmentation de
la charge du serveur dû à la nécessite de gérer les
chargements / déchargements des modules en mémoire.
Si vous souhaitez disposer d'un bon compromis entre performance et maintenance
aisée, vous pouvez intégrer les modules fournis avec Apache (donc
dépendants de la version d'Apache) dans l'exécutable. Pour cela,
il suffit de ne pas spécifier l'option --enable-shared=max. Par
contre, les modules tiers (et donc indépendants de la version d'Apache)
tels que PHP, mod_gzip, etc. peuvent être gérés comme modules
dynamiques via apxs.
Vous pouvez maintenant lancer la compilation et l'installation :
# make
# make install
Tout comme nous l'avons fait pour MySQL, nous vons conseillons de créer
un lien symbolique apache vers le répertoire d'installation (apache-1.3.22)
:
# ln -s /usr/local/apache-1.3.22 /usr/local/apache
Vous pouvez maintenant démarrer Apache :
# /usr/local/apache/bin/apachectl start
Pour vérifier que l'installation est correcte, ouvrez votre navigateur
et tapez simplement l'adresse IP (ou le nom si vous avez un DNS) de la machine
sur laquelle vous venez d'installer Apache. La page suivante devrait apparaître
:
Pour qu'Apache démarre automatiquement, ajoutez les lignes suivantes
au fichier /etc/rc.local (valable sur Linux Slackware) :
# Demarrage Apache
if [ -x /usr/local/apache/bin/apachectl ]; then
. /usr/local/apache/bin/apachectl start
fi
L'étape suivante va consister à modifier le fichier de configuration
d'Apache afin de l'adapter à nos besoins. Celui-ci se trouve dans le
sous-répertoire conf et se nomme httpd.conf. Plutôt
que d'en détailler chaque ligne, nous allons vous en présenter
les options (ou directives) importantes, ainsi que quelques propositions de
modification.
Le fichier httpd.conf comporte trois grandes sections que nous allons maintenant
décrire.
Première section : Global Environment
Cette section comprend des paramètres qui décrivent
le fonctionnement global d'Apache comme par exemple le nombre de requêtes
concurrentes qu'il peut accepter. Voici les plus importants :
ServerType standalone
Cette option décrit le mode d'exécution d'Apache.
Les valeurs possibles sont inetd ou standalone (autonome), ce dernier étant
choisi par défaut.
Rappelons que le démon inetd (appelé également le "super-serveur
Internet") est en quelque sorte un superviseur. Il attend des connexions
sur un certain nombre de ports (21 pour FTP, 23 pour Telnet, etc.) et lors d'une
demande de connexion sur un port particulier, il démarre une application
(ou démon) spécifique apte à fournir les services qu'attend
la machine appelante. Cette application terminée, inetd continue l'écoute
sur le port. L'intérêt d'inetd est donc de limiter la charge du
système en ne démarrant un démon qu'à la demande.
En mode autonome, le démon Apache est en permanence présent en
mémoire, qu'il y ait ou non des requêtes. Ce mode est préféré
car plus performant : lors d'une requête, Apache répond instantanément.
A l'opposé, en mode inetd, un temps de latence inhérent à
l'activation du démon est constaté et pénalise lourdement
la performance d'un serveur très sollicité. Nous vous conseillons
de conserver le paramètre standalone.
ServerRoot "/usr/local/apache-1.3.22"
Cette option spécifie le répertoire principal
d'Apache. Les composants sont placés dans des sous-répertoires
: bin pour les programmes, conf pour les fichiers de configuration, logs pour
les journaux d'accès ou d'erreur, libexec pour les modules dynamiques,
man pour les pages de manuel, etc. Cette option prend comme valeur celle spécifiée
pour le paramètre "--prefix" lors de la préconfiguration.
LoadModule nommodule_module libexec/nommodule.so
ClearModuleList
AddModule nommodule.c
Ces paramètres permettent l'utilisation des modules
dynamiques (ou Dynamic Shared Objects, DSO). L'ordre dans lequel ils sont spécifiés
est très important et il ne faut donc pas le modifier.
Si vous souhaitez ajouter un nouveau module à Apache et que vous le compilez
pour qu'il soit dynamique, il faudra ajouter les paramètres "LoadModule"
et "AddModule" correspondants. Prenons par exemple un module mod_toto
: vous devrez ajouter la ligne "LoadModule mod_toto_module libexec/mod_toto.so"
avant "ClearModuleList" et ajouter une ligne "AddModule mod_toto.c"
juste après la dernière ligne "AddModule ...".
Actuellement, la plupart des modules tiers sont fournis sous la forme d'un fichier
source (mod_toto.c par exemple). Pour l'installer simplement, utilisez la commande
apxs disponible dans le répertoire bin de Apache :
# /usr/local/apache/bin/apxs -c -i -a mod_toto.c
Le module va ête compilé (-c), installé dans le bon répertoire
(-i) et activé (-a). Cette dernière option correspond à
l'ajout des lignes "LoadModule" et "AddModule" adéquates
dans le fichier httpd.conf.
Deuxième section : 'Main' server configuration
Cette section décrit l'ensemble des paramètres
utilisés par le serveur par défaut, c'est-à-dire celui
qui répond aux requêtes qui ne sont pas adressées à
un hôte virtuel. Si vous souhaitez héberger plusieurs sites distincts
sur un seul serveur, vous aurez besoin des hôtes virtuels. Nous les détaillerons
lors de la présentation de la troisième section, qui leur est
consacrée. Si vous n'hébergez qu'un seul site, seule cette rubrique
est importante. Nous ajouterons également que l'ensemble des options
de configuration du serveur principal peuvent être reprises dans la configuration
d'un hôte virtuel.
Port 80
Cette option spécifie le port sur lequel le serveur
Apache attend des requêtes. 80 est la valeur par défaut et correspond
à la valeur attribuée au service www par les instances
de normalisation (RFC 1700).
A noter que comme pour tout port inférieur à 1024, un programme
devant utiliser le port 80 doit être lancé avec les droits de root.
Si vous n'avez pas les droits d'administration sur la machine, utilisez une
valeur supérieure, par exemple 8080.
User nobody
Group nobody
Les directives User et Group permettent de spécifier
un utilisateur et un groupe fictif qui détermineront les droits d'accès
du serveur Apache, le but étant de limiter les risques en cas d'intrusion
par un pirate. Nous sommes donc ici dans le même cas de figure que celui
présenté précédemment avec MySQL.
Cependant, et comme nous l'avons évoqué ci-dessus, il n'est pas
possible d'utiliser le port 80 si Apache ne tourne pas avec les droits root.
La subtilité réside dans le mécanisme de fonctionnement
client/serveur d'Apache. Un processus père, tournant avec les droits
root, attend des connexions sur le port 80. Lorsqu'une demande de connexion
arrive, le processus père crée un processus fils (tournant avec
les droits nobody) qui va être chargé de satisfaire les demandes
du client venant de se connecter. C'est donc un processus ayant des droits restreints
qui lit les fichiers (HTML, PHP, etc.) et les envoie au navigateur de l'internaute.
Une règle doit donc être observée : les fichiers constituant
votre site doivent être accessibles en lecture à l'utilisateur
et/ou au groupe nobody. Assurez-vous que les nouveaux fichiers que vous copiez
sont soit en lecture pour tout le monde (chmod a+r fichier.html), soit appartiennent
à l'utilisateur nobody (chown nobody fichier.html) ou au groupe nobody
(chgrp nobody fichier.html).
Pour des raisons obscures, la version 1.3.22 définit comme groupe par défaut "#-1". Si vous avez le moindre souci, remplacez-le par nobody.
ServerAdmin webmaster@asgard.local
La directive ServerAdmin permet simplement de définir
une adresse email qui sera affichée sur les pages générées
par Apache (pages d'erreur, présentation de répertoire, etc.)
#ServerName thor.asgard.local
Cette directive permet de forcer un nom d'hôte qui sera
renvoyé au navigateur client, par exemple www plutôt que
le nom d'hôte réel.
Attention toutefois, vous ne pouvez pas spécifier n'importe quel nom,
celui que vous avez choisi devra être défini dans le DNS local.
Si ce n'est pas le cas, il faudra y accéder par son adresse IP.
Si vous laissez la ligne commentée (avec la # devant), le serveur répondra
avec le nom que vous avez tapé dans votre navigateur.
Dans un premier temps, laissez cette ligne commentée.
DocumentRoot "/data/www/html"
Cette option permet de spécifier dans quel répertoire
sont stockées les pages présentes à la racine du site (par
exemple http://nomserveur/test.html).
Ne changez pas cette option pour l'instant.
<Directory "/data/www/html">...</Directory>
Ces directives délimitent une liste d'options qui va
s'appliquer à un répertoire spécifique.
La directive "Options" va déterminer les comportements généraux
du répertoire.
La directive "AllowOverride" permet de spécifier si certaines
options définies par la directive Options vont pouvoir être surchargées
par l'utilisation d'un fichier d'accès (voir AccessFileName ci-dessous).
Les directives "Allow from" et "Order" déterminent
qui a accès aux fichiers contenus dans ce répertoire, et dans
quel ordre les autorisations sont gérées : d'abord les exclusions
ou d'abord les autorisations.
<IfModule mod_userdir.c>...</IfModule>
Ces directives délimitent une liste d'options à
n'appliquer que si le nom de module spécifié (mod_userdir dans
ce cas) a été activé au niveau de la première section
par les directives LoadModule et AddModule.
UserDir public_html
Dans le cas où le module mod_userdir est chargé,
cette option permet de spécifier un nom de répertoire qui, s'il
existe dans le répertoire de base (home directory) d'un utilisateur local
du serveur Apache, va lui permettre d'y stocker des pages. Pour y accèder,
il suffira de saisir comme URL http://nomserveur/~nomutilisateur/.
Attention, le serveur Apache ayant les droits de l'utilisateur nobody,
le répertoire de base ainsi que le répertoire pour les pages des
utilisateurs devront lui être accessibles. Pour ce faire, donnez leur
les droits en lecture et en parcours :
# chmod 755 ~nomutilisateur
# chmod 755 ~/public_html
Puis donnez les droits en lecture aux fichiers contenus dans le répertoire
public_html :
# chmod -R 755 ~/public_html/*
Si vous ne souhaitez pas utiliser cette fonctionnalité, commentez les
lignes LoadModule et AddModule correspondantes dans la première
section du fichier httpd.conf.
DirectoryIndex index.html
Si le module mod_dir est chargé (voir IfModule
ci-dessus), cette directive permet de spécifier des noms de fichiers
qu'Apache va considérer comme noms de page par défaut. Ceci permet
de taper une URL sans spécifier un nom de fichier supplémentaire
(http://nomachine/test/ plutôt que http://nomachine/test/index.html).
Les noms doivent être séparés par des espaces, et l'ordre
dans lequel ils sont saisis conditionne la priorité dans le cas où
deux fichiers "par défaut" sont présents au même
endroit.
Attention ! Lorsqu'aucun nom de fichier n'est fourni, Apache balaye l'ensemble
des fichiers du répertoire pour déterminer l'existence ou non
de pages "par défaut". Donc dans un souci de performance, ne
saisissez pas une liste trop longue.
Vous pouvez ajouter index.php devant index.html.
AccessFileName .htaccess
Cette directive permet de spécifier le nom d'un fichier
qui, s'il est présent dans un répertoire, va permettre de spécifier
des règles de sécurité pour l'accès aux autres pages
de ce répertoire. C'est la présence d'un tel fichier qui fait
qu'une fenêtre vous demandant votre login et votre mot de passe vous est
présentée. Un tel fichier est utile, par exemple, pour protéger
un répertoire contenant les pages d'administration de votre site.
Le fichier d'accès permet également de "surcharger"
certaines options définies dans le fichier httpd.conf, c'est-à-dire
demander un comportement différent et spécifique pour un répertoire.
Cela est intéressant si votre site est hébergé et que vous
n'avez pas donc pas la possibilité de jouer sur la configuration de Apache.
A noter que ce fichier permet également de spécifier certains
options pour PHP.
Le choix ou non d'utiliser les fonctionnalités apportées par ce
fichier n'est pas évident. La problèmatique reste celle du bon
équilibre souplesse/performance. Si l'option AccessFileName existe, chaque
fois qu'Apache ouvrira un répertoire à la recherche d'un fichier,
il cherchera un fichier du nom de ce qui a été spécifié
lors de la configuration. Cela ajoute donc une opération et a donc un
impact certain sur les performances. Par contre, on dispose de fonctionnalités
appréciables. Au contraire, si cette ligne est commentée (symbole
# au début de la ligne), Apache n'effectuera pas la recherche d'un fichier.
Les performances ne seront pas impactées mais on perd en souplesse.
HostnameLookups Off
Cette directive conditionne le fait qu'Apache va essayer (valeur
On) ou non (valeur Off) de résoudre l'adresse IP du client qui se connecte
à lui pour l'écrire dans les journaux d'accès. Si cette
option rend les journaux plus explicites, l'impact sur les performances est
généralement trop important. Il vaut donc mieux laisser à
"Off"
ErrorLog /usr/local/apache-1.3.22/logs/error_log
CustomLog /usr/local/apache-1.3.22/logs/access_log common
ErrorLog (journal d'erreur) et CustomLog (journal personnalisé,
i.e. journal d'accès) permettent de spécifier le chemin et le
nom du fichier contenant respectivement les erreurs d'accès (pages non
trouvées, etc.) et les accès réussis. CustomLog accepte
en plus un paramètre qui correspond à un format de journal, c'est-à-dire
une plus ou moins grande richesse des informations journalisées. Les
formats pour le journal d'accès sont déterminés par la
directive LogFormat.
Pour obtenir un maximum d'informations sur les visiteurs, il est bien plus intéressant
d'utiliser le mode combined en lieu et place de common. Mais dans
ce cas, le volume des journaux devient vite très importants. Pour mieux les
gérer, il suffit d'avoir recours à un programme permettant "d'éclater"
les journaux, le plus facile étant une séparation basée
sur la date. L'outil cronolog
est parfaitement indiqué, car il permet de spécifier des noms
de fichiers et/ou de répertoires en se basant sur la syntaxe de strftime.
Par exemple, %Y représente l'année courante sur quatre chiffres,
%m le mois courant sur deux chiffres, etc. Pour connaître l'ensemble des
possibilités, faites :
# man strftime
Tout d'abord, commentez la ligne CustomLog /usr/local/apache-1.3.22/logs/access_log
common (ajout d'une dièse # au début de la ligne) afin de
ne plus utiliser le mode standard. Commentez également la ligne contenant
ErrorLog.
Ensuite, téléchargez
cronolog et décompactez l'archive:
# tar xvfz cronolog-1.6.1.tar.gz
Rendez-vous dans le répertoire créé :
# cd cronolog-1.6.1
Préparez la configuration :
# ./configure --prefix=/usr/local/cronolog-1.6.1
Compilez et installez cronolog :
# make install
Nous avons choisi de garder les noms de fichier access_log et error_log, mais
ceux-ci vont être séparés mensuellement. Un répertoire
par année, et un sous -répertoire par mois.
Pour cela, ajoutez la ligne suivante juste en-dessous de la dernière
ligne du type CustomLog :
CustomLog "|/usr/local/cronolog-1.6.1/sbin/cronolog /usr/local/apache-1.3.22/logs/%Y/%m/access_log"
combined
Ajoutez également une ligne pour le journal des erreurs :
ErrorLog "|/usr/local/cronolog-1.6.1/sbin/cronolog /usr/local/apache-1.3.22/logs/%Y/%m/error_log".
N.B. : Le caractère avant le chemin vers cronolog est un pipe ("|").
Alias /icons/ "/usr/local/apache-1.3.22/icons/"
La directive Alias permet de créer un lien entre un
répertoire dans l'arborescence Web et un répertoire dans l'arborescence
du système de fichiers du serveur. Ainsi, avec la directive ci-dessus,
une requête sur l'URL http://nomserveur/icons/test.gif retournera
le fichier /usr/local/apache-1.3.22/icons/test/gif.
Attention, si l'alias est défini avec un slash à la fin (le symbole
"/"), il est nécessaire de taper un slash (ou de spécifier
un fichier) dans l'URL pour accèder aux données pointées
par l'alias. Par exemple, la directive Alias /doc/ "/usr/local/apache/htdocs/manual/"
permettra d'obtenir le contenu du répertoire manual si vous saisissez
http://monserveur/doc/ ou http://monserveur/doc/index.html. Si
vous tapez http://monserveur/doc, Apache recherchera un sous-répertoire
doc dans l'arborescence standard des documents (voir DocumentRoot).
La directive Alias apporte une certaine souplesse en évitant de devoir
dupliquer certaines données que l'on voudrait rendre accessible. Cependant,
le fait de mettre à disposition des fichiers hors de l'aborescence standard
pouvant présenter des risques, il est d'usage d'associer à une
directive Alias une directive Directory afin d'instaurer certaines règles
de sécurité.
AddType application/x-httpd-php3 .php3
La directive AddType permet soit d'ajouter des type MIME,
soit d'étendre la liste des extensions de fichiers correspondant à
un type MIME.
L'utilisation la plus courante de cette directive nous concerne directement
puisqu'elle permet la prise en compte active par Apache des fichiers PHP.
Nous y reviendrons ultérieurement.
ErrorDocument 404 /missing.html
Les directives ErrorDocument permettent de personnaliser les
pages présentées en cas d'erreur. Les paramètres de la
directive sont tout d'abord le code HTTP pour lequel on veut personnaliser,
puis soit du texte précédé d'une double quote (par exemple
"Page introuvable), soit une URL. Dans ce dernier cas, l'URL ne doit pas
forcément désigner un fichier HTML statique : cela peut être
un script Perl (/cgi-bin/erreur404.pl par exemple), une page PHP, etc.
N.B. : les codes d'erreur les plus courants sont 404 (page introuvable), 500
(erreur interne du serveur) et 403 (accès interdit).
Troisième section : Virtual Hosts
La rubrique Virtual Hosts (hôtes virtuels) permet à
Apache de gérer plusieurs sites/domaines différents avec le même
serveur. Il existe deux types d'hôtes virtuels : ceux basés sur
l'adresse IP et ceux basés sur le nom. Attention toutefois, ces derniers
s'appuient sur des spécificités du protocole HTTP dans sa version
1.1, même si.cela ne devrait plus être un problème à
l'heure actuelle car tous les navigateurs récents gèrent ce protocole.
Nous n'allons pas étudier les hôtes virtuels car ils couvrent des
besoins spécifiques qui sortent du cadre de cet article.
Lorsque vous avez terminé les changements dans le fichier de configuration,
arrêtez puis redémarrez Apache :
# /usr/local/apache/bin/apachectl restart
