Ports durch Domains ersetzen

Wurde hier in den letzten Jahren schon mehrmals diskutiert, es müsste per Reverse Proxy mit rewrite-Regeln (bei Apache mod_proxy, mod_proxy_html und mod_rewrite) theoretisch gehen, ist wohl aber aufwändig.

Einfacher ist es eventuell, nur mit einem Reverse-Proxy und mehreren (Sub)domains + mehreren name-based virtual Hosts zu arbeiten, aber ohne mod_rewrite. Jeder Service bekommt eine Subdomain, und der Reverse-Proxy empfängt alle Requests auf Port 80 oder ggf. 443.

Alternativen zu Apache wären hier LightHTTPd, nginx oder pound.

Gruß
hepi

live braucht Patches damit das geht. Bei den EPG Images muss da nen führendes "/" weg und in pages/vlc.ecpp muss fürs Aufnahmestreaming der Server/Port weg damit das alles relativ ist.

Ansonsten geht das einfach so in Apache

RewriteEngine on


	RewriteRule ^/live$ http://%{SERVER_NAME}/live/
	RewriteRule ^/live(.*) http://127.0.0.1:5001$1 [P]

cu

Ich habe gestern mal sowas gebastelt mit yaVDR 0.5 und Apache mod_proxy. Ich konnte mit nur zwei zusätzlichen Konfigurationszeilen in der apache-vhost-Konfig einen reverse proxy für VDR Live aufsetzen, der anscheinend einfach komplett funktioniert. Mir sind bisher keine Probleme aufgefallen. Also ist yaVDR mit der beigepackten Live-Version da Reverse-Proxy-freundlich.

Gruß
hepi

Stimmt, solange live noch zusätzlich auf seinen Orgninalport erreichbar ist geht das. Nur wenn man Live an localhost bindet oder im Router nur die 80 durch leitet muss live gepatcht werden.

cu

Also meine Zielsetzung war das:

Live kann wie gehabt im ganzen lokalen Netz auf 8008 abgerufen werden.
Live soll neben anderen HTTP-Services von außen mit SSL-Verschlüsselung erreichbar sein.

Ich will jeden Service über einen virtuellen Subfolder ansprechen können:

https://meine.domain.dyndns.org/liveplugin/
https://meine.domain.dyndns.org/streamdevserver/
https://meine.domain.dyndns.org/etc/
https://meine.domain.dyndns.org/bla/

Mein Apache läuft nicht auf dem VDR, da der nicht immer an ist.

Gruß
hepi

Zitat von hepi

Live soll neben anderen HTTP-Services von außen mit SSL-Verschlüsselung erreichbar sein.

Dann muss live gepatcht werden, zumindest für die epgimages.
Ob streaming von außen sinnvoll ist...? Zumindest für Record- und Live-Streaming brauchts da auch Patches in live.

Ich habs bei mir so gelöst
[live/pages/vlc.cpp]

string videourl;
	if (Channel != 0) {
		int streamdevPort = LiveSetup().GetStreamdevPort();
		videourl = string("http://") + getenv("VDR_PLUGIN_LIVE_USER_PASS") + string("@") + getenv("VDR_PLUGIN_LIVE_HOSTNAME") + string("/streamdev/") + LiveSetup().GetStreamdevType() + "/" + *Channel->GetChannelID().ToString();
	}
	else {
		videourl = string("http://") + getenv("VDR_PLUGIN_LIVE_USER_PASS") + string("@") + getenv("VDR_PLUGIN_LIVE_HOSTNAME") + string("/live") + "/recstream.html?recid=" + recid;
	}

(Über Enviroment programmiert sich das einfacher ;))
VDR_PLUGIN_LIVE_USER_PASS ist ne GID die per cron regelmäßig erneuert wird und im VDR Startscript exportiert und von Apache ausgewertet wird. Aber bei SSL ist das ja nicht relevant.

Zitat von hepi

https://meine.domain.dyndns.org/streamdevserver/

Braucht auch Patches damit nicht versucht wird absolut drauf zuzugreifen.

--- /usr/local/src/myvdr-0.2.8/PLUGINS/UPSTREAM/src/streamdev/server/menuHTTP.c 2011-06-22 22:21:14.000000000 +0200
+++ /usr/local/src/myvdr-0.2.8/PLUGINS/BUILD/src/streamdev/server/menuHTTP.c    2012-04-25 18:45:40.000000000 +0200
@@ -117,7 +117,7 @@


 // ******************** cHtmlChannelList ******************
 const char* cHtmlChannelList::menu =
-       "[<a href=\"/\">Home</a> (<a href=\"all.html\" tvid=\"RED\">no script</a>)] "
+       "[<a href=\"/streamdev/\">Home</a> (<a href=\"all.html\" tvid=\"RED\">no script</a>)] "
        "[<a href=\"tree.html\" tvid=\"GREEN\">Tree View</a>] "
        "[<a href=\"groups.html\" tvid=\"YELLOW\">Groups</a> (<a href=\"groups.m3u\">Playlist</a>)] "
        "[<a href=\"channels.html\" tvid=\"BLUE\">Channels</a> (<a href=\"channels.m3u\">Playlist</a>)] ";
@@ -203,15 +203,15 @@
 {
        std::string typeMenu;
        typeMenu += (streamType == stTS ? (std::string) "[TS] " :
-                       (std::string) "[<a href=\"/TS/" + self + "\">TS</a>] ");
+                       (std::string) "[<a href=\"/streamdev/TS/" + self + "\">TS</a>] ");
        typeMenu += (streamType == stPS ? (std::string) "[PS] " :
-                       (std::string) "[<a href=\"/PS/" + self + "\">PS</a>] ");
+                       (std::string) "[<a href=\"/streamdev/PS/" + self + "\">PS</a>] ");
        typeMenu += (streamType == stPES ? (std::string) "[PES] " :
-                       (std::string) "[<a href=\"/PES/" + self + "\">PES</a>] ");
+                       (std::string) "[<a href=\"/streamdev/PES/" + self + "\">PES</a>] ");
        typeMenu += (streamType == stES ? (std::string) "[ES] " :
-                       (std::string) "[<a href=\"/ES/" + self + "\">ES</a>] ");
+                       (std::string) "[<a href=\"/streamdev/ES/" + self + "\">ES</a>] ");
        typeMenu += (streamType == stEXT ? (std::string) "[EXT] " :
-                       (std::string) "[<a href=\"/EXT/" + self + "\">EXT</a>] ");
+                       (std::string) "[<a href=\"/streamdev/EXT/" + self + "\">EXT</a>] ");
        return typeMenu;
 }

Für https://meine.domain.dyndns.org/streamdev/ ist aber nicht sehr schön (nur nen quick Hack), müsste in der Programmierung eleganter gelöst werden.

Das nur mal so als Pointer zu den problematischen Stellen der beiden Plugins.

cu

Danke für die Hinweise, ich werde es mir bei Gelegenheit anschauen. Live ist mir von außerhalb primär zum Programmieren von Timern wichtig, streamen von Aufnahmen ist mir momentan recht unwichtig. Bei streamdev würde mich höchstens Radio-Streaming interessieren, weil mein Upstream wohl für viel mehr auch nicht reicht, aber ist auch unwichtig. Wichtig ist mir momentan: Wakeup, Timer programmieren, etc.

Gruß
hepi

Zitat von timbo2k

hepi: wird die lösung in der 0.5er enthalten sein?

Der Reverse-Proxy läuft ja bei mir nicht auf dem yaVDR-Rechner, sondern auf einem unabhängigen Rechner (Goflex Net). Für meinen Anwendungsfall sehe ich keinen Grund, direkt auf dem yaVDR-Rechner den Reverse-Proxy + SSL-Zertifikat zu installieren. Es ist nur ein bisschen Apache-Konfiguration. Auf jedem yaVDR-Rechner läuft standardmäßig schon ein sehr schlanker Webserver bzw. mehrere basierend auf tntnet. Dort auch einen Apache zu installieren, kann jeder für sich gern machen, aber wir würden es nicht als Addon für yaVDR verpacken, weil es doppelt gemoppelt wäre.

Wenn ich hier jetzt Apache sage, kommt gleich der nächste und sagt "Lighttpd ist besser!" und dann kommt der nächste und sagt "Nginx ist besser!". Für mich war es einfach mit Apache schnell installiert, weil ich hier die meisten Praxiserfahrungen habe.

Gruß
hepi

Zitat von hepi

Wenn ich hier jetzt Apache sage, kommt gleich der nächste und sagt "Lighttpd ist besser!"

Was ja auch stimmt.

Zitat von hepi

und dann kommt der nächste und sagt "Nginx ist besser!".

Ne, die Config ist mir zu kryptisch.

Du hast natürlich Recht Henning, das hat nichts in yaVDR zu suchen.

Gerald

Hallo,

dieser Thread kommt meinem Problem schon sehr nah, daher beschreibe ich hier mal meine Erfahrungen und mein Problem in der Hoffnung auf Hilfe:

Also, ich habe als Reverse Proxy nginx im Einsatz, weil ich als einziges nginx dazu bewegen konnte auch meine Fritzbox ordentlich zu proxien. Mag sein dass das andere Tools auch schaffen, aber ICH hab's halt mit denen nicht geschafft .

Mit dem nginx-Default-Absatz

server {
  listen 443;
  server_name <dyndns-address>;
  ssl on;
  location / {
    proxy_pass http://<local-address>;
    proxy_redirect default;
  }
}

bekomme ich jedenfalls "live" (von yaVDR 0.5) sauber auf eine von überall verfügbare öffentliche https-URL ge-reverse-proxyt.

"streamdev" wird vollständig angezeigt, und ich habe auch noch keine falschen Umleitungen gesehen. Sender werden brav von vlc gespielt, nur in runtergeladenen Playlisten stehen immer erst einmal lokale Adressen, was aber mit nem Editor leicht zu korrigieren geht.

Probleme habe ich allerdings definitiv mit der Konfigurationsseite von yaVDR (Pfad "/admin/"). Die bekomme ich nur dann über die geproxyte-URL angezeigt, wenn der Browser sich im LAN befindet. Von Extern bleibt der Bildschirm hellblau leer bis auf einen kleinen weissen Streifen ganz oben.

Was ich hier so gelesen habe, könnte das damit zu tun haben, dass irgendwo im Code lokale und/oder absolute http-Pfade drinne stehen, oder/und Ports, die von aussen nicht erreichbar sind. Liege ich da (412 Tage nach dem letzten Kommentar hier in diesem Thread und somit einige viele yaVDR-Updates später) immer noch richtig?

Patchen von yaVDR kommt für mich als Anwender aber wohl eher nicht in Frage. Kann man das nicht durch geeignete "Rewrite" o.ä. Kommandos von nginx während der Laufzeit übersetzen lassen?

Muss aber nicht nginx sein, Apache und Lighttpd unterscheiden sich ja im Funktionsumfang diesbezüglich nicht allzu sehr von nginx. Übersetzen werd ich das dann schon können. Ich brauche nur den Weg, das Ziel finde ich dann schon irgendwie ...

Danke schon mal im Voraus
ako673de

Gelöst!

Am Ende hat es eine ganze Weile gedauert, bis ich auf die Lösung gekommen bin. Es wurde mir aber auch nicht wirklich einfach gemacht.

Ich habe den http-Verkehr bis ins letzte Detail untersucht, alles völlig identisch bei allen funktionierenden und nicht funktionierenden Systemen. Ich habe Browser neu gestartet, Caches und Histories geleert, usw. aber alles ohne Erfolg.

Auf den richtigen Weg hat mich dann der letzte verzweifelte Versuch gebracht, doch mal einen anderen Browser auf einem der nicht funktionierenden Systeme zu probieren. Und e voila, als das unerwarteterweise klappte (unerwartet ist das natürlich, wenn es bei zwei völlig identischen Firefoxen bei einem geht und beim anderen nicht) war die Saat gesetzt.

Also, worin unterscheiden sich die Browser? Na ja, Gedanke erst einmal geparkt und den bösen Firefox nochmal versucht. Ups, wieso geht das denn jetzt mit dem auch?! Vorher noch nie und jetzt nach einem einzigen Start eines anderen Browsers geht's und zwar immer und immer wieder, auch nachdem der andere Browser längst wieder unten ist. Hat sich was am http-Verkehr geändert? Nee, kein bisschen! What the f*** is going on! Was soll der andere Browser denn mit dem bösen Firefox zu tun haben? Hmm, die Broswer auf diesem System sind hinter einem recht restriktiven Proxy, aber immer noch erschliesst sich mir der genaue Zusammenhang nicht wirklich. Aber EGAL...

Auf dem zweiten bösen System hat die Installation von Fiddler, einem Webtraffic-Analyzer, ausgereicht, um ein ähnliches Phänomen zu bewirken. Direkt nach der Installation des Tools ging die Seite astrein auf. Und das bleibt auch so, nachdem Fiddler wieder weg ist. Auch unklar, aber auch EGAL...

Auf dem dritten bösen System, einem Android-Handy war es dann mal zur Abwechslung auch für mich verständlich. Da darf ich einfach nur nicht das integrierte Tool "Internet" zum Browsen verwenden, sondern muss z.B. Opera nehmen.

Ich hoffe das findet jemand hilfreich. Jedenfalls habe ich jetzt alle yaVDR-Pages erfolgreich über nginx (auf Port 80!) ins Internet reverse-geproxied. Auch Streaming geht mit ein wenig Geschick (man muss da nur mit "subs_filter" in den Antworten des Servers die lokalen Adressen durch Internet-Adressen ersetzen lassen).

ako673de