Beiträge von M-Reimer

    Punkt 3 geht genauso über die Config-Dateien. Kannst da ja mal schauen wie wir es unter Arch machen.


    Und was du "verstreut" nennst, nennt sich "FHS". Unter Unix hat alles und jede "Art" von Datei ihren fest vorgegebenen Platz. Diese "Ordnung" erwarte ich bei meinen Systemen auch, da ich dann durch "intuitive Suche" dann extrem oft direkt ohne Doku-Lesen ans Ziel komme. Bei Arch kommen wir dem "Optimum" da hoffentlich schon recht nahe. Andere Distributionen haben da noch an einigen Details gedreht.


    Wegen X-Server-Start. Das ist und bleibt ein Hack. Bei Arch ist das mit xlogin und dem verlinkten Dropin gelöst. Richtig sauber geht nur wenn man Backend und Frontend getrennt startet und das Frontend dann sauber in eine Session packt. Da der VDR neben TV keine Multimedia-Fähigkeit hat, ist der Mehrwert durch eine "saubere Session" aber begrenzt.


    Deshalb auch als Dropin. Ohne dieses ist der VDR sauber als Dienst gestartet ohne "von hinten durch die Brust" nen X-Server hochzuleiern. Kodi starte ich dann in einer sauberen Session via xinit separat.

    Jondalar Das bedeutet mit tvheadend hat es funktioniert?

    Gerade für eine solche Anwendung wäre tvheadend möglicherweise durchaus im Vorteil

    • Kann selber mit IPTV umgehen
    • Hat selber ein brauchbares Webinterface für die Remote-Konfiguration

    Mit Plex bin ich selber nie warm geworden. Und sei es nur weil ich Open-Source eigentlich immer bevorzuge. Kodi macht schon einen guten Job.

    In der Vergangenheit sind so alte Dinger (Full-Featured-Karten) hier im Forum durchaus noch weggegangen wenn man sie gegen "Versandkostenerstattung" angeboten hat. Es gibt durchaus noch einige hier, die einen alten Full-Featured-VDR noch am Laufen haben und sich eine Karte als "Reserve" aufheben wollen.

    Du hast Recht. Es wurde viel diskutiert. Allerdings sind die nötigen Features alle bereits in den VDR gewandert. Hier nochmal vielen Dank an mini73 der den Code für die Config-Dateien geschrieben hat.


    Was ich schonmal ohne viel "Durchlesen" sagen kann, ist, dass deine Lösung zu "fett" ist.


    So machen wir's bei Arch Linux:

    https://github.com/VDR4Arch/vd…ob/master/vdr/vdr.service

    That's it. Mehr braucht es auch nicht.


    Wenn du den VDR mit Ausgabe betreibst, dann wird das hier noch nachinstalliert (als Drop-In)

    https://github.com/VDR4Arch/vd…er/vdr-xorg/vdr-xorg.conf

    Das Drop-In ergänzt das Environment und zieht einen X-Sever an. Damit das Drop-In geht muss "xlogin" installiert sein.


    So wie das aussieht nutzt du immer noch eine "runvdr". Die wird eigentlich garnicht mehr gebraucht.


    Und die anderen Dienste haben in aller Regel selber Systemd-Units. Um die müsstest du dich garnicht kümmern. Für Alsa gibt es sowas zum Beispiel definitiv und was cpufreq angeht:

    https://wiki.archlinux.org/ind…y_scaling#Userspace_tools


    Was ich ganz vergessen habe: Das der Kram bei dir unter /etc liegt ist sicher historisch bedingt. Wenn schon alles an einem Ort, dann packe es wenigstens nach /opt...

    Wenn der VDR keine Ausgabe konfiguriert hat wüsste ich nicht wohin er Live-TV wiedergeben sollte.

    Folglich sollte eigentlich der IPTV-Stream nicht laufen wenn keine Aufnahme läuft.


    Bei offenen Ports habe ich vor X Jahren sogar mal einen Patch für den VDR erstellt, der dafür sorgt, dass der VDR nur auf "localhost" den Port öffnet wenn lediglich für 127.0.0.1 Zugriff erlaubt ist. Der ist schon länger Bestandteil vom VDR. Externe Plugins, die Ports öffnen, handhaben das aber unter Umständen noch nicht so.


    Oder anders gesagt: In der "Standardkonfiguration" öffnet ein aktueller VDR (2.4) normalerweise garkeine Ports nach außen. Allerdings weiß ich nicht wie sich das verhält mit den neuen Ports wegen diesem "Streaming" das Klaus eingebaut hat. Nutze ich selber nicht und werde ich auch nicht nutzen. Ich hoffe einfach mal, dass die Ports da auch erstmal zu sind.

    Ich habe das Repository, das ich immer wieder nachgezogen habe, mal umgezogen:


    https://github.com/VDR4Arch/vdr


    Das gibt dem ganzen eine etwas "neutraleren" Charakter. In meinem Benutzerkontext habe ich gerne nur Projekte die ich entweder selber entwickelt habe oder bei denen ich Pull-Requests laufen habe.


    Das mit "projects.vdr-developer.org" gebe ich auf. Was ich rausfinden konnte, war, dass das ein Mirror ist von hier: http://git.gekrumbel.de/?p=vdr.git;a=summary


    Ich konnte bisher aber keinen finden der den Mirror verbiegen könnte. Sollte sich doch noch jemand finden: Das neue GIT ist oben.


    Ich hoffe immer noch, dass Klaus irgendwie mal etwas in der Art (und sei es nur als Mirror) verfügbar macht. Wer keinen Bock auf "selber patchen" hat kann sich auf jeden Fall schon jetzt direkt einen Snapshot von oben ziehen um ein "fertig gepatchtes" VDR 2.4 zu bekommen.

    Spätestens mit 18 kann Kodi "intern" mit Emulatoren umgehen. Das ist dann in sofern praktisch, dass man die Controller direkt in Kodi konfigurieren kann und ein nahtloser Wechsel zwischen Spiel und Kodi möglich ist.

    Kommt Patch 18 eigentlich wieder? Frage nur weil ich die neuen gerne auf den GIT-Server übernehmen würde und da dann später noch ein Commit dazwischen frickeln wäre fummelig.

    Der letzte Angriff kam aber von innen über den Browser.

    (Wenn ich den folgenden C't Artikel richtig interpretiert habe)


    Stimmt. Und wie wird das effektiv über CSRF ausgenutzt? Natürlich indem man davon ausgeht das die Box auf "fritz.box" hört.

    Macht sie hinter einem komplett anderen Router aber nicht.

    Denkbar wäre bestenfalls eine Brute-Force-Attacke quer über die privaten IP-Ranges.

    Wer ganz auf Nummer sicher gehen will kann die Box aber natürlich auch in ihr eigens Subnetz packen. Bei einem Router wie dem hier:

    https://www.amazon.de/dp/B011N1IT2A/

    Gehen, wenn es gebraucht wird, bis zu 4 getrennte Netze.

    Der Bug hat nur den Fernzugriff betroffen und wurde auch über den Supportzeitraum hinaus gepatcht.

    Wenn die Box hinter der Firewall läuft und man auf Portweiterleitungen verzichtet ist sie von außen auch schwer anzugreifen.

    "Dahinter" geht alles was man bei ebay billig bekommt.

    Ich habe hinter als reiner "VoIP-Adapter" eine Fritz!Box 5050 im Einsatz.

    In dieser Anwendung ist auch vollkommen egal, dass das Modem in der 5050 an einem "modernen" DSL-Anschluss keine Verbindung mehr bekommen wird.


    Und um ehrlich zu sein: Ich hasse diese "One-For-All"-Ansätze. DSL ändert sich in letzter Zeit ständig. ADSL, VDSL, Vectoring, Super-Vectoring, ...

    Und jedes Mal wirft man nicht nur das Modem sondern auch den Router und die Telefonanlage mit weg.


    Bester Ansatz für Neuanschaffungen ist übrigens direkt VoIP-Telefone zu kaufen. Die laufen direkt an einem beliebigen LAN-Anschluss.