NEWS
ioBroker Umzug auf neues Gerät
-
@150d sagte in ioBroker Umzug auf neues Gerät:
Was verstehst Du unter "direkt installiert"?
= "nicht über den Master".
Dann weiß der nichts davon.@150d sagte in ioBroker Umzug auf neues Gerät:
Es handelt sich um unterschiedliche Systeme mit unterschiedlichem Stand
und genau dann kann es zu Problemen kommen.
@Homoran sagte in ioBroker Umzug auf neues Gerät:
@150d sagte in ioBroker Umzug auf neues Gerät:
Was verstehst Du unter "direkt installiert"?
= "nicht über den Master".
Dann weiß der nichts davon.Nein. Installiert wurde immer über den Master. Ich kann nicht mehr sicher sagen, ob immer "direkt" auf den Slave (also direkt beim Installieren angegeben Host=Slave) oder zuerst installiert auf dem Master und später "verschoben" auf den Slave, aber über Kommandozeile auf den Slaves nie.
-
@Homoran sagte in ioBroker Umzug auf neues Gerät:
bring bitte alle 3 hosts auf gleiche Versionen per
iob nodejs-updateDas ist nicht ganz so einfach. Es handelt sich um unterschiedliche Systeme mit unterschiedlichem Stand. Das Fass möchte ich zum jetzigen Zeitpunkt lieber nicht auch noch aufmachen, das macht die Sache nur noch komplizierter.
Hoffentlich sind da such aktuelle OS Versionen drsuf und krine veralteten direkt installierte Adapter
Was verstehst Du unter "direkt installiert"? Über Kommandozeile?
-
@Thomas-Braun sagte in ioBroker Umzug auf neues Gerät:
@150d sagte in ioBroker Umzug auf neues Gerät:
home
Auf dem home läuft gar kein iobroker.
Natürlich nicht, soll man den nicht vor "iob diag" anhalten?
-
@Thomas-Braun sagte in ioBroker Umzug auf neues Gerät:
@150d sagte in ioBroker Umzug auf neues Gerät:
home
Auf dem home läuft gar kein iobroker.
Natürlich nicht, soll man den nicht vor "iob diag" anhalten?
@150d sagte in ioBroker Umzug auf neues Gerät:
Natürlich nicht, soll man den nicht vor "iob diag" anhalten?
Natürlich nicht. Was soll der denn sonst diagnostizieren, wenn der gar nicht läuft?
-
@150d sagte in ioBroker Umzug auf neues Gerät:
Natürlich nicht, soll man den nicht vor "iob diag" anhalten?
Natürlich nicht. Was soll der denn sonst diagnostizieren, wenn der gar nicht läuft?
Ich habe jetzt (auf dem Master) die Dateien in
/opt/iobroker/iobroker-data/files
manuell wiederhergestellt, die beim Restore offenbar nicht übertragen wurden. Nachdem ich dort die Verzeichnisse
/opt/iobroker/iobroker-data/files/homekit-controller.admin/
/opt/iobroker/iobroker-data/files/matter.admin/vom vorherigen System eingefügt hatte, können die Slave-Adapter jetzt wieder vom Master-UI aus konfiguriert werden. Es fehlten offenbar wirklich nur die html-Dateien für das Admin-UI.
Danke an alle Beteiligten!
PS: Ich habe meine vorherigen Posts editiert und das Diag-Log entfernt. Es ist mir nicht wohl dabei, wenn solche Interna öffentlich verfügbar bleiben. Also bitte nicht wundern. :-)
-
Ich habe jetzt (auf dem Master) die Dateien in
/opt/iobroker/iobroker-data/files
manuell wiederhergestellt, die beim Restore offenbar nicht übertragen wurden. Nachdem ich dort die Verzeichnisse
/opt/iobroker/iobroker-data/files/homekit-controller.admin/
/opt/iobroker/iobroker-data/files/matter.admin/vom vorherigen System eingefügt hatte, können die Slave-Adapter jetzt wieder vom Master-UI aus konfiguriert werden. Es fehlten offenbar wirklich nur die html-Dateien für das Admin-UI.
Danke an alle Beteiligten!
PS: Ich habe meine vorherigen Posts editiert und das Diag-Log entfernt. Es ist mir nicht wohl dabei, wenn solche Interna öffentlich verfügbar bleiben. Also bitte nicht wundern. :-)
@150d sagte in ioBroker Umzug auf neues Gerät:
Ich habe jetzt (auf dem Master) die Dateien in
/opt/iobroker/iobroker-data/files
manuell wiederhergestellt, die beim Restore offenbar nicht übertragen wurden. Nachdem ich dort die Verzeichnisse
/opt/iobroker/iobroker-data/files/homekit-controller.admin/
/opt/iobroker/iobroker-data/files/matter.admin/vom vorherigen System eingefügt hatte, können die Slave-Adapter jetzt wieder vom Master-UI aus konfiguriert werden. Es fehlten offenbar wirklich nur die html-Dateien für das Admin-UI.
ääähmmmm!
da wäre es sicherer gewesen, das Backup nochmal neu zu restoren.
Wenigstens herauszufinden warum due Daten nicht da waren.
Möglicherweise hätte such ein
iob upload alldas hinbekommen und zwar auch in der korrekten Fassung der Dateien.Ein kopieren von Daten sollte immer nur auf das selbe System durchgeführt werden.
Auf jeinen Fall bei anderer Hardware, OS oder node-Version
-
Ich habe jetzt (auf dem Master) die Dateien in
/opt/iobroker/iobroker-data/files
manuell wiederhergestellt, die beim Restore offenbar nicht übertragen wurden. Nachdem ich dort die Verzeichnisse
/opt/iobroker/iobroker-data/files/homekit-controller.admin/
/opt/iobroker/iobroker-data/files/matter.admin/vom vorherigen System eingefügt hatte, können die Slave-Adapter jetzt wieder vom Master-UI aus konfiguriert werden. Es fehlten offenbar wirklich nur die html-Dateien für das Admin-UI.
Danke an alle Beteiligten!
PS: Ich habe meine vorherigen Posts editiert und das Diag-Log entfernt. Es ist mir nicht wohl dabei, wenn solche Interna öffentlich verfügbar bleiben. Also bitte nicht wundern. :-)
@150d sagte in ioBroker Umzug auf neues Gerät:
solche Interna öffentlich verfügbar bleiben. Also bitte nicht wundern
wenn da nicht zufällig gerade Zugangsdaten im log auftauchen, was soll da "gefährliches" drin stehen?
-
@150d sagte in ioBroker Umzug auf neues Gerät:
Ich habe jetzt (auf dem Master) die Dateien in
/opt/iobroker/iobroker-data/files
manuell wiederhergestellt, die beim Restore offenbar nicht übertragen wurden. Nachdem ich dort die Verzeichnisse
/opt/iobroker/iobroker-data/files/homekit-controller.admin/
/opt/iobroker/iobroker-data/files/matter.admin/vom vorherigen System eingefügt hatte, können die Slave-Adapter jetzt wieder vom Master-UI aus konfiguriert werden. Es fehlten offenbar wirklich nur die html-Dateien für das Admin-UI.
ääähmmmm!
da wäre es sicherer gewesen, das Backup nochmal neu zu restoren.
Wenigstens herauszufinden warum due Daten nicht da waren.
Möglicherweise hätte such ein
iob upload alldas hinbekommen und zwar auch in der korrekten Fassung der Dateien.Ein kopieren von Daten sollte immer nur auf das selbe System durchgeführt werden.
Auf jeinen Fall bei anderer Hardware, OS oder node-Version
-
@150d sagte in ioBroker Umzug auf neues Gerät:
solche Interna öffentlich verfügbar bleiben. Also bitte nicht wundern
wenn da nicht zufällig gerade Zugangsdaten im log auftauchen, was soll da "gefährliches" drin stehen?
@Homoran sagte in ioBroker Umzug auf neues Gerät:
wenn da nicht zufällig gerade Zugangsdaten im log auftauchen, was soll da "gefährliches" drin stehen?
Zum Beispiel Maschinennamen, IP-Layout, oder welche Adapter ich installiert habe und was für interessante Targets es folglich in meinem Netz noch geben könnte.
Beispiel: Wenn irgendwo ein SMB gemountet wäre, könnte man doch mal Angriffe gegen Windows-Server ausprobieren. Wenn ich einen Somfy-Adapter installiert hätte, könnte man mal testen, ob das Somfy-Gerät auch wirklich die neueste Firmware installiert hat oder doch noch Vulnerabilities offen sind...
Der selbe Grund, aus dem Spione so gerne in Mülleimern wühlen. Hast Du nie den Film "Sneakers" gesehen? :-)
-
@Homoran sagte in ioBroker Umzug auf neues Gerät:
wenn da nicht zufällig gerade Zugangsdaten im log auftauchen, was soll da "gefährliches" drin stehen?
Zum Beispiel Maschinennamen, IP-Layout, oder welche Adapter ich installiert habe und was für interessante Targets es folglich in meinem Netz noch geben könnte.
Beispiel: Wenn irgendwo ein SMB gemountet wäre, könnte man doch mal Angriffe gegen Windows-Server ausprobieren. Wenn ich einen Somfy-Adapter installiert hätte, könnte man mal testen, ob das Somfy-Gerät auch wirklich die neueste Firmware installiert hat oder doch noch Vulnerabilities offen sind...
Der selbe Grund, aus dem Spione so gerne in Mülleimern wühlen. Hast Du nie den Film "Sneakers" gesehen? :-)
Dazu müssten aber die Ports nicht abgesichert nach außen offen sein.
Und das tut man NIE, NIE, NIE.Auf wenn wohl diverse Büchsen dennoch komplett 'ohne Hose' im Netz stehen.
-
@150d sagte in ioBroker Umzug auf neues Gerät:
Ich habe jetzt (auf dem Master) die Dateien in
/opt/iobroker/iobroker-data/files
manuell wiederhergestellt, die beim Restore offenbar nicht übertragen wurden. Nachdem ich dort die Verzeichnisse
/opt/iobroker/iobroker-data/files/homekit-controller.admin/
/opt/iobroker/iobroker-data/files/matter.admin/vom vorherigen System eingefügt hatte, können die Slave-Adapter jetzt wieder vom Master-UI aus konfiguriert werden. Es fehlten offenbar wirklich nur die html-Dateien für das Admin-UI.
ääähmmmm!
da wäre es sicherer gewesen, das Backup nochmal neu zu restoren.
Wenigstens herauszufinden warum due Daten nicht da waren.
Möglicherweise hätte such ein
iob upload alldas hinbekommen und zwar auch in der korrekten Fassung der Dateien.Ein kopieren von Daten sollte immer nur auf das selbe System durchgeführt werden.
Auf jeinen Fall bei anderer Hardware, OS oder node-Version
@Homoran sagte in ioBroker Umzug auf neues Gerät:
Möglicherweise hätte such ein
iob upload alldas hinbekommen und zwar auch in der korrekten Fassung der Dateien.Das hat mir keine Ruhe gelassen, deswegen habe ich das jetzt auch nochmal ausprobiert. In der Ausgabe finde ich folgende Zeile für jeden Adapter, der (nur) auf einem Slave läuft:
No alive host found which has the adapter homekit-controller installed! No upload possible. Skipped.Deshalb also hat das Restore diese Dateien nicht wiederhergestellt: Es hat die Slaves nicht als "alive" erkannt.
Die Zeile erscheint übrigens nicht für den Adapter, den ich mittels einer neuen Instanz "nachinstalliert" hatte.
-
@Homoran sagte in ioBroker Umzug auf neues Gerät:
Möglicherweise hätte such ein
iob upload alldas hinbekommen und zwar auch in der korrekten Fassung der Dateien.Das hat mir keine Ruhe gelassen, deswegen habe ich das jetzt auch nochmal ausprobiert. In der Ausgabe finde ich folgende Zeile für jeden Adapter, der (nur) auf einem Slave läuft:
No alive host found which has the adapter homekit-controller installed! No upload possible. Skipped.Deshalb also hat das Restore diese Dateien nicht wiederhergestellt: Es hat die Slaves nicht als "alive" erkannt.
Die Zeile erscheint übrigens nicht für den Adapter, den ich mittels einer neuen Instanz "nachinstalliert" hatte.
@150d sagte in ioBroker Umzug auf neues Gerät:
Deshalb also hat das Restore diese Dateien nicht wiederhergestellt: Es hat die Slaves nicht als "alive" erkannt.
das passt!
wie ich schrieb
sagte in ioBroker Umzug auf neues Gerät:Die Admindateien müssen da sein, aber höchstens der connect zum slave fehlen
sagte in ioBroker Umzug auf neues Gerät:
Wenigstens herauszufinden warum due Daten nicht da waren
@150d sagte in ioBroker Umzug auf neues Gerät:
Die Zeile erscheint übrigens nicht für den Adapter, den ich mittels einer neuen Instanz "nachinstalliert" hatte
Dann ist irgendwas krumm und der Master sieht den Slave nicht
ist das der mit altem node?
-
Nein, beide Slaves verhalten sich identisch, der mit node v20 und der mit node v22 - beide werden offenbar nicht als "alive" erkannt.
Trotzdem existiert die Instanz des Adapters, und der Adapter auf dem Slave arbeitet einwandfrei auf den Datenpunkten. Unter "Hosts" im UI tauchen alle Slaves normal auf.
Zuerst dachte ich an ein Netzwerkproblem, da sich die drei Maschinen (Master und die beiden Slaves) in drei verschiedenen Subnets befinden. Aber im Firewall-Log steht nichts, außerdem sind die Netze ganz unterschiedlich konfiguriert (wer zu wem darf usw.)
Kann es sein, daß einfach der alive-detection Mechanismus versagt, wenn die Slaves in anderen Subnets sind?
-
Nein, beide Slaves verhalten sich identisch, der mit node v20 und der mit node v22 - beide werden offenbar nicht als "alive" erkannt.
Trotzdem existiert die Instanz des Adapters, und der Adapter auf dem Slave arbeitet einwandfrei auf den Datenpunkten. Unter "Hosts" im UI tauchen alle Slaves normal auf.
Zuerst dachte ich an ein Netzwerkproblem, da sich die drei Maschinen (Master und die beiden Slaves) in drei verschiedenen Subnets befinden. Aber im Firewall-Log steht nichts, außerdem sind die Netze ganz unterschiedlich konfiguriert (wer zu wem darf usw.)
Kann es sein, daß einfach der alive-detection Mechanismus versagt, wenn die Slaves in anderen Subnets sind?
@150d sagte in ioBroker Umzug auf neues Gerät:
Kann es sein, daß einfach der alive-detection Mechanismus versagt, wenn die Slaves in anderen Subnets sind?
wäre durchaus möglich, denn laut Doku (https://www.iobroker.net/#de/documentation/config/multihost.md)
Multihost mit verschiedenen Subnetzen
Wenn beide ioBroker-Hosts in unterschiedlichen Subnetzen sind, …
Beispiel:
Normales LAN (für PC, Tablet, use.) = 192.168.178.0/24
IoT LAN (für Shelly, Kameras, usw.) = 10.20.30.0/24
… geht die Multihost-Automatik (“iobroker multihost enable” und “iobroker multihost browse“) nicht, sondern nur der alte Weg (iobroker setup custom) -
Den manuellen Prozess (nicht "suchen" lassen, sondern über "iobroker setup custom" mit Angabe der beteiligten IPs) habe ich natürlich benutzt. Sonst hätte ich die Slaves ja gar nicht verbunden bekommen.
Meinst Du, daß die alive-Erkennung in dem Fall eben grundsätzlich nicht funktioniert und das Verhalten wie bei mir daher normal ist?
Aber ok, damit kann ich leben. :-)