NEWS
iobroker telefoniert "nach Hause"?
-
Hallo Miteinander,
ich bin zwar neu hier im Forum aber ein langjähriger Mitleser und Nutzer von iobroker. Vorher bin lange Jahre begeisterter Nutzer von ccu.io gewesen, bis ich dann wg. der Ablösung der CCU1 zu iobroker wechseln musste.
Seit 2019 betreibe ich eine umfangreiche iobroker-Installation. Sämtliche Bereiche in meinem Neubau wird von Homematic mit dem darübergestülpten iobroker verwaltet.An dieser Stelle muss ich mich auch bei den Entwicklern für die tolle Arbeit bedanken. Absolut sensationell!
Die ständig wachsende Zahl von JS-Scripten sowie der Wunsch nach zusätzlichen Adaptern zwang mich irgendwann von dem zuverlässigen Raspi2 mit js-controller 1.4.2 auf einen aktuellen Raspi 4 mit 8 GB zu migrieren. Bis auf Änderungen an den JS-Scripten hab ich das System in Ruhe gelassen, und es lief ohne Zwischenfälle 2 Jahre durch.
Wegen der Wichtigkeit bevorzuge ich "saubere" Systeme, sämtliche "wichtigen" Host laufen in einem abgeschotteten "Prozess-VLAN" (CCU, iobroker, Wärmepumpensteuerung, Wallbox, Wechselrichter, SolarLog, ISG, vzlogger usw usw.). Sämtlicher Traffic inbound oder outbound aus diesem VLAN wird von einer Firewall kontrolliert.
Ich habe also den neuen Raspi4 komplett neu aufgesetzt, mit aktuellem Buster und der aktuellen "stable" iobroker Installation (js-controller 3.2.16).
Bis auf minimale Änderungen an den .vis-views (wg. den Pfaden zu den Bilder) sowie marginale Änderungen an den JS-Scripten lief auch alles auf Anhieb.Leider stelle ich fest, dass die aktuelle Installation bei jedem Aufruf der Admin-Oberfläche eine Verbindung zu 79.143.182.215 (m0855.contabo.host) mit tcp80 aufbaue möchte. Ich habe schon alles abgeschaltet was die Oberfläche hergibt (Statistik, den Sentry-Plugin disabled), aber trotzdem will das Ding ständig nach Hause telefonieren. Ich habe verstanden, dass die Reporting Funktionen neu aufgesetzt sind und versucht über common.disableDataReporting:true im host-Objekt das Verhalten zu Ändern.
Das syslog spuckt auch ständig folgende Meldungen aus:May 14 12:29:08 [xxx] bash[2927]: Send diag info: null
May 14 12:29:10 [xxx] bash[2927]: Cannot send diag info: ETIMEDOUTVielleicht mach ich auch einfach was falsch.
Ich verstehe natürlich das berechtigte Interesse an statistischen Daten zur Fehleranalyse, und bin auch bereit diese vom Testsystem bereitzustellen (ich betreibe eine 2. identische Installation für Test und Entwicklungszwecke), aber das Produktivsystem ist bewusst "cloud-free" konzipiert.
Hat jemand eine Idee, wie ich dem Produktivsystem sämtliche Verbindungsversuche Richtung Internet abgewöhnen kann?
Vielen Dank schon mal im Voraus
berti
-
Hallo Miteinander,
ich bin zwar neu hier im Forum aber ein langjähriger Mitleser und Nutzer von iobroker. Vorher bin lange Jahre begeisterter Nutzer von ccu.io gewesen, bis ich dann wg. der Ablösung der CCU1 zu iobroker wechseln musste.
Seit 2019 betreibe ich eine umfangreiche iobroker-Installation. Sämtliche Bereiche in meinem Neubau wird von Homematic mit dem darübergestülpten iobroker verwaltet.An dieser Stelle muss ich mich auch bei den Entwicklern für die tolle Arbeit bedanken. Absolut sensationell!
Die ständig wachsende Zahl von JS-Scripten sowie der Wunsch nach zusätzlichen Adaptern zwang mich irgendwann von dem zuverlässigen Raspi2 mit js-controller 1.4.2 auf einen aktuellen Raspi 4 mit 8 GB zu migrieren. Bis auf Änderungen an den JS-Scripten hab ich das System in Ruhe gelassen, und es lief ohne Zwischenfälle 2 Jahre durch.
Wegen der Wichtigkeit bevorzuge ich "saubere" Systeme, sämtliche "wichtigen" Host laufen in einem abgeschotteten "Prozess-VLAN" (CCU, iobroker, Wärmepumpensteuerung, Wallbox, Wechselrichter, SolarLog, ISG, vzlogger usw usw.). Sämtlicher Traffic inbound oder outbound aus diesem VLAN wird von einer Firewall kontrolliert.
Ich habe also den neuen Raspi4 komplett neu aufgesetzt, mit aktuellem Buster und der aktuellen "stable" iobroker Installation (js-controller 3.2.16).
Bis auf minimale Änderungen an den .vis-views (wg. den Pfaden zu den Bilder) sowie marginale Änderungen an den JS-Scripten lief auch alles auf Anhieb.Leider stelle ich fest, dass die aktuelle Installation bei jedem Aufruf der Admin-Oberfläche eine Verbindung zu 79.143.182.215 (m0855.contabo.host) mit tcp80 aufbaue möchte. Ich habe schon alles abgeschaltet was die Oberfläche hergibt (Statistik, den Sentry-Plugin disabled), aber trotzdem will das Ding ständig nach Hause telefonieren. Ich habe verstanden, dass die Reporting Funktionen neu aufgesetzt sind und versucht über common.disableDataReporting:true im host-Objekt das Verhalten zu Ändern.
Das syslog spuckt auch ständig folgende Meldungen aus:May 14 12:29:08 [xxx] bash[2927]: Send diag info: null
May 14 12:29:10 [xxx] bash[2927]: Cannot send diag info: ETIMEDOUTVielleicht mach ich auch einfach was falsch.
Ich verstehe natürlich das berechtigte Interesse an statistischen Daten zur Fehleranalyse, und bin auch bereit diese vom Testsystem bereitzustellen (ich betreibe eine 2. identische Installation für Test und Entwicklungszwecke), aber das Produktivsystem ist bewusst "cloud-free" konzipiert.
Hat jemand eine Idee, wie ich dem Produktivsystem sämtliche Verbindungsversuche Richtung Internet abgewöhnen kann?
Vielen Dank schon mal im Voraus
berti
@berti7 sagte in iobroker telefoniert "nach Hause"?:
Hat jemand eine Idee, wie ich dem Produktivsystem sämtliche Verbindungsversuche Richtung Internet abgewöhnen kann?
Ja!
Systemeinstellungen - Statistik - Pulldown auf "nichts" stellen
EDIT:
du hattest ja "sämtliche" geschrieben.
Das wird etwas schwieriger. Schließlich sucht dein ioBroker ja auch immer wieder nach Adapterupdates.
den Info-Adapter wirst du wohl auch deinstalliert haben, oder? -
... das wäre zu einfach.
diese Einstellung in der webGUI war natürlich das Erste was ich durchgeführt habe...Weiterhin:
STATE system.host.x.plugins.sentry.enabled auf false
STATE system.adapter.x.plugins.sentry.enabled auf false
iobroker plugin disable sentryschon mal Danke für die Mühe.
-
Kurzer Nachtrag: Die Meldung im syslog kommt immer dann wenn man auf die GUI im Browser neu aufruft, oder wenn man auf "hosts" klickt ... Und dann kann man auch im Firewall-Log sehen, dass ein Verbindungsversuch zu der oben angegebenen Adresse kommt
-
... ihr seid der Hammer: ich sehe im github, dass der Fall schon eingekippt und bearbeitet wurde.
Ich habe die 6 Zeilen in main.js der Version 3.2.16 angepasst (gemaess https://github.com/ioBroker/ioBroker.js-controller/pull/1354/files) und was soll ich sagen: ALLES PRIMA. Getestet, alle Varianten durchprobiert und tcpdump gibt jetzt auch Ruhe
Vielen Dank für die tolle Arbeit
-
Hm, ich muss leider nochmal nachhaken...
Beim Start versucht iobroker auch diese Adresse zu erreichen: s21181212.onlinehome-server.info
tcpdump:
17:19:57.311012 IP 10.0.50.13.39058 > s21181212.onlinehome-server.info.https: Flags [S], seq 1140359660, win 64240, options [mss 1460,sackOK,TS val 2842676723 ecr 0,nop,wscale 7], length 0
17:19:58.325227 IP 10.0.50.13.39058 > s21181212.onlinehome-server.info.https: Flags [S], seq 1140359660, win 64240, options [mss 1460,sackOK,TS val 2842677738 ecr 0,nop,wscale 7], length 0
17:20:00.405177 IP 10.0.50.13.39058 > s21181212.onlinehome-server.info.https: Flags [S], seq 1140359660, win 64240, options [mss 1460,sackOK,TS val 2842679818 ecr 0,nop,wscale 7], length 0
17:20:04.485193 IP 10.0.50.13.39058 > s21181212.onlinehome-server.info.https: Flags [S], seq 1140359660, win 64240, options [mss 1460,sackOK,TS val 2842683898 ecr 0,nop,wscale 7], length 0
17:20:12.885207 IP 10.0.50.13.39058 > s21181212.onlinehome-server.info.https: Flags [S], seq 1140359660, win 64240, options [mss 1460,sackOK,TS val 2842692298 ecr 0,nop,wscale 7], length 0
17:20:29.525208 IP 10.0.50.13.39058 > s21181212.onlinehome-server.info.https: Flags [S], seq 1140359660, win 64240, options [mss 1460,sackOK,TS val 2842708938 ecr 0,nop,wscale 7], length 0
17:21:02.165214 IP 10.0.50.13.39058 > s21181212.onlinehome-server.info.https: Flags [S], seq 1140359660, win 64240, options [mss 1460,sackOK,TS val 2842741578 ecr 0,nop,wscale 7], length 0Passiert nur beim Start von iobroker und gibt dann Ruhe.
Verständnisfrage: was passiert da? Und gibts Langzeitfolgen wenn ich den Connect per Firewall unterbinde? Sorry wenn ich nochmal nerve, aber ich muss das wissen bevor das System in Produktivbetrieb geht.Gruesse
-
@berti7 Es ist korrekt das
- vis und ggf andere Adapter die eine Lizenz benötigen (auch wenn es bei vis die "Private Use Lizenz" ist diese Online prüfen - ohne Zugriff kann vis bzw Lizenz-Adapter nicht genutzt werden
- Admin bzw CLI Kommandos das Adapter-Repository Online lädt - ohne Zugriff keine Adapter Updates u.ä.
- Admin zB ab Admin5 Adater-Ratings Online lädt - ohne Zugriff ggf keine Rating-Anzeige im Admin (ich hoffe es geht nicht mehr kaputt)
- Cloud bzw iot Adapter verbinden sich aus extern um Ihre Funktion anzubieten
Am Ende hat es die genannten Auswirkungen wenn diese Abfragen nicht zugelassen werden.
-
... ihr seid der Hammer: ich sehe im github, dass der Fall schon eingekippt und bearbeitet wurde.
Ich habe die 6 Zeilen in main.js der Version 3.2.16 angepasst (gemaess https://github.com/ioBroker/ioBroker.js-controller/pull/1354/files) und was soll ich sagen: ALLES PRIMA. Getestet, alle Varianten durchprobiert und tcpdump gibt jetzt auch Ruhe
Vielen Dank für die tolle Arbeit
727
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge