Blog ENI : Toute la veille numérique !
🐠 -25€ dès 75€ 
+ 7 jours d'accès à la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Installation et configuration d'un serveur internet
  3. Serveur web (Apache/Nginx)
Extrait - Installation et configuration d'un serveur internet (BIND, Apache, Nginx, Dovecot, Postfix...)
Extraits du livre
Installation et configuration d'un serveur internet (BIND, Apache, Nginx, Dovecot, Postfix...)
2 avis
Revenir à la page d'achat du livre

Serveur web (Apache/Nginx) - Avancé

Introduction

La configuration de base du serveur web a déjà été traitée dans le chapitre Serveur web (Apache/Nginx) - Base. PHP est également déjà installé, ainsi que le gestionnaire de processus PHP FastCGI. De plus, quelques hôtes virtuels (Apache) ou serveurs virtuels (Nginx) ont déjà été créés : vert.example.com, bd.example.com et courriel.example.com. Les sections suivantes traiteront de quelques fonctionnalités plus avancées du serveur web et passeront en revue un certain nombre d’applications web instantanées et téléchargeables gratuitement.

www.example.com

Afin de rafraîchir les connaissances acquises dans les chapitres précédents, l’hôte virtuel www.example.com est d’abord créé. Pour cela, il faut suivre les étapes suivantes.

Alias DNS

Le nom www(.example.com) est un alias pour le nom d’hôte vert(.example.com). Pour cela, un enregistrement CNAME est créé, le numéro de série du fichier zone est incrémenté et la configuration named est rechargée.

Utilisateur

Le PHP-FPM sera exécuté sous le nom www-www. Le groupe primaire de cet utilisateur s’appelle également www-www et son répertoire personnel est /srv/www/www.example.com, mais ce répertoire n’est pas encore créé. L’utilisateur n’a pas de shell par défaut et n’appartient pas à des groupes supplémentaires. 

Répertoires

Le répertoire de base pour cet hôte virtuel est :  /srv/www/www.example.com. Dans ce répertoire se trouvent les sous-répertoires alias, bin, cgi-bin, conf, htdocs et tmp. Ceux-ci appartiennent à l’utilisateur devweb et au groupe devweb. On attribue le droit de lecture au serveur web et au PHP-FPM à l’aide des ACL ; de plus, on attribue au PHP-FPM le droit de modification pour le sous-répertoire tmp.

PHP-FPM

Le PHP-FPM est configuré...

CGI (Common Gateway Interface)

CGI est une interface permettant au serveur web d’exécuter des applications de ligne de commande et des scripts, et de présenter le résultat à l’utilisateur (à ne pas confondre avec la Computer-generated Imagery ou effets spéciaux numériques). Le PHP-FPM (PHP FastCGI Process Manager) décrit plus tôt est une variante de CGI, optimisée pour exécuter du code PHP.

Les scripts ou applications à exécuter par le serveur web sont installés dans un répertoire nommé cgi-bin (Common Gateway Interface Binaries). Au lieu de présenter les fichiers de ce répertoire aux visiteurs, le serveur web exécute les scripts ou applications et présente leur résultat (le flux STDOUT) aux visiteurs.

Le format du résultat des applications et scripts concernés doit répondre aux exigences suivantes :

<en-têtes HTTP> 
<ligne blanche> 
<contenu> 

Voici un exemple d’un script CGI très petit et simple :

#!/bin/sh 
 
echo "Content-Type: text/html" 
echo 
echo "<h1>Ça fonctionne !</h1>" 

Si ce script est enregistré dans le cgi-bin de www.example.com sous le nom test.sh et que le serveur web a le droit d’exécution, alors l’adresse...

Alias

Il est possible qu’un site web soit étalé sur plusieurs emplacements sur le serveur. Un exemple d’une telle configuration est un serveur qui héberge plusieurs sites web similaires, dont les images ont été enregistrées de façon centralisée. Un autre exemple est un site web fait maison www.example.com, où l’adresse www.example.com/wiki propose un wiki qui n’est pas fait maison. Dans ce cas, il est judicieux de séparer complètement le code du site web du code du wiki, de sorte que, d’une part, le wiki puisse être facilement mis à jour vers une nouvelle version, sans risque pour le site web, et que, d’autre part, cela empêche un développeur propriétaire de bricoler le code du wiki.

Apache et Nginx disposent tous deux d’un mécanisme simple pour présenter ces répertoires distincts aux visiteurs dans le cadre du site. La directive s’appelle Alias sur les deux serveurs.

1. Apache

Apache emploie la directive dans le contexte d’un hôte virtuel :

<VirtualHost *:443> 
    ServerName www.example.com 
 
    # L'Alias réfère à un chemin absolu 
    # quelque part dans le système de fichiers. 
    Alias "/images" "/srv/www/toutes_les_images" 
 
    # Évidemment, à part les permissions définies 
    # ci-dessous, Apache a aussi besoin d'un accès à ce 
    # répertoire au niveau du système de fichiers. 
    <Directory...

Contrôle d’accès

Apache et Nginx disposent tous deux de plusieurs mécanismes pour réguler l’accès aux (parties des) sites web.

Si les données d’un site web sont assez importantes pour limiter l’accès, le chiffrement TLS n’est pas optionnel. C’est encore plus important pour la configuration décrite ici, car elle envoie les mots de passe au serveur en texte clair.

1. Apache

La directive la plus importante pour limiter l’accès en Apache est Require ; cette directive est employée pour définir les conditions qu’un utilisateur doit remplir pour être admis ou bloqué. Les lignes suivantes se trouvent dans la configuration primaire d’Apache :

<Directory /> 
  Require all denied 
</Directory> 

Le verbe anglais deny signifie refuser en français, donc ces lignes assurent qu’Apache n’a pas d’accès à la racine du système de fichiers (/), et donc pas non plus au reste du système de fichiers, car chaque répertoire hérite des permissions de son répertoire parent, sauf si elles sont redéfinies explicitement.

À titre d’exemple, dans les hôtes virtuels décrits précédemment, on a déjà lu la ligne suivante :

Require all granted 

Le verbe anglais grant signifie accorder en français, donc cette ligne permet inconditionnellement l’accès au répertoire concerné (et ses sous-répertoires).

On a également déjà lu la ligne suivante :

Require ip 192.0.2.125 203.0.113.12 

Cette ligne limite l’accès aux visiteurs...

WebDAV

Le WebDAV (en anglais : Web-based Distributed Authoring and Versioning, rédaction et versionnage distribués sur le web) est une extension du HTTP, l’Hypertext Transfer Protocol, qui permet de créer, modifier, enregistrer, déplacer et supprimer des fichiers en ligne. Un grand nombre de services de stockage en ligne emploie le WebDAV, et la majorité des systèmes d’exploitation modernes, dont les smartphones et les tablettes, le supporte. La plupart des gestionnaires de fichiers (Windows Explorateur, Finder, Nautilus, Dolphin, PCManFM…) sait accéder aux emplacements WebDAV, et les applications de bureau comme LibreOffice, OpenOffice et Microsoft Office savent se servir de WebDAV pour ouvrir, modifier et enregistrer des documents.

Cela fait de WebDAV un moyen idéal pour le stockage et le partage en ligne des fichiers, ce qui le rend indispensable pour un serveur internet moderne. Mais, évidemment, le partage est optionnel : une petite modification de la configuration décrite ci-dessous permet de créer des répertoires WebDAV personnels pour, par exemple sauvegarder les fichiers des smartphones.

Il existe plusieurs implémentations des serveurs WebDAV, développées dans des langages de programmation divers. Les implémentations évoquées ici sont des modules pour les serveurs web déjà installés.

Même si cela fait du serveur WebDAV un hôte virtuel ou un serveur virtuel normal, dans le système de fichiers le serveur WebDAV (lecture et écriture) sera séparé des sites web (lecture seule). Évidemment, cela n’est pas obligatoire : le Filesystem Hierarchy Standard affirme explicitement que l’administrateur système est complètement libre dans l’organisation de l’arborescence sous /srv.

Pour assurer que seul le serveur web a le droit de modification dans ces répertoires, il est le propriétaire de cette arborescence et aucun autre droit n’est attribué à l’aide des ACL.

# mkdir -p /srv/dav/dav.example.com/{conf,htdocs,tmp} 
# chmod -R 0751 /srv/dav 
# chmod 2770 /srv/dav/dav.example.com/* 
 
freebsd# chown www:www /srv/dav/dav.example.com/* 
 
debian# chown www-data:www-data /srv/dav/dav.example.com/* 
 
centos+apache#...

Journaux et statistiques

Quiconque gère un site web veut savoir combien de visiteurs ce site reçoit, d’où ils viennent, quelles sont les heures de pointe, comment les visiteurs naviguent sur le site, etc., mais aussi où se trouvent les points chauds et quelles requêtes ont abouti en erreur 404 (Fichier introuvable).

Et, bien que toutes ces informations puissent être récupérées à partir des fichiers journaux du serveur web dans le répertoire /var/log, et qu’il soit certainement conseillé de les parcourir régulièrement (par exemple chaque semaine) pour identifier et résoudre les problèmes, ces fichiers journaux ne sont pas vraiment conviviaux pour un usage quotidien. Il est plus pratique et agréable d’utiliser un logiciel spécialisé qui collecte ces informations, les agrège et sait les présenter de différentes manières.

AWStats et Webalizer sont deux applications qui essayent de rendre plus compréhensibles les données de ces fichiers journaux. Ces applications importent les fichiers journaux du serveur web et génèrent des fichiers statiques HTML qui catégorisent les données et les affichent de façon plus graphique.

Les applications indiquées sont surtout orientées vers les administrateurs des serveurs web. Les départements...

Applications web clés en main

À la fin de ce chapitre, un certain nombre d’applications web intéressantes pour un serveur internet sont mentionnées. Ceci n’est qu’une toute petite sélection d’un nombre quasiment infini d’applications disponibles et cette sélection ne vise qu’à donner une idée des possibilités.

L’installation et l’utilisation de ces applications ne sont pas détaillées. En revanche, ces sujets sont abordés plus en détail sur les sites web de ces applications, dont les liens se trouvent dans les fichiers en téléchargement disponibles avec ce livre.

1. Site web complet

Un SGC ou Système de Gestion de Contenu (CMS ou Content Management System) est un système qui facilite la publication des informations sur internet. Un SGC est généralement une application web qui enregistre les données saisies dans une base de données ou un répertoire sur le serveur, pour ensuite les présenter en tant que site web aux visiteurs, à l’aide des modèles de présentation. La majorité des SGC peut être enrichie avec des modules (fonctionnalités) et des thèmes (graphisme du site web).

Pour un responsable de contenu expérimenté, un SGC peut être une solution idéale qui permet de gagner beaucoup de temps. En revanche, pour les personnes pour qui la maintenance d’un site web n’est pas un travail quotidien, un SGC peut être complexe et lourd...