You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

1

Friday, November 12th 2010, 5:03pm

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

This post has been edited 1 times, last edit by "Razorblade" (Nov 12th 2010, 5:06pm)


2

Friday, November 12th 2010, 5:17pm

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

Grüsse
TheChief
- VDR: Thermaltake DH 102 mit 7" TouchTFT * Mystique SaTiX-S2 Dual * Debian Wheezy/vdr-2.1.5/graphtft/MainMenuHooks-Patch * Intel Petium G3220 * DH87RL * Zotac GT630 * 1 TB System HDD * 4 GB Corsair Vegance * Harmony 900 (39-44W)
- Server: Zotac H55-ITX WiFi, Core i3 540, 4GB RAM, 4x4TB 3.5" WD RED + 1x500GB 2.5", Cine S2, vdr-2.1.6
- vdr-theme-darkred: https://github.com/TheChief79/vdr-theme-darkred

3

Friday, November 12th 2010, 5:20pm

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?

Joe_D

Professional

Posts: 977

Location: Kuchen

  • Send private message

4

Friday, November 12th 2010, 5:27pm

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

This post has been edited 1 times, last edit by "Joe_D" (Nov 12th 2010, 5:28pm)


5

Friday, November 12th 2010, 5:37pm

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...

6

Friday, November 12th 2010, 5:52pm

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

Grüsse
TheChief
- VDR: Thermaltake DH 102 mit 7" TouchTFT * Mystique SaTiX-S2 Dual * Debian Wheezy/vdr-2.1.5/graphtft/MainMenuHooks-Patch * Intel Petium G3220 * DH87RL * Zotac GT630 * 1 TB System HDD * 4 GB Corsair Vegance * Harmony 900 (39-44W)
- Server: Zotac H55-ITX WiFi, Core i3 540, 4GB RAM, 4x4TB 3.5" WD RED + 1x500GB 2.5", Cine S2, vdr-2.1.6
- vdr-theme-darkred: https://github.com/TheChief79/vdr-theme-darkred

7

Friday, November 12th 2010, 5:58pm

Das ist ja eine der Varianten, aber nicht die einzige Frage die ich aufgeworfen habe...

8

Friday, November 12th 2010, 6:01pm

Was spricht dagegen für die gewünschte Verschlüsselung ein etabliertes Verfahren zu benutzen, z. B. eine SSH-Verbindung?
1. gen2vdr ActivyEdition auf Activy 330, HD WD-10EAVS mit Digitus DS-33151 IDE-SATA Konverter
2. gen2vdr v2 auf Aopen i915GMm-HFS und CeleronM 360J, RAM 1GB, HD Samsung HD401LJ, DVD Pioneer DVR-A05, Funk-Tastatur Cherry mit USB-Empfänger, TT FF 1.5 (System nur noch selten im Einsatz)
3. gen2vdr v3 auf Gigabyte GA-E7AUM-DS2H (NVidia 9400 Onboard-Grafik) mit Core2Duo E8500, RAM 4 GB, SATA-Festplatte im Wechselrahmen, SATA BD-ROM/DVD-Brenner Pioneer, Tastatur, Skystar HD2

9

Friday, November 12th 2010, 6:09pm

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

This post has been edited 1 times, last edit by "Razorblade" (Nov 12th 2010, 6:36pm)


10

Friday, November 12th 2010, 7:00pm

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

11

Friday, November 12th 2010, 7:11pm

Quoted

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...

This post has been edited 1 times, last edit by "Razorblade" (Nov 12th 2010, 7:15pm)


gda

Im Forum Zuhause

Posts: 13,043

Location: HH

  • Send private message

12

Friday, November 12th 2010, 7:18pm

Quoted

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 12.04.2, Plex Media Server
Zbox HD-ID40, OpenELEC 4.0.2, PLEXBMC

13

Friday, November 12th 2010, 7:41pm

Quoted

Original von Razorblade

Quoted

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?


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.
1. gen2vdr ActivyEdition auf Activy 330, HD WD-10EAVS mit Digitus DS-33151 IDE-SATA Konverter
2. gen2vdr v2 auf Aopen i915GMm-HFS und CeleronM 360J, RAM 1GB, HD Samsung HD401LJ, DVD Pioneer DVR-A05, Funk-Tastatur Cherry mit USB-Empfänger, TT FF 1.5 (System nur noch selten im Einsatz)
3. gen2vdr v3 auf Gigabyte GA-E7AUM-DS2H (NVidia 9400 Onboard-Grafik) mit Core2Duo E8500, RAM 4 GB, SATA-Festplatte im Wechselrahmen, SATA BD-ROM/DVD-Brenner Pioneer, Tastatur, Skystar HD2

14

Friday, November 12th 2010, 8:02pm

@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!

mini73

Moderator

Posts: 5,518

Location: Flensburg

  • Send private message

15

Friday, November 12th 2010, 8:25pm

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.

meine Signatur

vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
vdr: yaVDR 0.2/pvr350 @ Sempron 64 LE-1200, MSI K9MM-V, 1x PVR350, 2x Satelco EasyWatch DVB-C
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | noepg | pvrinput | sundtek |
pre-alpha Plugins: | ddci CI-Support für DD/L4M (siehe Post 1048374) |

gda

Im Forum Zuhause

Posts: 13,043

Location: HH

  • Send private message

16

Friday, November 12th 2010, 8:36pm

Quoted

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 12.04.2, Plex Media Server
Zbox HD-ID40, OpenELEC 4.0.2, PLEXBMC

17

Friday, November 12th 2010, 8:54pm

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).

wilderigel

Im Forum Zuhause

Posts: 16,946

Location: Ansfelden

  • Send private message

18

Friday, November 12th 2010, 9:08pm

mach, wenn wer aufspringt gut fuer dich, wenn ned ned

plugin- und addonszene liegt derzeit sehr danieder.
2003 - 2011 - R.I.P.

gnapheus

Intermediate

Posts: 550

Location: erst Norden / jetzt Süden

  • Send private message

19

Friday, November 12th 2010, 9:12pm

@Razorblade
Meinst du sowas hier http://projects.vdr-developer.org/projects/esvdrp ?

LG

Joachim
Mein VDR: Digitainer II Gehäuse, Asus M85M-US2H, AMD Sempron 140, 2 GB RAM, 1 TB WD Festplatte, Satelco Easywatch / Terratec Cinergy DVB-C, IR- Fernbedienung mit Atric-Einschalter, yavdr-0.3.0a

20

Friday, November 12th 2010, 9:25pm

Quoted

Original von gnapheus
@Razorblade
Meinst du sowas hier http://projects.vdr-developer.org/projects/esvdrp ?


Vom Prinzip ja, aber ohne Java und die Notwendigkeit einen statischen Schlüssel auszutauschen ;-)