Offizielles FHEM Docker Basis Image für verschiedene Plattformen

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

Vorheriges Thema - Nächstes Thema

desmoloch

Also irgendwie klappt das mit Pyhton3 und dem Inline::Python nicht so richtig
Ich bekomme bei GOOGLECAST immer folgenden Fehler:
2019.12.08 13:15:03 1: reload: Error:Modul 98_GOOGLECAST deactivated:
Error -- py_eval raised an exception at /usr/lib/x86_64-linux-gnu/perl5/5.28/Inline/Python.pm line 177.
BEGIN failed--compilation aborted at ./FHEM/98_GOOGLECAST.pm line 699.

2019.12.08 13:15:03 0: Error -- py_eval raised an exception at /usr/lib/x86_64-linux-gnu/perl5/5.28/Inline/Python.pm line 177.
BEGIN failed--compilation aborted at ./FHEM/98_GOOGLECAST.pm line 699.

Traceback (most recent call last):
  File "<string>", line 3, in <module>
ImportError: No module named pychromecast


mein Inline Pyhthon ist eigentlich gesetzt:
INLINE_PYTHON_EXECUTABLE=/usr/bin/python3 cpanm Inlin
e::Python


Was mache ich noch falsch?!

persching

Zitat von: OdfFhem am 06 Dezember 2019, 15:49:10
Bei update all würde die Meldung nothing to do... jeweils pro Repository ausgegeben.

update list liefert die Liste aller Repositories.

Ob ich update oder update all eintippe macht in der Ausgabe keinen Unterschied.

OdfFhem

@persching

update list

https://fhem.de/fhemupdate/controls_fhem.txt
https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt



update check

fhem
nothing to do...

fhemtabletui
nothing to do...



update all

2019.12.08 17:57:08.784 1 : fhem
2019.12.08 17:57:11.002 1 : nothing to do...
2019.12.08 17:57:11.012 1 :
2019.12.08 17:57:11.013 1 : fhemtabletui
2019.12.08 17:57:11.530 1 : nothing to do...



So sieht derzeit meine Ausgabe aus, wenn ich alle Repositories auf dem aktuellen Stand habe.

Statt https://fhem.de/fhemupdate/controls_fhem.txt kann man auch http://fhem.de/fhemupdate/controls_fhem.txt nutzen; ist wohl derzeit auch der Standard im Docker-Image. Beide Varianten führen bei mir aber zum selben Ergebnis.

persching

Wo kann ich denn angeben ob die Daten per http oder https geholt werden? Ich habe (zumindest bewusst) nichts umgestellt.

OdfFhem

@persching

more /opt/fhem/FHEM/controls.txt

https://fhem.de/fhemupdate/controls_fhem.txt
https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt


Diese Datei wird normal über das update-Kommando verwaltet, kann aber im Zweifel auch vom Prompt aus editiert werden.

Jackson

Nabend,

irgendwie schaffe ich es nicht den node.js package im fhem container zu aktualiseren.


Error code E500
Summary:
Parsing error - malformed JSON string, neither tag, array, object, number, string or atom, at character offset 277 (before "sh: 2: npm: Permissi...") at ./FHEM/42_npmjs.pm line 1160.
Detail:
{
"versions":
{"http_parser":"2.8.0","node":"10.17.0","v8":"6.8.275.32-node.54","uv":"1.28.0","zlib":"1.2.11","brotli":"1.0.7","ares":"1.15.0","modules":"64","nghttp2":"1.39.2","napi":"5","openssl":"1.1.1d","icu":"64.2","unicode":"12.1","cldr":"35.1","tz":"2019a"}
, "outdated": sh: 2: npm: Permission denied
}


Was mach ich falsch? Wenn ich ein "set fhemServerNpm statusRequest" ausführe, ist der Status plötzlich wieder grün.

List Docker


Internals:
   .FhemMetaInternals 1
   CHANGED   
   FUUID      5dba9b1c-f33f-ebd1-6eb9-52ce42b0745edb9c
   NAME       DockerImageInfo
   NR         14
   STATE      ok
   TYPE       DockerImageInfo
   READINGS:
     2019-10-31 09:30:17   container.cap.e audit_write,chown,dac_override,fowner,fsetid,kill,mknod,net_bind_service,net_raw,setfcap,setgid,setpcap,setuid,sys_chroot

     2019-10-31 09:30:17   container.cap.i audit_write,chown,dac_override,fowner,fsetid,kill,mknod,net_bind_service,net_raw,setfcap,setgid,setpcap,setuid,sys_chroot

     2019-10-31 09:30:17   container.cap.p audit_write,chown,dac_override,fowner,fsetid,kill,mknod,net_bind_service,net_raw,setfcap,setgid,setpcap,setuid,sys_chroot

     2019-12-04 20:19:50   container.hostname e707bbf79ed6

     2019-10-31 09:30:17   container.hostnetwork 0

     2019-12-04 20:19:50   container.id    e707bbf79ed6809c6052dc9716ef22a414ac5c2570ba75ece3d2e15e2ab345e7

     2019-10-31 09:30:17   container.privileged 0

     2019-10-31 09:30:17   id.gid          1000
     2019-10-31 09:30:17   id.gname        fhem
     2019-10-31 09:30:17   id.groups       [ "fhem": 1000, "tty": 5, "mail": 8, "dialout": 20, "audio": 29, "video": 44, "bluetooth": 6001, "gpio": 6002, "i2c": 6003 ]
     2019-10-31 09:30:17   id.uid          1000
     2019-10-31 09:30:17   id.uname        fhem
     2019-11-11 21:39:19   image.created   2019-11-10T19:16:37+00:00
     2019-10-31 09:30:17   image.description A basic Docker image for FHEM house automation system, based on Debian Buster.
     2019-10-31 09:30:17   image.documentation https://github.com/fhem/fhem-docker/blob/ae19137eaa2af2fcfe97997d16c1c761d4fa0cd6/README.md
     2019-10-31 09:30:17   image.licenses  MIT
     2019-10-31 09:30:17   image.revision  ae19137eaa2af2fcfe97997d16c1c761d4fa0cd6
     2019-10-31 09:30:17   image.source    https://github.com/fhem/fhem-docker/
     2019-10-31 09:30:17   image.title     fhem-amd64_linux
     2019-10-31 09:30:17   image.url       https://hub.docker.com/r/fhem/fhem-amd64_linux
     2019-10-31 09:30:17   image.vendor    Julian Pawlowski
     2019-11-11 21:39:19   image.version   5.9-s20490_v2.2.1-3-gae19137
     2019-10-31 09:30:17   ssh-id_ed25519.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBcVEvrQUjUCijaKDeKOuiycXrOHlAQy+mxzwl6jk3T/ fhem@fhem-docker

     2019-10-31 09:30:17   ssh-id_rsa.pub  ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCz7gLpR+A3PguntwsJOmaxMAY46Yh0CXuut677JROk+WYq3pirJRC8KWmeG8moHYGmRrx5R36apTUZEFGRqM4Q1CJpv1d/3rTMv/6ou+AGb2uaQKfjUKiZswLc8E/YYQTCfxLZpuTdfdN3VIxeG0rSFtaaYNSJeeCd+6qBCyDv/np2vzXj28w00rOn45KhD/up/i8yKmhjD3slvpj0aPtlJjib4KmX44dA1n41EUPwiMyD+oh5eQId3+AE7kCQel3NHx86b/QPLCS2Ew36sZxrKAOPut6XXh9u9Edq26aR6eatLI36ex7/ukY676oSmgcbs2qASzrcKkibX5sfhG6lUbPuwIDSZ1EP3xUfrf0LkKfhJ2FzNfqkU2bzUKOBY1jIjb5Y8IIAk1MImO5EJqWqbGbvehVXYWQPojJTeDqJAOi0dgfU5pSpYKwvhjJ5o7EOQtt/rkTK7ZAzIGQArACrMTJKuWMhUOgM6ZG+LhTdYzc47Fnzm0Yad/eCAWCNevGpFlnQRiPhrW1tua6dB0RaGwCf4o9CyzoZuoDeBwn9iSmucPXG3HvbWIugrDXZPFiJdTlcfP/CxutTsXTaLC9qii5VGPvLbTrHYFLZBHQfC9y91djAc5BtA2Cf3nE++f7Pk7m2gEgHo9y4XvcRL+0BVVp7zBYQ37Ih4qCKYIN51Q== fhem@fhem-docker

     2019-10-31 09:30:17   sudoers         [ "# Auto-generated during container start", "fhem ALL=(ALL) NOPASSWD:SETENV: /usr/bin/npm install *", "fhem ALL=(ALL) NOPASSWD:SETENV: /usr/bin/npm uninstall *", "fhem ALL=(ALL) NOPASSWD:SETENV: /usr/bin/npm update *", "fhem ALL=(ALL) NOPASSWD:SETENV: /usr/local/bin/cpanm *", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -q update", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -s -q -V upgrade", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -y install *", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -y -q -V dist-upgrade", "fhem ALL=(ALL) NOPASSWD: /usr/bin/apt-get -y -q -V upgrade", "fhem ALL=(ALL) NOPASSWD: /usr/bin/nmap" ]
Attributes:
   alias      Docker Image Info
   devStateIcon ok:security@green Initialized:system_fhem_reboot@orange .*:message_attention@red
   group      System
   icon       docker
   room       00_System




FHEM5.9@RPI3

persching

Ich befürchte fast dass ich ganz andere Probleme habe. Ich hab jetzt mein pihole wieder auf cloudflare als DNS resolver eingestellt und jetzt bekomme ich wenigstens mal irgendwas hin so dass bei Update mal kein 'nothing to do' angezeigt bekomme. Aber so richtig flutscht es nicht. Ich bleibe schon bei 10_CUL_HM.pm hängen...

Morgennebel

Zitat von: Jackson am 08 Dezember 2019, 21:45:20
, "outdated": sh: 2: npm: Permission denied

npm kann wegen fehlender Rechte nicht von /bin/sh aufgerufen werden. Wer das aufruft, keine Ahnung.

Dein Setup verstößt aber gegen das KISS-Prinzip und Du selbst kannst es nicht debuggen. Was soll passieren, wenn es mal richtig kritisch wird...?

Ciao, -MN
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

persching

Zitat von: OdfFhem am 08 Dezember 2019, 20:10:15
@persching

more /opt/fhem/FHEM/controls.txt

https://fhem.de/fhemupdate/controls_fhem.txt
https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt


Diese Datei wird normal über das update-Kommando verwaltet, kann aber im Zweifel auch vom Prompt aus editiert werden.

Es wird immer komischer. In meiner controls.txt steht definitiv "http://fhem.de/fhemupdate/controls_fhem.txt":

https://ibb.co/VjFzpfY

trotzdem kommt dann im Log der Eintrag

2019.12.10 14:48:40.106 1: https://fhem.de/fhemupdate/controls_fhem.txt: Can't connect(1) to https://fhem.de:443: IO::Socket::INET: connect: timeout

erste Idee: vielleicht wird auf eine andere Datei zugegriffen und darum habe ich einfach .aaa an den Pfad gehängt. Das führt zu

2019.12.10 14:51:26.849 1: https://fhem.de/fhemupdate/controls_fhem.txt.aaa: Can't connect(1) to https://fhem.de:443: IO::Socket::INET: connect: timeout

Woher kommt das https?  :o


OdfFhem

@persching

Ist denn Dein Problemfall auf den FHEM-Server beschränkt oder generell in Deinem Netzwerk vorhanden?

Mach doch mal folgenden Test: Starte einen Browser im private/incognito-Modus - http/https-Aufrufreihenfolge einhalten:

Erster und evtl weitere http-Aufrufe liefern immer das not secure-Schloss

http://fhem.de/fhemupdate/controls_fhem.txt


Mindestens ein https-Aufruf ausführen; liefert logischerweise das secure-Schloss

https://fhem.de/fhemupdate/controls_fhem.txt


Ab jetzt (!) liefert aber auch jeder weitere http-Aufruf das secure-Schloss; d.h. werden statt mit http mit https ausgeführt

http://fhem.de/fhemupdate/controls_fhem.txt


persching

Hallo OdfFhem,
es ist wie von dir beschrieben: http Aufruf erst ohne Schloss, dann https mit Schloss und ab dann beide Varianten mit Schloss.

OdfFhem

@persching

Von welchem Rechner hast Du den Test jetzt gemacht?

Mach doch mal zusätzlich folgende Aufrufe vom Prompt am FHEM-Server:

curl http://fhem.de/fhemupdate/controls_fhem.txt -o http.out -v > http.verbose 2>&1


curl https://fhem.de/fhemupdate/controls_fhem.txt -o https.out -v > https.verbose 2>&1


Darauf achten, dass die Ausgabedateien in einem temporären Verzeichnis (z.B. /tmp) landen bzw. wieder entfernt werden.

Die out-Dateien sollten ja im Normalfall gleichgroß sein. In den verbose-Dateien finden sich im Fehlerfall vermutlich ein paar zusätzliche Informationen ...

Morgennebel

Zitat von: persching am 10 Dezember 2019, 17:20:02
es ist wie von dir beschrieben: http Aufruf erst ohne Schloss, dann https mit Schloss und ab dann beide Varianten mit Schloss.

Im dritten Test macht der Server automatisch eine Umlenkung von http auf https. Schau Dir die URL im Browser mal genau an.

Warum er es beim ersten Mal nicht macht, keine Ahnung. Evtl. eine RegExp im Redirect, die nicht funktioniert?

Ciao, -MN
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

persching

Zitat von: OdfFhem am 10 Dezember 2019, 18:33:51
@persching

Von welchem Rechner hast Du den Test jetzt gemacht?

Mach doch mal zusätzlich folgende Aufrufe vom Prompt am FHEM-Server:

curl http://fhem.de/fhemupdate/controls_fhem.txt -o http.out -v > http.verbose 2>&1


curl https://fhem.de/fhemupdate/controls_fhem.txt -o https.out -v > https.verbose 2>&1


Darauf achten, dass die Ausgabedateien in einem temporären Verzeichnis (z.B. /tmp) landen bzw. wieder entfernt werden.

Die out-Dateien sollten ja im Normalfall gleichgroß sein. In den verbose-Dateien finden sich im Fehlerfall vermutlich ein paar zusätzliche Informationen ...

Ich habe den Test mit Firefox auf meinem Android 9 Handy gemacht.

Die beiden curl Befehle bringen folgendes zutage:

http.verbose:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 2a01:4f8:10a:806::2...
* TCP_NODELAY set
* Connected to fhem.de (2a01:4f8:10a:806::2) port 80 (#0)
> GET /fhemupdate/controls_fhem.txt HTTP/1.1
> Host: fhem.de
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Wed, 11 Dec 2019 06:20:45 GMT
< Server: Apache
< X-Xss-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< Last-Modified: Tue, 10 Dec 2019 06:45:12 GMT
< Accept-Ranges: bytes
< Content-Length: 143698
< Vary: Accept-Encoding
< Cache-Control: max-age=0, no-cache, no-store, must-revalidate
< Pragma: no-cache
< Content-Type: text/plain
<
{ [1031 bytes data]

100  140k  100  140k    0     0  1287k      0 --:--:-- --:--:-- --:--:-- 1287k
* Connection #0 to host fhem.de left intact


https.verbose

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 2a01:4f8:10a:806::2...
* TCP_NODELAY set
* Connected to fhem.de (2a01:4f8:10a:806::2) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [108 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2677 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=fhem.de
*  start date: Dec  1 14:09:13 2019 GMT
*  expire date: Feb 29 14:09:13 2020 GMT
*  subjectAltName: host "fhem.de" matched cert's "fhem.de"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
} [5 bytes data]
> GET /fhemupdate/controls_fhem.txt HTTP/1.1
> Host: fhem.de
> User-Agent: curl/7.58.0
> Accept: */*
>
{ [5 bytes data]
< HTTP/1.1 200 OK
< Date: Wed, 11 Dec 2019 06:21:55 GMT
< Server: Apache
< Strict-Transport-Security: max-age=31536000;
< X-Xss-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< Last-Modified: Tue, 10 Dec 2019 06:45:12 GMT
< Accept-Ranges: bytes
< Content-Length: 143698
< Vary: Accept-Encoding
< Cache-Control: max-age=0, no-cache, no-store, must-revalidate
< Pragma: no-cache
< Content-Type: text/plain
<
{ [5 bytes data]

100  140k  100  140k    0     0  1031k      0 --:--:-- --:--:-- --:--:-- 1031k
* Connection #0 to host fhem.de left intact


diff http.out https.out liefert keine unterschiede...

persching

Ich hab jetzt noch einen weiteren Test gemacht und mich in Portainer in meinen fhem-Container eingeloggt und dort im Terminalfenster die curl Befehle ausgeführt. Beide liefern die gleich große Dateien zurück. Und das wichtigste: es werden die Daten runtergeladen, kein Timeout oder sonst etwas. Wartet der Updateprozess von fhem einfach nicht lange genug und bringt darum diese Fehlermeldung??