L'installation, la configuration et l'exploitation d'un serveur apache peut devenir chronophage
Il faut souvent adapter la configuration lorsque l'on souhaite ajouter un hôte virtuel. Découvrez comment cela peut être
automatique. Un vhost à créer ? Un répertoire. Un vhost où l'utilisation du SSL est obligatoire ? Un lien symbolique.
Un vhosts où l'authentification est obligatoire ? Encore un lien symbolique.
Compliqué ? Pas tant que ça. Suivez le guide.
Limitations de la première partie
Dans l'épisode précédent, nous avions réussi à obtenir une gestion automatique (comprendre sans redémarrage d'Apache) des sous-domaines,
des accès SSL et de l'authentification. Cependant, ce système comporte plusieurs limitations, et de taille:
Les alias déclarés dans la configuration d'Apache ne sont plus fonctionnels.
Le bloc de règles de ré-écriture doit être copié dans chaque vhost.
Dans cette partie, nous allons tâcher de remédier à la première limitation.
Résumé de l'épisode précédent
Voici à quoi nous étions arrivés dans l'épisode précédent:
Support des alias
Le fait que les règles obtenues comportent toutes le flag [L] indique qu'Apache doit arrêter toute tentative de ré-écriture d'URL. Entre autre effet de bord, ceci a pour effet
de désactiver le support des Alias. Pourtant, ceux-ci sont parfois bien utiles, par exemple pour partager du code applicatif (blog en PHP) entre plusieurs vhosts.
Il faudrait donc pouvoir poursuivre la ré-écriture. Est-ce faisable/souhaitable dans tous les cas ? Non, notamment dans le cas des redirections d'URL (Règles 1 à 3).
Celles-ci devront donc conserver le flag [L]. Quant aux autres, nous allons essayer de les modifier pour qu'Apache soit capable d'y détecter les alias.
Première étape, là où nous transformons des URL en chemin absolus, il faudrait pouvoir conserver des URL et utiliser la directive DocumentRoot.
En fait, tout cela va être transparent pour vous: c'est Apache qui va d'abord considérer la ré-écriture comme un chemin absolu, puis comme un suffixe à DocumentRoot.
Je laisse pour l'instant de côté le bloc 4 (authentification) dans la mesure où nous aurons besoin des Alias pour le faire fonctionner correctement.
Le bloc 5 devient donc:
Malheureusement, ça ne marche toujours pas. Une lecture de la documentation apache consacrée à la ré-écriture d'URL
plus tard, nous avons une piste: il faut utiliser le flag PT (passthrough), qui, comme l'indique la documentation est utilisé justement pour les directives Alias (entre autre). Notre bloc devient alors:
Las, rien n'y fait. Si vous activez les logs (directive RewriteLog et RewriteLogLevel), vous constaterez que nos règles sont parcourues à nouveau. Argll !!
Pas vraiment ce que l'on cherchait. Mais, toujours dans les logs, vous constaterez que le contexte change: la première fois, nous sommes dans le contexte initial, et
nous passons ensuite dans le contexte subreq ou sous-requète. Et si nous cherchons subreq dans la documentation Apache (même page qu'au dessus), nous tombons sur un autre flag: NS pour nosubrequest.
Victoire ? Voyons donc ce que cela donne. Il faut maintenant indiquer quelles règles doivent être ou non prises en compte dans le contexte subreq. Il faut donc modifier toutes nos règles.
Le flag QSA, dont je n'ai pas parlé, est là pour rajouter les éventuels querystring à l'URL ré-écrite.
Et là, ça marche ! Si vous avez défini un Alias dans la configuration d'apache, celui-ci est maintenant pris en compte. Elle est pas belle la vie ?
Cas particulier de l'authentification
Voici venu le moment de résoudre le problème de l'authentification. Nous avons vu que les Alias sont maintenant supportés. Les plus observateurs (attentifs ?) d'entre vous ont constaté
que l'URL nécessitant l'authentification est préfixée par /auth (bloc n°4 pour les étourdis). Mais nous avons un tout petit problème: le répertoire n'existe pas.
C'est là qu'interviennent les Alias. Nous allons "bêtement" définir un Aliasauth qui pointera sur /var/www/mondomaine.com/config/auth/:
Configuration finale
Voici ce que donne la définition de notre vhost. Au passage, j'ai commenté le bloc n°3 dans le vhost SSL, ça évitera une boucle infinie :-/
Conclusion
Voilà un des problèmes identifiés au début résolu. Prochaine étape, éviter d'avoir à copier les règles dans chaque vhost. Impossible ? À voir. Une piste que je vous laisse creuser.
Quelques indices qui pourraient vous aider:
La directive DocumentRoot est disponible en variable d'environnement.
Toutes les directives RewriteCond peuvent être simplifiées: n'oubliez pas que vous êtes dans des vhosts avec des ServerName et des ServerAlias.
Enfin, et comme souvent (toujours ?): RTFM ;-) La directive RewriteOptions pourrait bien être votre amie
Format
Ce document est disponible aux formats suivants:
Un fichier (X)HTML en ligne que vous êtes en train de consulter.
Je suis responsable d'exploitation dans le domaine de l'hébergement. Je travaille, entre autres, sur la virtualisation et l'amélioration des
performances web. De temps en temps, j'arrive à décrocher de mon clavier pour lire un bon bouquin en écoutant de la musique.