Die folgende Lösung ist mit Risiken verbunden, da ihr euch hierbei mit den Konfigurationsfiles auf der Konsole anfreunden müsst. Macht also unbedingt eine Sicherungskopie einer jeden Datei BEVOR ihr sie ändert. Ausserdem seit ihr dabei wohl als root unterwegs. Seid also vorsichtig bevor ihr einen Befehl absetzt und kontolliert ihn lieber zweimal
Wenn ihr die Subs ohne DSM einrichten wollt, dann solltet ihr zuerst ein Backup aller Verzeichnisse der Subs machen. Dazu würde ich empfehlen gleich unter /volume1 ein neues Verzeichnis für alle Subs einzurichten z.B. /volume1/www
Dann kopiert ihr alle Verzeichnisse der Subs dorthin und zwar so, dass folgende Struktur entsteht:
/volume1/www
+ sub1
+ wordpress
+ blog
+ whatever
Dies stellt sicher, dass die Subs vom Haupthost (Hauptdomain) her nicht mehr erreichbar sind. Solange die Subs nur Unterverzeichnisse von /volume1/web sind kann man die Subdomain blog.domain.tld auch via domain.tld/blog erreichen und das ist eigentlich nicht Sinn und Zweck einer Subdomain ;)
Wenn ich euch für diesen Weg entscheidet dann müsst ihr euch des folgenden bewusst sein:
So eingerichtet Subdomains sind zwar für den Haupthost nicht mehr erreichbar.
Aber es ist auch VOLLKOMMEN unmöglich via HTTPS auf den Inhalt der Subdomains zuzugreifen.
Ausgeschlossen no way!!
Genaugenommen kann man aber auch die Subs (im DSM eingerichtet) NICHT via HTTPS erreichen. Würdet ihr bei der DSM-Lösung z.B. https://wordpress.domain.tld
eingeben, dann würde Euch die URL im Browser zwar suggerieren, dass alles geklappt hätte. Ihr würdet aber nur den Inhalt von domain.tld sehen. Denn HTTPS Requests können nur am Haupthost verarbeitet werden.
Das ist aber kein Apache spezifisches Problem, sondern das kann schlicht kein Server. Das ist eine Einschränkung seitens des SSL resp HTTP(S) Protokolls. Denn zum Zeitpunkt der Verbindungsaufbaus muss der Apache breits wissen welches Zertifikat verwendet werden soll. Er muss also den angefragten Hostnamen kennen. Nur steht dieser Hostname im HTTPS Request verschlüsselt. Um ihn zu entschlüsseln müsste der Server aber wissen welcher Schlüssel zu verwenden ist und das kann er nur wissen wenn er den Hostnamen (z.B. wordpress.domain.tld) kennt.
Die Regel ist eigentlich ganz einfach: Es kann via HTTPS nur erreicht werden, was auch bei Requests ohne Hostname (also direkt an die IP) antwortet. Und das ist der Haupthost. Der Vorteil bei der DSM Lösung ist, dass man den Inhalt der Sub z.B. so https://domain.tld/wordpress
auch via https erreichen kann, was bei der Lösung ohne DSM nicht mehr möglich ist.
Wenn ihr die Subs so einrichten wollt und auch die Einschränkung bezüglich HTTPS kennt und in Kauf nehmt, dann müsst ihr folgende Arbeiten als Vorbereitung machen:
v.a. der letzte Punkt ist wichtig, denn sonst funkt euch der DSM in euren Einstellungen rum.
In dieser Konfigurationsdatei für den User-Apache - zu finden unter /usr/syno/apache/conf/httpd.conf-user
- der Diskstation, müsst ihr eigentlich nicht viel ändern. Ziemlich weit unten in dieser Datei kommt ein Bereich mit verschiedenen Include
-Anweisungen. Sucht dort diejenige, die das File httpd-vhosts.conf einbindet und entfernt das Kommentarzeichen davor (#).
Include conf/extra/httpd-vhosts.conf
Dann solltet ihr ganz am Anfang der Datei die Variable PHPINI_DEF_BASEDIR
so anpassen, dass auch das Verzeichnis mit den Verzeichnissen der Subs erlaubt ist (sonst laufen alle PHP Scripte für die Subs nicht mehr)
PHPINI_DEF_BASEDIR=„/volume1/www:/restliche Pfade….“
Also einfach euer Verzeichnis voranstellen und sonst nichts ändern oder entfernen.
Dann solltet ihr noch folgende Variabeln suchen und euch deren Werte (falls überhaupt welche gesetzt sind) merken
ServerName
DocumentRoot
Diese Werte braucht ihr nachher für die Konfiguration der virtuellen Hosts. Wenn bei ServerName *:80
steht, dann müsst ihr euch diesen Wert nicht merken
Stellt zudem sicher, dass DocumentRoot
auf /volume1/web oder /var/services/web zeigt.
Diese Datei sollte unter /usr/syno/apache/conf/extra/httpd-vhosts.conf
liegen (Datei ggf anlegen falls nicht vorhanden). Dort drin werden also die virtuellen Hosts festgelegt. Als erste Zeile solltet ihr
NameVirtualHost *:80
setzen. Der Wert von NameVirtualHost
muss identisch sein zum globalen Wert in ServerName
. Diese Anweisung darf nur einmal vorkommen. Es ist ein häufiger Fehler NameVirtualHost
mehrfach zu setzen z.B. einmal in der Hauptkonfig und einmal im vhosts File. Das mag der Apache überhaupt nicht
Nach dieser einleitenden Anweisung werden die virtuellen Hosts gesetzt. Dabei ist der Aufbau eines VirtualHost Containers eigentlich sehr einfach
<VirtualHost *:80>
ServerName mydomain.homeip.net
ServerAlias www.mydomain.homeip.net www.localnet localnet
DocumentRoot /var/services/web
</VirtualHost>
<VirtualHost *:80>
ServerName blog.mydomain.homeip.net
ServerAlias www.blog.mydomain.homeip.net www.blog.localnet
DocumentRoot /volume1/www/myblog
</VirtualHost>
<VirtualHost *:80>
ServerName photo.mydomain.homeip.net
ServerAlias www.photo.mydomain.homeip.net *.mydomain.homeip.net *.localnet
DocumentRoot /volume1/www/cp
#DocumentRoot /usr/syno/synoman/phpsrc/photo/
</VirtualHost>
Wichtig ist der erste VirtualHost Container. Das ist derjenige für den alten Hauptserver. Dort also den Pfad und Host eintragen, den ihr auch unter HTTPS erreichen wollt.
Der DocumentRoot MUSS identisch sein wie der globale DocumentRoot
Beim letzten Container ist auch etwas speziell und zwar werden zum einen catch-all Aliase gesetzt d.h. für jede Sub die keinen expliziten Eintrag hier drin hat und für die ein Request beim Apache landet wird der Inhalt dieses DocumentRoot angezeigt. Ohne diese catch-all würde der Request vom DocumentRoot des ersten virtuellen Hosts bedient werden.
Zum andern zeigt die letzte (auskommentierte) Zeile des letzten Containers wie man die Photostation via Subdomain einbinden kann. Die Photostation kann aber weiterhin auch via https://mydomain.homeip.net/photo
und damit über SSL erreicht werden.
Ihr könnt aber logischerweise pro VirtualHost Eintrag nur einen DocumentRoot festlegen
Jetzt müsst ihr nur noch den Apache neustarten und auf allfällige Fehlermeldungen auf der Konsole achten
/usr/syno/etc.defaults/rc.d/S97apache-user.sh restart