Serveur web Apache sous CentOS 7

Apache est le principal serveur web du monde de l’Open Source. À l’origine, c’était la continuation du serveur libre développé par le NCSA (National Center for Supercomputing Applications) à l’Université de l’Illinois. Lorsque le projet officiel a été abandonné en 1994, une équipe de développeurs volontaires a continué à fournir du code sous forme de nombreux correctifs, ce qui explique la genèse du nom a patchy server, c’est-à-dire « serveur rafistolé ».

D’après les statistiques de Netcraft, un peu moins de la moitié des sites Web du monde tournent sur un serveur Apache. Ces dernières années, les parts de marché perdues par Apache sont reprises par Nginx, son principal concurrent, qui est orienté vers la performance tout en offrant moins de fonctionnalités.

Une installation typique d’Apache est généralement constituée d’un assemblage cohérent de paquets.

• le serveur Apache à proprement parler
• des bibliothèques diverses et variées
• des plug-ins
• des langages de programmation
• etc.

Cet article décrit la configuration d’un serveur Web de type LAMP (Linux + Apache + MySQL/MariaDB + PHP) sur CentOS 7.

• Le protocole HTTP et les URL
• Ports et pare-feu
• Installation
• Premier lancement du serveur
• Les fichiers de configuration
• La configuration par défaut
• Configuration de base
• Héberger un site statique
• Apache et les permissions de fichiers
• Héberger plusieurs sites sur un serveur local
• Héberger plusieurs sites sur une machine publique
• Héberger des sites dynamiques avec PHP
• Utiliser MySQL/MariaDB à partir de PHP
• Documentation
• Crédits

Le protocole HTTP et les URL

Le protocole HTTP (Hypertext Transfer Protocol, c’est-à-dire « protocole de transfert hypertexte ») est un protocole de communication client-serveur développé pour le World Wide Web. Il permet un transfert de fichiers (html, css, js, mp4, etc.) localisés grâce à une chaîne de caractères appelée URL entre un navigateur (le client) et un serveur web.

HTTP est un protocole « requête-réponse » de la couche application qui utilise le protocole TCP comme couche de transport.

1. Le client ouvre une connexion TCP vers le serveur et envoie une requête.
2. Le serveur analyse la requête et répond en fonction de sa configuration.

Une réponse HTTP est un ensemble de lignes envoyées au client par le serveur. Elle comprend une ligne de statut, les champs d’en-tête et le corps de la réponse. Voici un exemple de réponse HTTP.

$ curl --head --location http://www.slackware.com
HTTP/1.1 200 OK
Server: Apache/2.2.22
Last-Modified: Fri, 01 Jul 2016 20:15:06 GMT
ETag: "3c6282-2d8d-53698a47ae680"
Accept-Ranges: bytes
Content-Length: 11661
Content-Type: text/html
Date: Thu, 14 Mar 2019 07:53:30 GMT
Connection: keep-alive

Le rôle du serveur web consiste à traduire une URL (comme par exemple http://www.slackware.com) en ressource locale. Consulter la page http://www.slackware.com revient à envoyer une requête HTTP à cette machine.

Une URL (Uniform Resource Locator, autrement dit « identifiant uniforme de ressources ») est une chaîne de caractères ASCII utilisée pour désigner les ressources sur Internet. Elle est informellement appelée « adresse web », et elle est divisée en plusieurs parties, comme ceci.

<protocole>://<hôte>:<port>/<chemin>

• Le protocole, c’est le langage utilisé pour communiquer sur le réseau, comme par exemple http, https, ftp, etc.
• L’hôte, c’est l’ordinateur qui héberge la ressource demandée. Il est possible d’utiliser l’adresse IP, ce qui rend l’URL moins lisible.
• Le numéro de port, c’est un numéro associé à un service qui permet de savoir quel type de ressource est demandé. Le port 80 est associé par défaut au protocole HTTP. Si l’on utilise ce port, ce n’est pas la peine de le spécifier explicitement.
• Enfin, le chemin d’accès à la ressource permet au serveur de connaître l’emplacement du fichier demandé.

Ports et pare-feu

Apache utilise le port 80 en TCP pour le protocole HTTP. Il faudra donc songer à ouvrir ce port dans le pare-feu.

$ sudo firewall-cmd --permanent --add-service=http
$ sudo firewall-cmd --reload
$ sudo firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources: 
  services: dns http ssh
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

Notons que théoriquement, l’administrateur peut choisir librement le port d’écoute du serveur.

Installation

Le serveur Apache est fourni par le paquet httpd.

$ sudo yum install httpd

L’installation du paquet crée un utilisateur système apache et un groupe système apache correspondant.

$ grep apache /etc/passwd
apache:x:48:48:Apache:/usr/share/httpd:/sbin/nologin
$ grep apache /etc/group
apache:x:48:
$ sudo grep apache /etc/shadow
apache:!!:17352::::::

Premier lancement du serveur

Sous Red Hat et CentOS, Apache est préconfiguré pour afficher une page statique par défaut. Il suffit d’activer et de lancer le service.

$ sudo systemctl enable httpd --now

Installer le navigateur en mode texte ELinks.

$ sudo yum install elinks

Tester le bon fonctionnement du serveur.

$ elinks http://localhost

On doit voir quelque chose de ce genre.

=================================================================
                           Testing 123..
This page is used to test the proper operation of the Apache HTTP
server after it has been installed. If you can read this page it 
means that this site is working properly. This server is powered 
by CentOS.
=================================================================

Dans le réseau local, ouvrir l’adresse IP du serveur avec un navigateur web.

• http://192.168.2.5

On peut également invoquer le nom d’hôte.

• http://amandine.microlinux.lan

Sur un serveur dédié, on essaiera successivement l’adresse IP, le nom de domaine et l’alias associé.

• http://163.172.220.174
• http://slackbox.fr
• http://www.slackbox.fr

Voici à quoi ressemble la page par défaut dans un navigateur graphique.

Les fichiers de configuration

Initialement, la configuration du serveur Apache s’effectuait dans un seul fichier /etc/httpd/conf/httpd.conf. Avec le temps, ce fichier est devenu de plus en plus volumineux et de moins en moins lisible.

Les distributions modernes ont donc tendance à répartir la configuration d’Apache sur une série de fichiers *.conf répartis dans les répertoires /etc/httpd/conf.d et /etc/httpd/conf.modules.d, rattachés au fichier principal /etc/httpd/conf/httpd.conf par la directive Include.

Le fichier /etc/httpd/conf/httpd.conf est amplement documenté. Pour commencer, nous allons sauvegarder ce fichier par défaut et créer une version dépourvue de commentaires et plus lisible. Ici, la commande egrep filtre les lignes qui commencent soit par un commentaire (^#), soit par un espace (^$), soit par quatre espaces suivis d’un commentaire, soit par six espaces suivis d’un commentaire.

$ cd /etc/httpd/conf
$ sudo mv httpd.conf httpd.conf.orig
$ egrep -v '^#|^$|^    #|^      #' httpd.conf.orig | sudo tee httpd.conf.lite
$ sudo cp httpd.conf.lite httpd.conf

La configuration par défaut

Jetons un oeil sur le fichier httpd.conf par défaut et regardons de plus près les principales directives qui le constituent.

La directive ServerRoot permet de définir le répertoire dans lequel le serveur est installé.

ServerRoot "/etc/httpd"

La directive Listen permet à Apache d’écouter sur des adresses ou des ports spécifiques. Notons que cette directive est requise. Si elle est absente du fichier de configuration, Apache refuse de démarrer.

Listen 80

Comme nous l’avons vu un peu plus haut, la directive Include permet l’inclusion d’autres fichiers de configuration dans le fichier de configuration principal du serveur. IncludeOptional fonctionne comme Include, au détail près que la directive ne produira pas une erreur au cas où le métacaractère * ne correspond à aucun fichier. Le chemin est relatif par rapport à l’emplacement spécifié dans la directive ServerRoot.

Include conf.modules.d/*.conf
...
IncludeOptional conf.d/*.conf

Apache n’est pas censé tourner en tant que root, mais en tant qu’utilisateur spécial défini par les directives User et Group dans /etc/httpd/conf/httpd.conf. Plus précisément, il est lancé par root pour ensuite changer de propriétaire.

User apache
Group apache

L’adresse mail de l’administrateur, définie par la directive ServerAdmin, apparaîtra sur certaines pages générées par le serveur, notamment les pages d’erreur.

ServerAdmin root@localhost

Les balises <Directory> et </Directory> permettent de regrouper un ensemble de directives qui ne s’appliquent qu’au répertoire précisé, à ses sous-répertoires, et aux fichiers situés dans ces sous-répertoires.

<Directory />
  AllowOverride none
  Require all denied
</Directory>
...
<Directory "/var/www">
  AllowOverride None
  Require all granted
</Directory>
<Directory "/var/www/html">
  Options Indexes FollowSymLinks
  AllowOverride None
  Require all granted
</Directory>

La directive DocumentRoot permet de définir le répertoire à partir duquel Apache va servir des fichiers.

DocumentRoot "/var/www/html"

Lorsque le serveur trouve un fichier .htaccess, il doit savoir lesquelles des directives placées dans ce fichier sont autorisées à modifier la configuration préexistante. Le traitement des fichiers .htaccess est contrôlé par la directive AllowOverride, qui ne peut être utilisée que dans les sections <Directory>. À partir du moment où elle est définie à none, les fichiers .htaccess sont totalement ignorés.

<Directory />
  AllowOverride none
  Require all denied
</Directory>

La directive Require permet de contrôler l’accès au système de fichiers du serveur. Require all denied bloque l’accès pour tous les utilisateurs, Require all granted autorise tout le monde.

<Directory />
  AllowOverride none
  Require all denied
</Directory>
...
<Directory "/var/www">
  AllowOverride None
  Require all granted
</Directory>

Comme son nom l’indique, la directive Options permet d’activer ou de désactiver une série d’options (ou de comportements) pour un répertoire donné. Ici par exemple, l’option Indexes affiche la liste des fichiers d’un répertoire en cas d’absence de fichier index.html. FollowSymlinks permet de suivre les liens symboliques.

<Directory "/var/www/html">
  Options Indexes FollowSymLinks
  AllowOverride None
  Require all granted
</Directory>

Les balises <IfModule> et </IfModule> contiennent des directives qui ne s’appliquent qu’en fonction de la présence ou de l’absence d’un module spécifique. La directive DirectoryIndex spécifie le fichier à envoyer par Apache lorsqu’une URL se termine par / et concerne un répertoire entier.

<IfModule dir_module>
  DirectoryIndex index.html
</IfModule>

Les balises <Files> et </Files> contiennent des directives qui s’appliquent aux fichiers précisés.Ici par exemple, on interdit l’accès à tous les fichiers dont le nom commence par .ht, notamment .htaccess.

<Files ".ht*">
  Require all denied
</Files>

La directive ErrorLog définit le chemin vers le journal des erreurs. La verbosité de ce journal est contrôlée par la directive LogLevel.

ErrorLog "logs/error_log"
LogLevel warn

La directive CustomLog permet de contrôler la journalisation des requêtes destinées au serveur. Elle définit le nom et le format du fichier journal.

CustomLog "logs/access_log" combined

La directive AddDefaultCharset paramètre le jeu de caractères par défaut pour les pages de texte. Lorsqu’elle est désactivée (AddDefaultCharset off), Apache prend en compte l’encodage spécifié dans la balise <meta> des fichiers HTML à envoyer au navigateur.

meta http-equiv="Content-Type" content="text/html; charset=utf-8"

Ici en revanche, Apache utilise d’emblée le jeu de caractères spécifié en ignorant la balise <meta>.

AddDefaultCharset UTF-8

Configuration de base

Apache est immédiatement utilisable dans sa configuration par défaut. Avant d’héberger notre premier site, nous allons procéder à quelques ajustements.

Pour commencer, renseigner l’adresse mail de l’administrateur du serveur.

ServerAdmin info@microlinux.fr

Le nom du serveur peut être déterminé automatiquement, mais il vaut mieux le spécifier explicitement grâce à la directive ServerName.

ServerName amandine.microlinux.lan

Sur un serveur dédié, on aura ceci.

ServerName sd-100246.dedibox.fr

Pour la journalisation, on choisira un format un peu moins bavard.

CustomLog "logs/access_log" common

On permettra aux pages hébergées de spécifier leur propre encodage.

AddDefaultCharset off

Nous n’avons pas besoin des scripts CGI pour l’instant. Nous pouvons donc allègrement supprimer les stances correspondantes.

<IfModule alias_module>
  ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
</IfModule>
<Directory "/var/www/cgi-bin">
  AllowOverride None
  Options None
  Require all granted
</Directory>

Tester la nouvelle configuration.

$ apachectl configtest
Syntax OK

Prendre en compte les modifications.

$ sudo systemctl reload httpd

Héberger un site statique

Dans la configuration par défaut, Apache est censé servir le contenu de /var/www/html. En l’absence de contenu, c’est la page de test qui s’affiche, en fonction de la configuration prédéfinie dans /etc/httpd/conf.d/welcome.conf.

Pour nous épargner la corvée de créer du contenu bidon, nous pouvons très bien récupérer un site web existant. On choisira la documentation de Slackware, qui vient sous forme d’une série de pages HTML statiques.

$ cd /var/www/html/
$ sudo wget -r -np -nH --cut-dirs=1 http://www.slackbook.org/html/

Ouvrir le site dans un navigateur (Firefox, Links, Lynx) et apprécier le résultat.

Apache et les permissions de fichiers

Apache n’est pas censé tourner en tant que root, mais en tant qu’utilisateur spécial défini par les directives User et Group dans /etc/httpd/conf/httpd.conf.

User apache
Group apache

Une règle de sécurité générale, c’est que les contenus du serveur web ne doivent pas appartenir au processus qui fait tourner le serveur. Ici, nous attribuons les contenus à l’utilisateur non privilégié microlinux et au groupe associé microlinux. En passant, nous en profitons pour restreindre les droits d’accès du groupe.

$ sudo chown -R microlinux:microlinux /var/www/html/
$ cd /var/www/html/
$ find . -type d -exec chmod 0755 {} \;
$ find . -type f -exec chmod 0644 {} \;

Héberger plusieurs sites sur un serveur local

Le principe des hôtes virtuels (Virtual Hosts) consiste à faire fonctionner un ou plusieurs sites Web sur une même machine. L’utilisateur final ne perçoit pas qu’en fait il s’agit d’un même serveur physique.

Sur un serveur local, on pourra essayer d’héberger trois sites.

• http://slackware.amandine hébergera la documentation de Slackware.
• http://freebsd.amandine affichera la documentation de FreeBSD.
• http://amandine pointera vers la page par défaut du serveur.

Les trois sites seront rangés dans trois arborescences correspondantes.

• /var/www/slackware/html pour la documentation de Slackware.
• /var/www/freebsd/html pour la documentation de FreeBSD.
• /var/www/default/html pour la page par défaut du serveur.

Pour commencer, on va déplacer le site existant dans un nouveau répertoire /var/www/slackware/html.

$ cd /var/www
$ sudo mkdir -v slackware
mkdir: création du répertoire « slackware »
$ sudo mv html/ slackware/
$ sudo chown -R microlinux:microlinux slackware/

Puis, on va créer un autre répertoire /var/www/freebsd/html, dans lequel on va télécharger un autre site, en l’occurrence la documentation de FreeBSD.

$ sudo mkdir -pv freebsd/html
mkdir: création du répertoire « freebsd »
mkdir: création du répertoire « freebsd/html »
$ sudo chown -R microlinux:microlinux freebsd/
$ cd freebsd/html
$ wget -r -p -np -nH --cut-dirs=4 \
  http://www.freebsd.org/doc/fr_FR.ISO8859-1/books/handbook/

Enfin, on va mettre en place une page par défaut dans le répertoire /var/www/default/html. Pour ce faire, on va utiliser la page qui s’affiche lorsqu’il n’y a pas de contenu.

$ cd /var/www
$ sudo mkdir -pv default/html
mkdir: création du répertoire « default »
mkdir: création du répertoire « default/html »
$ sudo chown -R microlinux:microlinux default/
$ cp -R /usr/share/httpd/noindex/* default/html/

Il ne reste plus qu’à supprimer le répertoire cgi-bin qui ne sert à rien.

$ sudo rmdir cgi-bin

Au total, on a donc…

$ ls -l
total 12
drwxr-xr-x. 3 microlinux microlinux 4096 14 mars  10:05 default
drwxr-xr-x. 3 microlinux microlinux 4096 14 mars  10:02 freebsd
drwxr-xr-x. 3 microlinux microlinux 4096 14 mars  10:00 slackware

Créer un fichier /etc/httpd/conf.d/00-amandine.microlinux.lan.conf. Ce fichier définira le site affiché par défaut, c’est-à-dire lorsqu’on invoque l’adresse IP ou le nom d’hôte de la machine.

# /etc/httpd/conf.d/00-amandine.microlinux.lan.conf
#
# http://amandine.microlinux.lan
<VirtualHost *:80>
  ServerAdmin info@microlinux.fr
  DocumentRoot "/var/www/default/html"
  ServerName amandine.microlinux.lan
  ServerAlias amandine
  ErrorLog logs/amandine.microlinux.lan-error_log
  CustomLog logs/amandine.microlinux.lan-access_log common
</VirtualHost>

Dans le fichier /etc/httpd/conf/httpd.conf, il faudra supprimer toutes les références à l’ancien site par défaut.

DocumentRoot "/var/www/html"
...
<Directory "/var/www/html">
  Options Indexes FollowSymLinks
  AllowOverride None
  Require all granted
</Directory>

Tester la configuration.

$ apachectl configtest
Syntax OK

Prendre en compte les modifications.

$ sudo systemctl reload httpd

Vérifier si la page par défaut du serveur s’affiche comme prévu.

$ elinks http://amandine.microlinux.lan

À présent, nous pouvons ajouter les deux autres sites. Le site http://slackware.amandine sera configuré comme ceci.

# /etc/httpd/conf.d/10-slackware.amandine.conf
#
# http://slackware.amandine.microlinux.lan
<VirtualHost *:80>
  ServerAdmin info@microlinux.fr
  DocumentRoot "/var/www/slackware/html"
  ServerName slackware.amandine.microlinux.lan
  ServerAlias slackware.amandine
  ErrorLog logs/slackware.amandine-error_log
  CustomLog logs/slackware.amandine-access_log common
</VirtualHost>

La configuration de http://freebsd.amandine suivra la même logique.

# /etc/httpd/conf.d/10-freebsd.amandine.conf
#
# http://freebsd.amandine.microlinux.lan
<VirtualHost *:80>
  ServerAdmin info@microlinux.fr
  DocumentRoot "/var/www/freebsd/html"
  ServerName freebsd.amandine.microlinux.lan
  ServerAlias freebsd.amandine
  ErrorLog logs/freebsd.amandine-error_log
  CustomLog logs/freebsd.amandine-access_log common
</VirtualHost>

Pour l’instant, les noms d’hôtes slackware.amandine et freebsd.amandine ne correspondent à rien dans notre réseau local. Nous pouvons ajouter un DNS générique (DNS wildcard) à la configuration de Dnsmasq sur le serveur.

# Amandine
address=/amandine.microlinux.lan/192.168.2.5

Redémarrer Dnsmasq pour propager l’info DNS.

$ sudo systemctl restart dnsmasq

Prendre en compte la nouvelle configuration d’Apache.

$ sudo systemctl reload httpd

Tester les deux sites en local avec Links ou Firefox sur une machine du réseau local.

• http://slackware.amandine.microlinux.lan
• http://freebsd.amandine.microlinux.lan

Héberger plusieurs sites sur une machine publique

Sur un serveur dédié avec un ou plusieurs domaines publiquement accessibles, la configuration de la page par défaut ressemblera à ceci.

# /etc/httpd/conf.d/00-sd-100246.dedibox.fr.conf
#
# http://sd-100246.dedibox.fr
<VirtualHost *:80>
  ServerAdmin info@microlinux.fr
  DocumentRoot "/var/www/default/html"
  ServerName sd-100246.dedibox.fr
  ErrorLog logs/sd-100246.dedibox.fr-error_log
  CustomLog logs/sd-100246.dedibox.fr-access_log common
</VirtualHost>

La documentation de Slackware sera hébergée sur l’hôte www.slackbox.fr.

# /etc/httpd/conf.d/10-www.slackbox.fr.conf
#
# http://www.slackbox.fr
<VirtualHost *:80>
  ServerAdmin info@microlinux.fr
  DocumentRoot "/var/www/slackware/html"
  ServerName www.slackbox.fr
  ServerAlias slackbox.fr
  ErrorLog logs/www.slackbox.fr-error_log
  CustomLog logs/www.slackbox.fr-access_log common
</VirtualHost>

Et pour l’hébergement de la documentation de FreeBSD, on suivra la même logique.

# /etc/httpd/conf.d/10-www.unixbox.fr.conf
#
# http://www.unixbox.fr
<VirtualHost *:80>
  ServerAdmin info@microlinux.fr
  DocumentRoot "/var/www/freebsd/html"
  ServerName www.unixbox.fr
  ServerAlias unixbox.fr
  ErrorLog logs/www.unixbox.fr-error_log
  CustomLog logs/www.unixbox.fr-access_log common
</VirtualHost>

Tester l’affichage des différents sites.

• http://www.slackbox.fr (documentation de Slackware)
• http://slackbox.fr
• http://www.unixbox.fr (documentation de FreeBSD)
• http://unixbox.fr
• http://sd-100246.dedibox.fr (page par défaut)

Héberger des sites dynamiques avec PHP

CentOS 7 fournit PHP 5.4 par défaut, une version passablement ancienne. Les correctifs de sécurité sont certes rétroportés pour cette version, mais on risque d’avoir des problèmes avec certaines applications qui requièrent une version plus récente. L’installation de PHP 7.2 est décrite en détail dans cet article.

$ sudo yum install php

Mettre en place un hôte virtuel http://phpinfo.amandine et éditer la configuration correspondante. L’hôte virtuel contiendra une seule page index.php que l’on éditera comme ceci.

<?php
 echo phpinfo();
?>

La prise en compte de PHP nécessite de redémarrer Apache.

$ sudo systemctl restart httpd

Afficher la page http://phpinfo.amandine dans un navigateur. On doit obtenir quelque chose qui ressemble grosso modo à ceci.

Le fichier /etc/php.ini contient la configuration de PHP. On peut commencer par définir le fuseau horaire du serveur, nécessaire pour le bon fonctionnement de certaines applications. Au lieu d’éditer ce fichier directement, on va copier la stance correspondante dans un fichier /etc/php.d/date.ini en l’éditant comme ceci.

[Date]
; Defines the default timezone used by the date functions
; http://php.net/date.timezone
date.timezone = Europe/Paris

Redémarrer Apache et vérifier les données correspondantes dans la page qui affiche les infos PHP.

Utiliser MySQL/MariaDB à partir de PHP

Pour utiliser MySQL/MariaDB à partir de PHP, il suffit d’installer le module correspondant et de redémarrer Apache.

$ sudo yum install php-mysql
$ sudo systemctl restart httpd

Documentation

• La documentation officielle du projet
• Antoine Le Morvan : Serveur web Apache, Formatux
• Linux 2019, Michael Kofler (en allemand)

Crédits

Un grand merci à Antoine Le Morvan du projet Formatux pour la relecture technique et les nombreuses suggestions.

Merci à Remi Collet pour ses conseils pour la configuration de PHP.

---

La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.