Apache est un des serveurs web les plus populaires 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 d’un tiers des sites Web de la planète 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.
L’objectif de ce premier article sur Apache consistera à découvrir les fonctionnalités de base dans le but d’héberger un site web statique sur une machine locale et/ou un serveur dédié avec une ouverture frontale sur Internet.
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 :
- Le client ouvre une connexion TCP vers le serveur et envoie une requête.
- 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: Thu, 03 Feb 2022 20:54:49 GMT ETag: "3c6282-1889-5d723584fb840" Accept-Ranges: bytes Content-Length: 6281 Content-Type: text/html Date: Thu, 27 Apr 2023 07:15:19 GMT Connection: keep-alive
Le rôle du serveur web consiste à traduire une URL (c’est-à-dire quelque chose comme 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 « localisateur uniforme de ressource ») 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 :
# firewall-cmd --permanent --add-service=http success # firewall-cmd --reload success # firewall-cmd --list-services http ssh
Notons que théoriquement, l’administrateur peut choisir librement le port d’écoute du serveur. En pratique, sachez que dans ce cas vous risquez de vous exposer à des souffrances innommables avec SELinux.
Installation
Sous Red Hat Enterprise Linux et toutes les distributions dérivées, le serveur Apache est fourni par le paquet httpd dans les dépôts officiels :
# dnf install -y httpd
L’installation du paquet crée un utilisateur système apache et un groupe système apache correspondant :
# grep apache /etc/{passwd,group,shadow}
/etc/passwd:apache:x:48:48:Apache:/usr/share/httpd:/sbin/nologin
/etc/group:apache:x:48:
/etc/shadow:apache:!!:19474::::::
Premier lancement du serveur
Sous Red Hat Enterprise Linux et Rocky Linux, Apache est préconfiguré pour afficher une page statique par défaut. Il suffit d’activer et de lancer le service :
# systemctl enable httpd --now
Installez le navigateur en mode texte ELinks :
# dnf install -y elinks
Testez le bon fonctionnement du serveur :
$ elinks http://localhost
Si tout se passe bien, vous devez voir quelque chose de ce genre :
Dans le réseau local, ouvrez l’adresse IP du serveur avec un navigateur web :
http://192.168.2.3
Vous pouvez également invoquer le nom d’hôte :
http://sandbox.microlinux.lan
Sur un serveur dédié, on essaiera de même l’adresse IP et le nom d’hôte associé :
http://51.158.146.161http://sandbox.microlinux.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 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 :
# cd /etc/httpd/conf
# mv httpd.conf httpd.conf.orig
# grep -Ev '^#|^$|^[ ]{4}#|^[ ]{6}#' httpd.conf.orig > httpd.conf
Ici, la commande grep utilise une expression régulière étendue pour filtrer les lignes qui commencent soit par un commentaire (^#), soit par une espace (^$), soit par quatre espaces suivis d’un commentaire (^[ ]{4}#), soit par six espaces suivis d’un commentaire (^[ ]{6}#).
La configuration par défaut
Jetons un œil 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 racine du serveur, ce qui permet à Apache de localiser les fichiers de configuration et les fichiers de support nécessaires à l’exécution du serveur :
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, renseignez l’adresse mail de l’administrateur du serveur. Oui, utilisez votre adresse mail, pas la mienne :
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 sandbox.microlinux.lan
Sur un serveur dédié, on aura quelque chose comme ceci :
ServerName sd-155842.dedibox.fr
Dans les deux exemples ci-dessus, j’ai renseigné le FQDN (Fully Qualified Domain Name) du serveur. Utilisez la commande hostname --fqdn pour afficher le FQDN de votre machine.
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>
Testez la nouvelle configuration :
# apachectl configtest Syntax OK
Prenez en compte les modifications :
# 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. Au hasard tout en choisissant bien, je récupère la documentation archivée de Slackware Linux, qui vient sous forme d’une série de pages HTML statiques :
# cd /var/www/html/ # wget -r -np -nH --cut-dirs=1 http://www.slackbook.org/html/
Ouvrez le site dans un navigateur web (Firefox, Links, Lynx) et appréciez 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, j’attribue les contenus à l’utilisateur non privilégié microlinux et au groupe associé microlinux. En passant, j’en profite pour restreindre les droits d’accès du groupe :
# chown -R microlinux:microlinux /var/www/html/
# cd /var/www/html/
# find . -type d -exec chmod 0755 {} \;
# find . -type f -exec chmod 0644 {} \;
Certaines distributions – notamment toutes celles de la famille Debian – disposent d’un utilisateur non privilégié www-data et d’un groupe www-data correspondant pour le contenu web. Les distributions de la famille Red Hat ne fournissent pas cet utilisateur dans leur configuration par défaut.
La suite au prochain numéro, où nous allons faire fonctionner plusieurs sites sur une même machine grâce aux hôtes virtuels.
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.
0 commentaire