Serveur Apache HTTP Version 2.4
Le but de ce document est d'essayer de r�pondre aux questions les plus r�pandues sur la configuration des serveurs virtuels. Les sc�narios pr�sent�s ici se rencontrent quand plusieurs serveurs Webs doivent tourner sur une seule et m�me machine au moyen de serveurs virtuels par nom ou par IP.
Virtual_host
et de mod_proxy_default_
ServerPath
Votre serveur poss�de plusieurs noms d'h�te qui correspondent � une seule
adresse IP, et vous souhaitez des r�ponses diff�rentes si on demande
www.example.com
ou www.example.org
.
La configuration de serveurs virtuels
sous Apache ne provoque pas leur apparition magique dans la
configuration du DNS. Il faut que leurs noms soient
d�finis dans le DNS, et qu'ils y soient r�solus sur l'adresse IP
du serveur, faute de quoi personne ne pourra visiter votre site Web.
Il est possible d'ajouter des entr�es dans le fichier
hosts
pour tests locaux, mais qui ne fonctionneront
que sur la machine poss�dant ces entr�es.
# Apache doit �couter sur le port 80 Listen 80 <VirtualHost *:80> DocumentRoot "/www/example1" ServerName www.example.com # Autres directives ici </VirtualHost> <VirtualHost *:80> DocumentRoot "/www/example2" ServerName www.example.org # Autres directives ici </VirtualHost>
Les ast�risques correspondent � toutes les adresses, si bien que
le serveur principal ne r�pondra jamais � aucune requ�te. Comme le
serveur virtuel
ServerName www.example.com
se trouve en premier dans le fichier
de configuration, il a la plus grande priorit� et peut �tre vu
comme serveur par d�faut ou primaire ;
ce qui signifie que toute requ�te re�ue ne correspondant � aucune
des directives ServerName
sera servie par ce premier
<VirtualHost>
.
La configuration ci-dessus correspond � ce que l'on souhaite pour la plupart des serveurs virtuels � base de nom. Il faudra cependant utiliser une configuration diff�rente si vous souhaitez servir un contenu diff�rent en fonction de l'adresse IP ou du port.
Vous pouvez remplacer *
par une adresse IP du syst�me. Le serveur virtuel concern�
ne sera alors s�lectionn� que pour les requ�tes HTTP vers
cette adresse IP.
En g�n�ral, il est commode d'utiliser *
sur
les syst�mes dont l'adresse IP n'est pas constante - par
exemple, pour des serveurs dont l'adresse IP est attribu�e
dynamiquement par le FAI, et o� le DNS est g�r� au moyen
d'un DNS dynamique quelconque. Comme *
signifie
n'importe quelle adresse, cette configuration
fonctionne sans devoir �tre modifi�e quand l'adresse IP du
syst�me est modifi�e.
Toutes les techniques pr�sent�es ici peuvent �tre �tendues � un plus grand nombre d'adresses IP.
Le serveur a deux adresses IP. Sur l'une
(172.20.30.40
), le serveur "principal"
server.example.com
doit r�pondre, et sur l'autre
(172.20.30.50
), deux serveurs virtuels (ou plus)
r�pondront.
Listen 80 # Serveur "principal" sur 172.20.30.40 ServerName server.example.com DocumentRoot "/www/mainserver" <VirtualHost 172.20.30.50> DocumentRoot "/www/example1" ServerName www.example.com # D'autres directives ici ... </VirtualHost> <VirtualHost 172.20.30.50> DocumentRoot "/www/example2" ServerName www.example.org # D'autres directives ici ... </VirtualHost>
Toute requ�te arrivant sur une autre adresse que
172.20.30.50
sera servie par le serveur principal.
Les requ�tes vers 172.20.30.50
avec un nom de serveur
inconnu, ou sans en-t�te Host:
, seront servies par
www.example.com
.
La machine serveur dispose de deux adresses IP
(192.168.1.1
et 172.20.30.40
). Cette
machine est plac�e � la fois sur le r�seau interne (l'Intranet)
et le r�seau externe (Internet). Sur Internet, le nom
server.example.com
pointe vers l'adresse externe
(172.20.30.40
), mais sur le r�seau interne, ce m�me
nom pointe vers l'adresse interne (192.168.1.1
).
Le serveur peut �tre configur� pour r�pondre de la m�me mani�re
aux requ�tes internes et externes, au moyen d'une seule section
<VirtualHost>
.
<VirtualHost 192.168.1.1 172.20.30.40> DocumentRoot "/www/server1" ServerName server.example.com ServerAlias server </VirtualHost>
Ainsi, les requ�tes en provenance de chacun des deux r�seaux
seront servies par le m�me <VirtualHost>
.
Sur le r�seau interne, il est possible
d'utiliser le nom raccourci server
au lieu du nom
complet server.example.com
.
Notez �galement que dans l'exemple pr�c�dent, vous pouvez
remplacer la liste des adresses IP par des *
afin
que le serveur r�ponde de la m�me mani�re sur toutes ses
adresses.
Vous disposez de plusieurs domaines pointant sur la m�me adresse IP et vous voulez �galement servir de multiples ports. L'exemple suivant montre que la s�lection en fonction du nom intervient apr�s la s�lection de la meilleure correspondance du point de vue adresse IP/port.
Listen 80 Listen 8080 <VirtualHost 172.20.30.40:80> ServerName www.example.com DocumentRoot "/www/domain-80" </VirtualHost> <VirtualHost 172.20.30.40:8080> ServerName www.example.com DocumentRoot "/www/domain-8080" </VirtualHost> <VirtualHost 172.20.30.40:80> ServerName www.example.org DocumentRoot "/www/otherdomain-80" </VirtualHost> <VirtualHost 172.20.30.40:8080> ServerName www.example.org DocumentRoot "/www/otherdomain-8080" </VirtualHost>
Le serveur dispose de deux adresses IP (172.20.30.40
et 172.20.30.50
) correspondant respectivement aux noms
www.example.com
et www.example.org
.
Listen 80 <VirtualHost 172.20.30.40> DocumentRoot "/www/example1" ServerName www.example.com </VirtualHost> <VirtualHost 172.20.30.50> DocumentRoot "/www/example2" ServerName www.example.org </VirtualHost>
Les requ�tes provenant d'adresses non sp�cifi�es dans l'une des
directives <VirtualHost>
(comme pour
localhost
par exemple) seront dirig�es vers le serveur
principal, s'il en existe un.
Le serveur dispose de deux adresses IP (172.20.30.40
et 172.20.30.50
) correspondant respectivement aux noms
www.example.com
et www.example.org
.
Pour chacun d'eux, nous voulons un h�bergement sur les ports 80
et 8080.
Listen 172.20.30.40:80 Listen 172.20.30.40:8080 Listen 172.20.30.50:80 Listen 172.20.30.50:8080 <VirtualHost 172.20.30.40:80> DocumentRoot "/www/example1-80" ServerName www.example.com </VirtualHost> <VirtualHost 172.20.30.40:8080> DocumentRoot "/www/example1-8080" ServerName www.example.com </VirtualHost> <VirtualHost 172.20.30.50:80> DocumentRoot "/www/example2-80" ServerName www.example.org </VirtualHost> <VirtualHost 172.20.30.50:8080> DocumentRoot "/www/example2-8080" ServerName www.example.org </VirtualHost>
Toute adresse indiqu�e comme argument d'une section VirtualHost et n'apparaissant dans aucun autre serveur virtuel, fait de cette section un serveur virtuel s�lectionnable uniquement en fonction de son adresse IP.
Listen 80 <VirtualHost 172.20.30.40> DocumentRoot "/www/example1" ServerName www.example.com </VirtualHost> <VirtualHost 172.20.30.40> DocumentRoot "/www/example2" ServerName www.example.org </VirtualHost> <VirtualHost 172.20.30.40> DocumentRoot "/www/example3" ServerName www.example.net </VirtualHost> # IP-based <VirtualHost 172.20.30.50> DocumentRoot "/www/example4" ServerName www.example.edu </VirtualHost> <VirtualHost 172.20.30.60> DocumentRoot "/www/example5" ServerName www.example.gov </VirtualHost>
Virtual_host
et de mod_proxyL'exemple suivant montre comment une machine peut mandater
un serveur virtuel fonctionnant sur le serveur d'une autre machine.
Dans cet exemple, un serveur virtuel de m�me nom est configur� sur
une machine � l'adresse 192.168.111.2
. La directive
ProxyPreserveHost On
est
employ�e pour permette au nom de domaine d'�tre pr�serv� lors du
transfert, au cas o� plusieurs noms de domaines cohabitent sur
une m�me machine.
<VirtualHost *:*> ProxyPreserveHost On ProxyPass "/" "http://192.168.111.2/" ProxyPassReverse "/" "http://192.168.111.2/" ServerName hostname.example.com </VirtualHost>
_default_
_default_
pour tous les portsExemple de capture de toutes les requ�tes �manant d'adresses IP ou de ports non connus, c'est-�-dire, d'un couple adresse/port non trait� par aucun autre serveur virtuel.
<VirtualHost _default_:*> DocumentRoot "/www/default" </VirtualHost>
L'utilisation d'un tel serveur virtuel avec un joker pour le port emp�che de mani�re efficace qu'une requ�te n'atteigne le serveur principal.
Un serveur virtuel par d�faut ne servira jamais une requ�te
qui est envoy�e vers un couple adresse/port utilis�e par un
serveur virtuel par nom. Si la requ�te contient un en-t�te
Host:
inconnu, ou si celui-ci est absent, elle
sera toujours servie par le serveur virtuel primaire par nom
(celui correspondant � ce couple adresse/port trouv� en premier
dans le fichier de configuration).
Vous pouvez utiliser une directive
AliasMatch
ou
RewriteRule
afin de
r��crire une requ�te pour une unique page d'information (ou pour
un script).
_default_
pour des ports diff�rentsLa configuration est similaire � l'exemple pr�c�dent, mais
le serveur �coute sur plusieurs ports et un second serveur virtuel
_default_
pour le port 80 est ajout�.
<VirtualHost _default_:80> DocumentRoot "/www/default80" # ... </VirtualHost> <VirtualHost _default_:*> DocumentRoot "/www/default" # ... </VirtualHost>
Le serveur virtuel par d�faut d�fini pour le port 80 (il doit imp�rativement �tre plac� avant un autre serveur virtuel par d�faut traitant tous les ports gr�ce au joker *) capture toutes les requ�tes envoy�es sur une adresse IP non sp�cifi�e. Le serveur principal n'est jamais utilis� pour servir une requ�te.
_default_
pour un seul portNous voulons cr�er un serveur virtuel par d�faut seulement pour le port 80.
<VirtualHost _default_:80> DocumentRoot "/www/default" ... </VirtualHost>
Une requ�te vers une adresse non sp�cifi�e sur le port 80 sera servie par le serveur virtuel par d�faut, et toute autre requ�te vers une adresse et un port non sp�cifi�s sera servie par le serveur principal.
L'utilisation du caract�re g�n�rique *
dans la
d�claration d'un serveur virtuel l'emporte sur
_default_
.
Le serveur virtuel par nom avec le nom de domaine
www.example.org
(de notre exemple
par nom) devrait obtenir sa propre adresse IP. Pendant la
phase de migration, il est possible d'�viter les probl�mes avec
les noms de serveurs et autres serveurs mandataires qui m�morisent
les vielles adresses IP pour les serveurs virtuels par nom.
La solution est simple, car il suffit d'ajouter la nouvelle
adresse IP (172.20.30.50
) dans la directive
VirtualHost
.
Listen 80 ServerName www.example.com DocumentRoot "/www/example1" <VirtualHost 172.20.30.40 172.20.30.50> DocumentRoot "/www/example2" ServerName www.example.org # ... </VirtualHost> <VirtualHost 172.20.30.40> DocumentRoot "/www/example3" ServerName www.example.net ServerAlias *.example.net # ... </VirtualHost>
Le serveur virtuel peut maintenant �tre joint par la nouvelle adresse (comme un serveur virtuel par IP) et par l'ancienne adresse (comme un serveur virtuel par nom).
ServerPath
Dans le cas o� vous disposez de deux serveurs virtuels par nom,
le client doit transmettre un en-t�te Host:
correct
pour d�terminer le serveur concern�. Les vieux clients HTTP/1.0
n'envoient pas un tel en-t�te et Apache n'a aucun indice pour
conna�tre le serveur virtuel devant �tre joint (il sert la
requ�te � partir d'un serveur virtuel primaire). Dans un soucis
de pr�server la compatibilit� descendante, il suffit de cr�er
un serveur virtuel primaire charg� de retourner une page contenant
des liens dont les URLs auront un pr�fixe identifiant les serveurs
virtuels par nom.
<VirtualHost 172.20.30.40> # serveur virtuel primaire DocumentRoot "/www/subdomain" RewriteEngine On RewriteRule "." "/www/subdomain/index.html" # ... </VirtualHost> <VirtualHost 172.20.30.40> DocumentRoot "/www/subdomain/sub1" ServerName www.sub1.domain.tld ServerPath "/sub1/" RewriteEngine On RewriteRule "^(/sub1/.*)" "/www/subdomain$1 # ... </VirtualHost> <VirtualHost 172.20.30.40> DocumentRoot "/www/subdomain/sub2" ServerName www.sub2.domain.tld ServerPath "/sub2/" RewriteEngine On RewriteRule "^(/sub2/.*)" "/www/subdomain$1" # ... </VirtualHost>
� cause de la directive
ServerPath
, une requ�te sur
une URL http://www.sub1.domain.tld/sub1/
est
toujours servie par le serveur sub1-vhost.
Une requ�te sur une URL http://www.sub1.domain.tld/
n'est
servie par le serveur sub1-vhost que si le client envoie un en-t�te
Host:
correct. Si aucun en-t�te Host:
n'est transmis, le serveur primaire sera utilis�.
Notez qu'il y a une singularit� : une requ�te sur
http://www.sub2.domain.tld/sub1/
est �galement servie
par le serveur sub1-vhost si le client n'envoie pas d'en-t�te
Host:
.
Les directives RewriteRule
sont employ�es pour s'assurer que le client qui envoie un en-t�te
Host:
correct puisse utiliser d'autres variantes d'URLs,
c'est-�-dire avec ou sans pr�fixe d'URL.