La documentation officielle, https://httpd.apache.org/docs/current deviendra vite votre meilleure amie. Que ce soit pour vérifier la syntaxe d’un élément de configuration, savoir si une modification nécessite un redémarrage ou juste un rechargement d’Apache, trouver des exemples de configuration, c’est bien là qu’il vous faudra aller voir.
Ne croyez pas que la documentation est uniquement pour les débutantes : il est plus facile de savoir où chercher que de retenir les dizaines, centaines ou milliers d’éléments de configuration différents… même les plus usuels !
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.
Une directive est généralement constituée d’un nom de directive et de paramètres séparés par des espaces, sauf en ce qui concerne les directives appelées « conteneurs » (voir plus bas). Le nom des directives est insensible à la casse (vous pouvez donc les écrire avec ou sans majuscules) mais on les écrit généralement en Camel case1.
Exemple :
ServerRoot /var/www/html
Les conteneurs sont des directives spéciales sous forme de balises ouvrantes et fermantes qui vont permettre de limiter la portée des directives encadrées par ces balises. La balise ouvrante possédera généralement un ou des paramètres séparés par des espaces (mais peut aussi parfois ne pas en nécessiter).
Exemple :
<Directory /var/www/html/>
DirectoryIndex tennant.html index.html
</Directory>
Sur 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. L’inclusion de sous-répertoires permet de séparer le configuration en petits blocs facilement repérables, comme conf-available/security.conf
. Ce mécanisme est utilisé afin de faciliter la maintenance d’Apache par rapport à la philosophie de ces distributions.
Sur Debian, par exemple, il faut considérer le fichier apache2.conf
pour la configuration principale d’Apache, les sous-répertoires conf-available
pour des morceaux de configurations supplémentaires disponibles, et conf-enabled
pour les morceaux de configurations supplémentaires actifs (c’est-à-dire effectivement pris en compte par Apache), les sous-répertoires mod-available
et mod-enabled
pour les modules d’extension disponibles et actifs et enfin les sous-répertoires sites-available
et sites-enabled
pour la configuration des hôtes virtuels (les sites web) disponibles et actifs.
Exemple d’organisation de la configuration d’Apache dans Debian :
/etc/apache2
├── apache2.conf
├── conf-available
│ ├── apache2-doc.conf
│ ├── big_files_no_cache.conf
│ ├── …
│ └── serve-cgi-bin.conf
├── conf-enabled
│ ├── big_files_no_cache.conf -> ../conf-available/big_files_no_cache.conf
│ ├── …
│ └── serve-cgi-bin.conf -> ../conf-available/serve-cgi-bin.conf
├── envvars
├── magic
├── mods-available
│ ├── access_compat.load
│ ├── alias.conf
│ ├── alias.load
│ ├── …
│ ├── setenvif.conf
│ ├── setenvif.load
│ ├── ssl.conf
│ └── ssl.load
├── mods-enabled
│ ├── access_compat.load -> ../mods-available/access_compat.load
│ ├── alias.conf -> ../mods-available/alias.conf
│ ├── alias.load -> ../mods-available/alias.load
│ ├── …
│ ├── ssl.conf -> ../mods-available/ssl.conf
│ └── ssl.load -> ../mods-available/ssl.load
├── ports.conf
├── sites-available
│ ├── 000-default.conf
│ └── exemple.org
├── sites-enabled
│ └── 000-default -> ../sites-available/000-default.conf
└── ssl.conf
Attention ! Pour activer un morceau de configuration, un module ou un site disponible, on ne déplace pas son fichier de xxx-available
vers xxx-enabled
. On se contentera de faire un lien symbolique vers le fichier, par exemple : ln -s ../conf-available/apache2-doc.conf /etc/apache2/conf-enabled
.
Cette manière de faire permet de conserver les fichiers de configuration disponibles pour les activer et les désactiver à loisir, sans risquer de les supprimer définitivement. À noter que Debian fournit des utilitaires simplifiant l’activation et la désactivation des fichiers de configuration disponibles :
a2enconf
pour activer un morceau de configuration disponible, a2disconf
pour le désactiver ;a2enmod
et a2dismod
pour activer et désactiver des modules ;a2ensite
et a2dissite
pour activer et désactiver des sites.Avec l’exemple précédent, cela donnerait : a2enconf apache2-doc
.
Chaque directive agit dans un contexte2 particulier, c’est à dire que son action est limitée à ce contexte. 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 :
PidFile
, qui définit le fichier où Apache écrira son PID3), 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 de configuration globale 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.<VirtualHost>
.<Directory>
(relatif au répertoire utilisé pour répondre à la requête), <Files>
(relatif au fichier supposé être renvoyé), <Location>
(relatif à l’URI demandée), <If>
et <Proxy>
..htaccess
. Un fichier .htaccess
est un fichier de configuration complémentaire pouvant être placé dans les répertoires contenant les fichiers servis par Apache. Le but de ces fichiers est de décentraliser les directives liées à Apache, en permettant par exemple à un utilisateur « lambda » (c’est-à-dire non privilégié) 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).Attention : certaines directives peuvent être utilisée dans tous les contextes, d’autres uniquement dans un ou plusieurs contextes particuliers. La documentation officielle vous permettra de savoir dans quel contexte vous pouvez utiliser la directive souhaitée.
Voici quelques directives utilisables dans le contexte de configuration globale. Certaines lui sont propres (et donc ne peuvent être utilisées dans un autre contexte) et d’autres non (définissant ainsi les valeurs par défaut de ces directives comme vu plus haut).
Servername
: contient le nom d’hôte (nom de domaine) et le port que le serveur utilise pour s’authentifier lui-même. Placée dans un contexte d’hôte virtuel, cette directive définit généralement le nom de domaine auquel répondra le site configuré.ServerRoot
: correspond au répertoire d’installation d’Apache, contenant en particulier ses fichiers de configuration (/etc/apache2
sur Debian). 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 ou dossiers spécifiés (exemple : Include ports.conf
)IncludeOptional
: charge la configuration contenue dans les fichiers ou dossiers spécifiés mais ne génère pas d’erreur si ceux-ci n’existent pas (exemple : IncludeOptional conf-enabled/*.conf
)DocumentRoot
: permet de définir la racine des documents distribués par Apache (le répertoire où chercher les fichiers). Ce chemin est ainsi utilisé comme base pour le calcul des noms de fichiers correspondant aux requêtes reçues par le serveur.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. Cela permettra par exemple d’afficher une page 404 personnalisée.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 (par exemple DirectoryIndex index.html index.php index.htm
). Le premier fichier présent est renvoyé.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 force l’activation de cette option — action par défaut — et un « - » en force la désactivation. Notez que toutes les valeurs doivent être préfixées, ou aucune : il n’est pas possible de mixer des valeurs avec ou sans préfixe) :
ExecCGI
: autorise l’exécution de script CGIFollowSymLinks
: 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 SSI4 (Server-Side Includes, un langage de programmation interprété par les serveurs web)IncludesNOEXEC
: autorise les SSI, mais leurs commandes #exec
et #include
sont désactivéesIndexes
: 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.La documentation officielle, https://nginx.org/en/docs/ vous sera, ici aussi, très précieuse. Tout particulièrement les pages https://nginx.org/en/docs/dirindex.html et https://nginx.org/en/docs/varindex.html. Créez-vous des marque-pages dans votre navigateur !
Comme pour Apache, on retrouvera généralement 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-available
et modules-enabled
: 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 mais la configuration de cette fonctionnalité ne se fera pas dans conf.d
) ;sites-available
et sites-enabled
: dossiers contenant la 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 configurations d’hôtes virtuels. L’intérêt est de mutualiser la configuration (à quoi bon écrire 20 fois le même bout de configuration alors qu’une inclusion est plus rapide ?).
Les contextes Nginx n’ont rien à voir avec les contextes d’Apache.
une directive est constituée d’un nom de directive, de paramètres séparés par des espaces et se terminant par un point-virgule :
listen 80;
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;
}
}
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 moins5 au contexte de configuration globale d’Apache vu précédemment.
Les contextes possibles pour une directive peuvent varier selon cette directive (tout comme pour Apache). Ainsi, si internal
ne peut être placé que dans le contexte location
, la directive ignore_invalid_headers
peut être placée 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 https://nginx.org/en/docs/dirindex.html.
!!! 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 : un élément encadrant une ou des directives, ce qui en limite la portée. Par exemple, pour une directive n’agissant que pour le chemin /private/
(ex : https://exemple.org/private/
), on aura pour Apache :
<Location /private/>
Require all denied
</Location>
Et pour Nginx :
location /private/ {
deny all;
}
Si le contexte main
ressemble au contexte de configuration globale 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 de configuration globale 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 de configuration globale d’Apache, ne pourront se placer que dans server
(par exemple).
Le contexte d’hôte virtuel d’Apache est comparable au contexte server
de Nginx (équivalent du conteneur <Virtualhost>
d’Apache).
Le contexte répertoire d’Apache n’a pas vraiment d’équivalent strict, tant sont diverses les combinaisons entre directives et contextes dans lesquels on peut les placer.
On pourra obtenir des équivalences sur certaines configurations, comme entre le conteneur Apache <Location>
et le contexte Nginx location {}
, alors que d’autres configurations seront tout simplement impossibles à transcrire de façon similaire pour les mêmes buts.
.htaccess
Le contexte .htaccess
n’existe tout simplement pas avec Nginx. Ceci possède des avantages et des inconvénients :
.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)..htaccess
mal configuré.Certaines directives pourront prendre place dans le contexte Nginx main
, d’autres dans http
et d’autres encore dans d’autres contextes.
Servername
: server_name
(contexte : server
).ServerRoot
: pas de directive équivalente. Correspond à l’option --prefix
utilisée lors de la compilation.Include
: include
(contextes : tous)IncludeOptional
: pas de directive équivalente.DocumentRoot
: root
(contextes : http
, server
, location
, if
in location
).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.User
et Group
: user
(contexte :main
).DirectoryIndex
: index
(contextes : http
, server
, location
).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.Je ne sais pas si vous utilisez Vagrant pour faire des machines virtuelles pour les TP, mais si oui, vous pouvez faire ceci pour mettre en place des Vagrantfile configurés comme il faut pour les TP de ce cours :
wget -O bootstrap.sh https://lstu.fr/vagrant-asrall
# On regarde toujours le contenu d’un script téléchargé du net
# avant de l’exécuter !
cat bootstrap.sh
bash bootstrap.sh
Vous pouvez tenter de décommenter les lignes config.vm.synced_folder
dans les Vagrantfile, mais :
Ces config.vm.synced_folder
vous permettent d’avoir des dossiers partagés (configuration des serveurs web et dossier des sites web) entre votre machine et la machine virtuelle.
Si vous avez des questions à me poser, envoyez-les à asrall[CHEZ]fiat-tux.fr. Merci de bien vouloir :
darklordofchaos78@bidule.com
n’est pas très parlant pour moi)[asrall][TP 1]
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.
!!! ATTENTION !!! Ne modifiez JAMAIS la configuration du virtualhost par défaut (fichier 000-default.conf
) pour les exercices !
Faites toujours, avant chaque TP :
cd /etc/apache2/sites-available
cp 000-default.conf tp1.conf
a2dissite 000-default.conf
a2ensite tp1.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.
N’oubliez pas : 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 pendant, il en va tout autrement en production.
Prenez les bonnes habitudes tout de suite, relancez donc Apache avec :
apachectl -t && apachectl graceful
Cela permet de ne recharger Apache que si la syntaxe de la configuration est correcte (cela n’empêche pas de faire des erreurs de configuration, mais cela permet au moins d’éviter le crash d’Apache à cause d’une faute de frappe).
Sans Vagrant :
Installez Apache sur votre machine et lancez-le. Pointez un navigateur sur l’URL http://127.0.0.1 pour vérifier que tout fonctionne bien.
Avec Vagrant :
Lancez la machine virtuelle. Pointez un navigateur sur l’URL http://127.0.0.1:8080 pour vérifier que tout fonctionne bien.
NB : Ne modifiez que votre fichier tp1.conf
. Si les directives à utiliser sont utilisables dans le contexte d’hôte virtuel ou le contexte répertoire, mettez ces directives, ainsi que les conteneurs nécessaires éventuels entre les balises <VirtualHost>
de ce fichier. Si les directives doivent être placées dans le contexte de configuration globale, vous pouvez les mettre avant ou après les balises <VirtualHost>
du fichier. Exemple :
ThreadLimit 25
<VirtualHost *:80>
…
</VirtualHost>
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 :
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
├── index.html
├── foo
│ ├── index.html
│ └── accueil.html
└── bar
├── index.html
└── accueil.html
Pour cela :
mkdir /var/www/html/{foo,bar}
echo index | tee /var/www/html/{foo,bar}/index.html
echo accueil | tee /var/www/html/{foo,bar}/accueil.html
Pour définir une directive différente par répertoire, vous devrez utiliser le conteneur <Directory>
:
<Directory /var/www/html/foo>
VotreDirective son_argument
</Directory>
<Directory /var/www/html/bar>
VotreDirective son_autre_argument
</Directory>
Testez en allant sur http://127.0.0.1/foo/ et http://127.0.0.1/bar/ (ajoutez le port 8080
si vous utilisez Vagrant).
index.html
, par exemple) présent dans le répertoire, Apache ne renvoie pas une page HTML listant les fichiers présents dans le répertoire (la configuration par défaut sous Debian affiche le contenu du répertoire).mkdir /var/www/html/affichage/sous-rep/ -p
echo "Hello world" > /var/www/html/affichage/world.txt
echo "Hello sous répertoire" > /var/www/html/affichage/sous-rep/hello.txt
!!! ATTENTION !!! Ne modifiez JAMAIS la configuration du server par défaut pour les exercices !
Faites toujours, avant chaque TP :
cd /etc/nginx/sites-available
cp default tp1
rm /etc/nginx/sites-enabled/default
ln -s /etc/nginx/sites-available/tp1 /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.
N’oubliez pas, 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
Sans Vagrant :
Installez Nginx sur votre machine et lancez-le. Pointez un navigateur sur l’URL http://127.0.0.1 pour vérifier que tout fonctionne bien.
Avec Vagrant :
Lancez la machine virtuelle. Pointez un navigateur sur l’URL http://127.0.0.1.8081 pour vérifier que tout fonctionne bien.
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
├── index.html
├── foo
│ ├── index.html
│ └── accueil.html
└── bar
├── index.html
└── accueil.html
Pour cela :
mkdir /var/www/html/{foo,bar}
echo index | tee /var/www/html/{foo,bar}/index.html
echo accueil | tee /var/www/html/{foo,bar}/accueil.html
index.html
, par exemple) présent dans le répertoire, Nginx renvoie une page HTML listant les fichiers présents dans le répertoire (la configuration par défaut sous Debian affiche le contenu du répertoire).mkdir /var/www/html/affichage/sous-rep/ -p
echo "Hello world" > /var/www/html/affichage/world.txt
echo "Hello sous répertoire" > /var/www/html/affichage/sous-rep/hello.txt
telnet
Exercice à effectuer 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.
telnet localhost 80
(remplacez localhost
par l’adresse IP de votre serveur s’il n’est pas sur votre machine et le port 80
par 8080
ou 8081
si vous utilisez Vagrant) et établissez une requête avec la commande GET /
.GET / HTTP/1.0
.GET / HTTP/1.1
.Host: localhost
sur la ligne suivante (notez que dans notre cas, le nom de l’hôte pourrait être n’importe quoi).