[FYI] yavdr-ansible auf dem Raspberry Pi (Version 2 und 3)

  • ich finde trotzdem das mit skindesigner/shady meine andere sd Karte mit MLD 5.1 besser läuft, da hat man einfach mehr Speicher frei. Auch mit den ganzen Senderlogos. Zusätzlich einen epgd samt mariaDB zu betreiben wird das komplett zum Erliegen bringen.


    Grundsätzlich gefällt mir von der Architektur das hier um längen besser als MLD, auch um daheim alles homogen zu halten. Vllt kriegt man das ja noch in den Griff.

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5

  • seahawk1986

    Schön wäre es, wenn man alle eigenen Konfigurationsparameter vom VDR und seiner Plugins per Playbook setzen könnte. Dann könnte man ohne manuellen Eingriff schnell wieder einen neuen VDR aufsetzen. Mir fehlen dazu aber noch ein paar Templates, z.B. für das SAT>IP Plugin. Um deine TODO List nicht noch größer werden zu lassen, habe ich mich mal an ansible versucht.

    Hier ein Template um in der satip.conf den Wert von --devices setzen zu können.

    Bitte mal prüfen und ggf. übernehmen.

  • Schön wäre es, wenn man alle eigenen Konfigurationsparameter vom VDR und seiner Plugins per Playbook setzen könnte. Dann könnte man ohne manuellen Eingriff schnell wieder einen neuen VDR aufsetzen. Mir fehlen dazu aber noch ein paar Templates, z.B. für das SAT>IP Plugin.

    Ich würde da langfristig gerne etwas generischeres für die Konfiguration der Plugins schaffen, damit man nicht für jedes einzelne Plugin eine extra Rolle bzw. Action benötigt, sondern nur eine Variable setzen muss - und idealerweise sollte das dann auch noch mit dem Webfrontend in spe zusammenspielen, damit man keine konkurrierenden Vorgaben erzeugt... - ich werde bei Gelegenheit mal einen Versuch mit https://docs.ansible.com/ansib…gins/lookup/varnames.html starten, damit sollte man Variablen mit einem bestimmten Namensschema einsammeln können.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Du hast Recht, bei meinen 4 Plugins ist das eine einfache Lösung, aber grundsätzlich braucht man hier eine generische Lösung. Ich habe den Pull Request geschlossen und versuche mich mal an einem generischen Vorschlag. Möglicherweise geht es auch über eine Variablen Liste. Letztendlich sind es ja nur zwei Stellen, wo Plugins konfiguriert werden (/etc/vdr/conf.d und /var/lib/vdr/setup.conf). Oder gibt es da noch mehr ?

  • Letztendlich sind es ja nur zwei Stellen, wo Plugins konfiguriert werden (/etc/vdr/conf.d und /var/lib/vdr/setup.conf). Oder gibt es da noch mehr ?

    Es gibt Plugins mit zusätzlichen Konfigurationsdateien (z.B. epgsearch) - für die wird sich extra Aufwand nicht vermeiden lassen, wenn man die komplett über das Playbook konfigurieren will.


    Ich bin da noch beim Experimentieren, wie man das sinnvoll umsetzen kann... - anbei mal ein paar Screenshots vom experimentellen WFE (das Abholen der Daten klappt schon mal recht gut, fürs Speichern der Änderungen muss ich mir noch was überlegen, ansible ist recht gemütlich, so dass es sich bei kleinen Aktionen ggf. lohnt das zu Fuß zu machen statt ein Playbook laufen zu lassen) - die Positionierung von Elementen mit vuetify und CSS ist für mich immer noch etwas ungewohnt, das wird hoffentlich noch runder, wenn man das Grundgerüst funktioniert...


    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    The post was edited 1 time, last by seahawk1986 ().

  • ... anbei mal ein paar Screenshots vom experimentellen WFE ....

    :wow da hast du ja schon ordentlich was weitergebracht - auch die Fernbedienung sieht schon viel besser aus. :tup

    MyVDR: yaVDR-Ansible (Ubuntu 18) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

  • seahawk1986

    die Oberfläche sieht gut aus.

    Ich habe jetzt mal eine neue Rolle gebaut, die generisch Plugins konfigurieren kann. Zumindest /etc/vdr/conf.d und /var/lib/vdr/setup.conf, für weitere Files wie bei epgsearch wird man wohl ohne Templates oder einfaches Kopieren einen Musters, wie bei channel.conf, nicht auskommen. Mehrere Muster sind auskommentiert in group_vars/all drin.

    Wie gefällt dir der Ansatz ?


  • Das sieht interessant aus - ich muss das mal in Ruhe durchspielen, ob das alles abdeckt, was das Playbook und das WFE da leisten müssen.


    Ich bin mir auch noch nicht sicher, ob es eventuell besser wäre die Konfigurationsdatei komplett zu überschreiben - sonst könnte aus Versehen es doppelte oder widersprüchliche Argumente geben.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich bin mir auch noch nicht sicher, ob es eventuell besser wäre die Konfigurationsdatei komplett zu überschreiben - sonst könnte aus Versehen es doppelte oder widersprüchliche Argumente geben.

    Das würde mir auch besser gefallen. Hätte aber dann wieder den Nachteil nicht generisch zu sein, weil die Werte für die Default Konfiguration für alle Plugins in der group_vars/all vordefiniert sein müssten.

  • Meine Arbeitsidee wäre folgende:

    • Wenn man keine Vorgaben macht, bleibt die mit dem Paket installierte Konfiguration erhalten
    • Wenn man Vorgaben macht, müssen diese alle Start-Argumente beinhalten. Beim Webfrontend (und ggf. einem angepassten vdrctl) könnte man das so lösen, dass die Konfigurationsdatei gelesen wird und als Basis für die weitere Bearbeitung dient. Beim Speichern wird dann nicht nur die angepasste Datei geschrieben, sondern auch die Vorgabe für Ansible angepasst - ob man das jetzt gleich in die host_vars/localhost oder eine Datei in /etc/ansible/facts.d/ schreibt, kann man sich überlegen
    • Zum Sichern der vollstängiden Konfiguration muss man generell einige Verzeichnisse mitnehmen (/etc/vdr, /var/lib/vdr/ (wobei man da ggf. einige Dotfiles auslassen kann), ggf. /etc/ansible/facts.d für vom Playbook erfassste Daten usw. - da könnte man sich z.B. mit https://docs.ansible.com/ansib…dules/archive_module.html etwas schönes basteln

    Momentan gewinnt das schöne Wetter bei mir eindeutig noch gegenüber Basteleien am Schreibtisch, dafür ist bei nasskaltem Wetter dann Zeit...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Deine Idee würde gehen mit meinem 2 Vorschlag, wenn man vor dem Schreiben der Variablen die Datei zurücksetzt. Mehr wäre wohl nicht zu erweitern.

    Ich versuche mich gerade noch an einer 3. Variante, die vorher die vorhanden .conf Files liest und dann die Teile, die nicht in host_vars enthalten sind, unverändert wieder zurück schreibt. Dann bräuchte man nicht alle Werte eines Plugins konfigurieren, sondern nur die geänderten. Aber ich habe es noch nicht hinbekommen, da reicht bis jetzt mein ansible KowHow noch nicht.

  • Deine Idee würde gehen mit meinem 2 Vorschlag, wenn man vor dem Schreiben der Variablen die Datei zurücksetzt.

    Dann könnte man ein Template statt einem Block in der Datei nutzen.

    Ich versuche mich gerade noch an einer 3. Variante, die vorher die vorhanden .conf Files liest und dann die Teile, die nicht in host_vars enthalten sind, unverändert wieder zurück schreibt.

    Da gibt es ggf. das Problem, dass einige Plugins eine kurze und eine lange Version für die Startargumente kennen (ist z.B. bei xineliboutput der Fall). Ich bin mir gerade nicht sicher, ob es auch Plugins gibt, die die Wiederholung von bestimmten Argumenten erlauben - daher könnte es etwas tricky sein, das sauber zu mergen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich bin mir gerade nicht sicher, ob es auch Plugins gibt, die die Wiederholung von bestimmten Argumenten erlauben

    Ich habe mir ein paar Plugins angeschaut und nichts dergleichen gefunden, das sollte also kein Problem werden.

    Da gibt es ggf. das Problem, dass einige Plugins eine kurze und eine lange Version für die Startargumente kennen

    Ja, das Restrisiko bleibt, wenn hier versehentlich gemischt wird.


    Ich glaube fast, es wäre für das WFE besser, die Files neu zu schreiben (kein Restrisiko), für die Erstinstallation wäre es besser, nur die geänderten Werte manuell eintragen zu müssen (weniger zu pflegen und kein Risiko, Werte zu vergessen). Also warum nicht beide Varianten, gesteuert über eine hosts_vars Variable.

  • Hallo seahawk1986 ,

    nun die 3. Variante, die beides kann: Über eine Variable wird festgelegt, ob ein merge mit der vorhandenen .conf oder ein replace gemacht werden soll.

    Die beiden Sub Tasks read_plugin_config.yml und write_plugin_config.yml könnten aus dem WFE aufgerufen werden um ein einzelnes Plugin zu konfigurieren.

    Um meinen RasPi vollständig zu konfigurieren, habe ich noch zwei weitere Erweiterungen eingebaut, alles hier zu finden. Kannst dich gerne bedienen, falls du da was für brauchbar hälts.

  • Danke, ich schaue mir das gerne an, was ich davon übernehmen kann.


    Auf die Schnelle ist mir in https://github.com/kfb77/yavdr…les/system/tasks/main.yml aufgefallen, dass man die Befehle zum Auslesen von Zeitzone und Hostnamen vereinfachen könnte (dann kommt man mit cmd statt shell aus):

    hostnamectl --static liefert den Statisch konfigurierten Hostnamen (ansonsten gibt es den nachdem gather_facts gelaufen ist auch über die Variable ansible_hostname bzw. wenn man den FQDN will ansible_fqdn) und timedatectl show -p Timezone --value liefert den String für die aktuell gesetzte Zeitzone.


    Zum Escapen von Pfaden für die Namen von Systemd-Mount-Units gibt es systemd-escape - deine Lösung mit den Ersetzungen würde z.B. über Leerzeichen und Umlaute in den Pfaden stolpern.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)