Vorschlag: Verschlüsselts und komprimiertes Interface zum VDR

  • Zurzeit verwendet jede Erweiterung, die Funktionen benötigt, die über die normalen SVDRP Möglichkeiten hinausgehen eine eigene Methode.
    Bekannte Beispiele dafür sind:
    - vdradmin (benutzt zwar natives SVDRP mit entsprechend schlechter Performance, bietet aber optional direkten Dateizugriff auf die EPG Daten)
    - live-plugin (integriert sich als Plugin)
    - vdr iphone remote (benutzt erstmal natives SVDRP, wegen schlechter Performance bei den EPG Daten und Verschlüsselungsmöglichkeiten optional eine Web-basierte Schnittstelle)
    (und sicher einige mehr)


    Das ist nicht unbedingt schlecht so, aber es ist auch eindeutig Verbesserungspotential vorhanden.
    Also habe ich mir überlegt eine neue, standardisierte Schnittstelle zum VDR einzuführen mit der Plugins oder Erweiterung folgende Möglichkeiten erhalten:
    - Verschlüsselung (für sichereren Zugriff)
    - Komprimierung (das sollte speziell bei großen Mengen EPG Daten die vorhandenen Engpässe beseitigen)
    - Authentifizierung


    Dazu würde ich gern eine Diskussion anregen, folgende Punkte fallen mir sofort ein:
    - Ist eine Integration als Plugin oder im eigentlichen VDR am sinnvollsten?
    - Würde Klaus überhaupt Patches akzeptieren wenn es auf eine Erweiterung des SVDRP Befehlssatzes hinausläuft?
    - Sind die Entwickler von derzeitigen Plugins/Erweiterungen überhaupt an solch einer standardisierten Schnittstelle interessiert?
    - Wie würde die sinnvollste technische Realisierung aussehen?
    - Wer würde bei der Implementation und Pflege helfen?


    Als erstes dachte ich spontan daran, einfach einen zusätzlichen SVDRP Befehl "STARTTLS" zu implementieren, der dann die Aushandlung der Verschlüsselung (und evtl gleich transparenter Komprimierung) anstößt. Das sollte nicht alllzu kompliziert sein, da es bereits einige Projekte (zB Mail Server) gibt, bei denen man sich Ideen oder sogar Codeschnipsel holen könnte. Authentifizierung hingegen würde schon größere Eingriffe erfordern sofern ich das Einschätzen kann.




    Ich habe das ganze auch (in Englisch) in der VDR Mailingliste gepostet:
    http://permalink.gmane.org/gmane.linux.vdr/43720

  • Also mir stellt sich jetzt die Frage, welchen Zweck das ganze haben soll. Erkenne denn Sinn dahinter nicht ganz.


    Grüsse
    TheChief

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Na wozu ist SVDRP denn da? Damit man extern zum Beispiel mit Erweiterungen auf den VDR zugreifen kann. Da das aber vielen Erweiterungen nicht ausreicht, benutzt jeden ihre eigene Methode um zB schnell/besser/überhaupt an EPG Daten zu kommen.
    Wieso soll denn jede Extension das Rad neuerfinden wenn man das auch zentral implementieren könnte?

  • Plugins können doch sowieso schon auf alles innerhalb des VDR zugreifen, mein Infosatepg z.B. drückt EPG-Daten direkt in die internen Strukturen rein, ganz ohne SVDRP.


    SVDRP ist IMHO nur für externe Skripte und dergleichen. Ansonsten kann man sich bei EPG-Daten überlegen, ob diese nicht gefiltert ausgegeben werden können (z.B. nur Kanal X von N1-N2 Uhr)


    Gruß


    Joe_D

  • Das macht sicherlich hauptsächlich Sinn für Erweiterungen richtig, und da auch hauptsächlich für Erweiterungen die eine externe Bedienung anbieten (wie zum Beispiel die genannten, vdradmin, live).
    Live hat das ja ganz gut gelöst (durch die Integration als Plugin) aber man kann die dort gemachte Arbeit nicht "einfach" in anderen Projekten nutzen...

  • Du könntest ja Deine Schnittstelle als Plugin bauen und wer die Schnitstelle benötigt, greift dann darauf zu.


    Grüsse
    TheChief

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Was spricht dagegen für die gewünschte Verschlüsselung ein etabliertes Verfahren zu benutzen, z. B. eine SSH-Verbindung?

  • ich halte SSL durchaus für ein "etabliertes" Verfahren, gegen SSH spricht, dass man eine extra Applikation starten muß (die außerdem nicht auf allen Geräten zur Verfügung steht) und für ssh ohne Passwort auch noch recht umständlich Host-Keys austauschen müßte...


    Edit: Eine Variante wäre natürlich die Verwendung von stunnel auf Seite des vdr, die Erweiterung kann dann entweder ebenfalls stunnel oder openssl libraries benutzen.
    Nachteile:
    - die in stunnel eingesetzt Kompression funktioniert afaik auch nur mit einem stunnel (binary) auf der Gegenseite
    - da jeder den stunnel selbst installieren und konfigurieren müßte, hätte man keinen echten "Standard" auf den sich eine Erweiterung berufen kann
    - man bräuchte einen zusätzlichen Port, dadurch keine implizite Abwärtskompatibilität zu "vanilla" vdr

  • Ich finde kompression und Absicherung und authentifizierung jetzt nicht immanent wichtig. Ich würde den Port auch dann nicht weiter gesichert ins Netz lassen. Die Hauptprobleme sind EPG Austausch und Single-Connection. Der EPG Austausch sollte u.U. ganz anders gelöst werden (EPG DB Backend ?) - am drängensten wäre wohl den Zugang zu svdrp nicht zu blockieren, sondern mehrere Verbindungen gleichzeitig zuzulassen. Das kann man zwar mit svdrpd ausgleichen, aber schön ist das nicht.

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

  • Zitat

    Original von steffen_b
    Ich finde kompression und Absicherung und authentifizierung jetzt nicht immanent wichtig.


    Ich schon oder was siehst Du als Alternative um z.B. mit einem Smartphone aus der Ferne den VDR zu programmieren? Wenn es erstmal eine einheitliche Schnittstelle dafür auf dem vdr gibt, würde es den diversen remote-apps (die es bereits gibt) etwas leichter gemacht einheitlich (und eben abgesichert) auf den vdr zuzugreifen.
    Der Vorteil bei der Benutzung von SSL und Zertifikaten ist ja, dass man (wenn man Port zB ins Internet öffnet) durch eine Authentifizierung anhand des Client-Zertifikats durchführen könnte. Damit könnte eine App (ohne weitere User/password) Authentifizierung auf den VDR zugreifen.


    Edit: Kommen den die derzeitigen Performance Probleme z.B. beim Abruf der EPG Daten durch svdrp selbst oder nur durch die großen Volumen der Daten (auf dem Übertragungsweg)? Ich bin bisher von zweiterem ausgegangen, deswegen wäre Kompression eine mögliche Lösung. Sollte es aber wirklich an der Performance von SVDRP selbst liegen wird das auch nichts bringen, da gebe ich Dir Recht...

  • Zitat

    Original von Razorblade
    Ich schon oder was siehst Du als Alternative um z.B. mit einem Smartphone aus der Ferne den VDR zu programmieren?


    Die erste Alternative wäre es nicht zu tun und die zweite, fast genauso gute, das Live-Plugin an geringere Auflösungen anzupassen.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Zitat

    Original von Razorblade


    Ich schon oder was siehst Du als Alternative um z.B. mit einem Smartphone aus der Ferne den VDR zu programmieren?


    Für solche Zwecke wurde VPN erfunden, das können viele Router. Smartphones sollten dies heutzutage auch beherrschen, sonst sind sie nur als Spielzeug für die Zwecke die der Provider vorbestimmt hat zu gebrauchen.


    Bestimmt besser als Ports nach außen zu öffnen und dann darauf zu hoffen dass die Anwendung sicher genug programmiert ist.

  • halbfertiger
    Nunja, also ein VPN zu öffnen um den VDR zu bedienen halte ich für mit Kanonen auf Spatzen geschoßen. Und die Aussage "Bestimmt besser als Ports nach außen zu öffnen und dann darauf zu hoffen dass die Anwendung sicher genug programmiert ist." lasse ich so auch nicht gelten, den die üblichen VPN-Endpunkte auf Home-Routern sind auch nicht anderes als ein Stück Software mit einer Variante von OpenSSL zur Verschlüsselung.


    gda
    Wenn Du es nicht brauchst ist "es nicht zu tun" natürlich eine Option, aber wenn dem so wäre hätte ich es nicht als Use-Case beschrieben. Variante zwei ist mal wieder eine Sonderlocke: man steckt viel Arbeit in die Anpassung verschiedener Auflösungen (nicht alle Smartphones habe die gleiche Auflösung) nur um dann wieder für ein einzelner Plugin programmiert zu haben ohne die Arbeit in anderen Plugins nutzen zu können.


    @An alle Skeptiker: Mir geht es nicht darum OB man soetwas braucht oder nicht, sondern nur WIE ich es umsetze, nämlich so, dass der größtmögliche Mehrwert (nicht nur für meine Anwendungsfelder sondern auch für andere) entsteht. Ich dachte das ist das Prinzip von modularer Programmierung und OpenSource. Wenn IHR keinen Mehrwert für EUCH erkennt, dann braucht ihr mir mein vorhaben trotzdem nicht ausreden. Wenn ihr allerdings konkrete Vorschläge habt, was ich bei der Implementierung beachten sollte, damit IHR auch etwas davon habt, dann her damit!

  • Moin!


    Das live-Plugin bietet doch schon einen https-Zugriff, ist dir das nicht genug? Und wenn man Statusbox, AJAX usw. in den Einstellungen abstellt, hab ich eigentlich kein Problem, meinen vdr über ein Smartphone zu programmieren.
    Außerdem hab ich auf meinem Router noch ein Apache mit Proxy-Modul laufen, der stellt den Zugang auch via https zur Verfügung (selbst wenn live das nicht bieten würde).
    Ich verstehe dein Anliegen, aber nicht dein Problem.


    Lars.

  • Zitat

    Original von Razorblade
    gda
    Variante zwei ist mal wieder eine Sonderlocke: man steckt viel Arbeit in die Anpassung verschiedener Auflösungen (nicht alle Smartphones habe die gleiche Auflösung)


    Na und? Seit wann muss man denn eine Webseite an jede denkbare Auflösung anpassen? Da hast du glaube ich etwas falsch verstanden. Ich dachte höchstens an ein anderes Layout für Geräte mit geringer Auflösung, damit man nicht all zu viel scrollen und zoomen muss. Ansonsten stimme ich mit mini73 völlig überein, dass Live schon jetzt völlig ausreichend ist um den VDR mit einem Smartphone zu programmieren. Und egal wie toll man svdrp umbaut, es wird nie besser sein können als die Anbindung von Live an den VDR. Ein Thread im selben Prozess wie die VDR-Threads, Datenaustausch über Memory.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Mir geht es doch nicht darum ein neues Interface für Live oder einen Ersatz für Live zu schaffen. Live war nur ein Beispiel (genau wie der Mobile Access).


    Aber "es wird nie besser sein können als die Anbindung von Live an den VDR. Ein Thread im selben Prozess wie die VDR-Threads, Datenaustausch über Memory" ist ja mal eine Aussage.


    Und nur damit ihr mir nichtmehr ständig davon überzeugen wollt Live zu benutzen, eine andere Anwendungen auf meiner ToDo Liste ist z.B. die Kopplung von VDR an EIB/KNX (z.B. Aufnahmesteuerung aus der KNX Visu).

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!