Configuration
Le répertoire du cache du serveur mandataire doit être soigneusement configuré et appartenir à l’utilisateur webuser et au groupe webgroup car c’est cet insignifiant personnage qui y accède (voir le chapitre 2).
Vous devez maintenant indiquer à votre navigateur que vous accédez au Web via un mandataire. Avec Netscape/Mozilla, par exemple, cliquez sur Édition ® Préférences ® Avancées ® Proxies ® Configuration manuelle du proxy. Entrez l’adresse IP de votre mandataire dans le champ Proxy HTTP, qui est sur le même réseau 192.168.123 que votre navigateur :
192.168.123.4
Mettez 8000 dans le champ de saisie Port.
Pour configurer Microsoft Internet Explorer, choisissez Outils ® Options Internet ® Onglet Connexions. Cliquez sur le bouton Paramètres pour configurer le proxy, puis sur le bouton Configuration et configurez le mandataire HTTP comme nous l’avons décrit ci-dessus. C’est tout ce qu’il y a à faire.
Vous pourriez vouloir simuler le fonctionnement du mandataire, comme nous l’avons fait, avant de le mettre en service. Cependant, simuler un serveur mandataire sur une seule machine n’est pas si simple que cela et, lorsque nous l’avons fait, les éléments ont joué des rôles différents de ceux qu’ils avaient joué jusqu’alors. Nous avons quatre éléments qui entrent en jeu :
- Netscape s’exécute sur une machine Windows. Généralement, il s’agit de quelqu’un qui tente d’accéder à notre site de ventes sur le Web ; maintenant, cela simule un employé de Butterthlies qui tente de joindre un site extérieur.
- Un pare-feu imaginaire.
- Une instance d’Apache (site .site.proxy/proxy ) tournant sur une machine FreeBSD et servant de mandataire pour le réseau de Butterthlies.
- Une autre instance d’Apache, tournant également sous FreeBSD (site .site.proxy/real ) et simulant un autre site web que nous tentons d’atteindre. Nous devons imaginer que l’univers du Web nous sépare de lui.
Nous avons déjà présenté le fichier de configuration de .site.proxy/proxy. Comme le mandataire tourne sur une machine censée être de l’autre côté du Web par rapport à celle qui exécute .site.proxy/real, nous devons le mettre sur un autre port ; on utilise traditionnellement le port 8000.
Le fichier de configuration de .proxy/real contient les lignes suivantes :
User webuser
Group webgroup
ServerName www.faraway.com
Listen www.faraway.com:80
DocumentRoot /usr/www/APACHE3/site.proxy/real/htdocs
Sur ce site, nous utilisons la directive Listen, plus concise, en lui indiquant le nom du serveur combiné au numéro du port.
Normalement, www.faraway.com serait un site situé ailleurs sur le Web mais, ici, nous le simulons sur la même machine.
Le répertoire .site.proxy/real/htdocs contient un fichier avec le message suivant :
Je suis un site web loin, très loin d’ici.
De plus, /etc/hosts contient l’entrée suivante :
192.168.124.1 www.faraway.com
pour simuler un enregistrement DNS pour ce site lointain. Vous remarquerez qu’il est situé sur un réseau différent ( 192.168.124 ) de celui que nous utilisons normalement ( 192.168.123 ), pour que si l’on essaie d’y accéder par notre réseau local, on ne puisse le faire sans aide.
Le fichier /usr/www/lan_setup de la machine FreeBSD contient maintenant :
ifconfig ep0 192.168.123.2
ifconfig ep0 192.168.123.3 alias netmask 0xFFFFFFFF
ifconfig ep0 192.168.124.1 alias
Passons à l’action : allez en .site.proxy/real et lancez le serveur avec ./go puis allez dans .site.proxy/proxy et lancez le mandataire ./go. Faites pointer votre navigateur vers http://192.168.124.1/, vous devriez voit apparaître la page suivante :
Index of /
. Parent Directory
. message
Si nous sélectionnons message, nous voyons apparaître :
Je suis un site web loin, très loin d’ici.
Bien, mais ne sommes-nous pas en train de nous tromper ? Allez dans la configuration des mandataires de votre navigateur et désactivez le mandataire HTTP en ôtant l’adresse :
192.168.123.2
Puis, accédez de nouveau à http://192.168.124.1/. Vous devriez recevoir un message vous indiquant un problème de réseau.
Que s’est-il passé ? Nous avons demandé au navigateur d’accéder à http://192.168.124.1/. Comme ce site est sur le réseau 192.168.123, il n’a pas pu trouver cette adresse et il a utilisé à la place le serveur mandataire sur le port 8000 de 192.168.123.2 et y a envoyé ce message :
GET http://192.168.124.1/ HTTP/1.0
L’instance d’Apache qui s’exécute sur la machine FreeBSD et qui écoute le port 8000 a reçu ce message. Comme nous lui avons demandé d’honorer les requêtes mandatées, elle a retransmis cette requête au destinataire auquel nous pensions qu’elle était tout le temps liée : 192.168.123.1 (ce qu’elle peut faire puisqu’il est sur la même machine) :
GET / HTTP/1.0
Dans la réalité, les choses sont plus simples : il vous suffit de suivre les étapes deux et trois et d’ignorer la théorie. Lorsque vous en avez fini, n’oubliez pas de supprimer l’adresse du mandataire dans les préférences de votre navigateur.
Mandataire inverse
Cette section présente une configuration pour mandater vos serveurs mod_perl lorsque vous devez utiliser des hôtes virtuels. Consultez la page perl.apache.org/guide/scenario.html, que nous citons librement ici.
- Parce que vous n’y aviez pas pensé initialement, et que vous vous battez maintenant contre les incendies.
- Parce que vous voulez économiser la taille des pages en utilisant des URL relatives au lieu d’URL absolues.
- Parce que vous voulez améliorer les performances en mettant en cache les résultats de scripts CGI coûteux en ressources, par exemple.
Le terme d’hôte virtuel fait référence au fait que l’on gère plusieurs serveurs sur la même machine et qu’ils se différencient par leur nom d’hôte apparent. Il est, par exemple, souvent souhaitable que les sociétés partageant un serveur web aient leurs propres domaines et que leurs serveurs soient accessibles par www.societe1.com et www.societe2.com, sans que l’utilisateur ait besoin d’en savoir plus.
Une méthode possible consiste à utiliser un port différent pour les communications de chaque hôte virtuel avec le serveur annexe : vous pouvez ainsi rediriger les requêtes provenant du serveur principal vers localhost:1234 et les serveurs virtuels par noms, bien que n’importe quelle technique sur le serveur principal fasse l’affaire.
Comme nous le verrons dans l’exemple de configuration suivant, si le serveur principal et les serveurs annexes s’exécutent sur la même machine, vous pouvez empêcher les connexions directes venant de l’extérieur vers le serveur annexe si vous le liez à l’adresse 127.0.0.1 ( localhost ).
La configuration du serveur principal est la suivante :
<VirtualHost 10.10.10.10>
ServerName www.exemple.com
ServerAlias exemple.com
RewriteEngine On
RewriteOptions 'inherit'
RewriteRule \.(gif|jpg|png|txt|html)$ - [last]
RewriteRule ^/(.*)$ http://localhost:4077/$1 [proxy]
</VirtualHost>
<VirtualHost 10.10.10.10>
ServerName truc.exemple.com
RewriteEngine On
RewriteOptions 'inherit'
RewriteRule \.(gif|jpg|png|txt|html)$ - [last]
RewriteRule ^/(.*)$ http://localhost:4078/$1 [proxy]
</VirtualHost>
Ce serveur gère deux hôtes virtuels : www.exemple.com et truc.exemple.com, aux configurations pratiquement identiques.
Le serveur principal gérera les fichiers ayant les extensions .gif, .jpg, .png, .txt et .html ; les autres seront mandatés pour être traités par le serveur annexe.
La seule différence entre les configurations des deux hôtes virtuels est que le premier récrit les requêtes sur le port 4077 de la machine annexe alors que le deuxième le fait sur le port 4078.
Si votre serveur est configuré pour exécuter des scripts CGI classiques (avec mod_cgi ) et des programmes CGI mod_perl, il serait avantageux de configurer le serveur principal pour qu’il lance directement les scripts CGI classiques. Pour ce faire, on peut modifier la règle gif|jpg|png|txt Rewrite pour lui ajouter |cgi si tous vos scripts mod_cgi ont l’extension .cgi, ou ajouter une nouvelle règle pour gérer localement tous les emplacements /cgi-bin/*.
Voici la configuration du serveur annexe :
Port 80
PerlPostReadRequestHandler My::ProxyRemoteAddr
Listen 4077
<VirtualHost localhost:4077>
ServerName www.exemple.com
DocumentRoot /home/httpd/docs/www.exemple.com
DirectoryIndex index.shtml index.html
</VirtualHost>
Listen 4078
<VirtualHost localhost:4078>
ServerName truc.exemple.com
DocumentRoot /home/httpd/docs/truc.exemple.com
DirectoryIndex index.shtml index.html
</VirtualHost>
Ce serveur sait à quel hôte virtuel s’adresse la requête car il peut vérifier le numéro de port sur laquelle a elle a été envoyée et utiliser le conteneur approprié pour la gérer.
Nous utilisons Port 80 pour que toutes les redirections utilisent le port 80 plutôt que celui sur lequel s’exécute le serveur annexe.
Pour obtenir du mandataire les véritables adresses IP distantes, nous utilisons le handler My::ProxyRemoteAddr, basé sur le module mod_proxy_add_forward. Avant la version 1.22 de mod_perl, il fallait répéter cette configuration pour chaque hôte virtuel car ils n’en héritaient pas.
La configuration suivante est un autre exemple montrant une autre façon de procéder. Elle précise ce qui doit être mandaté, puis le reste est servi par le serveur principal :
RewriteEngine on
RewriteLogLevel 0
RewriteRule ^/(perl.*)$ http://127.0.0.1:8052/$1 [P,L]
NoCache *
ProxyPassReverse / http://www.exemple.com/
Nous n’avons donc pas besoin de spécifier de règle pour que les objets statiques soient servis par le serveur principal, comme c’était le cas dans l’exemple précédent pour gérer les fichiers ayant les extensions .gif, .jpg, .png, .txt et .html.