[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.
-
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.
Diff
Alles anzeigendiff --git a/group_vars/all b/group_vars/all index 9f29ae9..7df6566 100644 --- a/group_vars/all +++ b/group_vars/all @@ -192,3 +192,7 @@ serial_ir_device: ttyS0 # Set the memory for the GPU core - rpihddevice needs 256 MB, which is the default value set by the playbook # rpi_gpu_mem = 256 + +# SAT>IP Plugin +# -d <num>, --devices=<number> set number of devices to be created +# plugin_satip_devices: 1 diff --git a/roles/autoinstall-satip/tasks/main.yml b/roles/autoinstall-satip/tasks/main.yml index 3943532..915bd30 100644 --- a/roles/autoinstall-satip/tasks/main.yml +++ b/roles/autoinstall-satip/tasks/main.yml @@ -14,3 +14,13 @@ state: present when: satip_devices | length > 0 notify: [ 'Restart VDR' ] + +- name: copy file | satip.conf if a Sat>IP server has been detected + template: + src: templates/satip.conf.j2 + dest: /etc/vdr/conf.avail/satip.conf + owner: root + group: root + mode: 0644 + when: satip_devices | length > 0 + notify: [ 'Restart VDR' ] diff --git a/roles/autoinstall-satip/templates/satip.conf.j2 b/roles/autoinstall-satip/templates/satip.conf.j2 new file mode 100644 index 0000000..0ac7eb6 --- /dev/null +++ b/roles/autoinstall-satip/templates/satip.conf.j2 @@ -0,0 +1,16 @@ +{{ ansible_managed | comment }} +# ------------------------------------ +# Configuration of SAT>IP Plugin +# ------------------------------------ + +# satip - SAT>IP Devices +# +# -d <num>, --devices=<number> set number of devices to be created +# -s <ipaddr>|<model>|<desc>, --server=<ipaddr1>|<model1>|<desc1>;<ipaddr2>|<model2>|<desc2> +# define hard-coded SAT>IP server(s) +# -s 192.168.6.237|DVBS2-4|OctopusNet +# -s 192.168.6.237|DVBS2-2,DVBT2-2|OctopusNet +[satip] +{% if plugin_satip_devices is defined %} +--devices={{ plugin_satip_devices }} +{% endif %}
-
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.
-
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...
-
Das sieht ja schon sehr vielversprechend aus...!!!
-
... anbei mal ein paar Screenshots vom experimentellen WFE ....
da hast du ja schon ordentlich was weitergebracht - auch die Fernbedienung sieht schon viel besser aus.
-
Nice!
-
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 ?
Diff
Alles anzeigendiff --git a/group_vars/all b/group_vars/all index 9f29ae9..657239d 100644 --- a/group_vars/all +++ b/group_vars/all @@ -23,6 +23,25 @@ vdr: safe_dirnames: true # escape characters (useful for windows clients and FAT/NTFS file systems) override_vdr_charset: "" # set the desired charset, e.g. "ISO-8859-9" +plugins: +# - name: satip # name of the first plugin +# conf_avail: # list of lines to add in /etc/vdr/conf.avail/satip.conf +# - --devices=1 # limit to one device +# - name: live # name of the next plugin +# setup: # list of variables to set in /var/lib/vdr/setup.conf +# - live.UseAuth: # name of the key +# value: 0 # turn off authentication +# - live.MarkNewRec: +# value: 0 # do not mark new recordings +# - name: rpihddevice +# setup: +# - rpihddevice.AudioPort: +# value: 1 # use HDMI +# - name: epg2vdr +# setup: +# - epg2vdr.DbHost: +# value: 10.1.10.146 # ip address of the epg2 server + # wait for dvb devices by adapter number # NOTE: This only works for devices that are discoverable by udev, not userspace drivers like sundtek tuners! # e.g. wait_for_dvb_devices: [0, 1] to wait for /dev/dvb/adapter0 and /dev/dvb/adapter1 diff --git a/roles/plugins/tasks/main.yml b/roles/plugins/tasks/main.yml new file mode 100644 index 0000000..3ac9aed --- /dev/null +++ b/roles/plugins/tasks/main.yml @@ -0,0 +1,33 @@ +--- +# file: roles/plugins/tasks/main.yml + + +- name: ensure vdr is stopped + systemd: + name: vdr.service + state: stopped + notify: [ 'Start VDR' ] + + +- name: "write vdr plugin configuration to /etc/vdr/conf.avail" + blockinfile: + path: /etc/vdr/conf.avail/{{ item.0.name }}.conf + block: | + {{ item.1 }} + marker: "# {mark} {{ item.1 }} is managed by yavdr ansible" + with_subelements: + - "{{ plugins }}" + - conf_avail + - skip_missing: True + + +- name: "configure /var/lib/vdr/setup.conf for plugins" + lineinfile: + path: /var/lib/vdr/setup.conf + regexp: '^{{ item.1 | first }}' + line: '{{ item.1 | first }} = {{ item.1.value }}' + with_subelements: + - "{{ plugins }}" + - setup + - skip_missing: True + diff --git a/yavdr07-rpi.yml b/yavdr07-rpi.yml index ec0857b..8740bcc 100644 --- a/yavdr07-rpi.yml +++ b/yavdr07-rpi.yml @@ -36,6 +36,7 @@ #- channellogos # use channellogos provided by https://github.com/Jasmeet181/mediaportal-*-logos # set the variable channellogos_languages to a list of the langues you want (see group_vars/all) # and link them to /var/lib/channellogos/ - this needs at least 300 MB of storage + - plugins # configure vdr plugins tags: - always handlers:
-
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.
-
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...
-
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.
-
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.
-
Danke für die Tipps, wieder was dazu gelernt.
Die Änderungen sind in meinem fork, falls du es verwenden möchtest.
-
Hallo,
.. wie immer ist das mit yaVDR ansible einfach nur ein Genuss.
Noch nie hatte ich ein derart smoothes VDR Ergebnis mit den Beeren.
Ich möchte der Einfachheit halber meine überbezahlten Intel PC's in Rente schicken - dazu fehlt mir nur eine Kleinigkeit:
für den Schnitt am Server würde es das remoteOSD Plugin brauchen, kann man das bitte ins PPA noch aufnehmen ?
Besten Dank
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!