Will man den Apache Webserver lediglich dazu einsetzen, ein paar Scripts (Perl, CGI, PHP oder ähnliches) zu überprüfen, ist die Einrichtung von virtuellen Hosts nicht zwingend erforderlich. Ohne virtuelle Hosts kann man einen lokalen Apache ausschließlich mit zwei Adreßangaben nutzen: unter http://localhost und http://127.0.0.1 lassen sich die Serverfunktionen im Browser ansprechen und die lokalen Webinhalte darstellen. Vielfach genügt das bereits. Sofern der Webserver auch "von außen", also über das Internet, zugänglich gemacht werden soll, ist dies bereits möglich. Es kann dabei nur eine einzige Domain gehostet werden.
Mit eingerichteten virtuellen Hosts können jedoch "echte" Domainnamen in der Form http://www.domainname.tld in größerer Zahl verwendet werden, ohne daß dafür auch "echte" IP-Adressen vergeben worden sein müssen. Man könnte sich zum Beispiel vorstellen, daß die Adresse http://www.server.test eingesetzt werden soll. "test" ist hier eine TLD (Top Level Domain), die es im Internet nicht gibt, die aber von der Internet Corporation for Assigned Names and Numbers (
ICANN) für private Zwecke reserviert wurde (siehe ftp://ftp.rfc-editor.org/in-notes/rfc2606.txt). Ein Browser kann einen Servernamen dieser TLD nur ansprechen, wenn er tatsächlich vom lokalen Webserver bereitgestellt wird - unter "lokal" muß nicht unbedingt physikalisch derselbe Rechner verstanden werden, das kann auch ein lokales Netzwerk sein.
Da die "Namensauflösung" über einen DNS-Mechanismus vollzogen wird, muß es eine Möglichkeit geben, den neuen Namen www.server.test irgendwie der bzw. einer IP-Adresse zuzuordnen. Das geschieht, indem der Umstand ausgenutzt wird, daß während des Aufbaus einer Verbindung zu einer Domain zunächst nach einem DNS gesucht wird, der die vorgesehene Namensauflösung registriert hat. In diese Suche ist die Abfrage der lokalen hosts-Datei integriert. Man kann sich auch (muß aber nicht unbedingt) auf einer Linux-Maschine relativ einfach einen lokalen DNS-Server (Nameserver) einrichten. Auf einer Windows-Maschine ist die Einrichtung eines Nameservers etwas schwieriger - Server-Systeme wie Win2003 Server enthalten entsprechende Software, die "Professional"- oder "Personal"-Systeme für Arbeitsplatzrechner enthalten sie nicht.
Es hat historische Gründe, daß für die Namensauflösung nicht unbedingt ein komplettes Softwarepaket benötigt wird, sondern in kleineren Netzen eine lokale hosts-Datei genügt. Auf einer Linux-Maschine ist das /etc/hosts. Auf einer Windows 9x-Maschine gibt es eine solche Datei nur dann, wenn TCP/IP installiert ist. Sie kann unter dem Namen hosts.sam im %windir% liegen, also meistens wohl C:\Windows\hosts.sam. Der Dateiname muß zu hosts korrigiert werden. Ab Windows 2000 gibt es die Datei %systemroot%\system32\drivers\etc\hosts.
Ohne eigene Eintragungen sieht die hosts-Datei in der Regel erst einmal folgendermaßen aus:
# /etc/hosts diese Datei enthält eine Anzahl von Hostname-zu-Adresse- # Übersetzungen für das TCP/IP-Subsystem. Das wird hauptsächlich # während des Hochfahrens benötigt, wenn noch kein Nameserver # gestartet ist. # Auf kleinen Systemen kann diese Datei auch als Ersatz für einen # Nameserver dienen. # Syntax: # IP-Adresse vollständiger Hostname kurzer Hostname # # spezielle IPv6-Adressen ::1 localhost ipv6-localhost ipv6-loopback fe00::0 ipv6-localnet ff00::0 ipv6-mcastprefix ff02::1 ipv6-allnodes ff02::2 ipv6-allrouters ff02::3 ipv6-allhosts # IPv4-Adressen 127.0.0.1 localhost
und auf einer Windows-Maschine:
# Copyright (c) 1993-1999 Microsoft Corp. # # Dies ist eine HOSTS-Beispieldatei, die von Microsoft TCP/IP # für Windows 2000 verwendet wird. # # Diese Datei enthält die Zuordnungen der IP-Adressen zu Hostnamen. # Jeder Eintrag muss in einer eigenen Zeile stehen. Die IP- # Adresse sollte in der ersten Spalte gefolgt vom zugehörigen # Hostnamen stehen. # Die IP-Adresse und der Hostname müssen durch mindestens ein # Leerzeichen getrennt sein. # # Zusätzliche Kommentare (so wie in dieser Datei) können in # einzelnen Zeilen oder hinter dem Computernamen eingefügt werden, # aber müssen mit dem Zeichen '#' eingegeben werden. # # Zum Beispiel: # # 102.54.94.97 rhino.acme.com # Quellserver # 38.25.63.10 x.acme.com # x-Clienthost 127.0.0.1 localhost
Die Kommentarzeilen kann man problemlos streichen. Für ein Beispiel soll nun zunächst davon ausgegangen werden, daß es zwei über ein Kabel miteinander kommunizierende Rechner gibt, die pc1 und pc2 heißen, wobei auf jedem ein Apache installiert ist. Dann sieht, noch ohne virtuelle hosts, die hosts-Datei beispielsweise so aus:
# lokale hosts-Datei 127.0.0.1 localhost 192.168.0.1 pc1 192.168.0.2 pc2
Damit wird nur dafür gesorgt, daß ein ping Rechnername im lokalen Netz funktioniert, und nicht nur ein ping lokale_IP. Es kommen jetzt noch die Einträge für die vorgesehenen virtuellen Hosts hinzu, wobei die Festlegung der IP-Adressen mehr oder weniger zufällig erfolgt:
# hosts-Datei # lokale IP-Adressen 127.0.0.1 localhost 192.168.0.1 pc1 192.168.0.2 pc2 # virtuelle Hosts 192.168.0.2 www.server1.test 172.24.10.2 www.server2.test 172.24.10.2 www.server3.test 10.0.0.1 www.server4.test
Hier sollen also für den Rechner pc2 vier virtuelle Hosts erzeugt werden, wobei die lokalen Domains www.server1.test und www.server3.test namensgestützte virtuelle Hosts werden sollen, und www.server2.test sowie www.server4.test werden IP-gestützte virtuelle Hosts.
Achtung!: wird hier ein "echter" Domainname, den es tatsächlich im Internet gibt (beispielsweise de.selfhtml.org), einer lokalen IP-Adresse zugeordnet, kann ein Browser das im Internet vorhandene Webangebot nicht mehr darstellen. Daher sollten zur Vermeidung möglicher Konflikte grundsätzlich lokale TLDs wie beispielsweise "test" verwendet werden.
Die Konfiguration virtueller Hosts kann auf zwei einander ähnlichen Wegen erfolgen, entweder als namensgestützter (namebased) virtueller Host oder als IP-gestützter (ipbased) virtueller Host. Bei allen Überlegungen, ob und wie man sich einen virtuellen Host einrichten möchte, steht zuerst immer die Kontrolle, ob in der Modul-Liste der httpd.conf auch das zuständige Modul eingebunden wurde. Soll nur ein einzelner virtueller Host als _default_ eingerichtet werden, so genügt das ja immer vorhandene core-Modul, das den <VirtualHost>-Container bereitstellt (bzw. http_core in Apache 1.3.x). Sollen Anweisungen wie VirtualScriptAlias oder VirtualDocumentRoot benutzt werden, muß die Modul-Liste zusätzlich diesen Eintrag enthalten:
... LoadModule vhost_alias_module modules/mod_vhost_alias.so ...
Zunächst werden die benötigten Verzeichnisse auf dem Rechner erstellt, auf dem der Apache installiert ist und die später als DocumentRoot genutzt werden sollen. SuSE Linux sieht seit einiger Zeit dafür ein Verzeichnis /srv/www vor, Red Hat/Fedora ein Verzeichnis /var/www, FreeBSD ein Verzeichnis /usr/local/www usw. Auf einer Windows-Maschine kann das beispielsweise D:\www sein. Man kann diesen Vorschlägen folgen, aber auch ein beliebiges anderes Verzeichnis wählen, lediglich /home/Benutzername sollte besser nicht genommen werden, da das das Arbeitsverzeichnis für einen angemeldeten Benutzer darstellt und wesentlich andere Dateien enthalten kann als webtaugliche Dokumente. Will man genau sein, sollte dann wenigstens noch rasch eine index.htm erstellt und im neuen Verzeichnis abgelegt werden, damit der Apache etwas zur Übergabe an den aufrufenden Browser vorfindet - beliebige Unterverzeichnisse und weitere Webdokumente sind natürlich auch möglich. Der Verzeichnisname kann (wie hier) mit dem Servernamen des virtuellen Hosts übereinstimmen, das ist jedoch nicht Bedingung, es kann auch ein beliebiger anderer Verzeichnisname gewählt werden:
Namensgestützte virtuelle Hosts werden über dieselbe lokale IP angesprochen, die für den Rechner (bzw. dessen Netzwerk-Schnittstelle) gilt, auf dem der Webserver installiert wurde. Das kann beispielsweise 192.168.0.x sein oder 10.0.0.1 oder ähnlich - und wenn es keine lokale IP gibt, kann das auch die 127.0.0.1 sein. Dann werden am Ende der httpd.conf folgende Einträge vorgenommen:
NameVirtualHost 192.168.0.2 <VirtualHost 192.168.0.2> ServerName www.server1.test DocumentRoot "/var/www/server1" </VirtualHost>
beziehungsweise auf einer Windows-Maschine:
NameVirtualHost 192.168.0.2 <VirtualHost 192.168.0.2> ServerName www.server1.test DocumentRoot "D:/www/server1" </VirtualHost>
Und das wars auch schon. Bis auf die Pfadnamen gibt es hier keine plattformspezifischen Unterschiede zwischen Linux und Windows. Wichtig ist allerdings, daß eine Zeile NameVirtualHost 192.168.0.2 über dem <VirtualHost 192.168.0.2>-Container liegt, der die Konfiguration für den namensbasierten Host enthält. Ist keine eigene IP vergeben (weil der Rechner nicht an ein lokales Netzwerk angeschlossen ist), gilt zumindest die Loopback-Adresse 127.0.0.1, die ebenfalls für solche namensbasierte virtuelle Hosts eingesetzt werden kann (dann muß auch in der lokalen hosts-Datei der Name des virtuellen Hosts der IP 127.0.0.1 zugeordnet werden). Es soll der Vollständigkeit wegen noch erwähnt werden, daß nach Änderungen der Konfigurationsdatei der Apache neu gestartet werden muß. Tippt man dann in der Adreßzeile des Browsers http://www.server1.test ein, wird tatsächlich die Datei /var/www/server1/index.htm bzw. D:\www\server1\index.htm an den aufrufenden Browser übergeben - und zwar an jeden Browser auf jedem beliebigen an dieses lokale Netz angeschlossenen Rechner. Auch beliebige Unterverzeichnisse sind erreichbar, sie benötigen keine eigenen virtuellen Hosts.
Je nach Bedarf können in einem <VirtualHost>-Container noch wesentlich mehr Anweisungen notiert werden. Nahezu alles, was im Abschnitt "main server configuration" eingetragen werden kann, ist auch innerhalb eines <VirtualHost>-Containers erlaubt. Mit dem hier angegebenen Beispiel ist die Verwaltung von zwei unterschiedlichen Domains möglich: http://localhost und http://www.server1.test. Im Abschnitt "main server configuration" wurde bereits ein DocumentRoot angegeben, das /var/www/localhost ist. Es handelt sich also tatsächlich um völlig unterschiedliche Verzeichnisse und somit auch um zwei verschiedene Webangebote.
Es kann nun sein, daß es gar keine Netzwerkkarte gibt, aber ein Modem oder einen anderen Anschluß für den Zugang zum Internet auf einem Einzelplatzrechner. In einem solchen Fall gibt es zwar die loopback-Adresse, aber keine "private" IP für den lokalen Rechner. Dem Netzwerkadapter wird in der Regel vom ISP die für eine DFÜ-Verbindung nötige IP dynamisch zugewiesen, so daß man sie bei Verbindungsaufbau natürlich noch nicht kennen und ihr also auch keinen virtuellen Host zuordnen kann. Eine solche "default"-Situation wird von den hier zum Vergleich bereits mehrfach genannten Linux-Distributionen grundsätzlich vorausgesetzt. Daher wird "default" anstelle einer IP-Adresse ein Platzhalter eingesetzt:
NameVirtualHost *:80 <VirtualHost *:80> ServerName www.server1.test DocumentRoot "/var/www/server1" </VirtualHost>
Der Apache beantwortet grundsätzlich alle Anfragen nach nicht aufgelösten Domainnamen so, als ob damit der erste vorhandene virtuelle Host gemeint sei. "Nicht aufgelöst" bedeutet, daß weder die gewünschte IP noch der gewünschte Domainname einer <VirtualHost>-Konfiguration zugeordnet werden können. Bei Verwendung des Platzhalters wird sogar http://localhost auf das unter DocumentRoot genannte Verzeichnis des <VirtualHost>-Containers verwiesen - selbst dann, wenn weiter oben im 2. Abschnitt der httpd.conf (main server configuration) ein anderes Verzeichnis als DocumentRoot vorgesehen wurde. Allerdings ist es nicht möglich, für den Platzhalter mehrere unterschiedliche virtuelle Domains zu definieren. Eine zusätzliche Domain ist möglich, wenn für den Platzhalter ein anderer port angegeben wird. Wenn man mehrere Domains verwalten möchte, obwohl keine IP-Adresse zur Verfügung steht, muß die loopback-Adresse anstelle des Platzhalters notiert werden.
Da die Methode zur Einrichtung eines namensgestützten virtuellen Hosts am einfachsten zu verstehen und zu befolgen ist, wird sie auch am häufigsten empfohlen.
In diesem Konzept wird nicht versucht, einer IP-Adresse mehrere Hostnamen zuzuordnen, sondern es wird für jeden möglichen virtuellen Hostnamen eine eigene IP-Adresse vorgegeben. Das ist ein bißchen komplexer, da man ja normalerweise außer der loopback-Adresse nur eine - in der Regel vom Provider zugewiesene - IP-Adresse für die DFÜ-Verbindung zur Verfügung hat und es wenig Sinn macht, für jeden vorgesehenen virtuellen Host eine neue Netzwerkkarte einzustecken - ganz abgesehen davon, daß die Computer-Hardware gar nicht so viele freie Slots zum Einstecken weiterer Karten bietet. Der Ausweg besteht in einem weiteren Konzept, das IP-Aliasing genannt wird und im wesentlichen bedeutet, daß jedem Netzwerkgerät nicht nur eine IP, sondern zusätzliche IPs in Form von Aliasen zugeordnet werden können.
Das Vorgehen ist relativ einfach. Auf einer Linux-Maschine gibt es zwei Konsolenbefehle bzw. die dahinterstehenden Programme, die dafür verwendet werden können, ifconfig und ip. ifconfig ist der ältere Befehl, der auf jeder Linux-Maschine zur Verfügung stehen sollte, ip ist jünger, deutlich flexibler und mächtiger, aber (noch) nicht auf allen Distributionen Bestandteil des "core"-Systems. Man muß ihn eventuell gesondert installieren. ifconfig liefert, wenn man ihn ohne weitere Parameter aufruft, Informationen über Netzwerkschnittstellen, was bei einem Rechner, in dem es eine Ethernet-Netzwerkkarte gibt und der nicht über eine eigene aktive Internetverbindung verfügt, so aussehen kann:
Es gibt in diesem Rechner also zwei Netzwerkgeräte, die eth0 und lo heißen - eth0 ist die Netzwerkkarte (für das LAN) und lo ist die immer vorhandene Loopbackadresse. Beide "Geräte" könnten nun IP-Aliase zugeordnet bekommen, hier soll es lediglich an der Ethernetkarte demonstriert werden. ifconfig kann mit verschiedenen Parametern aufgerufen werden, der einzige Parameter, den man ifconfig leider nicht zeigt, ist derjenige, der einen IP-Alias erzeugen kann. Ein solcher Alias kann auf folgende Weise erstellt werden:
ifconfig eth0:1 192.168.0.20
Damit dieser Alias wirksam werden kann, muß zwar nicht gleich der ganze Rechner, aber immerhin das Netzwerk neu gestartet werden, wofür es (nicht in allen Distributionen) den Konsolenbefehl rcnetwork restart gibt - eine Reinitialisierung der Netzwerkkarte mit ifup eth0 hat denselben Effekt. Danach liefert ifconfig folgende Anzeige:
Das heißt, für die Netzwerkkarte gibt es jetzt sowohl die IP 192.168.0.2 wie auch die IP 192.168.0.20. Beide IP-Adressen gehören zum selben (Sub-)Netz, was allerdings nicht Bedingung ist. Der IP-Alias könnte auch 10.0.4.34 oder irgendeine andere "private" IP mit anderer Netzmaske sein. Mit ifconfig eth0:x können bei Bedarf auch mehrere Aliase erzeugt werden, indem der Wert für x einfach hochgezählt wird.
Leider ist aber ein auf solche Weise erzeugter IP-Alias nicht persistent, das heißt, nach dem nächsten reboot ist er wieder weg und man darf ihn neu anlegen. Also muß nach anderen zuverlässigen Wegen gesucht werden, um den IP-Alias dauerhaft im System zu verankern.
Die Scripts, die die Konfiguration für die Netzwerkschnittstellen enthalten, liegen unterhalb von /etc, wobei die Distributionen unterschiedliche Dateinamen und Ablageorte vorsehen.
SuSE Linux 9.1:
Die Konfigurationsscripts liegen in /etc/sysconfig/network und tragen die Namen der Netzwerkschnittstellen. Unter "Name" wird dabei in SuSE Linux 9.1, anders als in vorausgegangenen SuSE-Versionen, die Hardware-Adresse verstanden. Das Script, mit dem eine Ethernetkarte angesprochen wird, kann also beispielsweise /etc/sysconfig/network/ifcfg-eth-id-00:30:84:40:09:ee oder ähnlich heißen, während /etc/sysconfig/network/ifcfg-lo für die Loopback-Schittstelle zuständig ist, außerdem gibt es eine gut kommentierte Vorlage /etc/sysconfig/network/ifcfg.template (
Vorlagenscript anzeigen). Sollen die in der oben als Beispiel dargestellten hosts-Datei notierten zusätzlichen IP-Adressen 172.24.10.2 und 10.0.0.1 wirksam werden, so muß /etc/sysconfig/network/ifcfg-eth-id-00:30:84:40:09:ee folgenden Inhalt bekommen:
BOOTPROTO='static' BROADCAST_1='192.168.0.255' IPADDR_1='192.168.0.2' NETMASK_1='255.255.255.0' NETWORK_1='192.168.0.0' BROADCAST_2='172.24.10.255' IPADDR_2='172.24.10.2' NETMASK_2='255.255.0.0' NETWORK_2='172.24.10.0' BROADCAST_3='10.0.0.255' IPADDR_3='10.0.0.1' NETMASK_3='255.0.0.0' NETWORK_3='10.0.0.0' REMOTE_IPADDR='' MTU='' STARTMODE='onboot' UNIQUE='Gcmk.V9wnhMKHJYC' _nm_name='bus-pci-0000:02:0e.0'
Fedora Core 2:
Hier liegen die Konfigurationsdateien in /etc/sysconfig/network-scripts. Ist nur eine Netzwerkkarte vorhanden, heißt das zugehörige Script ifcfg-eth0. Für jeden gewünschten Alias wird ein weiteres Script erstellt, wobei die letzte Ziffer des Scriptnamens hochgezählt wird. ifcfg-eth1 ist demzufolge der erste Alias, ifcfg-eth2 der nächste usw. Die Scripts enthalten solche Einträge:
DEVICE=eth0 BOOTPROTO=static BROADCAST=10.255.255.255 IPADDR=10.0.0.1 NETMASK=255.0.0.0 NETWORK=10.0.0.0 ONBOOT=yes TYPE=Ethernet
Debian 3.0r2 (sarge):
Debian macht es relativ einfach. Das Konfigurationsscript ist /etc/network/interfaces mit ungefähr diesem Inhalt:
auto lo eth0 eth0:1 eth0:2 iface lo inet loopback iface eth0 inet static address 192.168.0.2 network 192.168.0.0 netmask 255.255.255.0 broadcast 192.168.0.255 iface eth0:1 inet static address 172.24.10.2 network 172.24.10.0 netmask 255.255.0.0 broadcast 172.24.255.255 iface eth0:2 inet static address 10.0.0.1 network 10.0.0.0 netmask 255.0.0.0 broadcast 10.255.255.255
Gentoo:
Noch einfacher - das für die Schnittstellenkofiguration zuständige Script ist /etc/conf.d/net mit folgendem Inhalt:
# /etc/conf.d/net: iface_eth0="192.168.0.2 broadcast 192.168.0.255 netmask 255.255.255.0" alias_eth0="172.24.10.2 10.0.0.1"
FreeBSD 5.2.1:
Wesentliche Anweisungen zur Systemkonfiguration werden hier in einer /etc/rc.conf zusammengefaßt. Eine solche zentrale rc.conf gab es bei den Linux-Distributionen ursprünglich auch, ehe begonnen wurde, die System-Konfiguration in viele verschiedene Teile aufzusplitten. Die Einrichtung virtueller hosts in FreeBSD wird in einem 
Kapitel des Handbuchs. ausreichend dargestellt. Der Abschnitt in /etc/rc.conf kann so aussehen:
network_interfaces="lo0 rl0 sk0 tun0" ifconfig_sk0="inet 192.168.0.1 netmask 255.255.255.0" ifconfig_sk0_alias0="inet 172.24.10.2 netmask 255.255.0.0" ifconfig_sk0_alias1="inet 10.0.0.1 netmask 255.0.0.0"
Nach einem Neustart des Netzwerks oder gegebenenfalls einem reboot zeigt ifconfig (Gentoo):
Achtung! In SuSE Linux 9.1 und Fedora Core 2 zeigt ifconfig solche fixen IP-Aliase nicht an, auch wenn sie vorhanden sind. Das liegt daran, daß ifconfig von anderen Systemeinstellungen (Kernelversion höher als 2.2) gehindert wird, IP-Aliase darzustellen. Für ip gibt es eine solche Einschränkung nicht, und dieser Konsolenbefehl steht auch in SuSE und in Fedora ohne gesonderte Installation zur Verfügung. Damit sieht die Anzeige dann eben so aus:
Der Informationsgehalt ist derselbe: alle drei IP-Adressen stehen mit den richtigen Netzmasken zur Verfügung und können in der httpd.conf für virtuelle Hosts eingesetzt werden.
Ganz so einfach wie auf einer Linux-Maschine ist es auf einer Windows-Maschine (Windows 2000 / XP) nicht. Es gibt keine Scripts, in die man bloß eben mal was hineinzuschreiben braucht. Außerdem vergibt Windows an Geräte, die ihre IP über DHCP dynamisch erhalten sollen, die IP 169.254.213.96 als "dummy". Sollen IP-Aliase eingerichtet werden, so werden dafür die "Eigenschaften" eines Netzwerkgeräts (beispielsweise einer Ethernetkarte oder eines entsprechenden Netzwerkchips auf dem mainboard) geöffnet. Dort gibt es wiederum "Eigenschaften" für das TCP/IP-Protokoll:
 |
 |
Und dort schließlich gibt es eine Registerkarte "Erweitert". Hier können nun weitere, eventuell als Alias benötigte IP-Adressen eingegeben werden:
Für das Beispiel wurde Wert darauf gelegt, daß die beiden neuen Aliaseinträge jeweils anderen (Sub-)Netzen angehören, man sieht es an der Netzwerkmaske. Die neuen Einträge werden mit "ok" bestätigt, damit ist die Einrichtung der Aliase vollständig. Man kann sich davon durch einen Blick in die registry überzeugen. Unter dem Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\{13665A19-8468-4BE3-95C6-E750FFF90ECA}\Parameters\Tcpip sollte es jetzt die neuen IP-Adressen geben - der CLSID-Wert in den geschweiften Klammern kann auch aus einer etwas anderen Ziffern-/Buchstabenkombination bestehen:
Zur Kontrolle kann man sich in der "Eingabeaufforderung" die vorhandenen IP-Adressen mit ipconfig -all anzeigen lassen:
Dafür, daß auf Aliase Wert gelegt wurde, die verschiedenen (logischen) Netzen zugehören, gibt es einen einfachen Grund: das "private" Netz 192.168.0.x wird nicht nur zur Einbindung des Webservers benötigt, sondern auch dafür, daß über Freigaben verschiedene Rechnerlaufwerke unabhängig vom Webserver den anderen Rechnern zur Verfügung gestellt werden können. Die "Netzwerkumgebung" muß dazu euf eine einzige, klar definierte IP zugreifen können, die dem für die "Arbeitsgruppe" zuständigen Netz angehört. Wird eine zweite IP für dasselbe Netz vergeben (192.168.0.20 gehört zum selben Netz wie 192.168.0.2) so kann sich Windows nicht entscheiden und ersetzt die "default"-IP durch 0.0.0.0 - was sich allerdings erst bei einem Rechnerneustart bemerkbar macht. Dann ist der gesamte Rechner plötzlich nicht mehr im LAN erreichbar. Erst ein IP-Alias, der einem anderen Netz angehört, scheint dieses Verhalten blockieren zu können.
Der Rest der Konfiguration verläuft unabhängig von der Einsatzplattform und wird mit einigen wenigen Einträgen in der httpd.conf durchgeführt.
<VirtualHost 192.168.0.2> ServerName pc2 DocumentRoot "/var/www/localhost" </VirtualHost> <VirtualHost 172.24.10.2> ServerName www.server2.test DocumentRoot "/var/www/server2" </VirtualHost> <VirtualHost 10.0.0.1> ServerName www.server4.test DocumentRoot "/var/www/server4" </VirtualHost>
beziehungsweise auf einer Windows-Maschine:
<VirtualHost 192.168.0.2> ServerName pc2 DocumentRoot "D:/www/localhost" </VirtualHost> <VirtualHost 172.24.10.2> ServerName www.server2.test DocumentRoot "D:/www/server2" </VirtualHost> <VirtualHost 10.0.0.1> ServerName www.server4.test DocumentRoot "D:/www/server4" </VirtualHost>
Damit dürfte die manchmal (auch nach Lektüre der Online-Dokumentation) nicht leicht verständliche Bezeichnung "IP-gestützt" doch etwas klarer werden. Alle nötigen Voraussetzungen sind erfüllt:
lokale hosts-Datei existiertDann sind drei unterschiedliche Domains ansprechbar:
http://pc2
http://www.server2.test
http://www.server4.test
Wegen der Zuordnung der Domainnamen zu lokalen IP-Adressen in der hosts-Datei stehen diese Domains ausschließlich im lokalen Netz zur Verfügung, auch dann, wenn der Rechner gleichzeitg eine aktive Internetverbindung hat.
Zuguterletzt lassen sich, wenn es denn nötig sein sollte, beide Verfahren zur Erstellung virtueller Hosts kombinieren. Wenn es einen IP-Alias gibt, können ihm natürlich auch mehrere namensbasierte virtuelle Hosts zugeordnet werden. Entsprechend der oben als Beispiel angegebenen hosts-Datei kann der 3. Abschnitt der httpd.conf dann folgendes Aussehen erhalten:
<VirtualHost 192.168.0.2> ServerName pc2 DocumentRoot "/var/www/localhost" </VirtualHost> NameVirtualHost 192.168.0.2 <VirtualHost 192.168.0.2> ServerName www.server1.test DocumentRoot "/var/www/server1" </VirtualHost> <VirtualHost 172.24.10.2> ServerName www.server2.test DocumentRoot "/var/www/server2" </VirtualHost> NameVirtualHost 172.24.10.2 <VirtualHost 172.24.10.2> ServerName www.server3.test DocumentRoot "/var/www/server3" </VirtualHost> <VirtualHost 10.0.0.1> ServerName www.server4.test DocumentRoot "/var/www/server4" </VirtualHost>
Damit würden fünf verschiedene Domains in drei logisch voneinander abgegrenzten Netzen zur Verfügung stehen.
Das Konzept der Ports gehört unmittelbar zu TCP/IP. Es wird in der entsprechenden RFC beschrieben ( RFC 793). Insgesamt gibt es 65 536 (216) ports, von denen die ersten 1024 (210) "reserviert" sind und die ersten 256 als "häufig verwendet" deklariert werden. Port 80 ist derjenige, der für das Hypertext Transfer Protocol (HTTP, siehe RFC 2616) normalerweise vorgesehen ist. Der Apache ist ein HTTP-Webserver, daher findet sich im "Global Environment" der httpd.conf eine Zeile:
Listen 80
Apache 1.3.x kann anstelle von Listen im Abschnitt "main server configuration" eine Anweisung
Port 80
enthalten, die es für Apache 2.0.x nicht mehr gibt (Das Konzept, wie ports angesprochen werden, unterscheidet sich in beiden Apache-Versionen). Das bedeutet, daß Apache port 80 benutzt und alle vorhandenen IP-Adressen berücksichtigt, da dafür keine Einschränkung vorgegeben wurde. Man kann den Apache nun anweisen, nur einige ganz spezifische Adressen zu beachten, was so aussehen kann:
Listen 192.168.0.2:80 Listen 172.24.10.2:80 Listen 10.0.0.1:80
Vorsicht! Jetzt sind Einschränkungen formuliert, das heißt, Apache wird alles ignorieren, was sich nicht den drei explizit angegebenen IP-Adressen zuordnen läßt - also ist mit einer solchen Einstellung beispielsweise http://localhost nicht mehr erreichbar, da diese Adresse ja mit der IP 127.0.0.1 verbunden ist. Und die wäre bei einer solchen Vorgabe ausgeschlossen. Aber alle fünf oben konfigurierten lokalen Domains sind erreichbar. Wird, wie hier, eine Kombination IP-Adresse:Portnummer notiert, so muß dieselbe Notationsweise auch auf <VirtualHost>-Container angewendet werden:
... NameVirtualHost 192.168.0.2:80 <VirtualHost 192.168.0.2:80> ...
Wird das versäumt, kann es zu Fehlermeldungen im Syslog kommen, die ungefähr so lauten: "[error] VirtualHost 192.168.0.2:0 -- mixing * ports and non-* ports with a NameVirtualHost address is not supported, proceeding with undefined results". Es kann gleichzeitig sein, daß der gewünschte virtuelle Host nicht erreichbar ist.
Wenn der Rechner, auf dem der Apache installiert ist, über eine aktive Internetverbindung verfügt und Apache auf port 80 eingestellt ist, ist er unter der aktuellen IP auch für Anfragen aus dem Internet erreichbar. Da es eine ganze Reihe von Robots und anderen Suchdiensten, aber auch ein paar "Schwarze Schafe" und aktive Viren bzw.Würmer gibt, kann das dazu führen, daß sich in den Protokollen (access_log) Zugriffsmeldungen finden wie zum Beispiel so etwas:
ideapilot-s01 - - [19/Jun/2004:14:33:00 +0200] "CONNECT 1.3.3.7:1337 HTTP/1.0" 405 1067 pd958e1a6.dip.t-dialin.net - - [20/Jun/2004:13:03:43 +0200] "SEARCH /\x90\x02 ... \x90\x90" 414 326 geosys03.kaist.ac.kr - - [22/Jun/2004:16:50:47 +0200] "CONNECT 1.3.3.7:1337 HTTP/1.0" 405 1067 traeumt.net - - [23/Jun/2004:01:16:51 +0200] "CONNECT 195.137.213.77:6667 HTTP/1.0" 405 1067 217.139.4.3 - - [30/Jun/2004:04:16:02 +0200] "GET /default.ida?XXXXXXXX%u9090%u6858%ucbd3%u7801 %u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b %u53ff%u0078%u0000%u00=a HTTP/1.0" 404 1204
Über die Interpretation der Protokolleinträge gibt es 
weiter hinten etwas mehr Informationen, hier ist erst einmal wichtig, zu sehen, daß der Apache auf solche Anfragen reagiert. In allen Fällen mit Zurückweisungen, wobei die zweite Meldung eine möglicherweise sehr unerwünschte "Kontaktaufnahme" bedeuten könnte. Die fünfte Protokolleintragung dokumentiert den mißlungenen Versuch, einen Wurm (Nimda) über port 80 einzuschleusen - übrigens von einem im ägyptischen Gizeh ansässigen Provider aus. Ein ungeschützter IIS anstelle des Apache wäre damit infiziert worden.
Solche Versuche, den Apache "von außen" zu erreichen, lassen sich deutlich zurückdrängen (aber nicht gänzlich vermeiden), wenn man ihm für den lokalen Gebrauch einen anderen port zuweist. Das kann beispielsweise in dieser Form geschehen:
Listen 192.168.0.2:32540 Listen 172.24.10.2:32555 Listen 10.0.0.1:25140
Port 80 ist damit zwar nicht "geschlossen" (das fällt in den Aufgabenbereich einer Firewall - ein Browser kann immer noch über port 80 beliebige Internetadressen erreichen), aber der lokale Apache interessiert sich nicht mehr für diesen port, sondern nur noch für die ports 32540, 32555 und 25140. Das heißt, obwohl es laut hosts-Datei einen auf die IP 172.24.10.2 gesetzten virtuellen Host www.server3.test geben sollte, passiert bei Aufruf von http://www.server3.test in der Adreßzeile eines Browsers gar nichts oder es gibt eine Fehlermeldung. Es muß also der port ebenfalls angegeben werden: http://www.server3.test:32555.
Man kann diese Konfigurationsmöglichkeit nutzen, um entgegen der oben aufgestellten Behauptung trotz fehlender IP-Adresse doch noch zwei verschiedene Webangebote zusammenzustellen, indem im Abschnitt "main server configuration" bereits ein DocumentRoot angegeben und in einem <VirtualHost>-Container ein anderes DocumentRoot festgelegt wird. Die relevanten Einträge in der httpd.conf sehen dann schematisch ungefähr so aus:
#====== global environment ===== ... Listen 80 Listen 2080 ... #====== main server configuration ===== ... ServerName Rechnername:80 DocumentRoot "/var/www/localhost" ... #===== virtual hosts ===== NameVirtualHost *:2080 <VirtualHost *:2080> ServerName www.server.test:2080 DocumentRoot "/var/www/server" </VirtualHost>
Im Browser bekommt man dann mit http://localhost oder http://Rechnername das in /var/www/localhost liegende Webangebot zu sehen, mit http://www.server.test:2080 dagegen das im Verzeichnis /var/www/server liegende Webangebot.
Welcher port benutzt werden soll, ist Ermessenssache des Server-Administrators. Es sollte allerdings möglichst keiner sein, der unterhalb der "reservierten" ports bis 1024 liegt.
In den 
Layoutvorgaben wird empfohlen, sich einen virtuellen Host einzurichten, wenn man beabsichtigt, eine Seite für den SELFHTML-Raum bereitzustellen - beispielsweise einen Artikel. Die dafür nötige URL ist http://aktuell.de.selfhtml.org/artikel/. Es ist deutlich zu sehen, daß es sich um Unterverzeichnisse einer SELFHTML-Domain handelt, für den virtuellen Host wird also nur ein Äquivalent für http://aktuell.de.selfhtml.org benötigt. Entsprechend dem oben gegebenen Hinweis kann es jedoch Konflikte geben, wenn man bei diesem Domainnamen bleibt und ihm in der lokalen hosts-Datei eine lokale IP zuordnet. Es kann passieren, daß das online-Angebot von http://aktuell.de.selfhtml.org nicht mehr zur Verfügung steht, sondern stattdessen grundsätzlich der virtuelle Host sein Webangebot an den aufrufenden Browser schickt. Um dieses Problem zu vermeiden, sollte als Domainname besser aktuell.de.selfhtml.test gewählt werden.
Angenommen, es handelt sich bei dem Rechner, an dem der "virtuelle SELFHTML-Autor" seinen bedeutenden Beitrag schreiben möchte, um einen Einzelplatzrechner ohne Netzwerkkarte und mit einer dynamisch zugewiesenen IP, und der "virtuelle SELFHTML-Autor" möchte sich nur ganz schnell mal ohne viel Aufwand einen Apache wie vorn beschrieben unter Windows einrichten, um sein Werk vor dem Absenden ans DEV-Team prüfen zu können. Es macht in diesem Fall keinen Sinn, in der hosts-Datei irgendeine lokale IP zu notieren. Da auch nur ein einziger virtueller Host benötigt wird, genügt die loopback-Adresse:
# lokale hosts-Datei 127.0.0.1 localhost 127.0.0.1 aktuell.de.selfhtml.test
Festlegungen zum gewünschten port sind nicht erforderlich, aber ein <VirtualHost>-Container wird natürlich benötigt:
NameVirtualHost 127.0.0.1 <VirtualHost 127.0.0.1> ServerName aktuell.de.selfhtml.test DocumentRoot "C:/selfaktuell" </VirtualHost>
Selbstverständlich müssen die nötigen Verzeichnisse noch rasch angelegt werden, was zu einem solchen Ergebnis führen kann:
Eventuell muß noch PERL und/oder PHP aktiviert werden, aber das ist ja kein Problem - und schon kann es losgehen mit dem Schreiben eines neuen Artikels.
SELFHTML aktuell Artikel Serverkonfiguration Die Apache-Konfigurationsdatei
© 2007 
Impressum, für diese Seite: 
christoph.schnauss@berlin.de
