Beta Container Images auf Basis von debian Bookworm

Begonnen von Sidey, 12 Januar 2025, 14:59:50

Vorheriges Thema - Nächstes Thema

Sidey

Hallo zusammen,

ich habe neue Container Images für fhem und alexa-fhem auf Basis von Debian 12 (Bookworm) erstellt.

Bei dem FHEM Image ist die wesentliche mir bekannte Änderung, dass die Android debug bridge nicht mehr installiert ist.

Beim dem Alexa Image, waren einige Anpassung der ssh Konfiguration notwendig. Diese wird beim Starten des Images geprüft und gepatcht.


Das Alexa-fhem image

ghcr.io/fhem/alexa-fhem:5.1.0-beta6

Die FHEM images:
ghcr.io/fhem/fhem-minimal-docker:5.0.0-beta2-bookworm
ghcr.io/fhem/fhem-docker:5.0.0-beta2-bookworm

Die threaded FHEM images:
ghcr.io/fhem/fhem-minimal-docker:5.0.0-beta2-threaded-bookworm
ghcr.io/fhem/fhem-docker:5.0.0-beta2-threaded-bookworm

Ich habe zwar auch selbst schon ein wenig getestet, würde mich aber über weitere Rückmeldungen freuen bevor ich das als "stable" veröffentliche.

Viele Grüße
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

passibe

Super, danke!

Hab eben fhem-docker:5.0.0-beta2-bookworm und das alexa-fhem-Image geladen und darauf aktualisiert. Bis jetzt funktioniert alles ohne Probleme (mache aber auch nichts exotisches).

Melde mich die Tage nochmal, ob mir was aufgefallen ist.

rallye

Danke! Ich hab mir das mal auf mein System geladen und lasse es erstmal vor sich hinlaufen. Bin jetzt 2 Wochen auf Urlaub - mal sehen ob hier daheim die Katastrophe ausbricht. Wenn mir etwas auffällt melde ich mich

LG Rallye
RaspiPi v4, HM-LGW, 6x HM-TC-IT-WM-W-EU, 11x HM-CC-RT-DN, 1x HUE Bridge, 4x HUE-RC, 5x HUE White&Color, 15xHUE White, 3xHM-LC-SW1-FM, 1xHM-LC-SW2-FM, 1x ConBeeII, 15x Shelly1, 5xShellyplug, Aquara: 2x Temp-Sensor, 1x Vibrationssensor, 2x Lichtsensor, 19x Tür/Fenstersensor

passibe

Bis jetzt ist alles stabil.
Einzig bei alexa-fhem musste ich, weil ich per curl einen healthcheck (mit https) ausführe, /etc/ssl/certs/ca-certificates.crt vom Host in den Container mappen, aber damit kann ich gut leben.

Was mir wegen diesem Thread noch aufgefallen ist: Kann es sein, dass in Version 5 standardmäßig kein npm mehr im Container ist? "find / -type f -name 'npm'" liefert auch nichts zurück.
Ist das Absicht oder ist da was schiefgelaufen?

rallye

Alexa-fhem läuft bis jetzt stabil. Leider musste ich mit FHEM wieder zurück, da fhempy sich einfach nicht starten ließ
defmod fhempy_local BindingsIo fhempy
attr fhempy_local devStateIcon {      my $attr_ver = "1.1.0";;;;      my $status_img = "10px-kreis-gruen";;;;      my $status_txt = "connected";;;;      my $ver = ReadingsVal($name, "version", "-");;;;      my $ver_available = ReadingsVal($name, "version_available", $ver);;;;      my $update_icon = "";;;;      my $refresh_img = "refresh";;;;      my $refresh_txt = "Update fhempy";;;;      if ($ver_available ne $ver) {        $refresh_img = "refresh\@orange";;;;        $refresh_txt = "Version ".$ver_available." available for update";;;;      }      if (ReadingsVal($name, "state", "disconnected") eq "disconnected") {        $status_img = "10px-kreis-rot";;;;        $status_txt = "disconnected";;;;      }      $update_icon = "<a  href=\"/fhem?cmd.dummy=set $name update&XHR=1\" title=\"Start ".$ver_available." update\">".FW_makeImage($refresh_img, $refresh_txt)."</a>";;;;      my $restart_icon = "<a  href=\"/fhem?cmd.dummy=set $name restart&XHR=1\" title=\"Restart fhempy\">".FW_makeImage("control_reboot")."</a>";;;;      "<div><a>".FW_makeImage($status_img, $status_txt)."</a><a> ".$ver." </a>".$update_icon.$restart_icon."</div>"    }
attr fhempy_local group fhempy
attr fhempy_local icon file_json-ld2
attr fhempy_local room HW & Gateways


setstate fhempy_local opened
setstate fhempy_local 2025-01-13 18:23:44 hostname 7b78120694a2
setstate fhempy_local 2025-01-13 18:23:44 os posix
setstate fhempy_local 2025-01-13 18:23:44 python 3.9.2
setstate fhempy_local 2025-01-13 18:23:44 release 6.6.62+rpt-rpi-2712
setstate fhempy_local 2025-01-13 18:23:44 state opened
setstate fhempy_local 2025-01-13 18:23:44 system Linux
setstate fhempy_local 2025-01-13 18:23:44 version 0.1.745
setstate fhempy_local 2025-01-13 18:23:45 version_available 0.1.745
setstate fhempy_local 2025-01-13 18:23:45 version_release_notes <html><a href="https://github.com/fhempy/fhempy/releases" target="_blank">Release Notes</a></html>

Im FHEM-Log war repeatedly zu lesen:
2025.01.13 18:11:59 3: fhempyserver_15733: starting
2025.01.13 18:11:59 3: fhempyserver_15733: using logfile: ./log/fhempy-2025-01-13.log
2025.01.13 18:12:59 3: fhempyserver_15733: read: end of file reached while sysread
2025.01.13 18:12:59 3: fhempyserver_15733: stopped
2025.01.13 18:13:19 3: fhempyserver_15733: starting
2025.01.13 18:13:19 3: fhempyserver_15733: using logfile: ./log/fhempy-2025-01-13.log
2025.01.13 18:14:19 3: fhempyserver_15733: read: end of file reached while sysread
2025.01.13 18:14:19 3: fhempyserver_15733: stopped
2025.01.13 18:14:39 3: fhempyserver_15733: starting
2025.01.13 18:14:39 3: fhempyserver_15733: using logfile: ./log/fhempy-2025-01-13.log
2025.01.13 18:15:39 3: fhempyserver_15733: read: end of file reached while sysread
2025.01.13 18:15:39 3: fhempyserver_15733: stopped
2025.01.13 18:15:59 3: fhempyserver_15733: starting
2025.01.13 18:15:59 3: fhempyserver_15733: using logfile: ./log/fhempy-2025-01-13.log

Das Logfile zeigt wiederholt zu den o.a. Timestamps:
2025-01-13 18:10:39,550 - ERROR    - __main__: Failed to install fhempy, exit now...
Running within a Docker container.
2025-01-13 18:11:59,091 - ERROR    - __main__: Failed to load fhempy
Traceback (most recent call last):
  File "/opt/fhem/FHEM/bindings/python/bin/start_fhempy.py", line 141, in <module>
    import fhempy.lib.fhem_pythonbinding as fpb
ModuleNotFoundError: No module named 'fhempy'
2025-01-13 18:11:59,094 - INFO     - __main__: Attempting install of fhempy>=0.1.462
2025-01-13 18:11:59,519 - ERROR    - __main__: Unable to install package fhempy>=0.1.462: error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.

    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.

    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.

    See /usr/share/doc/python3.11/README.venv for more information.


Da ich FHEMPY unbedingt für mein FusionSolar und Tuya benötige bin ich mit FHEM. wieder zurück auf bullseye
RaspiPi v4, HM-LGW, 6x HM-TC-IT-WM-W-EU, 11x HM-CC-RT-DN, 1x HUE Bridge, 4x HUE-RC, 5x HUE White&Color, 15xHUE White, 3xHM-LC-SW1-FM, 1xHM-LC-SW2-FM, 1x ConBeeII, 15x Shelly1, 5xShellyplug, Aquara: 2x Temp-Sensor, 1x Vibrationssensor, 2x Lichtsensor, 19x Tür/Fenstersensor

passibe

Eigentlich gehört fhempy in einen separaten Container, siehe https://github.com/fhem/fhempy-docker

z.B. für googlecast nutze ich:
  fhempy-gcast:
    image: ghcr.io/fhem/fhempy-docker_googlecast:latest
    container_name: fhempy_gcast
    restart: unless-stopped
    networks:
      - fhem-net

Und dann in fhem einfach mit dem docker-(host)namen ansprechen:
defmod fhempy_gcast BindingsIo fhempy_gcast:15733 fhempy

rallye

#6
So ähnlich habe ich es in meiner Produktionsumgebung auch. Ich habe mich lediglich an diese Anleitung gehalten.

Ich habe das Ganze nun auf meinem Testsystem nochmals nachvollzogen. Eine nagelneue Installation (System & FHEM + ausschließlich die FHEMpy-Definitionen). So wie ICH das (in meinem Produktionssystem) definiert habe, habe ich unter Bookworm den gestern beschriebenen Fehler.
Auch deine Anleitung habe ich mit einem jungfräulichen System implementiert - fehlerfrei (lediglich den Update von fhempy 0.1.742 -> 0.1.745 hat er mit "Connection refused" abgelehnt - auch in meiner Testumgebung)

Nachtrag: ich habe am Testsystem DEINE Methode verwendet und keine Probleme feststellen können - damit läuft die von @Sidey bereitgestellte Beta-Version auch bei mir soweit einwandfrei.

GLG Rallye
RaspiPi v4, HM-LGW, 6x HM-TC-IT-WM-W-EU, 11x HM-CC-RT-DN, 1x HUE Bridge, 4x HUE-RC, 5x HUE White&Color, 15xHUE White, 3xHM-LC-SW1-FM, 1xHM-LC-SW2-FM, 1x ConBeeII, 15x Shelly1, 5xShellyplug, Aquara: 2x Temp-Sensor, 1x Vibrationssensor, 2x Lichtsensor, 19x Tür/Fenstersensor

passibe

#7
Zitat von: rallye am 14 Januar 2025, 14:24:15define fhempy_local BindingsIo fhempy
Das nicht machen!

Du brauchst (in deinem Fall) 3 BindingsIo-Devices (jeweils für FusionSolar, Google Weather und Tuya). Jedes dieser BindingsIo-Devices kommuniziert dann mit seinem eigenen Fhempy-Docker-Container, der das jeweilige fhempy-modul bereitstellt.

Also:
defmod fhempy_fusionsolar BindingsIo fhempy-fusionsolar:15733 fhempy
defmod fhempy_googleweather BindingsIo fhempy-googleweather:15733 fhempy
defmod fhempy_tuya BindingsIo fhempy-tuya:15733 fhempy

Die Zuweisung des IODevices so wie hier
Zitat von: rallye am 14 Januar 2025, 14:24:15attr Irenetal_weather IODev fhempy_local
musst du dann je nach dem welches Modul du konkret brauchst auf das entsprechende BindingsIo-Device ändern.

So z.B. für dein Wetter-Device (das dann logischerweise das fhempy_googleweather IODev braucht):
defmod Irenetal_weather fhempy google_weather Irenental
attr Irenetal_weather IODev fhempy_googleweather

So weit ...
Zitat von: rallye am 14 Januar 2025, 14:24:15habe ich unter Bookworm den gestern beschriebenen Fehler.
... sollte es gar nicht kommen, denn es sollte überhaupt gar nicht versucht werden, im FHEM-Container fhempy oder irgendwelche fhempy-Module zu installieren. Denn das alles ist ja (pro Modul) ausgelagert in die jeweiligen Docker-Container.

Insofern vereinfacht Docker das ganz ungemein, denn man muss nur noch den jeweiligen Container starten und dem BindingsIo-Device sagen, unter welchem Hostnamen der Container läuft. Dann noch allen Geräten sagen, sie sollen das BindingsIo-Device nutzen – fertig. Man muss eben nichts mehr manuell oder semi-automatisch installieren oder updaten usw., weil das alles über die separaten Container stattfindet.

Hilft das?

rallye

Ja, danke, das hilft und so habe ich es auch gemacht. Leider habe ich meinen vorigen Post (während du geantwortet hast) bereits updated und die "bösen" Statements gelöscht. So wie du das beschreibst funktioniert es einwandfrei!
Danke

GLG Rallye
RaspiPi v4, HM-LGW, 6x HM-TC-IT-WM-W-EU, 11x HM-CC-RT-DN, 1x HUE Bridge, 4x HUE-RC, 5x HUE White&Color, 15xHUE White, 3xHM-LC-SW1-FM, 1xHM-LC-SW2-FM, 1x ConBeeII, 15x Shelly1, 5xShellyplug, Aquara: 2x Temp-Sensor, 1x Vibrationssensor, 2x Lichtsensor, 19x Tür/Fenstersensor

CoolTux

Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Sidey

Zitat von: passibe am 13 Januar 2025, 12:58:00Einzig bei alexa-fhem musste ich, weil ich per curl einen healthcheck (mit https) ausführe, /etc/ssl/certs/ca-certificates.crt vom Host in den Container mappen, aber damit kann ich gut leben.

Zur Info: Der Container führt auch selbst einen healthcheck aus.

Zitat von: passibe am 13 Januar 2025, 12:58:00Was mir wegen diesem Thread noch aufgefallen ist: Kann es sein, dass in Version 5 standardmäßig kein npm mehr im Container ist? "find / -type f -name 'npm'" liefert auch nichts zurück.
Ist das Absicht oder ist da was schiefgelaufen?

Also Absicht war das direkt nicht, ich hab mal eben geschaut, wenn ich npm wieder mit aufnehme, 400 MB Zusätzlicher Speicherplatz :)

Was ist denn der Anwendungsfall überhaupt node Programme in dem FHEM Container laufen zu lassen?


Grüße Sidey

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

passibe

Zitat von: Sidey am 22 Januar 2025, 20:14:11Der Container führt auch selbst einen healthcheck aus.
Ja, ich weiß – vielleicht muss ich das alles mal umstellen, dass irgendwie der Docker daemon abgefragt wird, ob die Container noch healthy sind und das dann an Uptime Kuma melden, aber noch finde ich es so ganz elegant.

Zitat von: Sidey am 22 Januar 2025, 20:14:11Was ist denn der Anwendungsfall überhaupt node Programme in dem FHEM Container laufen zu lassen?
Ich persönlich habe keinen, könnte also gut darauf verzichten. Aber (mindestens) das echodevice-Modul braucht das.
Einmal zur ursprünglichen Installation des alexa-cookie2-Moduls, aber selbst wenn das Modul schon installiert ist, prüft 37_echodevice.pm bei jedem Login-Vorgang (egal ob neu oder refresh) nochmal, ob npm überhaupt installiert ist und bricht sonst mit einer Fehlermeldung ab.

Siehe ab Zeile 4949 bzw. 5205:
    # Prüfen ob node installiert ist
    if (!(-e $npm_bin_node)) {
        $InstallResult .= '<p>Das Bin <strong>' . $npm_bin_node . '</strong> wurde nicht gefunden. Bitte zuerst das Linux Paket NPM installieren. Folgenden Befehl koennt Ihr hier verwenden:</p>';
        $InstallResult .= '<p><strong><font color="blue">sudo apt-get install npm</font></strong></p><br>';
        $InstallResult .= '<p>Sollte das Linux Paket NPM schon installiert sein, muesst Ihr ggf. das Attribut "<strong>npm_bin_node</strong>" entsprechend anpassen. Standard=/usr/bin/node</p>';
        $InstallResult .= '<br><form><input type="button" value="Zur&uuml;ck" onClick="history.go(-1);return true;"></form>';
        $InstallResult .= "</html>";
        $InstallResult =~ s/'/&#x0027/g;
        Log3 $name, 3, "[$name] [echodevice_NPMLoginNew] " . $npm_bin_node . " not found" ;
        return $InstallResult;
    }

Vielleicht bietet es sich ja an, ein extra Image à la 5-bookworm-npm anzubieten? Wobei das wahrscheinlich nur dafür unverhältnismäßig viel Aufwand ist ...

Sidey

Hmm, ich hatte noch mal kurz überlegt, ob alexa-cookie installieren und dann ohne npm weiter arbeiten eine Option wäre....

Aber dann müsste ich wohl ein Script mit dem Namen npm ablegen..
Alles unschön und das nur um an ein Token zu kommen.
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

passibe

Zitat von: Sidey am 22 Januar 2025, 21:59:27Hmm, ich hatte noch mal kurz überlegt, ob alexa-cookie installieren und dann ohne npm weiter arbeiten eine Option wäre....
Das wäre sicherlich nicht verkehrt. Im Endeffekt geht es ja nur um zwei .js-Dateien (alexa-cookie.js und lib/proxy.js) und die package.json.

Zitat von: Sidey am 22 Januar 2025, 21:59:27Aber dann müsste ich wohl ein Script mit dem Namen npm ablegen..
Oder man patcht 37_echodevice.pm entsprechend, dass in einer Docker-Umgebung eben nicht mehr überprüft wird, ob es npm gibt? Ob alexa-cookie2 installiert ist, wird, wenn ich mich nicht täusche, sowieso danach nochmal gesondert geprüft.

Sidey

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem,zigbee2mqtt

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker