Einrichten von mehreren Webseiten und Subdomains: Unterschied zwischen den Versionen
imported>Anjoho Keine Bearbeitungszusammenfassung |
imported>Jahlives |
||
Zeile 117: | Zeile 117: | ||
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. | 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 <pre>https://domain.tld/wordpress</pre> auch via https erreichen kann, was bei der Lösung ohne DSM nicht mehr möglich ist. | 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 <pre>https://domain.tld/wordpress</pre> auch via https erreichen kann, was bei der Lösung ohne DSM nicht mehr möglich ist. | ||
==== Vorarbeiten ==== | |||
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 | |||
# Verzeichnis für die Subs erstellen (z.B. /volume1/www) | |||
# Verzeichnisse der Subs in den neuen Ordner kopieren | |||
# Einstellung virtueller Host im DSM deaktivieren und alle Subs im DSM entfernen | |||
v.a. der letzte Punkt ist wichtig, denn sonst funkt euch der DSM in euren Einstellungen rum. | |||
Wenn ihr diese Punkte nicht machen wollt, dann solltet ihr bei der Konfig via DSM bleiben.<br />'''<code>Es gibt rein gar keinen Vorteil gegenüber der DSM-Lösung, wenn ihr die Verzeichnisse der Subs nicht in ein eigenes Verzeichnis ausserhalb von <span style="color:red">/volume1/web</span> verschiebt</code>''' | |||
==== httpd.conf-user ==== | |||
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 '''<code>Include</code>'''-Anweisungen. Sucht dort diejenige, die das File httpd-vhosts.conf einbindet und entfernt das Kommentarzeichen davor (#). | |||
Dann solltet ihr ganz am Anfang der Datei die Variable '''<code>PHPINI_DEF_BASEDIR</code>''' so anpassen, dass auch das Verzeichnis mit den Verzeichnissen der Subs erlaubt ist (sonst laufen alle PHP Scripte für die Subs nicht mehr) | |||
<pre> | |||
PHPINI_DEF_BASEDIR="/volume1/www:/restliche Pfade...." | |||
</pre> | |||
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 | |||
<pre> | |||
ServerName | |||
DocumentRoot | |||
</pre> | |||
Diese Werte braucht ihr nachher für die Konfiguration der virtuellen Hosts. Wenn bei '''<code>ServerName</code>''' *:80 steht, dann müsst ihr euch diesen Wert nicht merken :-) | |||
Stellt zudem sicher, dass '''<code>DocumentRoot</code>''' auf "/volume1/web" oder "/var/services/web" zeigt. | |||
==== httpd-vhosts.conf ==== | |||
Diese Datei sollte unter '''<code>/usr/syno/apache/conf/extra/httpd-vhosts.conf</code>''' liegen (Datei ggf anlegen falls nicht vorhanden). Dort drin werden also die virtuellen Hosts festgelegt. Als erste Zeile solltet ihr | |||
<pre> | |||
NameVirtualHost *:80 | |||
</pre> | |||
Der Wert von '''<code>NameVirtualHost</code>''' muss identisch sein zum globalen Wert in '''<code>ServerName</code>'''. Diese Anweisung darf nur einmal vorkommen. Es ist ein häufiger Fehler '''<code>NameVirtualHost</code>''' 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 ;-) | |||
<pre> | |||
<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 '''<code>https://mydomain.homeip.net/photo</code>''' und damit über SSL erreicht werden. | |||
Ihr könnt aber logischerweise pro VirtualHost Eintrag nur einen DocumentRoot festlegen | |||
</pre> | |||
<br /><br /> | |||
--[[Benutzer:Jahlives|Jahlives]] 21:33, 21. Apr. 2010 (UTC) | --[[Benutzer:Jahlives|Jahlives]] 21:33, 21. Apr. 2010 (UTC) |
Version vom 21. April 2010, 22:51 Uhr
Subdomains auf der DS einrichten
Einführung
Da die Vorgehensweise/Ablauf zum einrichten von mehreren Webseiten und Subdomains die selbe ist, wurden beide Themen hier zusammengefasst.
Was ist eine Subdomain ?
Bei einer Subdomain handelt es sich um eine vollständige Webseite, die unterhalb der Hauptdomain liegt.
Sie wird entweder durch Direkteingabe "www.subdomain.hauptdomain.de" oder über eine Verlinkung
innerhalb oder außerhalb der Hauptdomain aufgerufen.
Welche Bedeutung hat eine Subdomain ?
Mit einer Subdomain kann der Webseitenbetreiber einen bestimmten Inhalt/Rubrik zielgerecht anbieten
bzw. eine bestimmte Zielgruppe ansprechen.
Beispielsweise kann einer Firma auf ihrer Webseite jede Abteilungen mit einer eigenen Subdomain darstellen.
Hauptdomain --> "www.beispielbaumarkt.dyndns-domainname.com" Subdomain 1 --> "www.sanitaer.beispielbaumarkt.dyndns-domainname.com" Subdomain 2 --> "www.elektro.beispielbaumarkt.dyndns-domainname.com" Subdomain 3 --> "www.holz.beispielbaumarkt.dyndns-domainname.com" Subdomain 4 --> "www.forum.beispielbaumarkt.dyndns-domainname.com"
Oder eine Familie präsentiert sich im Internet, wobei jeder seine Seite ganz individuell gestaltet:
Hauptdomain --> "www.unsere-grosse-familie.dyndns-domainname.com".''' Subdomain 1 --> "www.karin.unsere-grosse-familie.dyndns-domainname.com" (z.B. Kochrezepte) Subdomain 2 --> "www.torsten.unsere-grosse-familie.dyndns-domainname.com" (z.B. Hobbys) Subdomain 3 --> "www.klaus.unsere-grosse-familie.dyndns-domainname.com" (z.B. Computerspiele) Subdomain 4 --> "www.marco.unsere-grosse-familie.dyndns-domainname.com" (z.B. Musik) Subdomain 5 --> "www.janine.unsere-grosse-familie.dyndns-domainname.com" (z.B. Lieblingstars) Subdomain 6 --> "www.photo.unsere-grosse-familie.dyndns-domainname.com" (Familienfotos)
Einrichten von Subdomains via DSM (Diskstation-Manager)
Mehrere Webseiten bzw. Subdomain auf der DS einrichten
(ausgehend von Disk Station Manager 2.2)
Bevor eine oder mehrere Subdomains eingerichtet werden können, ist zu prüfen, ob der dynDNS-Anbieter auch "wildcard" = "*" vor dem eigentlichen Domainnamen unterstützt.
Bsp.: www.*.mein-dyndns-domainname.com
Kann er das nicht, funktionieren auch Subdomains auf der DS nicht. Diese Funktionalität ist bei einigen Anbietern kostenlos, bei anderen wiederum kostenpflichtig. Darüber sollte man sich im Vorfeld informieren.
Um auf der DS abgelegte Webseiten über das Internet aufrufen zu können, müssen einige Einstellungen an der DS vorgenommen werden.
Einstellungen im DSM
Unter "Netzwerkdienste" --> "Webdienste" muss der Haken "Web Station aktivieren" gesetzt werden. Damit wird auf Volume1 ein Verzeichnis mit dem Namen "web" erstellt. Im Ordner "web" wird der Inhalt der Internetseite abgelegt, die dann über www.mein-dyndns-domainname.com erreicht werden kann. Im Ordner "web" muss für jede weitere Webseite/Subdomain ein eigener Ordner angelegt werden, in dem der Inhalt der zusätzlichen Internetseiten abgelegt wird. Die Ordnernamen für die Unterordner sind frei wählbar. In jedem Unterordner muss sich eine eigene index.htm, index.html oder index.php befinden.
Beispiel für mehrere Webseiten
volume1 --> web --> index.html (www.mein-dyndns-domainname.com) volume1 --> web --> seite1 --> index.html (www.mein-dyndns-domainname1.com) volume1 --> web --> seite2 --> index.html (www.mein-dyndns-domainname2.com) volume1 --> web --> seite3 --> index.html (www.mein-dyndns-domainname3.com)
Beispiel für Subdomains =
volume1 --> web --> index.html (www.mein-dyndns-domainname.com) volume1 --> web --> sub1 --> index.html (www.subdomain-1.mein-dyndns-domainname.com) volume1 --> web --> sub2 --> index.html (www.subdomain-2.mein-dyndns-domainname.com) volume1 --> web --> sub3 --> index.html (www.subdomain-3.mein-dyndns-domainname.com)
Unter "Netzwerkdienste" --> "Webdienste" das Button "Virtueller Host" betätigen. Es öffnet sich ein Fenster, in dem die Verbindungsdaten zu den Subdomains eingerichtet werden.
Folgende Beispiel-Informationen müssen eingepflegt werden:
für mehrere Webseiten -- Seite 1, 2, 3,...
Name des Unterordners: "seite1" Hostname: "www.mein-dyndns-domainname1.com" Protokoll: "http" Anschluss: "80" Name des Unterordners: "seite2" Hostname: "www.mein-dyndns-domainname2.com" Protokoll: "http" Anschluss: "80" Name des Unterordners: "seite3" Hostname: "www.mein-dyndns-domainname3.com" Protokoll: "http" Anschluss: "80"
für Subdomains -- Subdomain 1, 2, 3,...
Name des Unterordners: "sub1" Hostname: "www.subdomain-1.mein-dyndns-domainname.com" Protokoll: "http" Anschluss: "80" Name des Unterordners: "sub2" Hostname: "www.subdomain-2.mein-dyndns-domainname.com" Protokoll: "http" Anschluss: "80" Name des Unterordners: "sub3" Hostname: "www.subdomain-3.mein-dyndns-domainname.com" Protokoll: "http" Anschluss: "80"
Nach Eingabe der Daten mit OK bestätigen und die Webseiten bzw. Subdomain-Seiten sollten erreichbar sein.
--Anjoho 21:46, 21. Apr. 2010 (UTC)
Subdomains ohne DSM
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.
Vorarbeiten
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
- Verzeichnis für die Subs erstellen (z.B. /volume1/www)
- Verzeichnisse der Subs in den neuen Ordner kopieren
- Einstellung virtueller Host im DSM deaktivieren und alle Subs im DSM entfernen
v.a. der letzte Punkt ist wichtig, denn sonst funkt euch der DSM in euren Einstellungen rum.
Wenn ihr diese Punkte nicht machen wollt, dann solltet ihr bei der Konfig via DSM bleiben.Es gibt rein gar keinen Vorteil gegenüber der DSM-Lösung, wenn ihr die Verzeichnisse der Subs nicht in ein eigenes Verzeichnis ausserhalb von /volume1/web verschiebt
httpd.conf-user
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 (#).
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.
httpd-vhosts.conf
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
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 '''<code>https://mydomain.homeip.net/photo</code>''' und damit über SSL erreicht werden. Ihr könnt aber logischerweise pro VirtualHost Eintrag nur einen DocumentRoot festlegen
--Jahlives 21:33, 21. Apr. 2010 (UTC)