Valider la réécriture et les erreurs

Une configuration peut passer le test de syntaxe et pourtant ne pas servir les bonnes pages. Vous allez vérifier les URL des deux hôtes, puis produire des erreurs temporaires pour confirmer que les réponses et les journaux concordent.

Vous poursuivez le projet avec les deux hôtes site.example.test et api.example.test, leurs racines déjà déployées et les trois fichiers de configuration convenus. Les noms en .test servent ici d’exemple de test : remplacez l’adresse IP ci-dessous par celle du serveur qui héberge Apache. Les principes de configuration des hôtes et de consultation des journaux ont été présentés dans les leçons précédentes.

1. Exécuter la recette des URL

Vérifiez chaque nom séparément : les réponses doivent correspondre à la racine prévue pour cet hôte. La requête /accueil teste en plus la règle déjà mise en place sur l’hôte principal. Avec curl -i, vous voyez le code HTTP et les en-têtes ; l’option --resolve dirige le nom demandé vers l’adresse de test sans changer le nom d’hôte envoyé à Apache.

IP_SERVEUR=192.0.2.10

curl -i --resolve site.example.test:80:$IP_SERVEUR \
  http://site.example.test/accueil
curl -ik --resolve site.example.test:443:$IP_SERVEUR \
  https://site.example.test/accueil
curl -i --resolve api.example.test:80:$IP_SERVEUR \
  http://api.example.test/
curl -ik --resolve api.example.test:443:$IP_SERVEUR \
  https://api.example.test/

Les requêtes HTTP doivent répondre par une redirection vers HTTPS, en conservant le chemin demandé. Les requêtes HTTPS doivent répondre avec le contenu de l’hôte correspondant. L’option -k ignore la vérification du certificat : réservez-la aux tests si le certificat n’est pas reconnu par votre machine.

Remplacez 192.0.2.10 par l’adresse réelle du serveur : cette adresse est réservée à la documentation et ne désigne pas votre machine. En environnement de production, retirez -k pour vérifier aussi la confiance accordée au certificat. Si un résultat ne correspond pas à l’attendu, notez l’heure, le nom d’hôte, l’URL et le code reçu avant de consulter les journaux.

2. Produire un refus 403 sans laisser de changement

Pour tester le diagnostic d’un refus d’accès, choisissez un fichier temporaire situé dans la racine de l’hôte, par exemple /var/www/api/journal.html. Notez d’abord ses permissions, puis retirez temporairement le droit de lecture pour le processus Apache. N’effectuez pas ce test sur un fichier critique et restaurez immédiatement les permissions initiales après la requête ; ne remplacez pas les droits d’un répertoire entier.

stat -c '%a %U:%G %n' /var/www/api/journal.html
sudo chmod 000 /var/www/api/journal.html
curl -ik --resolve api.example.test:443:192.0.2.10 \
  https://api.example.test/journal.html
sudo chmod 644 /var/www/api/journal.html

Pendant le test, curl doit recevoir un refus 403. La commande chmod 644 restaure un mode courant pour un fichier statique ; si le mode initial affiché par stat était différent, rétablissez précisément ce mode à la place. Vérifiez ensuite de nouveau les permissions.

Un 403 indique que le serveur refuse l’accès ; le journal d’erreurs peut préciser si le refus vient des permissions ou d’une règle d’accès. Si Apache peut lire le fichier malgré le changement, contrôlez l’utilisateur du service et les permissions des répertoires parents : chaque répertoire du chemin doit pouvoir être traversé. Ne corrigez pas le problème en accordant des droits d’écriture à Apache sur les contenus statiques.

3. Produire une erreur 500 avec une règle temporaire

Pour obtenir une réponse 500 de manière reproductible, ajoutez temporairement à la configuration HTTPS de l’hôte principal une règle limitée à une URL de diagnostic. Insérez-la dans le contexte de l’hôte virtuel, avant toute règle qui pourrait traiter cette URL. Elle renvoie une erreur serveur uniquement pour /diagnostic-500 ; elle ne doit pas rester en place après la recette.

RewriteRule ^diagnostic-500$ - [R=500,L]

Après l’ajout, testez la configuration avant de recharger Apache. Si le test échoue, annulez la modification et ne rechargez pas. S’il réussit, rechargez, appelez l’URL avec curl, puis supprimez la règle de diagnostic, relancez apachectl configtest et ne rechargez qu’après un résultat réussi. Ne confondez pas cette erreur volontaire avec une panne applicative réelle.

sudo apachectl configtest
sudo systemctl reload apache2
curl -ik --resolve site.example.test:443:192.0.2.10 \
  https://site.example.test/diagnostic-500
# Après le test : supprimer la règle temporaire, puis valider à nouveau.
sudo apachectl configtest
sudo systemctl reload apache2

La requête /diagnostic-500 doit répondre avec le code 500 pendant le test. Après retrait de la règle et rechargement, cette URL ne doit plus produire le 500 provoqué par la règle.

4. Corréler les réponses avec les journaux

Consultez les journaux propres à l’hôte concerné, en utilisant les chemins réellement déclarés dans ses fichiers de configuration. Les journaux d’accès confirment l’heure, l’URL et le code de réponse ; le journal d’erreurs donne les messages utiles pour interpréter le refus ou l’erreur. Les chemins ci-dessous correspondent au journal d’erreurs du projet si ce nom de fichier est bien celui configuré.

sudo tail -n 30 /var/log/apache2/application-error.log
sudo tail -n 30 /var/log/apache2/application-access.log

Pour chaque essai, consignez l’heure, le nom d’hôte, l’URL, le code HTTP, l’extrait pertinent du journal et l’action de rétablissement effectuée. Pour le 403, attendez-vous à une entrée d’accès en 403 et à un message lié au refus de lecture ou aux permissions. Pour le 500 forcé par la règle, l’accès doit enregistrer le code 500 ; le journal d’erreurs ne montrera pas nécessairement une panne interne, puisque cette réponse a été demandée volontairement par la règle.

À retenir