Configuration de base

Luc Didry, à partir des cours de Sébastien Jean. Licence CC-BY-SA
Hello, handsome.
Le onzième docteur

Télécharger le PDF

Un petit mot sur les hôtes virtuels

C’est bien expliqué sur Wikipédia1, alors boum, citation :

En informatique, l'hébergement virtuel (de l'anglais virtual hosting abrégé vhost) est une méthode que les serveurs tels que serveurs Web utilisent pour accueillir plus d'un nom de domaine sur le même ordinateur, parfois sur la même adresse IP, tout en maintenant une gestion séparée de chacun de ces noms. Cela permet de partager les ressources du serveur, comme la mémoire et le processeur, sans nécessiter que tous les services fournis utilisent le même nom d'hôte. Le terme hébergement virtuel (virtual hosting) est utilisé habituellement en référence aux serveurs Web, mais les principes s'appliquent également à d'autres services internet.

Dans notre cas, les hôtes virtuels sont les différents sites web servis par Apache ou Nginx.

1 Apache

La documentation officielle, https://httpd.apache.org/docs/ deviendra vite votre meilleure amie.

1.1 Introduction

Le comportement d’Apache est contrôlé par un ensemble d’instructions appelées directives. Ces directives se décomposent en deux groupes : les directives natives, disponibles sur toute installation d’Apache, et les directives d’extension, liées aux extensions installées sur un serveur Apache particulier.

Sous certaines distributions, le fichier de configuration principal, apache2.conf est organisé de façon à sous-traiter les directives qu’il est sensé contenir à d’autres fichiers, contenus parfois dans des sous-répertoires du répertoire principal d’installation. Ce mécanisme est utilisé afin de faciliter la maintenance d’Apache par rapport à la philosophie de ces distributions. Sous Debian, par exemple, il faut considérer le fichier apache2.conf pour la configuration principale d’Apache, les sous-répertoires conf-xxx pour des morceaux de configurations supplémentaires, les sous-répertoires mod-xxx pour les modules d’extension et enfin les sous-répertoires sites-xxx pour la configuration des hôtes virtuels (les sites web).

Pour plus de lisibilité, le fichier apache2.conf est généralement divisé en 3 sections :

  1. Configuration de l’environnement global, traitant essentiellement du fonctionnement global des processus rattachés à Apache ;
  2. Section principale, contenant les directives du serveur principal. Ces directives sont également utilisées par défaut pour les hôtes virtuels si ceux-ci n’ont pas donné de nouvelles directives ;
  3. Section des hôtes virtuels, utilisée lorsqu’Apache traite les requêtes concernant plusieurs sites Web sur une même machine.

L’inclusion de sous-répertoires permet de séparer le configuration en petits blocs facilement repérables, comme conf-available/security.conf.

1.2 Portée et contexte des directives

Chaque directive agit dans un contexte particulier. Il est important de connaître et de comprendre ces contextes pour mesurer la portée des directives qui y sont définies. Les quatre contextes existants sous Apache sont :

  • Le contexte général du serveur. Ce contexte contient des directives qui ne peuvent être présentes qu’à cet endroit, ainsi que d’autres directives pouvant être également définies dans d’autres contextes. Pour ces dernières directives, une définition dans le contexte général du serveur permet de fixer une valeur par défaut à ces directives dans le cas où elles ne sont pas redéfinies dans d’autres contextes.
  • Le contexte conteneur. Ce contexte inclut les directives inclues dans un des 3 conteneurs suivant : <Directory> (relatif au répertoire utilisé pour répondre à la requêt), <Files> (relatif au fichier supposé être renvoyé), <Location> (relatif à l’URI demandée).
  • Le contexte d’hôte virtuel, défini par le conteneur <VirtualHost>.
  • Le contexte .htaccess, qui sont des fichiers de configuration complémentaires pouvant être placés dans les répertoires gérés par Apache. Le but de ces fichiers est de décentraliser les directives liées à Apache, en permettant par exemple à un utilisateur « lambda » de configurer les requêtes liées aux données qui le concerne sans avoir à modifier le fichier apache2.conf (ce qu’il ne peut pas faire normalement de toute façon).

1.3 Configuration du contexte général du serveur

  • Servername : contient le nom d’hôte de la machine sur laquelle s’exécute le serveur.
  • ServerRoot : correspond au répertoire d’installation d’Apache, contenant en particulier ses fichiers de configuration. Il est possible de changer au démarrage d’Apache la valeur donnée par cette directive grâce à l’option -d. C’est à partir de ce répertoire que seront calculés les chemins relatifs contenus dans les autres directives (comme Include par exemple).
  • Include : charge la configuration contenue dans les fichiers spécifiés
  • DocumentRoot : permet de définir la racine des documents distribués par Apache. Ce chemin est ainsi utilisé comme base pour le calcul des noms de fichiers correspondant aux requêtes reçues par le serveur.
  • ScriptAlias : permet de spécifier un répertoire contenant des scripts exécutables (se termine généralement par cgi-bin).
  • ErrorDocument : permet de changer le comportement par défaut d’Apache lorsqu’une erreur est rencontrée. Cette directive permet une redéfinition par code d’erreur, en affichant un message différent ou en redirigeant la requête vers un document traitant l’erreur en question.
  • DefaultType : permet de redéfinir le type MIME par défaut des documents renvoyés par le serveur (rarement utilisée dans un contexte général).
  • User et Group : permettent de définir sous quelle identité s’exécuteront les fils du processus principal Apache.
  • DirectoryIndex : définit dans l’ordre la liste des fichiers qui doivent être recherchés lorsqu’une requête concerne un répertoire. Le premier fichier présent est renvoyé.
  • UserDir : permet de fournir des répertoires Web individuels aux utilisateurs d’un système.
  • Options : permet de contrôler certaines fonctionnalités du serveur dans un répertoire particulier. Cette directive peut être associée aux valeurs suivantes (un « + » en préfixe d’une valeur active cette option — action par défaut — et un « - » la désactive) :
    • ExecCGI : autorise l’exécution de script CGI
    • FollowSymLinks : le serveur peut suivre les liens symboliques de ce répertoire, mais cela ne change pas la correspondance établie avec les sections <Directory>.
    • Includes : autorise les SSI (Server-Side Includes)
    • IncludesNOEXEC : autorise les SSI, mais leurs commandes #exec et #include sont désactivées
    • Indexes : renvoie une liste formatée de ce répertoire si une requête concernant ce répertoire est établie et qu’il n’existe pas de fichier correspondant à une des valeurs de la directive DirectoryIndex.
    • Multiviews : autorise les multiviews à contenu négocié (par exemple pour fournir foo.fr.html ou foo.en.html selon la préférence du navigateur quand la ressource foo est demandée)
    • SymLinksIfOwnerMatch : suit les liens symboliques dont le fichier ou le répertoire appartient au même utilisateur que le lien.
    • All : inclut toutes les options, sauf Multiviews. C’est la valeur par défaut.
    • None : aucune de ces options.
  • IndexOptions (avec la valeur FancyIndexing) : fournit un listage du contenu des répertoires plus agréable lorsque l’option Indexes est activée.

2 Nginx

La documentation officielle, http://nginx.org/en/docs/ vous sera, ici aussi, très précieuse. Tout particulièrement les pages http://nginx.org/en/docs/dirindex.html et http://nginx.org/en/docs/varindex.html. Créez-vous des marque-pages dans votre navigateur !

Comme pour Apache, on retrouvera un découpage de la configuration en plusieurs fichiers répartis dans différents répertoires.

Sur Debian : - nginx.conf : fichier de configuration générale, qui contient des inclusions d’autres fichiers de configuration ; - modules-xxx : dossiers contenant les fichiers permettant l’activation des modules de Nginx ; - conf.d : contient des fichiers de configuration générale pour le serveur web (Nginx peut aussi faire office de proxy mail) ; - sites-xxx : configuration des hôtes virtuels.

Le dossier snippets est particulier : il ne fait pas l’objet d’inclusions dans la configuration de base. Il est là pour vous permettre de ranger des bouts de configuration que vous pourrez alors vous-même inclure dans vos configuration. L’intérêt est de mutualiser la configuration (à quoi bon écrire 20 fois la même configuration alors qu’une inclusion est plus rapide ?).

2.1 Directives et contextes

  • une directive est constituée d’un nom de directive, de paramètres séparés par des espaces et se terminant par ; :

    ssl on;
  • les contextes ont une structure similaire à ceci près qu’ils se terminent par des accolades encadrant des directives ou des contextes supplémentaires :

    http {
        server {
            server_name example.org;
        }
    }

2.2 Portée des directives

Les directives peuvent être positionnées dans zéro, un ou plusieurs contextes. Lorsqu’elles ne peuvent être positionnées dans aucun contexte, on parlera du contexte main, correspondant plus ou moins2 au contexte général d’Apache vu plus haut.

Les contextes possibles pour une directive peuvent varier selon cette directive3. Ainsi, si internal ne peut être placé que dans le contexte location, ignore_invalid_headers peut être placé dans les contextes http et server.

Pour trouver dans quel contexte doit se situer une directive, reportez-vous à la documentation officielle. La liste alphabétique des directives et des contextes est disponible sur http://nginx.org/en/docs/dirindex.html.

3 Contextes Apache et Nginx

3.1 Différences

!!! ATTENTION !!! Ne pas confondre les contextes Apache et Nginx, j’utilise le même terme mais ils ne désignent pas la même chose.

Les contextes Nginx sont plutôt similaires aux conteneurs d’Apache.

Si le contexte main ressemble au contexte général d’Apache, il existe toutefois une différence de taille. En effet, Nginx n’est pas qu’un serveur web, il peut aussi faire office de proxy mail. Dès lors, les directives du contexte général d’Apache relatives au programme lui-même (User et Group) auront bien généralement des directives équivalentes (user, qui permet aussi de définir le groupe auquel appartient le processus), tandis que celles qui ne sont utiles que dans le cadre d’un serveur web, comme ErrorDocument auront une directive équivalente à placer dans le contexte http. Et d’autres, bien qu’on puisse penser qu’elles pourraient se placer dans le contexte http puisqu’étant dans le contexte général d’Apache, ne pourront se placer que dans server (par exemple).

Le contexte conteneur d’Apache n’a pas vraiment d’équivalent, tant sont diverses les combinaisons entre directives et contextes dans lesquels on peut les placer.

Le contexte d’hôte virtuel d’Apache est, lui, comparable au contexte server.

Enfin, le contexte .htaccess n’existe tout simplement pas avec Nginx. Ceci possède des avantages et des inconvénients.

  • On ne peut laisser la possibilité à un utilisateur « lambda » de modifier le comportement du serveur dans les répertoires le concernant : on risque donc plus d’avoir des demandes d’utilisateur. De plus, de nombreux projets proposent des fichiers .htaccess pour adapter le serveur aux besoins particuliers du projet : il faudra traduire ces besoins en configuration Nginx (ce sont généralement des réécritures d’URL, un vrai bonheur à traduire).
  • Par contre, comme Nginx ne regardant pas dans chaque répertoire traversé s’il n’existe pas un .htaccess à prendre en compte, la vitesse est accrue. De plus, cela évite les erreurs de configuration des utilisateurs, sur lesquelles on s’arrache parfois les cheveux à cause d’un .htaccess mal configuré.

3.2 Équivalents Nginx des directives de configuration du contexte général d’Apache

Je vous présente mes excuses pour cet inventaire à la Prévert, mais j’essayerai, lors de ce cours, et autant que faire ce peut, de vous permettre de configurer aussi bien Apache que Nginx pour des mêmes tâches.

Certaines directives pourront prendre place dans le contexte main, d’autres dans http et d’autres encore dans d’autres contextes4.

  • Servername : server_name (contexte : server).
  • ServerRoot : pas de directive équivalente. Correspond à l’option --prefix utilisée lors de la compilation.
  • Include : include (contextes : tous)
  • DocumentRoot : root (contextes : http, server, location, if in location).
  • ScriptAlias : pas d’équivalent, Nginx ne permettant pas d’utiliser des scripts CGI.
  • ErrorDocument : error_page (contextes : http, server, location, if in location), mais ne permet pas de spécifier de message. Uniquement une page ou une redirection.
  • DefaultType : default_type (contextes : http, server, location).
  • User et Group : user (contexte :main).
  • DirectoryIndex : index (contextes : http, server, location).
  • UserDir : pas d’équivalent, mais on peut se débrouiller avec des expressions rationnelles dans un contexte location5.
  • Options : pas d’équivalent, mais on trouve parfois des directives équivalentes pour les options.
    • ExecCGI : pas d’équivalent.
    • FollowSymLinks : disable_symlinks (contextes : http, server, location).
    • Includes : ssi (contextes : http, server, location, if in location).
    • IncludesNOEXEC : pas d’équivalent.
    • Indexes : autoindex (contextes : http, server, location).
    • Multiviews : pas d’équivalent.
    • SymLinksIfOwnerMatch : voir disable_symlinks.
    • All et None : pas d’équivalent.
  • IndexOptions : pas d’équivalent.

4 Exercices

Si vous avez des questions à me poser, envoyez-les à asrall[CHEZ]fiat-tux.fr. Merci de bien vouloir :

  • utiliser votre adresse étudiante fournie par l’université (cela m’évite d’avoir à chercher qui m’a envoyé le mail si vous oubliez de mettre votre nom. darklordofchaos78@bidule.com n’est pas très parlant pour moi)
  • mettre comme sujet [asrall][TP 1]
  • mettre votre nom dans le mail

Les exercices sont à rendre sur https://lstu.fr/asrall-web-tp1. Envoyez vos réponses dans un fichier appelé tp1_votre_nom.txt.

Vous pouvez envoyer un seul fichier pour un binôme, mais pensez bien à mettre vos deux noms dans le nom du fichier.

Ces exercices ont pour but, non pas de récupérer forcément de bonnes réponses (vous êtes là pour apprendre après tout), mais de voir comment vous appréhendez les problèmes et comment vous vous y prenez pour vous en sortir. Les exercices ont aussi pour but de vous habituer à rechercher des informations dans la documentation officielle des projets. En effet, à force d’habitude, vous saurez où chercher l’information idoine rapidement.

La réponse à ces exercices est OBLIGATOIRE. Des points bonus pourront être attribués si les exercices ont bien été faits et que les réponses ne sont pas dénuées de sens.

4.1 Apache

!!! ATTENTION !!! Ne modifiez JAMAIS la configuration du virtualhost par défaut pour les exercices !

Faites toujours :

cd /etc/apache2/sites-available
cp 000-default.conf td1.conf
a2dissite 000-default.conf
a2ensite td1.conf
apachectl -t
apachectl graceful

Cela vous permettra d’avoir toujours une configuration propre sous la main, et de ne pas effacer vos travaux de la semaine précédente.

a2dissite et a2ensite ne sont pas des outils fournis par Apache mais par Debian. Ils permettent de désactiver et d’activer aisément des sites dans la configuration d’Apache. Il existe aussi a2dismod et a2enmod pour désactiver et activer rapidement des modules Apache, ainsi que a2disconf et a2enconf pour désactiver et activer les morceaux de configuration contenus dans les sous-répertoires conf-xxx.

apachectl -t effectue une vérification de la configuration. Pensez à toujours utiliser cette commande avant de relancer Apache. Si une configuration ratée ne prête pas à conséquence en cours, il en va tout autrement en production.

Prenez les bonnes habitudes tout de suite, relancez donc Apache avec :

apachectl -t && apachectl graceful

Installez Apache sur votre machine et lancez-le. Pointez un navigateur sur l’URL http://ip_de_la_machine pour vérifier que tout marche bien.

4.1.1 Configuration par défaut

  1. Décrivez l’organisation des fichiers de configuration proposée par votre distribution.
  2. Donner un moyen (simple) de lire toute la configuration utilisée par le serveur sur la sortie standard6 (et donc de la lire confortablement avec votre $PAGER favori) ;

4.1.2 Quelques exercices de configuration

En vous basant sur le cours, en vous inspirant des fichiers de configuration et en parcourant la documentation relative à Apache, répondez aux questions suivantes :

  1. Comment définir le fichier renvoyé par défaut lorsque la requête correspond à un nom de répertoire plutôt qu’à un nom de fichier ? Faites un test en définissant index.html pour un répertoire et accueil.html pour un autre. Placez ces deux fichiers dans chacun des répertoires et vérifiez votre configuration.

Vous devez avoir une arborescence similaire à :

└── var
    └── www
        └── html
            ├── foo
            │   ├── index.html
            │   └── accueil.html
            └── bar
                ├── index.html
                └── accueil.html
  1. Comment autoriser le listage du contenu d’un répertoire ? Faites un test sur un répertoire pour vérifier votre configuration. Quel est l’impact pour les sous-répertoires du répertoire d’origine ? Comment supprimer le listage dans les sous-répertoires ?
  2. Afficher le contenu des répertoires avec un style « fancy », ou sans ce style si votre serveur était déjà configuré avec ce style.
  3. Comment autoriser les utilisateurs de votre système à utiliser un répertoire de leur home directory via Apache ? Vérifiez que votre solution marche.
  4. Configurez votre serveur Web pour qu’il :
    • supporte les connexions persistantes ;
    • accepte 50 requêtes au maximum par connexion ;
    • crée 4 processus au démarrage ;
    • accepte au maximum 30 clients en même temps.

Comment avez-vous vérifié la prise en compte de ces valeurs ?

4.2 Nginx

!!! ATTENTION !!! Ne modifiez JAMAIS la configuration du server par défaut pour les exercices !

Faites toujours :

cd /etc/nginx/sites-available
cp default td1
rm /etc/nginx/sites-enabled/default
ln -s /etc/nginx/sites-available/td1 /etc/nginx/sites-enabled/
nginx -t
nginx -s reload

Cela vous permettra d’avoir toujours une configuration propre sous la main, et de ne pas effacer vos travaux de la semaine précédente.

nginx -t effectue une vérification de la configuration. Pensez à toujours utiliser cette commande avant de relancer Nginx. Si une configuration ratée ne prête pas à conséquence en cours, il en va tout autrement en production.

Prenez les bonnes habitudes tout de suite, relancez donc Nginx avec :

nginx -t && nginx -s reload

Installez Nginx sur votre machine et lancez-le. Pointez un navigateur sur l’URL http://ip_de_la_machine pour vérifier que tout marche bien.

Si Nginx ne veut pas se lancer, demandez-vous si par hasard vous n’avez pas installé Apache sur la même machine et s’il ne squatte pas déjà le port 80 : un même port ne peut être utilisé que par un processus à la fois.

4.2.1 Quelques exercices de configuration

  1. Comment définir le fichier renvoyé par défaut lorsque la requête correspond à un nom de répertoire plutôt qu’à un nom de fichier ? Faites un test en définissant index.html pour un répertoire et accueil.html pour un autre. Placez ces deux fichiers dans chacun des répertoires et vérifiez votre configuration.
  2. Comment supprimer le listage du contenu d’un répertoire ? Faites un test sur un répertoire pour vérifier votre configuration. Quel est l’impact pour les sous-répertoires du répertoire d’origine ? Comment autoriser le listage dans les sous-répertoires ?

4.3 Connexion avec telnet

Effectuez cet exercice avec Apache ou Nginx, cela n’a pas d’importance.

telnet permet d’établir des connexions à distance, en précisant éventuellement le port demandé. Sachant que les serveurs Web s’exécutent normalement en écoutant les requêtes du port 80, il est alors possible de se connecter avec telnet sur un serveur Web et de lui faire des requêtes en utilisant le protocole HTTP.

  1. Connectez-vous avec la commande telnet localhost 80 et établissez une requête avec la commande GET /. Quel résultat vous est retourné ? Comment se finit la connexion ?
  2. La commande précédente correspondait à la norme 0.9. Pour établir une connexion en utilisant 1.0, tapez maintenant la commande GET / HTTP/1.0. Que constatez-vous par rapport à la commande précédente ?
  3. Enfin, pour établir une commande utilisant 1.1, utilisez la commande GET / HTTP/1.1. Que constatez-vous ?
  4. Pour remédier au problème de la question précédente, il faut ajouter le nom du serveur auquel vous faites la demande (localhost dans notre cas). Retapez la commande en ajoutant Host: localhost sur la ligne suivante. Quel est, selon vous, l’intérêt de cette évolution du protocole ?

  1.  https://fr.wikipedia.org/wiki/H%C3%A9bergement_virtuel, consulté le 12 nov. 2018

  2.  voir la section suivante

  3.  ceci est aussi valable pour Apache

  4.  quand je vous disais que les contextes Apache et Nginx étaient différents

  5.  il suffit de chercher des exemples sur le net, comme https://gist.github.com/alanbriolat/1248004

  6.  Vous cherchez donc à concaténer des fichiers


https://asrall.fr