From fe39ffb8b90ae4e002ed73fe98617cd590abb467 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sat, 27 Apr 2024 08:33:50 +0200 Subject: Adding upstream version 2.4.56. Signed-off-by: Daniel Baumann --- docs/manual/vhosts/details.html | 17 + docs/manual/vhosts/details.html.en | 348 ++++++++++++++ docs/manual/vhosts/details.html.fr.utf8 | 369 +++++++++++++++ docs/manual/vhosts/details.html.ko.euc-kr | 412 ++++++++++++++++ docs/manual/vhosts/details.html.tr.utf8 | 319 +++++++++++++ docs/manual/vhosts/examples.html | 21 + docs/manual/vhosts/examples.html.en | 566 ++++++++++++++++++++++ docs/manual/vhosts/examples.html.fr.utf8 | 586 +++++++++++++++++++++++ docs/manual/vhosts/examples.html.ja.utf8 | 680 +++++++++++++++++++++++++++ docs/manual/vhosts/examples.html.ko.euc-kr | 657 ++++++++++++++++++++++++++ docs/manual/vhosts/examples.html.tr.utf8 | 562 ++++++++++++++++++++++ docs/manual/vhosts/fd-limits.html | 21 + docs/manual/vhosts/fd-limits.html.en | 155 ++++++ docs/manual/vhosts/fd-limits.html.fr.utf8 | 167 +++++++ docs/manual/vhosts/fd-limits.html.ja.utf8 | 157 +++++++ docs/manual/vhosts/fd-limits.html.ko.euc-kr | 152 ++++++ docs/manual/vhosts/fd-limits.html.tr.utf8 | 150 ++++++ docs/manual/vhosts/index.html | 29 ++ docs/manual/vhosts/index.html.de | 124 +++++ docs/manual/vhosts/index.html.en | 126 +++++ docs/manual/vhosts/index.html.fr.utf8 | 127 +++++ docs/manual/vhosts/index.html.ja.utf8 | 120 +++++ docs/manual/vhosts/index.html.ko.euc-kr | 119 +++++ docs/manual/vhosts/index.html.tr.utf8 | 123 +++++ docs/manual/vhosts/index.html.zh-cn.utf8 | 105 +++++ docs/manual/vhosts/ip-based.html | 21 + docs/manual/vhosts/ip-based.html.en | 210 +++++++++ docs/manual/vhosts/ip-based.html.fr.utf8 | 213 +++++++++ docs/manual/vhosts/ip-based.html.ja.utf8 | 190 ++++++++ docs/manual/vhosts/ip-based.html.ko.euc-kr | 180 +++++++ docs/manual/vhosts/ip-based.html.tr.utf8 | 211 +++++++++ docs/manual/vhosts/mass.html | 17 + docs/manual/vhosts/mass.html.en | 348 ++++++++++++++ docs/manual/vhosts/mass.html.fr.utf8 | 363 ++++++++++++++ docs/manual/vhosts/mass.html.ko.euc-kr | 453 ++++++++++++++++++ docs/manual/vhosts/mass.html.tr.utf8 | 334 +++++++++++++ docs/manual/vhosts/name-based.html | 25 + docs/manual/vhosts/name-based.html.de | 299 ++++++++++++ docs/manual/vhosts/name-based.html.en | 224 +++++++++ docs/manual/vhosts/name-based.html.fr.utf8 | 267 +++++++++++ docs/manual/vhosts/name-based.html.ja.utf8 | 303 ++++++++++++ docs/manual/vhosts/name-based.html.ko.euc-kr | 266 +++++++++++ docs/manual/vhosts/name-based.html.tr.utf8 | 238 ++++++++++ 43 files changed, 10374 insertions(+) create mode 100644 docs/manual/vhosts/details.html create mode 100644 docs/manual/vhosts/details.html.en create mode 100644 docs/manual/vhosts/details.html.fr.utf8 create mode 100644 docs/manual/vhosts/details.html.ko.euc-kr create mode 100644 docs/manual/vhosts/details.html.tr.utf8 create mode 100644 docs/manual/vhosts/examples.html create mode 100644 docs/manual/vhosts/examples.html.en create mode 100644 docs/manual/vhosts/examples.html.fr.utf8 create mode 100644 docs/manual/vhosts/examples.html.ja.utf8 create mode 100644 docs/manual/vhosts/examples.html.ko.euc-kr create mode 100644 docs/manual/vhosts/examples.html.tr.utf8 create mode 100644 docs/manual/vhosts/fd-limits.html create mode 100644 docs/manual/vhosts/fd-limits.html.en create mode 100644 docs/manual/vhosts/fd-limits.html.fr.utf8 create mode 100644 docs/manual/vhosts/fd-limits.html.ja.utf8 create mode 100644 docs/manual/vhosts/fd-limits.html.ko.euc-kr create mode 100644 docs/manual/vhosts/fd-limits.html.tr.utf8 create mode 100644 docs/manual/vhosts/index.html create mode 100644 docs/manual/vhosts/index.html.de create mode 100644 docs/manual/vhosts/index.html.en create mode 100644 docs/manual/vhosts/index.html.fr.utf8 create mode 100644 docs/manual/vhosts/index.html.ja.utf8 create mode 100644 docs/manual/vhosts/index.html.ko.euc-kr create mode 100644 docs/manual/vhosts/index.html.tr.utf8 create mode 100644 docs/manual/vhosts/index.html.zh-cn.utf8 create mode 100644 docs/manual/vhosts/ip-based.html create mode 100644 docs/manual/vhosts/ip-based.html.en create mode 100644 docs/manual/vhosts/ip-based.html.fr.utf8 create mode 100644 docs/manual/vhosts/ip-based.html.ja.utf8 create mode 100644 docs/manual/vhosts/ip-based.html.ko.euc-kr create mode 100644 docs/manual/vhosts/ip-based.html.tr.utf8 create mode 100644 docs/manual/vhosts/mass.html create mode 100644 docs/manual/vhosts/mass.html.en create mode 100644 docs/manual/vhosts/mass.html.fr.utf8 create mode 100644 docs/manual/vhosts/mass.html.ko.euc-kr create mode 100644 docs/manual/vhosts/mass.html.tr.utf8 create mode 100644 docs/manual/vhosts/name-based.html create mode 100644 docs/manual/vhosts/name-based.html.de create mode 100644 docs/manual/vhosts/name-based.html.en create mode 100644 docs/manual/vhosts/name-based.html.fr.utf8 create mode 100644 docs/manual/vhosts/name-based.html.ja.utf8 create mode 100644 docs/manual/vhosts/name-based.html.ko.euc-kr create mode 100644 docs/manual/vhosts/name-based.html.tr.utf8 (limited to 'docs/manual/vhosts') diff --git a/docs/manual/vhosts/details.html b/docs/manual/vhosts/details.html new file mode 100644 index 0000000..8132639 --- /dev/null +++ b/docs/manual/vhosts/details.html @@ -0,0 +1,17 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: details.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: details.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +URI: details.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR + +URI: details.html.tr.utf8 +Content-Language: tr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/vhosts/details.html.en b/docs/manual/vhosts/details.html.en new file mode 100644 index 0000000..d0fa1d0 --- /dev/null +++ b/docs/manual/vhosts/details.html.en @@ -0,0 +1,348 @@ + + + + + +An In-Depth Discussion of Virtual Host Matching - Apache HTTP Server Version 2.4 + + + + + + + +
<-
+

An In-Depth Discussion of Virtual Host Matching

+
+

Available Languages:  en  | + fr  | + ko  | + tr 

+
+ + +

This document attempts to explain + exactly what Apache HTTP Server does when deciding what virtual host to + serve a request from.

+ +

Most users should read about + Name-based vs. IP-based Virtual Hosts to decide which type they + want to use, then read more about name-based + or IP-based virtualhosts, and then see + some examples.

+ +

If you want to understand all the details, then you can + come back to this page.

+ +
+ +
top
+
+

Configuration File

+ +

There is a main server which consists of all the + definitions appearing outside of + <VirtualHost> sections.

+ +

There are virtual + servers, called vhosts, which are defined by + <VirtualHost> + sections.

+ +

Each VirtualHost directive includes one + or more addresses and optional ports.

+ +

Hostnames can be used in place of IP addresses in a virtual + host definition, but they are resolved at startup and if any name + resolutions fail, those virtual host definitions are ignored. + This is, therefore, not recommended.

+ +

The address can be specified as + *, which will match a request if no + other vhost has the explicit address on which the request was + received.

+ +

The address appearing in the VirtualHost + directive can have an optional port. If the port is unspecified, + it is treated as a wildcard port, which can also be indicated + explicitly using *. + The wildcard port matches any port.

+ +

(Port numbers specified in the VirtualHost directive do + not influence what port numbers Apache will listen on, they only control + which VirtualHost will be selected to handle a request. + Use the Listen directive to + control the addresses and ports on which the server listens.) +

+ +

Collectively the + entire set of addresses (including multiple + results from DNS lookups) are called the vhost's + address set.

+ +

Apache automatically discriminates on the + basis of the HTTP Host header supplied by the client + whenever the most specific match for an IP address and port combination + is listed in multiple virtual hosts.

+ +

The + ServerName directive + may appear anywhere within the definition of a server. However, + each appearance overrides the previous appearance (within that + server). If no ServerName is specified, the server + attempts to deduce it from the server's IP address.

+ +

The first name-based vhost in the configuration file for a + given IP:port pair is significant because it is used for all + requests received on that address and port for which no other + vhost for that IP:port pair has a matching ServerName or + ServerAlias. It is also used for all SSL connections if the + server does not support Server Name Indication.

+ +

The complete list of names in the VirtualHost + directive are treated just like a (non wildcard) ServerAlias + (but are not overridden by any ServerAlias statement).

+ +

For every vhost various default values are set. In + particular:

+ +
    +
  1. If a vhost has no ServerAdmin, + Timeout, + KeepAliveTimeout, + KeepAlive, + MaxKeepAliveRequests, + ReceiveBufferSize, + or SendBufferSize + directive then the respective value is inherited from the + main server. (That is, inherited from whatever the final + setting of that value is in the main server.)
  2. + +
  3. The "lookup defaults" that define the default directory + permissions for a vhost are merged with those of the + main server. This includes any per-directory configuration + information for any module.
  4. + +
  5. The per-server configs for each module from the + main server are merged into the vhost server.
  6. +
+ +

Essentially, the main server is treated as "defaults" or a + "base" on which to build each vhost. But the positioning of + these main server definitions in the config file is largely + irrelevant -- the entire config of the main server has been + parsed when this final merging occurs. So even if a main server + definition appears after a vhost definition it might affect the + vhost definition.

+ +

If the main server has no ServerName at this + point, then the hostname of the machine that httpd + is running on is used instead. We will call the main server address + set those IP addresses returned by a DNS lookup on the + ServerName of the main server.

+ +

For any undefined ServerName fields, a + name-based vhost defaults to the address given first in the + VirtualHost statement defining the vhost.

+ +

Any vhost that includes the magic _default_ + wildcard is given the same ServerName as the + main server.

+ +
top
+
+

Virtual Host Matching

+ +

The server determines which vhost to use for a request as + follows:

+ +

IP address lookup

+ +

When the connection is first received on some address and port, + the server looks for all the VirtualHost definitions + that have the same IP address and port.

+ +

If there are no exact matches for the address and port, then + wildcard (*) matches are considered.

+ +

If no matches are found, the request is served by the + main server.

+ +

If there are VirtualHost definitions for + the IP address, the next step is to decide if we have to + deal with an IP-based or a name-based vhost.

+ + + +

IP-based vhost

+ +

If there is exactly one VirtualHost directive + listing the IP address and port combination that was determined + to be the best match, no further actions are performed and + the request is served from the matching vhost.

+ + + +

Name-based vhost

+ +

If there are multiple VirtualHost directives listing + the IP address and port combination that was determined to be the + best match, the "list" in the remaining steps refers to the list of vhosts + that matched, in the order they were in the configuration file.

+ +

If the connection is using SSL, the server supports Server Name Indication, and + the SSL client handshake includes the TLS extension with the + requested hostname, then that hostname is used below just like the + Host: header would be used on a non-SSL connection. + Otherwise, the first name-based vhost whose address matched is + used for SSL connections. This is significant because the + vhost determines which certificate the server will use for the + connection.

+ +

If the request contains a Host: header field, the + list is searched for the first vhost with a matching + ServerName or ServerAlias, and the + request is served from that vhost. A Host: header + field can contain a port number, but Apache always ignores it and + matches against the real port to which the client sent the + request.

+ +

The first vhost in the config + file with the specified IP address has the highest priority + and catches any request to an unknown server name, or a request + without a Host: header field (such as a HTTP/1.0 + request).

+ + + +

Persistent connections

+ +

The IP lookup described above is only done once for a + particular TCP/IP session while the name lookup is done on + every request during a KeepAlive/persistent + connection. In other words, a client may request pages from + different name-based vhosts during a single persistent + connection.

+ + + +

Absolute URI

+ +

If the URI from the request is an absolute URI, and its + hostname and port match the main server or one of the + configured virtual hosts and match the address and + port to which the client sent the request, then the + scheme/hostname/port prefix is stripped off and the remaining + relative URI is served by the corresponding main server or + virtual host. If it does not match, then the URI remains + untouched and the request is taken to be a proxy request.

+ + +

Observations

+ +
    +
  • Name-based virtual hosting is a process applied after + the server has selected the best matching IP-based virtual + host.
  • + +
  • If you don't care what IP address the client has connected to, use a + "*" as the address of every virtual host, and name-based virtual hosting + is applied across all configured virtual hosts.
  • + +
  • ServerName and ServerAlias + checks are never performed for an IP-based vhost.
  • + +
  • Only the ordering of + name-based vhosts for a specific address set is significant. + The one name-based vhosts that comes first in the + configuration file has the highest priority for its + corresponding address set.
  • + +
  • Any port in the Host: header field is never used during the + matching process. Apache always uses the real port to which + the client sent the request.
  • + +
  • If two vhosts have an address in common, those common addresses + act as name-based virtual hosts implicitly. This is new behavior as of + 2.3.11.
  • + +
  • The main server is only used to serve a request if the IP + address and port number to which the client connected + does not match any vhost (including a + * vhost). In other words, the main server + only catches a request for an unspecified address/port + combination (unless there is a _default_ vhost + which matches that port).
  • + +
  • You should never specify DNS names in + VirtualHost directives because it will force + your server to rely on DNS to boot. Furthermore it poses a + security threat if you do not control the DNS for all the + domains listed. There's more + information available on this and the next two + topics.
  • + +
  • ServerName should always be set for each + vhost. Otherwise a DNS lookup is required for each + vhost.
  • +
+ + +
top
+
+

Tips

+ +

In addition to the tips on the DNS Issues page, here are + some further tips:

+ +
    +
  • Place all main server definitions before any + VirtualHost definitions. (This is to aid the + readability of the configuration -- the post-config merging + process makes it non-obvious that definitions mixed in around + virtual hosts might affect all virtual hosts.)
  • +
+ +
+
+

Available Languages:  en  | + fr  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/details.html.fr.utf8 b/docs/manual/vhosts/details.html.fr.utf8 new file mode 100644 index 0000000..29bc31d --- /dev/null +++ b/docs/manual/vhosts/details.html.fr.utf8 @@ -0,0 +1,369 @@ + + + + + +Détails sur le fonctionnement des serveurs virtuels - Serveur HTTP Apache Version 2.4 + + + + + + + +
<-
+

Détails sur le fonctionnement des serveurs virtuels

+
+

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

+
+ + +

Ce document vise à expliquer dans le détail comment le serveur + HTTP Apache procède lors du choix de l'utilisation + d'un serveur virtuel en fonction d'une requête reçue.

+ +

Il est recommandé de lire la documentation + Serveurs virtuels à base de nom et serveurs virtuels à base + d'adresse IP pour déterminer quel type de serveur virtuel nous + convient le mieux, puis de lire les documentations serveurs virtuels à base de nom ou serveurs virtuels à base d'adresse IP, et enfin + d'étudier quelques exemples.

+ +

Si vous voulez entrer dans les détails, vous pouvez revenir vers + cette page.

+ +
+ +
top
+
+

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

+ +

Chaque directive VirtualHost comporte une ou + plusieurs adresses et des ports optionnels.

+ +

Il est possible d'utiliser des noms d'hôtes dans la définition + d'un serveur virtuel, mais ils seront résolus en adresses IP au + démarrage du serveur, et si une résolution de nom échoue, cette + définition de serveur virtuel sera ignorée. Cette méthode est par + conséquent déconseillée.

+ +

L'adresse peut + être spécifiée sous la forme *, ce qui conviendra à la + requête si aucun autre serveur virtuel ne possède l'adresse IP + explicite correspondant à celle de la requête.

+ +

L'adresse qui apparaît dans la directive VirtualHost + peut être associée à un port optionnel. Si aucun port n'est + spécifié, il s'agit d'un port générique qui peut aussi être spécifié + comme *. Le port générique correspond à toutes les + valeurs de port.

+ +

(Il ne faut pas confondre les numéros de port sur lesquels Apache + est en écoute avec les numéros de port spécifiés dans la directive + VirtualHost ; ces derniers ne servent qu'à définir le + serveur virtuel qui sera sélectionné pour traiter la + requête. Pour définir les ports sur lesquels Apache est en écoute, + utilisez la directive Listen). +

+ +

L'ensemble des adresses (y compris les résultats multiples + A issus des requêtes DNS) est appelé jeu + d'adresses du serveur virtuel.

+ +

Apache fait automatiquement sa sélection à partir de l'en-tête + HTTP Host fourni par le client, lorsque la + correspondance la plus exacte du point de vue adresse IP/port a lieu + pour plusieurs serveurs virtuels.

+ +

La directive ServerName peut + apparaître en quelque endroit de la définition d'un serveur. + Cependant, chaque occurrence écrase la précédente (pour ce serveur). + Si aucune directive ServerName n'est spécifiée, le + serveur tente de déterminer le nom du serveur à partir de l'adresse + IP.

+ +

Le premier serveur virtuel à base de nom apparaissant dans le + fichier de configuration pour une paire IP:port donnée est + significatif car c'est lui qui sera utilisé pour toutes les requêtes + reçues sur cette adresse IP/port et pour laquelle aucun autre + serveur virtuel ne possède un ServerName ou un ServerAlias + correspondant. Il sera aussi utilisé pour toutes les connexions SSL + si le serveur ne supporte pas l'Indication du nom du serveur.

+ +

Tous les noms spécifiés au sein d'une section + VirtualHost sont traités comme un + ServerAlias (sans caractères génériques), mais ne sont + écrasés par aucune directive ServerAlias.

+ +

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

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

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.

+ +
top
+
+

Choix du serveur virtuel

+ +

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

+ +

Recherche de l'adresse IP

+ +

Lors d'une première connexion sur une adresse/port, le serveur + recherche toutes les directives VirtualHost qui + possèdent la même adresse IP/port.

+ +

S'il n'y a aucune correspondance exacte pour cette adresse/port, + la recherche s'effectue sur la valeur générique (*).

+ +

Si aucune correspondance n'est enfin trouvée, la requête sera + servie par le serveur principal.

+ +

S'il existe des définitions VirtualHost pour + l'adresse IP, l'étape suivante consiste à déterminer si nous avons à + faire à un serveur virtuel à base de nom ou d'adresse IP.

+ + + +

Serveur virtuel par IP

+ +

Si une seule section VirtualHost présente la + meilleure correspondance avec la paire adresse IP/port, aucune + action n'est entreprise et la requête est + traitée par le serveur virtuel qui correspond.

+ + + +

Serveur virtuel par nom

+ +

Si plusieurs sections VirtualHost présentent la + meilleure correspondance avec la paire adresse IP/port, le terme + "liste" dans les étapes suivantes fait référence à la liste des + serveurs virtuels qui correspondent, selon l'ordre dans lequel ils + apparaissent dans le fichier de configuration.

+ +

Si la connexion utilise SSL, si le serveur supporte l'Indication de nom de serveur, + et si la négociation du client SSL inclut l'extension TLS dans le + nom d'hôte requis, alors ce nom d'hôte sera utilisé par la suite, tout + comme un en-tête Host: aurait été utilisé dans le cas + d'une connexion non-SSL. Si ces conditions ne sont pas réunies, le + premier serveur virtuel à base de nom dont l'adresse correspond sera + utilisé pour les connexions SSL. Ceci est important car c'est le + serveur virtuel qui détermine quel certificat le serveur va utiliser + pour la connexion.

+ +

Si la requête contient un en-tête Host:, on + recherche dans la liste le premier serveur virtuel dont le + ServerName ou le ServerAlias correspond, + et c'est celui-ci qui va traiter la requête. Un en-tête + Host: peut comporter un numéro de port mais Apache + l'ignore systématiquement et utilise toujours le + port sur lequel il a effectivement reçu la requête.

+ +

Le premier serveur virtuel du fichier de configuration qui + possède l'adresse spécifiée est prioritaire et intercepte toutes les + requêtes à destination d'un nom de serveur inconnu, ou toute requête + sans en-tête Host: (comme les requêtes HTTP/1.0).

+ + + +

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

+ +
    +
  • La sélection d'un serveur virtuel en fonction de son nom est + un processus qui intervient après la sélection par le serveur du + serveur virtuel qui correspond le mieux du point de vue adresse + IP/port.
  • + +
  • Si vous ne tenez pas compte de l'adresse IP à laquelle le + client s'est connecté, indiquez un caractère "*" comme adresse + pour tous les serveurs virtuels, et la sélection du serveur + virtuel en fonction du nom s'appliquera alors à tous les serveurs + virtuels définis.
  • + +
  • Les vérifications sur ServerName et + ServerAlias ne sont jamais + réalisées pour les serveurs virtuels par IP.
  • + +
  • 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.
  • + +
  • Le numéro de port contenu dans l'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 deux serveurs virtuels partagent la même adresse, la + sélection se fera implicitement sur le nom. Il s'agit d'une + nouvelle fonctionnalité de la version 2.3.11.
  • + +
  • Le serveur principal ne sert 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 *). 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).
  • + +
  • 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.
  • +
+ + +
top
+
+

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 de tous les + serveurs virtuels.)
  • + +
+ +
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/details.html.ko.euc-kr b/docs/manual/vhosts/details.html.ko.euc-kr new file mode 100644 index 0000000..ca5088a --- /dev/null +++ b/docs/manual/vhosts/details.html.ko.euc-kr @@ -0,0 +1,412 @@ + + + + + +ȣƮ ã⿡ ڼ - Apache HTTP Server Version 2.4 + + + + + + + +
<-
+

ȣƮ ã⿡ ڼ

+
+

:  en  | + fr  | + ko  | + tr 

+
+
ֽ ƴմϴ. + ֱٿ ϼ.
+ + +

ȣƮ ڵ ġ 1.3 ٽ + ۼǾ. ġ û  ȣƮ + ϴ Ѵ. ο NameVirtualHost þ Ͽ + ȣƮ 1.3 .

+ +

 ϴ ʰ ϰԸ + ϰ ʹٸ, ϶.

+ +
+ +
top
+
+

б

+ +

<VirtualHost> + ּ . <VirtualHost> + κ ȣƮ θ.

+ +

Listen, + ServerName, + ServerPath, + ServerAlias þ + ִ. ׷ þ + ( ) þ ȿϴ.

+ +

ּ Listen ⺻ 80̴. ּ + ServerPath ServerAlias + ⺻ . ServerName ⺻ + IP ̴ּ.

+ +

ּ Listen þ ΰ Ѵ. ù° + ġ ⺻ Ʈ Ʈ ϴ ̴. ° + ̷ URI Ʈ ȣ ϴ ̴.

+ +

ּ ޸ ȣƮ Ʈ ġ ٸ + Ʈ ʴ´.

+ +

VirtualHost þ Ʈ ִ. + Ʈ ּ ֱ Listen + Ѵ. Ư Ʈ *  Ʈ + Īϴ ϵī̴. (DNS ˻ A + ڵ带 Ͽ) ȣƮ ּҸ ĪϿ ȣƮ + ּ(address set)̶ θ.

+ +

Ư IP ּҿ NameVirtualHost þ ٸ + ּҸ ϴ ù° ȣƮ IP ȣƮ Ѵ. + IP ּҿ ϵī * ִ.

+ +

̸ ȣƮ Ѵٸ ̸ ȣƮ + IP ּҸ NameVirtualHost þ + ؾ Ѵ. , NameVirtualHost + þ ̸ ȣƮ ȣƮ(CNAME) شϴ + IP ּҸ ؾ Ѵ.

+ +

Ư IP:Ʈ ֿ NameVirtualHost + þ Ѵٸ, NameVirtualHost þ + VirtualHost þ  ִ.

+ +

NameVirtualHost VirtualHost + þ ߿ ʱ⶧ ( + ּտ VirtualHost + ߿ϴ. Ʒ ):

+ + + + +

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

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

+ + +

( б ϴ.)

+ +

VirtualHost þ , ȣƮ + VirtualHost þ Ʈ ⺻ + Listen Ѵ.

+ +

VirtualHost þ ̸ + ּտ Ѵٸ ServerAlias Ѵ + (׷ ٸ ServerAlias ʴ´). + ȣƮ ߰ Listen ּ + Ʈ ϶.

+ +

Ҷ IP ּ ؽ̺ ߰Ѵ. + NameVirtualHost þ IP ּҸ ϸ + IP ּҿ ̸ ȣƮ Ѵ. + ּҿ ȣƮ ٸ NameVirtualHost + þ ϰ α׿ Ѵ. IP ȣƮ + ؽ̺ ߰ ʴ´.

+ +

ؽԼ ϱ⶧ û IP ּҸ ؽϴ + δ . ؽ̺ IP ּ κ + ̿ ȭִ.

+ +

ȣƮ ⺻ ȴ. Ư:

+ +
    +
  1. ȣƮ ServerAdmin, + ResourceConfig, + AccessConfig, + Timeout, + KeepAliveTimeout, + KeepAlive, + MaxKeepAliveRequests, + SendBufferSize + þ ٸ ּ ش ´. (, + ּ Ѵ.)
  2. + +
  3. ȣƮ 丮 ⺻ ϴ " + ⺻(lookup defaults)" ּ . + 丮 (per-directory configuration) + ⿡ شȴ.
  4. + +
  5. (per-server config) ּ + ȣƮ ģ.
  6. +
+ +

⺻ ּ ȣƮ "⺻" Ȥ "" + ȴ. ׷ Ͽ ּ ϴ ġ . + ġ ּ оδ. + ׷ ּ ǰ ȣƮ ڿ ͵ ȣƮ + ǿ ش.

+ +

ּ ServerName ٸ ϴ + ǻ ȣƮ Ѵ. ּ + ServerName DNS ̻Ͽ IP ּҵ + ּ ̶ּ θ.

+ +

̸ ȣƮ ServerName + ȣƮ ϴ VirtualHost + ó ּҸ ⺻ Ѵ.

+ +

Ư _default_ Ʈī带 ϴ + ȣƮ ּ ServerName .

+ +
top
+
+

ȣƮ ã

+ +

Ʒ  ȣƮ û + ó Ѵ:

+ +

ؽ̺ ã

+ +

Ŭ̾Ʈ ó ϸ IP ּҸ IP + ؽ̺ ã´.

+ +

IP ּҸ ã Ŭ̾Ʈ û Ʈ + شϴ ȣƮ ִٸ, _default_ ȣƮ + û Ѵ. _default_ ȣƮ + ٸ ּ û Ѵ.

+ +

ؽ̺ IP ּҰ Ʈ ȣ + NameVirtualHost * ش ִ. + ̸ ȣƮó óѴ.

+ +

ãҴٸ (Ͽ IP ּҿ شϴ ׸ ã), + IP ȣƮ ̸ ȣƮ Ѵ.

+ + + +

IP ȣƮ

+ +

ã ׸ ̸ ٸ IP ȣƮ̴. + ̻ ۾ ʿ, ȣƮ û óѴ.

+ + + +

̸ ȣƮ

+ +

̸ Ͽ Ѱ ̻ ȣƮ ԵǸ + ̸ ȣƮ̴. Ͽ ȣƮ + VirtualHost ġѴ.

+ +

Ͽ ù° ȣƮ(Ͽ ش IP ּҸ + ϴ ù° ȣƮ) 켱 , + ų Host: û + óѴ.

+ +

Ŭ̾Ʈ Host: ָ, Ͽ + ù° ServerName̳ + ServerAlias ϴ ȣƮ û + Ѵ. Host: Ʈ ȣ + , ġ ׻ Ŭ̾Ʈ û Ʈ + ã´.

+ +

Ŭ̾Ʈ Host: HTTP/1.0 û + ϸ Ŭ̾Ʈ  Ϸ ⶧ + û URI شϴ ServerPath ִ ã´. + Ͽ ã θ ϰ, ȣƮ + û Ѵ.

+ +

ϴ ȣƮ ã ٸ, (̹ տ ߵ) + Ŭ̾Ʈ IP Ͽ ġϴ Ʈ ȣ + ϴ ù° ȣƮ û Ѵ.

+ + + +

+ +

IP ѵ Ư TCP/IP Ǵ ѹ + ã, ̸ KeepAlive/ ᵿ û + ã´. , Ŭ̾Ʈ ᵿ ̸ + ȣƮ û ִ.

+ + + +

URI

+ +

û URI URḬ Ŭ̾Ʈ û + ȣƮ Ʈ ּ Ư ȣƮ شϸ, + ּ Ȥ ȣƮ URI Ŵ/ȣƮ/Ʈ + κ URI Ѵ. شϴ + ּ ȣƮ ٸ URI ״ ΰ û + Ͻ û óѴ.

+ + +

+ +
    +
  • ̸ ȣƮ IP ȣƮ ο + ʴ´. IP ȣƮ ڽ ̸ + IP ּҿܿ  ּҷε . ̸ + ȣƮ . ̸ ȣƮ + NameVirtualHost þ ּ + IP ּҸ ؼ ִ.
  • + +
  • IP ȣƮ ServerAlias + ServerPath ˻ ʴ´.
  • + +
  • Ͽ ̸ ȣƮ, IP ȣƮ, + _default_ ȣƮ, NameVirtualHost + þ ߿ ʴ. Ư ּտ + ̸ ȣƮ ߿ϴ. Ͽ + տ ̸ ȣƮ ڽ ּտ + 켱 .
  • + +
  • Host: Ե Ʈ + ȣ ʴ´. ġ ׻ Ŭ̾Ʈ + û Ʈ Ѵ.
  • + +
  • ( ̸ Host: ٰ + ϸ,) ServerPath þ Ͽ + ڿ ٸ ServerPath þ պκ + Īϴ ׻ տ þ Ѵ.
  • + +
  • IP ȣƮ ּҸ , ׻ + Ͽ տ ȣƮ Ѵ. ̷ + ƹ 𸣰 Ͼ ִ. ̷ Ȳ ߰ϸ + αϿ Ѵ.
  • + +
  • _default_ ȣƮ û IP ּ + Ʈ ȣ شϴ ȣƮ û óѴ. + Ŭ̾Ʈ û Ʈ ȣ _default_ + ȣƮ Ʈ ȣ(⺻ Listen) + û óѴ.  Ʈ û̶ + ( , _default_:*) ϵī + Ʈ ִ. NameVirtualHost * + ȣƮ .
  • + +
  • ּ Ŭ̾Ʈ IP ּҿ Ʈ ȣ + شϴ (_default_ ȣƮ Ͽ) + ȣƮ û Ѵ. , ּ + ( Ʈ شϴ _default_ ȣƮ + ٸ) ּ/Ʈ ֿ û óѴ.
  • + +
  • Ŭ̾Ʈ ( , NameVirtualHost + þ) ̸ ȣƮ ּ( Ʈ) + Host: ų + û û _default_ + ȣƮ ּ ó ʴ´.
  • + +
  • Ҷ DNS + VirtualHost þ DNS ̸ . + Դٰ DNS ʴ´ٸ + Ȼ 赵 ִ. ̿ ִ.
  • + +
  • ȣƮ ServerName ׻ + ؾ Ѵ. ȱ׷ ȣƮ DNS ã ȴ.
  • +
+ + +
top
+
+

+ +

DNS + ߰ Ʒ ִ:

+ +
    +
  • ּ Ǹ VirtualHost տ + ξ. (׷ б ϴ. ȱ׷ ߿ + ȣƮ ̿ ǰ ȣƮ + ֱ⶧ ȥ.)
  • + +
  • б ϵ شϴ NameVirtualHost + VirtualHost ǵ .
  • + +
  • ServerPath ٸ ServerPath + պκ Īϴ 츦 ϶. ٸ Ͽ + պκ ( ڼ) ȣƮ ª ( ڼ) + ȣƮ տ ξ. ( , + "ServerPath /abc" "ServerPath /abc/def" ξ + Ѵ.
  • +
+ +
+
+

:  en  | + fr  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/details.html.tr.utf8 b/docs/manual/vhosts/details.html.tr.utf8 new file mode 100644 index 0000000..ef4297d --- /dev/null +++ b/docs/manual/vhosts/details.html.tr.utf8 @@ -0,0 +1,319 @@ + + + + + +Sanal Konak Eşlemenin Derinliğine İncelenmesi - Apache HTTP Sunucusu Sürüm 2.4 + + + + + + + +
<-
+

Sanal Konak Eşlemenin Derinliğine İncelenmesi

+
+

Mevcut Diller:  en  | + fr  | + ko  | + tr 

+
+ + +

Bu belgede, bir istek aldığında Apache’nin hangi sanal konak + ile hizmet sunacağına nasıl karar verdiği açıklanmaya çalışılmıştır.

+ +

Çoğu kullanıcı hangi türü kullanacağına karar vermek için önce İsme dayalı ve IP’ye dayalı Sanal + Konak bölümünü, sonra İsme Dayalı Sanal + Konak Desteği veya IP’ye Dayalı Sanal Konak + Desteği belgesini okumalı ve bazı + örneklere göz atmalıdır.

+ +

Bunlardan sonra tüm ayrıntıları anlamak isterseniz tekrar bu sayfaya + gelebilirsiniz.

+ +
+ +
top
+
+

Yapılandırma Dosyası

+ +

Bu belgede <VirtualHost> bölümleri dışında kalan + tanımlardan bahsederken ana_sunucu diyeceğiz.

+ +

<VirtualHost> + bölümlerindeki tanımlamalardan bahsederken sankonlar + diyeceğiz.

+ +

Her VirtualHost bölümü en az bir adres ve isteğe bağlı + portlar içerir.

+ +

Sanal konak tanımlarının içindeki IP adreslerinin yerine konak isimleri + kullanılabilir, fakat bunlar başlatma sırasında çözümleneceklerinden + çözümlemedeki bir başarısızlık bu sanal konak tanımlarının yoksayılması + ile sonuçlanacaktır. Bu bakımdan önerilmez.

+ +

VirtualHost yönergesinde görünen her adresin seçimlik bir + portu olabilir. Eğer bir port belirtilmemişse, port olarak * + belirtilmiş gibi bütün portlar dinlenir.

+ +

(VirtualHost yönergesinde belirtilen port numaraları Apache + httpd'nin dinleyeceği port numaraları olarak yorumlanmaz, sadece bir + isteği işleme sokarken hangi VirtualHost bölümünün + seçileceğini belirlerler. Sunucunun dinleyeceği adresleri ve portları + belirtmek için Listen + yönergesini kullanın.)

+ +

Adreslerin tamamını (DNS sorgularındaki çoklu sonuçlar dahil) içeren + kümeye sankonların adres kümesi denir.

+ +

Apache httpd, bir IP adresi ve port birleşimi için en belirgin + eşleşmelerin listelendiği çok sayıdaki sanal konak arasında ayırdedici + olarak istemci tarafından sağlanan HTTP Host başlığını + kullanır.

+ +

ServerName yönergesi sunucu + tanımının içinde herhangi bir yerde görünebilirse de her göründüğü yerde + bir öncekini iptal eder. Hiç ServerName belirtilmemişse, + Apache httpd, sunucu ismini sunucunun IP adresinden saptamaya + çalışır.

+ +

Belli bir IP adresi ve port çifti için yapılandırma dosyasındaki ilk + isme dayalı sankon önemlidir, çünkü başka hiçbir sankonun ServerName veya + ServerAlias yönergesi ile eşleşmeyen bu adres ve port çifti için alınmış + tüm isteklerde bu sankon kullanılır. Ayrıca, sunucunun Sunucu İsmi Belirtimini + desteklemediği durumlarda tüm SSL bağlantıları için bu sankon + kullanılır.

+ +

VirtualHost içindeki isimlerin sırası (jokersiz) bir + ServerAlias gibi ele alınır (fakat hiçbir + ServerAlias yönergesi ile geçersiz kılınmaz).

+ +

Her sankon için bazı değerler öntanımlı olarak atanır. Bunların + başlıcaları:

+ +
    +
  1. Sankon bir ServerAdmin + yönergesi içermiyorsa, + Timeout, + KeepAliveTimeout, + KeepAlive, + MaxKeepAliveRequests, + ReceiveBufferSize ve + SendBufferSize yönergeleri için + öntanımlı değerler ana_sunucudaki eşdeğerlerinden miras alınır. (Yani, + bu yönergeler için ana_sunucudaki son değerler miras alınır.)
  2. + +
  3. Sankon için öntanımlı dizin erişim izinlerinin tanımlandığı "arama + öntanımlıları" ana_sunucununkilere katılır. Buna her modülün dizinlere + özgü yapılandırma bilgileri dahildir.
  4. + +
  5. Her modülün ana_sunucudaki sunuculara özgü yapılandırmaları sankon + sunucusununkilerle katıştırılır.
  6. +
+ +

Esasen, ana_sunucu, sankon sunucularını oluştururken bir öntanımlılar + listesi veya öntanımlı değerlere dayanak noktası olarak ele alınır. + Fakat bu ana_sunucu tanımlarının yapılandırma dosyasındaki yerlerinin + saptanmasının konumuzla ilgisi yoktur; ana_sunucu yapılandırmasının + tamamı son katıştırma yapılacağı zaman çözümlenir. Bu bakımdan, + ana_sunucu tanımlarından bir kısmı sankon tanımlarından sonra yer alsa + bile sankon tanımlarında etkili olabilir.

+ +

Eğer, bu noktada ana_sunucu hiçbir ServerName satırı + içermiyorsa httpd programının çalıştığı makinenin + konak ismi öntanımlıdır. Ana_sunucunun ServerName için + yaptığı DNS sorgusundan dönen IP adreslerine ana_sunucu adres + kümesi diyoruz.

+ +

Tanımsız ServerName alanları için bir isme dayalı sankon, + sankonu tanımlayan VirtualHost yönergesinde belirtilen ilk + adresi öntanımlı değer kabul eder.

+ +

Sihirli _default_ sankonları için ana_sunucunun + ServerName değeri kullanılır.

+ +
top
+
+

Sanal Konağın Belirlenmesi

+ +

Sunucu bir istek durumunda hangi sankonun kullanılacağını şöyle + belirler:

+ +

IP adresi aranır

+ +

Bir adres ve port için bağlantı ilk alındığında Apache httpd tüm + VirtualHost tanımlarında bu çifti arar.

+ +

Arama başarısız olursa * (herşey) eşleşmelerine + bakılır.

+ +

Bir eşleşme bulunamazsa hizmet ana sunucudan sunulur.

+ +

Arama sonucunda bu IP adresi için bulunmuş VirtualHost + tanımları varsa sonraki adım hizmetin bir IP’ye dayalı sankondan mı yoksa + isme dayalı bir sankondan mı sunulacağına karar vermektir.

+ + + +

IP’ye dayalı sankon

+ +

Eğer en iyi eşleşme olarak saptanmış IP adresi ve port çiftini içeren + sadece bir VirtualHost yönergesi varsa artık karar vermek + için başka bir şey yapmaya gerek yoktur ve istek bu sankondan + sunulur.

+ + + +

İsme dayalı sankon

+ +

Eğer en iyi eşleşme olarak saptanmış IP adresi ve port çiftini içeren + birden fazla VirtualHost yönergesi varsa, sonraki + adımlardaki "liste" eşleşen sankonların listesi olup sankonlar listede + yapılandırma dosyasındaki yerlerine göre sıralanırlar.

+ +

Bağlantı SSL kullanıyorsa, sunucunun Sunucu İsmi Belirtimini + desteklediği durumlarda SSL istemci uzlaşımı, istenen konak ismiyle + birlikte TLS eklentisini de içeriyorsa, konak ismi, SSL olmayan + bağlantılardaki Host: başlığı kullanımına benzer şekilde + aşağıdaki gibi kullanılır. Aksi takdirde, SSL bağlantıları için adresin + eşleştiği ilk isme dayalı sankon kullanılır. Sunucunun bağlantı için + hangi sertifikayı kullanacağını sankon belirlediği için bu önemlidir.

+ +

İstek bir Host: başlık alanı içeriyorsa, listede + ServerName veya ServerAlias alanı başlık alanı + ile eşleşen ilk sankona bakılır. Host: alanı bir port + içerebilirse de Apache httpd bunu yoksayarak daima istemcinin isteği + gönderdiği portu gerçek port kabul eder.

+ +

Yapılandırma dosyasındaki belirtilen IP adresiyle eşleşen ilk sankon en + yüksek önceliğe sahiptir ve sunucu ismi bilinmeyen ve (bir HTTP/1.0 + isteği gibi) Host: başlık alanı içermeyen istekleri de + yakalar.

+ + + +

Kalıcı bağlantılar

+ +

Yukarıda açıklanan IP araması belli bir TCP/IP oturumunda + bir defaya mahsus yapıldığı halde bir kalıcı/KeepAlive bağlantı + sırasında her istek için ayrı bir arama yapılır. Başka + bir deyişle, bir istemci tek bir kalıcı bağlantı üzerinde farklı isme + dayalı sankonlardan sayfa talebinde bulunabilir.

+ + + +

Mutlak URI

+ +

Eğer istekte belirtilen URI bir mutlak URI ise ve istek yapılan konak + ismi ve port ana sunucuyla veya sankonlardan biriyle eşleşiyorsa, + şema/konakadı/port öneki ayrılır ve elde edilen göreli URI ilgili + sankondan veya ana sunucudan sunulur. Eğer bir eşleşme sağlanamazsa + URI’ye dokunulmaz ve istek bir vekil isteği olarak ele alınır.

+ + +

İzlenimler

+ +
    +
  • İsme dayalı sanal konak işlemleri, sunucunun en iyi eşleşen IP'ye + dayalı sanal konağı seçmesinin ardından uygulanır.
  • + +
  • İstemcinin hangi IP adresine bağlandığını umursamıyorsanız, sanal + konaklarınızda adres olarak "*" kullanın, böylece yapılandırılmış + sankonların hepsine isme dayalı sanal konak işlemleri uygulanır.
  • + +
  • Bir IP’ye dayalı sankon için asla ServerAlias ve + ServerPath değerine bakılmaz.
  • + +
  • Sıralama sadece aynı IP adresine sahip isme dayalı sankonlar arasında + önemlidir. Aynı adres kümesine mensup isme dayalı sankonlardan + yapılandırma dosyasında ilk sırada yer alanı en yüksek önceliğe + sahiptir.
  • + +
  • Eşleştirme işlemi sırasında Host: + başlık alanında belirtilen port asla kullanılmaz. Apache httpd daima + istemcinin isteği gönderdiği gerçek portu kullanır.
  • + +
  • Eğer aynı IP adresine sahip IP’ye dayalı iki sankon varsa, bunlara + örtük olarak isme dayalı sanal konak işlemleri uygulanır. 2.3.11 + sürümünden beri yeni davranış şekli budur.
  • + +
  • Ana_sunucunun bir isteğe hizmet sunabilmesi için istemcinin + bağlandığı IP adresi ve port hiçbir yerde belirtilmemiş ve + hiçbir sankon ile eşleşme sağlanamamış olmalıdır. Başka bir deyişle, + istemcinin bağlandığı port ile eşleşen bir _default_ + sankon olmadıkça adres ve port belirtmeyen bir isteğe ana_sunucu yanıt + verecektir.
  • + +
  • VirtualHost yönergelerinde asla DNS isimleri + belirtmemelisiniz. Aksi takdirde sunucuyu başlatma sırasında DNS + sorgusu yapmaya zorlamış olursunuz. Listelenen tüm alanlar için DNS + üzerinde tam denetime sahip değilseniz bu ayrıca bir güvenlik + tehdidine yol açar. Bu konuda daha ayrıntılı bilgi edinmek için DNS ile ilgili konular ve Apache + belgesine bakınız.
  • + +
  • ServerName her sankon için ayrı ayrı belirlenmiş + olmalıdır. Aksi takdirde her sankon için bir DNS sorgusu gerekir.
  • +
+ + +
top
+
+

İpuçları

+ +

DNS konuları sayfasındaki + ipuçlarına ilaveten burada da bazı ipuçları bulacaksınız:

+ +
    +
  • Ana sunucu tanımlarının hepsini VirtualHost + tanımlarının öncesinde bitirin. Bu ayrıca yapılandırmanızın + okunabilirliğini de arttırır; VirtualHost tanımlarının + sonrasına sarkan yapılandırmaların katıştırılması işlemi tüm sanal + konakları etkileyebilen tanımlar bakımından bir + karışıklığa/belirsizliğe sebep olabilir.)
  • +
+ +
+
+

Mevcut Diller:  en  | + fr  | + ko  | + tr 

+
top

Yorumlar

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/examples.html b/docs/manual/vhosts/examples.html new file mode 100644 index 0000000..73b5188 --- /dev/null +++ b/docs/manual/vhosts/examples.html @@ -0,0 +1,21 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: examples.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: examples.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +URI: examples.html.ja.utf8 +Content-Language: ja +Content-type: text/html; charset=UTF-8 + +URI: examples.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR + +URI: examples.html.tr.utf8 +Content-Language: tr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/vhosts/examples.html.en b/docs/manual/vhosts/examples.html.en new file mode 100644 index 0000000..6c4f333 --- /dev/null +++ b/docs/manual/vhosts/examples.html.en @@ -0,0 +1,566 @@ + + + + + +VirtualHost Examples - Apache HTTP Server Version 2.4 + + + + + + + +
<-
+

VirtualHost Examples

+
+

Available Languages:  en  | + fr  | + ja  | + ko  | + tr 

+
+ + +

This document attempts to answer the commonly-asked questions about + setting up virtual hosts. These scenarios are those involving multiple + web sites running on a single server, via name-based or IP-based virtual hosts. +

+ +
+ +
top
+
+

Running several name-based web + sites on a single IP address.

+ +

Your server has multiple hostnames that resolve to a single address, + and you want to respond differently for www.example.com + and www.example.org.

+ +

Note

Creating virtual + host configurations on your Apache server does not magically + cause DNS entries to be created for those host names. You + must have the names in DNS, resolving to your IP + address, or nobody else will be able to see your web site. You + can put entries in your hosts file for local + testing, but that will work only from the machine with those + hosts entries.

+
+ +
# Ensure that Apache listens on port 80
+Listen 80
+<VirtualHost *:80>
+    DocumentRoot "/www/example1"
+    ServerName www.example.com
+
+    # Other directives here
+</VirtualHost>
+
+<VirtualHost *:80>
+    DocumentRoot "/www/example2"
+    ServerName www.example.org
+
+    # Other directives here
+</VirtualHost>
+ + +

The asterisks match all addresses, so the main server serves no + requests. Due to the fact that the virtual host with + ServerName www.example.com is first + in the configuration file, it has the highest priority and can be seen + as the default or primary server. That means + that if a request is received that does not match one of the specified + ServerName directives, it will be served by this first + <VirtualHost>.

+ +

The above configuration is what you will want to use in almost + all name-based virtual hosting situations. The only thing that this + configuration will not work for, in fact, is when you are serving + different content based on differing IP addresses or ports.

+ +
+

Note

+ +

You may replace * with a specific IP address + on the system. Such virtual hosts will only be used for + HTTP requests received on connection to the specified IP + address.

+ +

However, it is additionally useful to use * + on systems where the IP address is not predictable - for + example if you have a dynamic IP address with your ISP, and + you are using some variety of dynamic DNS solution. Since + * matches any IP address, this configuration + would work without changes whenever your IP address + changes.

+
+
top
+
+

Name-based hosts on more than one + IP address.

+ +
+

Note

+

Any of the techniques discussed here can be extended to any + number of IP addresses.

+
+ +

The server has two IP addresses. On one (172.20.30.40), we + will serve the "main" server, server.example.com and on the + other (172.20.30.50), we will serve two or more virtual hosts.

+ +
Listen 80
+
+# This is the "main" server running on 172.20.30.40
+ServerName server.example.com
+DocumentRoot "/www/mainserver"
+
+<VirtualHost 172.20.30.50>
+    DocumentRoot "/www/example1"
+    ServerName www.example.com
+
+    # Other directives here ...
+</VirtualHost>
+
+<VirtualHost 172.20.30.50>
+    DocumentRoot "/www/example2"
+    ServerName www.example.org
+
+    # Other directives here ...
+</VirtualHost>
+ + +

Any request to an address other than 172.20.30.50 will be + served from the main server. A request to 172.20.30.50 with an + unknown hostname, or no Host: header, will be served from + www.example.com.

+ +
top
+
+

Serving the same content on + different IP addresses (such as an internal and external + address).

+ +

The server machine has two IP addresses (192.168.1.1 + and 172.20.30.40). The machine is sitting between an + internal (intranet) network and an external (internet) network. Outside + of the network, the name server.example.com resolves to + the external address (172.20.30.40), but inside the + network, that same name resolves to the internal address + (192.168.1.1).

+ +

The server can be made to respond to internal and external requests + with the same content, with just one <VirtualHost> section.

+ +
<VirtualHost 192.168.1.1 172.20.30.40>
+    DocumentRoot "/www/server1"
+    ServerName server.example.com
+    ServerAlias server
+</VirtualHost>
+ + +

Now requests from both networks will be served from the same + <VirtualHost>.

+ +
+

Note:

On the internal + network, one can just use the name server rather + than the fully qualified host name + server.example.com.

+ +

Note also that, in the above example, you can replace the list + of IP addresses with *, which will cause the server to + respond the same on all addresses.

+
+ +
top
+
+

Running different sites on different + ports.

+ +

You have multiple domains going to the same IP and also want to + serve multiple ports. The example below illustrates that the name-matching + takes place after the best matching IP address and port combination + is determined.

+ +
Listen 80
+Listen 8080
+
+<VirtualHost 172.20.30.40:80>
+    ServerName www.example.com
+    DocumentRoot "/www/domain-80"
+</VirtualHost>
+
+<VirtualHost 172.20.30.40:8080>
+    ServerName www.example.com
+    DocumentRoot "/www/domain-8080"
+</VirtualHost>
+
+<VirtualHost 172.20.30.40:80>
+    ServerName www.example.org
+    DocumentRoot "/www/otherdomain-80"
+</VirtualHost>
+
+<VirtualHost 172.20.30.40:8080>
+    ServerName www.example.org
+    DocumentRoot "/www/otherdomain-8080"
+</VirtualHost>
+ + +
top
+
+

IP-based virtual hosting

+ +

The server has two IP addresses (172.20.30.40 and + 172.20.30.50) which resolve to the names + www.example.com and www.example.org + respectively.

+ +
Listen 80
+
+<VirtualHost 172.20.30.40>
+    DocumentRoot "/www/example1"
+    ServerName www.example.com
+</VirtualHost>
+
+<VirtualHost 172.20.30.50>
+    DocumentRoot "/www/example2"
+    ServerName www.example.org
+</VirtualHost>
+ + +

Requests for any address not specified in one of the + <VirtualHost> directives (such as + localhost, for example) will go to the main server, if + there is one.

+ +
top
+
+

Mixed port-based and ip-based virtual + hosts

+ +

The server machine has two IP addresses (172.20.30.40 and + 172.20.30.50) which resolve to the names + www.example.com and www.example.org + respectively. In each case, we want to run hosts on ports 80 and + 8080.

+ +
Listen 172.20.30.40:80
+Listen 172.20.30.40:8080
+Listen 172.20.30.50:80
+Listen 172.20.30.50:8080
+
+<VirtualHost 172.20.30.40:80>
+    DocumentRoot "/www/example1-80"
+    ServerName www.example.com
+</VirtualHost>
+
+<VirtualHost 172.20.30.40:8080>
+    DocumentRoot "/www/example1-8080"
+    ServerName www.example.com
+</VirtualHost>
+
+<VirtualHost 172.20.30.50:80>
+    DocumentRoot "/www/example2-80"
+    ServerName www.example.org
+</VirtualHost>
+
+<VirtualHost 172.20.30.50:8080>
+    DocumentRoot "/www/example2-8080"
+    ServerName www.example.org
+</VirtualHost>
+ + +
top
+
+

Mixed name-based and IP-based + vhosts

+ +

Any address mentioned in the argument to a virtualhost that never + appears in another virtual host is a strictly IP-based virtual host.

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

Using Virtual_host and + mod_proxy together

+ +

The following example allows a front-end machine to proxy a + virtual host through to a server running on another machine. In the + example, a virtual host of the same name is configured on a machine + at 192.168.111.2. The ProxyPreserveHost + On directive is used so that the desired hostname is + passed through, in case we are proxying multiple hostnames to a + single machine.

+ +
<VirtualHost *:*>
+    ProxyPreserveHost On
+    ProxyPass        "/" "http://192.168.111.2/"
+    ProxyPassReverse "/" "http://192.168.111.2/"
+    ServerName hostname.example.com
+</VirtualHost>
+ + +
top
+
+

Using _default_ + vhosts

+ +

_default_ vhosts + for all ports

+ +

Catching every request to any unspecified IP address and + port, i.e., an address/port combination that is not used for + any other virtual host.

+ +
<VirtualHost _default_:*>
+    DocumentRoot "/www/default"
+</VirtualHost>
+ + +

Using such a default vhost with a wildcard port effectively prevents + any request going to the main server.

+ +

A default vhost never serves a request that was sent to an + address/port that is used for name-based vhosts. If the request + contained an unknown or no Host: header it is always + served from the primary name-based vhost (the vhost for that + address/port appearing first in the configuration file).

+ +

You can use AliasMatch or + RewriteRule to rewrite any + request to a single information page (or script).

+ + +

_default_ vhosts + for different ports

+ +

Same as setup 1, but the server listens on several ports and we want + to use a second _default_ vhost for port 80.

+ +
<VirtualHost _default_:80>
+    DocumentRoot "/www/default80"
+    # ...
+</VirtualHost>
+
+<VirtualHost _default_:*>
+    DocumentRoot "/www/default"
+    # ...
+</VirtualHost>
+ + +

The default vhost for port 80 (which must appear before any + default vhost with a wildcard port) catches all requests that were sent + to an unspecified IP address. The main server is never used to serve a + request.

+ + +

_default_ vhosts + for one port

+ +

We want to have a default vhost for port 80, but no other default + vhosts.

+ +
<VirtualHost _default_:80>
+    DocumentRoot "/www/default"
+...
+</VirtualHost>
+ + +

A request to an unspecified address on port 80 is served from the + default vhost. Any other request to an unspecified address and port is + served from the main server.

+ +

Any use of * in a virtual host declaration will have + higher precedence than _default_.

+ + + +
top
+
+

Migrating a name-based vhost to an + IP-based vhost

+ +

The name-based vhost with the hostname + www.example.org (from our name-based example, setup 2) should get its own IP + address. To avoid problems with name servers or proxies who cached the + old IP address for the name-based vhost we want to provide both + variants during a migration phase.

+ +

+ The solution is easy, because we can simply add the new IP address + (172.20.30.50) to the VirtualHost + directive.

+ +
Listen 80
+ServerName www.example.com
+DocumentRoot "/www/example1"
+
+<VirtualHost 172.20.30.40 172.20.30.50>
+    DocumentRoot "/www/example2"
+    ServerName www.example.org
+    # ...
+</VirtualHost>
+
+<VirtualHost 172.20.30.40>
+    DocumentRoot "/www/example3"
+    ServerName www.example.net
+    ServerAlias *.example.net
+    # ...
+</VirtualHost>
+ + +

The vhost can now be accessed through the new address (as an + IP-based vhost) and through the old address (as a name-based + vhost).

+ +
top
+
+

Using the ServerPath + directive

+ +

We have a server with two name-based vhosts. In order to match the + correct virtual host a client must send the correct Host: + header. Old HTTP/1.0 clients do not send such a header and Apache has + no clue what vhost the client tried to reach (and serves the request + from the primary vhost). To provide as much backward compatibility as + possible we create a primary vhost which returns a single page + containing links with an URL prefix to the name-based virtual + hosts.

+ +
<VirtualHost 172.20.30.40>
+    # primary vhost
+    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>
+ + +

Due to the ServerPath + directive a request to the URL + http://www.sub1.domain.tld/sub1/ is always served + from the sub1-vhost.
A request to the URL + http://www.sub1.domain.tld/ is only + served from the sub1-vhost if the client sent a correct + Host: header. If no Host: header is sent the + client gets the information page from the primary host.

+ +

Please note that there is one oddity: A request to + http://www.sub2.domain.tld/sub1/ is also served from the + sub1-vhost if the client sent no Host: header.

+ +

The RewriteRule directives + are used to make sure that a client which sent a correct + Host: header can use both URL variants, i.e., + with or without URL prefix.

+ +
+
+

Available Languages:  en  | + fr  | + ja  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/examples.html.fr.utf8 b/docs/manual/vhosts/examples.html.fr.utf8 new file mode 100644 index 0000000..f8851a7 --- /dev/null +++ b/docs/manual/vhosts/examples.html.fr.utf8 @@ -0,0 +1,586 @@ + + + + + +Exemples d'utilisations de VirtualHost - Serveur HTTP Apache Version 2.4 + + + + + + + +
<-
+

Exemples d'utilisations de VirtualHost

+
+

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

+
+ + +

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.

+ +
+ +
top
+
+

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

+ +

Votre serveur possède plusieurs noms d'hôte qui correspondent à une seule + adresse IP, et vous souhaitez des réponses différentes si on demande + www.example.com ou www.example.org.

+ +

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.

+
+ +
# Apache doit écouter sur le port 80
+Listen 80
+<VirtualHost *:80>
+    DocumentRoot "/www/example1"
+    ServerName www.example.com
+  
+    # Autres directives ici
+</VirtualHost>
+
+<VirtualHost *:80>
+    DocumentRoot "/www/example2"
+    ServerName www.example.org
+
+    # Autres directives ici
+</VirtualHost>
+ + + +

Les astérisques correspondent à toutes les adresses, si bien que + le serveur principal ne répondra jamais à aucune requête. Comme le + serveur virtuel + ServerName www.example.com se trouve en premier dans le fichier + de configuration, il a la plus grande priorité et peut être vu + comme serveur par défaut ou primaire ; + ce qui signifie que toute requête reçue ne correspondant à aucune + des directives ServerName sera servie par ce premier + <VirtualHost>.

+ +

La configuration ci-dessus correspond à ce que l'on souhaite pour + la plupart des serveurs virtuels à base de nom. Il faudra cependant + utiliser une configuration différente si vous souhaitez servir un + contenu différent en fonction de l'adresse IP ou du port.

+ +
+

Note :

+ +

Vous pouvez remplacer * + par une adresse IP du système. Le serveur virtuel concerné + ne sera alors sélectionné que pour les requêtes HTTP vers + cette adresse IP.

+ +

En général, il est commode d'utiliser * sur + les systèmes dont l'adresse IP n'est pas constante - par + exemple, pour des serveurs dont l'adresse IP est attribuée + dynamiquement par le FAI, et où le DNS est géré au moyen + d'un DNS dynamique quelconque. Comme * signifie + n'importe quelle adresse, cette configuration + fonctionne sans devoir être modifiée quand l'adresse IP du + système est modifiée.

+
+ +
top
+
+

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

+ +
Listen 80
+
+# Serveur "principal" sur 172.20.30.40
+ServerName server.example.com
+DocumentRoot "/www/mainserver"
+
+<VirtualHost 172.20.30.50>
+    DocumentRoot "/www/example1"
+    ServerName www.example.com
+    
+    # D'autres directives ici ...
+</VirtualHost>
+
+<VirtualHost 172.20.30.50>
+    DocumentRoot "/www/example2"
+    ServerName www.example.org
+    
+    # D'autres directives ici ...
+</VirtualHost>
+ + +

Toute requête arrivant sur une autre adresse que + 172.20.30.50 sera servie par le serveur principal. + Les requêtes vers 172.20.30.50 avec un nom de serveur + inconnu, ou sans en-tête Host:, seront servies par + www.example.com.

+ +
top
+
+

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

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

+
+ +
top
+
+

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. L'exemple + suivant montre que la sélection en fonction du nom intervient après + la sélection de la meilleure correspondance du point de vue adresse + IP/port.

+ +
Listen 80
+Listen 8080
+
+<VirtualHost 172.20.30.40:80>
+    ServerName www.example.com
+    DocumentRoot "/www/domain-80"
+</VirtualHost>
+
+<VirtualHost 172.20.30.40:8080>
+    ServerName www.example.com
+    DocumentRoot "/www/domain-8080"
+</VirtualHost>
+
+<VirtualHost 172.20.30.40:80>
+    ServerName www.example.org
+    DocumentRoot "/www/otherdomain-80"
+</VirtualHost>
+
+<VirtualHost 172.20.30.40:8080>
+    ServerName www.example.org
+    DocumentRoot "/www/otherdomain-8080"
+</VirtualHost>
+ + +
top
+
+

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.example.com et www.example.org.

+ +
Listen 80
+
+<VirtualHost 172.20.30.40>
+    DocumentRoot "/www/example1"
+    ServerName www.example.com
+</VirtualHost>
+
+<VirtualHost 172.20.30.50>
+    DocumentRoot "/www/example2"
+    ServerName www.example.org
+</VirtualHost>
+ + +

Les requêtes provenant d'adresses non spécifiées dans l'une des + directives <VirtualHost> (comme pour + localhost par exemple) seront dirigées vers le serveur + principal, s'il en existe un.

+ +
top
+
+

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.example.com et www.example.org. + Pour chacun d'eux, nous voulons un hébergement sur les ports 80 + et 8080.

+ +
Listen 172.20.30.40:80
+Listen 172.20.30.40:8080
+Listen 172.20.30.50:80
+Listen 172.20.30.50:8080
+
+<VirtualHost 172.20.30.40:80>
+    DocumentRoot "/www/example1-80"
+    ServerName www.example.com
+</VirtualHost>
+
+<VirtualHost 172.20.30.40:8080>
+    DocumentRoot "/www/example1-8080"
+    ServerName www.example.com
+</VirtualHost>
+
+<VirtualHost 172.20.30.50:80>
+    DocumentRoot "/www/example2-80"
+    ServerName www.example.org
+</VirtualHost>
+
+<VirtualHost 172.20.30.50:8080>
+    DocumentRoot "/www/example2-8080"
+    ServerName www.example.org
+</VirtualHost>
+ + +
top
+
+

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

+ +

Toute adresse indiquée comme argument d'une section VirtualHost + et n'apparaissant dans aucun autre serveur virtuel, fait de cette + section un serveur virtuel sélectionnable uniquement en fonction de + son adresse IP.

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

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

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.

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

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

+ +
<VirtualHost _default_:80>
+    DocumentRoot "/www/default"
+...
+</VirtualHost>
+ + +

Une requête vers une adresse non spécifiée sur le port 80 + sera servie par le serveur virtuel par défaut, et toute autre + requête vers une adresse et un port non spécifiés sera servie + par le serveur principal.

+ +

L'utilisation du caractère générique * dans la + déclaration d'un serveur virtuel l'emporte sur + _default_.

+ + +
top
+
+

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

+ +

Le serveur virtuel par nom avec le nom de domaine + www.example.org (de notre exemple + par nom) devrait obtenir sa propre adresse IP. Pendant la + phase de migration, il est possible d'éviter les problèmes avec + les noms de serveurs et autres serveurs mandataires qui mémorisent + les vielles adresses IP pour les serveurs virtuels par nom.
+ La solution est simple, car il suffit d'ajouter la nouvelle + adresse IP (172.20.30.50) dans la directive + VirtualHost.

+ +
Listen 80
+ServerName www.example.com
+DocumentRoot "/www/example1"
+
+<VirtualHost 172.20.30.40 172.20.30.50>
+    DocumentRoot "/www/example2"
+    ServerName www.example.org
+    # ...
+</VirtualHost>
+
+<VirtualHost 172.20.30.40>
+    DocumentRoot "/www/example3"
+    ServerName www.example.net
+    ServerAlias *.example.net
+    # ...
+</VirtualHost>
+ + +

Le serveur virtuel peut maintenant être joint par la nouvelle + adresse (comme un serveur virtuel par IP) et par l'ancienne + adresse (comme un serveur virtuel par nom).

+ +
top
+
+

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.

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/examples.html.ja.utf8 b/docs/manual/vhosts/examples.html.ja.utf8 new file mode 100644 index 0000000..7c31f0e --- /dev/null +++ b/docs/manual/vhosts/examples.html.ja.utf8 @@ -0,0 +1,680 @@ + + + + + +バーチャルホストの例 - Apache HTTP サーバ バージョン 2.4 + + + + + + + +
<-
+

バーチャルホストの例

+
+

翻訳済み言語:  en  | + fr  | + ja  | + ko  | + tr 

+
+
この日本語訳はすでに古くなっている + 可能性があります。 + 最近更新された内容を見るには英語版をご覧下さい。 +
+ + +

この文書は、バーチャルホストの設定の際に + よくある質問に答えるものです。想定している対象は 名前ベースIP ベース のバーチャルホストを使って + 一つのサーバで複数のウェブサイトを運用している状況です。 +

+ +
+ +
top
+
+

一つの IP アドレスでいくつかの名前ベースの + ウェブサイトを実行する

+ +

サーバは IP アドレスを一つ割り当てられていて、DNS でマシンに + 複数の名前 (CNAME) が指定されています。このマシンで + www.example.comwww.example.org + のためのウェブサーバを実行させたいとします。

+ +

+ Apache サーバの設定でバーチャルホストの設定をしただけで、 + 知らない間にそのホスト名に対応する DNS のエントリが + 作成されたりはしません。そのサーバの IP アドレスに解決される + ように DNS に名前を登録しなければなりません。 + そうでないと誰もあなたのウェブサイトを見ることはできません。 + ローカルでのテストのために hosts ファイルに + エントリを追加することもできますが、この場合はその + hosts エントリのあるマシンからしか動作しません。

+
+ +

サーバ設定

+ + + # Ensure that Apache listens on port 80
+ Listen 80
+
+ # Listen for virtual host requests on all IP addresses
+ NameVirtualHost *:80
+
+ <VirtualHost *:80>
+ + DocumentRoot /www/example1
+ ServerName www.example.com
+
+ # Other directives here
+
+
+ </VirtualHost>
+
+ <VirtualHost *:80>
+ + DocumentRoot /www/example2
+ ServerName www.example.org
+
+ # Other directives here
+
+
+ </VirtualHost> +

+ +

アスタリスクはすべてのアドレスにマッチしますので、主サーバは + リクエストを扱いません。www.example.com は + 最初にあるため、優先順位は一番高くなり、default もしくは + primary のサーバと考えることができます。つまり、リクエストが + どの ServerName ディレクティブにもマッチしない場合、 + 一番最初の VirtualHost により扱われます。

+ +

+ +

* をシステムの実際の IP アドレスに置き換える + こともできます。その場合は VirtualHost の引数は + NameVirtualHost の引数と同じにしなければなりません + :

+ +

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

+ +

しかし、IP アドレスが予測不可能なシステム + ――例えばプロバイダから動的に IP アドレスを取得して何らかの + ダイナミック DNS を使っている場合など――においては、* + 指定はさらに便利です。* はすべての IP アドレスに + マッチしますので、この設定にしておけば IP アドレスが変更されても + 設定変更せずに動作します。

+
+ +

名前ベースのバーチャルホスティングではほぼすべての状況で、 + 上記の設定で希望の設定になっていることでしょう。 + 実際この設定が動作しないのは、IP アドレスやポートの違いによって + 違うコンテンツを送るときだけです。

+ +
top
+
+

複数の IP アドレスのあるホストで名前ベースの + ホスティングを行なう

+ +
+

ここで説明されている方法は IP アドレスが + 何個あっても同様にできます。

+
+ +

サーバには二つ IP アドレスがついています。一つ目 + (172.20.30.40) では主サーバ + server.domain.com を扱い、もう一方 + (172.20.30.50) では二つかそれ以上の数の + バーチャルホストを扱います。

+ +

サーバの設定

+ + + Listen 80
+
+ # This is the "main" server running on 172.20.30.40
+ ServerName server.domain.com
+ DocumentRoot /www/mainserver
+
+ # This is the other address
+ NameVirtualHost 172.20.30.50
+
+ <VirtualHost 172.20.30.50>
+ + DocumentRoot /www/example1
+ ServerName www.example.com
+
+ # Other directives here ...
+
+
+ </VirtualHost>
+
+ <VirtualHost 172.20.30.50>
+ + DocumentRoot /www/example2
+ ServerName www.example.org
+
+ # Other directives here ...
+
+
+ </VirtualHost> +

+ +

172.20.30.50 以外のアドレスへのリクエストは主サーバ + が扱います。172.20.30.50 への、未知のホスト名または + Host: ヘッダなしのリクエストは www.example.com + が扱います。

+ +
top
+
+

違う IP アドレス (例えば、内部と外部アドレス) + で同じコンテンツを送る

+ +

サーバマシンは IP アドレスを二つ (192.168.1.1 + と 172.20.30.40) 持っています。このマシンは内部 + (イントラネット) と 外部 (インターネット) のネットワークの間に + あります。server.example.com はネットワークの外からは + 外部アドレス (172.20.30.40) として解決されますが、 + ネットワークの中からは内部アドレス (192.168.1.1) + として解決されます。

+ +

VirtualHost 一つだけでサーバが内部のリクエストと + 外部のリクエストの両方に同じコンテンツで応答するようにできます。

+ +

サーバの設定

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

+ +

これでどちらのネットワークからのリクエストも同じ VirtualHost + で扱われるようになります。

+ +

注:

内部ネットワークでは完全なホスト名の + server.example.com の代わりに、単に server + を使うことができます。

+ +

上の例では、IP アドレスのリストを、すべてのアドレスに + 同じコンテンツで応答する * に置き換えられます。

+
+ +
top
+
+

違うポートで違うサイトを運営する

+ +

同じ IP に複数のドメインがあり、さらに複数のポートを使って + リクエストを扱いたいときがあります。"NameVirtualHost" タグの中で + ポートを定義することで、これを動作させられます。 + NameVirtualHost name:port 無しや Listen ディレクティブで + <VirtualHost name:port> を使おうとしても、その設定は動作しません。

+ +

サーバの設定

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

+ +
top
+
+

IP ベースのバーチャルホスティング

+ +

サーバは www.example.comwww.example.org + にそれぞれ解決される、二つの IP アドレス (172.20.30.40 と + 172.20.30.50) があります。

+ +

サーバの設定

+ + + Listen 80
+
+ <VirtualHost 172.20.30.40>
+ + DocumentRoot /www/example1
+ ServerName www.example.com
+
+ </VirtualHost>
+
+ <VirtualHost 172.20.30.50>
+ + DocumentRoot /www/example2
+ ServerName www.example.org
+
+ </VirtualHost> +

+ +

<VirtualHost> ディレクティブのどれでも + 指定されていないアドレス (例えば localhost) は、 + 主サーバがあればそこに行きます。

+ +
top
+
+

ポートベースと IP ベースの混ざった + バーチャルホスト

+ +

サーバマシンはそれぞれ www.example.com と + www.example.org にそれぞれ解決される、IP アドレスを二つ + (172.20.30.40172.20.30.50) 持っています。 + どちらもポート 80 と 8080 でホストを走らせます。

+ +

サーバの設定

+ + + Listen 172.20.30.40:80
+ Listen 172.20.30.40:8080
+ Listen 172.20.30.50:80
+ Listen 172.20.30.50:8080
+
+ <VirtualHost 172.20.30.40:80>
+ + DocumentRoot /www/example1-80
+ ServerName www.example.com
+
+ </VirtualHost>
+
+ <VirtualHost 172.20.30.40:8080>
+ + DocumentRoot /www/example1-8080
+ ServerName www.example.com
+
+ </VirtualHost>
+
+ <VirtualHost 172.20.30.50:80>
+ + DocumentRoot /www/example2-80
+ ServerName www.example.org
+
+ </VirtualHost>
+
+ <VirtualHost 172.20.30.50:8080>
+ + DocumentRoot /www/example2-8080
+ ServerName www.example.org
+
+ </VirtualHost> +

+ +
top
+
+

名前ベースと IP ベースを混ぜた + バーチャルホスト

+ +

いくつかのマシンでは名前ベースの、その他では IP ベースのバーチャル + ホストをします。

+ +

サーバの設定

+ + + Listen 80
+
+ NameVirtualHost 172.20.30.40
+
+ <VirtualHost 172.20.30.40>
+ + DocumentRoot /www/example1
+ ServerName www.example.com
+
+ </VirtualHost>
+
+ <VirtualHost 172.20.30.40>
+ + DocumentRoot /www/example2
+ ServerName www.example.org
+
+ </VirtualHost>
+
+ <VirtualHost 172.20.30.40>
+ + DocumentRoot /www/example3
+ ServerName www.example3.net
+
+ </VirtualHost>
+
+ # IP-based
+ <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> +

+ +
top
+
+

Virtual_host と + mod_proxy を併用する

+ +

次の例は、フロント側のバーチャルホストで他のマシンへプロクシします。 + 例では 192.168.111.2 のマシンではバーチャルホスト名は + 同じ名前で設定されています。複数のホスト名を一台のマシンにプロクシする + 場合は、ProxyPreserveHost On + ディレクティブを使って、希望のホスト名を渡せるようになります。 +

+ +

+ <VirtualHost *:*>
+ ProxyPreserveHost On
+ ProxyPass / http://192.168.111.2/
+ ProxyPassReverse / http://192.168.111.2/
+ ServerName hostname.example.com
+ </VirtualHost> +

+ +
top
+
+

_default_ のバーチャルホストを + 使う

+ +

すべてのポートに対する + _default_ バーチャルホスト

+ +

未指定の IP アドレスとポート、つまり他のバーチャルホストに + 使われていないアドレスとポートの組み合わせ、へのすべてのリクエストを + 受け取ります。

+ +

サーバの設定

+ + + <VirtualHost _default_:*>
+ + DocumentRoot /www/default
+
+ </VirtualHost> +

+ +

このようにワイルドカードのポートでデフォルトのバーチャルホストを + 指定すると、主サーバにリクエストが行くのを防げます。

+ +

デフォルトのバーチャルホストは名前ベースのバーチャルホストに + 使われているアドレスとポートの組に送られたリクエストを扱うことは + ありません。リクエストが不明な Host: ヘッダやその + ヘッダがなかったりする場合は基本名前ベースバーチャルホスト (その + アドレスとポートで設定ファイル中で最初のバーチャルホスト) により + 扱われます。

+ +

どんなリクエストでも AliasMatch + や RewriteRule を使って + 単一の情報ページ (やスクリプト) に書き換えることができます。

+ + +

違うポートのための + _default_ バーチャルホスト

+ +

一つめの設定とほぼ同じですが、サーバは複数のポートを listen しており、 + 80 番ポートに対して二つめの _default_ バーチャルホストを + 設定したい場合です。

+ +

サーバの設定

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

+ +

80 番ポートのデフォルトバーチャルホスト (ワイルドカードポートの + デフォルトバーチャルホストよりも前に書かれていなければなりません) は + 未指定の IP アドレスに送られたすべてのリクエストを扱います。 + 主サーバはリクエストを扱いません。

+ + +

一つのポートに対してだけの + _default_ バーチャルホスト

+ +

80 番ポートにはデフォルトのバーチャルホストが必要で、他の + バーチャルホストはデフォルトが必要ない場合です。

+ +

サーバの設定

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

+ +

80 番ポートへのアドレス未指定のリクエストはデフォルトのバーチャル + ホストから送られます。他の未指定のアドレスとポートへのリクエストは + 主サーバから送られます。

+ + +
top
+
+

名前ベースのバーチャルホストから IP ベースの + バーチャルホストに移行する

+ +

ホスト名が名前 www.example.org のバーチャルホスト + (名前ベースの例の 2 番目の設定) が専用の IP アドレスを + 得たとします。名前ベースのバーチャルホストの古い IP アドレスを + キャッシュしているネームサーバやプロキシのために移行期間中は両方の + バーチャルホストを提供したいとします。

+ +

答は簡単です。単に新しい IP アドレス (172.20.30.50) + を VirtualHost ディレクティブに追加することで + できます。

+ +

サーバ設定

+ + + Listen 80
+ ServerName www.example.com
+ DocumentRoot /www/example1
+
+ NameVirtualHost 172.20.30.40
+
+ <VirtualHost 172.20.30.40 172.20.30.50>
+ + DocumentRoot /www/example2
+ ServerName www.example.org
+ # ...
+
+ </VirtualHost>
+
+ <VirtualHost 172.20.30.40>
+ + DocumentRoot /www/example3
+ ServerName www.example.net
+ ServerAlias *.example.net
+ # ...
+
+ </VirtualHost> +

+ +

このバーチャルホストは新しいアドレス (IP ベースのバーチャルホストとして) + と古いアドレス(名前ベースのバーチャルホストとして) の両方から + アクセスできます。

+ +
top
+
+

ServerPath ディレクティブを + 使う

+ +

名前ベースのバーチャルホストが二つあるサーバがあるとします。 + 正しいバーチャルホストを得るためにはクライアントは正しい + Host: ヘッダを送らなければなりません。 + 古い HTTP/1.0 はそのようなヘッダを送らないので、Apache はクライアントが + どのバーチャルホストを意図したのかさっぱりわかりません + (なので、主バーチャルホストでリクエストを扱います)。 + 可能な限りの下位互換性を得るため、名前ベースのバーチャルホストの + URL 接頭辞へのリンクの書かれたページを返す、 + 主バーチャルホストが作成されます。

+ +

サーバの設定

+ + + NameVirtualHost 172.20.30.40
+
+ <VirtualHost 172.20.30.40>
+ + # primary vhost
+ 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> +

+ +

ServerPath ディレクティブの設定に + より、URL http://www.sub1.domain.tld/sub1/ は + 常に sub1-vhost により扱われます。URL + http://www.sub1.domain.tld/ へのリクエストは + クライアントが正しい Host: ヘッダを送ったときにのみ + sub1-vhost から送られます。Host: ヘッダがなければ + クライアントは主ホストの情報ページを得ます。

+ +

一つ奇妙な動作をする点があることは覚えておいてください。 + http://www.sub2.domain.tld/sub1/ へのリクエストも + Host: ヘッダがなければ sub1-vhost により扱われます。

+ +

正しい Host: ヘッダを送ったクライアントはどちらの + URL、つまり接頭辞がある方も無い方も使えるように + RewriteRule ディレクティブが + 使われています。

+
+
+

翻訳済み言語:  en  | + fr  | + ja  | + ko  | + tr 

+
top

コメント

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/examples.html.ko.euc-kr b/docs/manual/vhosts/examples.html.ko.euc-kr new file mode 100644 index 0000000..ebe9e0c --- /dev/null +++ b/docs/manual/vhosts/examples.html.ko.euc-kr @@ -0,0 +1,657 @@ + + + + + +ȣƮ - Apache HTTP Server Version 2.4 + + + + + + + +
<-
+

ȣƮ

+
+

:  en  | + fr  | + ja  | + ko  | + tr 

+
+
ֽ ƴմϴ. + ֱٿ ϼ.
+ + +

ǵǴ ȣƮ + Ϸ . Ȳ ̸̳ IP ȣƮ + Ʈ Ϸ ̴. Ͻ ڿ + Ͽ Ʈ ϴ 츦 ٷ + ̴.

+ +
+ +
top
+
+

IP ּ Ѱ ̸ + Ʈ ϱ.

+ +

IP ּҰ Ѱ ְ, DNS ּ(CNAMES) + ǻ͸ Ų. ǻͿ www.example.com + www.example.org ϰ ʹ.

+ +

Note

ġ ȣƮ + Ѵٰ ȣƮ DNS ׸ ڵ̷ + ʴ´. ݵ DNS IP ּҸ Ű + ̸ ־ Ѵ. ȱ׷ ƹ Ʈ + . ˻غ hosts Ͽ ׸ + ߰ , ̴ hosts ׸ ǻͿ + ݿȴ.

+
+ +

+ + + # ġ Ʈ 80 ٸ
+ Listen 80
+
+ # IP ּҿ ȣƮ û ٸ
+ NameVirtualHost *:80
+
+ <VirtualHost *:80>
+ + DocumentRoot /www/example1
+ ServerName www.example.com
+
+ # ٸ þ鵵 ִ
+
+
+ </VirtualHost>
+
+ <VirtualHost *:80>
+ + DocumentRoot /www/example2
+ ServerName www.example.org
+
+ # ٸ þ鵵 ִ
+
+
+ </VirtualHost> +

+ +

ǥ ּҸ ŰǷ, ּ  û + ʴ´. www.example.com + Ͽ ó Ƿ 켱 , + Ȥ ʱ ȴ. +  ServerName þ شʴ û + ù° VirtualHost Ѵ.

+ +
+

+ +

Ѵٸ * ý IP + ּҸ ִ. + VirtualHost ƱԸƮ + NameVirtualHost ƱԸƮ ġؾ + Ѵ:

+ +

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

+ +

׷ ISP IP ּҸ + IP ּҸ 𸣴 쿡 * ϴ + ϴ. * IP ּҿ + شϹǷ, IP ּҰ Ǿ + ʿ䰡 .

+
+ +

κ ̸ ȣƮ . + ܴ ٸ IP ּҳ Ʈ ٸ Ϸ + ̴.

+ +
top
+
+

IP ּҿ ̸ + ȣƮ.

+ +
+

⼭ IP ּҰ +  밡ϴ.

+
+ +

IP ּҰ ΰִ. ϳ + (172.20.30.40) "" + server.domain.com ϰ, ٸ ϳ + (172.20.30.50) ȣƮ + ̴.

+ +

+ + + Listen 80
+
+ # 172.20.30.40 ϴ ""̴
+ ServerName server.domain.com
+ DocumentRoot /www/mainserver
+
+ # ٸ ּҴ
+ NameVirtualHost 172.20.30.50
+
+ <VirtualHost 172.20.30.50>
+ + DocumentRoot /www/example1
+ ServerName www.example.com
+
+ # ٸ þ鵵 ִ ...
+
+
+ </VirtualHost>
+
+ <VirtualHost 172.20.30.50>
+ + DocumentRoot /www/example2
+ ServerName www.example.org
+
+ # ٸ þ鵵 ִ ...
+
+
+ </VirtualHost> +

+ +

172.20.30.50 ƴ ּҿ û + ּ Ѵ. ȣƮ , Host: + 172.20.30.50 ûϸ + www.example.com Ѵ.

+ +
top
+
+

(ο ܺ ּҿ ) + ٸ IP ּҷ ϱ.

+ +

ǻͿ IP ּҰ ΰ (192.168.1.1 + 172.20.30.40) ִ. ǻʹ (Ʈ) + Ʈ ܺ (ͳ) Ʈ ̿ ġѴ. Ʈ ۿ + server.example.com ܺ ּҸ + (172.20.30.40) ǹϰ, Ʈ ο + ̸ ּҷ (192.168.1.1) Ѵ.

+ +

VirtualHost Ѱ ο ܺ + 信 ִ.

+ +

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

+ +

Ʈ û + VirtualHost Ѵ.

+ +
+

:

Ʈ ȣƮ + server.example.com ̸ + server ϴ.

+ +

IP ּ * + Ͽ ּҿ ϰ + ִ.

+
+ +
top
+
+

Ʈ ٸ Ʈ + ϱ.

+ +

IP Ʈ ٸ Ѵٰ + . ̴ "NameVirtualHost" ±׿ Ʈ ϸ + ϴ. NameVirtualHost name:port <VirtualHost + name:port> Ȥ Listen þ ϸ ȵȴ.

+ +

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

+ +
top
+
+

IP ȣƮ

+ +

www.example.com + www.example.org شϴ IP ּҸ + (172.20.30.40 172.20.30.50) + .

+ +

+ + + Listen 80
+
+ <VirtualHost 172.20.30.40>
+ + DocumentRoot /www/example1
+ ServerName www.example.com
+
+ </VirtualHost>
+
+ <VirtualHost 172.20.30.50>
+ + DocumentRoot /www/example2
+ ServerName www.example.org
+
+ </VirtualHost> +

+ +

<VirtualHost> þ ּҿ + شʴ ּҷ ( , localhost) + û ּ ִ ּ Ѵ.

+ +
top
+
+

Ʈݰ ip ȥյ + ȣƮ

+ +

www.example.com + www.example.org شϴ IP ּҸ + (172.20.30.40 172.20.30.50) + . IP 80 8080 Ʈ ȣƮ .

+ +

+ + + Listen 172.20.30.40:80
+ Listen 172.20.30.40:8080
+ Listen 172.20.30.50:80
+ Listen 172.20.30.50:8080
+
+ <VirtualHost 172.20.30.40:80>
+ + DocumentRoot /www/example1-80
+ ServerName www.example.com
+
+ </VirtualHost>
+
+ <VirtualHost 172.20.30.40:8080>
+ + DocumentRoot /www/example1-8080
+ ServerName www.example.com
+
+ </VirtualHost>
+
+ <VirtualHost 172.20.30.50:80>
+ + DocumentRoot /www/example2-80
+ ServerName www.example.org
+
+ </VirtualHost>
+
+ <VirtualHost 172.20.30.50:8080>
+ + DocumentRoot /www/example2-8080
+ ServerName www.example.org
+
+ </VirtualHost> +

+ +
top
+
+

̸ݰ IP ȥյ + ȣƮ

+ +

ּ ̸ ȣƮ, ٸ IP + ȣƮ ϰ ʹ.

+ +

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

+ +
top
+
+

_default_ ȣƮ + ϱ

+ +

Ʈ + _default_ ȣƮ

+ +

 ȣƮ ش IP ּҿ Ʈ + û óϱ.

+ +

+ + + <VirtualHost _default_:*>
+ + DocumentRoot /www/default
+
+ </VirtualHost> +

+ +

default(⺻) ȣƮ Ʈ ϵī带 Ͽ  û + ּ .

+ +

default ȣƮ ̸ ȣƮ ϴ + ּ/Ʈ û ʴ´. ų + Host: û ׻ ̸ + ȣƮ(Ͽ + ּ/Ʈ ó ȣƮ) Ѵ.

+ +

AliasMatch + RewriteRule + Ͽ  û Ư (Ȥ ũƮ) + ۼ(rewrite) ִ.

+ + +

Ʈ + _default_ ȣƮ

+ +

, Ʈ ٸ 80 + Ʈ ؼ ߰ _default_ ȣƮ + ϰ ʹ.

+ +

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

+ +

80 Ʈ default ȣƮ (ݵ + ϵī Ʈ ⺻ ȣƮ ; Ѵ) + IP ּҷ û Ѵ. + ּ û Ѵ.

+ + +

Ʈ + _default_ ȣƮ

+ +

80 Ʈ ؼ default ȣƮ ʹ.

+ +

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

+ +

Ʈ 80 ּҿ û ⺻ + ȣƮ ϰ, ٸ ּҿ Ʈ + û Ѵ.

+ + +
top
+
+

̸ ȣƮ IP + ȣƮ ű

+ +

(̸ ù° ) ȣƮ + www.example.org ̸ ȣƮ + ڽ IP ּҸ Ѵ. ̸ ȣƮ + IP ּҸ ijϴ Ӽ Ͻÿ ϱ + ű θ ϰ ʹ.

+ +

+ VirtualHost þ IP ּҸ + (172.20.30.50) ߰ϸǹǷ .

+ +

+ + + Listen 80
+ ServerName www.example.com
+ DocumentRoot /www/example1
+
+ NameVirtualHost 172.20.30.40
+
+ <VirtualHost 172.20.30.40 172.20.30.50>
+ + DocumentRoot /www/example2
+ ServerName www.example.org
+ # ...
+
+ </VirtualHost>
+
+ <VirtualHost 172.20.30.40>
+ + DocumentRoot /www/example3
+ ServerName www.example.net
+ ServerAlias *.example.net
+ # ...
+
+ </VirtualHost> +

+ +

(IP ȣƮ ) ο ּҿ (̸ + ȣƮ ) ּ ȣƮ + ִ.

+ +
top
+
+

ServerPath + þ ϱ

+ +

̸ ȣƮ ִ. ùٸ + ȣƮ ϱ Ŭ̾Ʈ ùٸ + Host: Ѵ. HTTP/1.0 + Ŭ̾Ʈ ϸ ġ Ŭ̾Ʈ +  ȣƮ ϴ (׷ + ȣƮ û Ѵ). ȣȯ + ϱ ȣƮ , ⿡ ̸ + ȣƮ URL λ縦 ϴ ũ + д.

+ +

+ + + NameVirtualHost 172.20.30.40
+
+ <VirtualHost 172.20.30.40>
+ + # primary vhost
+ 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> +

+ +

ServerPath þ + URL http://www.sub1.domain.tld/sub1/ + û ׻ subl-ȣƮ Ѵ.
+ Ŭ̾Ʈ ùٸ Host: ٸ, + URL http://www.sub1.domain.tld/ û + subl-ȣƮ Ѵ. Host: + Ŭ̾Ʈ ȣƮ ִ + Եȴ.

+ +

⿡ ϶: Ŭ̾Ʈ + Host: + http://www.sub2.domain.tld/sub1/ û + subl-ȣƮ Ѵ.

+ +

RewriteRule + þ Ͽ ùٸ Host: + Ŭ̾Ʈ ( , URL ġ簡 ְų ) + URL ִ.

+ +
+
+

:  en  | + fr  | + ja  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/examples.html.tr.utf8 b/docs/manual/vhosts/examples.html.tr.utf8 new file mode 100644 index 0000000..d5c620d --- /dev/null +++ b/docs/manual/vhosts/examples.html.tr.utf8 @@ -0,0 +1,562 @@ + + + + + +Sanal Konak Örnekleri - Apache HTTP Sunucusu Sürüm 2.4 + + + + + + + +
<-
+

Sanal Konak Örnekleri

+
+

Mevcut Diller:  en  | + fr  | + ja  | + ko  | + tr 

+
+ + +

Bu belgede sanal konaklarla ile ilgili olarak + karşılaşılması olası tüm senaryolara yer verilmeye çalışılmıştır. + Buradaki senaryolar, tek bir sunucu üzerinde isme dayalı veya IP’ye dayalı + sanal konaklar aracılığıyla çok sayıda sitenin sunumu ile ilgilidir. +

+ +
+ +
top
+
+

Tek bir IP ile çok sayıda isme dayalı site

+ + +

Bu örnekte, makinenizin tek bir IP adresine çözümlenen çok sayıda konak + adına sahip olduğunu, example.com ve + example.org gibi farklı isimlere farklı yanıtlar vermek + istediğinizi varsayalım.

+ +

Bilginize

Apache sunucusu üzerinde sanal konakları + yapılandırmakla bu konak isimleri için sihirli bir şekilde DNS + kayıtlarının da oluşturulmasını sağlamış olmazsınız. Bu isimler için + ilgili DNS kayıtlarında sizin IP adresinize çözümlenen A kayıtlarının + olması gerekir, yoksa sitenize kimse erişemez. Sitelere erişimi yerel + olarak denemek isterseniz, bu girdileri hosts dosyanıza + yazabilirsiniz. Fakat bu sadece sizin makinenizde çalışır. Yerel + ağınızdaki her makinenin hosts dosyasına bu girdileri + yazarak yerel ağdan erişimi bu yolla sağlayabilirsiniz ama dış ağdan + gelecek ziyaretçileriniz için DNS kayıtlarınızın olması şarttır.

+
+ +
# Apache’nin 80. portu dinlediğinden emin olalım
+Listen 80
+<VirtualHost *:80>
+  DocumentRoot "/siteler/ecom"
+  ServerName example.com
+
+  # Diğer yönergeler, burada ...
+</VirtualHost>
+
+<VirtualHost *:80>
+  DocumentRoot "/siteler/eorg"
+  ServerName example.org
+
+  # Diğer yönergeler, burada ...
+</VirtualHost>
+ + +

Yıldız imleri tüm adreslerle eşleşmeyi sağladığından ana sunucu + (yapılandırma dosyası genelindeki yapılandırma - sunucu geneli) + erişilebilir olmayacaktır. Yapılandırma + dosyasındaki ServerName example.com yönergeli konak, ilk + sanal konak olduğundan en yüksek önceliğe sahiptir ve + öntanımlı veya baskın site olarak davranır. + Yani, hiçbir ServerName yönergesi + ile eşleşmeyen bir istek alındığında bu istek ilk <VirtualHost> yapılandırması ile + karşılanır.

+ +

Yukarıdaki yapılandırmayı hemen hemen tüm isme dayalı sanal konaklar + için kullanabilirsiniz. Bu yapılandırmanın çalışmayacağı tek durum, + farklı içerikleri farklı IP adres veya portlardan sunma gereğiyle + karşılaşmaktır.

+ +

Bilginize

+

* yerine sisteminizdeki belli bir IP adresini + yazabilirsiniz. Böyle sanal konaklar sadece, HTTP isteklerinin sadece + belirtilen IP adreslerinden alınması için kullanilabilir.

+ +
NameVirtualHost 192.168.1.22
+
+<VirtualHost 192.168.1.22>
+  # vs. ...
+</VirtualHost>
+ + +

Bununla birlikte, IP adresinin önceden kestirilebilir olmadığı + sistemlerde, örneğin, hizmet sağlayıcınıza çevirmeli ağ ile bağlanıyor + ve onun rasgele atadığı bir IP adresi için bir devingen DNS çözümü + kullanıyorsanız, IP adresi değil de * kullanmak daha çok + işinize yarayacaktır. Yıldız imi her IP adresi ile eşleşeceğinden IP + adresiniz değişse bile bu yapılandırmayı değiştirmeden + kullanabilirsiniz.

+
+ +
top
+
+

IP adresleri farklı çok sayıda isme dayalı site

+ + +

Bilginize

+

Burada açıklanan teknikler istendiği kadar çok IP adresine + genişletilebilir.

+
+ +

Sunucunun iki IP adresi olsun. Birinden "ana sunucu" + (192.168.1.2) diğerinden example.com + 192.168.2.2 hizmet versin. Bu arada başka sanal konakları + da sunabilelim istiyoruz.

+ +
Listen 80
+
+# Bu, 192.168.1.2 adresindeki "ana sunucu" olsun
+ServerName sunucu.example.com
+DocumentRoot "/siteler/anasunucu"
+
+<VirtualHost 192.168.1.20>
+    DocumentRoot "/siteler/ecom"
+    ServerName example.com
+
+    # Diğer yönergeler, burada ...
+</VirtualHost>
+
+<VirtualHost 192.168.1.20>
+    DocumentRoot "/siteler/eorg"
+    ServerName example.org
+
+    # Diğer yönergeler, burada ...
+</VirtualHost>
+ + +

192.168.1.20 adresinden gelmeyen tüm isteklere ana sunucu + (sunucu.example.com), 192.168.1.20 adresinden + gelen sunucu ismi belirtmeyenler ile Host: başlığı + belirtmeyenlere ise example.com hizmet verecektir.

+ +
top
+
+

Aynı içeriği farklı IP adresleriyle sunmak + (örn., dahili ve harici ağlara)

+ +

Sunucu makine iki IP adresine sahip olsun. Biri iç ağa + (192.168.1.1) diğeri dış ağa (172.20.30.40) + bakıyor olsun. sunucu.example.com ismi dış ağda dış ağa + bakan IP’ye, iç ağda ise iç ağa bakan IP’ye çözümleniyor olsun.

+ +

Bu durumda, sunucu hem iç hem de dış ağdan gelen isteklere aynı içerik, + dolayısıyla aynı <VirtualHost> bölümü ile hizmet verebilir.

+ +
<VirtualHost 192.168.1.1 172.20.30.40>
+    DocumentRoot "/siteler/sunucu"
+    ServerName sunucu.example.com
+    ServerAlias sunucu
+</VirtualHost>
+ + +

Artık, hem iç hem de dış ağdan gelen isteklere aynı + <VirtualHost> + bölümünden hizmet sunulacaktır.

+ +

Bilginize:

+

İç ağdan istek yapan biri, tam nitelenmiş konak ismi + sunucu.example.com yerine makine ismini + (sunucu) kullanabilir (ServerAlias sunucu + satırına dikkat).

+ +

Ayrıca, yukarıdaki gibi iki ayrı IP adresi belirtmek yerine sadece + * belirtmekle sunucunun tüm IP adreslerine yine aynı + içerikle yanıt vereceğine dikkat ediniz.

+
+ +
top
+
+

Farklı portlarla farklı siteler

+ +

Aynı IP adresine sahip çok sayıda konak ismine sahip olduğunuzu ve + bunların bazılarının farklı portları kullanmasını istediğinizi + varsayalım. Aşağıdaki örnekte, isim eşleşmesinin, en iyi eşleşen IP + adresi ve port çifti saptandıktan sonra yer alması gösterilmiştir.

+ +
Listen 80
+Listen 8080
+
+<VirtualHost 172.20.30.40:80>
+    ServerName example.com
+    DocumentRoot "/siteler/ecom-80"
+</VirtualHost>
+
+<VirtualHost 172.20.30.40:8080>
+    ServerName example.com
+    DocumentRoot "/siteler/ecom-8080"
+</VirtualHost>
+
+<VirtualHost 172.20.30.40:80>
+    ServerName example.org
+    DocumentRoot "/siteler/eorg-80"
+</VirtualHost>
+
+<VirtualHost 172.20.30.40:8080>
+    ServerName example.org
+    DocumentRoot "/siteler/eorg-8080"
+</VirtualHost>
+ + +
top
+
+

IP’ye dayalı sanal konaklar

+ +

Sunucu makinenin, biri example.com adından çözümlenen + 172.20.30.40, diğeri example.org adından + çözümlenen 172.20.30.50 diye iki IP adresi olsun.

+ +
Listen 80
+
+<VirtualHost 172.20.30.40>
+    DocumentRoot "/siteler/ecom"
+    ServerName example.com
+</VirtualHost>
+
+<VirtualHost 172.20.30.50>
+    DocumentRoot "/siteler/eorg"
+    ServerName example.org
+</VirtualHost>
+ + +

<VirtualHost> yönergelerinde belirtilmeyen + adreslerle yapılan isteklere (örneğin, localhost) sunucu + genelindeki yapılandırma ile ana sunucu yanıt verecektir.

+
top
+
+

Hem IP’ye hem de porta dayalı sanal konaklar

+ + +

Sunucu makinenin, biri example.com adından çözümlenen + 172.20.30.40, diğeri example.org adından + çözümlenen 172.20.30.50 diye iki IP adresi olsun ve iki + konak da hem 80 hem de 8080 portlarında çalışsınlar istiyoruz.

+ +
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 "/siteler/ecom-80"
+    ServerName example.com
+</VirtualHost>
+
+<VirtualHost 172.20.30.40:8080>
+    DocumentRoot "/siteler/ecom-8080"
+    ServerName example.com
+</VirtualHost>
+
+<VirtualHost 172.20.30.50:80>
+    DocumentRoot "/siteler/eorg-80"
+    ServerName example.org
+</VirtualHost>
+
+<VirtualHost 172.20.30.50:8080>
+    DocumentRoot "/siteler/eorg-8080"
+    ServerName example.org
+</VirtualHost>
+ + +
top
+
+

Hem isme hem de IP‘ye dayalı sanal konaklar

+ + +

Bir VirtualHost yönergesinde belirtilen bir IP adresi başka + bir sanal konakta görünmüyorsa bu sankon kesinlikle IP'ye dayalı bir + sanal konaktır.

+ +
Listen 80
+
+<VirtualHost 172.20.30.40>
+    DocumentRoot "/siteler/ecom"
+    ServerName example.com
+</VirtualHost>
+
+<VirtualHost 172.20.30.40>
+    DocumentRoot "/siteler/eorg"
+    ServerName example.org
+</VirtualHost>
+
+<VirtualHost 172.20.30.40>
+    DocumentRoot "/siteler/enet"
+    ServerName example.net
+</VirtualHost>
+
+# IP'ye dayalı
+<VirtualHost 172.20.30.50>
+    DocumentRoot "/siteler/eedu"
+    ServerName example.edu
+</VirtualHost>
+
+<VirtualHost 172.20.30.60>
+    DocumentRoot "/siteler/egov"
+    ServerName example.gov
+</VirtualHost>
+ + +
top
+
+

Virtualhost ve + mod_proxy’nin birlikte kullanımı

+ +

Bu örnekte bir arabirimi dışarıya bakan bir makinede, başka bir + makinede çalışan bir sunucuya sanal konak olarak, bir vekil sunucu + çalıştırmak istediğimizi varsayıyoruz. 192.168.111.2 IP + adresli bir makinede aynı isimde bir sanal konak yapılandırılmış olsun. + Çok sayıda konak ismi için vekil olarak tek bir makine kullandığımızdan + ve konak isminin de aktarılmasını arzuladığımızdan ProxyPreserveHost + On yönergesini kullandık.

+ +
<VirtualHost *:*>
+    ProxyPreserveHost On
+    ProxyPass        "/" "http://192.168.111.2/"
+    ProxyPassReverse "/" "http://192.168.111.2/"
+    ServerName konak.example.com
+</VirtualHost>
+ + +
top
+
+

_default_ sanal konakları

+ +

Tüm portlar için _default_

+ + +

Bir IP adresi ve port belirtilmeyen veya hiçbir sanal konağın hiçbir + adresi/portu ile eşleşmeyen istekleri yakalamak istersek...

+ +
<VirtualHost _default_:*>
+    DocumentRoot "/siteler/default"
+</VirtualHost>
+ + +

Bütün portlarla eşleşen böyle bir öntanımlı sanal konağın kullanımı + hiçbir isteğin ana sunucuya gitmemesi sonucunu doğurur.

+ +

Bir öntanımlı sanal konak, asla, isme dayalı sanal konaklar için + kullanılmış bir adrese/porta gönderilmiş bir isteğe hizmet sunmaz. Eğer + istek bilinmeyen bir Host: başlığına sahipse veya hiç + Host: başlığı içermiyorsa isteğe daima ilk (yapılandırma + dosyasındaki ilk) isme dayalı sanal konak hizmet sunar.

+ +

Her isteği tek bir bilgilendirme sayfasına (veya betiğe) yönlendirmek + isterseniz AliasMatch veya + RewriteRule yönergesini + kullanabilirsiniz.

+ + +

Farklı portlardan _default_

+ + +

Önceki yapılandırmaya ek olarak 80. portta ayrı bir + _default_ sanal konağı kullanmak istersek...

+ +
<VirtualHost _default_:80>
+    DocumentRoot "/siteler/default80"
+    # ...
+</VirtualHost>
+
+<VirtualHost _default_:*>
+    DocumentRoot "/siteler/default"
+    # ...
+</VirtualHost>
+ + +

80. porttan hizmet sunan _default_ sanal konağı IP adresi + belirtilmeyen tüm istekleri yakalar, bunu yapabilmesi için yapılandırma + dosyasında tüm portlara hizmet sunan benzerinden önce yer almalıdır. Bu + durumda ana sunucu hiçbir isteğe yanıt vermeyecektir.

+ + +

Tek portluk _default_

+ + +

_default_ sanal konağının sadece 80. porttan hizmet + sunmasını istersek...

+ +
<VirtualHost _default_:80>
+    DocumentRoot "/siteler/default"
+    ...
+</VirtualHost>
+ + +

80. porttan gelen IP adresi belirtilmemiş isteklere + _default_ sanal konağı, diğer portlardan gelen adres + belirtilmemiş isteklere ise ana sunucu hizmet verecektir.

+ +

Bir sanal konak bildiriminde * kullanımı + _default_ kullanımından daha yüksek öncelik sağlar.

+ + +
top
+
+

Bir isme dayalı sanal konağı bir IP’ye dayalı + sanal konakla yansılamak

+ +

İsme dayalı sanal konak örneklerinin 2. sinde adı + geçen example.org bu örnekte kendi IP adresinden hizmet + veriyor olsun. İsme dayalı sanal konağı eski IP adresiyle kaydetmiş + vekiller ve isim sunucularından kaynaklanacak olası sorunlardan kaçınmak + için yansılama sırasında sanal konağı hem eski hem de yeni IP adresiyle + sunmamız lazım.

+ +

Çözüm kolay, çünkü yapacağımız sadece VirtualHost + yönergesine yeni IP adresini (192.168.1.2) eklemek + olacak.

+ +
Listen 80
+ServerName example.com
+DocumentRoot "/siteler/ecom"
+
+<VirtualHost 192.168.1.20 192.168.1.2>
+    DocumentRoot "/siteler/eorg"
+    ServerName example.org
+    # ...
+</VirtualHost>
+
+<VirtualHost 192.168.1.20>
+    DocumentRoot "/siteler/enet"
+    ServerName example.enet
+    ServerAlias *.example.net
+    # ...
+</VirtualHost>
+ + +

Böylece sanal konağa hem yeni (bir IP’ye dayalı sanal konak olarak) + hem de eski adresinden (bir isme dayalı sanal konak olarak) + erişilebilecektir.

+ +
top
+
+

ServerPath yönergesinin kullanımı

+ + +

İsme dayalı iki sanal konağı olan bir sunucumuz olsun. Doğru sanal + konağa erişebilmek için istemcinin doğru Host: başlığı + göndermesi gerekir. Eski HTTP/1.0 istemcileri böyle bir başlık + göndermedikleri için Apache istemcinin hangi sanal konağa erişmek + istediğini bilemez (ve isteğe ilk sanal konaktan hizmet sunar). Daha iyi + bir geriye uyumluluk sağlamak için isme dayalı sanal konağa bir önek + bağlantısı içeren bir bilgilendirme sayfası sunmak üzere yeni bir sanal + konak oluşturabiliriz.

+ +
<VirtualHost 172.20.30.40>
+    # ilk sanal konak
+    DocumentRoot "/siteler/baska"
+    RewriteEngine On
+    RewriteRule "." "/siteler/baska/index.html"
+    # ...
+</VirtualHost>
+
+<VirtualHost 172.20.30.40>
+    DocumentRoot /siteler/baska/bir
+    ServerName "bir.baska.tld"
+    ServerPath "/bir/"
+    RewriteEngine On
+    RewriteRule "^(/bir/.*) /siteler/baska$1"
+    # ...
+</VirtualHost>
+
+<VirtualHost 172.20.30.40>
+    DocumentRoot "/siteler/baska/iki"
+    ServerName iki.baska.tld
+    ServerPath "/iki/"
+    RewriteEngine On
+    RewriteRule "^(/iki/.*)" "/siteler/baska$1"
+    # ...
+</VirtualHost>
+ + +

ServerPath yönergesinden dolayı + http://bir.baska.tld/bir/ şeklinde yapılan isteklere + daima “bir” sanal konağı hizmet sunacaktır.

+ +

http://bir.baska.tld/ şeklinde yapılan isteklere ise + istemcinin doğru Host: başlığı göndermesi şartıyla + “bir” sanal konağı hizmet sunacaktır. İstemci, bir + Host: başlığı göndermediği takdirde ilk konaktan bir + bilgilendirme sayfası alacaktır.

+ +

Yalnız buradaki bir tuhaflığa dikkat edin: Eğer istemci bir + Host: başlığı göndermeden + http://iki.baska.tld/bir/ şeklinde bir istek yaparsa bu + isteğe de “bir” sanal konağı hizmet sunacaktır.

+ +

RewriteRule yönergesi, bir + istemcinin, bir URL öneki belirtsin ya da belirtmesin doğru + Host: başlığı gönderdiğinden emin olmak için + kullanılmıştır.

+ +
+
+

Mevcut Diller:  en  | + fr  | + ja  | + ko  | + tr 

+
top

Yorumlar

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/fd-limits.html b/docs/manual/vhosts/fd-limits.html new file mode 100644 index 0000000..9ae89ba --- /dev/null +++ b/docs/manual/vhosts/fd-limits.html @@ -0,0 +1,21 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: fd-limits.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: fd-limits.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +URI: fd-limits.html.ja.utf8 +Content-Language: ja +Content-type: text/html; charset=UTF-8 + +URI: fd-limits.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR + +URI: fd-limits.html.tr.utf8 +Content-Language: tr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/vhosts/fd-limits.html.en b/docs/manual/vhosts/fd-limits.html.en new file mode 100644 index 0000000..730573a --- /dev/null +++ b/docs/manual/vhosts/fd-limits.html.en @@ -0,0 +1,155 @@ + + + + + +File Descriptor Limits - Apache HTTP Server Version 2.4 + + + + + + + +
<-
+

File Descriptor Limits

+
+

Available Languages:  en  | + fr  | + ja  | + ko  | + tr 

+
+ + +

When using a large number of Virtual Hosts, Apache may run + out of available file descriptors (sometimes called file + handles) if each Virtual Host specifies different log + files. The total number of file descriptors used by Apache is + one for each distinct error log file, one for every other log + file directive, plus 10-20 for internal use. Unix operating + systems limit the number of file descriptors that may be used + by a process; the limit is typically 64, and may usually be + increased up to a large hard-limit.

+ +

Although Apache attempts to increase the limit as required, + this may not work if:

+ +
    +
  1. Your system does not provide the setrlimit() + system call.
  2. + +
  3. The setrlimit(RLIMIT_NOFILE) call does not + function on your system (such as Solaris 2.3)
  4. + +
  5. The number of file descriptors required exceeds the hard + limit.
  6. + +
  7. Your system imposes other limits on file descriptors, + such as a limit on stdio streams only using file descriptors + below 256. (Solaris 2)
  8. +
+ +

In the event of problems you can:

+ +
    +
  • Reduce the number of log files; don't specify log files + in the <VirtualHost> + sections, but only log to the main log files. (See Splitting up your log files, below, for more + information on doing this.)
  • + +
  • + If your system falls into 1 or 2 (above), then increase the + file descriptor limit before starting Apache, using a + script like: + +

    + #!/bin/sh
    + ulimit -S -n 100
    + exec httpd
    +

    +
  • +
+ +
+
top
+
+

Splitting up your log files

+ +

If you want to log multiple virtual hosts to the same log file, you +may want to split up the log files afterwards in order to run +statistical analysis of the various virtual hosts. This can be +accomplished in the following manner.

+ +

First, you will need to add the virtual host information to the log +entries. This can be done using the +LogFormat +directive, and the %v variable. Add this to the beginning +of your log format string:

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

This will create a log file in the common log format, but with the +canonical virtual host (whatever appears in the +ServerName directive) prepended to +each line. (See mod_log_config for +more about customizing your log files.)

+ +

When you wish to split your log file into its component parts (one +file per virtual host), you can use the program split-logfile to accomplish +this. You'll find this program in the support directory +of the Apache distribution.

+ +

Run this program with the command:

+ +

+split-logfile < /logs/multiple_vhost_log +

+ +

This program, when run with the name of your vhost log file, will +generate one file for each virtual host that appears in your log file. +Each file will be called hostname.log.

+ +
+
+

Available Languages:  en  | + fr  | + ja  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/fd-limits.html.fr.utf8 b/docs/manual/vhosts/fd-limits.html.fr.utf8 new file mode 100644 index 0000000..f926e16 --- /dev/null +++ b/docs/manual/vhosts/fd-limits.html.fr.utf8 @@ -0,0 +1,167 @@ + + + + + +Limites des descripteurs de fichiers - Serveur HTTP Apache Version 2.4 + + + + + + + +
<-
+

Limites des descripteurs de fichiers

+
+

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

+
+ + +

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 :

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

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
    +

    +
  • +
+ + + +
+
top
+
+

É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 mod_log_config 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  | + tr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/fd-limits.html.ja.utf8 b/docs/manual/vhosts/fd-limits.html.ja.utf8 new file mode 100644 index 0000000..8f2d447 --- /dev/null +++ b/docs/manual/vhosts/fd-limits.html.ja.utf8 @@ -0,0 +1,157 @@ + + + + + +ファイル記述子の限界 - Apache HTTP サーバ バージョン 2.4 + + + + + + + +
<-
+

ファイル記述子の限界

+
+

翻訳済み言語:  en  | + fr  | + ja  | + ko  | + tr 

+
+
この日本語訳はすでに古くなっている + 可能性があります。 + 最近更新された内容を見るには英語版をご覧下さい。 +
+ + +

たくさんのバーチャルホストを運用する場合、もし、 + 各バーチャルホストごとに異なるログファイルが指定してあると、 + Apache がファイル記述子 (ファイルハンドルとも呼ばれます) + を使い切ってしまうことがあります。Apache が使用するファイル + 記述子の数は、各エラーログファイルにつき 1 つ、他のログファイルの + ディレクティブにつき 1 つ、さらに内部で使用する 10 から 20、 + の合計になります。Unix オペレーティングシステムではプロセスごとに + 使用可能なファイル記述子の数を制限しています。たいていの場合は 64 で、 + 普通は大きな値のハードリミットまで増やすことができます。

+ +

Apache は必要に応じて上限を拡大しようと試みますが、 + 以下のような場合にはうまくいかないかもしれません。

+ +
    +
  1. 利用しているシステムで setrlimit() + システムコールが提供されていない。
  2. + +
  3. システム上で setrlimit(RLIMIT_NOFILE) が動作しない + (たとえば Solaris 2.3 のように)。
  4. + +
  5. 要求されるファイル記述子の数が + ハードリミットを超えてしまう。
  6. + +
  7. システムにファイル記述子に関して別の制限が存在してしまっている。 + たとえば、stdio ストリームではファイル記述子を 256 以上使えない + (Solaris 2)、など。
  8. +
+ +

問題が発生した時に取り得る対処方法は次のとおり:

+ +
    +
  • ログファイルの数を減らす。<VirtualHost> + セクションでログファイルを指定せず、メインのログファイルにのみ記録する。 + (これに関する詳しい情報は以下のログファイルの分割を読んでください。)
  • + +
  • + もし、前述の 1 または 2 の場合であれば、 + Apache を起動する前にファイル記述子を増やします。 + たとえば次のようなスクリプトを使います。 + +

    + #!/bin/sh
    + ulimit -S -n 100
    + exec httpd
    +

    +
  • +
+
+
top
+
+

ログファイルの分割

+ +

複数のバーチャルホストのログを同じログファイルに収集しようとしているときには、 +各バーチャルホストについて統計的な解析を実行するために後でログファイルを +分割したくなるかもしれません。これは以下のようにして実現できます。

+ +

まず、バーチャルホストの情報をログのエントリに追加する必要があります。 +これは LogFormat +ディレクティブの %v 変数を使うことでできます。 +これをログのフォーマット文字列の先頭に追加します:

+ +

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

+ +

これは common log format のログを作成しますが、それぞれの行の先頭に +正規化されたバーチャルホストの名前 +(ServerName +ディレクティブに書かれているもの) が付加されます。 +(ログファイルのカスタマイズの詳細については Custom Log Formats を +読んでください。)

+ +

ログファイルを各部分 (バーチャルホスト毎に 1 ファイル) に分けたいときは、 +split-logfile +を使って行なうことができます。プログラムは Apache 配布の +support ディレクトリにあります。

+ +

以下のようなコマンドでこのプログラムを実行します:

+ +

+split-logfile < /logs/multiple_vhost_log +

+ +

このプログラムはバーチャルホストのログファイルの名前とともに実行され、 +ログファイルに現れるそれぞれのバーチャルホスト毎に一つのファイルを作成します。 +それぞれのファイルは ホスト名.log という名前になります。

+ +
+
+

翻訳済み言語:  en  | + fr  | + ja  | + ko  | + tr 

+
top

コメント

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/fd-limits.html.ko.euc-kr b/docs/manual/vhosts/fd-limits.html.ko.euc-kr new file mode 100644 index 0000000..db1237f --- /dev/null +++ b/docs/manual/vhosts/fd-limits.html.ko.euc-kr @@ -0,0 +1,152 @@ + + + + + +ϱ(file descriptor) Ѱ - Apache HTTP Server Version 2.4 + + + + + + + +
<-
+

ϱ(file descriptor) Ѱ

+
+

:  en  | + fr  | + ja  | + ko  | + tr 

+
+
ֽ ƴմϴ. + ֱٿ ϼ.
+ + +

ȣƮ ϰ ȣƮ ٸ + α ϸ, ġ 밡 ϱ(file + descriptor, ڵ(file handle)̶ + θ) ִ. ġ ϴ ϱ + αϴ Ѱ, ٸ α þ + Ѱ, ߰ ο뵵 10-20 . н ü + μ ִ ϱ Ѵ. Ѱ + 64, ̺ ū hard-limit ø ִ.

+ +

ġ Ѱ踦 ʿѸŭ ø , ϴ + 찡 ִ:

+ +
    +
  1. ý setrlimit() ýȣ + ʴ´.
  2. + +
  3. (Solaris 2.3 ) ýۿ + setrlimit(RLIMIT_NOFILE) Լ + ʴ´.
  4. + +
  5. ʿ ϱ hard limit .
  6. + +
  7. (Solaris 2) ý stdio Ʈ 256 + ϱڸ ϵ ϴ ϱڿ + Ѵ.
  8. +
+ +

ذå:

+ +
    +
  • α δ. <VirtualHost> ǿ α + ʰ α Ѵ. ( ڼ + Ʒ α ϶.)
  • + +
  • + ϴ ý () 1° 2° 쿡 شѴٸ, + ũƮ ġ ϱ ϱ + Ѱ踦 ø. + +

    + #!/bin/sh
    + ulimit -S -n 100
    + exec httpd
    +

    +
  • +
+ +
+
top
+
+

α

+ +

ȣƮ α Ѵٸ ߿ +ȣƮ м α ̴. + ۾ ִ.

+ +

α ׸ ȣƮ ߰Ѵ. ̸ +LogFormat%v Ѵ. α +Ĺڿ տ ߰Ѵ:

+ +

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

+ +

׷ common α տ (ServerName þ ) +ȣƮ Ͽ α Ѵ. (α +ǿ α +϶.)

+ +

α (ȣƮ Ͼ) ʹٸ split-logfile α׷ +Ѵ. α׷ ġ support +丮 ִ.

+ +

α׷ Ѵ:

+ +

+split-logfile < /logs/multiple_vhost_log +

+ +

ȣƮ α α׷ ϸ αϿ + ȣƮ ϳ . ϸ +hostname.log̴.

+ +
+
+

:  en  | + fr  | + ja  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/fd-limits.html.tr.utf8 b/docs/manual/vhosts/fd-limits.html.tr.utf8 new file mode 100644 index 0000000..73a7037 --- /dev/null +++ b/docs/manual/vhosts/fd-limits.html.tr.utf8 @@ -0,0 +1,150 @@ + + + + + +Dosya Tanıtıcı Sınırları - Apache HTTP Sunucusu Sürüm 2.4 + + + + + + + +
<-
+

Dosya Tanıtıcı Sınırları

+
+

Mevcut Diller:  en  | + fr  | + ja  | + ko  | + tr 

+
+ + +

Çok büyük sayıda sanal konak kullanıyorsanız ve bunların her biri için + ayrı günlük kayıtları tutuyorsanız, Apache dosya tanıtıcılarını + tüketebilir. Apache tarafından, dahili olarak 10-20 dosya tanıtıcıya ek + olarak her hata günlüğü için bir ve her diğer günlük kaydı için bir dosya + tanıcı kullanılır. Unix işletim sisteminde dosya tanıtıcıların sayısı + süreç başına 64 taneyle sınırlıdır ve gerekirse donanıma bağlı olarak + arttırılabilir.

+ +

Apache gerektiğinde bu sınırı kendisi arttırmaya çalışırsa da bu her + zaman mümkün olmaz. Şöyle ki:

+ +
    +
  1. Sisteminiz setrlimit() sistem çağrısını + sağlamıyordur.
  2. + +
  3. Sisteminizde setrlimit(RLIMIT_NOFILE) çağrısı hiçbir işe + yaramıyordur (örneğin, Solaris 2.3).
  4. + +
  5. Dosya tanıtıcılarının sayısı donanıma bağlı olarak daha fazla + arttırılamıyordur.
  6. + +
  7. Sisteminiz dosya tanıtıcı sayısını başka sınırlara bağlı kılmıştır: + örneğin stdio akımları ile ilgili sınır, dosya tanıtıcı sayısının + 256’nın altında ollmasını gerektiriyordur (Solaris 2).
  8. +
+ +

Böyle sorunlar karşısında yapabilecekleriniz:

+ +
  • Ana günlük dosyaları hariç, <VirtualHost> bölümlerinde günlük dosyası + belirtmeyerek günlük dosyası sayısını düşürürsünüz. (Bunun nasıl + yapılacağını öğrenmek için Günlük kayıtlarının + ayrıştırılması bölümüne bakınız.)
  • + +
  • Sisteminizde serbest dosya tanıtıcı sayısı 1-2 civarına düşerse + Apache’yi aşağıdaki gibi bir betikle yeniden çalıştırarak dosya + tanıtıcı sayısını arttırabilirsiniz: + +

    + #!/bin/sh
    + ulimit -S -n 100
    + exec httpd
    +

    +
  • +
+ +
+
top
+
+

Günlük kayıtlarının ayrıştırılması

+ +

Günlük dosyalarını çok sayıda sanal konak için ortak olarak + kullanıyorsanız, sanal konaklar için istatistiksel çözümlemeler yapmak + amacıyla sırası geldiğinde bunları ayrıştırabilirsiniz. Bu işlem aşağıda + anlatıldığı gibi yapılabilir.

+ +

İlk iş olarak, sanal konak bilgilerini günlük girdilerine eklemeniz + gerekir. Bu işlem, LogFormat yönergesi ve + %v biçem değişkeni ile yapılabilir. Günlük girdisi biçem + dizgesinin başına bunu ekleyiniz:

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

Bu yapılandırma ile her günlük kaydının başında sanal konağın + ServerName yönergesine belirtilen + ismi eklenir. (Günlük dosyalarınızın kişiselleştirilmesi ile ilgili daha + fazla bilgi için mod_log_config belgesine bakınız.)

+ +

Günlük dosyanızdaki kayıtları bileşenlere göre gruplamak isterseniz + split-logfile + programını kullanabilirsiniz. Bu programı Apache dağıtımının + support dizininde bulabilirsiniz.

+ +

Programı aşağıdaki gibi çalıştırın:

+ +

+ split-logfile < /logs/multiple_vhost_log +

+ +

Bu programı sanal konaklar için tuttuğunuz günlük dosyasının ismini + argüman olarak belirterek çalıştırdığınızda o dosyadaki kayıtlardan her + sanal konak için ayrı bir günlük dosyası + (konakadı.log) üretilir.

+ +
+
+

Mevcut Diller:  en  | + fr  | + ja  | + ko  | + tr 

+
top

Yorumlar

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/index.html b/docs/manual/vhosts/index.html new file mode 100644 index 0000000..4fda34f --- /dev/null +++ b/docs/manual/vhosts/index.html @@ -0,0 +1,29 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: index.html.de +Content-Language: de +Content-type: text/html; charset=ISO-8859-1 + +URI: index.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: index.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +URI: index.html.ja.utf8 +Content-Language: ja +Content-type: text/html; charset=UTF-8 + +URI: index.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR + +URI: index.html.tr.utf8 +Content-Language: tr +Content-type: text/html; charset=UTF-8 + +URI: index.html.zh-cn.utf8 +Content-Language: zh-cn +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/vhosts/index.html.de b/docs/manual/vhosts/index.html.de new file mode 100644 index 0000000..72055b8 --- /dev/null +++ b/docs/manual/vhosts/index.html.de @@ -0,0 +1,124 @@ + + + + + +Apache-Dokumentation zu virtuellen Hosts - Apache HTTP Server Version 2.4 + + + + + + + +
<-
+

Apache-Dokumentation zu virtuellen Hosts

+
+

Verfügbare Sprachen:  de  | + en  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

+
+
Diese Übersetzung ist möglicherweise + nicht mehr aktuell. Bitte prüfen Sie die englische Version auf + die neuesten Änderungen.
+ +

Der Begriff virtueller Host (Anm.d.Ü.: engl. 'virtual + host') bezieht sich auf die Praxis, mehr als ein Webangebot + (z.B. www.company1.com und www.company2.com) + auf einer einzigen Maschine zu betreiben. Virtuelle Hosts können + "IP-basiert" sein, was bedeutet, dass jedes + Webangebot eine andere IP besitzt, oder "Namens-basiert", was bedeutet, dass + unter jeder IP-Adresse mehrere Namen laufen. Die Tatsache, dass sie + auf dem gleichen physischen Server laufen, ist für den Endbenutzer + nicht offensichtlich.

+ +

Der Apache war einer der ersten Server, der IP-basierte + virtuelle Hosts von Haus aus direkt unterstützt hat. Seit Version 1.1 + unterstützt der Apache sowohl IP-basierte als auch namensbasierte + virtuelle Hosts (vhosts). Letzteres wird zuweilen auch + Host-basiert oder non-IP-Virtual-Host genannt.

+ +

Nachfolgend finden Sie eine Liste von Dokumenten, die alle Details + der Unterstützung von virtuellen Hosts ab Apache Version 1.3 + beschreiben.

+ +
+ +
top
+
top
+
+

Konfigurationsdirektiven

+ + + +

Bei der Suche von Fehlern in Ihrer Virtual-Host-Konfiguration ist + die Apache-Befehlszeilenoption -S möglicherweise + hilfreich. Geben Sie dazu den folgenden Befehl ein:

+ +

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

+ +

Diese Anweisung gibt eine Beschreibung aus, wie der Apache die + Konfigurationsdatei analysiert hat. Eine sorgfältige + Überprüfung der IP-Adressen und Servernamen kann helfen, + Konfigurationsfehler aufzudecken. (Lesen Sie die Dokumentation zum + httpd-Programm für weitere + Befehlszeilenoptionen.)

+
+
+

Verfügbare Sprachen:  de  | + en  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/index.html.en b/docs/manual/vhosts/index.html.en new file mode 100644 index 0000000..7d5a37b --- /dev/null +++ b/docs/manual/vhosts/index.html.en @@ -0,0 +1,126 @@ + + + + + +Apache Virtual Host documentation - Apache HTTP Server Version 2.4 + + + + + + + +
<-
+

Apache Virtual Host documentation

+
+

Available Languages:  de  | + en  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

+
+ + +

The term Virtual Host refers to the practice of + running more than one web site (such as + company1.example.com and company2.example.com) + on a single machine. Virtual hosts can be "IP-based", meaning that you have a + different IP address for every web site, or "name-based", meaning that you have + multiple names running on each IP address. The fact that they + are running on the same physical server is not apparent to the + end user.

+ +

Apache was one of the first servers to support IP-based + virtual hosts right out of the box. Versions 1.1 and later of + Apache support both IP-based and name-based virtual hosts + (vhosts). The latter variant of virtual hosts is sometimes also + called host-based or non-IP virtual hosts.

+ +

Below is a list of documentation pages which explain all + details of virtual host support in Apache HTTP Server:

+ +
+ +
top
+
top
+
+

Configuration directives

+ + + +

If you are trying to debug your virtual host configuration, you + may find the -S command line switch + useful.

+ +

Unix example

+ + apachectl -S +

+ +

Windows example

+ + httpd.exe -S +

+ + +

This command will dump out a description of how Apache parsed + the configuration file. Careful examination of the IP addresses and + server names may help uncover configuration mistakes. (See + the docs for the httpd program for + other command line options)

+ +
+
+

Available Languages:  de  | + en  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/index.html.fr.utf8 b/docs/manual/vhosts/index.html.fr.utf8 new file mode 100644 index 0000000..0240fab --- /dev/null +++ b/docs/manual/vhosts/index.html.fr.utf8 @@ -0,0 +1,127 @@ + + + + + +Documentation sur les serveurs virtuels Apache - Serveur HTTP Apache Version 2.4 + + + + + + + +
<-
+

Documentation sur les serveurs virtuels Apache

+
+

Langues Disponibles:  de  | + en  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

+
+ + +

Le principe des Serveurs Virtuels consiste à + faire fonctionner un ou plusieurs serveurs Web (comme + www.company1.example.com et www.company2.example.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 proposent les 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 du support des serveurs + virtuels par le serveur HTTP Apache.

+ +
+ +
top
+
top
+
+

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.

+ +

Exemple Unix

+ + apachectl -S +

+ +

Exemple Windows

+ + httpd.exe -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  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/index.html.ja.utf8 b/docs/manual/vhosts/index.html.ja.utf8 new file mode 100644 index 0000000..9c4af13 --- /dev/null +++ b/docs/manual/vhosts/index.html.ja.utf8 @@ -0,0 +1,120 @@ + + + + + +Apache バーチャルホスト説明書 - Apache HTTP サーバ バージョン 2.4 + + + + + + + +
<-
+

Apache バーチャルホスト説明書

+
+

翻訳済み言語:  de  | + en  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

+
+
この日本語訳はすでに古くなっている + 可能性があります。 + 最近更新された内容を見るには英語版をご覧下さい。 +
+ + +

バーチャルホストという用語は、1 台のマシン上で + (www.company1.com and www.company2.com のような) + 二つ以上のウェブサイトを扱う運用方法のことを指します。 + バーチャルホストには、各ウェブサイトに違う IP アドレスがある + 「IP ベース」と、それぞれの IP アドレスに + 複数の名前がある「名前ベース」とがあります。 + 複数のサイトが物理的に同じサーバで扱われている、ということはエンドユーザには + 明らかではありません。

+ +

Apache は、特に手を入れない状態で IP ベースのバーチャルホスト + をサポートした最初のサーバの一つです。バージョン 1.1 以降の Apache + では、IP ベースとネームベースのバーチャルホストの両方をサポート + しています。ネームベースのバーチャルホストは、ホストベースあるいは + 非 IP ベースのバーチャルホストと呼ばれることもあります。

+ +

以下のページでは、Apache バージョン 1.3 + 以降でのバーチャルホストのサポートについての詳細を説明します。

+ +
+ +
top
+
top
+
+

設定ディレクティブ

+ + + +

バーチャルホストの設定のデバッグをするには + Apache のコマンドラインスイッチ -S が便利です。 + つまり、以下のコマンドを入力します:

+ +

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

+ +

このコマンドは Apache が設定ファイルをどう解析したかについて出力します。 + IP アドレスとサーバ名を注意深く調べれば、 + 設定の間違いを見つける助けになるでしょう。 + (他のコマンドラインのオプションは httpd + プログラムの説明文書を見てください)

+ +
+
+

翻訳済み言語:  de  | + en  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/index.html.ko.euc-kr b/docs/manual/vhosts/index.html.ko.euc-kr new file mode 100644 index 0000000..59012d6 --- /dev/null +++ b/docs/manual/vhosts/index.html.ko.euc-kr @@ -0,0 +1,119 @@ + + + + + +ġ ȣƮ - Apache HTTP Server Version 2.4 + + + + + + + +
<-
+

ġ ȣƮ

+
+

:  de  | + en  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

+
+
ֽ ƴմϴ. + ֱٿ ϼ.
+ + +

ȣƮ (Virtual Host) ǻͿ + Ʈ ( , www.company1.com + www.company2.com) Ѵ. + ȣƮ Ʈ ٸ IP ּҸ ϴ + "IP (IP-based)" İ + IP ּҴ ̸ "̸ (name-based)" + ִ. Ʈ ִٴ ڴ + ġä Ѵ.

+ +

ġ ⺻ IP ȣƮ â + ϳ. ġ 1.1 ̻ IPݰ ̸ + ȣƮ Ѵ. ̸ ȣƮ + ȣƮ (host-based) Ǵ IP ȣƮ + (non-IP virtual hosts) θ.

+ +

ġ 1.3 ̻ ȣƮ ڼ + ̴.

+ +
+ +
top
+
+

ȣƮ

+ + + +
top
+
+

þ

+ + + +

ȣƮ ׽ƮҶ ġ -S + ɼ ϴ. , Ѵ:

+ +

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

+ +

ɾ ġ Ͽ + Ѵ. IP ּҿ ڼ 캸 + Ǽ ߰ϴµ ̴. (ٸ ɼǵ + httpd α׷ + ϶.)

+ +
+
+

:  de  | + en  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/index.html.tr.utf8 b/docs/manual/vhosts/index.html.tr.utf8 new file mode 100644 index 0000000..2d249e1 --- /dev/null +++ b/docs/manual/vhosts/index.html.tr.utf8 @@ -0,0 +1,123 @@ + + + + + +Apache Sanal Konak Belgeleri - Apache HTTP Sunucusu Sürüm 2.4 + + + + + + + +
<-
+

Apache Sanal Konak Belgeleri

+
+

Mevcut Diller:  de  | + en  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

+
+ + +

Sanal Konak (Virtual Host) terimi tek bir makine üzerinde + birden fazla sitenin (sirket1.example.com, sirket2.example.com gibi) + barındırılma uygulamasını betimler. Sanal konaklar, + "IP’ye dayalı" veya + "isme dayalı" olabilir; + birincisinde, her site ayrı bir IP adresinden sunulurken, ikincisinde her + IP adresinde birden fazla site sunulur. Olayda aynı fiziksel sunucu + kullanıldığı halde bu sunucu son kullanıcıya görünür değildir.

+ +

Apache yazılımsal olarak IP’ye dayalı sanal konakları destekleyen ilk + sunuculardan biridir. 1.1 sürümünden itibaren Apache hem IP’ye dayalı hem + de isme dayalı sanal konakları desteklemektedir. İsme dayalı sanal + konaklara bazen konağa dayalı sanal konaklar veya IP’ye + dayanmayan sanal konaklar da denmektedir.

+ +

Aşağıda, Apache HTTP Suncusundaki sanal konak desteğini bütün + ayrıntıları ile açıklayan belgeler listelenmiştir.

+ +
+ +
top
+
top
+
+

Yapılandırma Yönergeleri

+ + + +

Sanal konak yapılandırmanız üzerinde hata ayıklamaya çalışıyorsanız + -S komut satırı seçeneği şu şekilde çok işinize + yarayabilir:

+ +

Unix örneği

+ apachectl -S +

+ +

Windows örneği

+ httpd.exe -S +

+ +

Bu komut, yapılandırma dosyasının Apache yorumunu dökümler. IP + adreslerinin ve sunucu isimlerinin dikkatli bir incelemesi, yapılandırma + yanlışlarınızı keşfetmenize yardımcı olabilir. (Diğer komut satırı + seçenekleri için httpd programının belgelerine + bakınız.)

+ +
+
+

Mevcut Diller:  de  | + en  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/index.html.zh-cn.utf8 b/docs/manual/vhosts/index.html.zh-cn.utf8 new file mode 100644 index 0000000..f1fc334 --- /dev/null +++ b/docs/manual/vhosts/index.html.zh-cn.utf8 @@ -0,0 +1,105 @@ + + + + + +Apache 虚拟主机文档 - Apache HTTP 服务器 版本 2.4 + + + + + + + +
<-
+

Apache 虚拟主机文档

+
+

可用语言:  de  | + en  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

+
+
此翻译可能过期。要了解最近的更改,请阅读英文版。
+ + +

术语虚拟主机指的是在单一机器上运行多个网站 + (例如 company1.example.com 和 + company2.example.com) 。 + 虚拟主机可以“基于 IP”,即每个 IP 一个站点; + 或者“基于名称”, + 即每个 IP 多个站点。这些站点运行在同一物理服务器上的事实不会明显的透漏给最终用户。

+ +

Apache 是第一个支持基于 IP 的虚拟主机的服务器。 + Apache 版本 1.1 和更新的版本同时支持基于 IP 和基于名称的虚拟主机。 + 基于名称的虚拟主机有时候称为基于主机非 IP 的虚拟主机.

+ +

以下解释是在 Apache 中支持虚拟主机的所有详细信息的文档页面列表。

+ +
+ +
top
+
top
+
+

配置指令

+ + + +

如果你要调试虚拟主机配置,你会发现 Apache 的命令行参数 -S + 非常有用。即输入以下命令:

+ +

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

+ +

这个命令将会显示 Apache 是如何解析配置文件的。仔细检查 IP + 地址与服务器名称可能会帮助你发现配置错误 + (参见 httpd 程序文档,以便了解其它命令行选项)。

+ +
+
+

可用语言:  de  | + en  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/ip-based.html b/docs/manual/vhosts/ip-based.html new file mode 100644 index 0000000..caffda8 --- /dev/null +++ b/docs/manual/vhosts/ip-based.html @@ -0,0 +1,21 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: ip-based.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: ip-based.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +URI: ip-based.html.ja.utf8 +Content-Language: ja +Content-type: text/html; charset=UTF-8 + +URI: ip-based.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR + +URI: ip-based.html.tr.utf8 +Content-Language: tr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/vhosts/ip-based.html.en b/docs/manual/vhosts/ip-based.html.en new file mode 100644 index 0000000..0823428 --- /dev/null +++ b/docs/manual/vhosts/ip-based.html.en @@ -0,0 +1,210 @@ + + + + + +Apache IP-based Virtual Host Support - Apache HTTP Server Version 2.4 + + + + + + + +
<-
+

Apache IP-based Virtual Host Support

+
+

Available Languages:  en  | + fr  | + ja  | + ko  | + tr 

+
+
+ +
top
+
+

What is IP-based virtual hosting

+

IP-based virtual hosting is a method to apply different directives +based on the IP address and port a request is received on. Most commonly, +this is used to serve different websites on different ports or interfaces.

+ +

In many cases, name-based +virtual hosts are more convenient, because they allow +many virtual hosts to share a single address/port. +See Name-based vs. IP-based +Virtual Hosts to help you decide.

+
top
+
+

System requirements

+ +

As the term IP-based indicates, the server + must have a different IP address/port combination for each IP-based + virtual host. This can be achieved by the machine + having several physical network connections, or by use of + virtual interfaces which are supported by most modern operating + systems (see system documentation for details, these are + frequently called "ip aliases", and the "ifconfig" command is + most commonly used to set them up), and/or using multiple + port numbers.

+ +

In the terminology of Apache HTTP Server, using a single IP address + but multiple TCP ports, is also IP-based virtual hosting.

+ +
top
+
+

How to set up Apache

+ +

There are two ways of configuring apache to support multiple + hosts. Either by running a separate httpd daemon for + each hostname, or by running a single daemon which supports all the + virtual hosts.

+ +

Use multiple daemons when:

+ +
    +
  • There are security partitioning issues, such as company1 + does not want anyone at company2 to be able to read their + data except via the web. In this case you would need two + daemons, each running with different User, Group, Listen, and ServerRoot settings.
  • + +
  • You can afford the memory and file descriptor + requirements of listening to every IP alias on the + machine. It's only possible to Listen to the "wildcard" + address, or to specific addresses. So if you have a need to + listen to a specific address for whatever reason, then you + will need to listen to all specific addresses. (Although one + httpd could listen to N-1 of the addresses, and another could + listen to the remaining address.)
  • +
+ +

Use a single daemon when:

+ +
    +
  • Sharing of the httpd configuration between virtual hosts + is acceptable.
  • + +
  • The machine services a large number of requests, and so + the performance loss in running separate daemons may be + significant.
  • +
+ +
top
+
+

Setting up multiple daemons

+ +

Create a separate httpd installation for each + virtual host. For each installation, use the Listen directive in the + configuration file to select which IP address (or virtual host) + that daemon services. e.g.

+ +
Listen 192.0.2.100:80
+ + +

It is recommended that you use an IP address instead of a + hostname (see DNS caveats).

+ +
top
+
+

Setting up a single daemon + with virtual hosts

+ +

For this case, a single httpd will service + requests for the main server and all the virtual hosts. The VirtualHost directive + in the configuration file is used to set the values of ServerAdmin, ServerName, DocumentRoot, ErrorLog and TransferLog + or CustomLog + configuration directives to different values for each virtual + host. e.g.

+ +
<VirtualHost 172.20.30.40:80>
+    ServerAdmin webmaster@www1.example.com
+    DocumentRoot "/www/vhosts/www1"
+    ServerName www1.example.com
+    ErrorLog "/www/logs/www1/error_log"
+    CustomLog "/www/logs/www1/access_log" combined
+</VirtualHost>
+
+<VirtualHost 172.20.30.50:80>
+    ServerAdmin webmaster@www2.example.org
+    DocumentRoot "/www/vhosts/www2"
+    ServerName www2.example.org
+    ErrorLog "/www/logs/www2/error_log"
+    CustomLog "/www/logs/www2/access_log" combined
+</VirtualHost>
+ + +

It is recommended that you use an IP address instead of a + hostname in the <VirtualHost> directive + (see DNS caveats).

+ +

Specific IP addresses or ports have precedence over their wildcard + equivalents, and any virtual host that matches has precedence over + the servers base configuration.

+ +

Almost any configuration directive can be + put in the VirtualHost directive, with the exception of + directives that control process creation and a few other + directives. To find out if a directive can be used in the + VirtualHost directive, check the Context using the + directive index.

+ +

SuexecUserGroup + may be used inside a + VirtualHost directive if the suEXEC + wrapper is used.

+ +

SECURITY: When specifying where to write log files, + be aware of some security risks which are present if anyone + other than the user that starts Apache has write access to the + directory where they are written. See the security tips document + for details.

+ +
+
+

Available Languages:  en  | + fr  | + ja  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/ip-based.html.fr.utf8 b/docs/manual/vhosts/ip-based.html.fr.utf8 new file mode 100644 index 0000000..c8ade5d --- /dev/null +++ b/docs/manual/vhosts/ip-based.html.fr.utf8 @@ -0,0 +1,213 @@ + + + + + +Support Apache des serveurs virtuels par IP - Serveur HTTP Apache Version 2.4 + + + + + + + +
<-
+

Support Apache des serveurs virtuels par IP

+
+

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

+
+
+ +
top
+
+

Système requis

+ +

Comme l'indique le terme par IP, le serveur + doit disposer de différentes paires adresses IP/port 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), et/ou utiliser + plusieurs numéros de port.

+ +

Selon la terminologie du serveur HTTP Apache, l'utilisation d'une + seule adresse IP avec plusieurs ports TCP s'apparente aussi à de + l'hébergement virtuel basé sur IP.

+
top
+
+

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

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 192.0.2.100:80
+ + +

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

+ +
top
+
+

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 172.20.30.40:80>
+    ServerAdmin webmaster@www1.example.com
+    DocumentRoot "/www/vhosts/www1"
+    ServerName www1.example.com
+    ErrorLog "/www/logs/www1/error_log"
+    CustomLog "/www/logs/www1/access_log" combined
+</VirtualHost>
+
+<VirtualHost 172.20.30.50:80>
+    ServerAdmin webmaster@www2.example.org
+    DocumentRoot "/www/vhosts/www2"
+    ServerName www2.example.org
+    ErrorLog "/www/logs/www2/error_log"
+    CustomLog "/www/logs/www2/access_log" combined
+</VirtualHost>
+ + +

Il est recommandé d'utiliser une adresse IP plutôt qu'un nom + de domaine comme argument à la directive <VirtualHost> + (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'directive index.

+ + +

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/ip-based.html.ja.utf8 b/docs/manual/vhosts/ip-based.html.ja.utf8 new file mode 100644 index 0000000..d8a1497 --- /dev/null +++ b/docs/manual/vhosts/ip-based.html.ja.utf8 @@ -0,0 +1,190 @@ + + + + + +Apache の IP ベースのバーチャルホストサポート - Apache HTTP サーバ バージョン 2.4 + + + + + + + +
<-
+

Apache の IP ベースのバーチャルホストサポート

+
+

翻訳済み言語:  en  | + fr  | + ja  | + ko  | + tr 

+
+
この日本語訳はすでに古くなっている + 可能性があります。 + 最近更新された内容を見るには英語版をご覧下さい。 +
+
+ +
top
+
+

システム要件

+ +

IP ベース という名前が示すように、サーバには + IP ベースのバーチャルホストそれぞれにつき、別々の IP アドレスが + 必要です。複数の物理コネクションを持っているマシンを用意するか、 + 最近のオペレーティングシステムでサポートされているバーチャル + インタフェース (詳細はシステムの説明書を読んでください。たいていは + "ip エイリアス" と呼ばれていて、設定には普通 "ifconfig" コマンドを + 使います) を使うかで実現できます。

+
top
+
+

Apache の設定方法

+ +

複数のホストをサポートするように Apache を設定する方法は + 二通りあります。別の httpd デーモンを各ホスト毎に実行するか、 + すべてのバーチャルホストをサポートするデーモンを一つ実行するかです。

+ +

以下のときには複数のデーモンを使うと良いでしょう:

+ +
    +
  • 会社1 はウェブ経由以外では会社2 からはデータを読まれたくない、 + といったセキュリティの分離の問題があるとき。この場合、それぞれ + User, Group, Listen, ServerRoot の設定が違う二つのデーモンを + 実行する必要があります。
  • + +
  • マシンのすべての IP エイリアスを listen するだけの + メモリとファイル記述子の余裕があるとき。Listen は「ワイルドカード」 + アドレスか、特定のアドレスのみを listen することができます。 + ですから、何らかの理由で特定のアドレスを listen しなけばならない + ときは、その特定のアドレスをすべて listen する必要があります。 + (ただし、一つの httpd が N-1 個のアドレスを listen し、 + 別の httpd が残りのアドレスを listen するといったことは可能です。)
  • +
+ +

以下のときには単独のデーモンを使うと良いでしょう:

+ +
    +
  • バーチャルホスト間での httpd の設定を共有してもよいとき。
  • + +
  • マシンが多くのリクエストを扱うため、別デーモンを実行することによる + 性能の低下の影響が著しいとき。
  • +
+ +
top
+
+

複数デーモンの設定

+ +

各バーチャルホストに対して別の httpd のインストールを行ないます。 + 設定ファイル中の Listen + ディレクティブを使って、 + 各インストールでデーモンが扱う IP アドレス (バーチャルホスト) + を選択します。例えば

+ +

+ Listen www.smallco.com:80 +

+ +

ここで、ホスト名の代わりに IP アドレスを使う方が推奨されていることに + 注意しておいてください + (DNS の注意事項 参照)。

+ +
top
+
+

複数のバーチャルホストの設定をした +デーモンを一つ設定する

+ +

この場合は、一つの httpd が主サーバとすべてのバーチャルホストのリクエストを + 処理します。設定ファイルの VirtualHost ディレクティブを使って、 + ServerAdmin, ServerName, DocumentRoot, ErrorLog, TransferLog + や CustomLog + 設定ディレクティブの値が各ホスト毎に異なる値に設定されるようにします。 + 例えば

+ +

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

+ +

ここで、ホスト名の代わりに IP アドレスを使う方が推奨されていることに + 注意しておいてください + (DNS の注意事項 参照)。

+ +

プロセス生成を制御するディレクティブやその他のいくつかのディレクティブを + 除いて、ほぼすべての設定ディレクティブを VirtualHost + ディレクティブの中に書くことができます。ディレクティブが VirtualHost + ディレクティブで使用できるかどうかは ディレクティブ索引を使ってコンテキストの + 欄を調べてください。

+ +

suEXECラッパーを使っている場合は、 + SuexecUserGroup + ディレクティブを VirtualHost + ディレクティブの中で使用することができます。

+ +

セキュリティ: ログファイルを書く場所を指定するときは、 + Apache を起動したユーザ以外がそのディレクトリに書き込み権限を + 持っている場合にセキュリティ上の危険があることに注意してください。 + 詳細はセキュリティのこつドキュメントを + 参照してください。

+ +
+
+

翻訳済み言語:  en  | + fr  | + ja  | + ko  | + tr 

+
top

コメント

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/ip-based.html.ko.euc-kr b/docs/manual/vhosts/ip-based.html.ko.euc-kr new file mode 100644 index 0000000..f6a306c --- /dev/null +++ b/docs/manual/vhosts/ip-based.html.ko.euc-kr @@ -0,0 +1,180 @@ + + + + + +ġ IP ȣƮ - Apache HTTP Server Version 2.4 + + + + + + + +
<-
+

ġ IP ȣƮ

+
+

:  en  | + fr  | + ja  | + ko  | + tr 

+
+
ֽ ƴմϴ. + ֱٿ ϼ.
+
+ +
top
+
+

ý 䱸

+ +

IP̶ ǹϵ + IP ȣƮ ٸ IP ּҸ + Ѵ. ̴ ǻ͸ Ʈ + ϰų, ֱ ü ϴ ̽ + (ڼ ý ϶. "ip aliases" + ϸ, "ifconfig" ɾ ) Ͽ ϴ.

+ +
top
+
+

ġ

+ +

ȣƮ ϵ ġ ϴ ΰ. + ϳ ȣƮ ϴ + ̰, ٸ ϳ ȣƮ ϴ Ѱ + ϴ ̴.

+ +

ϳ:

+ +
    +
  • ȸ2 ڰ ̿ ȸ1 ڷḦ + ϴ Ȼ ʿ . + ٸ User, Group, Listen, ServerRoot ؾ Ѵ.
  • + +
  • ޸𸮰 ְ, ǻ IP ٸ + ϱ(file descriptor) 䱸׵ Ѵ. "ϵī" + Ư ּҸ Listen ִ. ׷ +  Ư ּҸ ٸ ʿ䰡 ִٸ, ( + ּҸ ּҸ ٸ ٸ + ּҸ ٸ ) ּ + θ ٷ Ѵ.
  • +
+ +

Ѱ ϳ:

+ +
    +
  • ȣƮ ִ .
  • + +
  • ǻͰ ſ û Ѵٸ + ϱ⿡ ӵ ս Ŭ ִ.
  • +
+ +
top
+
+

ϱ

+ +

ȣƮ ġѴ. + Listen þ + IP ּ(Ȥ ȣƮ) ش. + ,

+ +

+ Listen www.smallco.com:80 +

+ +

ȣƮ ٴ IP ּҸ ϱ ٶ. + (DNS )

+ +
top
+
+

ϳ ȣƮ ϱ

+ +

Ѱ ּ ȣƮ + û Ѵ. VirtualHost þ ȣƮ + ٸ ServerAdmin, + ServerName, DocumentRoot, ErrorLog, TransferLog, + CustomLog + þ Ѵ. ,

+ +

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

+ +

ȣƮ ٴ IP ּҸ ϱ ٶ. + (DNS )

+ +

VirtualHost þ ȿ μ Ÿ þ + ϰ þ + ִ. VirtualHost þ ȿ þ ִ + ˷ þ + + Ȯ϶.

+ +

suEXEC α׷ + Ѵٸ VirtualHost þ ȿ User Group ִ.

+ +

: ϴ ڿܿ ٸ + α ִ 丮 ִٸ + ϶. ڼ ϶.

+ +
+
+

:  en  | + fr  | + ja  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/ip-based.html.tr.utf8 b/docs/manual/vhosts/ip-based.html.tr.utf8 new file mode 100644 index 0000000..0397fd2 --- /dev/null +++ b/docs/manual/vhosts/ip-based.html.tr.utf8 @@ -0,0 +1,211 @@ + + + + + +IP’ye Dayalı Sanal Konak Desteği - Apache HTTP Sunucusu Sürüm 2.4 + + + + + + + +
<-
+

IP’ye Dayalı Sanal Konak Desteği

+
+

Mevcut Diller:  en  | + fr  | + ja  | + ko  | + tr 

+
+
+ +
top
+
+

IP'ye dayalı sanal konak desteği nedir

+

IP'ye dayalı sanal konak desteği, bir isteğin alındığı IP adresi ve + porta bağlı olarak farklı yönergeleri uygulamak için bir yoldur. Özetle, + farklı siteleri farklı portlardan ve arayüzlerden sunmakta + kullanılır.

+ +

Çoğu durumda, isme dayalı sanal konaklar + birçok sanal konağın tek bir IP adresi/port çiftini paylaşmasını + sağladığından daha kullanışlıdır. Neyi kullanacağınıza karar vermek için + İsme dayalı ve IP’ye dayalı Sanal + Konaklar bölümüne bakınız.

+
top
+
+

Sistem gereksinimleri

+ +

IP’ye dayalı deyince, sunucunun her IP’ye dayalı + sanal konak için ayrı bir IP adresi/port çiftine sahip olduğunu + anlıyoruz. Bunun olması için, makine ya çok sayıda ağ bağlantısına + sahiptir ya da makinede, günümüzde çoğu işletim sistemi tarafından + desteklenen sanal arabirimler ve/veya çok sayıda port kullanılıyordur. + (Sanal arabirimlerle ilgili ayrıntılar için sistem belgelerinize bakınız; + bu konu genellikle IP rumuzları (ip aliases) olarak geçer ve ayarlamak + için genellikle "ifconfig" komutu kullanılır.)

+ +

Apache HTTP Sunucusu terminolojisinde, tek bir IP adresinin çok sayıda + TCP portuyla kullanımı IP'ye dayalı sanal konak desteği olarak + bilinir.

+
top
+
+

Apache nasıl ayarlanır?

+ +

Çok sayıda konağı desteklemek üzere Apache iki şekilde + yapılandırılabilir. Ya her konak için ayrı bir httpd + süreci çalıştırırsınız ya da tüm sanal konakları destekleyen tek bir + süreciniz olur.

+ +

Çok sayıda süreç kullanıyorsanız:

+ +
    +
  • Güvenli bölgeler oluşturmanız gerekiyordur. Örneğin, şirket2’deki hiç + kimse dosya sistemi üzerinden şirket1’e ait verileri okuyamasın, sadece + herkes gibi tarayıcı kullanarak okuyabilsin istenebilir. Bu durumda, + User, + Group, + Listen ve + ServerRoot yönergeleri farklı + değerlerle yapılandırılmış iki ayrı süreç çalıştırmanız gerekir.
  • + +
  • Makine üzerindeki her IP adresini dinlemek için gereken dosya tanıtıcı + ve bellek miktarını makul bir seviyede tutabilirsiniz. Bu sadece belli + adresleri dinleyerek veya çok sayıda adresle eşleşen adres kalıpları + kullanarak mümükün olabilir. Zaten, bir sebeple belli bir adresi dinleme + ihtiyacı duyarsanız, diğer tüm adresleri de ayrı ayrı dinlemeniz + gerekir. (Bir httpd programı N-1 adresi dinlerken + diğerleri kalan adresleri dinleyebilir.)
  • +
+ +

Tek bir süreç kullanıyorsanız:

+ +
    +
  • httpd yapılandırmasının sanal konaklar arasında + paylaşılmasına izin veriliyor demektir.
  • + +
  • Makine çok büyük miktarda isteği karşılayabilir ve ayrı ayrı + süreçlerin çalışmasından kaynaklanan önemli başarım kayıpları + yaşanmaz.
  • +
+ +
top
+
+

Çok sayıda sürecin yapılandırılması

+ +

Her sanal konak için ayrı bir httpd yapılandırması + oluşturulur. Her yapılandırmada, o süreç tarafından sunulacak IP adresi + (veya sanal konak) için Listen + yönergesi kullanılır. Örnek:

+ +
Listen 192.0.2.100:80
+ + +

Burada konak ismi yerine IP adresi kullanmanız önerilir (ayrıntılar için + DNS ile ilgili konular belgesine + bakınız).

+ +
top
+
+

Sanal konaklar tek bir sürecin yapılandırılması

+ +

Bu durum için, ana sunucu ve sanal konakların tümüne gelen istekler tek + bir httpd süreci tarafından karşılanır. Yapılandırma + dosyasında, her sanal konak için, farklı değerlere sahip ServerAdmin, ServerName, DocumentRoot, ErrorLogveTransferLog + veya CustomLog yönergeleri + içeren ayrı birer VirtualHost bölümü + oluşturulur. Örnek:

+ +
<VirtualHost 192.168.1.10:80>
+    ServerAdmin bilgi@example.com
+    DocumentRoot "/siteler/belgeler/ecom"
+    ServerName example.com
+    ErrorLog "/siteler/gunlukler/ecom/hatalar.log"
+    CustomLog "/siteler/gunlukler/ecom/erisim.log" combined
+</VirtualHost>
+
+<VirtualHost 192.168.1.20:80>
+    ServerAdmin bilgi@example.org
+    DocumentRoot "/siteler/belgeler/eorg"
+    ServerName example.org
+    ErrorLog "/siteler/gunlukler/eorg/hatalar.log"
+    CustomLog "/siteler/gunlukler/eorg/erisim.log" combined
+</VirtualHost>
+ + +

<VirtualHost> yönergesinde konak ismi yerine + IP adresi kullanmanız önerilir (ayrıntılar için + DNS ile ilgili konular + belgesine bakınız).

+ +

Belli bir IP adresi veya port kullanımı bunların joker eşdeğerlerine + göre daha yüksek öncelik sağlar ve eşleşen bir sanal konak da genel + sunucuya göre öncelik alır.

+ +

Süreç oluşturmayı denetleyen yönergeler ve bir kaç başka yönerge dışında + hemen hemen tüm yapılandırma yönergeleri VirtualHost bölümleri içinde kullanılabilir. + Bir yönergenin VirtualHost + bölümlerinde kullanılıp kullanılmayacağını öğrenmek için yönerge dizinini kullanarak yönergenin + Bağlam’ına bakınız.

+ +

suEXEC sarmalayıcısı kullanıldığı takdirde + SuexecUserGroup yönergesi de + bir VirtualHost bölümü içinde + kullanılabilir.

+ +

GÜVENLİK:Günlük dosyalarının yazılacağı yeri belirlerken, + Apache’yi başlatan kullanıcıdan başka kimsenin yazamayacağı bir yerin + seçilmesi bazı güvenlik risklerini ortadan kaldırmak bakımından + önemlidir. Ayrıntılar için güvenlik + ipuçları belgesine bakınız.

+
+
+

Mevcut Diller:  en  | + fr  | + ja  | + ko  | + tr 

+
top

Yorumlar

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/mass.html b/docs/manual/vhosts/mass.html new file mode 100644 index 0000000..ff8663f --- /dev/null +++ b/docs/manual/vhosts/mass.html @@ -0,0 +1,17 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: mass.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: mass.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +URI: mass.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR + +URI: mass.html.tr.utf8 +Content-Language: tr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/vhosts/mass.html.en b/docs/manual/vhosts/mass.html.en new file mode 100644 index 0000000..f5af1e1 --- /dev/null +++ b/docs/manual/vhosts/mass.html.en @@ -0,0 +1,348 @@ + + + + + +Dynamically Configured Mass Virtual Hosting - Apache HTTP Server Version 2.4 + + + + + + + +
<-
+

Dynamically Configured Mass Virtual Hosting

+
+

Available Languages:  en  | + fr  | + ko  | + tr 

+
+ + +

This document describes how to efficiently serve an + arbitrary number of virtual hosts with the Apache HTTP Server. A + separate document discusses using + mod_rewrite to create dynamic mass virtual hosts. +

+ +
+ +
top
+
+

Motivation

+ +

The techniques described here are of interest if your + httpd.conf contains many + <VirtualHost> sections that are + substantially the same, for example:

+ +
<VirtualHost 111.22.33.44>
+    ServerName                 customer-1.example.com
+    DocumentRoot        "/www/hosts/customer-1.example.com/docs"
+    ScriptAlias  "/cgi-bin/"  "/www/hosts/customer-1.example.com/cgi-bin"
+</VirtualHost>
+
+<VirtualHost 111.22.33.44>
+    ServerName                 customer-2.example.com
+    DocumentRoot        "/www/hosts/customer-2.example.com/docs"
+    ScriptAlias  "/cgi-bin/"  "/www/hosts/customer-2.example.com/cgi-bin"
+</VirtualHost>
+
+<VirtualHost 111.22.33.44>
+    ServerName                 customer-N.example.com
+    DocumentRoot        "/www/hosts/customer-N.example.com/docs"
+    ScriptAlias  "/cgi-bin/"  "/www/hosts/customer-N.example.com/cgi-bin"
+</VirtualHost>
+ + +

We wish to replace these multiple + <VirtualHost> blocks with a mechanism + that works them out dynamically. This has a number of + advantages:

+ +
    +
  1. Your configuration file is smaller, so Apache starts + more quickly and uses less memory. Perhaps more importantly, the + smaller configuration is easier to maintain, and leaves less room + for errors.
  2. + +
  3. Adding virtual hosts is simply a matter of creating the + appropriate directories in the filesystem and entries in the + DNS - you don't need to reconfigure or restart Apache.
  4. +
+ +

The main disadvantage is that you cannot have a different log file for + each virtual host; however, if you have many virtual hosts, doing + this can be a bad idea anyway, because of the number of file descriptors needed. + It is better to log to a pipe or a fifo, + and arrange for the process at the other end to split up the log + files into one per virtual host. One example of such a process can + be found in the split-logfile + utility.

+ +
top
+
+

Overview

+ +

A virtual host is defined by two pieces of information: its + IP address, and the contents of the Host: header + in the HTTP request. The dynamic mass virtual hosting technique + used here is based on automatically inserting this information into the + pathname of the file that is used to satisfy the request. This + can be most easily done by using mod_vhost_alias + with Apache httpd. Alternatively, + mod_rewrite can + be used.

+

Both of these modules are disabled by default; you must enable + one of them when configuring and building Apache httpd if you want to + use this technique.

+ +

A couple of things need to be determined from the request in + order to make the dynamic + virtual host look like a normal one. The most important is the + server name, which is used by the server to generate + self-referential URLs etc. It is configured with the + ServerName directive, and it is available to CGIs + via the SERVER_NAME environment variable. The + actual value used at run time is controlled by the UseCanonicalName + setting. With UseCanonicalName Off, the server name + is taken from the contents of the Host: header in the + request. With UseCanonicalName DNS, it is taken from a + reverse DNS lookup of the virtual host's IP address. The former + setting is used for name-based dynamic virtual hosting, and the + latter is used for IP-based hosting. If httpd cannot work out + the server name because there is no Host: header, + or the DNS lookup fails, then the value configured with + ServerName is used instead.

+ +

The other thing to determine is the document root (configured + with DocumentRoot and available to CGI scripts via the + DOCUMENT_ROOT environment variable). In a normal + configuration, this is used by the core module when + mapping URIs to filenames, but when the server is configured to + do dynamic virtual hosting, that job must be taken over by another + module (either mod_vhost_alias or + mod_rewrite), which has a different way of doing + the mapping. Neither of these modules is responsible for + setting the DOCUMENT_ROOT environment variable so + if any CGIs or SSI documents make use of it, they will get a + misleading value.

+ +
top
+
+

Dynamic Virtual Hosts with +mod_vhost_alias

+ +

This extract from httpd.conf implements the + virtual host arrangement outlined in the Motivation section above + using mod_vhost_alias.

+ +
# get the server name from the Host: header
+UseCanonicalName Off
+
+# this log format can be split per-virtual-host based on the first field
+# using the split-logfile utility.
+LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog "logs/access_log" vcommon
+
+# include the server name in the filenames used to satisfy requests
+VirtualDocumentRoot "/www/hosts/%0/docs"
+VirtualScriptAlias  "/www/hosts/%0/cgi-bin"
+ + +

This configuration can be changed into an IP-based virtual + hosting solution by just turning UseCanonicalName + Off into UseCanonicalName DNS. The server + name that is inserted into the filename is then derived from + the IP address of the virtual host. The variable %0 + references the requested servername, as indicated in the + Host: header.

+ +

See the mod_vhost_alias documentation for more usage +examples.

+ +
top
+
+

Simplified Dynamic Virtual Hosts

+ +

This is an adjustment of the above system, tailored for an + ISP's web hosting server. Using %2, + we can select substrings of the server name to + use in the filename so that, for example, the documents for + www.user.example.com are found in + /home/user/www. It uses a single cgi-bin + directory instead of one per virtual host.

+ +
UseCanonicalName Off
+
+LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog "logs/access_log" vcommon
+
+# include part of the server name in the filenames
+VirtualDocumentRoot "/home/%2/www"
+
+# single cgi-bin directory
+ScriptAlias  "/cgi-bin/"  "/www/std-cgi/"
+ + +

There are examples of more complicated + VirtualDocumentRoot settings in the + mod_vhost_alias documentation.

+ +
top
+
+

Using Multiple Virtual + Hosting Systems on the Same Server

+ +

With more complicated setups, you can use httpd's normal + <VirtualHost> directives to control the + scope of the various virtual hosting configurations. For + example, you could have one IP address for general customers' homepages, + and another for commercial customers, with the following setup. + This can be combined with conventional + <VirtualHost> configuration sections, as shown + below.

+ +
UseCanonicalName Off
+
+LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
+
+<Directory "/www/commercial">
+    Options FollowSymLinks
+    AllowOverride All
+</Directory>
+
+<Directory "/www/homepages">
+    Options FollowSymLinks
+    AllowOverride None
+</Directory>
+
+<VirtualHost 111.22.33.44>
+    ServerName www.commercial.example.com
+
+    CustomLog "logs/access_log.commercial" vcommon
+
+    VirtualDocumentRoot "/www/commercial/%0/docs"
+    VirtualScriptAlias  "/www/commercial/%0/cgi-bin"
+</VirtualHost>
+
+<VirtualHost 111.22.33.45>
+    ServerName www.homepages.example.com
+
+    CustomLog "logs/access_log.homepages" vcommon
+
+    VirtualDocumentRoot "/www/homepages/%0/docs"
+    ScriptAlias         "/cgi-bin/" "/www/std-cgi/"
+</VirtualHost>
+ + +
+

Note

+

If the first VirtualHost block does not include a + ServerName directive, the reverse + DNS of the relevant IP will be used instead. + If this is not the server name you + wish to use, a bogus entry (eg. ServerName + none.example.com) can be added to get around this + behaviour.

+
+ +
top
+
+

More Efficient IP-Based Virtual Hosting

+ +

The configuration changes suggested to turn the first + example into an IP-based virtual hosting setup result in + a rather inefficient setup. A new DNS lookup is required for every + request. To avoid this overhead, the filesystem can be arranged to + correspond to the IP addresses, instead of to the host names, thereby + negating the need for a DNS lookup. Logging will also have to be adjusted + to fit this system.

+ +
# get the server name from the reverse DNS of the IP address
+UseCanonicalName DNS
+
+# include the IP address in the logs so they may be split
+LogFormat "%A %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog "logs/access_log" vcommon
+
+# include the IP address in the filenames
+VirtualDocumentRootIP "/www/hosts/%0/docs"
+VirtualScriptAliasIP  "/www/hosts/%0/cgi-bin"
+ + +
top
+
+

Mass virtual hosts with +mod_rewrite

+ +

+Mass virtual hosting may also be accomplished using +mod_rewrite, either using simple RewriteRule directives, or using more +complicated techniques such as storing the vhost definitions externally +and accessing them via RewriteMap. These techniques are +discussed in the rewrite +documentation.

+
top
+
+

Mass virtual hosts with mod_macro

+ +

Another option for dynamically generated virtual hosts is +mod_macro, with which you can create a virtualhost +template, and invoke it for multiple hostnames. An example of this is +provided in the Usage section of the module +documentation. +

+
+
+

Available Languages:  en  | + fr  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/mass.html.fr.utf8 b/docs/manual/vhosts/mass.html.fr.utf8 new file mode 100644 index 0000000..7415fc4 --- /dev/null +++ b/docs/manual/vhosts/mass.html.fr.utf8 @@ -0,0 +1,363 @@ + + + + + +Hébergement virtuel de masse configuré dynamiquement - Serveur HTTP Apache Version 2.4 + + + + + + + +
<-
+

Hébergement virtuel de masse configuré dynamiquement

+
+

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

+
+ + +

Ce document propose une méthode performante pour servir un nombre + quelconque d'hôtes virtuels avec le serveur HTTP Apache. Un document séparé décrit comment + utiliser mod_rewrite pour gérer l'hébergement + virtuel de masse dynamique. +

+ +
+ +
top
+
+

A qui ce document est-il destiné ?

+ +

Les techniques décrites ici vous concernent si votre + httpd.conf contient de nombreuses sections + <VirtualHost> très semblables, + dans le style :

+ +
<VirtualHost 111.22.33.44>
+    ServerName                 customer-1.example.com
+    DocumentRoot        "/www/hosts/customer-1.example.com/docs"
+    ScriptAlias  "/cgi-bin/" "/www/hosts/customer-1.example.com/cgi-bin"
+</VirtualHost>
+
+<VirtualHost 111.22.33.44>
+    ServerName                 customer-2.example.com
+    DocumentRoot        "/www/hosts/customer-2.example.com/docs"
+    ScriptAlias  "/cgi-bin/" "/www/hosts/customer-2.example.com/cgi-bin"
+</VirtualHost>
+
+<VirtualHost 111.22.33.44>
+    ServerName                 customer-N.example.com
+    DocumentRoot        "/www/hosts/customer-N.example.com/docs"
+    ScriptAlias  "/cgi-bin/" "/www/hosts/customer-N.example.com/cgi-bin"
+</VirtualHost>
+ + +

Nous voulons remplacer toutes les configurations + <VirtualHost> par un mécanisme qui les génère + dynamiquement. Ceci présente certains avantages :

+ +
    +
  1. Votre fichier de configuration est plus petit, ainsi Apache + démarre plus rapidement et consomme moins de mémoire. Et ce qui + est peut-être le plus important, le fichier de configuration plus + petit est plus facile à maintenir, et le risque d'erreurs en est + diminué d'autant. +
  2. + +
  3. Pour ajouter des serveurs virtuels, il suffit de créer les + répertoires appropriés dans le système de fichiers et les entrées + dans le DNS - il n'est plus nécessaire de reconfigurer ou de + redémarrer Apache.
  4. +
+ +

Le principal désavantage réside dans le fait que vous ne pouvez + pas définir un fichier journal différent pour chaque serveur + virtuel. De toute façon, ce serait une mauvaise idée si vous avez de + nombreux serveurs virtuels, car cela nécessiterait un nombre important de descripteurs de + fichier. Il est préférable de rediriger les journaux via un pipe ou + une file fifo vers un + programme, et faire en sorte que ce dernier éclate les journaux + en un journal par serveur virtuel. L'utilitaire split-logfile + constitue un exemple de ce traitement.

+ +
top
+
+

Vue d'ensemble

+ +

Un serveur virtuel peut être défini par deux informations : son + adresse IP, et le contenu de l'en-tête Host: de la + requête HTTP. La technique d'hébergement virtuel dynamique de masse + utilisée ici consiste à insérer automatiquement ces informations + dans le chemin du fichier à utiliser pour répondre à la requête. On + peut y parvenir assez facilement en utilisant + mod_vhost_alias avec Apache httpd, mais on peut aussi + utiliser mod_rewrite.

+

Par défaut, ces deux modules + sont désactivés ; vous devez activer l'un d'eux lors de la + compilation et de la configuration d'Apache httpd si vous voulez utiliser + cette technique.

+ +

Certains paramètres doivent être extraits de la requête pour que le serveur + dynamique se présente comme un serveur dynamique normal. Le plus + important est le nom du serveur, que le serveur utilise pour générer des + URLs d'auto-référencement, etc... Il est défini via la directive + ServerName, et les CGIs peuvent s'y référer via la + variable d'environnement SERVER_NAME. Sa véritable + valeur utilisée à l'exécution est contrôlée par la définition de la + directive + UseCanonicalName. Avec + UseCanonicalName Off, le nom du serveur correspond au + contenu de l'en-tête Host: de la requête. Avec + UseCanonicalName DNS, il est extrait d'une recherche + DNS inverse sur l'adresse IP du serveur virtuel. La première + configuration est utilisée pour l'hébergement virtuel dynamique par + nom, et la deuxième pour l'hébergement virtuel dynamique par IP. Si + httpd ne peut pas déterminer le nom du serveur, soit parce qu'il + n'y a pas d'en-tête Host:, soit parce que la recherche + DNS a échoué, il prend en compte la valeur définie par la directive + ServerName.

+ +

L'autre paramètre à extraire est la racine des documents (définie + via la directive DocumentRoot et disponible pour les + scripts CGI via la variable d'environnement DOCUMENT_ROOT). + Dans une configuration classique, il est utilisé par le module core + pour faire correspondre les URIs aux noms de fichiers, mais lorsque + la configuration du serveur comporte des serveurs virtuels, ce + traitement doit être pris en charge par un autre module (soit + mod_vhost_alias, soit mod_rewrite), qui + utilise un méthode de correspondance différente. Aucun de ces + modules ne se chargeant de définir la variable d'environnement + DOCUMENT_ROOT, si des CGIs ou des documents SSI + doivent en faire usage, ils obtiendront une valeur erronée.

+ +
top
+
+

Hébergement virtuel +dynamique avec mod_vhost_alias

+ +

Cet extrait de fichier httpd.conf implémente + l'hébergement virtuel décrit dans la section À qui ce document est-il destiné ? ci-dessus + en utilisant mod_vhost_alias.

+ +
# extrait le nom du serveur de l'en-tête Host:
+UseCanonicalName Off
+
+# ce format de journal peut être éclaté en journaux par serveur virtuel
+# à l'aide du premier champ via l'utilitaire split-logfile
+LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog "logs/access_log" vcommon
+
+# inclut le nom du serveur dans les noms de fichiers ressources
+# nécessaires aux traitements des requêtes
+VirtualDocumentRoot "/www/hosts/%0/docs"
+VirtualScriptAlias  "/www/hosts/%0/cgi-bin"
+ + +

Pour changer cette configuration en solution de serveur virtuel + par IP, il suffit de remplacer UseCanonicalName + Off par UseCanonicalName DNS. Le nom du serveur + inséré dans le nom de fichier sera alors déduit de l'adresse IP du + serveur virtuel. La variable %0 fait référence au nom + de serveur de la requête, tel qu'il est indiqué dans l'en-tête + Host:.

+ +

Voir la documentation du module mod_vhost_alias + pour d'avantages d'exemples d'utilisation.

+ +
top
+
+

Système de serveurs virtuels dynamiques +simplifié

+ +

Il s'agit d'une adaptation du système ci-dessus, ajusté pour un + serveur d'hébergement web de FAI. Grâce à la variable + %2, on peut extraire des sous-chaînes de caractères du + nom du serveur pour les utiliser dans le nom de fichier afin, par + exemple, de définir /home/user/www comme emplacement des + documents pour www.user.example.com. Un seul répertoire + cgi-bin suffit pour l'ensemble des + serveurs virtuels.

+ +
UseCanonicalName Off
+
+LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog "logs/access_log" vcommon
+
+# insertion d'une partie du nom du serveur dans les noms de fichiers
+VirtualDocumentRoot "/home/%2/www"
+
+# répertoire cgi-bin unique
+ScriptAlias  "/cgi-bin/"  "/www/std-cgi/"
+ + +

Vous trouverez des exemples plus élaborés d'utilisation de la + directive VirtualDocumentRoot dans la documentation du + module mod_vhost_alias.

+ +
top
+
+

Utiliser plusieurs systèmes +d'hébergement virtuel sur le même serveur

+ +

Moyennant une configuration un peu plus compliquée, vous pouvez + contrôler la portée des différentes configurations d'hébergement + virtuel à l'aide des directives <VirtualHost> + normales de httpd. Par exemple, on peut associer une adresse IP pour + les pages d'accueil des clients en général, et une autre pour les + clients commerciaux avec la configuration suivante. Cette + configuration peut être combinée avec les sections + <VirtualHost> conventionnelles, comme indiqué + plus loin.

+ +
UseCanonicalName Off
+
+LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
+
+<Directory "/www/commercial">
+    Options FollowSymLinks
+    AllowOverride All
+</Directory>
+
+<Directory "/www/homepages">
+    Options FollowSymLinks
+    AllowOverride None
+</Directory>
+
+<VirtualHost 111.22.33.44>
+    ServerName www.commercial.example.com
+    
+    CustomLog "logs/access_log.commercial" vcommon
+    
+    VirtualDocumentRoot "/www/commercial/%0/docs"
+    VirtualScriptAlias  "/www/commercial/%0/cgi-bin"
+</VirtualHost>
+
+<VirtualHost 111.22.33.45>
+    ServerName www.homepages.example.com
+    
+    CustomLog "logs/access_log.homepages" vcommon
+    
+    VirtualDocumentRoot "/www/homepages/%0/docs"
+    ScriptAlias         "/cgi-bin/" "/www/std-cgi/"
+</VirtualHost>
+ + +
+

Note

+

Si le premier bloc VirtualHost ne comporte pas de + directive ServerName, c'est + le nom issu d'une recherche DNS inverse à partir de l'adresse IP + du serveur virtuel qui sera utilisé. Si ce nom ne correspond pas + à celui que vous voulez utiliser, vous pouvez ajouter une entrée + de remplacement (par exemple ServerName + none.example.com) pour éviter ce comportement.

+
+ +
top
+
+

Pour un hébergement virtuel par IP plus +efficace

+ +

Les changements de configuration suggérés pour transformer le premier exemple en hébergement virtuel par IP + conduisent à une configuration peu efficace. Chaque requête + nécessite une nouvelle recherche DNS. Pour éviter cette surcharge de + travail, le système de fichiers peut être organisé pour correspondre + aux adresses IP, plutôt qu'aux noms de serveurs, supprimant par + la-même la nécessité d'une recherche DNS. La journalisation doit + aussi être adaptée pour fonctionner sur un tel système.

+ +
# obtention du nom du serveur par recherche DNS inverse
+# sur l'adresse IP
+UseCanonicalName DNS
+
+# insertion de l'adresse IP dans les journaux afin de pouvoir les
+# éclater
+LogFormat "%A %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog "logs/access_log" vcommon
+
+# insertion de l'adresse IP dans les noms de fichiers
+VirtualDocumentRootIP "/www/hosts/%0/docs"
+VirtualScriptAliasIP  "/www/hosts/%0/cgi-bin"
+ + +
top
+
+

Hébergement virtuel de masse avec +mod_rewrite

+ +

+L'hébergement virtuel de masse peut aussi être effectué en utilisant +mod_rewrite, soit à l'aide de simples directives RewriteRule, soit en utilisant des +techniques plus compliquées comme le stockage externe des définitions +des serveurs virtuels, ces dernières étant accessibles via des +directives RewriteMap. Ces +techniques sont décrites dans la documentation sur la réécriture.

+ +
top
+
+

Hébergement virtuel en masse avec mod_macro

+ +

Une autre option pour générer dynamiquement des serveurs virtuels : +mod_macro ; ce module permet de créer un modèle de serveur virtuel que +vous pourrez invoquer pour des noms d'hôtes multiples. La section +Usage de la documentation du module présente un exemple qui +illustre cette méthode. +

+
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/mass.html.ko.euc-kr b/docs/manual/vhosts/mass.html.ko.euc-kr new file mode 100644 index 0000000..d6d2f89 --- /dev/null +++ b/docs/manual/vhosts/mass.html.ko.euc-kr @@ -0,0 +1,453 @@ + + + + + +뷮 ȣƮ ϱ - Apache HTTP Server Version 2.4 + + + + + + + +
<-
+

뷮 ȣƮ ϱ

+
+

:  en  | + fr  | + ko  | + tr 

+
+
ֽ ƴմϴ. + ֱٿ ϼ.
+ + +

ġ 1.3 뷮 ȣƮ ȿ + ϴ Ѵ. +

+ +
+ +
top
+
+

+ +

httpd.conf + <VirtualHost> ǵ ִٸ ⼭ + ϴ ̴:

+ +

+NameVirtualHost 111.22.33.44
+<VirtualHost 111.22.33.44>
+ + ServerName www.customer-1.com
+ DocumentRoot /www/hosts/www.customer-1.com/docs
+ ScriptAlias /cgi-bin/ /www/hosts/www.customer-1.com/cgi-bin
+
+</VirtualHost>
+<VirtualHost 111.22.33.44>
+ + ServerName www.customer-2.com
+ DocumentRoot /www/hosts/www.customer-2.com/docs
+ ScriptAlias /cgi-bin/ /www/hosts/www.customer-2.com/cgi-bin
+
+</VirtualHost>
+# ٺ ٺ ٺ
+<VirtualHost 111.22.33.44>
+ + ServerName www.customer-N.com
+ DocumentRoot /www/hosts/www.customer-N.com/docs
+ ScriptAlias /cgi-bin/ /www/hosts/www.customer-N.com/cgi-bin
+
+</VirtualHost> +

+ +

<VirtualHost> + θ óϵ üϴ ̴. + ׷ ִ:

+ +
    +
  1. ۾ ġ ϰ ޸𸮸 + Ѵ.
  2. + +
  3. ȣƮ ߰ϱ Ͻýۿ + 丮 DNS ׸ ߰ϱ⸸ ϸȴ. , + ġ 缳ϰ ʿ䰡 .
  4. +
+ +

ȣƮ ٸ α ٴ + ̴. ׷ ſ ȣƮ Ѵٸ ϱڸ + ⶧ ٸ α . + fifo α׸ , ޴ α׸ óϿ + ( ִ) .

+ +
top
+
+

+ +

ȣƮ IP ּҿ HTTP û Host: + Ѵ. ⺻ 뷮 + ȣƮ ڵ ȣƮ û + ϰο Ѵ. ̴ κ mod_vhost_alias + Ͽ ذ , ġ 1.3.6 ϸ Ѵٸ + mod_rewrite ؾ Ѵ. + ⺻ Ե ʴ´. Ϸ + ġ ϰ Ҷ ؾ Ѵ.

+ +

ȣƮ Ϲ ȣƮó ̰Ϸ + `ӿ' Ѵ. ߿ ġ ڱ + URL 鶧 ̴. + ServerName þ ϸ, CGI + SERVER_NAME ȯ溯 ־. + UseCanonicalName ޷ȴ. + UseCanonicalName Off̸ û Host: + ȴ. UseCanonicalName DNS̸ + ȣƮ IP ּҸ DNS ˻Ͽ ˾Ƴ. + ڴ ̸ ȣƮ ϰ, ڴ IP + ȣƮ Ѵ. Host: ų + DNS ˻ Ͽ ġ ˾Ƴ ϸ + ServerName Ѵ.

+ +

ٸ `' (DocumentRoot ϸ, + CGI DOCUMENT_ROOT ȯ溯 ־) + Ʈ̴. Ϲ core Ͽ + URI شϴ ϸ ã, ȣ Ҷ ٸ + (mod_vhost_alias mod_rewrite) + ٸ ̷ ۾ Ѵ. + DOCUMENT_ROOT ȯ溯 Ƿ + CGI SSI Ѵٸ ߸ + ִ.

+ +
top
+
+

ȣƮ

+ +

ȣƮ + mod_vhost_alias Ͽ Ϲ + ߴ.

+ +

+# Host: ˾Ƴ
+UseCanonicalName Off
+
+# ù° ʵ带 Ͽ α׸ ȣƮ ִ
+LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog logs/access_log vcommon
+
+# û óϱ ϸ Ѵ
+VirtualDocumentRoot /www/hosts/%0/docs
+VirtualScriptAlias /www/hosts/%0/cgi-bin +

+ +

UseCanonicalName Off + UseCanonicalName DNS ϱ⸸ ϸ IP + ȣƮ ȴ. ȣƮ IP ּҸ + ϸ ߰ ִ.

+ +
top
+
+

ȣƮϴ Ȩ ý

+ +

ISP Ȩ ߴ. + ϸ www.user.isp.com + /home/user/ δ Ϻθ + ϸ ִ. + cgi-bin ȣƮ ʰ + ȣƮ Ѵ.

+ +

+# ⺻ . ׸
+
+# ϸ Ϻθ Ѵ
+VirtualDocumentRoot /www/hosts/%2/docs
+
+# ϳ cgi-bin 丮
+ScriptAlias /cgi-bin/ /www/std-cgi/
+

+ +

mod_vhost_alias + VirtualDocumentRoot ִ.

+ +
top
+
+

ȣƮ + ý ϱ

+ +

ġ Ϲ + <VirtualHost> þ Ͽ + ȣƮ ִ. , + Ȩ IP ּ Ѱ, + ٸ IP ּ Ѱ οѴ. ó + <VirtualHost> ǿ + ִ.

+ +

+UseCanonicalName Off
+
+LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
+
+<Directory /www/commercial>
+ + Options FollowSymLinks
+ AllowOverride All
+
+</Directory>
+
+<Directory /www/homepages>
+ + Options FollowSymLinks
+ AllowOverride None
+
+</Directory>
+
+<VirtualHost 111.22.33.44>
+ + ServerName www.commercial.isp.com
+
+ CustomLog logs/access_log.commercial vcommon
+
+ VirtualDocumentRoot /www/commercial/%0/docs
+ VirtualScriptAlias /www/commercial/%0/cgi-bin
+
+</VirtualHost>
+
+<VirtualHost 111.22.33.45>
+ + ServerName www.homepages.isp.com
+
+ CustomLog logs/access_log.homepages vcommon
+
+ VirtualDocumentRoot /www/homepages/%0/docs
+ ScriptAlias /cgi-bin/ /www/std-cgi/
+
+</VirtualHost> +

+ +
top
+
+

ȿ IP ȣƮ

+ +

ù° + IP ȣƮ ٲ ִٰ ߴ. + ׷ û DNS ãƾϹǷ ſ ȿ̴. + ̸ IP ּҷ Ͻý ϰ + α׸ ϸ ذ ִ. ġ + ٷ ʿ䰡 , DNS ˻ ʰ ȴ.

+ +

+# IP ּҸ DNS ˻Ͽ ˾Ƴ
+UseCanonicalName DNS
+
+# α׸ ֵ IP ּҸ Ѵ
+LogFormat "%A %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog logs/access_log vcommon
+
+# ϸ IP ּҸ Ѵ
+VirtualDocumentRootIP /www/hosts/%0/docs
+VirtualScriptAliasIP /www/hosts/%0/cgi-bin
+

+ +
top
+
+

ġ ϱ

+ +

ġ 1.3.6 Ŀ Ե + mod_vhost_alias Ѵ. + mod_vhost_alias ġ Ѵٸ + ̹ ߵ mod_rewrite Ͽ, + Host:- ȣƮ, ִ.

+ +

α׿ Ͽ ִ. ġ 1.3.6 + α þ %V ԵǾ, 1.3.0 + - 1.3.3 %v ɼ ߴ. ׷ + 1.3.4 ̷ .  ġ + .htaccess Ͽ UseCanonicalName + þ Ƿ α׿ ̻ ϵ ִ. + ׷Ƿ %{Host}i þ + Ͽ Host: α׿ ̴. + , %V ʴ :port + ڿ ߰ ִ.

+ +
top
+
+

mod_rewrite + ȣƮ

+ +

ù° ϴ + httpd.conf ̴. ó ù° + , ȣȯ mod_rewrite + Ǿ. ۾ + ϴ mod_rewrite Ѵ.

+ +

Ư ؾ ִ. ⺻ + mod_rewrite (mod_alias ) ٸ + URI ȴ. ׷ ٸ URI + Ͽ mod_rewrite ؾ Ѵ. + , ȣƮ ScriptAlias + ؼ Ư ۾ ʿϴ.

+ +

+# Host: ´
+UseCanonicalName Off
+
+# splittable logs
+LogFormat "%{Host}i %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog logs/access_log vcommon
+
+<Directory /www/hosts>
+ + # ScriptAlias CGI ⶧
+ # ⿡ ExecCGI Ѵ
+ Options FollowSymLinks ExecCGI
+
+</Directory>
+
+# κ̴
+
+RewriteEngine On
+
+# Host: ҹڰ ڼ ִ
+RewriteMap lowercase int:tolower
+
+## Ϲ óѴ:
+# Alias /icons/ ϵ - ٸ alias ؼ ݺ
+RewriteCond %{REQUEST_URI} !^/icons/
+# CGI ϵ
+RewriteCond %{REQUEST_URI} !^/cgi-bin/
+# Ư ۾
+RewriteRule ^/(.*)$ /www/hosts/${lowercase:%{SERVER_NAME}}/docs/$1
+
+## CGI óѴ - MIME type ؾ Ѵ
+RewriteCond %{REQUEST_URI} ^/cgi-bin/
+RewriteRule ^/(.*)$ /www/hosts/${lowercase:%{SERVER_NAME}}/cgi-bin/$1 [T=application/x-httpd-cgi]
+
+# ! +

+ +
top
+
+

mod_rewrite + Ȩ ý

+ +

ι° + Ѵ.

+ +

+RewriteEngine on
+
+RewriteMap lowercase int:tolower
+
+# CGI ϵ
+RewriteCond %{REQUEST_URI} !^/cgi-bin/
+
+# RewriteRule ϵ ȣƮ ùٸ ˻Ѵ
+RewriteCond ${lowercase:%{SERVER_NAME}} ^www\.[a-z-]+\.isp\.com$
+
+# ȣƮ URI տ δ
+# [C] ۼ Ѵ
+RewriteRule ^(.+) ${lowercase:%{SERVER_NAME}}$1 [C]
+
+# ϸ
+RewriteRule ^www\.([a-z-]+)\.isp\.com/(.*) /home/$1/$2
+
+# ü CGI 丮 Ѵ
+ScriptAlias /cgi-bin/ /www/std-cgi/ +

+ +
top
+
+

ȣƮ + ϱ

+ +

mod_rewrite Ͽ + ȣƮ Ʈ ˾Ƴ. + ʿϴ.

+ +

vhost.map :

+ +

+www.customer-1.com /www/customers/1
+www.customer-2.com /www/customers/2
+# ...
+www.customer-N.com /www/customers/N
+

+ +

http.conf :

+ +

+RewriteEngine on
+
+RewriteMap lowercase int:tolower
+
+# Ѵ
+RewriteMap vhost txt:/www/conf/vhost.map
+
+# alias óѴ
+RewriteCond %{REQUEST_URI} !^/icons/
+RewriteCond %{REQUEST_URI} !^/cgi-bin/
+RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$
+# ã´
+RewriteCond ${vhost:%1} ^(/.*)$
+RewriteRule ^/(.*)$ %1/docs/$1
+
+RewriteCond %{REQUEST_URI} ^/cgi-bin/
+RewriteCond ${lowercase:%{SERVER_NAME}} ^(.+)$
+RewriteCond ${vhost:%1} ^(/.*)$
+RewriteRule ^/(.*)$ %1/cgi-bin/$1 +

+ +
+
+

:  en  | + fr  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/mass.html.tr.utf8 b/docs/manual/vhosts/mass.html.tr.utf8 new file mode 100644 index 0000000..bfac687 --- /dev/null +++ b/docs/manual/vhosts/mass.html.tr.utf8 @@ -0,0 +1,334 @@ + + + + + +Devingen olarak Yapılandırılan Kitlesel Sanal Barındırma - Apache HTTP Sunucusu Sürüm 2.4 + + + + + + + +
<-
+

Devingen olarak Yapılandırılan Kitlesel Sanal Barındırma

+
+

Mevcut Diller:  en  | + fr  | + ko  | + tr 

+
+ + +

Bu belgede sanal konakların sonu belirsiz bir şekilde artışı karşısında + Apache HTTP Sunucusunun nasıl daha verimli kullanılacağı açıklanmıştır. + Devingen kitlesel konakları oluşturmak için mod_rewrite + modülünün kullanımını açıklayan ayrı bir + belge de mevcuttur. +

+ +
+ +
top
+
+

Amaç

+ +

Burada açıklanan teknikler, httpd.conf dosyanızın + örnekteki gibi, aslında hemen hemen birbirinin aynı çok sayıda + <VirtualHost> bölümü içereceği zaman yapılacaklar ile + ilgilidir.

+ +
<VirtualHost 111.22.33.44>
+    ServerName                 musteri-1.example.com
+    DocumentRoot        "/siteler/musteri-1/belgeler"
+    ScriptAlias  "/cgi-bin/"  "/siteler/musteri-1/cgi-bin"
+</VirtualHost>
+
+<VirtualHost 111.22.33.44>
+    ServerName                 musteri-2.example.com
+    DocumentRoot        "/siteler/musteri-2/belgeler"
+    ScriptAlias   "/cgi-bin/"   "/siteler/musteri-2/cgi-bin"
+</VirtualHost>
+
+<VirtualHost 111.22.33.44>
+    ServerName                 musteri-N.example.com
+    DocumentRoot          "/siteler/musteri-N/belgeler"
+    ScriptAlias   "/cgi-bin/"  "/siteler/musteri-N/cgi-bin"
+</VirtualHost>
+ + +

İsteğimiz çok sayıda <VirtualHost> bölümünü devingen + olarak çalışan tek bir <VirtualHost> bölümüyle + değiştirmektir. Bunun elbette bazı getirileri olacaktır:

+ +
    +
  1. Yapılandırma dosyanız küçüleceği için Apache daha çabuk + başlatılabilecek ve daha az bellek harcayacaktır. Muhtemelen daha da + önemlisi, küçülmüş bir yapılandırmanın bakımı da kolaylaşacağı için + hatalar da azalacaktır.
  2. + +
  3. Yeni sanal konakların eklenmesi, DNS’de yeni girdiler oluşturmak ve + dosya sisteminde bununla ilgili dizinleri açmak dışında biraz daha + basit olacaktır; en azından Apache’yi yeniden yapılandırmak ve yeniden + başlatmak zorunda kalmayacaksınız.
  4. +
+ +

Ana götürüsü ise her sanal konak için ayrı birer günlük dosyasına sahip + olamayacak olmanızdır. Öte yandan, dosya + tanıtıcılarının sınırlı olması nedeniyle bunu yapmayı zaten + istemezsiniz. Günlük kayıtları için bir fifo + veya bir boru hattı oluşturmak ve diğer uçta çalışan bir süreç + vasıtasıyla günlükleri müşterilere paylaştırmak daha iyidir. Böyle bir + işlemle ilgili bir örneği split-logfile aracının belgesinde bulabilirsiniz.

+ +
top
+
+

Genel Bakış

+ +

Bir sanal konak iki bilgiye bakarak belirlenir: IP adresi ve HTTP + isteğindeki Host: başlığının içeriği. Devingen sanal + barındırma tekniği, isteği yerine getirmek için kullanılacak dosya + yoluna bu bilgiyi kendiliğinden girmek esasına dayanır. Bu, Apache httpd + ile mod_vhost_alias modülünü kullanarak oldukça kolay + yapılabileceği gibi mod_rewrite modülü + de kullanılabilir.

+ +

Bu modüllerin her ikisi de öntanımlı olarak devre dışıdır. Bu tekniği + kullanmak isterseniz Apache httpd'yi yeniden yapılandırıp derleyerek bu + iki modülü etkin duruma getirmeniz gerekir.

+ +

Devingen sanal konağı normal bir sanal konak gibi göstermek için + bazı bilgileri istekten saptamak gerekir. Bunlardan en önemlisi, + httpd tarafından göreli URL’lerden normal URL’leri ve benzerlerini + üretmek için kullanılan sunucu ismidir. Sunucu ismi + ServerName yönergesi ile yapılandırılır ve CGI’ler + tarafından SERVER_NAME ortam değişkeni üzerinden + kullanılır. Çalışma anındaki asıl değer UseCanonicalName yönergesi tarafından denetlenir. + UseCanonicalName Off olduğunda sunucu ismi isteğin + Host: başlık alanından elde edilir. UseCanonicalName + DNS belirtilmişse, sunucu ismi, sanal konağın IP adresinden + tersine DNS sorgusu yapılarak elde edilir. Birincisi isme dayalı sanal + konaklar tarafından ikincisi ise IP’ye dayalı sanal konaklar tarafından + kullanılır. Eğer httpd, istekte Host: başlığının olmayışı + veya DNS sorgusunun başarısız olması sebebiyle sunucu ismini elde + edemezse son çare olarak ServerName yönergesinde yazılı + değeri kullanır.

+ +

Saptanan bilgilerden biri de DocumentRoot + yönergesi ile yapılandırılan belge kök dizini olup CGI’ler tarafından + DOCUMENT_ROOT ortam değişkeni üzerinden kullanılır. Normal + yapılandırmada core modülü tarafından dosya isimlerini + URI’lere eşlerken kullanılır. Fakat sunucu devingen sanal konakları + kullanmak üzere yapılandırıldığında, eşleştirmeyi farklı yollardan yapan + başka bir modül devreye girer (mod_vhost_alias veya + mod_rewrite). DOCUMENT_ROOT ortam + değişkenine değerini atamaktan sorumlu olan bu iki modülden biri + kullanılmazsa CGI veya SSI belgeleri yanlış değerlerle üretilirler.

+ +
top
+
+

mod_vhost_alias ile Kitlesel Sanal Konaklar

+ +

Yukarıda Amaç bölümünde özetlenen sanal konak + düzenlemesinin mod_vhost_alias kullanarak gerçekleştirilmiş + halini içeren httpd.conf bölümü aşağıdadır.

+ +
# sunucu ismini Host: başlığından elde edelim
+UseCanonicalName Off
+
+# Bu günlükleme biçiminde split-logfile aracı kullanılarak
+# sanal konak günlükleri ilk alana göre ayrıştırılabilir
+LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog "logs/access_log vcommon"
+
+# istekleri yerine getirmek için kullanılacak
+# dosya isimlerine sunucu ismini ekleyelim
+VirtualDocumentRoot "/siteler/%0/belgeler"
+VirtualScriptAlias  "/siteler/%0/cgi-bin"
+ + +

Bu yapılandırmayı IP’ye dayalı sanal konaklar için kullanmak isterseniz + UseCanonicalName Off yerine UseCanonicalName + DNS yazmanız yeterlidir. Böylece dosya ismine eklenecek konak + ismi sanal konağın IP adresinden türetilir. %0 değişkeni, + Host: başlığı ile belirlenen istekteki sunucu isminin + ifadesidir.

+ +

Kullanım örnekleri için mod_vhost_aliasmodülünün + belgesine bakınız.

+ +
top
+
+

Basitleştirilmiş Kitlesel Sanal Konaklar

+ +

Bu sistem, yukarıdaki yapılandırmanın bir ISS’nin sunucusuna + uyarlanmasından başka bir şey değildir. %2 değişkenini + kullanarak, dosya isminde kullanmak üzere sunucu isminin alt dizgelerini + seçebiliriz, böylece, örneğin www.user.example.com belgeleri + /home/user/www dizininde bulunabilir. Farklı olarak her + sanal konak için bir tane değil hepsi için bir tane cgi-bin + olacaktır.

+ +
UseCanonicalName Off
+
+LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog "logs/access_log" vcommon
+
+# sunucu ismini içerecek dosya isimlerini oluşturalım
+VirtualDocumentRoot "/home/%2/www"
+
+# ortak cgi-bin dizini
+ScriptAlias  "/cgi-bin/"  "/siteler/std-cgi/"
+ + +

mod_vhost_alias belgesinde daha karmaşık + VirtualDocumentRoot örnekleri vardır.

+ +
top
+
+

Aynı Sunucuda Kişisel ve Kurumsal Sanal Konaklar

+ +

Daha karmaşık ayarlamalar yaparak httpd’nin normal + <VirtualHost> bölümlerini farklı kitlesel sanal konak + yapılandırmaları için kullanabilirsiniz. Örneğin, bireysel + müşterileriniz için bir IP adresiniz, kurumsal müşterileriniz için de + başka bir IP adresiniz olsun. Her biri için ayrı ayrı sanal konaklar + ayarlamak yerine aşağıdaki gibi bir yapılandırma kullanabilirsiniz:

+ +
UseCanonicalName Off
+
+LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
+
+<Directory "/siteler/kurumsal">
+    Options FollowSymLinks
+    AllowOverride All
+</Directory>
+
+<Directory "/siteler/bireysel">
+    Options FollowSymLinks
+    AllowOverride None
+</Directory>
+
+<VirtualHost 111.22.33.44>
+    ServerName kurumsal.example.com
+
+    CustomLog "logs/access_log.kurumsal" vcommon
+
+    VirtualDocumentRoot "/siteler/kurumsal/%0/belgeler"
+    VirtualScriptAlias  "/siteler/kurumsal/%0/cgi-bin"
+</VirtualHost>
+
+<VirtualHost 111.22.33.45>
+    ServerName bireysel.example.com
+
+    CustomLog "logs/access_log.bireysel" vcommon
+
+    VirtualDocumentRoot "/siteler/bireysel/%0/belgeler"
+    ScriptAlias         "/cgi-bin/" "/siteler/std-cgi/"
+</VirtualHost>
+ + +

Bilginize

+

Eğer ilk <VirtualHost> bölümü bir ServerName yönergesi içermezse ilgili IP + için ters DNS sorgusu yapılır. Eğer sorgudan elde edilen isim + sunucunun ismi değilse bu istenmeyen duruma bir çözüm olarak bir + bilgilendirme bölümü (örn, ServerName bilgi.example.com) + eklenebilir.

+
+ +
top
+
+

IP’ye dayalı sanal konakları daha verimli kılmak

+ + +

İlk örnekte IP’ye dayalı sanal konaklar için + kullanılmak istenirse yapılandırmada neyin nasıl değiştirileceği + belirtilmişti. Her istek için ayrı bir DNS sorgusu gerekeceğinden bu + başarım düşmesine yol açar. DNS sorgusu ihtiyacını ortadan kaldırmak + için, bir çözüm olarak dosya sistemi, konak isimleri yerine IP + adreslerine göre düzenlenebilir. Günlük kayıtları da IP adreslerine göre + ayrıştırılacak şekilde ayarlanabilir.

+ +
# Sunucu ismini IP adresinden ters DNS sorgusu ile elde edelim
+UseCanonicalName DNS
+
+# Günlük kayıtları IP adreslerine göre ayrıştırılabilsin
+LogFormat "%A %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog "logs/access_log" vcommon
+
+# dosya isimleri IP adreslerini içersin
+VirtualDocumentRootIP "/siteler/%0/belgeler"
+VirtualScriptAliasIP  "/siteler/%0/cgi-bin"
+ + +
top
+
+

mod_rewrite ile Kitlesel Sanal Konaklar

+ + +

Kitlesel sanal barındırma mod_rewrite modülü kullanarak + da gerçeklenebilir. Ya basitçe RewriteRule yönergelerini kullanırsınız ya da daha karmaşık + olarak sanal konak tanımlarınızı harici bir yerde tutar ve bunlara + RewriteMap yönergesini + kullanarak erişirsiniz. Bu teknikler ayrıntılı olarak + rewrite belgelerinde + açıklanmıştır.

+ +
top
+
+

mod_macro ile Kitlesel Sanal Konaklar

+ + +

Devingen olarak üretilen sanal konaklar için diğer bir seçenek + mod_macro modülüdür. Bir sanal konak şablonu oluşturup + bunu çok sayıda konak ismi için çağırabilirsiniz. Modül belgelerinin + Kullanım bölümünde böyle bir örneğe yer verilmiştir.

+
+
+

Mevcut Diller:  en  | + fr  | + ko  | + tr 

+
top

Yorumlar

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/name-based.html b/docs/manual/vhosts/name-based.html new file mode 100644 index 0000000..26593d7 --- /dev/null +++ b/docs/manual/vhosts/name-based.html @@ -0,0 +1,25 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: name-based.html.de +Content-Language: de +Content-type: text/html; charset=ISO-8859-1 + +URI: name-based.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: name-based.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +URI: name-based.html.ja.utf8 +Content-Language: ja +Content-type: text/html; charset=UTF-8 + +URI: name-based.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR + +URI: name-based.html.tr.utf8 +Content-Language: tr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/vhosts/name-based.html.de b/docs/manual/vhosts/name-based.html.de new file mode 100644 index 0000000..7bdf376 --- /dev/null +++ b/docs/manual/vhosts/name-based.html.de @@ -0,0 +1,299 @@ + + + + + +Unterstützung namensbasierter virtueller Hosts - Apache HTTP Server Version 2.4 + + + + + + + +
<-
+

Unterstützung namensbasierter virtueller Hosts

+
+

Verfügbare Sprachen:  de  | + en  | + fr  | + ja  | + ko  | + tr 

+
+
Diese Übersetzung ist möglicherweise + nicht mehr aktuell. Bitte prüfen Sie die englische Version auf + die neuesten Änderungen.
+ +

Das Dokument beschreibt, wann und wie namensbasierte virtuelle Hosts zu + verwenden sind.

+
+ +
top
+
+

Namensbasierte gegenüber IP-basierten + virtuellen Hosts

+ +

IP-basierte virtuelle Hosts verwenden die IP-Adresse der Verbindung, um den + korrekten virtuellen Host zur Bedienung einer Anfrage zu ermitteln. Folglich + benötigen Sie eine IP-Adresse für jeden virtuellen Host. Bei der + Verwendung von namensbasierten virtuellen Hosts verläßt sich der + Server darauf, dass der Client den Hostnamen als Bestandteil der HTTP-Header + angibt. Durch Anwendung dieser Technik können sich mehrere verschiedene + Hosts die gleiche IP-Adresse teilen.

+ +

Die Verwendung von namensbasierten virtuellen Hosts ist gewöhnlich + einfacher. Sie müssen lediglich Ihren DNS-Server darauf einstellen, + jeden Hostnamen auf die richtige IP-Adresse abzubilden, und dann den Apache + HTTP Server so konfigurieren, dass er die verschiedenen Hostnamen erkennt. + Namensbasierte virtuelle Hosts entschärfen auch den Bedarf an + knappen IP-Adressen. Daher sollten Sie namensbasierte virtuelle Hosts + verwenden, sofern kein besonderer Grund dafür existiert, IP-basierte + virtuelle Hosts zu wählen. Mögliche Gründe für die + Verwendung IP-basierter virtueller Hosts sind:

+ +
    +
  • Einige antike Clients sind nicht kompatibel zu namensbasierten + virtuellen Hosts. Damit namensbasierte virtuelle Hosts funktionieren, + muss der Client den HTTP-Host-Header senden. Dies ist bei HTTP/1.1 + vorgeschrieben und in allen modernen HTTP/1.0-Browsern als Erweiterung + implementiert. Wenn Sie Unterstützung für veraltete Clients + benötigen und dennoch namensbasierte virtuelle Hosts verwenden, + dann finden Sie eine mögliche Lösung dafür am Ende des + Dokuments.
  • + +
  • Namensbasierte virtuelle Hosts können aufgrund der Natur des + SSL-Protokolls nicht mit SSL-gesicherten Servern verwendet werden.
  • + +
  • Einige Betriebssysteme und Netzwerkanlagen setzen Techniken zum + Bandbreiten-Management ein, die nicht zwischen Hosts unterscheiden + können, wenn diese nicht auf verschiedenen IP-Adressen liegen.
  • +
+ +
top
+
+

Die Verwendung von namensbasierten virtuellen Hosts

+ + + +

Um namensbasierte virtuelle Hosts zu verwenden, müssen Sie die + IP-Adresse (und möglicherweise den Port) des Servers benennen, an + der Anfragen für die Hosts entgegengenommen werden. Dies wird mit + der Direktive NameVirtualHost + eingestellt. Im Normalfall, wenn alle IP-Adressen des Server verwendet + werden sollen, können Sie * als Argument für + NameVirtualHost verwenden. Wenn Sie + vorhaben, mehrere Ports zu nutzen (etwa wenn SSL läuft), sollten + Sie dem Argument einen Port hinzufügen, wie zum Beispiel + *:80. Beachten Sie, + dass die Angabe einer IP-Adresse in einer NameVirtualHost-Anweisung den Server nicht + automatisch an dieser Adresse lauschen läßt. Lesen Sie bitte "Bestimmen der vom Apache verwendeten Adressen und + Ports" für weitere Details. Zusätzlich muss jede hier + angegebene IP-Adresse einer Netzwerkkarte des Servers zugeordnet sein.

+ +

Der nächste Schritt ist die Erstellung eines <VirtualHost>-Blocks für jeden einzelnen + Host, den Sie bedienen wollen. Das Argument der Direktive <VirtualHost> sollte das gleiche + sein wie das Argument der NameVirtualHost-Anweisung (d.h. eine IP-Adresse + oder * für alle Adressen). Innerhalb jedes <VirtualHost>-Blocks benötigen + Sie zumindestens eine ServerName-Anweisung, um zu bestimmen, welcher + Host bedient wird, und eine DocumentRoot-Anweisung, um anzugeben, wo im + Dateisystem der Inhalt des Hosts abgelegt ist.

+ +

Der Hauptserver verschwindet

+ Wenn Sie virtuelle Hosts zu einem bestehenden Webserver hinzufügen, + müssen Sie auch einen <VirtualHost>-Block für den bestehenden Host + (Anm.d.Ü.: und bisherigen Hauptserver) erstellen. + Die ServerName- und + DocumentRoot-Anweisungen zu diesem + virtuellen Host sollten die gleichen sein wie die globalen ServerName- und DocumentRoot-Anweisungen. Führen Sie diesen + virtuellen Host als erstes in der Konfigurationsdatei auf, so dass er als + Standard-Host fungiert. +
+ +

Vorausgesetzt, Sie bedienen z.B. die Domain + www.domain.tld und möchten den virtuellen Host + www.otherdomain.tld hinzufügen, welcher auf + die gleiche IP-Adresse zeigt. Dann fügen Sie einfach Folgendes der + httpd.conf hinzu:

+ +

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

+ +

Sie können anstelle des * bei den beiden Anweisungen + NameVirtualHost und <VirtualHost> alternativ eine + eindeutige IP-Adresse angeben. Das kann man beispielsweise machen, um + einige namensbasierte virtuelle Hosts auf einer IP-Adresse zu betreiben und + entweder IP-basierte oder ein anderes Set von namensbasierten virtuellen + Hosts auf einer anderen Adresse.

+ +

Viele Server wollen unter mehr als einem Namen erreichbar sein. Die + Direktive ServerAlias, die innerhalb + des <VirtualHost>-Abschnittes angegeben wird, + ermöglicht dies. Zum Beispiel zeigt die ServerAlias-Anweisung in dem ersten <VirtualHost>-Block oben an, dass die + aufgeführten Namen alternative Namen sind, die man verwenden kann, um + das gleiche Webangebot zu erreichen:

+ +

+ ServerAlias domain.tld *.domain.tld +

+ +

Anfragen für alle Hosts der Domain domain.tld werden + von dem virtuellen Host www.domain.tld bedient. Die + Platzhalter * und ? können anstelle + entsprechender Namen verwendet werden. Natürlich können Sie nicht + einfach Namen erfinden und diese bei ServerName oder ServerAlias + angeben, Sie müssen zunächst Ihren DNS Server entsprechend + konfigurieren, dass er diese Namen auf die mit Ihrem Server verknüpfte + IP-Adresse abbildet.

+ +

Und schlußendlich können Sie die Konfiguration der virtuellen + Hosts mittels Angabe weiterer Direktiven innherhalb der <VirtualHost>-Container + feineinstellen. Die meisten Direktiven können in diesen Containern + angegeben werden und verändern dann ausschließlich die + Konfiguration des entsprechenden virtuellen Hosts. Prüfen Sie den Kontext einer Direktive, um + herauszufinden, ob eine bestimmte Direktive zulässig ist. + Im Hauptserver-Kontext (außerhalb der <VirtualHost>-Container) definierte + Konfigurationsanweisungen werden nur dann angewendet, wenn sie nicht durch + Einstellungen des virtuellen Hosts außer Kraft gesetzt wurden.

+ +

Wenn nun eine Anfrage eintrifft, prüft der Server zuerst, ob sie eine + IP-Adresse verwendet, die der NameVirtualHost-Anweisung entspricht. Ist dies der + Fall, dann sieht er sich jeden <VirtualHost>-Abschnitt mit einer passenden + IP-Adresse an und versucht den einen zu finden, dessen ServerName- oder ServerAlias-Anweisung mit dem gewünschten + Hostnamen übereinstimmt. Findet er einen, dann verwendet er die + Konfiguration dieses Servers. Wird kein passender virtueller Host gefunden, + dann wird der erste angegeben virtuelle Host verwendet, + dessen IP-Adresse paßt.

+ +

Die Folge davon ist, dass der erste aufgeführte virtuelle Host der + Standard-Virtual-Host ist. Die DocumentRoot-Anweisung des Hauptservers + wird niemals verwendet, wenn eine IP-Adresse mit einer + NameVirtualHost-Anweisung + übereinstimmt. Wenn Sie eine spezielle Konfiguration für Anfragen + angeben möchten, die keinem bestimmten virtuellen Host entsprechen, + packen Sie diese Konfiguration einfach in einen <VirtualHost>-Container und führen diesen als + erstes in der Konfigurationsdatei auf.

+ +
top
+
+

Kompatibilität mit älteren Browsern

+ +

Wie zuvor erwähnt gibt es einige Clients, die nicht die notwendigen + Daten senden, mit denen namensbasierte virtuelle Hosts korrekt + funktionieren. Diesen Clients werden stets die Seiten des ersten, für + diese IP-Adresse aufgeführten virtuellen Hosts gesendet werden (des + primären namensbasierten virtuellen Hosts).

+ +

Was bedeutet älter?

+

Beachten Sie bitte, wenn wir von älter sprechen, meinen wir auch + älter. Es ist sehr unwahrscheinlich, dass sie einen dieser Browser + heutzutage in Verwendung finden werden. Alle aktuellen Browser-Versionen + senden den Host-Header, so wie er für namensbasierte + virtuelle Hosts benäötigt wird.

+
+ +

Mit der Direktive ServerPath existiert + eine mögliche Behelfskonstruktion, obgleich sie etwas schwerfällig + ist:

+ +

Beispielkonfiguration:

+ +

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

+ +

Was bedeutet das? Es bedeutet, dass eine Anfrage für eine mit + "/domain" beginnende URI von dem virtuellen Host + www.domain.tld bedient wird. Dies heißt, dass die Seiten + für alle Clients unter http://www.domain.tld/domain/ + abrufbar sind, wenngleich Clients, die den Header Host: + senden, auch über http://www.domain.tld/ auf sie zugreifen + können.

+ +

Legen Sie einen Link auf der Seite Ihres primären virtuellen Hosts zu + http://www.domain.tld/domain/, um die Behelfslösung + verfügbar zu machen. Bei den Seiten der virtuellen Hosts müssen + Sie dann sicherstellen, entweder außschließlich relative Links + (z.B. "file.html" oder + "../icons/image.gif") zu verwenden oder Links, die das + einleitende /domain/ enthalten (z.B., + "http://www.domain.tld/domain/misc/file.html" oder + "/domain/misc/file.html").

+ +

Dies erfordert etwas Disziplin, die Befolgung dieser Richtlinien stellt + jedoch größtenteils sicher, dass Ihre Seiten mit allen Browsern + funktionieren, alten wie neuen.

+ +
+
+

Verfügbare Sprachen:  de  | + en  | + fr  | + ja  | + ko  | + tr 

+
top

Kommentare

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/name-based.html.en b/docs/manual/vhosts/name-based.html.en new file mode 100644 index 0000000..e2496a3 --- /dev/null +++ b/docs/manual/vhosts/name-based.html.en @@ -0,0 +1,224 @@ + + + + + +Name-based Virtual Host Support - Apache HTTP Server Version 2.4 + + + + + + + +
<-
+

Name-based Virtual Host Support

+
+

Available Languages:  de  | + en  | + fr  | + ja  | + ko  | + tr 

+
+ +

This document describes when and how to use name-based virtual hosts.

+
+ +
top
+
+

Name-based vs. IP-based Virtual Hosts

+ +

IP-based virtual hosts use the IP address of the connection to + determine the correct virtual host to serve. Therefore you need to + have a separate IP address for each host.

+ +

With name-based virtual hosting, the server relies on the client to + report the hostname as part of the HTTP headers. Using this technique, + many different hosts can share the same IP address.

+ +

Name-based virtual hosting is usually simpler, since you need + only configure your DNS server to map each hostname to the correct + IP address and then configure the Apache HTTP Server to recognize + the different hostnames. Name-based virtual hosting also eases + the demand for scarce IP addresses. Therefore you should use + name-based virtual hosting unless you are using equipment + that explicitly demands IP-based hosting. Historical reasons for + IP-based virtual hosting based on client support are no longer + applicable to a general-purpose web server.

+ +

Name-based virtual hosting builds off of the IP-based virtual host + selection algorithm, meaning that searches for the proper server name + occur only between virtual hosts that have the best IP-based address.

+ +
top
+
+

How the server selects the proper name-based virtual host

+ +

It is important to recognize that the first step in name-based virtual + host resolution is IP-based resolution. Name-based virtual host + resolution only chooses the most appropriate name-based virtual host + after narrowing down the candidates to the best IP-based match. Using a wildcard (*) + for the IP address in all of the VirtualHost directives makes this + IP-based mapping irrelevant.

+ +

When a request arrives, the server will find the best (most specific) matching + <VirtualHost> argument based on + the IP address and port used by the request. If there is more than one virtual host + containing this best-match address and port combination, Apache will further + compare the ServerName and ServerAlias directives to the server name + present in the request.

+ +

If you omit the ServerName + directive from any name-based virtual host, the server will default + to a fully qualified domain name (FQDN) derived from the system hostname. + This implicitly set server name can lead to counter-intuitive virtual host + matching and is discouraged.

+ +

The default name-based vhost for an IP and port combination

+

If no matching ServerName or ServerAlias is found in the set of + virtual hosts containing the most specific matching IP address and port + combination, then the first listed virtual host that + matches that will be used.

+
top
+
+

Using Name-based Virtual Hosts

+ + + +

The first step is to create a <VirtualHost> block for + each different host that you would like to serve. Inside each <VirtualHost> block, you will need at minimum a + ServerName directive to designate + which host is served and a DocumentRoot + directive to show where in the filesystem the content for that host + lives.

+ +

Main host goes away

+

Any request that doesn't match an existing <VirtualHost> is handled by the global + server configuration, regardless of the hostname or ServerName.

+ +

When you add a name-based virtual host to an existing server, and + the virtual host arguments match preexisting IP and port combinations, + requests will now be handled by an explicit virtual host. In this case, + it's usually wise to create a default virtual host + with a ServerName matching that of + the base server. New domains on the same interface and port, but + requiring separate configurations, can then be added as subsequent (non-default) + virtual hosts.

+
+ +

ServerName inheritance

+

It is best to always explicitly list a ServerName in every name-based virtual host.

+

If a VirtualHost doesn't specify + a ServerName, a server name will be + inherited from the base server configuration. If no server name was + specified globally, one is detected at startup through reverse DNS resolution + of the first listening address. In either case, this inherited server name + will influence name-based virtual host resolution, so it is best to always + explicitly list a ServerName in every + name-based virtual host.

+
+ +

For example, suppose that you are serving the domain + www.example.com and you wish to add the virtual host + other.example.com, which points at the same IP address. + Then you simply add the following to httpd.conf:

+ +
<VirtualHost *:80>
+    # This first-listed virtual host is also the default for *:80
+    ServerName www.example.com
+    ServerAlias example.com 
+    DocumentRoot "/www/domain"
+</VirtualHost>
+
+<VirtualHost *:80>
+    ServerName other.example.com
+    DocumentRoot "/www/otherdomain"
+</VirtualHost>
+ + +

You can alternatively specify an explicit IP address in place of the + * in <VirtualHost> directives. For example, you might want to do this + in order to run some name-based virtual hosts on one IP address, and either + IP-based, or another set of name-based virtual hosts on another address.

+ +

Many servers want to be accessible by more than one name. This is + possible with the ServerAlias + directive, placed inside the <VirtualHost> section. For example in the first <VirtualHost> block above, the + ServerAlias directive indicates that + the listed names are other names which people can use to see that same + web site:

+ +
ServerAlias example.com *.example.com
+ + +

then requests for all hosts in the example.com domain will + be served by the www.example.com virtual host. The wildcard + characters * and ? can be used to match names. + Of course, you can't just make up names and place them in ServerName or ServerAlias. You must + first have your DNS server properly configured to map those names to an IP + address associated with your server.

+ +

Name-based virtual hosts for the best-matching set of <virtualhost>s are processed + in the order they appear in the configuration. The first matching ServerName or ServerAlias is used, with no different precedence for wildcards + (nor for ServerName vs. ServerAlias).

+ +

The complete list of names in the VirtualHost + directive are treated just like a (non wildcard) + ServerAlias.

+ +

Finally, you can fine-tune the configuration of the virtual hosts + by placing other directives inside the <VirtualHost> containers. Most directives can be + placed in these containers and will then change the configuration only of + the relevant virtual host. To find out if a particular directive is allowed, + check the Context of the + directive. Configuration directives set in the main server context + (outside any <VirtualHost> + container) will be used only if they are not overridden by the virtual host + settings.

+ +
+
+

Available Languages:  de  | + en  | + fr  | + ja  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/name-based.html.fr.utf8 b/docs/manual/vhosts/name-based.html.fr.utf8 new file mode 100644 index 0000000..062c0a9 --- /dev/null +++ b/docs/manual/vhosts/name-based.html.fr.utf8 @@ -0,0 +1,267 @@ + + + + + +Support Apache des serveurs virtuels par nom - Serveur HTTP Apache Version 2.4 + + + + + + + +
<-
+

Support Apache des serveurs virtuels par nom

+
+

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

+
+ +

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

+
+ +
top
+
+

Serveurs virtuels par nom vs. par IP

+ +

Les serveurs 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 serveur.

+ +

Avec un hébergement + virtuel par nom, le serveur s'appuie 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, sauf dans le cas où vous utiliseriez des équipements qui + nécessitent un hébergement basé sur IP. Les raisons historiques de + l'hébergement basé sur IP dans un but de support de certains clients ne + s'appliquent plus à un serveur web d'usage général.

+ +

La sélection du serveur virtuel en fonction du nom s'opère en + dehors de l'algorithme de sélection du serveur virtuel en fonction + de l'adresse IP, ce qui signifie que les recherches du point de vue + du nom du serveur ne s'effectuent que parmi le jeu de serveurs + virtuels pour lesquels la correspondance avec la paire adresse + IP/port est la plus exacte.

+ +
top
+
+

Comment le serveur sélectionne-t-il le serveur +virtuel basé sur le nom approprié

+ +

Il est important de savoir que la première étape de la résolution + de serveur virtuel basée sur le nom est une résolution basée sur IP. + La résolution de serveur virtuel basée sur le nom ne fait que + choisir le serveur virtuel basé sur le nom le plus approprié, en se + limitant aux candidats qui conviennent le mieux du point de vue IP. + La résolution basée sur IP est sans objet si l'on + utilise un caractère générique (*) pour l'adresse IP dans + toutes les directives VirtualHost.

+ +

A l'arrivée d'une requête, le serveur va rechercher l'argument de + section <VirtualHost> présentant la meilleure + (la plus exacte) correspondance avec la paire adresse IP/port + utilisée dans la requête. Si plusieurs serveurs virtuels possèdent + cette même paire adresse IP/port, Apache va ensuite comparer les + valeurs des directives ServerName et ServerAlias avec le nom de serveur + présent dans la requête.

+ +

Si vous ne définissez pas de directive ServerName pour un serveur virtuel à base + de nom, le serveur utilisera par défaut le nom de domaine + entièrement qualifié (FQDN) déduit du nom d'hôte système. Cette + configuration sans nom de serveur explicite peut conduire à des + erreurs de choix du serveur virtuel à utiliser et est déconseillée.

+ +

Le serveur virtuel à base de nom + par défaut pour une paire adresse IP/port

+

Si aucune directive ServerName ou ServerAlias ne correspond dans + la liste de serveurs virtuels présentant la meilleure correspondance + du point de vue adresse IP/port, c'est le premier serveur + virtuel de cette liste qui sera utilisé.

+ + +
top
+
+

Utilisation de serveurs virtuels par nom

+ + + + +

La première étape consiste à créer une section + <VirtualHost> + pour chacun des serveurs à définir. 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

+

Toute requête qui ne correspond à aucune section <VirtualHost> existante + est traitée avec la configuration du serveur principal, sans + tenir compte du nom d'hôte ou de la directive ServerName.

+ +

Lorsque vous ajoutez un serveur virtuel basé sur le nom à un + serveur existant, et si les caractéristiques de ce serveur + virtuel correspondent à des combinaisons IP/port préexistantes, + les requêtes seront alors traitées par un serveur virtuel + explicite. Dans ce cas, il est en général judicieux de créer un + serveur virtuel par défaut + comportant une directive ServerName correspondant au nom du + serveur principal. De nouveaux domaines sur les mêmes interface + et port, mais nécessitant des configurations distinctes, + pourront alors être ajoutés en tant que serveurs virtuels + spécifiques (et non par défaut).

+
+ +

Héritage du nom de serveur

+

Il est toujours préférable de définir une directive ServerName au niveau de chaque serveur + virtuel à base de nom. Si un serveur virtuel ne définit pas + de directive ServerName, le + nom de ce serveur virtuel sera hérité du serveur principal. Si + aucun nom de serveur n'a été explicitement défini au niveau du + serveur principal, le serveur tentera de déterminer son nom via + une résolution de nom DNS inverse sur la première adresse + d'écoute. Dans tous les cas, ce nom de serveur hérité influencera + la sélection du serveur virtuel à base de nom, c'est pourquoi il + est toujours préférable de définir une directive ServerName pour chaque serveur virtuel + à base de nom.

+
+ +

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

+ +
<VirtualHost *:80>
+    # Le premier serveur virtuel de la liste est aussi le
+    # serveur par défaut pour *:80
+    ServerName www.example.com
+    ServerAlias example.com
+    DocumentRoot "/www/domain"
+</VirtualHost>
+
+<VirtualHost *:80>
+    ServerName other.example.com
+    DocumentRoot "/www/otherdomain"
+</VirtualHost>
+ + +

Autrement, vous pouvez spécifiez une adresse IP explicite + à la place de * dans la directive + <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 example.com *.example.com
+ + +

ainsi, toutes les requêtes portant sur un domaine + example.com seront servies par le serveur virtuel + www.example.com. 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.

+ +

La recherche du serveur virtuel à base de nom qui correspond au + plus près à la requête s'effectue parmi les <virtualhost> selon leur + ordre d'apparition dans le fichier de configuration. Le premier + serveur virtuel dont le ServerName ou le ServerAlias correspond est utilisé, sans + priorité particulière en cas de présence de caractères génériques + (que ce soit pour le ServerName ou le ServerAlias).

+ +

La liste complète des noms dans la section VirtualHost sont traités comme une + directive ServerAlias sans + caractères génériques.

+ +

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 le contexte de la + directive. 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.

+ +
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/name-based.html.ja.utf8 b/docs/manual/vhosts/name-based.html.ja.utf8 new file mode 100644 index 0000000..2089756 --- /dev/null +++ b/docs/manual/vhosts/name-based.html.ja.utf8 @@ -0,0 +1,303 @@ + + + + + +名前ベースのバーチャルホスト - Apache HTTP サーバ バージョン 2.4 + + + + + + + +
<-
+

名前ベースのバーチャルホスト

+
+

翻訳済み言語:  de  | + en  | + fr  | + ja  | + ko  | + tr 

+
+
この日本語訳はすでに古くなっている + 可能性があります。 + 最近更新された内容を見るには英語版をご覧下さい。 +
+ +

この文書では名前ベースのバーチャルホストをどんなとき、 + どうやって使うかを説明します。

+
+ +
top
+
+

名前ベースと IP ベースのバーチャルホストの比較

+ +

IP ベースのバーチャルホストでは、応答する + バーチャルホストへのコネクションを決定するために IP + アドレスを使用します。ですから、それぞれのホストに個々に IP + アドレスが必要になります。これに対して名前ベースのバーチャルホストでは、 + クライアントが HTTP ヘッダの一部としてホスト名を告げる、 + ということに依存します。この技術で同一 IP + アドレスを異なる多数のホストで共有しています。

+ +

名前ベースのバーチャルホストは通常単純で、それぞれのホスト名と + それに対応する正確な IP アドレスを DNS で設定し、異なる + ホスト名を区別するように Apache HTTP サーバを設定するだけです。 + さらに、名前ベースのバーチャルホストは不足する IP + アドレスの需要を緩和します。したがって、IP ベースのバーチャルホストを + 選択すべき特定の理由がなければ名前ベースのバーチャルホストを使うべきです。 + IP ベースのバーチャルホストを使用することを考慮する理由として、

+ +
    +
  • 名前ベースのバーチャルホストに対応していない古いクライアントがある + 名前ベースのバーチャルホストが働くためには、クライアントは + HTTP ホストヘッダを送ってこなければなりません。 + これは HTTP/1.1 の仕様で要求されていて、すべての現代的な + HTTP/1.0 ブラウザでも拡張として実装されています。 + とても古いクライアントをサポートしつつ、名前ベースの + バーチャルホストを行いたい場合は、この文書の最後の方に + 書かれている解決策になるかもしれない方法を見てください。
  • + +
  • 名前ベースのバーチャルホストは SSL プロトコルの特徴により、 + SSL セキュアサーバには使えません。
  • + +
  • オペレーティングシステムやネットワーク装置のなかには、 + 別の IP アドレス上でない場合、複数のホストを別扱いできないような + 帯域管理の方法を実装しているものがあります。
  • +
+ +
top
+
+

名前ベースのバーチャルホストを利用する

+ + + +

名前ベースのバーチャルホストを使うには、そのホストへの + リクエストを受け付けるサーバの IP アドレス (もしかしたらポートも) + を指定する必要があります。 + これは NameVirtualHost + ディレクティブで設定します。通常、NameVirtualHost で + * の属性を使ってサーバの全ての IP アドレスを使います。 + (例えば SSL の使用などで) 複数のポートを使うことを計画しているのであれば、 + 引数に *:80 のようにポートも含めるようにしてください。 + NameVirtualHost ディレクティブで + IP アドレスを書いても、 + 自動的にサーバがその IP アドレスをリッスンするということはないことに + 注意してください。詳細は「Apache の使うアドレスと + ポートを設定する」を読んでください。さらに、ここで指定された + IP アドレスは全てサーバのネットワークインターフェースと関連付けられて + いなければなりません。

+ +

次は、扱うホストそれぞれに対して <VirtualHost> ブロックを + 作成してください。<VirtualHost> + ディレクティブの引数は NameVirtualHost + ディレクティブの引数と同じにしてください (すなわち、IP アドレスか、全てのアドレスを意味する + *)。それぞれの <VirtualHost> + ディレクティブの中には、最低限、どのホストが扱われるかを示す ServerName ディレクティブと、 + そのホスト用のコンテンツがファイルシステム上のどこにあるかを示す + DocumentRoot ディレクティブを + 書く必要があります。

+ +

メインホストはなくなります

+

既にあるウェブサーバにバーチャルホストを追加する場合、 + 既存のウェブサーバに対しても <VirtualHost> + ブロックを作らなければなりません。このバーチャルホストの + ServerName と + DocumentRoot + は、グローバルな ServerName と + DocumentRoot + と同じものにします。また、このバーチャルホストを設定ファイルの中で + 先頭に置いて、デフォルトホストとして動作するようにします。

+
+ +

たとえば、www.domain.tld を動かしていて、 + さらにバーチャルホスト www.otherdomain.tld + を追加するとしましょう。このバーチャルホストは同一 IP を指しているとします。 + そのような場合は、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>
+

+ +

NameVirtualHost 及び + VirtualHost のどちらの場合も、 + * の部分には明示的に IP アドレスを指定することができます。 + 例えば、ある IP アドレスでは名前ベースのバーチャルホストを使いたい一方で、 + 別の IP アドレスでは、他の IP ベースのバーチャルホストや + 別組の名前ベースのバーチャルホストを使いたい場合、 + そう設定することになるでしょう。

+ +

複数の名前でサーバアクセスができるようにしたいことも多いでしょう。 + このようなことは、ServerAlias ディレクティブを <VirtualHost> + セクションに記述することで実現できます。 + 例えば上記の <VirtualHost> の例であれば、 + 次のように一覧に挙げられた名前が、 + ユーザが同一のウェブサイトとして目にして使用できるサーバ名である、 + と ServerAlias + ディレクティブで指定できます。

+ +

+ ServerAlias domain.tld *.domain.tld +

+ +

domain.tld ドメインへの全てのホストへのリクエストは + www.domain.tld のバーチャルホストが処理します。 + 名前をマッチさせるために、ワイルドカード文字 * や ? + を使用することもできます。もちろん思いつきの名前を作って、 + ServerName や + ServerAlias + にその名前を書くといったことはできません。まずは、 + これらの名前が サーバに付けられた IP アドレスにマップされるように + DNS サーバを適切に設定しなければなりません。

+ +

最後に、<VirtualHost> コンテナの中に + 他のディレクティブを書くことで、バーチャルホストの設定を細かく調整 + することができます。 + ほとんどのディレクティブはこれらのコンテナに設置することができて、 + 変更点はそのバーチャルホストに対してのみ有効になります。 + どのディレクティブを書くことができるかは、ディレクティブの コンテキスト を + 調べてください。主サーバコンテキスト + (<VirtualHost> + コンテナの外) の設定用ディレクティブはバーチャルホストでの設定で + 上書きされない場合のみ使用されます。

+ +

リクエストが来ると、サーバはまず最初に <NameVirtualHost> + にマッチする IP アドレスかどうかをチェックします。マッチすれば + マッチした IP アドレスの <VirtualHost> + のそれぞれのセクションの中から + ServerName か + ServerAlias + に要求されたホスト名があるか探します。 + 見つかればそのサーバ用の設定を使います。マッチするバーチャルホスト + が見つからなければ、マッチした IP アドレスの + リストの最初にあるバーチャルホスト が使われます。

+ +

結果として、リストの最初のバーチャルホストが デフォルト の + バーチャルホストになります。IP アドレスが NameVirtualHost + ディレクティブにマッチした場合は、メインのサーバ の + DocumentRoot + は決して使われません + どのバーチャルホストにもマッチしないリクエストに対して、 + 特別な設定をしたいのであれば、設定ファイル中の最初の + <VirtualHost> コンテナにそれを記述してください。

+ +
top
+
+

古いブラウザとの互換性

+ +

以前述べたように、名前ベースのバーチャルホストが正しく動作する + ために必要な情報を送ってこないクライアントが依然として存在しています。 + そのようなクライアントに対しては、該当する IP アドレスについて、 + 一番最初に設定されているバーチャルホスト + (プライマリの名前ベースのバーチャルホスト) + からページが送り返されます。

+ +

どのぐらい古いの ?

+

「古い」と表現している場合、本当に古いことを意味して使っています。 + 不幸にして今現在でもこのような古いブラウザに遭遇することがあります。 + 現在のブラウザは全て、名前ベースのバーチャルホストに必要な + Host ヘッダを送ります。

+
+ +

ServerPath + ディレクティブで対処が可能です。ちょっと不格好ですけれども。

+ +

設定例

+ +

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

+ +

この例にはどういう意味があるでしょうか? これは + "/domain" で始まる URI へのリクエストはすべて、 + バーチャルホスト www.domain.tld で処理される、 + という意味です。つまり、すべてのクライアントで + http://www.domain.tld/domain/ でアクセスできるページが、 + Host: ヘッダを送ってくるクライアントであれば + http://www.domain.tld/ としてもアクセスできる、 + という意味です。

+ +

これが動作するようにするには、 + プライマリのバーチャルホストのページに + http://www.domain.tld/domain/ へのリンクを設置します。 + そして、バーチャルホストのページでは、純粋な相対リンク (例: + "file.html" や "../icons/image.gif")、 + あるいは /domain/ で始まるリンク (例: + "http://www.domain.tld/domain/misc/file.html" や + "/domain/misc/file.html") だけを設置します。

+ +

これには、幾分かの規律が必要となりますが、 + このようなガイドラインを忠実に守ることにより、たいていの場合、 + すべてのブラウザで ― 新しいブラウザでも古いものでも ― + 作成したページが見えるということを保証します。

+ +
+
+

翻訳済み言語:  de  | + en  | + fr  | + ja  | + ko  | + tr 

+
top

コメント

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/name-based.html.ko.euc-kr b/docs/manual/vhosts/name-based.html.ko.euc-kr new file mode 100644 index 0000000..86f7d2a --- /dev/null +++ b/docs/manual/vhosts/name-based.html.ko.euc-kr @@ -0,0 +1,266 @@ + + + + + +̸ ȣƮ - Apache HTTP Server Version 2.4 + + + + + + + +
<-
+

̸ ȣƮ

+
+

:  de  | + en  | + fr  | + ja  | + ko  | + tr 

+
+
ֽ ƴմϴ. + ֱٿ ϼ.
+ +

̸ ȣƮ ϴ + Ѵ.

+
+ +
top
+
+

̸ IP ȣƮ

+ +

IP ȣƮ IP ּҸ + ȣƮ Ѵ. ׷ ȣƮ ٸ IP ּҸ + Ѵ. ̸ ȣƮ Ŭ̾Ʈ + HTTP ȣƮ ˷ֱ ٶ. ̷ + IP ּҷ ٸ ȣƮ ִ.

+ +

̸ ȣƮ DNS ȣƮ ùٸ + IP ּҷ ϵ ȣƮ ϰ, ٸ ȣƮ + ֵ ġ ϱ⸸ ϸǹǷ ϴ. ̸ + ȣƮ IP ּҰ ʿ. ׷Ƿ Ư + IP ȣƮ ٸ ̸ ȣƮ + ؾ Ѵ. IP ȣƮ ؾ δ:

+ +
    +
  • ̸ ȣƮ ʴ + Ŭ̾Ʈ ִ. ̸ ȣƮ Ϸ + Ŭ̾Ʈ HTTP Host Ѵ. ̴ + HTTP/1.1 ʼ̰, ֱ HTTP/1.0 鵵 + Ȯ Ѵ. ̸ ȣƮ ϸ鼭 + Ŭ̾Ʈ ؾ Ѵٸ ִ + .
  • + +
  • SSL ݻ SSL ȼ ̸ + ȣƮ .
  • + +
  •  ü Ʈ ġ ٸ IP ּҸ + ȣƮ ϴ Ʈ 뷮(bandwidth) + Ѵ.
  • +
+ +
top
+
+

̸ ȣƮ ϱ

+ + + +

̸ ȣƮ Ϸ + IP ּҸ (Ƹ Ʈ) ؾ Ѵ. ̴ NameVirtualHost þ ϴ. + Ϲ IP ּҸ Ѵٸ + NameVirtualHost + ƱԸƮ * Ѵ. Ʈ + ( , SSL ) ȹ̶ *:80 + ƱԸƮ Ʈ ߰ؾ Ѵ. NameVirtualHost þ IP ּҸ + ־ٰ ڵ IP ּҸ ٸ + ϶. ڼ ġ + ּҿ Ʈ ϱ ϶. , ⼭ + IP ּҴ Ʈ ̽̾ Ѵ.

+ +

ܰ Ϸ ȣƮ <VirtualHost> + ̴. <VirtualHost>> þ ƱԸƮ + NameVirtualHost þ + ƱԸƮ( , IP ּҳ ּҸ ϴ *) + ƾ Ѵ. <VirtualHost>> ȿ + ּ ȣƮ ϴ ServerName þ ȣƮ + Ͻý ִ ϴ DocumentRoot þ ʿϴ.

+ +

ȣƮ

+

ϴ ȣƮ ߰Ѵٸ + ϴ ȣƮ <VirtualHost> ϵ ߰ؾ + Ѵ. Ͽ ϴ ServerName DocumentRoot ü ServerName DocumentRoot ƾ Ѵ. + Ͽ ȣƮ ⺻ ȣƮ + ȴ.

+
+ +

www.domain.tld ϰ + ־µ IP ּҿ + www.otherdomain.tld ȣƮ ߰ϰ + ʹٰ . 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>
+

+ +

NameVirtualHost + <VirtualHost> + þ * IP ּҸ + ִ. , ̷ IP ּҿ ̸ + ȣƮ , ٸ ּҿ IP Ȥ ̸ + ȣƮ ִ.

+ +

 ̸ ֱ ٶ. ̴ + <VirtualHost> + ȿ ServerAlias + þ Ͽ ϴ. ù° <VirtualHost> Ͽ + ServerAlias þ + ϸ ̸ Ʈ ִ:

+ +

+ ServerAlias domain.tld *.domain.tld +

+ +

domain.tld ο ִ ȣƮ + û www.domain.tld ȣƮ Ѵ. + ̸ ٶ ϵī * ? + ִ. ServerName̳ ServerAlias + ̸ ־ٰ ƴϴ. ̸ + IP ּҷ ϵ DNS ˸° ؾ Ѵ.

+ +

<<VirtualHost>> ȿ ٸ + þ Ͽ ȣƮ ڼ ִ. + κ þ , õ ȣƮ + Ѵ.  þ 밡 ˷ þ + Ȯ϶. (<<VirtualHost>> ƴ) + ּ þ ȣƮ + þ 쿡 ȴ.

+ +

û NameVirtualHost IP + ּ ˻Ѵ. ׷ٸ IP ּҸ <VirtualHost> + ǵ鿡 û ȣƮ ġϴ ServerName̳ + ServerAlias ã´. ã Ѵ. + ȣƮ ãϸ, IP ּҿ شϴ + ȣƮ ù° Ѵ.

+ +

ó ȣƮ + ȣƮ ȴ. IP ּҰ NameVirtualHost þ شϸ, + ּ DocumentRoot + ʴ´. Ư ȣƮ + شʴ û Ϸ <VirtualHost> Ͽ + ϸ ȴ.

+ +
top
+
+

ȣȯ

+ +

̹ ̸ ȣƮ ùٷ ϱ + ʿ ʴ Ŭ̾Ʈ ִ. ̷ Ŭ̾Ʈ + ׻ û IP ּҿ ù° ȣƮ + ( ̸ ȣƮ) + Ѵ.

+ +

󸶳 ϴ°?

+

⼭ Ǿ Ѵ. + ó ̷ Ǿ. + ̸ ȣƮ ʿ Host + .

+
+ +

ణ 彺 ServerPath þ ذ ִ:

+ +

:

+ +

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

+ +

̰ ΰ? "/domain" ϴ + URI û ȣƮ www.domain.tld + Ѵ. , Host: Ŭ̾Ʈ + http://www.domain.tld/ε , + http://www.domain.tld/domain/δ + Ŭ̾Ʈ ִ.

+ +

̸ ȣƮ ִ + http://www.domain.tld/domain/ ũ + ִ´. ׸ ȣƮ 븵ũ ( , + "file.html" ̳ "../icons/image.gif") + Ȥ ("http://www.domain.tld/domain/misc/file.html"̳ + "/domain/misc/file.html" ) տ + /domain/ ũ Ѵ.

+ +

Ģ ʿ Ģ κ + ̳ ̳ + ִ.

+ +
+
+

:  de  | + en  | + fr  | + ja  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/vhosts/name-based.html.tr.utf8 b/docs/manual/vhosts/name-based.html.tr.utf8 new file mode 100644 index 0000000..3d51992 --- /dev/null +++ b/docs/manual/vhosts/name-based.html.tr.utf8 @@ -0,0 +1,238 @@ + + + + + +İsme Dayalı Sanal Konaklar - Apache HTTP Sunucusu Sürüm 2.4 + + + + + + + +
<-
+

İsme Dayalı Sanal Konaklar

+
+

Mevcut Diller:  de  | + en  | + fr  | + ja  | + ko  | + tr 

+
+ +

Bu belgede isme dayalı sanal konakların ne zaman, nasıl kullanılacakları + açıklanmıştır.

+
+ +
top
+
+

İsme dayalı ve IP’ye dayalı Sanal Konaklar

+ +

IP’ye dayalı sanal konaklarda sunulacak + sanal konağı doğru tespit edebilmek için bağlantının yapıldığı IP + adresine bakılır. Bu bakımdan her konak için ayrı bir IP adresine + gereksinim vardır.

+ +

İsme dayalı sanal konaklarda ise sunucu, istemcinin HTTP başlığının bir + parçası olarak gönderdiği konak adını kullanır. Bu teknikte aynı IP + adresini çok sayıda farklı konak kullanabilir.

+ +

İsme dayalı sanal barındırma nispeten daha kolaydır, çünkü her konak + ismini doğru IP adresiyle eşlemek için DNS sunucunuzu yapılandırdıktan + sonra Apache HTTP sunucusunu farklı konak isimlerini tanıyacak şekilde + yapılandırmanız yeterli olur. İsme dayalı sanal barındırma ayrıca zaten + kıt olan IP adreslerine talebi de azaltır. Bu nedenle, IP’ye dayalı sanal + konakları kullanmanızı gerektiren donanım kullanmadıkça isme dayalı + sanal konaklar kullanmalısınız. İstemci uyumuna bağlı IP’ye dayalı + sanal barındırma için eskiden varolan sebepler genel amaçlı bir HTTP + sunucusu için artık uygulanabilir değildir.

+ +

İsme dayalı sanal barındırma, IP'ye dayalı sanal barındırma seçim + algoritmasını kullanmaz, yani uygun sunucu ismini arama işlemi sadece en + iyi IP'ye dayalı adrese sahip sanal konaklar arasında gerçekleşir.

+ +
top
+
+

Sunucu isme dayalı sanal konaklardan uygun olanını nasıl seçer

+ + +

İsme dayalı sanal konak çözümlemesinin ilk adımının IP'ye dayalı + çözümleme olduğunun anlaşılması çok önemlidir. İsme dayalı sanal konak + çözümlemesi en uygun isme dayalı sanal konağı seçerken önce en iyi IP'ye + dayalı eşleşme adaylarının sayısını azaltır, sonra bunlar arasından en + uygununu seçer. Tüm VirtualHost yönergelerinde IP adresi + yerine joker kullanımı bu IP'ye dayalı eşlemeyi yersiz kılar.

+ +

Bir istek geldiğinde, sunucu, istekte kullanılan IP adresi ve portu ile + en iyi eşleşen <VirtualHost> bileşenini bulur. Bu IP adresi ve port çifti ile + eşleşen birden fazla sanal konak varsa, Apache httpd istekte kullanılan + sunucu ismini ServerName ve + ServerAlias yönergelerindeki + isimlerle karşılaştırır.

+ +

Herhangi bir isme dayalı sanal konakta ServerName yönergesini kullanmazsanız, sunucu + bu yönergeye sistem konak adından türetilmiş tam nitelenmiş alan adının + (FQDN) tanımlandığını varsayacaktır. Bu örtük atama sezgiselliğin + istenmediği bir sanal konak eşleşmesi ile sonuçlanabilir ve bu + önerilmez.

+ +

Bir IP adresi ve port çifti için öntanımlı isme dayalı sankon

+ +

ServerName ve + ServerAlias yönergelerinde bir + eşleşme bulunamazsa, Apache httpd bu çift ile eşleşen sanal + konaklar listesindeki ilk sanal konağı kullanır.

+ +
top
+
+

İsme Dayalı Sanal Konakların Kullanımı

+ + + +

İlk adım sunacağınız her konak için ayrı bir <VirtualHost> bölümü oluşturmaktır. Her + <VirtualHost> bölümü + içinde sunulan konağı belirtmek üzere en azından bir adet ServerName yönergesine ve konak içeriğinin + dosya sisteminde bulunduğu yeri gösteren bir DocumentRoot yönergesine ihtiyacınız + olacaktır.

+ +

Ana konağı unutmayın

+

Mevcut <VirtualHost> + yönergelerinin hiçbiriyle eşleşmeyen bir istek için, sunucu veya konak + ismine bakılmaksızın genel sunucu yapılandırmanız kullanılır.

+ +

Mevcut sitenize isme dayalı bir sanal konak eklerseniz ve bu sanal + konak ana sunucunun IP adresi ve portuna sahipse, ana sunucuya yapılan + istekler için bu sanal konak kullanılır. Bu bakımdan, ServerName yönergesi ana sunucununki ile aynı + olan bir öntanımlı sanal konak oluşturmak + akıllıca olacaktır. Aynı arayüz ve portu kullanan fakat farklı + yapılandırmalara sahip diğer alan isimlerinin sanal konakları (yani + öntanımlı olmayanlar) bu öntanımlı sanal konağın sonrasına + yerleştirilmelidir.

+
+ +

ServerName miras alma

+

İsme dayalı her sanal konak için daima bir ServerName belirtmek en iyisidir.

+ +

Eğer bir VirtualHost bölümü + içinde bir ServerName + belirtilmezse, sunucu ismi olarak ana sunucu yapılandırmasındaki isim + kullanılır. Orada da bir sunucu ismi belirtilmemişse, başlatma sırasında + dinlenen ilk IP adresinden ters DNS araması ile elde edilen isim + kullanılır. Her iki durumda da miras alınan isim gereksiz yere isme + dayalı sanal konak ismi haline gelecektir; bu bakımdan isme dayalı her + sanal konak için daima bir ServerName belirtmek en iyisidir.

+
+ +

Örnek olarak, site1.example.com adresinden sitenizi + sunmakta olduğunuzu ve bunun yanına aynı IP adresini kullanan + site2.example.com sanal konağını eklemek istediğinizi + varsayalım. Bunun için httpd.conf dosyanıza basitçe şu + satırları ekleyebilirsiniz:

+ +
<VirtualHost *:80>
+    #İlk sanal konak aynı zamanda *:80 için de öntanımlıdır.
+    ServerName site1.example.com
+    ServerAlias example.com
+    DocumentRoot "/siteler/site1"
+</VirtualHost>
+
+<VirtualHost *:80>
+    ServerName site2.example.com
+    DocumentRoot "/siteler/site2"
+</VirtualHost>
+ + +

İsterseniz, <VirtualHost> yönergesinde argüman olarak * + yerine doğrudan bir IP adresi belirtebilirsiniz. Hatta, daha sonra, isme + dayalı sanal konakları bir IP adresinden ve IP’ye dayalı olanları veya + isme dayalı diğer bir sanal konak grubunu diğer IP adreslerinden sunmak + isteyebilirsiniz.

+ +

Çoğu sunucunun birden fazla isim ile erişilebilir olması istenir. Bu, + <VirtualHost> bölümü + içine bir ServerAlias yönergesi + yerleştirmek suretiyle mümkün olur. Örneğin yukarıdaki örnekte, + kullanıcıların aynı siteye farklı isimlerle erişmelerini mümkün kılmak + için bölüm içine şu satırı ekleyebilirsiniz:

+ +
ServerAlias example.com *.example.com
+ + +

Böylece example.com alanındaki tüm konaklar için gelen + isteklere www.example.com sanal konağından hizmet sunulmuş + olur. Konak isimleriyle eşleşmek üzere dosya ismi kalıp karakterleri + * ve ? kullanılabilir. Şüphesiz bu isimleri + sırf ServerName veya + ServerAlias yönergesinde belirtmiş olmakla bu isimleri + erişilebilir kılamazsınız. Öncelikle, bu isimleri sunucunuzdaki IP + adresleriyle eşlemek üzere yapılandıracağınız bir DNS sunucunuz + olmalıdır.

+ +

İsme dayalı sanal konaklardan en iyi eşleşme kümesinde olanlar + yapılandırmada göründükleri sıraya göre işleme sokulur. Joker + kullanımları arasında fark gözetilmeksizin ServerName veya ServerAlias yönergesi eşleşen ilk sanal konak + kullanılır.

+ +

VirtualHost içindeki isimlerin sırası (jokersiz) bir + ServerAlias gibi ele alınır (fakat hiçbir + ServerAlias yönergesi ile geçersiz kılınmaz).

+ +

Son olarak, sanal konak yapılandırmanıza, <VirtualHost> bölümlerinin içine başka yönergeler + yerleştirerek ince ayar çekebilirsiniz. Çoğu yönerge bu bölümlere + yerleştirilebilir ve sadece o sanal konakla ilgili yapılandırmayı + değiştirmek için kullanılabilir. Belli bir yönergenin sanal konak + bölümlerinde kullanılıp kullanılmayacağını yönergenin açıklamasında Bağlam satırına bakarak + öğrenebilirsiniz. Ana sunucu bağlamındaki (<VirtualHost> bölümleri dışındaki) + yapılandırma yönergelerinden sadece sanal konak bölümlerinde geçersiz + kılınmamış olanlar kullanılacaktır.

+ +
+
+

Mevcut Diller:  de  | + en  | + fr  | + ja  | + ko  | + tr 

+
top

Yorumlar

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file -- cgit v1.2.3