Title: Tiefergehende Erörterung der Zuweisung virtueller Hosts
Der virtuelle Host-Code wurde für die Apache-Version 1.3
völlig umgeschrieben. Im folgenden wird versucht, genau zu erklären, was der
Apache tut, wenn er entscheidet, welcher virtuelle Host eine Anfrage bedienen soll.
Mit Hilfe der neuen
Für diejenigen, die es einfach zum Laufen bringen möchten, ohne zu verstehen zu wollen, wie es funktioniert, gibt es die Beispiele für virtuelle Hosts in typischen Situationen.
Für den Hauptserver gelten alle Definitionen außerhalb der
<VirtualHost>-Abschnitte. Die virtuellen Server oder
Vhosts werden in den
Die Direktiven
Der Standardwert des Listen-Felds ist für den Hauptserver
80. Einen standardmäßigen ServerPath oder
ServerAlias gibt es für den Hauptserver nicht. Der
standardmäßige ServerName wird von der IP-Adresse des
Servers abgeleitet.
Die Listen-Direktive des Hauptservers hat zwei
Funktionen. Zum einen definiert sie den Standardnetzwerk-Port, an den der
Apache gebunden wird. Zum anderen gibt sie die Port-Nummer an, die in
absoluten URIs bei Umleitungen benutzt wird.
Anders als beim Hauptserver beeinflussen die Vhost-Ports nicht, an welchen Ports der Apache auf Verbindungen reagiert.
Jede Adresse, die in der VirtualHost-Direktive erscheint,
kann einen optionalen Port besitzen. Wird der Port nicht angegeben, wird
standardmäßig der Wert der letzten Listen-Anweisung
des Hauptservers benutzt. Der spezielle Port mit dem Jokerzeichen
* steht für einen beliebigen Port. Die Gesamtmenge der Adressen
(einschließlich mehrerer Record A Ergebnisse von DNS-Suchen)
wird als Adressmenge des Vhost bezeichnet.
Wird keine * sein.
Sollen namensbasierte Vhosts benutzt werden, muss eine
NameVirtualHost-Direktive in Verbindung mit der
IP-Adressmenge für die namensbasierten Vhosts erscheinen. Anders ausgedrückt,
muss die IP-Adresse angegeben werden, die die Hostname-Aliase (CNAMEs)
für namensbasierte Vhosts mit einer NameVirtualHost-Direktive
in der Konfigurationsdatei erhält.
Es können mehrere NameVirtualHost-Direktiven mit jeweils
einer Reihe von VirtualHost-Direktiven benutzt werden, aber es darf
nur eine NameVirtualHost-Direktive für jedes spezielle
IP-Adresse:Port-Paar benutzt werden.
Die Reihenfolge der NameVirtualHost- und der
VirtualHost-Direktiven spielt keine Rolle, daher sind die beiden
folgenden Beispiele gleichbedeutend (nur die Reihenfolge der
VirtualHost-Direktiven für eine Adressmenge
ist von Bedeutung):
<VirtualHost 111.22.33.44> # server A ... </VirtualHost> <VirtualHost 111.22.33.44> # server B ... </VirtualHost> NameVirtualHost 111.22.33.55 <VirtualHost 111.22.33.55> # server C ... </VirtualHost> <VirtualHost 111.22.33.55> # server D ... </VirtualHost> |
# server A </VirtualHost> <VirtualHost 111.22.33.55> # server C ... </VirtualHost> <VirtualHost 111.22.33.44> # server B ... </VirtualHost> <VirtualHost 111.22.33.55> # server D ... </VirtualHost> NameVirtualHost 111.22.33.44 NameVirtualHost 111.22.33.55 |
(Wegen der besseren Lesbarkeit wird die linke Variante empfohlen.)
Nach der Auswertung der VirtualHost-Direktive erhält der
Vhost-Server eine standardmäßige Listen-Anweisung entsprechend
dem dem ersten Namen in der VirtualHost-Direktive zugewiesenen
Ports.
Die Namen der vollständigen Liste aus der
VirtualHost-Direktive werden wie ein ServerAlias
behandelt (werden aber von keiner ServerAlias-Anweisung
überschrieben), wenn alle Namen für die gleiche Adressmenge aufgelöst werden.
Beachten Sie, das spätere Listen-Anweisungen für diesen
Vhost sich nicht auf die in der Adressmenge zugewiesenen Ports auswirken.
Während der Initialisierung wird für jede IP-Adresse eine Liste erzeugt und
in eine Hashtabelle eingefügt. Wird die IP-Adresse in einer
NameVirtualHost-Direktive verwendet, enthält die Liste alle
namensbasierten Vhosts für eine bestimmte IP-Adresse. Sind keine Vhosts
für diese Adresse definiert, wird die NameVirtualHost-Direktive
ignoriert und ein Fehler ins Protokoll eingetragen. Bei einem IP-basierten Vhost
ist die Liste in der Hashtabelle leer.
Dank einer schnellen Hash-Funktion ist der zusätzliche Aufwand für das Hashing einer IP-Adresse während einer Anfrage minimal und tritt meist gar nicht in Erscheinung. Darüber hinaus ist die Tabelle für IP-Adressen, die sich im letzten Oktett unterscheiden, optimiert.
Für jeden Vhost werden verschiedene Standardwerte gesetzt:
- Wird für einen Vhost keine
ServerAdmin -,ResourceConfig -,AccessConfig -,Timeout -,KeepAliveTimeout -,KeepAlive -,MaxKeepAliveAnfragen - oderSendBufferSize -Direktive angegeben, wird der entsprechende Wert vom Hauptserver übernommen. (Der jeweils als letzter für den Hauptserver gesetzte Wert.) - Die "Suchvorgaben", die die Standardverzeichnisrechte für einen Vhost definieren, werden mit denen des Hauptservers vermischt. Das schließt auch jede Konfiguration für eine Modul auf Verzeichnisebene ein.
- Die Konfigurationen der Module auf Verzeichnisebene des Hauptservers werden mit der Konfiguration des Vhost-Servers verschmolzen.
Im Wesentlichen wird der Hauptserver als "Vorgabe" oder "Basis" angesehen, auf der jeder Vhost basiert. Die Positionierung der Hauptserverdefinitionen in der Konfigurationsdatei ist weitgehend irrelevant: Die gesamte Konfiguration des Hauptservers wurde bereits ausgewertet, wenn diese abschließende Verschmelzung stattfindet. Eine Hauptserverdefinition, die aufeine Vhost-Definition folgt, kann sich daher auf die Vhost-Definition auswirken.
Wurde an dieser Stelle keine ServerName-Direktive
für den Hauptserver angegeben, wird stattdessen der Hostname des Rechners
genommen, auf dem httpd ausgeführt wird. Als Hauptserver-Adressmenge
werden jene IP-Adressen bezeichnet, die von einer DNS-Suche für den
ServerName des Hauptservers zurückgeliefert werden.
Für nicht definierte ServerName-Felder setzt ein
namensbasierter Vhost die erste in der VirtualHost-Anweisung
für die Definition des Vhost angegebene Adresse.
Jeder Vhost mit dem _default_-Joker erhält den gleichen
ServerName wie der Hauptserver.
Der Server ermittelt wie folgt, welchem Vhost er eine Anfrage zuteilt:
Stellt ein Client eine Verbindung her, wird die IP-Adresse der Client kommt, in der internen IP-Hashtabelle gesucht.
Bleibt die Suche erfolglos (die IP-Adresse wurde nicht gefunden), wird die
Anfrage vom _default_-Vhost bearbeitet, wenn ein solcher
Vhost für den Port, an den der Client die Anfrage gesendet hat, vorhanden ist.
Gibt es keinen passenden _default_-Vhost, wird die Anfrage vom
Hauptserver beantwortet.
Wird die IP-Adresse nicht in der Hashtabelle gefunden, kann der Vergleich
mit der Port-Nummer auch zu einem Eintrag
NameVirtualHost * führen, der später wie andere
namensbasierte Vhosts behandelt wird.
War die Suche erfolgreich (es wurde eine entsprechende Liste für die IP-Adresse gefunden), wird im nächsten Schritt entschieden, ob es sich um einen IP-basierten oder einen namensbasierten Vhost handelt.
Enthält der gefundene Eintrag eine leere Namensliste, dann wurde ein IP-basierter Vhost gefunden. Weitere Aktionen werden nicht durchgeführt, die Anfrage wird von diesem Vhost bedient.
Gehört der Eintrag zu einem namensbasierten Vhost, enthält die
Namensliste eine oder mehrere Vhost-Strukturen. Diese Liste enthält die Vhosts
in der gleichen Reihenfolge, in der die VirtualHost-Direktiven
in der Konfigurationsdatei stehen.
Der erste Vhost dieser Liste (der erste Vhost in der Konfigurationsdatei mit der
angegebenen IP-Adresse) hat die höchste Priorität und übernimmt jede Anfrage
an einen unbekannten Server oder eine Anfrage ohne ein
Host:-Header-Feld.
Gibt der Client ein Host:-Header-Feld an, wird die Liste nach
einem passenden Vhost durchsucht (die erste Übereinstimmung mit einem
ServerName oder ServerAlias) und die
Anfrage von dem gefundenen Vhost bearbeitet. Ein
Host:-Header-Feld kann eine Port-Nummer enthalten, der Apache
vergleicht aber immer mit dem tatsächlichen Port , an welchen der Client seine
Anfrage gesendet hat.
Hat der Client eine HTTP/1.0-Anfrage ohne
Host:-Header-Feld gesendet, dann ist nicht bekannt, mit welchem
Server der Client verbunden werden möchte. In diesem Fall werden vorhandene
ServerPath-Angaben mit dem URI der Anfrage verglichen. Der erste
übereinstimmende Pfad aus der Liste wird genommen und die Anfrage von diesem
Vhost beantwortet.
Wurde kein entsprechender Vhost gefunden, wird die Anfrage vom ersten Vhost mit einer übereinstimmenden Port-Nummer bedient, der in der Liste der IP-Adressen enthalten ist, mit der der Client die Verbindung hergestellt hat (wie bereits oben erwähnt).
Die oben beschriebene IP-Adresssuche wird nur einmal für eine TCP/IP-Session durchgeführt, während die Suche nach dem Namen für jede Anfrage während einer KeepAlive- oder dauerhaften Verbindung durchgeführt wird. Ein Client kann also bei einer dauerhaften Verbindung Seiten von unterschiedlichen namensbasierten Vhosts anfordern.
Ist der URI der Anfrage ein absoluter URI und stimmen der Hostname und der Port mit dem Hauptserver oder einem der eingerichteten virtuellen Hosts und der Adresse und dem Port überein, an welchen der Client die Anfrage gesendet hat, dann wird der Schema/Hostname/Port-Präfix entfernt und der verbleibende relative URI wird vom entsprechenden Hauptserver oder virtuellen Host bearbeitet. Gibt es keine Übereinstimmung, bleibt der URI unverändert und die Anfrage wird als Proxy-Anfrage betrachtet.
- Namensbasierte und IP-basierte Vhosts können sich nicht in die Quere
kommen. IP-basierte Vhosts sind nur über eine IP-Adresse der eigenen
Adressmenge erreichbar und niemals über eine andere Adresse. Das Gleiche
gilt für namensbasierte Vhosts. Sie können nur über eine IP-Adresse der
entsprechenden Adressmenge erreicht werden, die mit einer
NameVirtualHost-Direktive definiert werden muss. ServerAlias- undServerPath-Überprüfungen werden für einen IP-basierten Vhost nicht durchgeführt.- Die Reihenfolge von namensbasiert//IP-basiert,
_default_-Vhost undNameVirtualHost-Direktive in der Konfigurationsdatei spielt keine Rolle. Nur die Reihenfolge der namensbasierten Vhosts für eine bestimmte Adresse ist wichtig. Der erste namensbasierte Vhosts in der Konfigurationsdatei hat die höchste Priorität für seine Adressmenge. - Aus Sicherheitsgründen wird die in einem
Host:-Header-Feld angegebene Port-Nummer niemals für den Vergleich benutzt. Der Apache benutzt immer den Port, an den der Client die Anfrage gesendet hat. - Gibt es eine
ServerPath-Direktive, die der Präfix einer anderenServerPath-Direktive ist, die später in der Konfigurationsdatei auftaucht, wird immer mit der ersten verglichen und letztere bleibt unbeachtet. (Die Zweideutigkeit wird nicht durch einHost:-Header-Feld aufgehoben.) - Haben zwei IP-basierte Vhosts eine gemeinsame Adresse, wird der Vergleich mit dem Vhost durchgeführt, der zuerst in der Konfigurationsdatei erscheint. Dazu kann es versehentlich kommen. Der Server schreibt eine Warnung in die Fehlerprotokolldatei, wenn er dies bemerkt.
- Ein
_default_-Vhost erhält eine Anfrage, wenn es keinen anderen Vhost mit einer übereinstimmenden IP-Adresse und einer übereinstimmenden Port-Nummer für die Anfrage gibt. Er erhält sie nur, wenn die Port-Nummer, an die der Client die Anfrage sendet, mit der Port-Nummer des_default_-Vhost übereinstimmt. Ein Jokerzeichen-Port kann angegeben werden (_default_:*), um Anfragen an einem beliebigen Port entgegenzunehmen. Das gilt auch fürNameVirtualHost *-Vhosts. - Der Hauptserver bedient eine Anfrage nur, wenn die IP-Adresse und die
Port-Nummer, mit der der Client verbunden ist, nicht angegeben wurde und
nicht mit einem der Vhost (einschließlich eines
_default_-Vhost) übereinstimmt. Das heißt, er übernimmt nur Anfragen für nicht angegebene Adress-/Port-Kombinationen (es sei denn, es gibt einen_default_-Vhost, der mit dem Port übereinstimmt). - Ein
_default_-Vhost oder der Hauptserver werden nicht für eine Anfrage mit einem unbekannten oder nicht angegebenenHost:-Header-Feld herangezogen, wenn der Client mit einer Adresse (und einem Port) verbunden ist, der für namensbasierte Vhosts vorgesehen ist , z.B. in einerNameVirtualHost-Direktive. - Geben Sie in
VirtualHost-Direktiven niemals DNS-Namen an, weil für den Server dann DNS gebootet werden muss. Außerdem ist es ein Sicherheitsrisiko, wenn Sie den DNS nicht für alle aufgeführten Domänen kontrollieren. Die beiden folgenden Themen enthalten weitere Information hierzu. - Der
ServerNamesollte grundsätzlich für jeden Vhost angegeben werden. Andernfalls ist für jeden Vhost eine DNS-Suche erforderlich.
Zusätzlich zu den Tipps zum Thema DNS-Probleme folgen hier noch einige weiter Tipps:
- Setzen Sie alle Hauptserverdefinitionen vor die
VirtualHost-Definitionen. (Das erleichtert das Lesen der Konfigurationsdatei -- das nach der Konfiguration vorgenommene Vermischen lässt nicht erkennen, dass Definitionen um die virtuellen Hosts herum alle virtuellen Hosts betreffen können.) - Gruppieren Sie die einander entsprechenden
NameVirtualHost- undVirtualHost-Definitionen, das erleichtert das Lesen. - Vermeiden Sie
ServerPaths-Anweisungen, die Präfixe andererServerPaths-Anweisungen sind. Lässt sich dies nicht vermeiden, dann müssen Sie dafür sorgen, dass der längere (spezifischere) Präfix-Vhost vor dem kürzeren (weniger spezifischen) Präfix in der Konfigurationsdatei steht (d.h.,ServerPath /abcmuss vorServerPath /abc/defstehen).
In diesem Abschnitt wird versucht, allgemeine Fragen zur Einrichtung virtueller Hosts zu beantworten. Zu den Szenarien gehören solche, bei denen mehrere Websites mit namensbasierten oder IP-basierten virtuellen Hosts auf einem einzelnen Server ausgeführt werden. In Kürze soll eine Beschreibung folgen, wie Sites hinter einem einzelnen Proxy auf mehreren Servern ausgeführt werden.
Ein Server besitzt eine einzige IP-Adresse und mehre Alias-Namen (CNAMES)
verweisen im DNS auf diesen Rechner. Sie möchten einen Webserver für
www.example1.com und www.example2.org
auf diesem Rechner ausführen.
Das Einrichten virtueller Host-Konfigurationen
für Ihren Apache-Server führt nicht automatisch zu DNS-Einträgen. Sie
müssen diese DNS-Namen haben, in die Ihre IP-Adresse aufgelöst
werden, sonst wird niemand Ihre Website sehen. Sie können für lokale
Test Einträge in die hosts-Datei schreiben, dass funktioniert
aber nur bei Rechnern mit diesen Host-Einträgen.
Listen 80
# Auf virtuelle Host-Anfragen an allen IP-Adressen reagieren
NameVirtualHost *
<VirtualHost *>
ServerName www.example1.com
# Hier folgen weitere Direktiven
<VirtualHost *>
ServerName www.example2.org
# Hier folgen weitere Direktiven
Die Sternchen stehen für alle Adressen, daher bedient der Hauptserver keine
Anfragen. Da www.example1.com zuerst in der
Konfigurationsdatei steht, hat er die höchste Priorität und kann als
Standard- oder primärer Server betrachtet werden.
Das bedeutet, dass bei Eingang einer Anfrage, die mit keiner der angegebenen
ServerName-Direktiven übereinstimmt, diese von dem ersten
VirtualHost bearbeitet wird.
Wenn Sie möchten, können Sie das Sternchen * durch
die IP-Adresse des Systems ersetzen. In diesem Fall muss das
Argument für VirtualHost mit dem Argument für
NameVirtualHost übereinstimmen:
<VirtualHost 172.20.30.40>
# etc ...
Bei Systemen, wo die IP-Adresse nicht vorhersehbar ist (beispielsweise
bei einer dynamischen IP-Adresse und bei einer Reihe von dynamischen
DNS-Lösungen) ist das Sternchen * sinnvoll. Da es mit
jeder IP-Adresse übereinstimmt, funktioniert diese Konfiguration immer,
selbst wenn sich die IP-Adresse ändert.
Die oben vorgestellte Konfiguration eignet sich fast in allen Situationen mit namensbasiertem virtuellen Hosting. Sie ist nicht angebracht, wenn Sie basierend auf verschiedenen IP-Adressen oder Ports unterschiedlichen Inhalt ausliefern.
Jedes der hier vorgestellten Verfahren kann auf eine beliebige Anzahl von IP-Adressen ausgedehnt werden.
Der Server besitzt zwei IP-Adressen. Die eine (172.20.30.40)
ist für den Hauptserver server.domain.com vorgesehen und
die zweite (172.20.30.50) ist für zwei oder mehr virtuelle Hosts
gedacht.
# Dies ist der Hauptsever mit der Adresse 172.20.30.40
ServerName server.domain.com
DocumentRoot /www/mainserver
# Dies ist die andere Adresse
NameVirtualHost 172.20.30.50
<VirtualHost 172.20.30.50>
ServerName www.example1.com
# Hier folgen weitere Direktiven ...
<VirtualHost 172.20.30.50>
ServerName www.example2.org
# Hier folgen weitere Direktiven ...
Jede Anfrage an eine andere Adresse als 172.20.30.50 wird
vom Hauptserver bedient. Eine Anfrage an die Adresse
172.20.30.50 mit einem unbekannten Hostnamen oder ohne
Host:-Header wird von www.example1.com
bearbeitet.
Der Server hat zwei IP-Adressen (192.168.1.1 und
172.20.30.40). Der Rechner liegt zwischen einem internen
Netzwerk (Intranet) und einem externen Netzwerk (Internet). Außerhalb des
Netzwerks wird der Name server.example.com in die externe
Adresse aufgelöst (172.20.30.40), innerhalb des Netzwerks
wird der gleiche Name in die interne Adresse aufgelöst
(192.168.1.1).
Der Server kann auf interne und externe Anfragen den gleichen Inhalt
liefern und benötigt dafür nur einen VirtualHost-Abschnitt.
NameVirtualHost 172.20.30.40
<VirtualHost 192.168.1.1 172.20.30.40>
ServerName server.example.com
ServerAlias server
Jetzt werden beide Netzwerke vom gleichen virtuellen Host bedient.
Im internen Netzwerk kann anstelle des vollqualifizierten
Hostnamens server.example.com einfach server
angegeben werden.
Beachten Sie ferner, dass im oben angeführten Beispiel die Liste der
IP-Adressen durch * ersetzt werden kann, was dazu führt, dass
der Server über alle Adressen gleich antwortet.
Mehrere Domänen gehen an die gleiche IP-Adresse und Sie möchten
außerdem mehrere Ports bedienen. Wenn Sie die Ports mit
NameVirtualHost definieren, funktioniert das. Versuchen Sie
<VirtualHost name:port> ohne NameVirtualHost name:port
zu benutzen oder versuchen Sie, die Listen-Direktive zu benutzen,
wird diese Konfiguration nicht funktionieren.
Listen 8080
NameVirtualHost 172.20.30.40:80
NameVirtualHost 172.20.30.40:8080
<VirtualHost 172.20.30.40:80>
DocumentRoot /www/domain-80
<VirtualHost 172.20.30.40:8080>
DocumentRoot /www/domain-8080
<VirtualHost 172.20.30.40:80>
DocumentRoot /www/otherdomain-80
<VirtualHost 172.20.30.40:8080>
DocumentRoot /www/otherdomain-8080
Der Server besitzt zwei IP-Adressen (172.20.30.40 und
172.20.30.50, die in die Namen
www.example1.com und www.example2.org
aufgelöst werden.
<VirtualHost 172.20.30.40>
ServerName www.example1.com
<VirtualHost 172.20.30.50>
ServerName www.example2.org
Anfragen für eine beliebige Adresse, die nicht in einer der
<VirtualHost>-Direktiven angegeben wird (zum Beispiel
localhost) gehen an den Hauptserver, falls einer vorhanden ist.
Der Server hat zwei IP-Adressen (172.20.30.40 und
172.20.30.50), die in die Namen
www.example1.com und www.example2.org
aufgelöst werden. In jedem Fall sollen die Hosts über die Ports 80 und
8080 gehen.
Listen 172.20.30.40:8080
Listen 172.20.30.50:80
Listen 172.20.30.50:8080
<VirtualHost 172.20.30.40:80>
ServerName www.example1.com
<VirtualHost 172.20.30.40:8080>
ServerName www.example1.com
<VirtualHost 172.20.30.50:80>
ServerName www.example1.org
<VirtualHost 172.20.30.50:8080>
ServerName www.example2.org
Einige Adressen sind für namensbasierte virtuelle Hosts und andere für IP-basierte Hosts vorgesehen.
NameVirtualHost 172.20.30.40
<VirtualHost 172.20.30.40>
ServerName www.example1.com
<VirtualHost 172.20.30.40>
ServerName www.example2.org
<VirtualHost 172.20.30.40>
ServerName www.example3.net
# IP-basiert
<VirtualHost 172.20.30.50>
ServerName www.example4.edu
<VirtualHost 172.20.30.60>
ServerName www.example5.gov
Jede Anfrage an eine nicht angegebene IP-Adresse und einen nicht angegebenen Port abfangen, d.h. eine Adress-/Port-Kombination, die für keinen anderen virtuellen Host benutzt wird.
Die Angabe eines Standard-Vhost mit einem Jokerzeichen für den Port bewirkt, dass keine Anfragen an den Hauptserver gehen.
Ein Standard-Vhost bedient keine Anfrage, die an eine Adresse der einen
Port gesendet wird, die oder der
für namensbasierte Vhosts benutzt wird. Enthält die Anfrage einen
unbekannten oder keinen Host:-Header, wird sie immer vom
primären namensbasierten Vhost (der Vhost, der für diese Adresse/Port in der
Konfigurationsdatei angegeben wird).
Mit den Direktiven
Die Situation ist die gleiche wie im ersten Beispiel, der Server reagiert aber auf mehrere Ports und für Port 80 soll ein zweiter Standard-Vhost eingerichtet werden.
# ...
<VirtualHost _default_:*>
# ...
Der Standard-Vhost für Port 80 (der vor einem Standard-Vhost mit
einem *-Port angegeben werden muss),
fängt alle Anfragen ab, die an eine nicht angegebene IP-Adresse gesendet
werden. Der Hauptserver bedient keine Anfragen.
Es soll nur einen Standard-Vhost für Port 80 und keine weiteren Standard-Vhosts geben.
DocumentRoot /www/default
...
</VirtualHost>
Eine Anfrage an eine nicht angegebene Adresse über Port 80 wird vom Standard-Vhost beantwortet, alle anderen Anfragen an eine nicht angegebene Adresse und einen nicht angegebenen Port werden vom Hauptserver bearbeitet.
Der namensbasierte Vhost mit dem Hostnamen
www.example2.org (aus Beispiel 2)
sollte eine eigene IP-Adresse erhalten. Um Probleme mit Name-Servern oder
Proxies zu vermeiden, die die alte IP-Adresse für den namensbasierten Vhost
gespeichert haben, sollen in der Übergangsphase beide Varianten zur
Verfügung stehen.
Die Lösung ist ganz einfach, da der VirtualHost-Direktive nur
die neue IP-Adresse (172.20.30.50) hinzugefügt werden muss.
ServerName www.example1.com
DocumentRoot /www/example1
NameVirtualHost 172.20.30.40
<VirtualHost 172.20.30.40 172.20.30.50>
ServerName www.example2.org
# ...
<VirtualHost 172.20.30.40>
ServerName www.example3.net
ServerAlias *.example3.net
# ...
Auf den Vhost kann jetzt über die neue Adresse als IP-basierter Vhost und über die alte Adresse als namensbasierter Vhost zugegriffen werden.
Bei einem Server mit zwei namensbasierten Vhosts muss der Client den
richtigen Host:-Header für den entsprechenden virtuellen
Vhost senden. Alte HTTP/1.0-Clients senden diesen Header nicht, der Apache
benötigt aber einen Hinweis, welchen Vhost der Client erreichen möchte
(und bedient die Anfrage über den primären Vhost). Um soviel
Abwärtskompatibilität wie möglich zu gewährleisten, wird ein primärer Vhost
eingerichtet, der eine einzelne Seite mit Links mit einem URL-Präfix für die
namensbasierten virtuellen Hosts zurückliefert.
<VirtualHost 172.20.30.40>
DocumentRoot /www/subdomain
RewriteEngine On
RewriteRule ^/.* /www/subdomain/index.html
# ...
<VirtualHost 172.20.30.40>
DocumentRoot /www/subdomain/sub1
ServerPath /sub1/
RewriteEngine On
RewriteRule ^(/sub1/.*) /www/subdomain$1
# ...
<VirtualHost 172.20.30.40>
ServerName www.sub2.domain.tld
ServerPath /sub2/
RewriteEngine On
RewriteRule ^(/sub2/.*) /www/subdomain$1
# ...
Aufgrund der http://www.sub1.domain.tld/sub1/
immer vom Vhost sub1 bedient.
Eine Anfrage an die URL http://www.sub1.domain.tld/ wird nur
dann vom Vhost sub1 bedient, wenn der Client einen
korrekten Host:-Header gesendet hat. Ist kein
Host:-Header vorhanden, erhält der Client die Informationsseite
für den primären Host.
Das funktioniert in jedem Fall: Eine Anfrage an
http://www.sub2.domain.tld/sub1/ wird auch vom Vhost
sub1 bedient, wenn der Client keinen Host:-Header
gesendet hat.
Mit den Host:-Header gesendet hat, beide URL-Varianten benutzen kann,
d.h. mit oder ohne URL-Präfix.
Wie die Bezeichnung IP-basiert andeutet, muss der Server unterschiedliche IP-Adressen für jeden IP-basierten virtuellen Host besitzen. Das kann mit mehrere Anschlüssen an das Netzwerk oder durch die Verwendung virtueller Schnittstellen erreicht werden, die von den meisten moderneren Betriebssystemen unterstützt werden (Informationen hierzu finden Sie in der Beschreibung des Betriebssystems, oft unter den Begriffen "IP-Alias" und the "ifconfig").
Es gibt zwei Möglichkeiten, den Apache für die Unterstützung mehrerer
Hosts einzurichten. Entweder wird ein separater httpd-Daemon
für jeden Hostnamen ausgeführt oder es wird ein Daemon ausgeführt, der alle
virtuellen Hosts unterstützt.
Benutzen Sie in folgenden Situationen mehrere Daemons:
- Aus Sicherheitsgründen soll eine Abschottung vorgenommen werden (z.B.
möchte Firma 1, dass jemand aus Firma 2 Daten nur über das Web lesen kann).
In diesem Fall benötigen Sie zwei Daemons mit unterschiedlichen
User -,Group -,Listen - undServerRoot -Einstellungen. - Sie können die Dateideskriptor- und
Speicheranforderungen zum Überwachen aller IP-Aliase des Rechners erfüllen.
Es ist nur möglich, die
*-Adresse oder bestimmte Adressen zu überwachen. Müssen Sie aus irgendwelchen Gründen eine bestimmte Adresse überwachen, dann müssen Sie alle spezifischen Adressen überwachen. (Einhttpd-Prozess könnte auch die Adressen N - 1 überwachen und ein anderer die übrigen Adressen.)
Benutzen Sie einen einzelnen Daemon, wenn:
- eine gemeinsame httpd-Konfiguration für die virtuellen Hosts möglich ist.
- der Rechner eine große Anzahl von Anfragen bearbeitet, so dass der Leistungsabfall bei separaten Daemons beträchtlich wäre.
Richten Sie für jeden virtuellen Host eine eigene httpd-Installation ein. Legen
Sie mit der
Es wird empfohlen, eine IP-Adresse anstelle eines Hostnamens zu benutzen (siehe DNS-Probleme).
In diesem Fall bedient ein einzelner httpd-Prozess Anfragen
an den Hauptserver und alle virtuellen Hosts. Mit der
ServerAdmin [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
DocumentRoot /groups/baygroup/www
ServerName www.baygroup.org
ErrorLog /groups/baygroup/logs/error_log
TransferLog /groups/baygroup/logs/access_log
</VirtualHost>
Es wird empfohlen, eine IP-Adresse anstelle eines Hostnamens zu benutzen (siehe DNS-Probleme).
Mit der Direktive VirtualHost kann fast jede
Konfigurationsdirektive angegeben werden. Ausgenommen sind Direktiven,
die die Prozesserzeugung kontrollieren sowie einige andere Direktiven. Um
festzustellen, ob eine Direktive in der VirtualHost-Direktive benutzt
werden kann, überprüfen Sie in der
Direktivenbeschreibung die Angabe zum
Kontext .
In der VirtualHost-Direktive können auch die Direktiven
SICHERHEIT: Wenn Sie festlegen, in welches Verzeichnis Protokolldateien geschrieben werden, sollten Sie sich über die Sicherheitsrisiken im Klaren sein, die daraus entstehen können, wenn jemand anders als der Benutzer, der den Apache startet, Schreibrechte in diesem Verzeichnis hat. In den Tipps zur Sicherheit finden Sie weitere Einzelheiten hierzu.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
