Date: Wed, 29 Jun 2005 08:54:09 +0000 (+0000) Subject: Submitted and reviewed by Vincent Deffontaines, alain B and Jean-François El Fouly. X-Git-Tag: 2.1.7~64 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f50493c17cb8869aae1bfb9bdd069663b60af18a;p=thirdparty%2Fapache%2Fhttpd.git Submitted and reviewed by Vincent Deffontaines, alain B and Jean-François El Fouly. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@202339 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/vhosts/details.html.fr b/docs/manual/vhosts/details.html.fr new file mode 100644 index 00000000000..c794ac3469e --- /dev/null +++ b/docs/manual/vhosts/details.html.fr @@ -0,0 +1,459 @@ + + + +Détails sur le fonctionnement des serveurs virtuels - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.1 > Serveurs virtuels

Détails sur le fonctionnement des serveurs virtuels

Langues Disponibles: en | + fr | + ko

Cette traduction peut être périmée. Verifiez la version + Anglaise pour les changements récents.

+ + +

Le code gérant les serveurs virtuels a été réécrit à partir de + zéro dans Apache 1.3. 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 NameVirtualHost + a rendu beaucoup plus facile et plus sûre la configuration des + serveurs virtuels par rapport aux versions précédant la 1.3.

+ +

Si vous voulez juste que ça marche sans en + comprendre le fonctionnement, voici quelques + exemples.

+ +

Interprétation des fichiers +de configuration
Choix du serveur virtuel
Trucs et astuces

Interprétation des fichiers +de configuration

+ +

Un serveur principal (main_server) contient toutes + les définitions qui apparaissent en dehors des sections + <VirtualHost>. Les serveurs virtuels, aussi + appelés vhosts (pour virtual hosts), sont définis par les + sections <VirtualHost>.

+ +

Les directives + Listen, + ServerName, + ServerPath, + et ServerAlias + 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).

+ +

La valeur par défaut du champ Listen pour le serveur + principal est de 80. Le serveur principal n'a pas de valeur par + défaut pour ServerPath ni pour ServerAlias. + La valeur par défaut de ServerName est déduite à partir + de l'adresses IP du serveur.

+ +

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.

+ +

À la différence du serveur principal, les ports des serveurs + virtuels n'affectent pas les ports sur lesquels + Apache se met à l'écoute.

+ +

Chaque adresse incluse dans une directive VirtualHost + peut disposer d'un port optionnel. Si le port n'est pas précisé, il + prend par défaut la dernière valeur de Listen lue dans + la configuration du serveur principal. Le port particulier + * représente un joker qui correspond à tous les ports. + L'ensemble des adresses (y compris les résultats multiples + A issus des requêtes DNS) est appelé jeu + d'adresses du serveur virtuel.

+ +

À moins qu'une directive + NameVirtualHost ne soit utilisée + pour une adresse IP spécifique, le premier serveur virtuel avec + cette adresse est considéré comme un serveur virtuel par-IP. + L'adresse IP peut également prendre la valeur joker *.

+ +

Dans les cas où l'on souhaite utiliser un serveur virtuel + par nom, la directive NameVirtualHost doit + 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 NameVirtualHost.

+ +

On peut utiliser plusieurs directives NameVirtualHost + pour un groupe de directives VirtualHost, mais seule + une directive NameVirtualHost doit être utilisée pour + chaque couple IP:port donné.

+ +

L'ordre d'apparition des directives NameVirtualHost + et VirtualHost est sans importance, ce qui fait que + les deux exemples suivants ont des effets identiques (seul l'ordre + des directives VirtualHost pour un jeu + d'adresses est important, voir ci-dessous) :

+ + + + +

+ NameVirtualHost 111.22.33.44 + <VirtualHost 111.22.33.44> + # serveur A + ... + </VirtualHost> + <VirtualHost 111.22.33.44> + # serveur B + ... + </VirtualHost> + + NameVirtualHost 111.22.33.55 + <VirtualHost 111.22.33.55> + # serveur C + ... + </VirtualHost> + <VirtualHost 111.22.33.55> + # serveur D + ... + </VirtualHost> +

+ <VirtualHost 111.22.33.44> + # serveur A + </VirtualHost> + <VirtualHost 111.22.33.55> + # serveur C + ... + </VirtualHost> + <VirtualHost 111.22.33.44> + # serveur B + ... + </VirtualHost> + <VirtualHost 111.22.33.55> + # serveur D + ... + </VirtualHost> + + NameVirtualHost 111.22.33.44 + NameVirtualHost 111.22.33.55 + +

+ + +

(Il est conseillé d'adopter le choix de gauche pour faciliter + la lisibilité des fichiers de configuration.)

+ +

Après la lecture de la directive VirtualHost, le + serveur virtuel se voit attribuer une valeur Listen + par défaut qui est la valeur du port associé au premier nom spécifié + dans sa directive VirtualHost.

+ +

La liste complète des noms d'une directive VirtualHost + est gérée exactement comme des ServerAlias (mais ne + sont pas écrasés par d'autres ServerAlias) si tous + les noms sont résolus dans ce jeu d'adresse. À noter que les états + Listen de ce serveur virtuel sont sans incidence sur + les ports attibués au jeu d'adresses.

+ +

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 NameVirtualHost, + cette liste contient les noms des serveurs virtuels pour cette + adresse. Si aucun serveur virtuel n'est défini pour cette adresse, + la directive NameVirtualHost 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.

+ +

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.

+ +

Pour chaque serveur virtuel, diverses valeurs sont initialisées + par défaut. En particulier :

+ +

Dans le cas où un serveur virtuel ne contient pas de directives + ServerAdmin, + ResourceConfig, + AccessConfig, + Timeout, + KeepAliveTimeout, + KeepAlive, + MaxKeepAliveRequests, + ou SendBufferSize, + 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.)
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.
Les configurations par serveur pour chaque module sont assemblées + à partir de celles du serveur principal.

+ +

L'essentiel des valeurs de configuration des serveurs virtuels + provient de valeurs par défaut issues du serveur principal. + Mais la position dans le fichier de configuration des directives + du serveur principal n'a pas d'importance -- 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 definition du serveur virtuel.

+ +

Dans le cas où le serveur principal n'a pas de ServerName + à ce stade, le nom de la machine sur laquelle tourne le programme + httpd est utilisé à sa place. Nous appellerons + jeu d'adresses du serveur principal, les adresses IP + renvoyées par une résolution DNS sur le ServerName + du serveur principal.

+ +

Pour tous les champs ServerName 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 + VirtualHost qui définit le serveur virtuel.

+ +

Si un serveur virtuel contient la valeur magique + _default_, il fonctionne sur le même ServerName + que le serveur principal.

+ +

Choix du serveur virtuel

+ +

À la réception d'une requête, le serveur procède comme suit pour + déterminer quel serveur virtuel utiliser :

+ +

Vérification dans la table de hash

+ +

Après que le client se soit connecté, l'adresse + IP à laquelle le client s'est connecté est recherchée dans la + table de hash IP interne.

+ +

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 + _default_ s'il est défini pour le port correspondant + à la requête. Sinon, elle est servie par le serveur principal.

+ +

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 NameVirtualHost * qui est géré + ensuite comme les autres serveur virtuels par noms.

+ +

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.

+ + + +

Serveur virtuel par IP

+ +

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.

+ + + +

Serveur virtuel par nom

+ +

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 VirtualHost + dans le fichier de configuration.

+ +

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 + Host: dans l'en-tête.

+ +

Si un champ Host: 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 ServerName + ou un ServerAlias correspondant est choisi pour + servir la requête. Il est possible que le champ Host: + contienne un numéro de port, mais Apache utilise toujours le + port sur lequel il a effectivement reçu la requête.

+ +

Dans le cas où le client a envoyé une requête en HTTP/1.0 sans + un champ d'en-tête Host:, 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 ServerPath + existants. Le premier chemin trouvé est utilisé et la requête est + servie par le serveur virtuel correspondant.

+ +

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).

+ + + +

Connexions persistantes

+ +

La recherche par adresse IP décrite ci-avant n'est faite + qu'une fois pour chaque session TCP/IP, alors que la + recherche par nom est réalisée pour chaque 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.

+ + + +

URI absolu

+ +

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), et 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 (proxy).

+ + +

Observations

+ +

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 + NameVirtualHost.
Les vérifications sur ServerAlias et + ServerPath ne sont jamais réalisées pour les + serveurs virtuels par IP.
L'ordre dans lequel sont agencés dans le fichier de + configuration le serveur virtuel _default_, les + serveurs virtuels par nom et par IP, et la directive + NameVirtualHost 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.
Pour des raisons de sécurité, le numéro de port présenté + dans le champ d'en-tête Host: 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.
Si une directive ServerPath existe, et se + trouve être préfixe d'une autre directive ServerPath + 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 Host: + n'a été présenté par le client pour distinguer les deux.)
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.
Le serveur virtuel _default_ ne sert la requête + que si aucun autre serveur virtuel travaillant sur l'adresse + IP et 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 _default_ (qui par + défaut, correspond à Listen). Un port joker peut + être spécifié (comme dans _default_:*) + pour récupérer les requêtes sur tous les ports ouverts. Ceci + est également applicable aux serveurs virtuels + NameVirtualHost *.
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 _default_). 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 _default_ + correspond au port).
Ni les serveurs virtuels _default_, ni le + serveur principal ne sont utilisés pour traiter une requête + avec un champ d'en-tête Host: manquant ou vide + lorsque l'adresse (et le port) de connexion correspondent à + des serveurs virtuels par nom, par exemple, dans une directive + NameVirtualHost.
Il ne faut jamais employer de noms DNS dans des directives + VirtualHost, 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 + disponible ici, ainsi que + les deux points précisés ci-après.
Un nom de serveur ServerName devrait toujours + être indiqué pour chaque serveur virtuel. Sans cela, une + résolution DNS est nécessaire pour chaque serveur virtuel.

+ + +

Trucs et astuces

+ +

En plus des points évoqués sur la page des + problèmes liés au DNS, + voici quelques points intéressants :

+ +

Toujours positionner les définitions relatives au serveur + principal avant toute définition VirtualHost. + (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.)
Toujours regrouper les définitions NameVirtualHost + et VirtualHost dans la configuration pour une + meilleure lisibilité.
Éviter les ServerPaths qui sont préfixes + d'autres ServerPaths. 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. (par exemple, + "ServerPath /abc" est à spécifier après "ServerPath /abc/def").

+ +

Langues Disponibles: en | + fr | + ko

+ \ No newline at end of file diff --git a/docs/manual/vhosts/details.xml.fr b/docs/manual/vhosts/details.xml.fr new file mode 100644 index 00000000000..21b19909892 --- /dev/null +++ b/docs/manual/vhosts/details.xml.fr @@ -0,0 +1,448 @@ + + + + + + + + + +Serveurs virtuels + Détails sur le fonctionnement des serveurs virtuels + +

+ +

Le code gérant les serveurs virtuels a été réécrit à partir de + zéro dans Apache 1.3. 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 NameVirtualHost + a rendu beaucoup plus facile et plus sûre la configuration des + serveurs virtuels par rapport aux versions précédant la 1.3.

+ +

Si vous voulez juste que ça marche sans en + comprendre le fonctionnement, voici quelques + exemples.

+ +

Interprétation des fichiers +de configuration + +

+ +

Les directives + Listen, + ServerName, + ServerPath, + et ServerAlias + 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).

+ +

À la différence du serveur principal, les ports des serveurs + virtuels n'affectent pas les ports sur lesquels + Apache se met à l'écoute.

+ +

À moins qu'une directive + NameVirtualHost ne soit utilisée + pour une adresse IP spécifique, le premier serveur virtuel avec + cette adresse est considéré comme un serveur virtuel par-IP. + L'adresse IP peut également prendre la valeur joker *.

+ +

+ + + + +

+ NameVirtualHost 111.22.33.44
+ <VirtualHost 111.22.33.44>
+ # serveur A
+ ...
+ </VirtualHost>
+ <VirtualHost 111.22.33.44>
+ # serveur B
+ ...
+ </VirtualHost>
+
+ NameVirtualHost 111.22.33.55
+ <VirtualHost 111.22.33.55>
+ # serveur C
+ ...
+ </VirtualHost>
+ <VirtualHost 111.22.33.55>
+ # serveur D
+ ...
+ </VirtualHost> +

+ <VirtualHost 111.22.33.44>
+ # serveur A
+ </VirtualHost>
+ <VirtualHost 111.22.33.55>
+ # serveur C
+ ...
+ </VirtualHost>
+ <VirtualHost 111.22.33.44>
+ # serveur B
+ ...
+ </VirtualHost>
+ <VirtualHost 111.22.33.55>
+ # serveur D
+ ...
+ </VirtualHost>
+
+ NameVirtualHost 111.22.33.44
+ NameVirtualHost 111.22.33.55
+
+

+ + +

(Il est conseillé d'adopter le choix de gauche pour faciliter + la lisibilité des fichiers de configuration.)

+ +

Pour chaque serveur virtuel, diverses valeurs sont initialisées + par défaut. En particulier :

+ +

Dans le cas où un serveur virtuel ne contient pas de directives + ServerAdmin, + ResourceConfig, + AccessConfig, + Timeout, + KeepAliveTimeout, + KeepAlive, + MaxKeepAliveRequests, + ou SendBufferSize, + 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.)
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.
Les configurations par serveur pour chaque module sont assemblées + à partir de celles du serveur principal.

+ +

Dans le cas où le serveur principal n'a pas de ServerName + à ce stade, le nom de la machine sur laquelle tourne le programme + httpd est utilisé à sa place. Nous appellerons + jeu d'adresses du serveur principal, les adresses IP + renvoyées par une résolution DNS sur le ServerName + du serveur principal.

+ +

Si un serveur virtuel contient la valeur magique + _default_, il fonctionne sur le même ServerName + que le serveur principal.

+ +

Choix du serveur virtuel + +

À la réception d'une requête, le serveur procède comme suit pour + déterminer quel serveur virtuel utiliser :

+ +

Vérification dans la table de hash + +

Après que le client se soit connecté, l'adresse + IP à laquelle le client s'est connecté est recherchée dans la + table de hash IP interne.

+ +

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.

+ +

Serveur virtuel par IP + +

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.

+ +

Serveur virtuel par nom + +

+ +

Connexions persistantes + +

+ +

URI absolu + +

+ +

Observations + +

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 + NameVirtualHost.
Les vérifications sur ServerAlias et + ServerPath ne sont jamais réalisées pour les + serveurs virtuels par IP.
L'ordre dans lequel sont agencés dans le fichier de + configuration le serveur virtuel _default_, les + serveurs virtuels par nom et par IP, et la directive + NameVirtualHost 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.
Pour des raisons de sécurité, le numéro de port présenté + dans le champ d'en-tête Host: 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.
Si une directive ServerPath existe, et se + trouve être préfixe d'une autre directive ServerPath + 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 Host: + n'a été présenté par le client pour distinguer les deux.)
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.
Le serveur virtuel _default_ ne sert la requête + que si aucun autre serveur virtuel travaillant sur l'adresse + IP et 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 _default_ (qui par + défaut, correspond à Listen). Un port joker peut + être spécifié (comme dans _default_:*) + pour récupérer les requêtes sur tous les ports ouverts. Ceci + est également applicable aux serveurs virtuels + NameVirtualHost *.
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 _default_). 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 _default_ + correspond au port).
Ni les serveurs virtuels _default_, ni le + serveur principal ne sont utilisés pour traiter une requête + avec un champ d'en-tête Host: manquant ou vide + lorsque l'adresse (et le port) de connexion correspondent à + des serveurs virtuels par nom, par exemple, dans une directive + NameVirtualHost.
Il ne faut jamais employer de noms DNS dans des directives + VirtualHost, 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 + disponible ici, ainsi que + les deux points précisés ci-après.
Un nom de serveur ServerName devrait toujours + être indiqué pour chaque serveur virtuel. Sans cela, une + résolution DNS est nécessaire pour chaque serveur virtuel.

+ +

Trucs et astuces + +

En plus des points évoqués sur la page des + problèmes liés au DNS, + voici quelques points intéressants :

+ +

Toujours positionner les définitions relatives au serveur + principal avant toute définition VirtualHost. + (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.)
Toujours regrouper les définitions NameVirtualHost + et VirtualHost dans la configuration pour une + meilleure lisibilité.
Éviter les ServerPaths qui sont préfixes + d'autres ServerPaths. 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. (par exemple, + "ServerPath /abc" est à spécifier après "ServerPath /abc/def").

+ +

+ + diff --git a/docs/manual/vhosts/examples.html.fr b/docs/manual/vhosts/examples.html.fr new file mode 100644 index 00000000000..daf518a05d6 --- /dev/null +++ b/docs/manual/vhosts/examples.html.fr @@ -0,0 +1,681 @@ + + + +Exemples d'utilisations de VirtualHost - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.1 > Serveurs virtuels

Exemples d'utilisations de VirtualHost

Langues Disponibles: en | + fr | + ja | + ko

Cette traduction peut être périmée. Verifiez la version + Anglaise pour les changements récents.

+ + +

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.

+ +

Fonctionnement de plusieurs serveurs + virtuels par nom sur une seule adresse IP.
Serveurs virtuels par nom sur plus + d'une seule adresse IP.
Servir le même contenu sur des + adresses IP différentes (telle qu'une adresse interne et une + externe).
Servir différents sites sur différents + ports.
Hébergement virtuel basé sur IP
Hébergements virtuels mixtes basés sur + les ports et sur les IP
Hébergements virtuels mixtes basé sur + les noms et sur IP
Utilisation simultanée de + Virtual_host et de mod_proxy
Utilisation de serveurs virtuels + _default_
Migration d'un serveur virtuel + par nom en un serveur virtuel par IP
Utilisation de la directive + ServerPath

Fonctionnement de plusieurs serveurs + virtuels par nom sur une seule adresse IP.

+ +

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.example1.com et + www.example2.org doivent tourner sur cette machine.

+ +

Note :

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.

+ +

Configuration du serveur

+ + + # Apache doit écouter sur le port 80 + Listen 80 + + # Toutes les adresses IP doivent répondre aux requêtes sur les + # serveurs virtuels + NameVirtualHost *:80 + + <VirtualHost *:80> + + DocumentRoot /www/example1 + ServerName www.example1.com + + # Autres directives ici + + + </VirtualHost> + + <VirtualHost *:80> + + DocumentRoot /www/example2 + ServerName www.example2.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 + www.example1.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 pas à une + des directives ServerName sera servie par ce premier + VirtualHost.

+ +

Note :

+ +

Si vous le souhaitez, vous pouvez remplacer * + par l'adresse IP du système. Dans ce cas, l'argument de + VirtualHost doit correspondre à + l'argument de NameVirtualHost :

+ +

+ NameVirtualHost 172.20.30.40 + + <VirtualHost 172.20.30.40> + # etc ... +

+ +

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.

+ +

Serveurs virtuels par nom sur plus + d'une seule adresse IP.

+ +

Note :

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.domain.com doit répondre, et sur l'autre + (172.20.30.50), deux serveurs virtuels (ou plus) + répondront.

+ +

Configuration du serveur

+ + + Listen 80 + + # Serveur "principal" sur 172.20.30.40 + ServerName server.domain.com + DocumentRoot /www/mainserver + + # l'autre adresse + NameVirtualHost 172.20.30.50 + + <VirtualHost 172.20.30.50> + + DocumentRoot /www/example1 + ServerName www.example1.com + + # D'autres directives ici ... + + + </VirtualHost> + + <VirtualHost 172.20.30.50> + + DocumentRoot /www/example2 + ServerName www.example2.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.example1.com.

+ +

Servir le même contenu sur des + adresses IP différentes (telle qu'une adresse interne et une + externe).

+ +

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.

+ +

Configuration du serveur

+ + + NameVirtualHost 192.168.1.1 + NameVirtualHost 172.20.30.40 + + <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.

+ +

Note :

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.

+ +

Servir différents sites sur différents + ports.

+ +

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.

+ +

Configuration du serveur

+ + + Listen 80 + Listen 8080 + + NameVirtualHost 172.20.30.40:80 + NameVirtualHost 172.20.30.40:8080 + + <VirtualHost 172.20.30.40:80> + + ServerName www.example1.com + DocumentRoot /www/domain-80 + + </VirtualHost> + + <VirtualHost 172.20.30.40:8080> + + ServerName www.example1.com + DocumentRoot /www/domain-8080 + + </VirtualHost> + + <VirtualHost 172.20.30.40:80> + + ServerName www.example2.org + DocumentRoot /www/otherdomain-80 + + </VirtualHost> + + <VirtualHost 172.20.30.40:8080> + + ServerName www.example2.org + DocumentRoot /www/otherdomain-8080 + + </VirtualHost> +

+ +

Hébergement virtuel basé sur IP

+ +

Le serveur dispose de deux adresses IP (172.20.30.40 + et 172.20.30.50) correspondant respectivement aux noms + www.example1.com et www.example2.org.

+ +

Configuration du serveur

+ + + Listen 80 + + <VirtualHost 172.20.30.40> + + DocumentRoot /www/example1 + ServerName www.example1.com + + </VirtualHost> + + <VirtualHost 172.20.30.50> + + DocumentRoot /www/example2 + ServerName www.example2.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.

+ +

Hébergements virtuels mixtes basés sur + les ports et sur les IP

+ +

Le serveur dispose de deux adresses IP (172.20.30.40 + et 172.20.30.50) correspondant respectivement aux noms + www.example1.com et www.example2.org. + Pour chacun d'eux, nous voulons un hébergement sur les ports 80 + et 8080.

+ +

Configuration du serveur

+ + + 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.example1.com + + </VirtualHost> + + <VirtualHost 172.20.30.40:8080> + + DocumentRoot /www/example1-8080 + ServerName www.example1.com + + </VirtualHost> + + <VirtualHost 172.20.30.50:80> + + DocumentRoot /www/example2-80 + ServerName www.example1.org + + </VirtualHost> + + <VirtualHost 172.20.30.50:8080> + + DocumentRoot /www/example2-8080 + ServerName www.example2.org + + </VirtualHost> +

+ +

Hébergements virtuels mixtes basé sur + les noms et sur IP

+ +

Pour certaines adresses, des serveurs virtuels seront définis + par nom, et pour d'autres, ils seront définis par IP.

+ +

Configuration du serveur

+ + + Listen 80 + + NameVirtualHost 172.20.30.40 + + <VirtualHost 172.20.30.40> + + DocumentRoot /www/example1 + ServerName www.example1.com + + </VirtualHost> + + <VirtualHost 172.20.30.40> + + DocumentRoot /www/example2 + ServerName www.example2.org + + </VirtualHost> + + <VirtualHost 172.20.30.40> + + DocumentRoot /www/example3 + ServerName www.example3.net + + </VirtualHost> + + # "par-IP" + <VirtualHost 172.20.30.50> + + DocumentRoot /www/example4 + ServerName www.example4.edu + + </VirtualHost> + + <VirtualHost 172.20.30.60> + + DocumentRoot /www/example5 + ServerName www.example5.gov + + </VirtualHost> +

+ +

Utilisation simultanée de + `Virtual_host` et de mod_proxy

+ +

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 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> +

+ +

Utilisation de serveurs virtuels + `_default_`

+ +

Serveurs virtuels + `_default_` pour tous les ports

+ +

Exemple 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.

+ +

Configuration du serveur

+ + + <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).

+ + +

Serveurs virtuels + `_default_` pour des ports différents

+ +

La 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é.

+ +

Configuration du serveur

+ + + <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.

+ + +

Serveurs virtuels + `_default_` pour un seul port

+ +

Nous voulons créer un serveur virtuel par défaut seulement + pour le port 80.

+ +

Configuration du serveur

+ + + <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.

+ + +

Migration d'un serveur virtuel + par nom en un serveur virtuel par IP

+ +

Le serveur virtuel par nom avec le nom de domaine + www.example2.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.

+ +

Configuration du serveur

+ + + Listen 80 + ServerName www.example1.com + DocumentRoot /www/example1 + + NameVirtualHost 172.20.30.40 + + <VirtualHost 172.20.30.40 172.20.30.50> + + DocumentRoot /www/example2 + ServerName www.example2.org + # ... + + </VirtualHost> + + <VirtualHost 172.20.30.40> + + DocumentRoot /www/example3 + ServerName www.example3.net + ServerAlias *.example3.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).

+ +

Utilisation de la directive + `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.

+ +

Configuration du serveur

+ + + NameVirtualHost 172.20.30.40 + + <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.

+ +

Langues Disponibles: en | + fr | + ja | + ko

+ \ No newline at end of file diff --git a/docs/manual/vhosts/examples.xml.fr b/docs/manual/vhosts/examples.xml.fr new file mode 100644 index 00000000000..09d46001359 --- /dev/null +++ b/docs/manual/vhosts/examples.xml.fr @@ -0,0 +1,650 @@ + + + + + + + + + +Serveurs virtuels + Exemples d'utilisations de VirtualHost + +

+ +

Fonctionnement de plusieurs serveurs + virtuels par nom sur une seule adresse IP. + +

+ + Note :

+ + + + Configuration du serveur + + # Apache doit écouter sur le port 80
+ Listen 80
+
+ # Toutes les adresses IP doivent répondre aux requêtes sur les + # serveurs virtuels + NameVirtualHost *:80
+
+ <VirtualHost *:80>
+ + DocumentRoot /www/example1
+ ServerName www.example1.com
+
+ # Autres directives ici
+
+ + </VirtualHost>
+
+ <VirtualHost *:80>
+ + DocumentRoot /www/example2
+ ServerName www.example2.org
+
+ # Autres directives ici
+
+ + </VirtualHost> + + +

+ + + Note : + +

Si vous le souhaitez, vous pouvez remplacer * + par l'adresse IP du système. Dans ce cas, l'argument de + VirtualHost doit correspondre à + l'argument de NameVirtualHost :

+ + + NameVirtualHost 172.20.30.40
+
+ <VirtualHost 172.20.30.40>
+ # etc ... + + +

+ + +

+ +

Serveurs virtuels par nom sur plus + d'une seule adresse IP. + + + Note :

Toutes les techniques présentées ici + peuvent être étendues à un plus grand nombre d'adresses IP.

+ + +

+ + + Configuration du serveur + + Listen 80
+
+ # Serveur "principal" sur 172.20.30.40
+ ServerName server.domain.com
+ DocumentRoot /www/mainserver
+
+ # l'autre adresse
+ NameVirtualHost 172.20.30.50
+
+ <VirtualHost 172.20.30.50>
+ + DocumentRoot /www/example1
+ ServerName www.example1.com
+
+ # D'autres directives ici ...
+
+ + </VirtualHost>
+
+ <VirtualHost 172.20.30.50>
+ + DocumentRoot /www/example2
+ ServerName www.example2.org
+
+ # D'autres directives ici ...
+
+ + </VirtualHost> + + +

+ +

Servir le même contenu sur des + adresses IP différentes (telle qu'une adresse interne et une + externe). + +

+ +

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.

+ + + Configuration du serveur + + NameVirtualHost 192.168.1.1
+ NameVirtualHost 172.20.30.40
+
+ <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.

+ + + Note :

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.

+ + +

+ +

Servir différents sites sur différents + ports. + +

+ + + Configuration du serveur + + Listen 80
+ Listen 8080
+
+ NameVirtualHost 172.20.30.40:80
+ NameVirtualHost 172.20.30.40:8080
+
+ <VirtualHost 172.20.30.40:80>
+ + ServerName www.example1.com
+ DocumentRoot /www/domain-80
+ + </VirtualHost>
+
+ <VirtualHost 172.20.30.40:8080>
+ + ServerName www.example1.com
+ DocumentRoot /www/domain-8080
+ + </VirtualHost>
+
+ <VirtualHost 172.20.30.40:80>
+ + ServerName www.example2.org
+ DocumentRoot /www/otherdomain-80
+ + </VirtualHost>
+
+ <VirtualHost 172.20.30.40:8080>
+ + ServerName www.example2.org
+ DocumentRoot /www/otherdomain-8080
+ + </VirtualHost> + + +

+ +

Hébergement virtuel basé sur IP + +

Le serveur dispose de deux adresses IP (172.20.30.40 + et 172.20.30.50) correspondant respectivement aux noms + www.example1.com et www.example2.org.

+ + + Configuration du serveur + + Listen 80
+
+ <VirtualHost 172.20.30.40>
+ + DocumentRoot /www/example1
+ ServerName www.example1.com
+ + </VirtualHost>
+
+ <VirtualHost 172.20.30.50>
+ + DocumentRoot /www/example2
+ ServerName www.example2.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.

+ +

Hébergements virtuels mixtes basés sur + les ports et sur les IP + +

+ + + Configuration du serveur + + 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.example1.com
+ + </VirtualHost>
+
+ <VirtualHost 172.20.30.40:8080>
+ + DocumentRoot /www/example1-8080
+ ServerName www.example1.com
+ + </VirtualHost>
+
+ <VirtualHost 172.20.30.50:80>
+ + DocumentRoot /www/example2-80
+ ServerName www.example1.org
+ + </VirtualHost>
+
+ <VirtualHost 172.20.30.50:8080>
+ + DocumentRoot /www/example2-8080
+ ServerName www.example2.org
+ + </VirtualHost> + + +

+ +

Hébergements virtuels mixtes basé sur + les noms et sur IP + +

Pour certaines adresses, des serveurs virtuels seront définis + par nom, et pour d'autres, ils seront définis par IP.

+ + + Configuration du serveur + + Listen 80
+
+ NameVirtualHost 172.20.30.40
+
+ <VirtualHost 172.20.30.40>
+ + DocumentRoot /www/example1
+ ServerName www.example1.com
+ + </VirtualHost>
+
+ <VirtualHost 172.20.30.40>
+ + DocumentRoot /www/example2
+ ServerName www.example2.org
+ + </VirtualHost>
+
+ <VirtualHost 172.20.30.40>
+ + DocumentRoot /www/example3
+ ServerName www.example3.net
+ + </VirtualHost>
+
+ # "par-IP"
+ <VirtualHost 172.20.30.50>
+ + DocumentRoot /www/example4
+ ServerName www.example4.edu
+ + </VirtualHost>
+
+ <VirtualHost 172.20.30.60>
+ + DocumentRoot /www/example5
+ ServerName www.example5.gov
+ + </VirtualHost> + + +

+ +

Utilisation simultanée de + <code>Virtual_host</code> et de mod_proxy + +

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 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> + + +

+ +

Utilisation de serveurs virtuels + <code>_default_</code> + +

Serveurs virtuels + <code>_default_</code> pour tous les ports + +

Exemple 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.

+ + + Configuration du serveur + + <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.

+ +

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).

+ +

Serveurs virtuels + <code>_default_</code> pour des ports différents + +

La 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é.

+ + + Configuration du serveur + + <VirtualHost _default_:80>
+ + DocumentRoot /www/default80
+ # ...
+ + </VirtualHost>
+
+ <VirtualHost _default_:*>
+ + DocumentRoot /www/default
+ # ...
+ + </VirtualHost> + + +

+ +

Serveurs virtuels + <code>_default_</code> pour un seul port + +

Nous voulons créer un serveur virtuel par défaut seulement + pour le port 80.

+ + + Configuration du serveur + + <VirtualHost _default_:80>
+ DocumentRoot /www/default
+ ...
+ </VirtualHost> + + +

+ +

Migration d'un serveur virtuel + par nom en un serveur virtuel par IP + +

+ + + Configuration du serveur + + Listen 80
+ ServerName www.example1.com
+ DocumentRoot /www/example1
+
+ NameVirtualHost 172.20.30.40
+
+ <VirtualHost 172.20.30.40 172.20.30.50>
+ + DocumentRoot /www/example2
+ ServerName www.example2.org
+ # ...
+ + </VirtualHost>
+
+ <VirtualHost 172.20.30.40>
+ + DocumentRoot /www/example3
+ ServerName www.example3.net
+ ServerAlias *.example3.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).

+ +

Utilisation de la directive + <code>ServerPath</code> + +

+ + + Configuration du serveur + + NameVirtualHost 172.20.30.40
+
+ <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.

+ +

+ + diff --git a/docs/manual/vhosts/fd-limits.html.fr b/docs/manual/vhosts/fd-limits.html.fr new file mode 100644 index 00000000000..792508f87a9 --- /dev/null +++ b/docs/manual/vhosts/fd-limits.html.fr @@ -0,0 +1,143 @@ + + + +Limites des descripteurs de fichiers - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.1 > Serveurs Virtuels

Limites des descripteurs de fichiers

Langues Disponibles: en | + fr | + ja | + ko

Cette traduction peut être périmée. Verifiez la version + Anglaise pour les changements récents.

+ + +

Quand de nombreux serveurs virtuels sont créés, Apache peut + dépasser les limites en descripteurs de fichiers ('file descriptors', + également appelés gestionnaires de fichiers) 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.

+ +

Apache tente d'accroître cette valeur limite si nécessaire, mais + sans y parvenir dans les cas suivants :

+ +

Le système d'exploitation ne permet pas l'utilisation d'appels + systèmes setrlimit().
L'appel setrlimit(RLIMIT_NOFILE) ne fonctionne pas + sur votre système d'exploitation (c'est le cas sous Solaris 2.3).
Le nombre de descripteurs de fichiers nécessaires à Apache + dépasse la limite physique du matériel.
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).

+ +

En cas de problème, Vous pouvez :

+ +

Réduire le nombre de fichiers journaux, en ne spécifiant + aucun fichier journal dans les sections + <VirtualHost>, + en donc en envoyant les informations aux fichiers journaux du + serveur principal (Voir Éclatement des + fichiers journaux ci-dessous pour plus d'informations sur + cette possibilité).
+ 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 + +
+ #!/bin/sh + ulimit -S -n 100 + exec httpd +
+

+ + + +

Éclatement des fichiers journaux

+ +

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 :

+ +

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 + LogFormat et de la +variable %v. Ajoutez cette variable au début de la chaîne +de définition du format de journalisations :

+ +

+LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost +CustomLog logs/multiple_vhost_log vhost +

+ +

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 ServerName). +(Voir Formats de journalisation +personnalisés pour d'autres informations sur la +personnalisation des fichiers journaux.)

+ +

Au moment de séparer les informations du fichier journal en un fichier +par serveur virtuel, le programme +split-logfile peut être +utilisé. Ce programme peut être trouvé dans le répertoire +support de la distribution d'Apache.

+ +

Exécutez ce programme au moyen de la commande :

+ +

+split-logfile < /logs/multiple_vhost_log +

+ +

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é nomduserveur.log.

+ +

Langues Disponibles: en | + fr | + ja | + ko

+ \ No newline at end of file diff --git a/docs/manual/vhosts/fd-limits.xml.fr b/docs/manual/vhosts/fd-limits.xml.fr new file mode 100644 index 00000000000..bdb3ce7c8e2 --- /dev/null +++ b/docs/manual/vhosts/fd-limits.xml.fr @@ -0,0 +1,141 @@ + + + + + + + + + +Serveurs Virtuels + Limites des descripteurs de fichiers + +

+ +

Apache tente d'accroître cette valeur limite si nécessaire, mais + sans y parvenir dans les cas suivants :

+ +

Le système d'exploitation ne permet pas l'utilisation d'appels + systèmes setrlimit().
L'appel setrlimit(RLIMIT_NOFILE) ne fonctionne pas + sur votre système d'exploitation (c'est le cas sous Solaris 2.3).
Le nombre de descripteurs de fichiers nécessaires à Apache + dépasse la limite physique du matériel.
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).

+ +

En cas de problème, Vous pouvez :

+ +

Réduire le nombre de fichiers journaux, en ne spécifiant + aucun fichier journal dans les sections + VirtualHost, + en donc en envoyant les informations aux fichiers journaux du + serveur principal (Voir Éclatement des + fichiers journaux ci-dessous pour plus d'informations sur + cette possibilité).
+ 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 + + + #!/bin/sh + ulimit -S -n 100 + exec httpd + +

+ + + +

+ +

Éclatement des fichiers journaux + +

+ +

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 + LogFormat et de la +variable %v. Ajoutez cette variable au début de la chaîne +de définition du format de journalisations :

+ + +LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost
+CustomLog logs/multiple_vhost_log vhost + + +

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 ServerName). +(Voir Formats de journalisation +personnalisés pour d'autres informations sur la +personnalisation des fichiers journaux.)

+ +

Exécutez ce programme au moyen de la commande :

+ + +split-logfile < /logs/multiple_vhost_log + + +

+ +

+ + diff --git a/docs/manual/vhosts/index.html.fr b/docs/manual/vhosts/index.html.fr new file mode 100644 index 00000000000..1cb324f9e38 --- /dev/null +++ b/docs/manual/vhosts/index.html.fr @@ -0,0 +1,111 @@ + + + +Documentation sur les serveurs virtuels Apache - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.1

Documentation sur les serveurs virtuels Apache

Langues Disponibles: de | + en | + fr | + ja | + ko

Cette traduction peut être périmée. Verifiez la version + Anglaise pour les changements récents.

+ + +

Le principe des Serveurs Virtuels consiste à + faire fonctionner un ou plusieurs serveurs Web (comme + www.company1.com et www.company2.com) + sur une même machine. Les serveurs virtuels peuvent être soit + "par-IP" où une adresse IP est + attribuée pour chaque serveur Web, soit "par-nom" 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.

+ +

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 host-based + ou serveur virtuel non-IP.

+ +

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.

+ +

Support des serveurs virtuels
Directives de configuration

Voir aussi

Support des serveurs virtuels

+ +

Serveurs Virtuels par-Nom + (Un ou plusieurs sites Web par adresse IP)
Serveurs Virtuels par-IP + (Une adresse IP pour chaque site Web)
Exemples de configurations classiques + de Serveurs Virtuels
Limites des descripteurs de fichiers + (ou, trop de fichiers journaux)
Configuration dynamique en masse de + Serveurs Virtuels
Explication approfondie des critères + de sélection d'un Serveur Virtuel

+ +

Directives de configuration

+ +

Pour vérifier et analyser la configuration de vos serveurs + virtuels, vous pouvez utiliser l'argument -S sur + la ligne de commande lançant le programme Apache comme ceci :

+ +

+ /usr/local/apache2/bin/httpd -S +

+ +

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 + httpd pour les autres arguments de la ligne de + commande)

+ +

Langues Disponibles: de | + en | + fr | + ja | + ko

+ \ No newline at end of file diff --git a/docs/manual/vhosts/index.xml.fr b/docs/manual/vhosts/index.xml.fr new file mode 100644 index 00000000000..0243b5da781 --- /dev/null +++ b/docs/manual/vhosts/index.xml.fr @@ -0,0 +1,108 @@ + + + + + + + + + + + + Documentation sur les serveurs virtuels Apache + +

+ +

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.

+ +

+ +mod_vhost_alias +Serveurs virtuels par-nom +Serveurs virtuels par-IP +Exemples de serveurs virtuels +Limites des descripteurs de fichiers +Hébergement virtuel en masse +Détails sur les critères de choix du serveur + +

Support des serveurs virtuels + +

Serveurs Virtuels par-Nom + (Un ou plusieurs sites Web par adresse IP)
Serveurs Virtuels par-IP + (Une adresse IP pour chaque site Web)
Exemples de configurations classiques + de Serveurs Virtuels
Limites des descripteurs de fichiers + (ou, trop de fichiers journaux)
Configuration dynamique en masse de + Serveurs Virtuels
Explication approfondie des critères + de sélection d'un Serveur Virtuel

+ +

Directives de configuration + +

VirtualHost
NameVirtualHost
ServerName
ServerAlias
ServerPath

+ +

Pour vérifier et analyser la configuration de vos serveurs + virtuels, vous pouvez utiliser l'argument -S sur + la ligne de commande lançant le programme Apache comme ceci :

+ + + /usr/local/apache2/bin/httpd -S + + +

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 + httpd pour les autres arguments de la ligne de + commande)

+ +

+ diff --git a/docs/manual/vhosts/ip-based.html.fr b/docs/manual/vhosts/ip-based.html.fr new file mode 100644 index 00000000000..a7dd3804b01 --- /dev/null +++ b/docs/manual/vhosts/ip-based.html.fr @@ -0,0 +1,184 @@ + + + +Support Apache des serveurs virtuels par IP - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.1 > Serveurs virtuels

Support Apache des serveurs virtuels par IP

Langues Disponibles: en | + fr | + ja | + ko

Cette traduction peut être périmée. Verifiez la version + Anglaise pour les changements récents.

Système requis
Comment configurer Apache
Configuration de processus multiples
Configuration d'un unique processus +résident pour des serveurs virtuels

Voir aussi

+Support Apache des serveurs virtuels par nom +

Système requis

+ +

Comme l'indique le terme par IP, le serveur + doit disposer de différentes adresses IP pour chaque + serveur virtuel par IP. 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).

+ +

Comment configurer Apache

+ +

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 httpd pour chaque nom de + domaine, soit de faire tourner un unique processus résident qui + gère tous les serveurs virtuels.

+ +

Utilisez des processus résidents multiples lorsque :

+ +

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 User, + Group, + Listen, et + ServerRoot différents.
vous disposez suffisamment de mémoire et de + descripteurs de fichiers + pour l'écoute de chaque alias IP de la machine. Il est seulement + possible d'appliquer la directive + Listen, 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 httpd pour écouter N-1 adresses, + et un autre pour l'adresse restante).

+ +

Utilisez un unique processus résident lorsque :

+ +

le partage de la configuration httpd entre les serveurs + virtuels est acceptable.
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.

+ +

Configuration de processus multiples

+ +

Créez une installation indépendante du programme + httpd pour chaque serveur virtuel. Pour + chacune d'elle, utilisez la directive + Listen dans le fichier + de configuration pour définir l'adresse IP (ou serveur virtuel) + que le processus résident doit gérer. Par exemple :

+ +

+ Listen www.smallco.com:80 +

+ +

Il est recommandé d'utiliser une adresse IP plutôt qu'un nom + de domaine (consultez Problèmes DNS + avec Apache).

+ +

Configuration d'un unique processus +résident pour des serveurs virtuels

+ +

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 + VirtualHost va servir à + définir les autres directives + ServerAdmin, + ServerName, + DocumentRoot, + ErrorLog et + TransferLog ou + CustomLog avec des + valeurs différentes pour chaque serveur virtuel. Par exemple :

+ +

+ <VirtualHost www.smallco.com> + ServerAdmin webmaster@mail.smallco.com + DocumentRoot /groups/smallco/www + ServerName www.smallco.com + ErrorLog /groups/smallco/logs/error_log + TransferLog /groups/smallco/logs/access_log + </VirtualHost> + + <VirtualHost www.baygroup.org> + ServerAdmin webmaster@mail.baygroup.org + DocumentRoot /groups/baygroup/www + ServerName www.baygroup.org + ErrorLog /groups/baygroup/logs/error_log + TransferLog /groups/baygroup/logs/access_log + </VirtualHost> +

+ +

Il est recommandé d'utiliser une adresse IP plutôt qu'un nom + de domaine (consultez Problèmes DNS + avec Apache).

+ +

Presque toutes 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 + Contexte en utilisant + l'Index des directives.

+ + + SuexecUserGroup peut être + utilisées à l'intérieur d'une directive VirtualHost si l'exécution se fait sous + suEXEC. (Voir suEXEC). + +

SÉCURITÉ : 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 + Conseils sur la sécurité + pour plus de détails.

+ +

Langues Disponibles: en | + fr | + ja | + ko

+ \ No newline at end of file diff --git a/docs/manual/vhosts/ip-based.xml.fr b/docs/manual/vhosts/ip-based.xml.fr new file mode 100644 index 00000000000..0a74cf8c2c4 --- /dev/null +++ b/docs/manual/vhosts/ip-based.xml.fr @@ -0,0 +1,176 @@ + + + + + + + + + +Serveurs virtuels + Support Apache des serveurs virtuels par IP + + +Support Apache des serveurs virtuels par nom + + +

Système requis + +

+ +

Comment configurer Apache + +

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 httpd pour chaque nom de + domaine, soit de faire tourner un unique processus résident qui + gère tous les serveurs virtuels.

+ +

Utilisez des processus résidents multiples lorsque :

+ +

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 User, + Group, + Listen, et + ServerRoot différents.
vous disposez suffisamment de mémoire et de + descripteurs de fichiers + pour l'écoute de chaque alias IP de la machine. Il est seulement + possible d'appliquer la directive + Listen, 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 httpd pour écouter N-1 adresses, + et un autre pour l'adresse restante).

+ +

Utilisez un unique processus résident lorsque :

+ +

le partage de la configuration httpd entre les serveurs + virtuels est acceptable.
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.

+ +

Configuration de processus multiples + +

Créez une installation indépendante du programme + httpd pour chaque serveur virtuel. Pour + chacune d'elle, utilisez la directive + Listen dans le fichier + de configuration pour définir l'adresse IP (ou serveur virtuel) + que le processus résident doit gérer. Par exemple :

+ + + Listen www.smallco.com:80 + + +

Il est recommandé d'utiliser une adresse IP plutôt qu'un nom + de domaine (consultez Problèmes DNS + avec Apache).

+ +

Configuration d'un unique processus +résident pour des serveurs virtuels + +

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 + VirtualHost va servir à + définir les autres directives + ServerAdmin, + ServerName, + DocumentRoot, + ErrorLog et + TransferLog ou + CustomLog avec des + valeurs différentes pour chaque serveur virtuel. Par exemple :

+ + + <VirtualHost www.smallco.com>
+ ServerAdmin webmaster@mail.smallco.com
+ DocumentRoot /groups/smallco/www
+ ServerName www.smallco.com
+ ErrorLog /groups/smallco/logs/error_log
+ TransferLog /groups/smallco/logs/access_log
+ </VirtualHost>
+
+ <VirtualHost www.baygroup.org>
+ ServerAdmin webmaster@mail.baygroup.org
+ DocumentRoot /groups/baygroup/www
+ ServerName www.baygroup.org
+ ErrorLog /groups/baygroup/logs/error_log
+ TransferLog /groups/baygroup/logs/access_log
+ </VirtualHost> + + +

Il est recommandé d'utiliser une adresse IP plutôt qu'un nom + de domaine (consultez Problèmes DNS + avec Apache).

+ +

+ + + SuexecUserGroup peut être + utilisées à l'intérieur d'une directive VirtualHost si l'exécution se fait sous + suEXEC. (Voir suEXEC). + +

+ +

+ diff --git a/docs/manual/vhosts/name-based.html.fr b/docs/manual/vhosts/name-based.html.fr new file mode 100644 index 00000000000..c98033a8111 --- /dev/null +++ b/docs/manual/vhosts/name-based.html.fr @@ -0,0 +1,300 @@ + + + +Support Apache des serveurs virtuels par nom - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.1 > Serveurs virtuels

Support Apache des serveurs virtuels par nom

Langues Disponibles: de | + en | + fr | + ja | + ko

Cette traduction peut être périmée. Verifiez la version + Anglaise pour les changements récents.

+ +

Ce document décrit quand et comment utiliser des serveurs + virtuels par nom.

Serveurs virtuels par nom vs. par IP
Utilisation de serveurs virtuels par nom
Compatibilité avec les navigateurs anciens

Voir aussi

Serveurs virtuels par nom vs. par IP

+ +

Les hébergements virtuels par IP utilisent l'adresse IP + de la connexion afin de déterminer quel serveur virtuel doit + répondre. Par conséquent, vous devez disposer d'adresses IP + différentes pour chaque nom de domaine complet (FQDN) que vous hébergez. + Avec un hébergement + virtuel par nom, le serveur s'appuit 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.

+ +

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 dont vous disposez, 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 :

+ +

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.
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.
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.

+ +

Utilisation de serveurs virtuels par nom

Modules Apparentés	Directives Apparentées
`core`	`DocumentRoot` `NameVirtualHost` `ServerAlias` `ServerName` `ServerPath` `<VirtualHost>`

+ + + +

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 + NameVirtualHost. Dans un + cas normal où n'importe quelle adresse IP peut être utilisée, + vous pouvez ajouter * comme argument de la directive + NameVirtualHost. Si vous + prévoyez d'utiliser de multiples ports (comme l'emploi de SSL), + vous devriez ajouter le port à cet argument tel que + *:80. Notez que la simple mention d'une adresse + IP dans une directive + NameVirtualHost ne suffit + pas à faire écouter le serveur sur cette IP. Consultez + la page sur les liaisons 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.

+ +

L'étape suivante est la création d'une section + <VirtualHost> + pour chacun des serveurs à créer. L'argument de la directive + <VirtualHost> + doit être le même que celui de la directive + NameVirtualHost + (c'est-à-dire l'adresse IP ou * pour toutes les + adresses). Dans chaque section + <VirtualHost>, + vous devez définir au minimum une directive + ServerName pour désigner + le serveur concerné et une directive + DocumentRoot pour préciser + l'emplacement sur le système de fichiers du contenu de ce serveur.

+ +

Le serveur principal disparaît

Si vous ajoutez des serveurs virtuels à un serveur Web + existant, vous devez également créer une section + <VirtualHost> + redéfinissant ce serveur existant. Les directives + ServerName et + DocumentRoot incluses + dans ce serveur virtuel doivent être les mêmes que pour + les directives globales + ServerName et + DocumentRoot. Positionnez + ce serveur virtuel en premier dans le fichier de configuration + pour en faire le serveur par défaut.

+ +

Par exemple, supposez que vous hébergez le domaine + www.domain.tld et que vous souhaitez ajouter le + serveur virtuel www.otherdomain.tld qui pointe sur + la même adresse IP. Il vous suffit d'ajouter la configuration + suivante à httpd.conf :

+ +

+ NameVirtualHost *:80 + + <VirtualHost *:80> + + ServerName www.domain.tld + ServerAlias domain.tld *.domain.tld + DocumentRoot /www/domain + + </VirtualHost> + + <VirtualHost *:80> + ServerName www.otherdomain.tld + DocumentRoot /www/otherdomain + + </VirtualHost> +

+ +

Autrement, vous pouvez spécifiez une adresse IP explicite + à la place de * dans les deux directives + NameVirtualHost et + <VirtualHost>. + 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.

+ +

Plusieurs serveurs sont accessibles par plus d'un nom. Il + suffit de placer la directive + ServerAlias dans une section + <VirtualHost>. + Par exemple, dans la première section + <VirtualHost> + ci-dessus, la directive ServerAlias + indique aux utilisateurs les autres noms permis pour accéder au + même site Web :

+ +

+ ServerAlias domain.tld *.domain.tld +

+ +

ainsi, toutes les requêtes portant sur un domaine + domain.tld seront servies par le serveur virtuel + www.domain.tld. Les caractères joker * + et ? peuvent être utilisés pour les correspondances. + Bien entendu, vous ne pouvez pas inventer des noms et les placer + dans une directive ServerName + ou ServerAlias. Tout d'abord, votre serveur DNS + doit être correctement configuré pour lier ces noms à une + adresse IP associée avec votre serveur.

+ +

Finalement, vous pouvez affiner la configuration des serveurs + virtuels en plaçant d'autres directives à l'intérieur des sections + <VirtualHost>. + La plupart des directives peut être placée dans ces sections en + y changeant seulement la configuration du serveur virtuel associé. + Pour déterminer si une directive particulière est permise, + consultez la page de + contexte. Le jeu de directives configurées dans le contexte + du serveur principal (en dehors de toutes sections + <VirtualHost>) + sera utilisé seulement s'il n'y a pas de configuration contraire + par un serveur virtuel.

+ +

Maintenant, lorsqu'une requête arrive, le serveur va d'abord + tester si elle utilise une adresse IP qui correspond à + NameVirtualHost. Si c'est + le cas, il regardera chaque section + <VirtualHost> + avec l'adresse correspondante et essaiera d'en trouver une où + le nom de domaine requis correspond à + ServerName ou + ServerAlias. S'il en trouve une, il utilisera + sa configuration pour le serveur. Si aucun serveur virtuel ne + correspond, alors le premier serveur virtuel listé + dont l'adresse IP correspond sera employé.

+ +

En conséquence, le premier serveur virtuel listé est le + serveur virtuel default. La directive + DocumentRoot du + serveur principal ne sera + jamais employée lorsqu'une adresse IP + correspond dans une directive + NameVirtualHost. 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 + <VirtualHost> + que vous placerez en premier dans le fichier de configuration.

+ +

Compatibilité avec les navigateurs anciens

+ +

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 primaire).

+ +

De combien plus anciens ?

Veuillez noter que quand nous disons plus anciens, nous + disons vraiment plus anciens. 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 + Host comme exigé par les serveurs virtuels par nom.

+ +

Il existe une solution avec la directive + ServerPath, bien que + légèrement complexe :

+ +

Exemple de configuration :

+ +

+ NameVirtualHost 111.22.33.44 + + <VirtualHost 111.22.33.44> + + ServerName www.domain.tld + ServerPath /domain + DocumentRoot /web/domain + + </VirtualHost> +

+ +

Qu'est-ce que cela signifie ? Il signifie qu'une requête + pour tout URI qui commence par "/domain" sera + servie par le serveur virtuel www.domain.tld. + Ainsi, les pages sont accessibles à + http://www.domain.tld/domain/ pour tous les + clients, bien que ceux qui transmettent un en-tête + Host: peuvent également y accéder à + http://www.domain.tld/.

+ +

Pour rendre cette technique fonctionnelle, mettez un lien + dans votre serveur virtuel primaire vers + http://www.domain.tld/domain/. Ensuite, dans les + pages de ce serveur virtuel, assurez vous ne n'utiliser que + des liens relatifs (par exemple, "file.html" + ou "../icons/image.gif") ou des liens contenant + le préfixe /domain/ (par exemple, + "http://www.domain.tld/domain/misc/file.html" + ou "/domain/misc/file.html").

+ +

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.

+ +

Langues Disponibles: de | + en | + fr | + ja | + ko

+ \ No newline at end of file diff --git a/docs/manual/vhosts/name-based.xml.fr b/docs/manual/vhosts/name-based.xml.fr new file mode 100644 index 00000000000..6802c7ddef2 --- /dev/null +++ b/docs/manual/vhosts/name-based.xml.fr @@ -0,0 +1,304 @@ + + + + + + + + + +Serveurs virtuels +Support Apache des serveurs virtuels par nom + +

Ce document décrit quand et comment utiliser des serveurs + virtuels par nom.

+ +Support Apache des serveurs virtuels par IP +Détails sur le fonctionnement des serveurs virtuels +Configuration dynamique des hébergements virtuels de masse +Exemples d'utilisations de VirtualHost +Utilisation de la directive ServerPath + +

Serveurs virtuels par nom vs. par IP + +

+ +

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.
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.
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.

+ +

Utilisation de serveurs virtuels par nom + + + + core + + + + DocumentRoot + NameVirtualHost + ServerAlias + ServerName + ServerPath + VirtualHost + + + +

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 + NameVirtualHost. Dans un + cas normal où n'importe quelle adresse IP peut être utilisée, + vous pouvez ajouter * comme argument de la directive + NameVirtualHost. Si vous + prévoyez d'utiliser de multiples ports (comme l'emploi de SSL), + vous devriez ajouter le port à cet argument tel que + *:80. Notez que la simple mention d'une adresse + IP dans une directive + NameVirtualHost ne suffit + pas à faire écouter le serveur sur cette IP. Consultez + la page sur les liaisons 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.

+ +

L'étape suivante est la création d'une section + VirtualHost + pour chacun des serveurs à créer. L'argument de la directive + VirtualHost + doit être le même que celui de la directive + NameVirtualHost + (c'est-à-dire l'adresse IP ou * pour toutes les + adresses). Dans chaque section + VirtualHost, + vous devez définir au minimum une directive + ServerName pour désigner + le serveur concerné et une directive + DocumentRoot pour préciser + l'emplacement sur le système de fichiers du contenu de ce serveur.

+ + Le serveur principal disparaît +

Si vous ajoutez des serveurs virtuels à un serveur Web + existant, vous devez également créer une section + VirtualHost + redéfinissant ce serveur existant. Les directives + ServerName et + DocumentRoot incluses + dans ce serveur virtuel doivent être les mêmes que pour + les directives globales + ServerName et + DocumentRoot. Positionnez + ce serveur virtuel en premier dans le fichier de configuration + pour en faire le serveur par défaut.

+ + +

+ + + NameVirtualHost *:80
+
+ <VirtualHost *:80>
+ + ServerName www.domain.tld
+ ServerAlias domain.tld *.domain.tld
+ DocumentRoot /www/domain
+ + </VirtualHost>
+
+ <VirtualHost *:80>
+ ServerName www.otherdomain.tld
+ DocumentRoot /www/otherdomain
+ + </VirtualHost>
+ + +

Autrement, vous pouvez spécifiez une adresse IP explicite + à la place de * dans les deux directives + NameVirtualHost et + VirtualHost. + 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.

+ +

Plusieurs serveurs sont accessibles par plus d'un nom. Il + suffit de placer la directive + ServerAlias dans une section + VirtualHost. + Par exemple, dans la première section + VirtualHost + ci-dessus, la directive ServerAlias + indique aux utilisateurs les autres noms permis pour accéder au + même site Web :

+ + + ServerAlias domain.tld *.domain.tld + + +

ainsi, toutes les requêtes portant sur un domaine + domain.tld seront servies par le serveur virtuel + www.domain.tld. Les caractères joker * + et ? peuvent être utilisés pour les correspondances. + Bien entendu, vous ne pouvez pas inventer des noms et les placer + dans une directive ServerName + ou ServerAlias. Tout d'abord, votre serveur DNS + doit être correctement configuré pour lier ces noms à une + adresse IP associée avec votre serveur.

+ +

Finalement, vous pouvez affiner la configuration des serveurs + virtuels en plaçant d'autres directives à l'intérieur des sections + VirtualHost. + La plupart des directives peut être placée dans ces sections en + y changeant seulement la configuration du serveur virtuel associé. + Pour déterminer si une directive particulière est permise, + consultez la page de + contexte. Le jeu de directives configurées dans le contexte + du serveur principal (en dehors de toutes sections + VirtualHost) + sera utilisé seulement s'il n'y a pas de configuration contraire + par un serveur virtuel.

+ +

Maintenant, lorsqu'une requête arrive, le serveur va d'abord + tester si elle utilise une adresse IP qui correspond à + NameVirtualHost. Si c'est + le cas, il regardera chaque section + VirtualHost + avec l'adresse correspondante et essaiera d'en trouver une où + le nom de domaine requis correspond à + ServerName ou + ServerAlias. S'il en trouve une, il utilisera + sa configuration pour le serveur. Si aucun serveur virtuel ne + correspond, alors le premier serveur virtuel listé + dont l'adresse IP correspond sera employé.

+ +

En conséquence, le premier serveur virtuel listé est le + serveur virtuel default. La directive + DocumentRoot du + serveur principal ne sera + jamais employée lorsqu'une adresse IP + correspond dans une directive + NameVirtualHost. 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 + VirtualHost + que vous placerez en premier dans le fichier de configuration.

+ +

Compatibilité avec les navigateurs anciens + +

+ + De combien plus anciens ? +

+ + +

Il existe une solution avec la directive + ServerPath, bien que + légèrement complexe :

+ +

Exemple de configuration :

+ + + NameVirtualHost 111.22.33.44
+
+ <VirtualHost 111.22.33.44>
+ + ServerName www.domain.tld
+ ServerPath /domain
+ DocumentRoot /web/domain
+ + </VirtualHost>
+ + +

+ +

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.

+ +