*** fr_FR ***
Bonjour, apr�s quelques semaines de travail, j'ai termin� de traduire et relire tout le r�pertoire /vhost/. Donc, vous noterez que certains fichiers ont simplement �t� relus, et d'autres doivent �tre relus par quelqu'un d'autre.
--Alain
<?xml version='1.0' encoding='ISO-8859-1' ?> <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd"> <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?> <!-- English Revision: 151405 --> <!-- french translation by alain B, review by ####### -->
<!--
Copyright 2005 The Apache Software Foundation or its licensors, as
applicable.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="index.xml.meta">
<parentdocument href="../"/>
<title>Documentation sur les serveurs virtuels Apache</title>
<summary>
<p>Le principe des <cite>Serveurs Virtuels</cite> consiste �
faire fonctionner un ou plusieurs serveurs Web (comme
<code>www.company1.com</code> et <code>www.company2.com</code>)
sur une m�me machine. Les serveurs virtuels peuvent �tre soit
"<a href="ip-based.html">par-IP</a>" o� une adresse IP est
attribu�e pour chaque serveur Web, soit "<a href="name-based.html"
>par-nom</a>" o� plusieurs noms de domaine se c�toient sur
des m�mes adresses IP. L'utilisateur final ne per�oit pas
qu'en fait il s'agit d'un m�me serveur physique.</p>
<p>Apache a �t� le pr�curseur des serveurs proposant cette
m�thode de serveurs virtuels bas�s sur les adresses IP. Ses
versions 1.1 et suivantes ont toujours propos�es ces deux
m�thodes de serveurs virtuels par-IP et par-nom. Cette
deuxi�me m�thode est parfois �galement appel�e <em>host-based</em>
ou <em>serveur virtuel non-IP</em>.</p>
<p>Vous trouverez ci-dessous une liste documentaire qui vous
expliquera en d�tails le fonctionnement des serveurs virtuels
sous Apache 1.3 et ses versions suivantes.</p>
</summary>
<seealso><module>mod_vhost_alias</module></seealso>
<seealso><a href="name-based.html">Serveurs virtuels par-nom</a></seealso>
<seealso><a href="ip-based.html">Serveurs virtuels par-IP</a></seealso>
<seealso><a href="examples.html">Exemples de serveurs virtuels</a></seealso>
<seealso><a href="fd-limits.html">Limites des descripteurs de fichiers</a></seealso>
<seealso><a href="mass.html">H�bergement virtuel en masse</a></seealso>
<seealso><a href="details.html">D�tails sur les crit�res de choix du serveur</a></seealso>
<section id="support"><title>Support des serveurs virtuels</title>
<ul>
<li><a href="name-based.html">Serveurs Virtuels par-Nom</a>
(Un ou plusieurs sites Web par adresse IP)</li>
<li><a href="ip-based.html">Serveurs Virtuels par-IP</a>
(Une adresse IP pour chaque site Web)</li>
<li><a href="examples.html">Exemples de configurations classiques
de Serveurs Virtuels </a></li>
<li><a href="fd-limits.html">Limites des descripteurs de fichiers</a>
(ou, <em>trop de fichiers journaux</em>)</li>
<li><a href="mass.html">Configuration dynamique en masse de
Serveurs Virtuels</a></li>
<li><a href="details.html">Explication approfondie des crit�res
de s�lection d'un Serveur Virtuel</a></li>
</ul>
</section>
<section id="directives"><title>Directives de configuration</title>
<ul>
<li><directive type="section"
module="core">VirtualHost</directive></li>
<li><directive module="core">NameVirtualHost</directive></li>
<li><directive module="core">ServerName</directive></li>
<li><directive module="core">ServerAlias</directive></li>
<li><directive module="core">ServerPath</directive></li>
</ul>
<p>Pour v�rifier et analyser la configuration de vos serveurs
virtuels, vous pouvez utiliser l'argument <code>-S</code> sur
la ligne de commande lan�ant le programme Apache comme ceci :</p>
<example>
/usr/local/apache2/bin/httpd -S
</example>
<p>Cette commande affichera dans le d�tail comment Apache a
trait� son fichier de configuration. Les erreurs de configuration
peuvent �tre corrig�es par l'examen attentif des adresses IP et
des noms de serveurs. (Consultez la documentation du programme
<program>httpd</program> pour les autres arguments de la ligne de
commande)</p>
</section>
</manualpage>
<?xml version='1.0' encoding='ISO-8859-1' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
<!-- English Revision: 151405 -->
<!-- French translation by alain B, review by -->
<!--
Copyright 2005 The Apache Software Foundation or its licensors, as
applicable.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="name-based.xml.meta">
<parentdocument href="./">Serveurs virtuels</parentdocument>
<title>Support Apache des serveurs virtuels par nom</title>
<summary>
<p>Ce document d�crit quand et comment utiliser des serveurs
virtuels par nom.</p>
</summary>
<seealso><a href="ip-based.html">Support Apache des serveurs virtuels par IP</a></seealso>
<seealso><a href="details.html">D�tails sur le fonctionnement des serveurs virtuels</a></seealso>
<seealso><a href="mass.html">Configuration dynamique des h�bergements virtuels de masse</a></seealso>
<seealso><a href="examples.html">Exemples d'utilisations de VirtualHost</a></seealso>
<seealso><a href="examples.html#serverpath">Utilisation de la directive ServerPath</a></seealso>
<section id="namevip"><title>Serveurs virtuels par nom vs. par IP</title>
<p>Les h�bergements virtuels par IP utilisent l'adresse IP
de la connexion afin de d�terminer quel serveur virtuel doit
servir. Par cons�quent, vous devez disposer d'adresses IP
diff�rentes pour chaque h�bergement. Avec un h�bergement
virtuel par nom, le serveur doit s'appuyer sur les informations
transmises par le client dans les en-t�tes HTTP de ses requ�tes.
La technique pr�sent�e ici vous permet de disposer de serveurs
virtuels diff�rents partag�s sur une m�me adresse IP.</p>
<p>L'h�bergement virtuel par nom est habituellement plus simple,
car il vous suffit de configurer votre serveur DNS pour que
chaque domaine pointe sur l'adresse IP correspondante, et de
configurer votre serveur Apache HTTP afin qu'il reconnaisse
ces domaines. Il r�duit aussi la p�nurie en adresses IP. Par
cons�quent, vous devriez utiliser l'h�bergement virtuel par
nom � moins d'avoir une raison sp�cifique de pr�f�rer
l'h�bergement virtuel par IP. Certaines de ces raisons vous
sont expos�es ci-apr�s :</p>
<ul>
<li>Certains anciens navigateurs ne sont pas compatibles
avec les serveurs virtuels par nom, car pour fonctionner,
un client doit transmettre un champ d'en-t�te HTTP Host.
Cet en-t�te est exig� pour HTTP/1.1, et peut �tre impl�ment�
sur des navigateurs modernes HTTP/1.0 gr�ce � une extension.
Si vous devez maintenir des clients obsol�tes tout en
utilisant l'h�bergement virtuel par nom, il existe une
technique qui est trait�e � la fin de ce document.</li>
<li>L'h�bergement virtuel par nom ne peut pas �tre utilis�
avec des serveurs s�curis�s SSL � cause de la nature m�me
du protocole SSL.</li>
<li>Certains syst�mes d'exploitation et �quipements r�seaux
emploient des techniques de gestion de la bande passante
qui ne peuvent pas diff�rencier des domaines autrement que
par des adresses IP s�par�es.</li>
</ul>
</section>
<section id="using"><title>Utilisation de serveurs virtuels par nom</title>
<related>
<modulelist>
<module>core</module>
</modulelist>
<directivelist>
<directive module="core">DocumentRoot</directive>
<directive module="core">NameVirtualHost</directive>
<directive module="core">ServerAlias</directive>
<directive module="core">ServerName</directive>
<directive module="core">ServerPath</directive>
<directive module="core" type="section">VirtualHost</directive>
</directivelist>
</related>
<p>Pour utiliser des serveurs virtuels par nom, vous devez
d�signer l'adresse IP (et si possible le port) sur le serveur
devant accepter les requ�tes pour des domaines. Cette
configuration utilise la directive
<directive module="core">NameVirtualHost</directive>. Dans un
cas normal o� n'importe quelle adresse IP peut �tre utilis�e,
vous pouvez ajouter <code>*</code> comme argument de la directive
<directive module="core">NameVirtualHost</directive>. Si vous
pr�voyez d'utiliser de multiples ports (comme l'emploi de SSL),
vous devriez ajouter le port � cet argument tel que
<code>*:80</code>. Notez que la simple mention d'une adresse
IP dans une directive
<directive module="core">NameVirtualHost</directive> ne suffit
pas � faire �couter le serveur sur cette IP. Consultez
<a href="../bind.html">la page sur les liaisons</a> pour plus
de d�tails. Par ailleurs, chaque adresse IP sp�cifi�e ici doit
�tre associ�e avec une interface r�seau sur le serveur.</p>
<p>L'�tape suivante est la cr�ation d'une section
<directive type="section" module="core">VirtualHost</directive>
pour chacun des serveurs � cr�er. L'argument de la directive
<directive type="section" module="core">VirtualHost</directive>
doit �tre le m�me que celui de la directive
<directive module="core">NameVirtualHost</directive>
(c'est-�-dire l'adresse IP ou <code>*</code> pour toutes les
adresses). Dans chaque section
<directive type="section" module="core">VirtualHost</directive>,
vous devez d�finir au minimum une directive
<directive module="core">ServerName</directive> pour d�signer
le serveur concern� et une directive
<directive module="core">DocumentRoot</directive> pour pr�ciser
l'emplacement sur le syst�me de fichiers du contenu de ce serveur.</p>
<note><title>Le serveur principal dispara�t</title>
<p>Si vous ajoutez des serveurs virtuels � un serveur Web
existant, vous devez �galement cr�er une section
<directive type="section" module="core">VirtualHost</directive>
red�finissant ce serveur existant. Les directives
<directive module="core">ServerName</directive> et
<directive module="core">DocumentRoot</directive> incluses
dans ce serveur virtuel doivent �tre les m�mes que pour
les directives globales
<directive module="core">ServerName</directive> et
<directive module="core">DocumentRoot</directive>. Positionnez
ce serveur virtuel en premier dans le fichier de configuration
pour en faire le serveur par d�faut.</p>
</note>
<p>Par exemple, supposez que vous servez le domaine
<code>www.domain.tld</code> et que vous souhaitez ajouter le
serveur virtuel <code>www.otherdomain.tld</code> qui pointe sur
la m�me adresse IP. Il vous suffit d'ajouter la configuration
suivante � <code>httpd.conf</code> :</p>
<example>
NameVirtualHost *:80<br />
<br />
<VirtualHost *:80><br />
<indent>
ServerName www.domain.tld<br />
ServerAlias domain.tld *.domain.tld<br />
DocumentRoot /www/domain<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost *:80><br />
<indent>ServerName www.otherdomain.tld<br />
DocumentRoot /www/otherdomain<br />
</indent>
</VirtualHost><br />
</example>
<p>Autrement, vous pouvez sp�cifiez une adresse IP explicite
� la place de <code>*</code> dans les deux directives
<directive module="core" >NameVirtualHost</directive> et
<directive type="section" module="core" >VirtualHost</directive>.
Par exemple, cette m�thode est utile si vous souhaitez faire
tourner quelques serveurs virtuels par nom sur une m�me adresse
IP, et d'autres, soit par IP, soit bas�s sur un autre jeu de
serveurs virtuels par nom sur une autre adresse IP.</p>
<p>Plusieurs serveurs sont accessibles par plus d'un nom. Il
suffit de placer la directive
<directive module="core">ServerAlias</directive> dans une section
<directive type="section" module="core">VirtualHost</directive>.
Par exemple, dans la premi�re section
<directive type="section" module="core">VirtualHost</directive>
ci-dessus, la directive <directive module="core">ServerAlias</directive>
indique aux utilisateurs les autres noms permis pour acc�der au
m�me site Web :</p>
<example>
ServerAlias domain.tld *.domain.tld
</example>
<p>ainsi, toutes les requ�tes portant sur un domaine
<code>domain.tld</code> sera servi par le serveur virtuel
<code>www.domain.tld</code>. Les caract�res joker <code>*</code>
et <code>?</code> peuvent �tre utilis�s pour les correspondances.
Bien entendu, vous ne pouvez pas inventer des noms et les placer
dans une directive <directive module="core">ServerName</directive>
ou <code>ServerAlias</code>. Tout d'abord, votre serveur DNS
doit �tre correctement configur� pour lier ces noms � une
adresse IP associ�e avec votre serveur.</p>
<p>Finalement, vous pouvez affiner la configuration des serveurs
virtuels en pla�ant d'autres directives � l'int�rieur des sections
<directive type="section" module="core">VirtualHost</directive>.
La plupart des directives peut �tre plac�e dans ces sections en
y changeant seulement la configuration du serveur virtuel associ�.
Pour conna�tre si une directive particuli�re est permise,
consultez <a href="../mod/directive-dict.html#Context">la page de
contexte</a>. Le jeu de directives configur�es dans le contexte
du <em>serveur principal</em> (en dehors de toutes sections
<directive type="section" module="core">VirtualHost</directive>)
sera utilis� seulement s'il n'y a pas de configuration surclassante
par un serveur virtuel.</p>
<p>Maintenant, lorsqu'une requ�te arrive, le serveur va d'abord
tester si elle utilise une adresse IP qui correspond �
<directive module="core" >NameVirtualHost</directive>. Si c'est
le cas, il regardera chaque section
<directive type="section" module="core">VirtualHost</directive>
avec l'adresse correspondante et essaiera d'en trouver une o�
le nom de domaine requis correspond �
<directive module="core">ServerName</directive> ou
<code>ServerAlias</code>. S'il en trouve une, il utilisera
sa configuration pour le serveur. Si aucun serveur virtuel ne
correspond, alors <em>le premier serveur virtuel list�</em>
dont l'adresse IP correspond sera employ�.</p>
<p>En cons�quence, le premier serveur virtuel list� est le
serveur virtuel <em>default</em>. La directive
<directive module="core">DocumentRoot</directive> du
<em>serveur principal</em> <strong>ne</strong> sera
<strong>jamais</strong> employ�e lorsqu'une adresse IP
correspond dans une directive
<directive module="core">NameVirtualHost</directive>. Si vous
ne voulez pas avoir de configuration sp�ciale pour les requ�tes
qui ne sont pas attach�es � un serveur virtuel en particulier,
mettez cette configuration dans une section
<directive type="section" module="core">VirtualHost</directive>
que vous placerez en premier dans le fichier de configuration.</p>
</section>
<section id="compat"><title>Compatibilit� avec les navigateurs anciens</title>
<p>Comme mentionn� plus t�t, certains clients ne transmettent
pas les donn�es n�cessaires pour le bon fonctionnement des
serveurs virtuels. Ces clients recevront toujours les pages
du premier serveur virtuel list� pour cette adresse IP (le
serveur virtuel par nom <cite>primaire</cite>).</p>
<note><title>De combien plus �g� ?</title>
<p>Veuillez noter que quand nous disons plus �g�, nous
disons vraiment plus �g�. Vous seriez malchanceux de rencontrer
de tels navigateurs encore utilis�s de nos jours. Toutes les
versions actuelles des navigateurs transmettent leur en-t�te
<code>Host</code> comme exig� par les serveurs virtuels par nom.</p>
</note>
<p>Il existe une solution avec la directive
<directive module="core">ServerPath</directive>, bien que
l�g�rement encombrante :</p>
<p>Exemple de configuration :</p>
<example>
NameVirtualHost 111.22.33.44<br />
<br />
<VirtualHost 111.22.33.44><br />
<indent>
ServerName www.domain.tld<br />
ServerPath /domain<br />
DocumentRoot /web/domain<br />
</indent>
</VirtualHost><br />
</example>
<p>Qu'est-ce que cela signifie ? Il signifie qu'une requ�te
pour tout URI qui commence par "<code>/domain</code>" sera
servie par le serveur virtuel <code>www.domain.tld</code>.
Ainsi, les pages sont accessibles �
<code>http://www.domain.tld/domain/</code> pour tous les
clients, bien que ceux qui transmettent un en-t�te
<code>Host:</code> peuvent �galement y acc�der �
<code>http://www.domain.tld/</code>.</p>
<p>Pour rendre cette technique fonctionnelle, mettez un lien
dans votre serveur virtuel primaire vers
<code>http://www.domain.tld/domain/</code>. Ensuite, dans les
pages de ce serveur virtuel, assurez vous ne n'utiliser que
des liens relatifs (<em>par exemple</em>, "<code>file.html</code>"
ou "<code>../icons/image.gif</code>") ou des liens contenant
le pr�fixe <code>/domain/</code> (<em>par exemple</em>,
"<code>http://www.domain.tld/domain/misc/file.html</code>"
ou "<code>/domain/misc/file.html</code>").</p>
<p>Cela requiert un peu de discipline, mais si vous suivez
cette ligne de conduite, vous serez assur� que vos pages
s'afficheront dans tous les navigateurs, nouveaux et anciens.</p>
</section>
</manualpage>
<?xml version='1.0' encoding='ISO-8859-1' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
<!-- English Revision: 151405 -->
<!-- French translation by Vincent Deffontaines, review by alain B -->
<!--
Copyright 2005 The Apache Software Foundation or its licensors, as
applicable.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="details.xml.meta">
<parentdocument href="./">Serveurs virtuels</parentdocument>
<title>D�tails sur le fonctionnement des serveurs virtuels</title>
<summary>
<p>Le code g�rant les serveurs virtuels a �t� r��crit � partir de
z�ro dans <strong>Apache 1.3</strong>. Ce document vise � expliquer
dans le d�tail comment Apache proc�de lors du choix de l'utilisation
d'un serveur virtuel en fonction d'une requ�te re�ue. L'apparition
de la directive <directive module="core">NameVirtualHost</directive>
a rendu beaucoup plus facile et plus s�re la configuration des
serveurs virtuels par rapport aux versions pr�c�dant la 1.3.</p>
<p>Si vous voulez juste <cite>que �a marche</cite> sans en
comprendre le fonctionnement, voici <a href="examples.html">quelques
exemples</a>.</p>
</summary>
<section id="configparsing"><title>Interpr�tation des fichiers
de configuration</title>
<p>Un <em>serveur principal (main_server)</em> contient toutes
les d�finitions qui apparaissent en dehors des sections
<code><VirtualHost></code>. Les serveurs virtuels, aussi
appel�s <em>vhosts</em> (pour virtual hosts), sont d�finis par les
sections <directive type="section" module="core">VirtualHost</directive>.</p>
<p>Les directives
<directive module="mpm_common">Listen</directive>,
<directive module="core">ServerName</directive>,
<directive module="core">ServerPath</directive>,
et <directive module="core">ServerAlias</directive>
peuvent �tre plac�es n'importe o� dans le cadre de d�finition d'un
serveur. Cependant, chaque fois que l'une d'elles est lue, elle �crase
ses instances pr�c�dentes (dans le contexte du m�me serveur).</p>
<p>La valeur par d�faut du champ <code>Listen</code> pour le serveur
principal est de 80. Le serveur principal n'a pas de valeur par
d�faut pour <code>ServerPath</code> ni pour <code>ServerAlias</code>.
La valeur par d�faut de <code>ServerName</code> est d�duite � partir
de l'adresses IP du serveur.</p>
<p>La directive Listen associ�e au serveur principal a deux utilit�s.
La premi�re d�termine le port r�seau sur lequel Apache va �couter.
La deuxi�me sp�cifie le port qui sera utilis� dans les URIs absolus
lors des redirections.</p>
<p>� la diff�rence du serveur principal, les ports des serveurs
virtuels <em>n</em>'affectent <em>pas</em> les ports sur lesquels
Apache se met � l'�coute.</p>
<p>Chaque adresse incluse dans une directive <code>VirtualHost</code>
peut disposer d'un port optionnel. Si le port n'est pas pr�cis�, il
prend par d�faut la derni�re valeur de <code>Listen</code> lue dans
la configuration du serveur principal. Le port particulier
<code>*</code> repr�sente un joker qui correspond � tous les ports.
L'ensemble des adresses (y compris les r�sultats multiples
<code>A</code> issus des requ�tes DNS) est appel� <em>jeu
d'adresses</em> du serveur virtuel.</p>
<p>� moins qu'une directive
<directive module="core">NameVirtualHost</directive> ne soit utilis�e
pour une adresse IP sp�cifique, le premier serveur virtuel avec
cette adresse est consid�r� comme un <em>serveur virtuel par-IP</em>.
L'adresse IP peut �galement prendre la valeur joker <code>*</code>.</p>
<p>Dans les cas o� l'on souhaite utiliser un <em>serveur virtuel
par nom</em>, la directive <code>NameVirtualHost</code> <em>doit</em>
appara�tre avec l'adresse IP choisie. En d'autres termes, vous devez
sp�cifier dans votre fichier de configuration l'adresse IP des noms
de domaine (CNAME) de vos serveurs virtuels par nom au moyen de
la directive <code>NameVirtualHost</code>.</p>
<p>On peut utiliser plusieurs directives <code>NameVirtualHost</code>
pour un groupe de directives <code>VirtualHost</code>, mais seule
une directive <code>NameVirtualHost</code> doit �tre utilis�e pour
chaque couple IP:port donn�.</p>
<p>L'ordre d'apparition des directives <code>NameVirtualHost</code>
et <code>VirtualHost</code> est sans importance, ce qui fait que
les deux exemples suivants ont des effets identiques (seul l'ordre
des directives <code>VirtualHost</code> pour <em>un</em> jeu
d'adresses est important, voir ci-dessous) :</p>
<table><tr>
<td><example>
NameVirtualHost 111.22.33.44<br />
<VirtualHost 111.22.33.44><br />
# serveur A<br />
...<br />
</VirtualHost><br />
<VirtualHost 111.22.33.44><br />
# serveur B<br />
...<br />
</VirtualHost><br />
<br />
NameVirtualHost 111.22.33.55<br />
<VirtualHost 111.22.33.55><br />
# serveur C<br />
...<br />
</VirtualHost><br />
<VirtualHost 111.22.33.55><br />
# serveur D<br />
...<br />
</VirtualHost>
</example></td>
<td><example>
<VirtualHost 111.22.33.44><br />
# serveur A<br />
</VirtualHost><br />
<VirtualHost 111.22.33.55><br />
# serveur C<br />
...<br />
</VirtualHost><br />
<VirtualHost 111.22.33.44><br />
# serveur B<br />
...<br />
</VirtualHost><br />
<VirtualHost 111.22.33.55><br />
# serveur D<br />
...<br />
</VirtualHost><br />
<br />
NameVirtualHost 111.22.33.44<br />
NameVirtualHost 111.22.33.55<br />
<br />
</example></td>
</tr></table>
<p>(Il est conseill� d'adopter le choix de gauche pour faciliter
la lisibilit� des fichiers de configuration.)</p>
<p>Apr�s la lecture de la directive <code>VirtualHost</code>, le
serveur virtuel se voit attribuer une valeur <code>Listen</code>
par d�faut qui est la valeur du port associ� au premier nom sp�cifi�
dans sa directive <code>VirtualHost</code>.</p>
<p>La liste compl�te des noms d'une directive <code>VirtualHost</code>
est g�r�e exactement comme des <code>ServerAlias</code> (mais ne
sont pas �cras�s par d'autres <code>ServerAlias</code>) si tous
les noms sont r�solus dans ce jeu d'adresse. � noter que les �tats
<code>Listen</code> de ce serveur virtuel sont sans incidence sur
les ports attibu�s au jeu d'adresses.</p>
<p>Pendant la phase d'initialisation, une liste de chaque adresse
IP est g�n�r�e et introduite dans une table de 'hash'. Si une
adresse IP est utilis�e dans une directive <code>NameVirtualHost</code>,
cette liste contient les noms des serveurs virtuels pour cette
adresse. Si aucun serveur virtuel n'est d�fini pour cette adresse,
la directive <code>NameVirtualHost</code> est ignor�e et un message
est envoy� au journal d'erreurs. Quand un serveur virtuel par IP
est utilis�, la table de 'hash' reste vide.</p>
<p>La fonction de 'hash' �tant rapide, le temps d'ex�cution d'un
'hash' sur une adresse IP lors d'une requ�te est minimale et
quasiment imperceptible. De plus, la table est optimis�e pour les
adresses IP dont le dernier octet est le seul � changer.</p>
<p>Pour chaque serveur virtuel, diverses valeurs sont initialis�es
par d�faut. En particulier :</p>
<ol>
<li>Dans le cas o� un serveur virtuel ne contient pas de directives
<directive module="core">ServerAdmin</directive>,
<directive module="core">ResourceConfig</directive>,
<directive module="core">AccessConfig</directive>,
<directive module="core">Timeout</directive>,
<directive module="core">KeepAliveTimeout</directive>,
<directive module="core">KeepAlive</directive>,
<directive module="core">MaxKeepAliveRequests</directive>,
ou <directive module="core">SendBufferSize</directive>,
alors la valeur de chacun de ces param�tres est h�rit�e de celle du
serveur principal. (C'est � dire, h�rit�e de la valeur finale apr�s
lecture de la configuration du serveur principal.)</li>
<li>Les permissions par d�faut sur les r�pertoires de chaque
serveur virtuel sont assembl�es avec celles du serveur principal.
Elles concernent �galement toutes les informations de configuration
par r�pertoire pour tous les modules.</li>
<li>Les configurations par serveur pour chaque module sont assembl�es
� partir de celles du serveur principal.</li>
</ol>
<p>L'essentiel des valeurs de configuration des serveurs virtuels
provient de valeurs par d�faut issues du serveur principal. Donc,
l'emploi de ces directives propres au serveur virtuel dans le fichier
de configuration est largement d�conseill� -- l'ensemble de la
configuration du serveur principal est lu avant que ces valeurs par
d�faut soient appliqu�es aux serveur virtuels. Ainsi, m�me si la
d�finition d'une valeur appara�t apr�s celle d'un serveur virtuel,
cette valeur peut affecter la configuration du serveur virtuel.</p>
<p>Dans le cas o� le serveur principal n'a pas de <code>ServerName</code>
� ce stade, le nom de la machine sur laquelle tourne le programme
<program>httpd</program> est utilis� � sa place. Nous appellerons
<em>jeu d'adresses du serveur principal</em>, les adresses IP
renvoy�es par une r�solution DNS sur le <code>ServerName</code>
du serveur principal.</p>
<p>Pour tous les champs <code>ServerName</code> non d�finis, dans
le cas d'une configuration en serveur virtuel par nom, la valeur
adopt�e par d�faut est la premi�re adresse donn�e dans la section
<code>VirtualHost</code> qui d�finit le serveur virtuel.</p>
<p>Si un serveur virtuel contient la valeur magique
<code>_default_</code>, il fonctionne sur le m�me <code>ServerName</code>
que le serveur principal.</p>
</section>
<section id="hostmatching"><title>Choix du serveur virtuel</title>
<p>� la r�ception d'une requ�te, le serveur proc�de comme suit pour
d�terminer quel serveur virtuel utiliser :</p>
<section id="hashtable"><title>V�rification dans la table de hash</title>
<p>Apr�s que le client se soit connect� une premi�re fois, l'adresse
IP avec laquelle le client s'est connect� est recherch�e dans la
table de hash IP interne.</p>
<p>Si la r�solution de l'adresse IP n'aboutit pas (adresse IP non
trouv�e), la requ�te est servie par le serveur virtuel
<code>_default_</code> s'il est d�fini pour le port correspondant
� la requ�te. Sinon, elle est servie par le serveur principal.</p>
<p>Si l'adresse IP n'est pas trouv�e dans la table de hash, la
recherche du num�ro de port peut aussi se terminer par une
correspondance � un <code>NameVirtualHost *</code> qui est g�r�
ensuite comme les autres serveur virtuels par noms.</p>
<p>Si une liste est bien trouv�e dans la table pour l'adresse
IP recherch�e, l'�tape suivante est de d�terminer s'il s'agit
d'un serveur virtuel par nom ou par IP.</p>
</section>
<section id="ipbased"><title>Serveur virtuel par IP</title>
<p>Si l'entr�e trouv�e dispose d'une liste de noms vide, c'est
qu'il s'agit d'un serveur virtuel par IP, et aucun autre choix
n'est plus � faire ; la requ�te est servie par ce serveur virtuel.</p>
</section>
<section id="namebased"><title>Serveur virtuel par nom</title>
<p>Si l'entr�e trouv�e correspond � un serveur virtuel par nom,
la liste de noms contient au moins une structure de serveurs
virtuels. Les serveurs virtuels se pr�sentent dans cette liste
dans le m�me ordre que la lecture des directives <code>VirtualHost</code>
dans le fichier de configuration.</p>
<p>Le premier serveur virtuel de cette liste (donc, le premier
serveur virtuel attribu� � une adresse IP donn�e dans le fichier
de configuration) se voit attribuer la plus grande priorit�, ce
qui signifie que c'est lui qui traite les requ�tes pr�sentant un
nom de serveur invalide ou ne pr�sentant pas de champ
<code>Host:</code> dans l'en-t�te.</p>
<p>Si un champ <code>Host:</code> est transmis dans l'en-t�te de
la requ�te, son occurrence est recherch�e dans la liste et le
premier serveur virtuel qui pr�sente un <code>ServerName</code>
ou un <code>ServerAlias</code> correspondant est choisi pour
servir la requ�te. Il est possible que le champ <code>Host:</code>
contienne un num�ro de port, mais Apache utilise toujours le
port sur lequel il a effectivement re�u la requ�te.</p>
<p>Dans le cas o� le client a envoy� une requ�te en HTTP/1.0 sans
un champ d'en-t�te <code>Host:</code>, il est impossible de
d�terminer le serveur auquel le client veut se connecter ; l'URI
de la requ�te est recherch� dans tous les <code>ServerPath</code>
existants. Le premier chemin trouv� est utilis� et la requ�te est
servie par le serveur virtuel correspondant.</p>
<p>Si aucun serveur virtuel n'est trouv�, la requ�te est servie
par le premier serveur virtuel qui �coute sur le port demand� et
qui est sur la liste associ�e � l'adresse IP vers laquelle la
requ�te a �t� envoy�e (comme d�j� pr�cis� ci-avant).</p>
</section>
<section id="persistent"><title>Connexions persistantes</title>
<p>La recherche par adresse IP d�crite ci-avant n'est faite
qu'<em>une fois</em> pour chaque session TCP/IP, alors que la
recherche par nom est r�alis�e pour <em>chaque</em> requ�te au
cours d'une connexion persistante (KeepAlive). En d'autres termes,
il est possible pour un client de faire des requ�tes sur
diff�rents serveurs virtuels par nom, au cours d'une unique
connexion persistante.</p>
</section>
<section id="absoluteURI"><title>URI absolu</title>
<p>Au cas o� l'URI de la requ�te est absolu, et que son nom de
serveur et son port correspondent au serveur principal (ou l'un
des serveurs virtuels configur�s), <em>et</em> qu'ils correspondent
� l'adresse et au port de la requ�te, alors l'URI est amput�
de son pr�fixe protocole/nom de serveur/port et trait� par le
serveur correspondant (principal ou virtuel). Si cette correspondance
n'existe pas, l'URI reste inchang� et la requ�te est consid�r�e
comme une requ�te d'un serveur mandataire.</p>
</section>
<section id="observations"><title>Observations</title>
<ul>
<li>Les serveurs virtuels par nom et par IP n'interf�rent
jamais entre eux. Les serveurs virtuels par IP ne sont joignables
qu'au travers de leur(s) adresse(s) IP propre(s), en aucun
cas par aucune autre adresse. Les serveurs virtuels par nom
ne sont accessibles que par leur(s) adresse(s) IP qui ne peuvent
�tre d�finies qu'au moyen de la directive
<code>NameVirtualHost</code>.</li>
<li>Les v�rifications sur <code>ServerAlias</code> et
<code>ServerPath</code> ne sont jamais r�alis�es pour les
serveurs virtuels par IP.</li>
<li>L'ordre dans lequel sont agenc�s dans le fichier de
configuration le serveur virtuel <code>_default_</code>, les
serveurs virtuels par nom et par IP, et la directive
<code>NameVirtualHost</code> est sans incidence sur le
fonctionnement. Seul l'ordre des serveurs virtuels par nom
pour une adresse donn�e a une importance. Le serveur virtuel
par nom qui est pr�sent en premier dans la configuration se
voit attribu� la priorit� la plus haute pour les requ�tes
arrivant sur son jeu d'adresses IP.</li>
<li>Pour des raisons de s�curit�, le num�ro de port pr�sent�
dans le champ d'en-t�te <code>Host:</code> n'est jamais utilis�
pour les tests de correspondances. Apache ne prend en compte
que le num�ro de port sur lequel le client a envoy� la requ�te.</li>
<li>Si une directive <code>ServerPath</code> existe, et se
trouve �tre pr�fixe d'une autre directive <code>ServerPath</code>
qui appara�t plus loin dans la configuration, la premi�re
sera toujours utilis�e et la deuxi�me jamais. (Ceci ne se
produit que dans le cas o� aucun champ <code>Host:</code>
n'a �t� pr�sent� par le client pour distinguer les deux.)</li>
<li>Dans le cas o� deux serveurs virtuels par IP ont une
adresse en commun, le serveur virtuel qui appara�t en premier
dans la configuration est toujours choisi. Ce genre de chose
peut arriver par inadvertance. Le serveur envoie une alerte
dans le journal d'erreurs si ce cas se pr�sente.</li>
<li>Le serveur virtuel <code>_default_</code> ne sert la requ�te
que si aucun autre serveur virtuel travaillant sur l'adresse
IP <em>et</em> le port demand�s n'est trouv�. La requ�te n'est
trait�e que si le num�ro de port qui a re�u la requ�te est
associ� au serveur virtuel <code>_default_</code> (qui par
d�faut, correspond � <code>Listen</code>). Un port joker peut
�tre sp�cifi� (<em>comme dans</em> <code>_default_:*</code>)
pour r�cup�rer les requ�tes sur tous les ports ouverts. Ceci
est �galement applicable aux serveurs virtuels
<code>NameVirtualHost *</code>.</li>
<li>Le serveur principal ne sert � servir les requ�tes que
lorsque l'adresse IP et le port demand�s par le client ne
correspondent � aucun serveur virtuel (y compris un serveur
virtuel <code>_default_</code>). En d'autres termes, le serveur
principal n'est utile que pour les combinaisons adresse/port
non sp�cifi�es (sauf quand un serveur virtuel <code>_default_</code>
correspond au port).</li>
<li>Ni les serveurs virtuels <code>_default_</code>, ni le
serveur principal ne sont utilis�s pour traiter une requ�te
avec un champ d'en-t�te <code>Host:</code> manquant ou vide
lorsque l'adresse (et le port) de connexion correspondent �
des serveurs virtuels par nom, par exemple, dans une directive
<code>NameVirtualHost</code>.</li>
<li>Il ne faut jamais employer de noms DNS dans des directives
<code>VirtualHost</code>, car cela oblige le serveur a s'appuyer
sur le DNS au moment du d�marrage. De plus, vous vous exposez
� des probl�mes de s�curit� si vous n'avez pas la ma�trise du
DNS pour la totalit� de vos domaines. Voir la documentation
<a href="../dns-caveats.html">disponible ici</a>, ainsi que
les deux points pr�cis�s ci-apr�s.</li>
<li>Un nom de serveur <code>ServerName</code> devrait toujours
�tre indiqu� pour chaque serveur virtuel. Sans cela, une
r�solution DNS est n�cessaire pour chaque serveur virtuel.</li>
</ul>
</section>
</section>
<section id="tips"><title>Trucs et astuces</title>
<p>En plus des points �voqu�s sur la page des
<a href="../dns-caveats.html#tips">probl�mes li�s au DNS</a>,
voici quelques points int�ressants :</p>
<ul>
<li>Toujours positionner les d�finitions relatives au serveur
principal avant toute d�finition <code>VirtualHost</code>.
(Ceci am�liore grandement la lisibilit� de la configuration
-- la mani�re dont la configuration est interpr�t�e apr�s la
lecture des fichiers ne met pas en �vidence le fait que les
d�finitions positionn�es avant et surtout apr�s les serveurs
virtuels peuvent impacter le fonctionnement des serveurs virtuels.)</li>
<li>Toujours regrouper les d�finitions <code>NameVirtualHost</code>
et <code>VirtualHost</code> dans la configuration pour une
meilleure lisibilit�.</li>
<li>�viter les <code>ServerPaths</code> qui sont pr�fixes
d'autres <code>ServerPaths</code>. Si cela ne peut �tre �vit�,
veillez � ce que le serveur virtuel contenant le pr�fixe le plus
long (donc le plus pr�cis) apparaisse dans le fichier de
configuration avant le plus court. (<em>par exemple</em>,
"ServerPath /abc" est � sp�cifier apr�s "ServerPath /abc/def").</li>
</ul>
</section>
</manualpage>
<?xml version='1.0' encoding='ISO-8859-1' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
<!-- English Revision: 151405 -->
<!-- French translation by Vincent Deffontaines, Alain B., review by -->
<!--
Copyright 2005 The Apache Software Foundation or its licensors, as
applicable.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="examples.xml.meta">
<parentdocument href="./">Serveurs virtuels</parentdocument>
<title>Exemples d'utilisations de VirtualHost</title>
<summary>
<p>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 <a href="name-based.html">par nom</a>
ou <a href="ip-based.html">par IP</a>.</p>
</summary>
<section id="purename"><title>Fonctionnement de plusieurs serveurs
virtuels par nom sur une seule adresse IP.</title>
<p>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, <code>www.example1.com</code> et
<code>www.example2.org</code> doivent tourner sur cette machine.</p>
<note><title>Note :</title><p>La configuration de serveurs virtuels
sous Apache ne provoque pas leur apparition magique dans la
configuration du DNS. Il <em>faut</em> 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
<code>hosts</code> pour tests locaux, mais qui ne fonctionneront
que sur la machine poss�dant ces entr�es.</p>
</note>
<example>
<title>Configuration du serveur</title>
# Apache doit �couter sur le port 80<br />
Listen 80<br />
<br />
# Toutes les adresses IP doivent r�pondre aux requ�tes sur les
# serveurs virtuels
NameVirtualHost *:80<br />
<br />
<VirtualHost *:80><br />
<indent>
DocumentRoot /www/example1<br />
ServerName www.example1.com<br />
<br />
# Autres directives ici<br />
<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost *:80><br />
<indent>
DocumentRoot /www/example2<br />
ServerName www.example2.org<br />
<br />
# Autres directives ici<br />
<br />
</indent>
</VirtualHost>
</example>
<p>Les ast�risques correspondent � toutes les adresses, si bien que
le serveur principal ne r�pondra jamais � aucune requ�te. Comme
<code>www.example1.com</code> se trouve en premier dans le fichier
de configuration, il a la plus grande priorit� et peut �tre vu
comme serveur <cite>par d�faut</cite> ou <cite>primaire</cite> ;
ce qui signifie que toute requ�te re�ue ne correspondant pas � une
des directives <code>ServerName</code> sera servie par ce premier
<code>VirtualHost</code>.</p>
<note>
<title>Note :</title>
<p>Si vous le souhaitez, vous pouvez remplacer <code>*</code>
par l'adresse IP du syst�me. Dans ce cas, l'argument de
<code>VirtualHost</code> <em>doit</em> correspondre �
l'argument de <code>NameVirtualHost</code> :</p>
<example>
NameVirtualHost 172.20.30.40<br />
<br />
<VirtualHost 172.20.30.40><br />
# etc ...
</example>
<p>En g�n�ral, il est commode d'utiliser <code>*</code> 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 <code>*</code> signifie
<cite>n'importe quelle adresse</cite>, cette configuration
fonctionne sans devoir �tre modifi�e quand l'adresse IP du
syst�me est modifi�e.</p>
</note>
<p>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.</p>
</section>
<section id="twoips"><title>Serveurs virtuels par nom sur plus
d'une seule adresse IP.</title>
<note>
<title>Note :</title><p>Toutes les techniques pr�sent�es ici
peuvent �tre �tendues � un plus grand nombre d'adresses IP.</p>
</note>
<p>Le serveur a deux adresses IP. Sur l'une
(<code>172.20.30.40</code>), le serveur "principal"
<code>server.domain.com</code> doit r�pondre, et sur l'autre
(<code>172.20.30.50</code>), deux serveurs virtuels (ou plus)
r�pondront.</p>
<example>
<title>Configuration du serveur</title>
Listen 80<br />
<br />
# Serveur "principal" sur 172.20.30.40<br />
ServerName server.domain.com<br />
DocumentRoot /www/mainserver<br />
<br />
# l'autre adresse <br />
NameVirtualHost 172.20.30.50<br />
<br />
<VirtualHost 172.20.30.50><br />
<indent>
DocumentRoot /www/example1<br />
ServerName www.example1.com<br />
<br />
# D'autres directives ici ...<br />
<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost 172.20.30.50><br />
<indent>
DocumentRoot /www/example2<br />
ServerName www.example2.org<br />
<br />
# D'autres directives ici ...<br />
<br />
</indent>
</VirtualHost>
</example>
<p>Toute requ�te arrivant sur une autre adresse que
<code>172.20.30.50</code> sera servie par le serveur principal.
Les requ�tes vers <code>172.20.30.50</code> avec un nom de serveur
inconnu, ou sans en-t�te <code>Host:</code>, seront servies par
<code>www.example1.com</code>.</p>
</section>
<section id="intraextra"><title>Servir le m�me contenu sur des
adresses IP diff�rentes (telle qu'une adresse interne et une
externe).</title>
<p>La machine serveur dispose de deux adresses IP
(<code>192.168.1.1</code> et <code>172.20.30.40</code>). Cette
machine est plac�e � la fois sur le r�seau interne (l'Intranet)
et le r�seau externe (Internet). Sur Internet, le nom
<code>server.example.com</code> pointe vers l'adresse externe
(<code>172.20.30.40</code>), mais sur le r�seau interne, ce m�me
nom pointe vers l'adresse interne (<code>192.168.1.1</code>).</p>
<p>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
<code>VirtualHost</code>.</p>
<example>
<title>Configuration du serveur</title>
NameVirtualHost 192.168.1.1<br />
NameVirtualHost 172.20.30.40<br />
<br />
<VirtualHost 192.168.1.1 172.20.30.40><br />
<indent>
DocumentRoot /www/server1<br />
ServerName server.example.com<br />
ServerAlias server<br />
</indent>
</VirtualHost>
</example>
<p>Ainsi, les requ�tes en provenance de chacun des deux r�seaux
seront servies par le m�me <code>VirtualHost</code>.</p>
<note>
<title>Note :</title><p>Sur le r�seau interne, il est possible
d'utiliser le nom raccourci <code>server</code> au lieu du nom
complet <code>server.example.com</code>.</p>
<p>Notez �galement que dans l'exemple pr�c�dent, vous pouvez
remplacer la liste des adresses IP par des <code>*</code> afin
que le serveur r�ponde de la m�me mani�re sur toutes ses
adresses.</p>
</note>
</section>
<section id="port"><title>Servir diff�rents sites sur diff�rents
ports.</title>
<p>Vous disposez de plusieurs domaines pointant sur la m�me adresse
IP et vous voulez �galement servir de multiples ports. Vous y
parviendrez en d�finissant les ports dans la directive
"NameVirtualHost". Si vous tentez d'utiliser <VirtualHost
name:port> sans directive NameVirtualHost name:port, ou tentez
d'utiliser la directive Listen, votre configuration ne fonctionnera
pas.</p>
<example>
<title>Configuration du serveur</title>
Listen 80<br />
Listen 8080<br />
<br />
NameVirtualHost 172.20.30.40:80<br />
NameVirtualHost 172.20.30.40:8080<br />
<br />
<VirtualHost 172.20.30.40:80><br />
<indent>
ServerName www.example1.com<br />
DocumentRoot /www/domain-80<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost 172.20.30.40:8080><br />
<indent>
ServerName www.example1.com<br />
DocumentRoot /www/domain-8080<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost 172.20.30.40:80><br />
<indent>
ServerName www.example2.org<br />
DocumentRoot /www/otherdomain-80<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost 172.20.30.40:8080><br />
<indent>
ServerName www.example2.org<br />
DocumentRoot /www/otherdomain-8080<br />
</indent>
</VirtualHost>
</example>
</section>
<section id="ip"><title>H�bergement virtuel bas� sur IP</title>
<p>Le serveur dispose de deux adresses IP (<code>172.20.30.40</code>
et <code>172.20.30.50</code>) correspondant respectivement aux noms
<code>www.example1.com</code> et <code>www.example2.org</code>.</p>
<example>
<title>Configuration du serveur</title>
Listen 80<br />
<br />
<VirtualHost 172.20.30.40><br />
<indent>
DocumentRoot /www/example1<br />
ServerName www.example1.com<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost 172.20.30.50><br />
<indent>
DocumentRoot /www/example2<br />
ServerName www.example2.org<br />
</indent>
</VirtualHost>
</example>
<p>Les requ�tes provenant d'adresses non sp�cifi�es dans l'une des
directives <code><VirtualHost></code> (comme pour
<code>localhost</code> par exemple) seront dirig�es vers le serveur
principal, s'il en existe un.</p>
</section>
<section id="ipport"><title>H�bergements virtuels mixtes bas�s sur
les ports et sur les IP</title>
<p>Le serveur dispose de deux adresses IP (<code>172.20.30.40</code>
et <code>172.20.30.50</code>) correspondant respectivement aux noms
<code>www.example1.com</code> et <code>www.example2.org</code>.
Pour chacun d'eux, nous voulons un h�bergement sur les ports 80
et 8080.</p>
<example>
<title>Configuration du serveur</title>
Listen 172.20.30.40:80<br />
Listen 172.20.30.40:8080<br />
Listen 172.20.30.50:80<br />
Listen 172.20.30.50:8080<br />
<br />
<VirtualHost 172.20.30.40:80><br />
<indent>
DocumentRoot /www/example1-80<br />
ServerName www.example1.com<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost 172.20.30.40:8080><br />
<indent>
DocumentRoot /www/example1-8080<br />
ServerName www.example1.com<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost 172.20.30.50:80><br />
<indent>
DocumentRoot /www/example2-80<br />
ServerName www.example1.org<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost 172.20.30.50:8080><br />
<indent>
DocumentRoot /www/example2-8080<br />
ServerName www.example2.org<br />
</indent>
</VirtualHost>
</example>
</section>
<section id="mixed"><title>H�bergements virtuels mixtes bas� sur
les noms et sur IP</title>
<p>Pour certaines adresses, des serveurs virtuels seront d�finis
par nom, et pour d'autres, ils seront d�finis par IP.</p>
<example>
<title>Configuration du serveur</title>
Listen 80<br />
<br />
NameVirtualHost 172.20.30.40<br />
<br />
<VirtualHost 172.20.30.40><br />
<indent>
DocumentRoot /www/example1<br />
ServerName www.example1.com<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost 172.20.30.40><br />
<indent>
DocumentRoot /www/example2<br />
ServerName www.example2.org<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost 172.20.30.40><br />
<indent>
DocumentRoot /www/example3<br />
ServerName www.example3.net<br />
</indent>
</VirtualHost><br />
<br />
# "par-IP"<br />
<VirtualHost 172.20.30.50><br />
<indent>
DocumentRoot /www/example4<br />
ServerName www.example4.edu<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost 172.20.30.60><br />
<indent>
DocumentRoot /www/example5<br />
ServerName www.example5.gov<br />
</indent>
</VirtualHost>
</example>
</section>
<section id="proxy"><title>Utilisation simultan�e de
<code>Virtual_host</code> et de mod_proxy</title>
<p>L'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 <code>192.168.111.2</code>. La directive
<directive module="mod_proxy">ProxyPreserveHost On</directive> 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.</p>
<example>
<VirtualHost *:*><br />
ProxyPreserveHost On<br />
ProxyPass / http://192.168.111.2<br />
ProxyPassReverse / http://192.168.111.2/<br />
ServerName hostname.example.com<br />
</VirtualHost>
</example>
</section>
<section id="default"><title>Utilisation de serveurs virtuels
<code>_default_</code></title>
<section id="defaultallports"><title>Serveurs virtuels
<code>_default_</code> pour tous les ports</title>
<p>Exemple de capture de <em>toutes</em> les requ�tes �manant
d'adresses IP ou de ports non connus, <em>c'est-�-dire</em>, d'un
couple adresse/port non trait� par aucun autre serveur virtuel.</p>
<example>
<title>Configuration du serveur</title>
<VirtualHost _default_:*><br />
<indent>
DocumentRoot /www/default<br />
</indent>
</VirtualHost>
</example>
<p>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.</p>
<p>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
<code>Host:</code> 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).</p>
<p>Vous pouvez utiliser une directive
<directive module="mod_alias">AliasMatch</directive> ou
<directive module="mod_rewrite">RewriteRule</directive> afin de
r��crire une requ�te pour une unique page d'information (ou pour
un script).</p>
</section>
<section id="defaultdifferentports"><title>Serveurs virtuels
<code>_default_</code> pour des ports diff�rents</title>
<p>La configuration est similaire � l'exemple pr�c�dent, mais
le serveur �coute sur plusieurs ports et un second serveur virtuel
<code>_default_</code> pour le port 80 est ajout�.</p>
<example>
<title>Configuration du serveur</title>
<VirtualHost _default_:80><br />
<indent>
DocumentRoot /www/default80<br />
# ...<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost _default_:*><br />
<indent>
DocumentRoot /www/default<br />
# ...<br />
</indent>
</VirtualHost>
</example>
<p>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.</p>
</section>
<section id="defaultoneport"><title>Serveurs virtuels
<code>_default_</code> pour un seul port</title>
<p>Nous voulons cr�er un serveur virtuel par d�faut seulement
pour le port 80.</p>
<example>
<title>Configuration du serveur</title>
<VirtualHost _default_:80><br />
DocumentRoot /www/default<br />
...<br />
</VirtualHost>
</example>
<p>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.</p>
</section>
</section>
<section id="migrate"><title>Migration d'un serveur virtuel
par nom en un serveur virtuel par IP</title>
<p>Le serveur virtuel par nom avec le nom de domaine
<code>www.example2.org</code> (de notre <a href="#name">exemple
par nom</a>) 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.<br />
La solution est simple, car il suffit d'ajouter la nouvelle
adresse IP (<code>172.20.30.50</code>) dans la directive
<code>VirtualHost</code>.</p>
<example>
<title>Configuration du serveur</title>
Listen 80<br />
ServerName www.example1.com<br />
DocumentRoot /www/example1<br />
<br />
NameVirtualHost 172.20.30.40<br />
<br />
<VirtualHost 172.20.30.40 172.20.30.50><br />
<indent>
DocumentRoot /www/example2<br />
ServerName www.example2.org<br />
# ...<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost 172.20.30.40><br />
<indent>
DocumentRoot /www/example3<br />
ServerName www.example3.net<br />
ServerAlias *.example3.net<br />
# ...<br />
</indent>
</VirtualHost>
</example>
<p>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).</p>
</section>
<section id="serverpath"><title>Utilisation de la directive
<code>ServerPath</code></title>
<p>Dans le cas o� vous disposez de deux serveurs virtuels par nom,
le client doit transmettre un en-t�te <code>Host:</code> 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.</p>
<example>
<title>Configuration du serveur</title>
NameVirtualHost 172.20.30.40<br />
<br />
<VirtualHost 172.20.30.40><br />
<indent>
# Serveur virtuel primaire<br />
DocumentRoot /www/subdomain<br />
RewriteEngine On<br />
RewriteRule ^/.* /www/subdomain/index.html<br />
# ...<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost 172.20.30.40><br />
DocumentRoot /www/subdomain/sub1<br />
<indent>
ServerName www.sub1.domain.tld<br />
ServerPath /sub1/<br />
RewriteEngine On<br />
RewriteRule ^(/sub1/.*) /www/subdomain$1<br />
# ...<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost 172.20.30.40><br />
<indent>
DocumentRoot /www/subdomain/sub2<br />
ServerName www.sub2.domain.tld<br />
ServerPath /sub2/<br />
RewriteEngine On<br />
RewriteRule ^(/sub2/.*) /www/subdomain$1<br />
# ...<br />
</indent>
</VirtualHost>
</example>
<p>� cause de la directive
<directive module="core">ServerPath</directive>, une requ�te sur
une URL <code>http://www.sub1.domain.tld/sub1/</code> est
<em>toujours</em> servie par le serveur sub1-vhost.<br />
Une requ�te sur une URL <code>http://www.sub1.domain.tld/</code> n'est
servie par le serveur sub1-vhost que si le client envoie un en-t�te
<code>Host:</code> correct. Si aucun en-t�te <code>Host:</code>
n'est transmis, le serveur primaire sera utilis�.<br />
Notez qu'il y a une singularit� : une requ�te sur
<code>http://www.sub2.domain.tld/sub1/</code> est �galement servie
par le serveur sub1-vhost si le client n'envoie pas d'en-t�te
<code>Host:</code>.<br />
Les directives <directive module="mod_rewrite">RewriteRule</directive>
sont employ�es pour s'assurer que le client qui envoie un en-t�te
<code>Host:</code> correct puisse utiliser d'autres variantes d'URLs,
<em>c'est-�-dire</em> avec ou sans pr�fixe d'URL.</p>
</section>
</manualpage>
<?xml version='1.0' encoding='ISO-8859-1' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
<!-- English Revision: 151405 -->
<!-- French translation by Vincent Deffontaines, review by alain B -->
<!--
Copyright 2005 The Apache Software Foundation or its licensors, as
applicable.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="fd-limits.xml.meta">
<parentdocument href="./">Serveurs Virtuels</parentdocument>
<title>Limites des descripteurs de fichiers</title>
<summary>
<p>Quand de nombreux serveurs virtuels sont cr��s, Apache peut
d�passer les limites en descripteurs de fichiers ('file descriptors',
�galement appel�s <cite>gestionnaires de fichiers</cite>) si chacun
des serveurs virtuels utilise ses propres fichiers journaux. Le
nombre total de descripteurs de fichiers utilis�s par Apache est
d'un par fichier journal, un pour chacune des autres directives
de fichiers journaux, plus un nombre constant compris entre 10 et 20
pour son fonctionnement interne. Les syst�mes d'exploitation Unix
limitent le nombre de descripteurs de fichiers utilisables par
processus ; une valeur courante pour cette limite est de 64, et
cette valeur peut le plus souvent �tre augment�e.</p>
<p>Apache tente d'accro�tre cette valeur limite si n�cessaire, mais
sans y parvenir dans les cas suivants :</p>
<ol>
<li>Le syst�me d'exploitation ne permet pas l'utilisation d'appels
syst�mes <code>setrlimit()</code>.</li>
<li>L'appel <code>setrlimit(RLIMIT_NOFILE)</code> ne fonctionne pas
sur votre syst�me d'exploitation (c'est le cas sous Solaris 2.3).</li>
<li>Le nombre de descripteurs de fichiers n�cessaires � Apache
d�passe la limite physique du mat�riel.</li>
<li>Le syst�me impose d'autres limites sur l'utilisation des
descripteurs de fichiers, comme par exemple une limite sur les
flux stdio, utilisables uniquement sur les descripteurs de
fichiers inf�rieurs � 256. (sous Solaris 2).</li>
</ol>
<p>En cas de probl�me, Vous pouvez :</p>
<ul>
<li>R�duire le nombre de fichiers journaux, en ne sp�cifiant
aucun fichier journal dans les sections
<directive type="section" module="core">VirtualHost</directive>,
en donc en envoyant les informations aux fichiers journaux du
serveur principal (Voir <a href="#splitlogs">�clatement des
fichiers journaux</a> ci-dessous pour plus d'informations sur
cette possibilit�).</li>
<li>
Dans les cas 1 ou 2 (�voqu�s ci-dessus), augmentez la limite sur
les descripteurs de fichiers avant le d�marrage d'Apache, au
moyen d'un script comme
<example>
<code>#!/bin/sh<br />
ulimit -S -n 100<br />
exec httpd</code>
</example>
</li>
</ul>
<p>Veuillez noter que le document
<a href="../misc/descriptors.html">Descripteurs et Apache</a>
contient plus de d�tails concernant les probl�mes de descripteurs
de fichiers et comment les r�soudre en fonction de votre syst�me
d'exploitation.</p>
</summary>
<section id="splitlogs"><title>�clatement des fichiers journaux</title>
<p>Lorsque vous choisissez d'enregistrer les informations �manant de
plusieurs serveurs virtuels dans un m�me fichier journal, vous voudrez
ensuite pouvoir scinder ces informations � des fins de statistiques, par
exemple, sur les diff�rents serveurs virtuels. Il est possible de proc�der
de la mani�re suivante :</p>
<p>Tout d'abord, vous devez ajouter le nom du serveur virtuel � chaque
entr�e du journal. Ceci se param�tre au moyen de la directive
<directive module="mod_log_config"> LogFormat</directive> et de la
variable <code>%v</code>. Ajoutez cette variable au d�but de la cha�ne
de d�finition du format de journalisations :</p>
<example>
LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost<br />
CustomLog logs/multiple_vhost_log vhost
</example>
<p>Cette configuration va provoquer la cr�ation d'un fichier de
journalisation au format standard (CLF : 'Common Log Format'), mais dont
chaque ligne d�butera par le nom canonique du serveur virtuel (sp�cifi�
par la directive <directive module="core">ServerName</directive>).
(Voir <directive module="mod_log_config">Formats de journalisation
personnalis�s</directive> pour d'autres informations sur la
personnalisation des fichiers journaux.)</p>
<p>Au moment de s�parer les informations du fichier journal en un fichier
par serveur virtuel, le programme <code>
<a href="../programs/other.html">split-logfile</a></code> peut �tre
utilis�. Ce programme peut �tre trouv� dans le r�pertoire
<code>support</code> de la distribution d'Apache.</p>
<p>Ex�cutez ce programme au moyen de la commande :</p>
<example>
split-logfile < /logs/multiple_vhost_log
</example>
<p>Une fois ex�cut� avec le nom du fichier contenant tous les journaux,
ce programme va g�n�rer un fichier pour chacun des serveurs virtuels
qui appara�t dans le fichier d'entr�e. Chaque fichier en sortie est
nomm� <code>nomduserveur.log</code>.</p>
</section>
</manualpage>
<?xml version='1.0' encoding='ISO-8859-1' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
<!-- English Revision: 151405 -->
<!-- French translation by alain B, review by -->
<!--
Copyright 2005 The Apache Software Foundation or its licensors, as
applicable.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="ip-based.xml.meta">
<parentdocument href="./">Serveurs virtuels</parentdocument>
<title>Support Apache des serveurs virtuels par IP</title>
<seealso>
<a href="name-based.html">Support Apache des serveurs virtuels par nom</a>
</seealso>
<section id="requirements"><title>Syst�me requis</title>
<p>Comme l'indique le terme <cite>par IP</cite>, le serveur
<strong>doit disposer de diff�rentes adresses IP pour chaque
serveur virtuel par IP</strong>. La machine peut poss�der
plusieurs connexions physiques au r�seau, ou utiliser des
interfaces virtuelles qui sont support�es par la plupart des
syst�mes d'exploitation modernes (Consultez la documentation des
syst�mes d'exploitation pour plus de d�tails, notamment les "alias
IP" et la commande "ifconfig" pour les activer).</p>
</section>
<section id="howto"><title>Comment configurer Apache</title>
<p>Il y a deux mani�res de configurer Apache pour le support de
multiples serveurs virtuels. Il suffit soit de faire tourner un
processus r�sident <program>httpd</program> pour chaque nom de
domaine, soit de faire tourner un unique processus r�sident qui
g�re tous les serveurs virtuels.</p>
<p>Utilisez des processus r�sidents multiples lorsque :</p>
<ul>
<li>il y a des probl�mes de r�partition de s�curit�, tels
qu'une entreprise1 ne souhaite que personne d'une entreprise2
ne puisse lire ses donn�es except� via le Web. Dans ce cas,
vous aurez besoin de deux processus r�sidents, chacun fonctionnant
avec des param�tres <directive module="mpm_common">User</directive>,
<directive module="mpm_common">Group</directive>,
<directive module="mpm_common">Listen</directive>, et
<directive module="core">ServerRoot</directive> diff�rents.</li>
<li>vous disposez suffisamment de m�moire et de
<a href="../misc/descriptors.html">descripteurs de fichiers</a>
pour l'�coute de chaque alias IP de la machine. Il est seulement
possible d'appliquer la directive
<directive module="mpm_common">Listen</directive>, soit sur toutes
les adresses avec le joker "*", soit uniquement sur des adresses
sp�cifiques. Donc, si vous avez besoin d'�couter une adresse
en particulier, vous devrez le faire pour l'ensemble des
autres adresses (Bien qu'il soit plus simple de lancer un
processus <program>httpd</program> pour �couter N-1 adresses,
et un autre pour l'adresse restante).</li>
</ul>
<p>Utilisez un unique processus r�sident lorsque :</p>
<ul>
<li>le partage de la configuration httpd entre les serveurs
virtuels est acceptable.</li>
<li>la machine assume d�j� une grande quantit� de requ�tes, et
que l'ajout de processus r�sidents suppl�mentaires en affecterait
les performances.</li>
</ul>
</section>
<section id="multiple"><title>Configuration de processus multiples</title>
<p>Cr�ez une installation ind�pendante du programme
<program>httpd</program> pour chaque serveur virtuel. Pour
chacune d'elle, utilisez la directive
<directive module="mpm_common">Listen</directive> dans le fichier
de configuration pour d�finir l'adresse IP (ou serveur virtuel)
que le processus r�sident doit g�rer. Par exemple :</p>
<example>
Listen www.smallco.com:80
</example>
<p>Il est recommand� d'utiliser une adresse IP plut�t qu'un nom
de domaine (consultez <a href="../dns-caveats.html">Probl�mes DNS
avec Apache</a>).</p>
</section>
<section id="single"><title>Configuration d'un unique processus
r�sident pour des serveurs virtuels</title>
<p>Dans ce cas, un unique processus httpd va g�rer les requ�tes
pour le serveur principal et tous les serveurs virtuels. Dans le
fichier de configuration, la directive
<directive module="core">VirtualHost</directive> va servir �
d�finir les autres directives
<directive module="core">ServerAdmin</directive>,
<directive module="core">ServerName</directive>,
<directive module="core">DocumentRoot</directive>,
<directive module="core">ErrorLog</directive> et
<directive module="mod_log_config">TransferLog</directive> ou
<directive module="mod_log_config">CustomLog</directive> avec des
valeurs diff�rentes pour chaque serveur virtuel. Par exemple :</p>
<example>
<VirtualHost www.smallco.com><br />
ServerAdmin [EMAIL PROTECTED]<br />
DocumentRoot /groups/smallco/www<br />
ServerName www.smallco.com<br />
ErrorLog /groups/smallco/logs/error_log<br />
TransferLog /groups/smallco/logs/access_log<br />
</VirtualHost><br />
<br />
<VirtualHost www.baygroup.org><br />
ServerAdmin [EMAIL PROTECTED]<br />
DocumentRoot /groups/baygroup/www<br />
ServerName www.baygroup.org<br />
ErrorLog /groups/baygroup/logs/error_log<br />
TransferLog /groups/baygroup/logs/access_log<br />
</VirtualHost>
</example>
<p>Il est recommand� d'utiliser une adresse IP plut�t qu'un nom
de domaine (consultez <a href="../dns-caveats.html">Probl�mes DNS
avec Apache</a>).</p>
<p>Presque <strong>toutes</strong> les directives de configuration
peuvent �tre employ�es dans une directive VirtualHost, � l'exception
des directives qui contr�lent la cr�ation du processus et de
quelques autres. Pour conna�tre celles utilisables dans une
directive VirtualHost, v�rifiez leur
<a href="../mod/directive-dict.html#Context">Contexte</a> en utilisant
l'<a href="../mod/directives.html">Index des directives</a>.</p>
<p>Les directives <directive module="mpm_common">User</directive> et
<directive module="mpm_common">Group</directive> doivent �tre
utilis�es � l'int�rieur d'une directive VirtualHost lors d'une
<a href="../suexec.html">ex�cution sous suEXEC</a>.</p>
<p><em>S�CURIT� :</em> lorsque vous sp�cifiez o� �crire les
fichiers journaux, soyez attentif aux risques si quelqu'un d'autre
que celui qui a d�marr� Apache dispose des droits d'�criture
sur l'emplacement de ces fichiers. Consultez les
<a href="../misc/security_tips.html">Conseils sur la s�curit�</a>
pour plus de d�tails.</p>
</section>
</manualpage>
<?xml version='1.0' encoding='ISO-8859-1' ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
<!-- English Revision: 151405 -->
<!-- French translation by alain B, review by -->
<!--
Copyright 2005 The Apache Software Foundation or its licensors, as
applicable.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="mass.xml.meta">
<parentdocument href="./">Serveurs virtuels</parentdocument>
<title>Configuration dynamique des h�bergements virtuels de masse</title>
<summary>
<p>Ce document d�crit comment servir efficacement un nombre
ind�termin� de serveurs virtuels avec Apache 1.3. <!--
Written by Tony Finch ([EMAIL PROTECTED]) ([EMAIL PROTECTED]).
Some examples were derived from Ralf S. Engleschall's document
http://www.engelschall.com/pw/apache/rewriteguide/
Some suggestions were made by Brian Behlendorf.
-->
</p>
</summary>
<section id="motivation"><title>But recherch�</title>
<p>Les techniques d�crites ici ne sont dignes d'int�r�ts que
si votre fichier de configuration <code>httpd.conf</code>
contient beaucoup de sections <code><VirtualHost></code>
qui sont presque identiques, comme par exemple :</p>
<example>
NameVirtualHost 111.22.33.44<br />
<VirtualHost 111.22.33.44><br />
<indent>
ServerName www.customer-1.com<br />
DocumentRoot /www/hosts/www.customer-1.com/docs<br />
ScriptAlias /cgi-bin/ /www/hosts/www.customer-1.com/cgi-bin<br />
</indent>
</VirtualHost><br />
<VirtualHost 111.22.33.44><br />
<indent>
ServerName www.customer-2.com<br />
DocumentRoot /www/hosts/www.customer-2.com/docs<br />
ScriptAlias /cgi-bin/ /www/hosts/www.customer-2.com/cgi-bin<br />
</indent>
</VirtualHost><br />
# blah blah blah<br />
<VirtualHost 111.22.33.44><br />
<indent>
ServerName www.customer-N.com<br />
DocumentRoot /www/hosts/www.customer-N.com/docs<br />
ScriptAlias /cgi-bin/ /www/hosts/www.customer-N.com/cgi-bin<br />
</indent>
</VirtualHost>
</example>
<p>L'id�e de base est de remplacer dans la configuration toutes
les d�clarations statiques <code><VirtualHost></code> par
un m�canisme qui les produira de fa�on dynamique en offrant de
nombreux avantages :</p>
<ol>
<li>Votre fichier de configuration est plus petit, et permet
� Apache de d�marrer plus rapidement en utilisant moins de
m�moire.</li>
<li>L'ajout de serveurs virtuels revient � simplement cr�er
des r�pertoires appropri�s dans le syst�me de fichiers et
des entr�es dans le DNS - vous n'avez pas besoin de
reconfigurer ou red�marrer Apache.</li>
</ol>
<p>Le principal inconv�nient est que vous ne disposerez pas
de fichiers journaux diff�rents pour chaque serveur virtuel ;
toutefois si c'�tait le cas, vous atteindriez rapidement les
limites des descripteurs de fichiers. Il est pr�f�rable
d'ajouter les informations dans un m�me journal les unes �
la suite des autres, et de s'arranger pour qu'un processus
se charge de les distribuer vers les clients (cela permet
les statistiques accumul�es, etc.).</p>
</section>
<section id="overview"><title>Aper�u</title>
<p>Un serveur virtuel est d�fini par deux morceaux d'information :
son adresse IP et le contenu du champ <code>Host:</code> dans
une requ�te HTTP. La technique d'h�bergement dynamique de masse
s'appuie sur l'ajout automatique de cette information au chemin
du fichier renvoy� pour satisfaire la requ�te. Il suffit
simplement d'utiliser le module <module>mod_vhost_alias</module>,
mais si vous disposez d'une version d'Apache sup�rieure � 1.3.6,
vous devriez utiliser le module <module>mod_rewrite</module>.
Par d�faut, ces deux modules ne sont pas activ�s, donc il vous
faudra en activer un pour pouvoir employer cette technique.</p>
<p>Certaines choses ont besoin d'�tre truqu�es pour rendre
un serveur virtuel dynamique similaire � un serveur virtuel
normal. La plus importante est le nom du serveur qu'Apache
utilisera pour g�n�rer les URLs auto-r�f�renc�es, etc. Ce nom
est configur� avec la directive <code>ServerName</code>, et il
sera disponible pour les scripts CGIs via la variable d'environnement
<code>SERVER_NAME</code>. La valeur en cours d'ex�cution est
contr�l�e par le param�trage de la directive
<directive module="core">UseCanonicalName</directive>. Avec
<code>UseCanonicalName Off</code>, le nom du serveur provient
du contenu du champ <code>Host:</code> de la requ�te. Avec
<code>UseCanonicalName DNS</code>, il provient de la r�solution
inverse DNS sur l'adresse IP du serveur virtuel. La premi�re
configuration sert pour l'h�bergement virtuel dynamique par nom,
et la seconde sert pour l'h�bergement par IP. Si Apache ne
parvient pas � d�terminer le nom du serveur, soit parce qu'il
n'y a pas de champ <code>Host:</code> dans l'en-t�te, soit
parce que la r�solution DNS �choue, alors la valeur configur�e
par <code>ServerName</code> sera employ�e � la place.</p>
<p>L'autre astuce porte sur la racine des documents (configur�e
avec <code>DocumentRoot</code> et disponible dans les scripts CGI
au moyen de la variable d'environnement <code>DOCUMENT_ROOT</code>).
Dans une configuration classique, ce param�tre est utilis� par
le module principal pour attribuer leurs URIs aux fichiers �
servir, mais lorsque le serveur est configur� pour l'h�bergement
de serveurs dynamiques virtuels, ce travail est effectu� d'une
mani�re diff�rente par un autre module (soit
<code>mod_vhost_alias</code> ou soit <code>mod_rewrite</code>).
Aucun de ces modules n'assurant la configuration de la variable
<code>DOCUMENT_ROOT</code>, sa valeur lue par des scripts CGI
ou des documents SSI peut s'av�rer erron�e.</p>
</section>
<section id="simple"><title>Serveurs virtuels dynamiques simples</title>
<p>Cet extrait du fichier <code>httpd.conf</code> impl�mente
la disposition des serveurs virtuels d�cris succinctement dans
la section <a href="#motivation">Aper�u</a> ci-dessus, mais
de fa�on g�n�rique en utilisant <code>mod_vhost_alias</code>.</p>
<example>
# r�cup�re le nom du serveur depuis l'en-t�te Host:<br />
UseCanonicalName Off<br />
<br />
# ce format de journal peut �tre d�coup� pour chaque serveur virtuel<br />
# gr�ce au premier champ<br />
LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon<br />
CustomLog logs/access_log vcommon<br />
<br />
# inclut le nom du serveur dans les adresses de fichiers<br />
# pour satisfaire les requ�tes<br />
VirtualDocumentRoot /www/hosts/%0/docs<br />
VirtualScriptAlias /www/hosts/%0/cgi-bin
</example>
<p>Cette configuration peut �tre modifi�e en un h�bergement
virtuel par IP simplement en changeant <code>UseCanonicalName Off</code>
en <code>UseCanonicalName DNS</code>. Le nom du serveur qui sera
inclut dans les adresses de fichiers d�coulera de l'adresse IP
du serveur virtuel.</p>
</section>
<section id="homepages"><title>Un syst�me de pages personnelles
h�berg�es virtuellement</title>
<p>Il s'agit d'un ajustement du syst�me d�cris ci-dessus d�di�
pour un serveur de pages personnelles chez un fournisseur d'acc�s.
En utilisant une configuration l�g�rement plus compliqu�e, nous
pouvons capturer une partie du nom du serveur pour nos adresses
de fichiers ; par exemple, les documents <code>www.user.isp.com</code>
seraient situ�s dans <code>/home/user/</code>. Un unique r�pertoire
<code>cgi-bin</code> est n�cessaire au lieu d'un par serveur virtuel.</p>
<example>
# la configuration pr�liminaire est la m�me que ci-dessus<br />
<br />
# inclut une partie du nom du serveur dans les adresses de fichiers<br />
VirtualDocumentRoot /www/hosts/%2/docs<br />
<br />
# unique r�pertoire cgi-bin<br />
ScriptAlias /cgi-bin/ /www/std-cgi/<br />
</example>
<p>Vous trouverez des exemples de configurations plus sophistiqu�es
avec <code>VirtualDocumentRoot</code> dans la documentation de
<module>mod_vhost_alias</module>.</p>
</section>
<section id="combinations"><title>Utilisation de plus d'un syst�me
d'h�bergement virtuel sur un m�me serveur</title>
<p>Avec une configuration encore plus compliqu�e, les directives
habituelles d'Apache <code><VirtualHost></code> vous
permettent le contr�le de diff�rentes configurations d'h�bergement
virtuel. Selon l'exemple suivant, vous pouvez avoir une adresse IP
pour les pages personnelles de vos clients et une autre pour les
usages commerciaux. Il suffit de combiner des sections
conventionnelles <code><VirtualHost></code>.</p>
<example>
UseCanonicalName Off<br />
<br />
LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon<br />
<br />
<Directory /www/commercial><br />
<indent>
Options FollowSymLinks<br />
AllowOverride All<br />
</indent>
</Directory><br />
<br />
<Directory /www/homepages><br />
<indent>
Options FollowSymLinks<br />
AllowOverride None<br />
</indent>
</Directory><br />
<br />
<VirtualHost 111.22.33.44><br />
<indent>
ServerName www.commercial.isp.com<br />
<br />
CustomLog logs/access_log.commercial vcommon<br />
<br />
VirtualDocumentRoot /www/commercial/%0/docs<br />
VirtualScriptAlias /www/commercial/%0/cgi-bin<br />
</indent>
</VirtualHost><br />
<br />
<VirtualHost 111.22.33.45><br />
<indent>
ServerName www.homepages.isp.com<br />
<br />
CustomLog logs/access_log.homepages vcommon<br />
<br />
VirtualDocumentRoot /www/homepages/%0/docs<br />
ScriptAlias /cgi-bin/ /www/std-cgi/<br />
</indent>
</VirtualHost>
</example>
</section>
<section id="ipbased"><title>Plus d'efficacit� avec l'h�bergement
virtuel par IP</title>
<p>Apr�s <a href="#simple">le premier exemple</a> pr�sent�, vous
noterez qu'il est facile de modifier la configuration pour un
h�bergement virtuel par IP. Malheureusement, cette configuration
n'est pas tr�s efficace car elle n�cessite une r�solution DNS
lors de chaque requ�te. Pour l'�viter, il faut pouvoir attribuer
aux adresses de fichiers, les IP elles m�mes au lieu des noms de
serveurs correspondant, ainsi que pour les enregistrements dans
les journaux. Apache n'a habituellement pas besoin de travailler
avec le nom d'un serveur et ainsi subir une r�solution DNS.</p>
<example>
# r�cup�re le nom du serveur � partir d'une r�solution inverse DNS <br />
# de l'adresse IP<br />
UseCanonicalName DNS<br />
<br />
# inclut l'adresse IP aux journaux qui pourront ainsi �tre <br />
# red�coup�s ult�rieurement<br />
LogFormat "%A %h %l %u %t \"%r\" %s %b" vcommon<br />
CustomLog logs/access_log vcommon<br />
<br />
# inclut l'adresse IP aux noms de fichiers<br />
VirtualDocumentRootIP /www/hosts/%0/docs<br />
VirtualScriptAliasIP /www/hosts/%0/cgi-bin<br />
</example>
</section>
<section id="oldversion"><title>Utilisation d'anciennes versions d'Apache</title>
<p>Les exemples pr�sent�s ci-dessus reposent sur l'emploi du
module <code>mod_vhost_alias</code> qui est apparu apr�s la
version 1.3.6. Si vous disposez d'une version d'Apache sans ce
module <code>mod_vhost_alias</code>, vous pouvez appliquer
cette technique par le biais du module <code>mod_rewrite</code>
comme illustr� ci-apr�s, mais seulement pour les h�bergements
virtuels bas�s sur les en-t�tes Host:.</p>
<p>En compl�ment, vous devrez faire attention aux enregistrements
journaux. Apache 1.3.6 f�t la premi�re version � inclure
l'option de format de journal <code>%V</code> ; dans les
versions 1.3.0 - 1.3.3, il s'agissait de l'option <code>%v</code> ;
et elle reste sans �quivalent pour la version 1.3.4. Dans
tous ces versions d'Apache, un utilisateur pouvait fort bien
fausser les enregistrements journaux par l'ajout d'une directive
<code>UseCanonicalName</code> dans ses fichiers <code>.htaccess</code>.
Donc, la meilleure pratique est d'utiliser l'option
<code>%{Host}i</code> qui ajoute directement dans les journaux
l'en-t�te <code>Host:</code> ; Notez que dans ce cas, le
<code>:port</code> sera ajout� � la fin, ce qui n'est pas le
cas avec <code>%V</code>.</p>
</section>
<section id="simple.rewrite"><title>Utilisation de <code>mod_rewrite</code>
pour un simple h�bergement virtuel dynamique</title>
<p>Cet extrait du fichier de configuration <code>httpd.conf</code>
r�alise la m�me chose qu'avec <a href="#simple">le premier exemple</a>.
La premi�re moiti� est tr�s similaire, mais avec quelques
ajustements pour une compatibilit� descendante et pour pr�parer
la partie avec <code>mod_rewrite</code> ; la seconde moiti�
configure <code>mod_rewrite</code> pour notre t�che.</p>
<p>Il y a quelques trucs � conna�tre : par d�faut,
<code>mod_rewrite</code> s'ex�cute avant d'autres modules de
traduction d'URI (<code>mod_alias</code>, etc.), donc vous
devez en tenir compte si vous utilisez ces autres modules en
configurant <code>mod_rewrite</code> en cons�quence. Il vous
faudra �tre dou� pour faire un h�bergement virtuel dynamique
�quivalent � un <code>ScriptAlias</code>.</p>
<example>
# r�cup�re le nom du serveur depuis l'en-t�te Host:<br />
UseCanonicalName Off<br />
<br />
# Journaux divisibles<br />
LogFormat "%{Host}i %h %l %u %t \"%r\" %s %b" vcommon<br />
CustomLog logs/access_log vcommon<br />
<br />
<Directory /www/hosts><br />
<indent>
# ExecCGI est n�cessaire, car nous ne pouvons pas forcer <br />
# l'ex�cution d'un script CGI comme le ferait un ScriptAlias<br />
Options FollowSymLinks ExecCGI<br />
</indent>
</Directory><br />
<br />
# maintenant la partie difficile<br />
<br />
RewriteEngine On<br />
<br />
# Un ServerName qui d�coule de l'en-t�te Host: doit �tre correctement format�<br />
RewriteMap lowercase int:tolower<br />
<br />
## traite d'abord les documents normaux :<br />
# permet � l'alias /icons/ de fonctionner - � r�p�ter avec les autres alias<br />
RewriteCond %{REQUEST_URI} !^/icons/<br />
# permet aux scripts CGI de fonctionner<br />
RewriteCond %{REQUEST_URI} !^/cgi-bin/<br />
# et la magie...<br />
RewriteRule ^/(.*)$ /www/hosts/${lowercase:%{SERVER_NAME}}/docs/$1<br />
<br />
## et maintenant, traitons les CGIs - nous devons forcer le type MIME<br />
RewriteCond %{REQUEST_URI} ^/cgi-bin/<br />
RewriteRule ^/(.*)$ /www/hosts/${lowercase:%{SERVER_NAME}}/cgi-bin/$1 [T=application/x-httpd-cgi]<br />
<br />
# c'est tout !
</example>
</section>
<section id="homepages.rewrite"><title>Un syst�me de pages personnelles
utilisant <code>mod_rewrite</code></title>
<p>Le fonctionnement est identique � <a href="#homepages">notre
second exemple</a>.</p>
<example>
RewriteEngine on<br />
<br />
RewriteMap lowercase int:tolower<br />
<br />
# permet aux scripts CGI de fonctionner<br />
RewriteCond %{REQUEST_URI} !^/cgi-bin/<br />
<br />
# teste si le nom de domaine est compatible avec notre RewriteRule<br />
RewriteCond ${lowercase:%{SERVER_NAME}} ^www\.[a-z-]+\.isp\.com$<br />
<br />
# ajoute le nom du serveur virtuel au d�but de l'URI<br />
# le [C] signifie que le prochain rewrite utilisera le r�sultat de celui-ci<br />
RewriteRule ^(.+) ${lowercase:%{SERVER_NAME}}$1 [C]<br />
<br />
# maintenant cr�ons le v�ritable nom du fichier<br />
RewriteRule ^www\.([a-z-]+)\.isp\.com/(.*) /home/$1/$2<br />
<br />
# d�finit le r�pertoire global CGI<br />
ScriptAlias /cgi-bin/ /www/std-cgi/
</example>
</section>
<section id="xtra-conf"><title>Utilisation d'un fichier de configuration
s�par� pour les serveurs virtuels</title>
<p>Ce mode utilise des fonctionnalit�s avanc�es de
<code>mod_rewrite</code> pour r�cup�rer la traduction d'une
adresse vers la racine d'un document � partir d'un fichier
de configuration s�par�. Il permet plus de souplesse mais
requiert une configuration plus compliqu�e.</p>
<p>Le fichier <code>vhost.map</code> contient quelque chose
comme ceci :</p>
<example>
www.customer-1.com /www/customers/1<br />
www.customer-2.com /www/customers/2<br />
# ...<br />
www.customer-N.com /www/customers/N<br />
</example>
<p>Le fichier <code>http.conf</code> contient cela :</p>
<example>
RewriteEngine on<br />
<br />
RewriteMap lowercase int:tolower<br />
<br />
# d�finit le fichier map<br />
RewriteMap vhost txt:/www/conf/vhost.map<br />
<br />
# traite les alias comme ci-dessus<br />
RewriteCond %{REQUEST_URI} !^/icons/<br />
RewriteCond %{REQUEST_URI} !^/cgi-bin/<br />
RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$<br />
# ceci renomme les fichier selon le fichier map<br />
RewriteCond ${vhost:%1} ^(/.*)$<br />
RewriteRule ^/(.*)$ %1/docs/$1<br />
<br />
RewriteCond %{REQUEST_URI} ^/cgi-bin/<br />
RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$<br />
RewriteCond ${vhost:%1} ^(/.*)$<br />
RewriteRule ^/(.*)$ %1/cgi-bin/$1
</example>
</section>
</manualpage>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
