Offizielles FHEM Docker Basis Image für verschiedene Plattformen

Begonnen von Loredo, 28 Juli 2018, 21:24:57

Vorheriges Thema - Nächstes Thema

wolfram

Danke @thotti70 - das war's!!!

Schönes Wochenende
wolf

Holzlenkrad

Wenn man das Device-Attribut nutzt, dann doch ohnehin nur einmal den Pfad zum Device angeben und nicht zwei mal mit Doppelpunkt getrennt oder?
Das könnte auch eine Fehlerquelle sein.

thotti70

Hallo nochmals,
ich greife mein Thema noch einmal auf.
Evtl. kann loredo mich im Zweifelsfall korrigieren.

Ich hatte beschrieben, dass ich zwei fhem container auf meinem system laufen lassen wollte.
Live und Test.
Ich hatte den Effekt, dass mein Live-fhem sich beendet hat, wenn ich das Testsystem ausgeschaltet habe.
Ursache bis dato unbekannt.

Jetzt meine Vermutung und erster Test scheint das zu bestätigen:
im Livesystem habe ich den Telnetport auf Standard 7072 belassen, im Testsystem auf einen anderen (da Netzwerk im hostmodus) um natürlich Dopplungen zu vermeiden.
Soweit ich das als Laie sehen kann, ist im Skript zum beenden des Containers der Port aber fest verdrahtet
su - fhem -c "cd "${FHEM_DIR}"; perl fhem.pl 7072 shutdown"
Für mich ergibt sich daraus: habe ich das Testsystem beendet, ging der shutdown Befehl aber an den Telnetport des Livesystems.

Lange Rede, kurzer Sinn, Port im Livesystem geändert und jetzt sieht es so aus, als wenn es nicht mehr gestoppt wird.
ABER: vermute jetzt erhält fhem natürlich nicht mehr den shutdown Befehl.
Oder?

Liege ich richtig und wenn ja, gibt es einen Workaround?

Hoffe es ist trotz später Stunde nachvollziehbar.

Gute Nacht


Loredo

Zitat von: kotaro am 26 April 2019, 14:56:12
Teste mal und teile mit ob es klappt. ich würde dann @Loredo bitten, vielleicht darauf hinzuweisen...


Kann da mal jemand eine vollständige Liste aller Möglichkeiten aufschreiben und auch alle Schritte Ende-zu-Ende, um dann ein Device einzubinden? Ich nehme das dann gerne mit in die README auf, kann das aber unmöglich alles selbst testen, da ich wie gesagt keine externen Geräte habe, die kein IP sprechen.


Zitat von: thotti70 am 27 April 2019, 02:12:29
Soweit ich das als Laie sehen kann, ist im Skript zum beenden des Containers der Port aber fest verdrahtet
su - fhem -c "cd "${FHEM_DIR}"; perl fhem.pl 7072 shutdown"
Für mich ergibt sich daraus: habe ich das Testsystem beendet, ging der shutdown Befehl aber an den Telnetport des Livesystems.


Sehr gutes Finding! Habe ich mal im DEV Image korrigiert, wird dann die Tage auch ins PROD Image wandern.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Loredo

Ich habe begonnen das DEV Image auf Debian Buster umzustellen. Es baut gerade und ist wohl in einer guten Stunde abrufbar.


Große Änderungen am FHEM Image selbst sind dabei nicht zu erwarten, dennoch ist der Unterbau natürlich aktueller und es ist nicht ausgeschlossen, dass dabei Probleme auftreten, auf die FHEM Entwickler in Modulen reagieren müssten.


Freiwillige Tester sind gern gesehen, da ich selbst das wie immer nur beschränkt alleine testen kann.
Sofern keine Schwierigkeiten erkennbar sind, kann Buster dann auch schon vor dem offiziellen Release als produktives Image verwendet werden, da die noch offenen Punkte für den Release von Buster mehrheitlich den Debian Installer betreffen, der bei Docker ohnehin keine Rolle spielt.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

kjmEjfu

Ich habe heute auch mal das Docker Image ausprobiert, funktioniert prinzipiell sehr gut (ein passendes, fertiges für Sonos wäre natürlich noch toll ;-).

Allerdings fällt mir folgendes auf:


Internals:
   FUUID      5cc42668-f33f-8030-8fd2-0c3143c6b507339c
   NAME       DockerImageInfo
   NR         318
   STATE      Initialized
   TYPE       DockerImageInfo
Attributes:
   room       10_System
 

   
So dürfte das eigentlich ja nicht aussehen. Also habe ich mal mein Telnetport und Allowed geprüft, die schauen so aus:
   

Internals:
   FUUID      5c446459-f33f-8030-e853-ecd6cef796ffe01d
   FVERSION   96_allowed.pm:0.190460/2019-03-27
   NAME       allowed_491726518426
   NR         100
   STATE      validFor:WEB,WEBhook,telnetPort
   TYPE       allowed
   validFor   WEB,WEBhook,telnetPort
   READINGS:
     2019-04-27 14:42:11   state           validFor:WEB,WEBhook,telnetPort
Attributes:
   basicAuth  SHA256:aaaaaaaaaaaa
   globalpassword SHA256:bbbbbbbbbbb
   validFor   WEB,WEBhook,telnetPort
 

   
   
   
Internals:
   CONNECTS   18
   DEF        7072 global
   FD         5
   FUUID      5c446454-f33f-8030-3cf3-a1ab21cde6695530
   FVERSION   98_telnet.pm:0.175290/2018-10-14
   NAME       telnetPort
   NR         3
   PORT       7072
   STATE      Initialized
   TYPE       telnet
   READINGS:
     2019-04-27 14:41:49   state           Initialized
Attributes:


was übersehe ich? Dachte eigentlich, es würde soweit zu den Vorgaben passen.
Migriere derzeit zu Home Assistant

Loredo

Telnet muss nicht global sein und braucht dann auch kein allowed.
Du hast aber bei allowed ein Passwort gesetzt, das funktioniert aber mit Docker nicht. Für diese Telnet Instanz darf es kein Passwort geben.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

kadettilac89

#322

Zitat von: Loredo am 27 April 2019, 13:59:29
Ich habe begonnen das DEV Image auf Debian Buster umzustellen. Es baut gerade und ist wohl in einer guten Stunde abrufbar.


.....


Freiwillige Tester sind gern gesehen, da ich selbst das wie immer nur beschränkt alleine testen kann.
...


Wie komme ich zum buster Image? Werde es testen.

edit: hat sich erledigt, du hast es ja geschrieben, DEV ... habe es mal geladen

kjmEjfu

Zitat von: Loredo am 27 April 2019, 15:11:32
Telnet muss nicht global sein und braucht dann auch kein allowed.
Du hast aber bei allowed ein Passwort gesetzt, das funktioniert aber mit Docker nicht. Für diese Telnet Instanz darf es kein Passwort geben.

Ah, dann lege ich mal eine zweite Telnet-Instanz auf einem anderen Port an und passe diese an. Ich brauche nämlich tatsächlich auch ein Telnet, welches ich von außen füttern kann.
Migriere derzeit zu Home Assistant

Holzlenkrad

Zitat von: Loredo am 27 April 2019, 13:59:29
Ich habe begonnen das DEV Image auf Debian Buster umzustellen. Es baut gerade und ist wohl in einer guten Stunde abrufbar.

Wie sieht denn das bzgl. des Ressourcen-Managements bzw. -sparsamkeit aus? Mein Host läuft unter Stretch und auch die anderen Container von mir basieren auf Stretch bzw. eher "latest".

Sooo viel RAM hat der Pi ja nun nicht...

Loredo

Zitat von: Holzlenkrad am 28 April 2019, 04:00:56
Wie sieht denn das bzgl. des Ressourcen-Managements bzw. -sparsamkeit aus? Mein Host läuft unter Stretch und auch die anderen Container von mir basieren auf Stretch bzw. eher "latest".

Sooo viel RAM hat der Pi ja nun nicht...


Am Arbeitsspeicher Verbrauch kannst du nur etwas ändern, wenn du weniger FHEM Module verwendest. Das hat nichts mit der Systemumgebung zu tun, es kommt auf die laufenden Anwendungsprozesse an und da gibt es nur fhem.pl und je nach verwendeter Module noch Kindprozesse wie homebridge, alexa-fhem, etc. ...
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

LuckyLuis

Hallo,

nach einem erfolgreichen Umzug meiner FHEM-Installation mit DBLog auf Docker habe ich derzeit ein kleines Problem (gehabt ;-): Leider ist im Docker-Image nicht die Localzone "de_DE.UTF-8" vorgeneriert. Dies führt in Zusammenarbeit mit MariaDB (auf UTF8 eingestellt) zu unerwünschten Effekten (Umlaute). Kann dies in das Image mit aufgenommen werden? Ich habe mir damit geholfen, dies im Container zu erstellen.

Vielen Dank für die tolle Arbeit, die meine Lebenszeit wieder etwas Freiraum für andere Dinge schafft :D!

LuckyLuis

Loredo

#327
Zitat von: Loredo am 27 April 2019, 13:59:29
Ich habe begonnen das DEV Image auf Debian Buster umzustellen. Es baut gerade und ist wohl in einer guten Stunde abrufbar.


Hier mal ein Zwischenstand:


Node.js:
Ich habe versucht Node.js 12 mit einzubauen, allerdings ist für gassistant-fhem eine Abhängigkeit da, für die es wohl (noch) kein vorkompiliertes NPM Modul gibt. Die Kompilierung endet mit einem etwas seltsamen Fehler, so dass die Images nun erstmal Node.js 10 enthalten, welches direkt in Buster enthalten ist. Ich schaue nochmal, ob man zumindest auf Node.js 10 von der Node.js Foundation gehen kann.


SSL Support:
Die Validierung von SSL Zertifikaten scheint in Buster an mehreren Stellen komplett kaputt zu sein. Das betrifft alle ARM 32-Bit Plattformen und sowohl curl als auch npm können deshalb keine Verbindung zu Webservern herstellen, während wget komischerweise funktioniert. Für curl gibt es bereits einen Bugreport bei Debian, aber eher unspezifisch. Bugreports sind sehr umständlich bei Debian, daher habe ich selbst noch keinen erstellt.


Aufgrund des SSL Findings wird es so schnell also erstmal kein Buster geben. Ich überlege mal, ob ich das DEV Image so belasse oder es wieder auf Debian Stretch zurückstufe.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

wolfram

Hallo zusammen,

ich muss noch einmal nachfragen: Nach jedem Neustart des Containers bekomme ich, wie @thotti70 beschrieben hat in der global von fhem den Eintrag:

DNS Server: nameserver     8.8.8.8

eingetragen, was zu Problemen mit UDP aus FHEM heraus führt. Ändere ich den Eintrag auf "8.8.8.8" (ohne das Wort "nameserver"), funkioniert alles bestens.
Ich bin also auf die Suche gegangen und scheinbar ist es so, dass der Eintrag aus der "resolve.conf" beim Start gezogen wird. Eigentlich sollte dort doch dann nur die IP-Adresse in die fhem.conf übergeben werden und nicht die ganze Zeile, was zu den genannten Problem führt.

Wie kann ich das verhindern? Das Wort "nameserver" aus der resolve.conf herausnehmen, ist glaube ich ne schlechte Idee?  8)

Hat jemand einen Tipp für mich?

Viele Grüße und einen schönen Sonntag

wolf

Loredo

Zitat von: wolfram am 28 April 2019, 15:33:00
Hat jemand einen Tipp für mich?


Aus irgendeinem Grund ist in deiner resolv.conf statt Leerzeichen ein Tab als Trennzeichen verwendet. Ich schaue mal, dass ich das im nächsten Update berücksichtige.
Derweil kannst du aber auch per Docker Environment Variable "DNS=8.8.8.8" explizit nachhelfen. Mich wundert aber, dass du offenbar keinen lokalen DNS Server hast, sondern deinen Docker Server so eingestellt hast, die Datenkrake direkt zu fragen.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER