DSM 3.0 1337 Virtual Host liste nicht mehr editierbar

[M!22]

Hi All,

bisher habe ich immer schnell alle Antworten in diesem Forum gefunden, wenn's mal etwas geholpet hat. Nennenswerte Probleme hatte ich bisher auch nur sehr wenige. Vorab also vielen Dank an alle die sich hier so stark engagieren.

Jetzt stehe ich jedoch vor einem Rätsel:
Ich betreibe auf meiner DS207+ mehrere kleine Internetseiten. Einige Sub-Domains und gegenwärtig auch zwei separate domains, die alle via CNAME und TWO-DNS zu erreichen sind.
Somit habe ich momentan 10 Virtual Hosts eingerichtet. Zu Testzwecken habe ich im laufe der vergangenen 1,5 Jahre auch immer wieder mal den ein oder anderen Virtual Host hinzugefügt oder entfernt. In dieser Zeit hatte ich zunächst den DSM 2.1, später 2.3 und bis heute keinerlei Probleme damit.
Heute habe ich erfolgreich das Update auf DSM 3.0-1337 getätigt.
Nun wollte ich wie "gewohnt" nochmals einen weiteren Virtual Host erstellen, in dem ich Namen des schon vorhandenen Unterverzeichnisses und den Hostnamen angebe - wie bei den anderen Einträgen auch - HTTP und die Port# sind ja vorgegeben

Klicke ich auf OK, erhalte ich eine port conflict-Fehlermeldung.
Wortlaut:
"Eine der Portnummern wird von einem anderen Dienst verwendet. Bitte wählen sie einen anderen Portbereich aus."

Diese Fehlermeldung erscheint ebenso, wenn ich versuche einen vorhandenen Eintrag zu ändern.

Ändere ich die Portnummer erhalte ich folgende Meldung:
"Diese Portnummer ist zur Verwendung durch das System reserviert. Benutzen Sie bitte eine andere Nummer."

Es ist mir also nicht mehr möglich die Virtual Hostliste zu editieren.

Gibt es noch jemanden der das Problem hat?
Gibt es vllt auch jemaden bei dem es mit dem aktuellen DSM funzt?
Wichtigste Frage: Lösung?

Grüße & Danke
M!ch!

 

[HarryPotter]

Es scheint mit den virtual hosts ein Problem zu geben, jedenfalls wird das im internationalen Forum heftig diskutiert:

http://forum.synology.com/enu/viewtopic.php?f=162&t=28551&p=114314&hilit=virtual#p114314

 

[M!22]

Zunächst mal vielen Dank für diesen Hinweis ... hatte ich noch nicht gefunden ...

Nun, die Jungs da schweifen da mal wieder etwas ab und diskutieren irgendwelche https-Details, doch zum Glück kommen die letztendlich doch auf den Punkt.
Jedoch muss ich leider sagen, dass in meiner Config. kein zusätzlicher http-Port vergeben ist. Also kann ich den auch nicht abschalten und dann läufts so wie bei den beiden dort.
Ich habe es natürlich auch schon umgekehrt versucht und einfach mal einen 2. http-Port eingerichtet und die vorhandenen Virtual Hosts darauf umzuschalten.
Auch die Idee das der Dienst der stört evtl. die PhotoStation sein könnte hatte ich schon und hab diese mal abgeschaltet.

Das auch alles schon vor meinem Post hier.

Ich kann die Virtual Hostliste nach wie vor nicht verändern.

Die vorhandenen VHs funktionieren jedoch ausnahmslos (sowohl die http's als auch die https's)
Es scheint als nur an der Routine zu liegen, die den Eintrag in die VH-Liste abspeichert und die Eingaben als fehlerhaft bewertet.
Hinter dem Wortlaut der Fehlermeldung verbigt sich diese Variable --> error_port_conflict
habe ich hier gefunden
--> http://www.synology-wiki.de/index.php//usr/syno/synoman/webman/texts/ger/strings

Ich bin kein linux professional. Wenn mir aber jemand sagen kann wie ich die VH-Liste ggf. über Telnet editiren kann, wäre mir zunächst schon mal sehr geholfen.

Danke und Grüße
M!ch!

 

[tunix]

Nachdem ich den zusätzlichen Port bei der Photostation deaktiviert hab, kann ich neue vHosts eintragen. Sub-Dir vorher angelegt.



auf einer 207+ DM3.0 1337

 

[jahlives]

Eine grundsätzliche Frage: Wieso die vhosts nicht direkt in der Apache Conf eintragen und bearbeiten? Unser Wiki weiss mehr wie man das direkt in der Apache Conf machen kann.

Nur noch etwas kurzes zur "abschweifenden" Diskussion im intl Forum: Diese HTTPS Geschichte ist relativ wichtig im Zusammenhang mit vhosts. Sagen wir du hast den Haupt-Host domain.tld mit dem DocumentRoot /volume1/web. Dann willst du sub.domain.tld mit DocumentRoot /volume1/web/sub hinzufügen.
Das geht gut solange du nicht mit https verbinden willst. Sobald du https://sub.domain.tld eingibst kommt ein 404 not found resp wenn du eine index.html in /volume1/web hast, wird diese angezeigt. Es wird NICHT der Inhalt von /volume1/web/sub geladen.
Du siehst also den Inhalt des Haupt-Hosts obwohl du den vhost eigegeben hast. Die Subdomain kannst du via https nur so erreichen https://sub.domain.tld/sub, also via den Haupthost.

Es ist vom Protokoll her ausgechlossen, dass du einen vhost via https erreichen kannst. Das geht wirklich nur ausschliesslich über den Haupthost. Die Grundregel ist dabei: Über https kannst du nur erreichen was auch bei der Eingabe der IP als URL antwortet

 

[M!22]

Ehrlich gesagt, habe ich bisher alles, was ich mit der DS machen wollte über den DSM hinbekommen. Und ich nutze von den im DSM einstellbaren Applikationen sicherlich gut die Hälfte.
Es ist jetzt wahrhaft das erste Mal, dass sich hier ein Prob. ergeben hat, was über den DSM für mich nicht mehr zu lösen war. Ich werde also mal den Herrn Wiki fragen und direkt die Apache Conf zurechtbiegen. Danke für diese Info.

Ohne wiedersprechen zu wollen. Ich habe seit dem ich die DS besitze eine index.htm mit dem DocumentRoot /volume1/web und sub1.domain.tld mit dem DocumentRoot /volume1/web/sub1. Aber auch andere; sub2, sub3 usw. insgesamt sind es 4 die via https://sub.domain.tld erreichbar sind. Z.B. auch https://phpmyadmin.domain.tld – das funktioniert! Und noch weitere via http.

Wenn Du sagst, dass sei von der Protokollstruktur her nicht möglich, wundert mich das etwas, weil es ja zum Einen im DSM möglich ist, https mit dem entsprechenden Port auszuwählen und zum Anderen funktioniert es bei mir seit dem ersten Tag.
Ich habe bei df.eu eine Domain, verweise dort mit Typ CNAME *.domain.tld auf den DDNShost (bei two-dns.de) der auch direkt in der DS entsprechend eingetragen ist.
Dies nur zum Verständnis.
Ergibt sich durch den CNAME-Eintrag ggf. einen Unterschied oder liegt hier ein Verständnisproblem meinerseits vor?
Oder liegt es daran, dass es in den bisherigen Versionen vom DSM nicht abgefangen wurde und jetzt mit dem DSM3.0-1337 auffällt, dass ich die ganze Zeit eine Reihe vhosts betrieben habe, die eigentlich nicht möglich sind?

Vllt. sollte ich vor dem Editieren der Apache Conf erst auf eine Antwort hierauf warten?!

In diesem Fall habe ich jedoch nur vor einen http vhost einzutragen, um auf mein eigentliches Problem zurückzukommen. Das geht jedoch nach wie vor nicht über den DSM.

Nochmals vielen Dank

 

[M!22]

Problem gelöst!

Leider musste ich selber drauf kommen ... deswegen hat's auch etwas gedauert. :-/
Ich habe mir den Artikel zu vhosts dann im Wiki mal durchgelesen und mich nach wie vor darüber gewundert, dass es via https nicht gehen soll.
Denn es hat ja wie beschrieben bei mir mit 4 vhosts funktioniert.
Eingerichtet hatte ich diese im DSM 2.2 und DSM 2.3. Jetzt nach dem Update auf DSM 3.0 kam es erst zum genannten Problem. Dennoch funktionierten die vier Seiten - und zwar auf diesem Wege: https:/sub.domain.tld
Wenn ich http://www.domain.tld/sup eingegeben habe, erschien die Meldung von der DS „Es tut uns Leid, die von ihnen gesuchte Seite konnte nicht gefunden werden.“
Dies sowohl vor als auch nach dem Update auf DSM 3.0!!!

Die oben erwähnte Fehlermeldung beim Versuch die vhost-Liste über den DSM 3.0 zu verändern, erfolgte aufgrund der eingetragenen https-vhosts. Nachdem ich diese alle in http geändert habe, konnte ich auch wieder weitere vhost-Einträge erstellen.

Es ist also so wie jahlives es oben beschreibt und alles verhält sich so, wie es im wiki detailliert nachzulesen ist. Jedoch konnte man bis zum DSM 2.3 vhost-Einträge mit https anlegen und die Seiten entsprechend erreichen, wenn man dem Browser den Zugriff “erlaubt“ hat (z.B. beim Firefox die Sicherheitsausnahmeregel hinzugefügt hat) … was vermutlich dazu führt das die Hostadresse dennoch aufgelöst werden kann?!
Aber hier reichen meine Kenntnisse zu diesem Thema wahrhaftig nicht aus …

Jetzt kann ich aber immer noch vhosts mit https anlegen, wenn ich eine abweichende Portnummer eingebe, z.B. 444. Doch dann passiert eben das was von jahlives und im Wiki postuliert wird: Es erscheint die index.htm die im DocumentRoot /volume1/web steht.

so far …

 

[jahlives]

Nur zur Sicherheit:
Konntest du wirklich im DS 2.3 eine Sub in /volume1/web/sub anlegen und diese dann via https://sub.domain.tld erreichen? Kann ich mich wirklich nicht vorstellen, denn du müsstest in diesem Fall den Inhalt von /volume1/web und nicht von /volume1/web/sub gesehen haben.

Wenn du natürlich einen anderen Port verwendest, dann sollte es eigentlich klappen. Denn dann verwendest du einen port-based-vhost und keinen name-based-vhost. Das müsste nach dem https Protokoll möglich sein.
Diese Einschränkung mit https gilt nur für die namensbasierten virtuellen Hosts. IP und Port basierte virtuelle Hosts kannst du via https erreichen.

Wenn du im DSM ein vhost namens sub.domain.tld mit http einrichtest, dann müsstest du den Inhalt eigentlich mit https://domain.tld/sub erreichen können

**edit**
Mit einer .htaccess Regel und mod_rewrite kannst du es so einrichten, dass es scheint also könntest du die sub via https erreichen
Sagen wir deine Sub heisst sub.domain.tld und der Haupthost ist domain.tld. Der DocumentRoot der Sub liegt unter /volume1/web/sub.
Dann kannst du mal das folgende probieren

#.htaccess
RewriteEngine on
RewriteCond %{HTTP_HOST} ^sub\.domain\.tld$
RewriteCond %{SERVER_PORT} ^443$
RewriteRule ^(.*)$ sub/$1 [L]

diese .htaccess müsste direkt in /volume1/web abgelegt werden
**/edit**

 

[itari]

Nur so am Rande. Es gibt im Verzeichnis /usr/syno/etc 2 Dateien für die Konfiguration der virtual hosts:

httpd-vhost.conf-user
httpd-ssl-vhost.conf-user

Itari

 

[M!22]

Ja wirklich!
Ich habe meine DS auf Empfehlung eines Freundes angeschafft, der sich vorher schon mit seiner eigenen vertraut machen konnte. Die erste Seite, die ich auf meiner DS zum Laufen brachte, habe ich via https mit einem vhost-Eintrag zugänglich gemacht, da zum gegebenen Zeitpunkt klar war, dass dies nicht die einzige Seite bleiben wir und ich diese mit einem PW schützen wollte. Erst später habe ich weitere ‘nicht‘-https Seiten hinzugefügt. Im web-Ordner direkt steht nur eine einzelne index.htm mit einem kurzen Text, damit nicht die Synology-Standartseite erscheint und jeder sofort weiß, was er vor sich hat.
Im Laufe der Zeit sind einfach weitere Seiten hinzugekommen.

Das das nicht gehen soll, habe ich nie gewusst und demzufolge auch niemals darüber nachgedacht.

Jetzt funktioniert es auch wieder! Denn man kann auch im DSM 3.0 https-vhosts einrichten. Nur eben nicht mit der Portnummer 443. Aber mit Port 444 geht’s!
Also habe ich alle Seiten die einem PW-Schutz unterliegen sollen, nun wieder auf https mit Port 444 umgestellt. In meinem Router (AVM Fritz!Box 7270) habe ich nun einfach den Port 443 von außen kommend auf Port 444 der DS umgeleitet (vorher 443). Den Port 444 musste ich zuletzt nur noch in der Firewall der DS freigeben.

Jetzt kann ich einfach gemäß dem vhost-Eintrag https://sup1.domain.tld eingeben und die Seite aus /volume1/web/sup1 erscheint. Gebe ich https://sup2.domain.tld ein, erscheinen die Seiten /volume1/web/sup2 und so weiter. Nicht zu erreichen sind die Seiten via http://sub1.domain.tld, da es ja hierzu keinen vhost-Eintrag gibt.
Jedoch sind diese Seiten auch via http://www.domain.tld/sub1 (/sub2, /sub3) zu erreichen. Der PW-Schutz erfolgt mit .htaccess. Um die Sicherheit zu gewährleisten logge ich mich auf dem zuletzt genannten weg nicht ein, um die PWs nicht preis zu geben. Stört also nicht weiter …

Ich habe den Eindruck, dass es auch über Port 443 funktionieren würde (das hat es ja im Grunde schon!!!), wenn der DSM 3.0 dies beim Erstellen eines vhost-Eintrages zulassen würde.

Dies kann ich auch gern demonstrieren, in dem wir uns nichtöffentlich austauschen und ich einfach mal im .htaccess-File einen Test-User für dich anlege.
Oder einfach mal selber ausprobieren. Wenn ich deine Signatur richtig deute steht noch eine DS109+ mit DSM 2.3 zur Verfügung …

Mein Problem ist somit gelöst und ich kann alles wieder so machen wie vorher.
Also dann …

PS: Sowohl den Rewrite als auch Redirect in einer .htaccess habe ich heute auch schon probiert. Jedoch ohne Erfolg. Danach bin ich dann gemeinsam mit meinem o.g. Freund auf die beschriebene Lösung gestoßen.
Eine Frage noch dazu: Ist es möglich, dass meine Konfiguration irgendwelche Sicherheitsrisiken birgt oder schwerwiegende Fehler verursacht werden?