Offizielles FHEM Docker Basis Image für verschiedene Plattformen

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

Vorheriges Thema - Nächstes Thema

vbs

Schön hier mal eine ordentliche Nutzung von Git(Hub) zu sehen. Halte ich aus vielen Gründen für wesentlich besser als die Patchfile-Posterei übers Forum.  :)

Wernieman

Es ging mir nicht um den Speicherverbrauch, sondern mehr Software-Produkte = mehr Problemquellen

Eigentlich sollte es eine Light-Container geben, der bei den "Großcontainern" in der Docker-Compose reverenziert wird .... also "Verschachteltes" Bauen, wie es in der Regel gemacht wird.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Loredo

#227
Ich sehe bei einem Paket, was dann nicht benutzt wird, keine größere Problemquelle. Es wird ja nichts selbst kompiliert (und selbst dann sind die Komponenten voneinander unabhängig).
Welche Probleme hast du denn konkret beobachtet?
Das einzige, was ich sehe ist, dass Leute Probleme damit haben, dass ihnen Komponenten fehlen, von denen sie nicht wissen, dass sie benötigt werden. Oder mit Tools, die die Komponenten installieren, nicht in geeigneter Weise umgehen, damit die Installation auch richtig ist. Das alles macht die Docker Umgebung so, dass alles funktioniert. Sie schafft aber IMHO keine neuen Problemquellen.

Was jedoch neue Problemquellen schafft, ist die höhere Maintenance von mehreren aufeinander aufbauenden Docker Paketen. Das kann man so machen und ich hatte ja auch schonmal angedeutet, dass es möglicherweise auch mal ein "light" Image geben könnte. Der Aufwand die Continuous Integration Umgebung daraufhin umzubauen ist aber nicht unerheblich und ich sehe für mein Vorhaben da absolut keinen Mehrwert, sondern nur Mehraufwand, den ich derzeit lieber in den FHEM Installer bzw. der Schaffung der richtigen Voraussetzungen für diesen stecke. Erst dann macht ein Light Image wirklich Sinn, bei dem man dann über den Installer selektiv einzelne Pakete nachinstallieren kann und diese dann auch automatisch wieder installiert werden, wenn man den Container neu erstellt.


Und wie gesagt: Wenn du meine Einschätzung nicht teilst oder nicht bereit bist dem vorgefertigten Image ein Stückweit Vertrauen entgegen zu bringen, dann kannst du doch auch deine eigene Dockerfile Datei schreiben und so gestalten, wie du sie brauchst? Dann weißt du auch garantiert, was drin ist. Du kannst nicht beides haben: 100% eigene Kontrolle _und_ alles vorgefertigt - du musst dich entscheiden.
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

Zitat von: Loredo am 04 März 2019, 12:06:34

Ich habe das mal uminterpretiert und ein erweitertes Dockerfile ins DEV Image eingecheckt:
https://github.com/fhem/fhem-docker/commit/7558a19e55c405c301c52754e222811fdd51a6fe


Außerdem kann man jetzt auch beim Containerstart über die selben Variablennamen die Installation ad-hoc mit einbauen:
https://github.com/fhem/fhem-docker/commit/8f9778754d6ef060957aa6f1c77665ce945e0b32
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

beddo


Zitat von: vbs am 01 März 2019, 15:13:42
Dieser VOC-Stick ist leider kein serielles Device und taucht deshalb nicht unter /dev/serial auf :(

T:  Bus=02 Lev=02 Prnt=03 Port=01 Cnt=02 Dev#=  9 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=32 #Cfgs=  1
P:  Vendor=03eb ProdID=2013 Rev=10.00
S:  Manufacturer=AppliedSensor
S:  Product=iAQ Stick
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbfs


Driver ist "usbfs".


Hallo vbs,

Hab das bei mir so gelöst:
Der Stick meldet sich mit lsusb bei mir so: "Bus 001 Device 004: ID 03eb:2013 Atmel Corp."
Dies ist auch nach einem Neustart des PIs so, oder wenn ich den Stick an einen frisch installierten Pi anstecke.

Auf einem neuen System folgendes in /etc/udev/rules.d/99-usb.rules einfügen (sonst läuft der Stick bei mir nicht)
[SUBSYSTEM=="usb", ATTR{idVendor}=="03eb", ATTR{idProduct}=="2013", MODE="0666" ```] 
dann reboot.


Da der Stick ja immer die gleiche Device ID hat, binde ich das in meiner docker-compose.yml so ein
devices:
            - "/dev/bus/usb/001/004:/dev/bus/usb/001/004"

Läuft einwandfrei bei mir.
Hoffe das hilft Dir weiter.


beddo

Hallo Zusammen,
hab mir heute das neue Dockerimage gezogen.
Seither spinnt mein fhem
1. ewig lange Startzeiten ~ rund 5 min
2. bei update kommt nur folgende Fehlermeldung:

https://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(1) to https://fhem.de:443: IO::Socket::INET: Bad hostname 'fhem.de:443'

Hat noch wer das gleiche Problem?

vbs

Hi beddo,
Zitat von: beddo am 05 März 2019, 11:46:08
Der Stick meldet sich mit lsusb bei mir so: "Bus 001 Device 004: ID 03eb:2013 Atmel Corp."
das Problem bei mir ist, dass die Device-ID nicht stabil ist. Mindestens bei jedem Reconnect wird hochgezählt. Bin momentan bei 38 39: :o
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 039: ID 03eb:2013 Atmel Corp.

patlabor

Zitat von: beddo am 10 März 2019, 16:49:30
Hallo Zusammen,
hab mir heute das neue Dockerimage gezogen.
Seither spinnt mein fhem
1. ewig lange Startzeiten ~ rund 5 min
2. bei update kommt nur folgende Fehlermeldung:

https://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(1) to https://fhem.de:443: IO::Socket::INET: Bad hostname 'fhem.de:443'

Hat noch wer das gleiche Problem?

Habe zwar nicht das gleiche Problem, habe aber seit einem Update heute morgen auch Probleme.
Mit latest geht leider gar nichts mehr, habe jetzt auf dev umgestellt, und jetzt bekomme ich das Log hiermit vollgespammt:
2019.03.10 19:20:39.128 1: ERROR evaluating { DockerImageInfo_GetImageInfo(); }: Undefined subroutine &main::DockerImageInfo_GetImageInfo called at (eval 35411) line 1.

beddo

"...Bad hostname 'fhem.de..." klang für mich nach einem DNS Problem. War aber nur fhem. Handy&Desktop usw. im gleichen Netz hatten keine DNS Probleme.
Hab das Image gerade nochmal neu gezogen.
Nun läuft wieder alles.

Loredo

Zitat von: beddo am 10 März 2019, 21:36:25
"...Bad hostname 'fhem.de..." klang für mich nach einem DNS Problem. War aber nur fhem. Handy&Desktop usw. im gleichen Netz hatten keine DNS Probleme.
Hab das Image gerade nochmal neu gezogen.
Nun läuft wieder alles.


Genau. Wenn dein DNS nicht erreichbar ist, blockiert FHEM. Das kann man mildern, indem man das globale Attribut dnsServer setzt. Das Startup Script aktualisiert das Attribut automatisch auf den Docker internen DNS Server (genauer den ersten DNS aus resolv.conf, den die Docker Engine aber in der Regel setzt), wenn es gesetzt ist.


Zitat von: patlabor am 10 März 2019, 19:29:47
Habe zwar nicht das gleiche Problem, habe aber seit einem Update heute morgen auch Probleme.
Mit latest geht leider gar nichts mehr, habe jetzt auf dev umgestellt, und jetzt bekomme ich das Log hiermit vollgespammt:
2019.03.10 19:20:39.128 1: ERROR evaluating { DockerImageInfo_GetImageInfo(); }: Undefined subroutine &main::DockerImageInfo_GetImageInfo called at (eval 35411) line 1.


Ich kann mit einem blank hochgefahrenen Container ohne bestehende FHEM Installation keinen Fehler feststellen.
Der Fehler liest sich als wenn du 99_DockerImageInfo.pm aus deiner FHEM Installation gelöscht hast. Das Modul wird jedoch vom Container angesprochen und daher benötigt. Du kannst zwar, wenn du willst, das DockerImageInfo Device in FHEM selbst löschen, aber die Moduldatei muss bleiben und würde auch bei einem neu erstellten Container wieder ins FHEM Verzeichnis kopiert.
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

ulli

Ich habe mit dem Wakeonlan Module das Problem das es ohne Probleme ausgeführt wird aber scheinbar  aus dem docker Container nicht raus kommt.
Habt ihr eine Idee woran das liegt?

kadettilac89

#236
Zitat von: ulli am 11 März 2019, 18:01:33
Ich habe mit dem Wakeonlan Module das Problem das es ohne Probleme ausgeführt wird aber scheinbar  aus dem docker Container nicht raus kommt.
Habt ihr eine Idee woran das liegt?

liegt wahrscheinlich daran, dass fhem (der User) kein rootrechte hat, wol aber etherwake nutzt. Ich rufe per SSH etherwake vom host, der user fhemusr existiert im HOst und hat sudo für etherwake ...

kurzfristig ....

Änderung in 98_WOL.pm Zeile 309 ... Voraussetzung SSH-Call vom Docker zum HOst mit Key und WOL-Modul "exclude from update"


  if (-e $sysWake) {
     $sysCmd =~ s/\$mac/$mac/;
     $sysCmd =~ s/\$sysInterface/$sysInterface/;
     Log3 $hash, 4, "[$name] executing $sysCmd";
     #qx (sudo $sysCmd);
qx (ssh fhemuser\@192.168.0.25 -p 444 -o StrictHostKeyChecking=no    "sudo $sysCmd -i wlan0")
  } else {
     Log3 $hash, 1, "[$hash->{NAME}] system command '$sysWake' not found";
  }


ggf. etherwake in sudo des containers zur langfristigen lösung.

Edit: wenn docker fhem im host-modul läuft müsste es jetzt schon gehen, wenn es bridged ist werden die magic packages nicht durchgelassen. Stichwort magic packet bridge, subnet ... sowas. Broadcasts werden nicht oder nicht immer weitergeleitet. Eine Netzwerksache, nicht unbedingt Docker.

patlabor

#237
Zitat von: Loredo am 10 März 2019, 23:04:10

Ich kann mit einem blank hochgefahrenen Container ohne bestehende FHEM Installation keinen Fehler feststellen.
Der Fehler liest sich als wenn du 99_DockerImageInfo.pm aus deiner FHEM Installation gelöscht hast. Das Modul wird jedoch vom Container angesprochen und daher benötigt. Du kannst zwar, wenn du willst, das DockerImageInfo Device in FHEM selbst löschen, aber die Moduldatei muss bleiben und würde auch bei einem neu erstellten Container wieder ins FHEM Verzeichnis kopiert.

Hallo nochmal,

habe jetzt versuchsweise nochmal das Image gezogen, leider immernoch die gleiche Fehlermeldung. Genaugenommen steht das hier im Log:

2019.03.13 10:49:36.016 1: Including fhem.cfg
2019.03.13 10:49:36.061 1: reload: Error:Modul 99_DockerImageInfo deactivated:
Can't locate FHEM/Meta.pm in @INC (you may need to install the FHEM::Meta module) (@INC contains: . /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/arm-linux-gnueabihf/perl5/5.24 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base ./FHEM) at ./FHEM/99_DockerImageInfo.pm line 7, <$fh> line 11.
BEGIN failed--compilation aborted at ./FHEM/99_DockerImageInfo.pm line 7, <$fh> line 11.


Entfernt habe ich eigentlich gar nichts, weder in der config noch in Image. Am Sonntag morgen hat watchtower das neuste Image gezogen, seit dem habe ich dieses Problem.

Loredo

Aber hast du auch dein FHEM auf dem aktuellsten Stand? Dort kommt Meta.pm nämlich erst mit.
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

patlabor

Jetzt bin ich etwas verwirrt.
Ich habe Docker immer so verstanden, das ich eine gekapselte Umgebung unabhängig von meinem OS habe in der alles drin ist was der entsprechende Dienst braucht um zu funktionieren.
Sprich ich brauche mir keine Gedanken und die verschieden Abhängigkeiten und Versionen zu machen: Im Image ist alles drin was ich brauche.

Habe fhem im Container jetzt mal geupdated, und jetzt geht es auch wieder.

Solle aber in einem aktuellen Image auch nicht gleich die passende Version von fhem installiert sein?
Habe ich da irgendwas bezgl. Docker falsch verstanden?