Académique Documents
Professionnel Documents
Culture Documents
Serveur HTTP Apache 2
Serveur HTTP Apache 2
Installation
Pour installer Apache seul, installez simplement le paquet apache2.
Pour installer Apache avec PHP et MySQL ou MariaDB, reportez vous à l'installation de LAMP.
À la suite de cette installation votre serveur doit fonctionner et être accessible à
l'adresse http://localhost (à partir de la même machine).
Un message It Works! devrait s'afficher dans votre navigateur. Il s'agit du contenu du
fichier /var/www/html/index.html qui est affiché par défaut.
Modifier
Lancement
Apache 2 se lance automatiquement dès son installation, et se relance automatiquement à
chaque démarrage. C'est l'idéal pour un serveur qui doit continuellement fournir du contenu en
ligne, mais pour un serveur de test (on dit de développement) on peut éventuellement désirer un
comportement différent.
Modifier
Modifier
sudo apache2ctl -v
sudo apache2ctl -t
sudo apache2ctl -M
Modifier
Fichiers de configuration
Un seul serveur Apache permet de déployer simultanément plusieurs sites et services qu'il faut
configurer individuellement.
Pour plus de clarté, la configuration d'Apache2 est morcelée. Toutefois, tous les fichiers de
configuration se situent dans le répertoire /etc/apache2 :
Normalement les fichiers de configuration globale apache2.conf, envars et ports.conf n'ont pas
à être modifiés. Toute la configuration devrait se faire dans les sous dossiers xxx-available.
Les diverses configurations sont activées (a2en pour Apache 2 enable) ou désactivées
(a2dis pour Apache 2 disable) avec les commandes suivantes :
Cela aura pour effet de créer ou supprimer les liens symboliques correspondants dans les
répertoires xxx-enabled.
Apache prendra alors en compte, ou pas, les fichiers de configuration concernés après
rechargement :
Par défaut Apache ne prend en compte que les fichiers portant l'extension .conf (ou .load,
seulement pour les modules).
Modifier
Hôtes virtuels
Avec Apache, chaque site ou application web correspond en principe à un hôte virtuel
(VirtualHost en anglais).
Chaque hôte virtuel est défini par un fichier de configuration indépendant, qu'on trouve ou qu'on
créé dans le répertoire /etc/apache2/sites-available/.
Modifier
Par défaut
Par défaut, il existe 2 hôtes virtuels.
Ce chapitre est ici à titre d'information.
Il n'est a priori pas nécessaire de modifier les fichiers existant par défaut. Chaque site ou service
devrait correspondre à un hôte virtuel unique, définit dans un fichier indépendant (voir création
d'hôtes virtuels).
De plus ces fichiers existant par défaut peuvent éventuellement être écrasés lors de mises à jour
majeures du système.
Le premier VirtualHost est défini dans le fichier /etc/apache2/sites-available/000-
default.conf. Voici son contenu sans les commentaires :
000-default.conf
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
directive description
<VirtualHost *:80>
On déclare l'hôte virtuel. Il doit répondre aux requêtes qui s'adressent à toutes les ad
peut ici éventuellement spécifier une adresse IP unique à laquelle répondra Apache p
le serveur possède plusieurs adresses IP), ou choisir de répondre au port 443 (pour H
de l'écouter).
ServerAdmin
C'est le courriel de l'administrateur système. Cette directive n'est ni très utile, ni indi
webmaster@localhost
directive description
DocumentRoot
C'est le chemin absolu vers l'emplacement local (sur l'espace disque du serveur) qui
/var/www/html en premier un fichier index.html ou index.php à afficher par défaut à l'emplacement
cet hôte virtuel qui affiche le message It Works! contenu dans le fichier /var/www/ht
ErrorLog $
Ce sont des directives relatives au log d'erreur et au log d'accès de cet hôte virtuel. C
{APACHE_LOG_DIR}/err répertoire APACHE_LOG_DIR, qui est par défaut /var/log/apache2 sur ubuntu.
or.log
CustomLog $
{APACHE_LOG_DIR}/acc
ess.log combined
</VirtualHost>
Fin de la section concernant cet hôte virtuel.
directive description
<VirtualHost *:80>
On accepte les connexions sur n'importe quelle IP du serveur (*) sur le port 80.
ServerName example.com
Cet hôte virtuel sera seulement appelé pour le nom de domaine example.com…
ServerAlias
…ainsi que pour le sous-domaine www.example.com. On peut spécifier ici d'aut
www.example.com un espace. On peut aussi utiliser *.example.com pour inclure tous les sous-doma
DocumentRoot
On placera les fichiers du site dans le répertoire /var/www/example.
"/var/www/example"
<Directory
On spécifie dans cette section des règles pour le répertoire /var/www/example sou
"/var/www/example">
Options +FollowSymLinks
Apache suivra les liens symboliques qu'il trouvera dans ce répertoire (et ses des
AllowOverride all
On pourra inclure une configuration personnalisée via un fichier .htaccess.
ErrorLog
Il est pratique d'avoir des logs séparés pour chaque hôte virtuel, afin de ne pas m
/var/log/apache2/error.
directive description
example.com.log
CustomLog
/var/log/apache2/access
.example.com.log
combined
Après avoir l'avoir créée, il faut activer cette configuration avec la commande sudo a2ensite
[nom du fichier sans son extension] . Par exemple :
On peut définir un hôte virtuel par un nom de domaine même sans avoir de nom de domaine
enregistré chez un registrar.
On peut soit utiliser un sous-domaine de localhost, comme example.localhost, qui pointera
directement sur la machine locale (et qui ne sera donc valable que sur la machine qui fait tourner
Apache), soit créer un nouveau nom de domaine "fictif".
Il faut dans ce cas résoudre l'IP du serveur pour un domaine fictif côté client. Cela se fait
en éditant le fichier /etc/hosts côté client avec les droits d'administration pour y ajouter la
ligne :
hosts
127.0.0.1 example
où 127.0.0.1 est l'adresse IP du serveur (locale dans ce cas) et example est le nom de domaine
choisi.
(Voir la documentation concernant le fichier hosts)
Avec la directive ServerName example dans le VirtualHost, l'hôte virtuel sera accessible depuis ce
client à l'adresse http://example/.
Cela peut être très pratique en phase de développement sur une machine ou un réseau local, par
exemple.
Modifier
HTTPS
HTTPS permet de chiffrer les communications entre le navigateur et Apache au moyen du
protocole SSL/TLS, et de garantir l'authenticité de votre serveur (au moyen d'un certificat). Cela
empêche qui que ce soit de récupérer ("sniffer") des informations sensibles (tels que des mots de
passes) en particulier lorsqu'on se connecte depuis un réseau public, ou empêche un autre
serveur de se faire passer pour le vôtre.
Il n'est ni nécessaire, ni faisable de mettre en place HTTPS avec un certificat valide sur un
serveur de développement local.
Pour rendre disponible les sites de manière sécurisée via HTTPS avec des certificats valides, la
solution la plus simple est d'utiliser l'outil Certbot de Let's Encrypt.
Vous trouverez une documentation plus détaillée à ce sujet sur cette page de la documentation,
mais nous verrons ici une méthode spécifique à Apache.
Modifier
Modifier
avoir un ou plusieurs noms de domaine enregistrés, pointant sur le serveur depuis plus
de 48 heures.
avoir un serveur web apache déjà configuré, fonctionnel et accessible publiquement.
Les instructions pour installer et utiliser simplement certbot sont disponibles en anglais sur le site
officiel. En voici un récapitulatif.
Installation de Certbot
Pour installer Certbot :
Utilisation de Certbot
Certbot permet ensuite de générer tous les certificats et d'adapter les configurations d'Apache
pour tous les noms de domaine associés aux hôtes virtuels au moyen d'une seule commande :
Lors de l'opération le script nous invite à cocher les domaines pour lesquels on souhaite obtenir
les certificats et à choisir de forcer l'usage de HTTPS ou pas. Pour des raisons de sécurité, c'est
généralement une très bonne idée de forcer HTTPS.
Après cette opération les sites devraient être accessibles en HTTPS de manière sécurisée, sans
que les navigateurs affichent de message d'alerte.
Grâce à l'option –apache, Certbot s'occupe automatiquement de créer des fichiers de
configuration de la forme /etc/apache2/sites-available/example.com-le-ssl.conf pour les
hôtes virtuels en HTTPS sur le port 443 et de les activer (-le-ssl pour Let's Encrypt).
Renouvellement automatique
Pour information c'est la commande certbot renew qui permet de renouveler les certificats très
simplement, mais Certbot créé automatiquement une tâche cron à cet effet
dans /etc/cron.d/certbot. Il est également créé un « timer » systemd qui fait la même chose
(/lib/systemd/system/certbot.timer et certbot.service).
Le script est lancé automatiquement toutes les 12 heures, mais les certificats ne seront
renouvelés que si nécessaire. En principe il n'y a donc rien à faire.
Modifier
.htaccess
En plus des fichiers de configuration situés dans /etc/apache2, Apache nous permet de définir
des configurations tierces pour certains répertoires en plaçant des fichiers
nommés .htaccess directement avec les autres fichiers du contenu web. (Le point au début du
nom du fichier en fait un fichier caché par défaut.)
Les directives de chaque fichier .htaccess s'appliquent au répertoire dans lequel il se trouve,
ainsi que tous ses descendants (sous-repertoires, sous-sous-repertoires, etc.).
C'est la directive AllowOverride, spécifiée dans une section <Directory> de l'hôte virtuel qui
définit si les fichiers .htaccess doivent être pris en compte, ou pas, pour ce répertoire et ses
descendants. Elle peut prendre la valeur All ou None.
Ces fichiers sont très pratiques pour redéfinir des paramètres sur un serveur mutualisé à
l'administration duquel on n'a pas accès, ou pour définir dynamiquement des règles spécifiques à
certaines solutions web (comme la réécriture d'URL).
Modifier
Index
L'index est le contenu affiché par défaut par Apache lorsqu'on appelle un répertoire sans spécifier
de nom de page web particulière.
L'index est définit par la directive DirectoryIndex qui détermine quels fichiers Apache doit
traiter par défaut. Chaque nom de fichier est séparé par un espace et listé par ordre de priorité.
Par défaut, DirectoryIndex a la valeur index.html index.cgi index.pl index.php index.xhtml
index.htm.
Si Apache ne trouve aucun des fichiers mentionnés par DirectoryIndex, il essaie de récupérer
une liste du contenu du répertoire, afin que le navigateur l'affiche de la même manière qu'un
gestionnaire de fichier.
On peut activer ou désactiver ce listing avec respectivement les directives Options
+Indexes ou Options -Indexes.
Pour des raisons de sécurité, il est généralement préférable de laisser cette option désactivée.
Dans ce cas, et faute de fichier index, c'est une erreur 403 qui s'affiche, car l'utilisateur n'a pas la
permission de lister le contenu du répertoire.
Toutes ces directives peuvent être définies dans une section <Directory> ou dans un
fichier .htaccess.
Modifier
Modules
Il est possible d'ajouter des modules à Apache afin d'étendre les fonctionnalités du serveur web.
Les modules disponibles sont répertoriés ici : /etc/apache2/mods-available
Modifier
mod_php
PHP est un langage de programmation et un interpréteur qui permet principalement de générer
du contenu HTML. C'est donc une solution très largement utilisée pour créer des applications web
ou des sites internet dynamiques.
Il est très couramment utilisé en conjonction d'Apache. Voir LAMP.
Le module mod_php permet de l'utiliser comme une extension d'Apache. C'est la méthode la plus
simple pour utiliser PHP avec Apache.
Une autre méthode consiste à utiliser PHP en FastCGI. C'est une solution plus souple et mieux
optimisée pour des sites destinés à supporter un traffic important, mais elle est plus complexe à
mettre en oeuvre. Nous ne traiterons pas de ce cas ici.
Pour installer et activer mod_php sous ubuntu, on utilise cette commande :
Mais encore une fois, mieux vaut vous reporter à la documentation de LAMP à ce sujet.
Modifier
mod_rewrite
mod_rewrite permet de réécrire des URL.
Il s'agit généralement de remplacer le chemin, le nom de la page, et la chaîne de requête de
l'URL par une chaîne de caractère en concordance avec la structure et le contenu du site.
De nombreux services ont recours à cette pratique afin d'augmenter leur référencement et de
clarifier leur contenu.
Ces services utilisent parfois une terminologie exotique pour mentionner cette
pratique : WordPress parle par ex. de permalinks.
On peut aussi s'en servir pour déployer une API web propre.
On utilise aussi parfois cette méthode afin de mettre en place des redirections web un peu
complexes.
Pour activer ce module on utilisera la commande
L'utilisation de mod_rewrite est relativement complexe et fait appel à des expressions régulières.
N'hésitez pas à consulter la documentation officielle à ce sujet.
Pour la rédaction des expressions régulières, vous pouvez vous aider de services en ligne tels
que regex101.com ou regexr.com
Un petit exemple :
RewriteEngine on
On peut écrire ces règles de réécriture dans une section <VirtualHost> ou <Directory> (le
comportement n'est pas le même), ou dans un fichier .htaccess.
N'oubliez pas de modifier le virtualhost en conséquence sinon les règles de réécriture .htaccess
ne fonctionneront pas correctement. Voici un exemple de configuration qui marche :
<Directory /var/www/html>
AllowOverride All
</Directory>
Modifier
mod_proxy
Comme son nom l'indique, mod_proxy permet à apache de relayer des requêtes depuis ou vers
un service tiers.
Ce module peut par exemple être utile lorsqu'on utilise d'autres serveurs HTTP en plus d'Apache
sur un même serveur web, afin d'éviter d'avoir à accéder au contenu web sur d'autres ports que
le port 80 ou 443.
L'activation de ce module sur un serveur ouvert sur le web est dangereuse. Une mauvaise
configuration permet par exemple à un intrus d'accéder aux services disponibles sur le réseau
local, ou d'usurper votre adresse IP.
N'activez ce module que si vous êtes certain de ce que vous faites.
Voir la documentation officielle à ce sujet.
Pour activer ce module :
<Location /emby>
ProxyPass http://localhost:8096/
ProxyPassReverse http://localhost:8096/
Require all granted
SetEnv proxy-nokeepalive 1
SetEnv proxy-sendchunked 1
</Location>
Modifier
mod_userdir
Ce module est également documenté sur la page xampp.
Il peut être utile, et c'est prévu par Apache, que chaque utilisateur puisse mettre un contenu web
à disposition depuis son espace personnel (dans le répertoire home).
Ce contenu sera accessible à l'adresse http://example.com/~nom_de_lutilisateur, ou dans la
plupart des cas : http://localhost/~nom_de_lutilisateur.
Pour mettre cette configuration en place, on crée un répertoire public_html dans son espace
personnel et on lui donne les droits de lecture et d'exécution :
mkdir ~/public_html
echo 'Mon site personnel' > ~/public_html/index.html
chmod -R 755 ~/public_html
mod_headers
Le module headers permet de personnaliser les en-têtes HTTP. C'est à dire les informations
envoyées par le serveur avant le document lui-même.
C'est utile notamment pour améliorer la sécurité des sites web. Voici quelques en-têtes qui
peuvent être ajoutées à cette fin.
Pour appliquer globalement les directives proposées, ouvrez (ou créez s'il n’existe pas) le
fichier /etc/apache2/mods_available/headers.conf et placez-y ceci :
headers.conf
# Cet en-tête empêche MSIE d'interpréter des fichiers comme quelque chose
# d'autre que ce qui est défini en dans que type de contenu dans les en-tes
HTTP
#
Header set X-Content-Type-Options: "nosniff"
# Cet en-tête empêchera les autres sites d'intégrer les pages de ce site
dans des frames.
# C'est une mesure de portection contre les attaques par détournement de
clic (clickjacking)
# Attention cet en-tête est rendue obsolète par les CSP
#
Header set X-Frame-Options: "sameorigin"
# Cet en-tête oblige les navigateurs à utiliser la protection XSS même s'il
l'ont désactivé
#
Header set X-XSS-Protection "1; mode=block"
<VirtualHost *:443>
…
Header always set Strict-Transport-Security: "max-
age=31536000;includeSubDomains;preload"
</VirtualHost>
Enfin, toujours dans un objectif de sécurité, vous pourrez être amené à utiliser les en-
têtes Content-Security-Policy, exemple :
Pour voir les en-têtes envoyées par votre serveur vous pouvez utiliser des outils en ligne de
commande comme :
curl -I https://example.com
ou une extension du navigateur web qui permet d'afficher les en-têtes HTTP.
Modifier
Modsecurity
Il s'agit d'un pare-feu pour Apache.
Une page de la documentation est consacrée à ce module.
Modifier
Sécurité
Sans chiffrer les communications avec le module SSL, toutes les informations échangées entre le
navigateur et le serveur, contenu web et variables d'authentification, transitent en clair sur
Internet. Une des premières règles de sécurité pour Apache est donc de forcer l'utilisation
de HTTPS.
Modifier
Permissions
Par défaut sur Ubuntu, Apache est exécuté par l'utilisateur www-data, qui appartient au
groupe www-data.
Quand Apache créé un fichier sur l'espace disque (via par exemple un script PHP), celui-ci
appartient donc par défaut à l'utilisateur www-data et au groupe www-data. De la même
manière, le serveur ne peut accéder qu'au contenu accessible par www-data.
Pour des raisons de sécurité il est recommandé de modifier le propriétaire des fichiers auxquels
peut accéder Apache.
Le propriétaire devrait être l'utilisateur qui va maintenir le contenu localement, mais le groupe
propriétaire devrait rester www-data :
On change ensuite les permissions du contenu de manière à ce que l'utilisateur puisse le lire et le
modifier, mais qu'Apache (dans le groupe www-data) ne puisse que le lire.
On attribue donc les droits rwx r-x — (750) pour les répertoires, et rw- r– — (640) pour les
fichiers :
(pour rappel x concerne les répertoires et les fichiers tandis que X ne concerne que les
répertoires - et autorise à les ouvrir)
Si Apache doit pouvoir modifier du contenu (pour un répertoire d'upload par exemple), on ne
modifie que la permission concernant le groupe (le second numéro), donc rwx rwx — (770) pour
les répertoires et rw- rw- — (660) pour les fichiers :
Modifier
Fail2ban
Pour contrer les attaques par force brute sur un système d'authentification d'une application web,
il est vivement recommandé d'utiliser l'application Fail2ban.
Modifier
Problèmes courants
En cas d'erreur du serveur, consultez avant tout les rapports d'erreurs dans le
répertoire /var/log/apache2.
Pour afficher les dernières 40 lignes du journal d'erreur par défaut :
Si vous rencontrez un problème avec PHP, consultez également les problèmes courants
spécifiques à PHP.
Modifier
Page blanche
Si vous utilisez PHP, une page blanche indique très probablement que l'affichage des retours
d'erreur sur la page n'est pas activé.
Vous pouvez l'activer en suivant cette documentation.
Modifier
Erreur 403
Une erreur 403 indique un problème d'autorisation.
Vérifiez les permissions concernant les fichiers du contenu web que vous souhaitez
partager vis-à-vis de l'utilisateur et du groupe www-data.
Vérifiez aussi la valeur de la directive Require : Require all granted pour toujours
autoriser l'accès aux ressources.
Il est aussi possible que cette erreur soit affichée faute de fichier index.
Modifier
Erreur 404
Cette erreur indique que le contenu demandé n'a pas été trouvé.
Modifier
Erreur 500
Il s'agit d'une erreur fatale du serveur, qui peut être par exemple liée à une erreur de syntaxe
dans un fichier .htaccess.
Consultez le log d'erreur de votre hôte virtuel pour en savoir plus.
Modifier
Modifier
<Directory "/usr/share/javascript/">
Options FollowSymLinks MultiViews
</Directory>