yavdr experimental für Ubuntu 20.04 (yavdr ansible @ focal)

Ok. Jetzt läuft er FAST durch ;-). Ich musste zwischendurch mal neu starten (nvidia), jetzt klemmt er nur noch hier:

TASK [yavdr-desktop : create osd2web.service for the session] ***************************************************************************************************************************
ok: [localhost]

TASK [yavdr-desktop : template] *********************************************************************************************************************************************************
ok: [localhost]

TASK [yavdr-desktop : template] *********************************************************************************************************************************************************
ok: [localhost]

TASK [yavdr-desktop : link /usr/bin/start-desktop to /var/lib/vdr/plugins/desktop/starter] **********************************************************************************************
ok: [localhost]

TASK [yavdr-desktop : enable and start yavdr-xorg for the vdr user] *********************************************************************************************************************
changed: [localhost]

TASK [yavdr-desktop : enable tmux.service] **********************************************************************************************************************************************
An exception occurred during task execution. To see the full traceback, use -vvv. The error was:     os.chdir(self.cwd)
fatal: [localhost]: FAILED! => {}

MSG:

Unexpected failure during module execution.

RUNNING HANDLER [Restart Samba] *********************************************************************************************************************************************************

RUNNING HANDLER [Start yavdr-xorg] ******************************************************************************************************************************************************

PLAY RECAP ******************************************************************************************************************************************************************************
localhost                  : ok=148  changed=17   unreachable=0    failed=1    skipped=18   rescued=0    ignored=0   

root@yavdr:~/yavdr-ansible#

Zitat von HagenS

Ok - Du hast völlig richtig vermutet. Ich hatte in der host_vars/localhost eine (!) Anpassung für den vdr-Block drin (override_vdr_charset) :-/. Ich hatte angenommen, er würde den Rest aus der group_vars/all nehmen...

Es gibt die Möglichkeit Dictionaries automatisch mergen zu lassen: https://docs.ansible.com/ansib…ml#default-hash-behaviour, aber das wird nicht empfohlen, weil es unerwünschte Nebenwirkungen haben kann, wenn man Werte eigentlich übersteuern statt mergen will.

Wenn ich den Task "yavdr-desktop" einzeln mit

sudo -H ansible-playbook yavdr07.yml -b -i 'localhost_inventory' --connection=local --tags="yavdr-desktop"

laufen lasse, dann geht das ohne Fehler durch, das install-script bleibt da mit o.g. Fehler hängen <grübel>.

Kannst du an die letzte Zeile in https://github.com/yavdr/yavdr…ocal/install-yavdr.sh#L11 mal ein -vvv anhängen und das Install-Skript erneut laufen lassen?

Zitat von seahawk1986

Kannst du an die letzte Zeile in https://github.com/yavdr/yavdr…ocal/install-yavdr.sh#L11 mal ein -vvv anhängen und das Install-Skript erneut laufen lassen?

Na klar. Es wird allerdings SEHR ausführlich... Hier mal der letzte Teil vor dem Abbruch:

[mux  10904] 12:07:50.239756 D mitogen.[fork.12910]: Router(Broker(adf0)): registering Context(1006, 'parent') to stream <Stream parent #dac0>
[mux  10904] 12:07:50.239964 D mitogen.[fork.12910]: Python version is 3.8.2 (default, Mar 13 2020, 10:14:16) 
[GCC 9.3.0]
[mux  10904] 12:07:50.240085 D mitogen.[fork.12910]: Parent is context 1006 (parent); my ID is 2147
[mux  10904] 12:07:50.240198 D mitogen.[fork.12910]: pid:12910 ppid:12883 uid:666/666, gid:666/666 host:'yavdr'
[mux  10904] 12:07:50.240285 D mitogen.[fork.12910]: Recovered sys.executable: '/usr/bin/python3'
[mux  10904] 12:07:50.241041 D mitogen.service.[local.10977.sudo.vdr]: PushFileService().store_and_forward('/usr/lib/python3/dist-packages/ansible/modules/system/systemd.py', [blob: 22263 bytes], Context(1006, 'sudo.vdr')) 'mitogen.Pool.abe0.0'
[mux  10904] 12:07:50.243326 D mitogen.service.[local.10977.sudo.vdr]: Pool(abe0, size=2, th='MainThread'): initialized
...
[mux  10904] 12:07:50.243675 D mitogen.[local.10977.sudo.vdr]: Dispatcher: Message(1006, 2146, 0, 101, 1003, b'\x80\x02(X!\x00\x00\x00yavdr-12862-7fe75f3f0740-4bc4f507q\x00X\x16\x00\x00\x00an'..5431) -> CallError('builtins.PermissionError: [Errno 13] Permission denied: \'/root/yavdr-ansible\'\n  File "<stdin>", line 3669, in _dispatch_one\n  File "master:/usr/local/lib/mitogen/ansible_mitogen/target.py", line 422, in run_module\n    return impl.run()\n  File "master:/usr/local/lib/mitogen/ansible_mitogen/runner.py", line 440, in run\n    self.setup()\n  File "master:/usr/local/lib/mitogen/ansible_mitogen/runner.py", line 851, in setup\n    super(NewStyleRunner, self).setup()\n  File "master:/usr/local/lib/mitogen/ansible_mitogen/runner.py", line 623, in setup\n    super(ProgramRunner, self).setup()\n  File "master:/usr/local/lib/mitogen/ansible_mitogen/runner.py", line 374, in setup\n    self._setup_cwd()\n  File "master:/usr/local/lib/mitogen/ansible_mitogen/runner.py", line 384, in _setup_cwd\n    os.chdir(self.cwd)\n')
...
[task 12862] 12:07:50.244261 D ansible_mitogen.mixins: _remove_tmp_path(None)
[task 12862] 12:07:50.246320 D mitogen.parent: starting no-reply function call to 'local.10977.sudo.vdr': mitogen.core.Dispatcher.forget_chain('yavdr-12862-7fe75f3f0740-4bc4f507')
[mux  10904] 12:07:50.246845 D ansible_mitogen.services: decrementing reference count for Context(1006, 'local.10977.sudo.vdr')
[task 12862] 12:07:50.247327 D mitogen: MitogenProtocol(unix_listener.10904): disconnecting
[mux  10904] 12:07:50.247639 D mitogen: <Side of unix_client.12862 fd 75>: empty read, disconnecting
[task 12862] 12:07:50.247632 D mitogen: Waker(fd=12/13): disconnecting
[mux  10904] 12:07:50.247858 D mitogen: MitogenProtocol(unix_client.12862): disconnecting
[task 12862] 12:07:50.247992 D mitogen: Router(Broker(18b0)): stats: 0 module requests in 0 ms, 0 sent (0 ms minify time), 0 negative responses. Sent 0.0 kb total, 0.0 kb avg.
[mux  10904] 12:07:50.250200 D mitogen.[local.10977.sudo.vdr]: Dispatcher: dispatching (None, 'mitogen.core', 'Dispatcher', 'forget_chain', ('yavdr-12862-7fe75f3f0740-4bc4f507',), Kwargs({}))
[mux  10904] 12:07:50.250380 D mitogen.[local.10977.sudo.vdr]: Dispatcher: Message(1006, 2146, 0, 101, 0, b'\x80\x02(NX\x0c\x00\x00\x00mitogen.coreq\x00X\n\x00\x00\x00Dispatcherq\x01X\x0c\x00\x00\x00forge'..138) -> None
The full traceback is:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/ansible/executor/task_executor.py", line 146, in run
    res = self._execute()
  File "/usr/lib/python3/dist-packages/ansible/executor/task_executor.py", line 645, in _execute
    result = self._handler.run(task_vars=variables)
  File "/usr/local/lib/mitogen/ansible_mitogen/mixins.py", line 142, in run
    return super(ActionModuleMixin, self).run(tmp, task_vars)
  File "/usr/lib/python3/dist-packages/ansible/plugins/action/normal.py", line 46, in run
    result = merge_hash(result, self._execute_module(task_vars=task_vars, wrap_async=wrap_async))
  File "/usr/local/lib/mitogen/ansible_mitogen/mixins.py", line 375, in _execute_module
    result = ansible_mitogen.planner.invoke(
  File "/usr/local/lib/mitogen/ansible_mitogen/planner.py", line 571, in invoke
    response = invocation.connection.get_chain().call(
  File "/usr/local/lib/mitogen/ansible_mitogen/connection.py", line 451, in call
    return self._rethrow(recv)
  File "/usr/local/lib/mitogen/ansible_mitogen/connection.py", line 437, in _rethrow
    return recv.get().unpickle()
  File "/usr/local/lib/mitogen/mitogen/core.py", line 963, in unpickle
    raise obj
mitogen.core.CallError: builtins.PermissionError: [Errno 13] Permission denied: '/root/yavdr-ansible'
  File "<stdin>", line 3669, in _dispatch_one
  File "master:/usr/local/lib/mitogen/ansible_mitogen/target.py", line 422, in run_module
    return impl.run()
  File "master:/usr/local/lib/mitogen/ansible_mitogen/runner.py", line 440, in run
    self.setup()
  File "master:/usr/local/lib/mitogen/ansible_mitogen/runner.py", line 851, in setup
    super(NewStyleRunner, self).setup()
  File "master:/usr/local/lib/mitogen/ansible_mitogen/runner.py", line 623, in setup
    super(ProgramRunner, self).setup()
  File "master:/usr/local/lib/mitogen/ansible_mitogen/runner.py", line 374, in setup
    self._setup_cwd()
  File "master:/usr/local/lib/mitogen/ansible_mitogen/runner.py", line 384, in _setup_cwd
    os.chdir(self.cwd)

fatal: [localhost]: FAILED! => {}

MSG:

Unexpected failure during module execution.

RUNNING HANDLER [Restart Samba] ***************************

Hast du das Git-Repo nach /root/yavdr-ansible geklont? Dann kannst du das Playbook auch direkt als root aufrufen - ändert das etwas? Das sudo -H ist ja nur dafür gedacht, dass man als normaler Nutzer arbeiten kann und die temporären Dateien beim Ausführen des Playbooks in /root/.ansible statt ~/.ansible landen.

Ok, ich kann den Fehler reproduzieren, wenn ich das Git-Repo nach /root klone. Scheint so, als würde mitogen nach der become-Direktive für den User vdr Probleme haben auf das Verzeichnis mit dem Playbook in /root zuzugreifen - der einfachste Workaround wäre das Git-Repo nicht nach /root zu klonen, sondern ein Verzeichnis zu nutzen, in dem andere Nutzer Lese-Rechte haben oder mitogen zu deaktivieren (also das if-Statement mit dem Export der Umgebungsvariablen dafür auszukommentieren: https://github.com/yavdr/yavdr…s/install-packages.sh#L21).

Zitat von seahawk1986

Hast du das Git-Repo nach /root/yavdr-ansible geklont? Dann kannst du das Playbook auch direkt als root aufrufen - ändert das etwas? Das sudo -H ist ja nur dafür gedacht, dass man als normaler Nutzer arbeiten kann und die temporären Dateien beim Ausführen des Playbooks in /root/.ansible statt ~/.ansible landen.

Ja - direkt ins Root-Homedir geklont. Und ja - das mit dem sudo ist schon klar, ich hatte es erstmal trotzdem drin gelassen. Ohne funktioniert es aber auch nicht bzw. läuft auf den gleichen Fehler.

Zitat von seahawk1986

Ok, ich kann den Fehler reproduzieren, wenn ich das Git-Repo nach /root klone. Scheint so, als würde mitogen nach der become-Direktive für den User vdr Probleme haben auf das Verzeichnis mit dem Playbook zuzugreifen - der einfachste Workaround wäre das Git-Repo nicht nach /root zu klonen.

Ok - Du hast mich überholt ;-). Ich teste das nochmal aus einem Homedir eines "normalen" Nutzers.

Na also - als " normaler" Nutzer läuft das ohne Fehler durch... Aber unter bionic hatte ich das auch als root durchgeführt, ohne derartige Probleme zu bekommen... Vielleicht läuft ja unter focal auch da etwas anders. Sollte dann aber irgendwo in der Doku auftauchen, dass man es nicht als root installieren darf :-).

Danke...!

Zitat von HagenS

Vielleicht läuft ja unter focal auch da etwas anders.

Ich habe unter focal mitogen for ansible eingebaut, um die Ausführung des Playbooks etwas zu beschleunigen (das versucht möglichst viel mit einem Prozess am Stück zu machen statt für jeden Schritt einen eigenen Prozess zu spawnen). Je nach Hardware spart das zwischen ein paar Sekunden und ein paar Minuten Laufzeit ein, wenn das komplette Playbook ausgeführt wird.

Zitat von HagenS

Sollte dann aber irgendwo in der Doku auftauchen, dass man es nicht als root installieren darf

Auf die Idee, dass jemand unnötigerweise als root unterwegs ist, muss man erst mal kommen , ich ergänze das bei Gegelegenheit noch in der README.md

Zitat von seahawk1986

Auf die Idee, dass jemand unnötigerweise als root unterwegs ist, muss man erst mal kommen , ich ergänze das bei Gegelegenheit noch in der README.md

Über "unnötig" kann man natürlich philosophieren . Da auf der Kiste nichts weiter läuft und der auch nur im internen Netz erreichbar ist, sehe ich da kein Problem drin - erst Recht nicht in der Ausführung der Ansible-Installation als root oder aus dem /root heraus... (zumal das ja auch noch ge-sudo't wird). Die Prozesse laufen dann später ja ohnehin unter einem dedizierten Nutzer .

Gibt es eigentlich eine Möglichkeit, nur durch Anpassungen an der host_vars/localhost am Ende der Installation zu veranlassen, dass relevante Konfig-Dateien geholt und ausgetauscht werden (wie ja schon für die channels.conf implementiert) und danach vielleicht noch die betroffenen Dienste neu gestartet werden? Dies würde den Aufwand an "Nacharbeiten" massiv reduzieren :-).

Bei mir sind das einige - spontan fällt mir da die boblight.conf und die smb.conf ein, beim epgd die channelmap usw., aber es sind natürlich noch viel mehr...

Da braucht es jeweils Rollen, die die nötigen Anpassungen anhand der gesetzten Variablen vornehmen. Für Samba kannst du bereits das Template https://github.com/yavdr/yavdr…fig/templates/smb.conf.j2 auf deine Wünsche anpassen. Für eigene Ergänzungen am Playbook vorbei ist /etc/samba/smb.conf.custom als include vorgesehen, die vom Playbook angelegt wird, wenn sie noch nicht existiert, aber an deren Inhalt vom Playbook nicht verändert wird.

Für Boblight könnte man sich überlegen, ob man da nicht eher ein Dictionary/Hashmap in der group_var/all befüllt und dann die Konfigurationsdatei als Template umsetzt.

Langfristig würde ich ja gerne noch ein Webfrontend bauen, da finde ich es konzeptionell schöner, wenn man von JSON Werten zu Variablen für die Ansible-Rollen kommt als wenn man da immer dicke Dateien durch die Gegend schieben muss (Ausnahmen wären Dateien, die sich nicht sinnvoll templaten lassen wie die setup.conf, channels.conf usw.).

Zitat von seahawk1986

Langfristig würde ich ja gerne noch ein Webfrontend bauen,

Das wäre toll!

Ich benutze es bei yaVDR 0.6x immer noch gerne.

Zitat von seahawk1986

Langfristig würde ich ja gerne noch ein Webfrontend bauen

Kann man dich dabei irgendwie unterstützen?

Fände ich nämlich auch cool, obwohl ich es seit Ansible nur mehr sehr selten vermisse.

Zitat von davie2000

Kann man dich dabei irgendwie unterstützen?

Wenn da jemand das nötige Wissen, Zeit und Lust hat, gerne. Das gleiche gilt übrigens auch für Ergänzungen für yavdr-ansible selbst, gerade wenn es z.B. um spezielle Hardware für boblight usw. geht, die man bequemer in Betrieb nehmen kann, wenn man des Playbook die Arbeit machen lässt.

Ich habe bislang nur wenig Web-Entwicklung gemacht und bin noch dabei mich einzulesen, die Komponenten zusammen zu suchen und zu experimentieren, was möglich ist und vom Aufwand her Sinn macht - wenn da jemand mit mehr Erfahrung dabei ist, ist da natürlich deutlich mehr möglich als wenn ich das als Lernprojekt nutze, bei dem ich mir alles selbst erarbeiten muss.

Fürs Backend wird es vermutlich Python3 mit fastapi werden, weil eine REST-API, SSE und Websockets damit recht einfach umsetzbar sind und es automatisch eine OpenAPI-kompatible API-Beschreibung generieren kann. Und dann fehlt da noch ein Wrapper für ansible-runner, damit man Playbooks ausführen lassen kann und ein paar andere Helferlein, die benötigt werden, wenn man mit erhöhten Rechten Änderungen am System vornehmen will.

Bei den JS Frameworks gefällt mir VueJS (zusammen mit router.vuejs, vuex und axios) bislang recht gut und scheint leicht(gewichtig)er als Angular zu sein, aber ich bin da für alles offen, solange ich mich mit vertretbarem Aufwand einarbeiten kann.

Da ich in letzter Zeit selten dazu komme, mich da mal längere Zeit am Stück dran zu setzen, geht es da bislang nur recht langsam voran...

Ich verwende softhdvaapi und mir ist aufgefallen, dass nach dem letzten Update der TV weiß bleibt und der ton läuft. Das OSD wird dargestellt und funktioniert.

neue Version = vdr-plugin-softhdvaapi_3.1.0-0yavdr0~focal_amd64.deb
                libplacebo42_2.43.0+git20200424-8-e7b3606-0yavdr0~focal_amd64.deb
alte Version = vdr-plugin-softhdvaapi_3.0.1+git20200326-25-f756334-0yavdr0~focal_amd64.deb
                libplacebo29_1:1.29.1-1yavdr0~focal

Die alte Version kann unter /var/cache/apt/archives gefunden werden und kann mit dpkg -i installiert werden. Nachher funktioniert alles wie gewohnt.

Kann jemand das bestätigen? Da sind hier bestimmt mehrere User mit Intel GPU Ausgabe unterwegs.

da habe ich von seahawk1986 die Lösung bekommen dass gamma auf max zu setzen, das war nach dem Update auf min.

Danke für den Hinweis, wie und was in welcher Datei hast Du eingestellt?