© lumineimages, 123RF
Die Adressknappheit und das Streben nach effizienter Ressourcennutzung haben die Virtualisierung in Webservern etabliert, noch bevor das Thema VMs und Container seine heutige Bedeutung erhielt. Dieser Artikel zeigt, wie sich mit modernen Webservern virtuelle Hosts aufsetzen lassen.
Mitte der 1990er Jahre lief unter einer IP-Adresse ein einzelner Webserver – meist der Apache-Server, der unter Linux schnell zum De-facto-Standard avancierte. Einmal installiert und konfiguriert, lieferte er zuverlässig eine Webseite aus – nach Anfragen zu dieser IP-Adresse immer dieselbe.
Dann wurden irgendwann die IPv4-Adressen knapp. Außerdem war es unpraktisch, für jeden noch so kleinen Webserver einen eigenen Rechner hinzustellen. Virtualisierte Rechner gab es noch nicht, also zauberten die Apache-Entwickler in der Version 1.1 als Lösung das Konzept der Virtual Hosts aus dem Hut. Auf einmal war es egal, wie viele Fully Qualified Domain Names (FQDN) auf dieselbe IP-Adresse zeigten: Der Webserver kümmerte sich um die korrekte Verteilung der Anfragen.
Deshalb kontaktiert der Webbrowser auch nicht nur die reine IP-Adresse, die er vom DNS erhält, nachdem das den FQDN aufgelöst hat, sondern gibt beispielsweise direkt nach der Anfrage »GET / HTTP/1.1« mit einer Angabe wie »HOST: www.wintermeyer.de« zusätzlich den gewünschten Host-Namen an. Das kann man per Telnet auf Port 80 ausprobieren (Listing 1, Zeile 1 bis 5).
Listing 1
Ausgaben eines virtuellen Hosts
$ telnet www.wintermeyer.de 80 Trying 89.221.14.204... Connected to www.wintermeyer.de. Escape character is '^]'. GET / HTTP/1.1 HOST: www.wintermeyer.de HTTP/1.1 301 Moved Permanently Server: nginx/1.10.3 Date: Fri, 27 Nov 2020 14:00:25 GMT Content-Type: text/html Content-Length: 185 Connection: keep-alive Location: https://www.wintermeyer.de/ <html> <head><title>301 Moved Permanently</title></head> <body bgcolor="white"> <center><h1>301 Moved Permanently</h1></center> <hr><center>nginx/1.10.3</center> </body> </html>
Im Beispiel aus Listing 1 hat der Webserver mit einem HTTP-Code 301 (Moved Permanently) geantwortet. Das bedeutet, dass diese Resource nicht mehr existiert und man bitte die neue URL benutzen soll. In diesem Beispiel liegt es daran, dass der Server die Webseite nicht mehr per HTTP ausliefert, sondern nur noch SSL-verschlüsselt per HTTPS. Um Endanwendern und Suchmaschinen das Leben so einfach wie möglich zu machen, definiert der Server-Betreiber dann eine 301-Umleitung. Der Browser versucht es in diesem Fall mit einer zweiten Anfrage an die neue URL. Für eine temporäre statt permanente Weiterleitung nutzt man den HTTP-Statuscode 302.
Dieser Artikel demonstriert, wie man mit Virtual Hosts verschiedene FQDNs auf demselben physischen System nutzt. Beim Einsatz von SSL-Verschlüsselung kommt man um diese Funktionalität nicht herum, selbst wenn man den Luxus einer eigenen IP-Adresse für seinen Webserver genießt.
Apache vs. Nginx
Auch wenn Apache ein, wenn nicht sogar der entscheidende Wegbereiter für stabile und schnelle Webserver auf Linux war, so hat Nginx heute einen etwas höheren Marktanteil. Der beläuft sich Stand November 2020 auf nicht ganz 34 Prozent bei allen Webservern weltweit, gegenüber knapp 27 Prozent für Apache [1]. Beide Webserver sind also in der Community sehr beliebt. Dieser Artikel stellt deshalb die Konfiguration sowohl für Nginx als auch für Apache vor. Bei Nginx benutzen wir dabei »Server«-Blocks, bei Apache »VirtualHost«-Blocks.
Ausgangspunkt soll ein frisch installiertes Debian 10.6 “Stable” sein, auf dem wir Virtual Hosts für die imaginären Domains »www.beispiel1.de« und »www.beispiel2.de« konfigurieren. Dabei kommen die Pakete aus dem Repository der Distribution zum Zug. Die IP-Adresse für den Server lautet 192.168.2.120.
Apache
Zunächst gilt es, den Webserver zu installieren. Im Fall von Apache gelingt das mit den Kommandos aus den ersten beiden Zeilen von Listing 2. Der Webserver ist damit installiert und läuft bereits, was man mit »systemctl status apache2« überprüfen kann. Die Default-Webseite lässt sich nun mit einem Webbrowser unter der URL »http://192.168.2.120« abrufen. Die ausgelieferte Webseite findet sich in der Datei »/var/www/html/index.html«.
Listing 2
Apache einrichten
# apt-get update
# apt-get -y install apache2
# mkdir /var/www/www.beispiel1.de
# mkdir /var/www/www.beispiel2.de
[... Verzeichnisse anlegen ...]
# chmod -R 755 /var/www/www.beispiel{1,2}.de
Für die beiden neuen Webseiten legen wir jeweils ein eigenes Verzeichnis an (Listing 2, Zeile 3 und 4). In jedes der beiden Verzeichnisse platzieren wir eine »index.html« mit dem Inhalt aus Listing 3, jeweils mit entsprechend angepasstem Domain-Namen. Die Rechte für diese Verzeichnisse setzen wir auf »rwx-rx-rx« (Listing 2, Zeile 6).
Listing 3
index.html
<html>
<head>
<title>Test für www.beispiel1.de</title>
</head>
<body>
<h1>Test für www.beispiel1.de</h1>
</body>
</html>
Apache konfigurieren
Die Konfigurationen für die auf dem System verfügbaren und aktivierten Webserver findent sich in den Verzeichnissen, die Listing 4 zeigt. In der Datei »/etc/apache2/sites-available/www_beispiel1_de.conf« legen wir noch eine minimale Basiskonfiguration für »www.beispiel1.de« an (Listing 5), analog verfahren wir für »www.beispiel2.de«.
Listing 4
Verzeichnisse für die Konfiguration
# tree /etc/apache2/sites-*
/etc/apache2/sites-available
--- 000-default.conf
default-ssl.conf
/etc/apache2/sites-enabled
--- 000-default.conf -> ../sites-available/000-default.conf
Listing 5
Minimalkonfiguration
<VirtualHost *:80> ServerName www.beispiel1.de DocumentRoot /var/www/www.beispiel1.de/ </VirtualHost>
Beide Konfigurationen sind allerdings noch nicht scharf geschaltet. Dazu müssen wir die Konfigurationsdateien entweder manuell nach »/etc/apache2/sites-enabled/« linken oder uns des Werkzeugs A2ensite bedienen (Listing 6, Zeile 1). Anschließend weisen wir Apache an, die neue Konfiguration einzulesen und damit die virtuellen Hosts verfügbar zu machen (Zeile 2). Das lässt sich wieder, wie in Listing 1 gezeigt, per Telnet testen.
Listing 6
Host (de-)aktivieren
# a2ensite www_beispiel1_de.conf # systemctl reload apache2 [...] # a2dissite www_beispiel1_de.conf # systemctl reload apache2
Um einen virtuellen Host wieder zu deaktivieren, könnte man mit Rm den entsprechenden Link löschen. Besser ist es aber, auch hier mithilfe des passenden Werkzeugs zu agieren (Listing 6, Zeile 4) und die geänderte Konfiguration erneut einzulesen (Zeile 5).
Um sich das Admin-Leben so einfach wie möglich zu machen, bedient man nur einen FQDN pro Konfigurationsdatei – ruhig aber sowohl für HTTPS als auch für HTTP. Rein technisch könnte man auch 100 verschiedene FQDNs in eine Datei aufnehmen, aber das wäre deutlich unübersichtlicher.
Redirects mit Apache
Ein einfaches Beispiel für die Benutzung von Virtual Hosts für denselben FQDN bietet das Umleiten aller »http://beispiel1.de« auf »http://www.beispiel1.de«. Das klappt gegebenenfalls auch umgekehrt – je nachdem, was die Marketing-Abteilung oder der hauseigene SEO-Guru für momentan angesagter halten. Dafür muss »/etc/apache2/sites-available/www_beispiel1_de.conf« den Code aus Listing 7 enthalten.
Listing 7
Redirects
<VirtualHost *:80> ServerName beispiel1.de Redirect permanent / http://www.beispiel1.de/ </VirtualHost> <VirtualHost *:80> ServerName www.beispiel1.de DocumentRoot /var/www/www.beispiel1.de/ </VirtualHost>
Zum Testen kommt »curl -I http://beispiel1.de« zum Einsatz. Das gibt die Header mit aus und liefert zunächst die Statusmeldung »301 Moved Permanently« mit Angabe der neuen Location »http://www.beispiel1.de«. Ein »curl -I http://www.beispiel1.de« sollte dann die Ausgaben aus Listing 8 erzeugen.
Listing 8
Zugriff auf umgeleitete Webseite
HTTP/1.1 200 OK Date: Sat, 28 Nov 2020 08:25:05 GMT Server: Apache/2.4.38 (Debian) Last-Modified: Fri, 27 Nov 2020 17:20:15 GMT ETag: "85-5b519dfafde34" Accept-Ranges: bytes Content-Length: 133 Vary: Accept-Encoding Content-Type: text/html
Nginx
Auch Nginx will zunächst nach dem Strickmuster aus Listing 2 eingerichtet werden (»apt-get -y install nginx«) und läuft nach der Installation bereits, was sich wiederum über Systemctl prüfen lässt. Hier gelangt man ebenfalls über »http://192.168.2.120« an die Default-Seite, die diesmal in der Datei »/var/www/html/index.nginx-debian.html« liegt.
Für die beiden neuen Nginx-Webseiten legen wir wieder jeweils ein eigenes Verzeichnis an (Listing 2, Zeile 3 und 4), speichern dort eine jeweils passende »index.html« à la Listing 3 und setzen dafür die passenden Rechte (Listing 2, Zeile 6).
Nginx konfigurieren
Die Konfiguration für den auf dem System verfügbaren und aktivierten Webserver findet sich in den Verzeichnissen, die Listing 9 zeigt. In der Datei »/etc/nginx/sites-available/www.beispiel1.de« legen wir nun eine minimale Basiskonfiguration für »www.beispiel1.de« an (Listing 10), analog verfahren wir für »www.beispiel2.de«.
Listing 9
Konfigurationsverzeichnisse
# tree /etc/nginx/sites-*
/etc/nginx/sites-available
--- default
/etc/nginx/sites-enabled
--- default -> /etc/nginx/sites-available/default
Listing 10
Minimalkonfiguration
server
{
listen 80;
server_name www.beispiel1.de;
root /var/www/www.beispiel1.de;
index index.html;
}
Auch hier müssen wir beide Konfigurationen noch scharf schalten. Dazu linken wir zunächst die Konfigurationsdateien manuell nach »/etc/nginx/sites-enabled/« (Listing 11, erste Zeile). Anschließend weisen wir Nginx an, die neue Konfiguration einzulesen und damit die virtuellen Hosts verfügbar zu machen (letzte Zeile).
Listing 11
Scharf schalten
# ln -s /etc/nginx/sites-available/www.beispiel1.de /etc/nginx/sites-enabled/ [...] # systemctl reload nginx
Wir testen die neue Konfiguration wieder wie in Listing 1 manuell per Telnet. Um einen virtuellen Host später zu deaktivieren, löscht man mit Rm den entsprechenden Link und liest die Konfiguration anschließend neu ein. Für die Anzahl der FQDNs pro Konfigurationsdatei gelten analog die schon zu Apache gemachten Ausführungen.
Redirects bei Nginx
Als einfaches Beispiel für die Nutzung von Virtual Hosts für denselben FQDN dient auch hier das Umleiten aller »http://beispiel1.de« auf »http://www.beispiel1.de« (Listing 12). Nach dem erneuten Laden der Konfiguration steht wieder der Test per »curl -I« an.
Listing 12
sites-available/www.beispiel1.de
server {
listen 80;
server_name beispiel1.de;
return 301 http://www.beispiel1.de$request_uri;
}
server {
listen 80;
server_name www.beispiel1.de;
root /var/www/www.beispiel1.de;
index index.html;
}
SSL mit Let’s Encrypt
Let’s Encrypt [2] stellt die einfachste Möglichkeit dar, SSL auf dem eigenen Webserver zu zum Laufen zu bringen. Glücklicherweise ist der Weg für Apache und Nginx identisch, bis auf einen kleinen Parameter beim Skriptaufruf.
Die Installation von Let’s Encrypt erfolgt über den Paketmanager Snapd, den man seinerseits zuerst einspielen muss (Listing 13, erste Zeile). An dieser Stelle muss man den User einmal ab- und wieder anmelden, damit alle Pfade korrekt gesetzt sind. Dann erfolgt das Einrichten von Let’s Encrypt mit den restlichen Befehlen aus dem Listing.
Listing 13
Let’s Encrypt einrichten
# apt-get -y install snapd [... Neuanmeldung ...] # snap install core # snap install --classic certbot # ln -s /snap/bin/certbot /usr/bin/certbot
Als nächster Befehl folgt ein Aufruf von Certbot entweder mit »–apache« oder »–nginx« als Parameter, für Apache also:
# certbot --apache
An dieser Stelle fragt Certbot zunächst nach einer gültigen E-Mail-Adresse und anschließend nach dem zu aktivierenden FQDN. Das Certbot-Skript konfiguriert den dabei gewählten FQDN automatisch und passt die Apache- beziehungsweise Nginx-Konfiguration entsprechend an.
Das Charmante daran: Das System kümmert sich jetzt ohne weiteres Zutun um das Aktualisieren der Zertifikate. Der neue Webserver lässt sich nun nur noch unter »https://www.beispiel1.de« erreichen, Anfragen an »http://www.beispiel1.de« leitet er automatisch per 301 auf HTTPS um. (jcb/jlu)
Infos
- Webserver-Marktanteile: https://news.netcraft.com/archives/category/web-server-survey
- Let’s Encrypt: https://letsencrypt.org
