33.3Virtuelle Hosts
Für jede Website (für jeden Host) ein eigener Webserver – das wäre angesichts der Leistungsfähigkeit aktueller Rechner eine Verschwendung von Ressourcen! Mit Apache können Sie dank sogenannter virtueller Hosts nahezu beliebig viele Websites parallel einrichten. Solange die Gesamtzugriffszahlen nicht an die Limits des Rechners gehen, bemerkt kein Anwender, dass die Websites in Wirklichkeit alle auf demselben Rechner laufen.
Aus technischer Sicht gibt es drei Verfahren, wie Apache entscheidet, an welchen virtuellen Host eine Webanfrage gerichtet ist. Als Ausgangspunkt dient in jedem Fall der vom Browser an den Server übertragene HTTP-Header.
-
Namensbasierte virtuelle Hosts: Apache erkennt die gewünschte Website anhand des im HTTP-Header enthaltenen Hostnamens. Diese Variante ist am einfachsten zu realisieren und am weitesten verbreitet.
-
IP-basierte virtuelle Hosts: Apache erkennt die gewünschte Website anhand der IP-Adresse im Header. Diese Vorgehensweise ist mit einem gravierenden Nachteil verbunden: Jeder virtuelle Host erfordert eine eigene IP-Adresse, und IP-Adressen sind für IPv4 Mangelware.
-
Port-basierte virtuelle Hosts: Apache erkennt aufgrund der Port-Nummer die gewünschte Website. Diese Variante ist in der Praxis unüblich, weil die Port-Nummer als Teil der Webadresse angegeben werden muss. Das sieht unübersichtlich aus und eignet sich bestenfalls für eine technisch versierte Zielgruppe, z. B. für Administratoren.
Ich beziehe mich in diesem Abschnitt wiederum auf die Default-Konfiguration von Debian bzw. Ubuntu. Dort ist es üblich, für jeden virtuellen Host eine eigene Konfigurationsdatei zu verwenden.
Wenn Sie Ihren Webserver unter Fedora oder RHEL einrichten, kommen naturgemäß dieselben Apache-Schlüsselwörter zum Einsatz. Allerdings erfolgen sämtliche Einstellungen wahlweise in /etc/httpd/conf/httpd.conf oder in /etc/httpd/conf.d/sitename.conf.
Virtuelle Hosts einrichten
In Apache 2.2 muss die Konfiguration an einer Stelle die Anweisung NameVirtualHost *:80 enthalten. Das ist die Voraussetzung dafür, dass Apache 2.2 namensbasierte Hosts unterstützt. Das *-Zeichen bedeutet, dass Apache alle hereinkommenden Webanfragen im Hinblick auf virtuelle Hosts auswertet. Wenn Ihr Server mit mehreren IP-Adressen ausgestattet ist und nur eine IP-Adresse für namensbasierte virtuelle Hosts gedacht ist, müssen Sie bei NameVirtualHost diese Adresse explizit angeben.
Ab Apache 2.4 ist das Schlüsselwort NameVirtualHost nicht mehr erforderlich. Apache erkennt bei der Analyse der Konfigurationsdateien automatisch, dass namensbasierte virtuelle Hosts verwendet werden.
Unter Debian und Ubuntu ist die Standard-Website in /etc/apache2/sites-available/default als virtueller Host definiert. Um einen neuen virtuellen Host zu definieren, legen Sie unter Debian oder Ubuntu eine neue Datei im Verzeichnis /etc/apache2/sites-available/ an. Diese Datei sollte genau eine <VirtualHost>-Gruppe enthalten. Die drei folgenden Listings geben je ein Beispiel für einen namens-, IP- und port-basierten Host.
ServerName gibt den Namen des Hosts an. Dieser Hostname muss in den Header-Informationen einer Webanfrage enthalten sein, damit Apache darauf reagiert. Optional können Sie mit ServerAlias weitere Namen nennen. Beispielsweise empfiehlt sich zur Einstellung ServerName www.meinserver.de die Ergänzung ServerAlias meinserver.de, damit ein virtueller Host mit oder ohne die vorangestellten Buchstaben www. verwendet werden kann.
Unter Apache 2.2 müssen Sie außerdem darauf achten, dass die Adressangabe in <VirtualHost> mit der von NameVirtualHost übereinstimmt.
Bei IP- und port-basierten Hosts muss die IP-Adresse mit einer der IP-Adressen des Servers übereinstimmen:
Vergessen Sie nicht, Zusatzports mit listen anzugeben!
Die Adress- und Port-Angaben in <VirtualHost> haben keinen Einfluss darauf, welche IP-Adressen und Ports Apache überwacht. In der Ubuntu-Standardkonfiguration sind nur die Ports 80 und 443 (https) vorgesehen. Die entsprechende Konfiguration erfolgt in /etc/apache2/ports.conf. Wenn Apache weitere Ports überwachen soll, müssen Sie ports.conf entsprechend erweitern. Weitere Informationen zur Apache-Konfiguration für virtuelle Hosts finden Sie hier:
http://httpd.apache.org/docs/2.2/de/vhosts
http://httpd.apache.org/docs/2.4/de/vhosts
Um einen virtuellen Host zu aktivieren bzw. später wieder zu deaktivieren, führen Sie nun unter Debian/Ubuntu a2ensite name bzw. a2dissite name aus und fordern Apache dann zum Neuladen der Konfigurationsdateien auf:
Theoretisch ist es möglich, mit a2dissite auch die Standard-Website des Servers zu deaktivieren. Das sollten Sie aber nicht tun, weil die Datei /etc/apache2/sites-available/000-default.conf diverse Standardeinstellungen für Apache enthält!
Sobald Sie virtuelle Hosts eingerichtet haben, wird die in sites-available/default definierte Standard-Website nur noch angezeigt, wenn Webanfragen für keine der virtuellen Hosts zutreffen.
Unter CentOS, Fedora, RHEL und SUSE entfallen die Kommandos a2ensite/a2dissite, weil sich alle Angaben zu den virtuellen Hosts in der zentralen Konfigurationsdatei httpd.conf oder in eigenen Dateien im Verzeichnis conf.d befinden. Dort durchgeführte Änderungen aktivieren Sie mit dem folgenden Kommando:
Beispiel
Dieser Abschnitt beschreibt, wie Sie auf einem Debian- oder Ubuntu-Server den neuen virtuellen Host firma-123.de einrichten – zusammen mit einem neuen Login firma123, sodass Ihr Kunde, Freund etc. den virtuellen Host selbst administrieren kann. Dabei gehe ich davon aus, dass die Web- und Logdateien des virtuellen Hosts innerhalb des Heimatverzeichnisses des neuen Benutzers firma123 angeordnet werden. Ebenso gut ist es möglich, zu diesem Zweck ein neues Verzeichnis /var/www-firma123 einzurichten und dem Benutzer hierfür Schreibrechte zu geben.
Der erste Schritt besteht darin, einen neuen Account einzurichten, ein Passwort zuzuweisen und die erforderlichen Verzeichnisse zu erzeugen. In den folgenden Kommandos müssen Sie natürlich firma123 durch den tatsächlichen Benutzernamen ersetzen!
Im zweiten Schritt erzeugen Sie eine neue Datei im Verzeichnis sites-available, die so ähnlich wie das folgende Muster aufgebaut ist. Abermals müssen Sie firma123 durch den tatsächlichen Benutzernamen ersetzen und außerdem statt firma-123.de den tatsächlichen Hostnamen angeben. Mit AllowOverride AuthConfig File geben Sie Ihrem Kunden relativ weitreichende Möglichkeiten, die Konfiguration der Website durch eine .htaccess-Datei anzupassen. Wenn Sie das nicht möchten, müssen Sie diverse Konfigurationsdetails absprechen und fix einstellen.
Zur Aktivierung der Website führen Sie die folgenden Kommandos aus:
Ihr Kunde muss nun nur noch die DNS-Konfiguration seiner Domain anpassen: Die zugeordnete IP-Adresse muss mit der Ihres Servers übereinstimmen. Sobald das der Fall ist, beantwortet Ihr Webserver alle Anfragen, die an www.firma-123.de gerichtet sind.
Wie ich bereits erwähnt habe, läuft Apache aus Sicherheitsgründen nicht mit root-Rechten, sondern unter einem Account mit eingeschränkten Rechten (www-data bei Debian/Ubuntu, apache bei Fedora/RHEL bzw. wwwrun bei SUSE). Stellen Sie die Zugriffsrechte der Webdateien so ein, dass Apache sie lesen kann!
Wenn Apache einzelne Dateien auch verändern soll (z.B. über ein PHP-Script), ordnen Sie den Verzeichnissen und Dateien die Gruppe www-data/apache/wwwrun zu und geben den Gruppenmitgliedern Schreibrechte (chmod g+w). Unter Fedora und RHEL müssen Sie außerdem den SELinux-Kontext korrekt einstellen.
Im obigen Beispiel werden alle Fehler- und Zugriffsmeldungen in eigenen Dateien für den virtuellen Host gespeichert. Diese Vorgehensweise erleichtert die Auswertung der Logging-Dateien. Allerdings ist die Anzahl der offenen Datei-Handles für Apache (wie für jeden anderen Linux-Prozess) beschränkt. Wenn Sie sehr viele virtuelle Hosts einrichten, müssen Sie alle Zugriffe in einer zentralen Datei protokollieren und diese Datei dann durch ein anderes Programm in kleinere Dateien je nach Host zerlegen. Weitere Informationen zu diesem Thema finden Sie hier:
http://httpd.apache.org/docs/2.4/vhosts/fd-limits.html
Virtuelle Hosts setzen voraus, dass die DNS-Konfiguration stimmt! Um die im vorigen Abschnitt beschriebene Website firma-123.de zu testen, muss der DNS-Eintrag der Domain firma-123.de auf die IP-Adresse Ihres Webservers zeigen. Änderungen am DNS-Eintrag kann nur der Eigentümer der Domain durchführen. Die meisten Domain-Händler bieten dazu entsprechende Werkzeuge an. Beachten Sie, dass DNS-Änderungen nicht sofort gelten. Die Synchronisation der vielen, weltweit verteilten Nameserver kann etliche Stunden dauern, auch wenn es oft schneller geht.
Bei Serverumbauten oder -umzügen besteht oft der Wunsch, den neuen Server zuerst in Ruhe zu testen, bevor die DNS-Änderung tatsächlich durchgeführt wird. Der einfachste Weg besteht darin, den neuen virtuellen Host anfänglich nicht namensbasiert, sondern port-basiert zu konfigurieren. Dazu entfernen Sie die ServerName- und ServerAlias-Anweisungen und geben im <VirtualHost>-Tag statt des Sterns die IP-Adresse des Servers sowie eine freie Port-Nummer an, beispielsweise so:
Standardmäßig verarbeitet Apache nur Anfragen, die an die Ports 80 und 443 (für https) gerichtet sind. Damit Apache auch den hier eingesetzten Port 12001 berücksichtigt, müssen Sie in /etc/apache2/ports.conf eine weitere Zeile mit Listen 12001 einfügen. Nun ist noch das Kommando service apache2 reload erforderlich, damit Apache die veränderte Konfiguration berücksichtigt. Jetzt können Sie den neuen Webauftritt mit Ihrem Webbrowser testen, indem Sie die IP-Adresse des Servers samt der Port-Nummer 12001 angeben, also beispielsweise 13.214.215.216:12001.
Ganz anders können Sie vorgehen, wenn sich bei einem Server-Umzug inklusive Wechsel auch die IP-Adresse ändert: In diesem Fall können Sie in Ruhe den neuen Server einrichten. Für Ihre Kunden ist der neue Server noch nicht sichtbar, weil Ihr DNS-Eintrag ja noch auf den alten Server verweist. Um den neuen Server aber schon jetzt selbst unter dem richtigen Hostnamen zu testen, können Sie auf Ihrem lokalen Linux-Rechner zu Hause (also nicht auf dem Server mit Apache!) vorübergehend den folgenden Eintrag in /etc/hosts vornehmen.
Nehmen wir an, für firma-123.de soll ein neuer Webauftritt erstellt werden. Momentan zeigt der DNS-Eintrag der Firma noch auf den alten Server, z.B. auf die IP-Adresse 234.234.236.237. Als Administrator haben Sie mittlerweile den neuen Server eingerichtet, der die IP-Adresse 123.124.125.126 hat. Jetzt möchten Sie testen, ob alles funktioniert. Also verändern Sie vorübergehend auf Ihrem lokalen Rechner /etc/hosts. Die dort durchgeführte Einstellung hat Vorrang vor allen Nameservern!
Der entscheidende Vorteil dieser Variante im Vergleich zur vorhin skizzierten Vorgehensweise mit einem eigenen Port besteht darin, dass beim Test auch alle Links funktionieren. Wenn Sie im Testbetrieb den Link http://www.firma-123.de/cms/seite-xy.html anklicken, wird auch die neue Seite wieder korrekt in Ihrem Webbrowser angezeigt.