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 ne dispose que d'une seule adresse IP, et de
nombreux alias (CNAMES) pointent vers cette adresse dans le DNS.
Pour l'exemple, www.example.com
et
www.example.org
doivent tourner sur cette machine.
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
.
Vous pouvez remplacer *
par l'adresse IP du syst�me si vous ne souhaitez pas faire
op�rer la s�lection du serveur virtuel en fonction de la
paire adresse IP/port.
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.
La configuration ci-dessus est en pratique utilis�e dans la plupart des cas pour les serveurs virtuels par nom. En fait, le seul cas o� cette configuration ne fonctionne pas est lorsque diff�rents contenus doivent �tre servis en fonction de l'adresse IP et du port contact�s par le client.
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.