Strato, Domainumleitungen, Plesk und das leidvolle Einrichten von Virtuellen Hosts

Eine Notiz zum Aufsetzen von virtuellen Hosts unter widrigen Bedingungen

Meine Seite läuft seit heute endlich mit eigenem virtuellen Host. Das gibt mir unter anderem eigene Log-Dateien und eine stärkere Abtrennung meiner Daten von den anderen auf dem Server befindlichen (ich habe darauf zwar Zugriff, aber will soweit wie möglich davon entfernt sein solange ich nicht gezielt daran arbeite). Also: Eine sehr erfreuliche Meldung. Weniger erfreulich war allerdings der weg dorthin. Weil ich im Netz keine Lösung auf das konkrete Problem finden konnte, notiere ich hier mal meinen Lösungsweg.

Bedingungen

Der Server, auf dem meine Homepage gehostet wird steht bei Strato. Auch meine Domain läuft über Strato, allerdings in einem anderen Paket. Auf dem Server bin ich über Kontakte, das heißt ich bin bei Änderungen an den Config-Dateien sehr vorsichtig.

Um das ganze weiter zu verkomplizieren läuft auf dem Server Plesk, das zwar eine schöne Oberfläche zum Servermanagement bietet, aber (deshalb) auch in den Konfigurationsdateien herumpfuscht. Entsprechend musste einen Weg finden, bei dem meine Änderungen zumindest nicht direkt wieder von Plesk überschrieben werden.

Wichtig ist noch, dass auf dem Server sowohl nginx als auch Apache laufen: nginx wird als erstes aufgerufen und liefert statische Inhalte aus, also z.B. Bilder. Im Falle von dynamischen Inhalten - also z.B. PHP/Python-Dateien - leitet es zum Apache um, der diese dann ausliefert.

Problem

Mein Ziel war die Einrichtung eines eigenen VHosts für meine Webseite, während sich mehrere VHosts die IP teilen. Meine Webseite muss über eine Umleitung zum Server führen. Normal würde man hierfür einfach ein neues "Abonnement" in Plesk einrichten und bei der Domainumleitung die Option für "maskierte" Umleitung wählen.

Eine solche Option gibt es bei Strato allerdings nicht. Strato lässt nur die folgenden Umleitungsoptionen zu (siehe auch Stratos eigene Informationen dazu):

http : Eine einfache Umleitung, die dem Client sagt, dass er zum Ziel gehen soll. Der Client ruft dann einfach die Zielseite gesondert auf. D.h., dass in der URL-Leiste der tatsächliche Ort der Seite angezeigt wird und dass der Server nicht weiß, welche Domain eigentlich angesteuert wurde.

Frameset : Über einen frame werden die Inhalte eingebunden. D.h., die Domain führt nicht wirklich zum Server. Über die HTTP-Header wird mitgegeben, dass die Seite von außen eingebunden wurde. D.h., sollte man damit arbeiten, dass alle Einstellungen, die man macht auch zutreffen, wenn Daten vom Server von einer anderen Seite eingebunden werden.

Proxy : Über einen Proxyserver leitet wird die Domain zum Zielserver umgeleitet. In den HTTP-Headern wird vermerkt, dass der Umleitungshost (aber nicht der richtige) die gewünschte Domain ist.

Shared Gallery : Eine Spezial-Kategorie für Stratos "HiDrive Share Gallery". Eindeutig keine Option für mein Ziel, also habe ich da nicht weitergelesen.

Damit nginx und Apache erkennen können, dass ein bestimmter VHost abgerufen werden soll, muss die damit verbundene Domain in den HTTP-Headern als "Host" markiert sein. Das passiert bei keiner der gebotenen Umleitungsoptionen.

Von all diesen Optionen ist die "Proxy"-Option die einzige, die halbwegs meinem Ziel entspricht. Immerhin bleibt die Domain in der URL stehen. Theoretisch ließe sich der HTTP-X-Forwarded-Host auch vor dem verarbeiten zum HTTP-Host umschreiben, allerdings soweit ich herausfinden konnte nur über Zusatzmodule (die ich nicht installieren will, solange ich keinen eigenen Server benutze).

Lösung

Beim dritten durchlesen der Apache-Informationen kam mir endlich die richtige Idee: VHosts sollen eigentlich rein über die HTTP-Header unterschieden werden können - aber können auch über verschiedene Ports ausgeliefert werden. Meine Seite wird jetzt also auf Port 8008 (einem alternativen Port für HTTP) ausgeliefert, während beim aufrufen von Port 80 auf dem gleichen Server die Default-Seite ausgeliefert wird.

Damit das passiert muss nginx so eingestellt werden, dass es auch auf diesen Port reagiert und dann die richtigen Dateien ausliefert. Weil nginx erst zu Apache weiterleiten muss, kann man dem Apache danach einfach veränderte HTTP-Header mitgeben.

Plesk legt beim Anlegen eines neuen "Abonnements" zusätzlich zu den Verzeichnissen für die auszuliefernden Dateien ein Verzeichnis /var/www/vhosts/system/ an, in dem unter anderem Konfigurationsdateien für den einzelnen VHost zu finden sind. Plesk scheint diese bei Server-Neustarts nicht zurückzusetzen.

Entscheidend ist /var/www/vhosts/system/domainname/conf/nginx.conf. Weil meine Seite bisher kein HTTPS unterstützt, ist für mich nur der zweite Teil der Datei interessant. Hier muss "listen :80;" zum gewünschten Port umgeändert werden, also in meinem Fall "listen :8008;". Weiter unten muss dann beim Aufrufen von Apache statt "proxy_set_header Host $host;" der Name der Domain direkt in die Datei geschrieben werden, also in meinem Fall "proxy_set_header Host "jrenslin.de";".

Das ist sicherlich nicht die schönste Lösung, eher ein etwas eigenwilliger Hack. Aber immerhin, es funktioniert unter den gegebenen Bedingungen.

Update 2016-10-30

Einen Tag später hat sich herausgestellt, dass Plesk die Änderungen doch überschreibt. Man kann zusätzliche Anweisungen an Plesk in /var/www/vhosts/system/domainname/conf/vhosts_nginx.conf definieren. Die von mir beschriebenen Anweisungen beißen sich allerdings mit den Standardangaben.

Es bieten sich also zwei weitere Vorgehensweisen an: Entweder man ändert die Defaulteinstellungen, mit denen die Konfigurationsdateien überschrieben werden (was dann auch die anderen Seiten auf dem Server beträfe, also keine Option ist) oder man sperrt die Datei gegenüber jedenüber Bearbeitungen aller Art mit chattr +i /var/www/vhosts/system/domainname/conf/nginx.conf. Das kann bei zukünftigen Updates zu Problemen führen, aber sollte zumindest erstmal helfen.