Offizielles FHEM Docker Basis Image für verschiedene Plattformen

[Master_Nick]

Guter Hinweis - teste ich mal.

Vorschlag:

In der README.md erscheinen mir einige Themensprünge (mach ich auch sehr gern) - dadurch steht die Info mit keinem Passwort für Telnet unter Config DB und nicht unter Telnet oder Healthcheck
Daher hatte ich es nicht so wirklich gefunden - geb ich zu.

Hätte es in der Sektion "Change FHEM local Telnet port" eingeordnet
Oder ggf einfach nochmal nen Hinweis dort fallen lassen.

Logisch der, der immer alles ließt bei dem ist das egal :-D
Aber gerade bei Konfigurationsmöglichkeiten such man ja dann doch ab und an speziell etwas.

[Master_Nick]

Code Auswählen Erweitern

Telnet(7072): OK; WEB(8083): OK; WEB2(8086): OK; WEBphone(8084): OK; WEBtablet(8085): OK; DockerImageInfo:undefined;

Perfekt Danke

Ich schau dann nochmmal nach dem DockerImageInfo :-D

Anscheinend wird, obwohl ich es hier im Thread anders gelesen habe DockerImageInfo nicht angelegt beim start des Containers.
So habe ich es zumindest verstanden, dass es so gedacht ist.

Code Auswählen Erweitern

configDB: Please define DockerImageInfo first
Please define DockerImageInfo first
Please define DockerImageInfo first
Please define DockerImageInfo first
weiter Wiederholungen des selbigen...

Habe mir nun einfach mit "define DockerImageInfo DockerImageInfo" selber geholfen.

Unter Docker Image Info sind alle verfügbaren Capabilitiesgelistet - möchte der Container die gerne haben?
Ich frage, weil man unter Kubernetes mit Rancher diese selber zuteilen muss und sie nicht einfach gewährt werden wenn das Image es ansagt.

[Migul47]

Dann fahr doch erstmal alles aufs aktuelle

So, alles aktuell. FHEM direkt ohne Container. Homebridge und mySQL im Container. Nur 2,5% CPU, Sauberer Takt. So hab ich das im Container nie gehabt. Denke, ich lass es jetzt so.

[PatrickR]

Mahlzeit!

Habe gerade meine zwei Container auf das offizielle Image portiert. Läuft soweit. Allerdings gibt es Probleme mit dem health-check:

Code Auswählen Erweitern


./health-check.sh
Telnet(7000): OK; WWW(8000): OK; WWW_FTUI(8001): OK; WWW_HOMEBRIDGE(8002): FAILED; DockerImageInfo:undefined;


Dass der health-check (korrekterweise) nicht auf WWW_HOMEBRIDGE zugreifen kann, führt nun dazu, dass der Container unhealthy ist. Ich sehe leider auf den ersten Blick keine Möglichkeit, dem health-check mitzuteilen, dass er einige (oder am besten alle) FHEMWEBs ignorieren soll, außer natürlich den Check zu patchen...

Patrick

[Loredo]

In der README.md erscheinen mir einige Themensprünge (mach ich auch sehr gern) - dadurch steht die Info mit keinem Passwort für Telnet unter Config DB und nicht unter Telnet oder Healthcheck
Daher hatte ich es nicht so wirklich gefunden - geb ich zu.

Hätte es in der Sektion "Change FHEM local Telnet port" eingeordnet
Oder ggf einfach nochmal nen Hinweis dort fallen lassen.

Das ist eigentlichn kein Themensprung, denn es ist vor allem für configDB Nutzer relevant, bei denen _keinerlei_ automatische Anpassungen möglich sind.
Und ich hatte bisher verstanden, dass du sehr wohl configDB nutzt. Ich selbst nutze das absichtlich überhaupt gar nicht und habe auch keine Erfahrungen damit, weshalb ich nicht vorausahnen kann, welche Schritte jemand mit configDB tatsächlich alles tun muss. Das ist die investigative Zuarbeit der Community, die ich hier erwarte - und die du ja nun fleißig erbringst
Sei herzlich eingeladen deine Erfahrungen in einem FHEM Wiki Beitrag zu verewigen, genau dafür ist es da 


Andere Nutzer ohne configDB sollten(!) davon profitieren, dass Anpassungen an der fhem.cfg automatisch vorgenommen werden, sofern sie für den Betrieb des Containers notwendig sind. Dazu gehört auch das erste(!) Telnet Device in der fhem.cfg auszulesen und auch zu schauen, ob es ein allowed Device dazu gibt und dieses anzupassen (theoretisch, ob das immer funktioniert, dafür fehlen die Erfahrungswerte - und deshalb sind wir ja hier).

Anscheinend wird, obwohl ich es hier im Thread anders gelesen habe DockerImageInfo nicht angelegt beim start des Containers.
So habe ich es zumindest verstanden, dass es so gedacht ist.

Ist es auch - aber für configDB User ist das eben nicht möglich (wie oben schon erwähnt). Du musst also auch hier selbst Hand anlegen, deshalb hast du dich ja für configDB entschieden 
Die da selbst zu helfen läuft also unter "works as designed".
Der Hinweis im Docker Start Protokoll weißt dich auch nochmals darauf hin, dass du alles selbst machen musst. Was genau das alles ist, das kann dir vorher keiner sagen, weil deine Konfiguration eben individuell ist und ich vor dem Start nicht in die Datenbank schauen kann (und will).

Unter Docker Image Info sind alle verfügbaren Capabilitiesgelistet - möchte der Container die gerne haben?
Ich frage, weil man unter Kubernetes mit Rancher diese selber zuteilen muss und sie nicht einfach gewährt werden wenn das Image es ansagt.

Wie der Name des Moduls schon sagt, ist es eine Info - also eine Info für dich und FHEM über den aktuellen Container Zustand und dessen Rechte, Betriebsart, etc.

Dass der health-check (korrekterweise) nicht auf WWW_HOMEBRIDGE zugreifen kann, führt nun dazu, dass der Container unhealthy ist. Ich sehe leider auf den ersten Blick keine Möglichkeit, dem health-check mitzuteilen, dass er einige (oder am besten alle) FHEMWEBs ignorieren soll, außer natürlich den Check zu patchen...

Für den Health Check ist es zwingend notwendig und auch sinnvoll, Zugriffe von lokal zuzulassen. Du musst dein allowed-Device für die FHEMWEB Instanz also so einstellen, dass man über localhost kein Passwort benötigt.

[der-Lolo]

Hat eigentlich einer der Docker Nutzer das can not fork / can not allocate memory problem..?

Ich würde gerne umsteigen wenn ich dieses problem hierdurch gelöst bekomme.
Hardware wäre eine Syno DS 716+i - hat diese kombination schon jemand am laufen..?

[PatrickR]

Hi!

Für den Health Check ist es zwingend notwendig und auch sinnvoll, Zugriffe von lokal zuzulassen. Du musst dein allowed-Device für die FHEMWEB Instanz also so einstellen, dass man über localhost kein Passwort benötigt.

Die Voraussetzungen des Skripts habe ich auch so verstanden. Meine Frage ging allerdings eher in die Richtung, wie man dieses Verhalten elegant bzw. robust anpassen kann.

Um ehrlich zu sein verstehe ich allerdings den informativen Mehrwert nicht, wenn drei FHEMWEB-Instanzen statt einer geprüft werden. Streng genommen sollte der Check über Telnet mehr als ausreichend sein, der tatsächlich sinnvoll ist.

Patrick

[Loredo]

Naja, weil es streng genommen darum geht jeden Dienst/Port zu prüfen und nicht implizit von der Funktion des einen auf die des anderen zu schließen.

[PatrickR]

Hi!

Naja, weil es streng genommen darum geht jeden Dienst/Port zu prüfen und nicht implizit von der Funktion des einen auf die des anderen zu schließen.

Das Problem ist, dass Du nur die Dienste prüfst, die üblicherweise in jeder FHEM-Instanz laufen, nicht jedoch jene, die tatsächlich wichtig sind (Telnet als genereller Indikator kann da eine Ausnahme sein). Die wirklich wichtigen Funktionalitäten sind aber individuell und vermutlich über keinen noch so durchdachte generische Logik ermittelbar.

Um mal in Richtung einer Lösung zu navigieren: Das Docker-Image glänzt ja durch eine unerschöpfliche Konfigurierbarkeit. Eine Lösung über die Skript-Hooks wie pre-start.sh wäre möglich, aber unschön. Wie wäre es, wenn Du die Zeile:

Code Auswählen Erweitern


FHEMWEB=$( cd /opt/fhem; perl fhem.pl ${TELNETPORT} "jsonlist2 TYPE=FHEMWEBOFF:FILTER=TEMPORARY!=1" 2>/dev/null )

durch

Code Auswählen Erweitern


FHEMWEB=$( cd /opt/fhem; perl fhem.pl ${TELNETPORT} "jsonlist2 TYPE=FHEMWEBOFF:FILTER=TEMPORARY!=1:FILTER=noHealthCheck!=1" 2>/dev/null )

ersetzen würdest?

Dann könnte man über ein userattr noHealthCheck die Instanz von der Prüfung ausnehmen.

Patrick

[Loredo]

Gute Idee, ich habe das mal testweise ins DEV Image aufgenommen.
In der README.me gibt es zwei neue Abschnitte zu diesen Themengebieten:


Role of the telnet device in FHEM
Docker health check control

[PatrickR]

Hi!

Gute Idee, ich habe das mal testweise ins DEV Image aufgenommen.

Hi! Sieht gut aus. Allerdings ist in DockerImageInfo noch der Wurm drin:

Code Auswählen Erweitern


2019.07.28 20:01:06.653 0: Missing $ on loop variable at ./FHEM/99_DockerImageInfo.pm line 14.


Patrick

[Loredo]

Danke, hab ich noch korrigiert und jetzt baut ein neues Prod Image.

[PatrickR]

Hi!

Danke, hab ich noch korrigiert und jetzt baut ein neues Prod Image.

Prima, DockerImageInfo läuft nun unter latest und dev. DockerHealthCheck funktioniert ebenfalls unter dev. Wenn ich es richtig gesehen habe, kümmert sich DockerImageInfo um das "Erlauben" des Attributs. Das klappt leider bei mir nicht. Über den Workaround mit einem userattr passt es aber.

Patrick

[Loredo]

Da das User Attribut beim hochfahren eines Demo Containers wie gewünscht erscheint, kann ich das leider nicht nachvollziehen.

[volschin]

Hat eigentlich einer der Docker Nutzer das can not fork / can not allocate memory problem..?

Ich würde gerne umsteigen wenn ich dieses problem hierdurch gelöst bekomme.
Hardware wäre eine Syno DS 716+i - hat diese kombination schon jemand am laufen..?

Ist denn der Docker ansonsten auf der Syno für Dich OK?
Da die Docker-Version immer noch auf 17.05 rumdümpelt, steht ja immer mehr in Frage, wie lange das noch gut geht. 
Es lassen sich z.B. viele neuere compose-Features nicht nutzen, da bei Level 2.2 Schluss ist.