NEWS
Windows: Nach Restore kein Zugriff auf WebUi
-
Jetzt habe ich noch mal ein wenig herumexperimentiert:
- Win10 neu aufgesetzt
- ioBroker mit dem Installer 1.5.14b installiert
- js-controller auf die 2.x aktualisiert (war noch 1.x)
- ioBroker läuft
- Backup des Basissytems
- Restore von meinem Produktivsystem
- ioBroker host this (mit Erfolgs-Rückmeldungen)
- Neustart der Maschine
- iobroker list instances (keine Instanz aktiv - nirgends ein "+")
- immer noch kein Zugriff auf die Admin-Webseite
Dann der Versuch, das ursprünglich installierte Basissystem wieder zu aktivieren:
- Restore des ursprünglich installierten Basissystems
- weiterhin kein Zugriff (Tests und Zwischenschritte spare ich mir hier)
Und um dem Verdacht vorzubeugen, der Backup könnte korrupt gewesen sein:
Ich habe einen Snapshot meines Produktivsystems (Debian 9.x) gemacht und dann den oben verwendeten backup restored. Mit Erfolg!Sollte jemand Interesse daran haben, die Ursache(n) der geschilderten Probleme mit meiner Hilfe zu analysieren, stehe ich zur Verfügung.
Angesichts der Tatsache, dass dieser und auch andere meiner Threads bzgl. Windows-Installation letztendlich oder gar schon mit dem Eröffnungsbeitrag ins Leere laufen endet aber ansonsten nun erst mal mein Ausflug in die ioBroker-Windows-Welt.
Als erfahrener Windows-Anwender der ersten Stunde hatte ich gehofft, das "malen nach Zahlen", das für mich in LINUX-Umgebungen leider immer noch die Regel ist, hinter mir zu lassen. Ich bin jetzt nicht enttäuscht. Ich habe ein Stück weit Erfahrung gesammelt und werde mich nun eben weiter in die LINUX-Welt reinfuchsen.
Alles Gut!
@hmanfred sagte in Nach Restore kein Zugriff auf WebUi:
js-controller auf die 2.x aktualisiert (war noch 1.x)
Das wird der Grund gewesen sein.
die aktuellen -nach dem Restore installierten- Versionen benötigen js-controller v2 -
Jetzt habe ich noch mal ein wenig herumexperimentiert:
- Win10 neu aufgesetzt
- ioBroker mit dem Installer 1.5.14b installiert
- js-controller auf die 2.x aktualisiert (war noch 1.x)
- ioBroker läuft
- Backup des Basissytems
- Restore von meinem Produktivsystem
- ioBroker host this (mit Erfolgs-Rückmeldungen)
- Neustart der Maschine
- iobroker list instances (keine Instanz aktiv - nirgends ein "+")
- immer noch kein Zugriff auf die Admin-Webseite
Dann der Versuch, das ursprünglich installierte Basissystem wieder zu aktivieren:
- Restore des ursprünglich installierten Basissystems
- weiterhin kein Zugriff (Tests und Zwischenschritte spare ich mir hier)
Und um dem Verdacht vorzubeugen, der Backup könnte korrupt gewesen sein:
Ich habe einen Snapshot meines Produktivsystems (Debian 9.x) gemacht und dann den oben verwendeten backup restored. Mit Erfolg!Sollte jemand Interesse daran haben, die Ursache(n) der geschilderten Probleme mit meiner Hilfe zu analysieren, stehe ich zur Verfügung.
Angesichts der Tatsache, dass dieser und auch andere meiner Threads bzgl. Windows-Installation letztendlich oder gar schon mit dem Eröffnungsbeitrag ins Leere laufen endet aber ansonsten nun erst mal mein Ausflug in die ioBroker-Windows-Welt.
Als erfahrener Windows-Anwender der ersten Stunde hatte ich gehofft, das "malen nach Zahlen", das für mich in LINUX-Umgebungen leider immer noch die Regel ist, hinter mir zu lassen. Ich bin jetzt nicht enttäuscht. Ich habe ein Stück weit Erfahrung gesammelt und werde mich nun eben weiter in die LINUX-Welt reinfuchsen.
Alles Gut!
-
@hmanfred sagte in Nach Restore kein Zugriff auf WebUi:
js-controller auf die 2.x aktualisiert (war noch 1.x)
Das wird der Grund gewesen sein.
die aktuellen -nach dem Restore installierten- Versionen benötigen js-controller v2@Homoran sagte in Nach Restore kein Zugriff auf WebUi:
@hmanfred sagte in Nach Restore kein Zugriff auf WebUi:
js-controller auf die 2.x aktualisiert (war noch 1.x)
Das wird der Grund gewesen sein.
die aktuellen -nach dem Restore installierten- Versionen benötigen js-controller v2Nein. Meine oben beschriebene Vorgehensweise war:
- Win10 neu aufgesetzt
- ioBroker mit dem Installer 1.5.14b installiert
- js-controller auf die 2.x aktualisiert (war noch 1.x)
- ioBroker läuft
- Backup des Basissytems
- Restore von meinem Produktivsystem
Die Aktualisierung des JS-Controllers war die allererste Maßnahme nach Installation von ioBroker!
-
@hmanfred
Ich weiß nicht genau, ob es hier gefragt wurde, aber nutzt du auf dem debian redis?
Wenn ja nur die states oder auch objects?@simatec sagte in Windows: Nach Restore kein Zugriff auf WebUi:
@hmanfred
Ich weiß nicht genau, ob es hier gefragt wurde, aber nutzt du auf dem debian redis?
Wenn ja nur die states oder auch objects?Ich weiss nicht so recht, wie ich die Frage verstehen soll.
Es handelt sich um eine Windows Installation.
Ich habe den Titel des Threads jetzt mal angepasst.
-
Jetzt habe ich noch mal ein wenig herumexperimentiert:
- Win10 neu aufgesetzt
- ioBroker mit dem Installer 1.5.14b installiert
- js-controller auf die 2.x aktualisiert (war noch 1.x)
- ioBroker läuft
- Backup des Basissytems
- Restore von meinem Produktivsystem
- ioBroker host this (mit Erfolgs-Rückmeldungen)
- Neustart der Maschine
- iobroker list instances (keine Instanz aktiv - nirgends ein "+")
- immer noch kein Zugriff auf die Admin-Webseite
Dann der Versuch, das ursprünglich installierte Basissystem wieder zu aktivieren:
- Restore des ursprünglich installierten Basissystems
- weiterhin kein Zugriff (Tests und Zwischenschritte spare ich mir hier)
Und um dem Verdacht vorzubeugen, der Backup könnte korrupt gewesen sein:
Ich habe einen Snapshot meines Produktivsystems (Debian 9.x) gemacht und dann den oben verwendeten backup restored. Mit Erfolg!Sollte jemand Interesse daran haben, die Ursache(n) der geschilderten Probleme mit meiner Hilfe zu analysieren, stehe ich zur Verfügung.
Angesichts der Tatsache, dass dieser und auch andere meiner Threads bzgl. Windows-Installation letztendlich oder gar schon mit dem Eröffnungsbeitrag ins Leere laufen endet aber ansonsten nun erst mal mein Ausflug in die ioBroker-Windows-Welt.
Als erfahrener Windows-Anwender der ersten Stunde hatte ich gehofft, das "malen nach Zahlen", das für mich in LINUX-Umgebungen leider immer noch die Regel ist, hinter mir zu lassen. Ich bin jetzt nicht enttäuscht. Ich habe ein Stück weit Erfahrung gesammelt und werde mich nun eben weiter in die LINUX-Welt reinfuchsen.
Alles Gut!
@hmanfred sagte in Windows: Nach Restore kein Zugriff auf WebUi:
Produktivsystems (Debian 9.x)
du schriebst aber von debian?
-
@hmanfred sagte in Windows: Nach Restore kein Zugriff auf WebUi:
Produktivsystems (Debian 9.x)
du schriebst aber von debian?
@simatec
Ich schrieb ausführlich von meinen Test mit erfolglosem restore eines backups auf die Windows Maschine.Damit dann aber keiner sagt "das backup ist sicher kaputt gewesen", habe ich geschrieben (jetzt anders und vllt. verständlicher formuliert):
"Ich habe ein Produktivsystem mit Debian. Darauf habe ich das (mit Windows) verwendete Backup eingespielt, um zu beweisen, dass es nicht kaputt ist.
Um Sicher zu gehen, habe ich vorher natürlich ein Snapshot des Produktivsystem erstellt." -
@simatec
Ich schrieb ausführlich von meinen Test mit erfolglosem restore eines backups auf die Windows Maschine.Damit dann aber keiner sagt "das backup ist sicher kaputt gewesen", habe ich geschrieben (jetzt anders und vllt. verständlicher formuliert):
"Ich habe ein Produktivsystem mit Debian. Darauf habe ich das (mit Windows) verwendete Backup eingespielt, um zu beweisen, dass es nicht kaputt ist.
Um Sicher zu gehen, habe ich vorher natürlich ein Snapshot des Produktivsystem erstellt." -
@hmanfred
Und dein backup wurde unter Windows erstellt?
Welche js-controller Version hat das backup?@simatec
Das verwendete Backup stammte aus dem Produktivsystem.Testsystem: WIN10 js-controller 2.2.9
Produktivsystem: Debian js-controller 2.2.10Kann es an diesem Unterschied gelegen haben?
Falls ja: warum hat dann das erneute Restore des vorher an der jungfräulichen WIN Installation erstellten Backups das Problem nicht behoben?
-
@simatec
Das verwendete Backup stammte aus dem Produktivsystem.Testsystem: WIN10 js-controller 2.2.9
Produktivsystem: Debian js-controller 2.2.10Kann es an diesem Unterschied gelegen haben?
Falls ja: warum hat dann das erneute Restore des vorher an der jungfräulichen WIN Installation erstellten Backups das Problem nicht behoben?
@hmanfred
Genau das sage ich doch die ganze Zeit.
Dein Backup welches du auf deinem WIN System restoren willst, kommt von debian.
Wenn du dort die objects über redis laufen hast, liegt genau hier dein Problem.
Darum die Frage nach Redis. -
@hmanfred
Genau das sage ich doch die ganze Zeit.
Dein Backup welches du auf deinem WIN System restoren willst, kommt von debian.
Wenn du dort die objects über redis laufen hast, liegt genau hier dein Problem.
Darum die Frage nach Redis. -
@hmanfred
Zeige doch mal bitte, was du auf deinem Produktivsystem in „iobroker setup custom “ eingestellt hastÄäähm... wo finde ich das?
Auch nach Umstellung auf Systemsprache Englisch finde ich diese Begriffkombination nirgends.
Edit:
Durch die Forumssuche habe ich nun herausgefunden, dass es den Konsolenbefehl "iobroker setup custom" gibt.
Ergebnis:Current configuration: - Objects database: - Type: file - Host/Unix Socket: 127.0.0.1 - Port: 9001 - States database: - Type: file - Host/Unix Socket: 127.0.0.1 - Port: 9000 - Data Directory: ../../iobroker-data/ -
Ääähm... wo finde ich das?
Auch nach Umstellung auf Systemsprache Englisch finde ich diese Begriffkombination nirgends.
Edit:
Durch die Forumssuche habe ich nun herausgefunden, dass es den Konsolenbefehl "iobroker setup custom" gibt.
Ergebnis:Current configuration: - Objects database: - Type: file - Host/Unix Socket: 127.0.0.1 - Port: 9001 - States database: - Type: file - Host/Unix Socket: 127.0.0.1 - Port: 9000 - Data Directory: ../../iobroker-data/@hmanfred sagte in Windows: Nach Restore kein Zugriff auf WebUi:
Ääähm... wo finde ich das?
Auch nach Umstellung auf Systemsprache Englisch finde ich diese Begriffkombination nirgends.
Edit:
Durch die Forumssuche habe ich nun herausgefunden, dass es den Konsolenbefehl "iobroker setup custom" gibt.
Ergebnis:Current configuration: - Objects database: - Type: file - Host/Unix Socket: 127.0.0.1 - Port: 9001 - States database: - Type: file - Host/Unix Socket: 127.0.0.1 - Port: 9000 - Data Directory: ../../iobroker-data/Ist dies die Config deines Produktivsystems?
-
@hmanfred sagte in Windows: Nach Restore kein Zugriff auf WebUi:
Ääähm... wo finde ich das?
Auch nach Umstellung auf Systemsprache Englisch finde ich diese Begriffkombination nirgends.
Edit:
Durch die Forumssuche habe ich nun herausgefunden, dass es den Konsolenbefehl "iobroker setup custom" gibt.
Ergebnis:Current configuration: - Objects database: - Type: file - Host/Unix Socket: 127.0.0.1 - Port: 9001 - States database: - Type: file - Host/Unix Socket: 127.0.0.1 - Port: 9000 - Data Directory: ../../iobroker-data/Ist dies die Config deines Produktivsystems?
-
@simatec
Ja, das ist die Konfig meines Produktivsystems.Das ist die Konfig des Systems (mein Produktivsystem, laufend unter DEBIAN 9.x), aus dem das verwendete Backup stammt.
-
@hmanfred
Dann poste noch mal bitte die Ausgabe „iobroker list instances“ von deinem Testsystem und die Logdatei -
Neue Erkenntnis:
nach einem "iobroker start admin.0" läuft die admin Instanz und ich komme auf die Weboberfläche!
Gerade läuft ein Neustart der Maschine...
...weiter geht's:
ioBroker Dienst läuft zwar laut Computerverwaltung-Dienste. Aber "iobroker status" sagt "iobroker is not running on this host.".
Also erst mal "iobroker stop" und "iobroker start". Wird dann die nächste Baustelle...Jetzt wurde die Admin Instanz auch gestartet, ich komme aufs Webinterface.
Dieses Problem ist also gelöst mit der Erkenntnis, dass nach einem restore (zumindest bei mir) die admin Instanz erst mal manuell gestartet werden muss.
Wenn's das war (wirklich?) bleibt die Frage: warum wird ioBroker nicht gestartet obwohl laut Computerverwaltung-Dienste der Dienst läuft?
-
@hmanfred
Und unter http://192.168.1.21:8081 ist admin nicht errechbar? Laut log werden gerade alle Adapter nach und nach installiertEdit: Hatte deinen letzten Beitrag zu spät gesehen.
Du könntest in backitup den Hacken setzen, dass nach dem restore alle Adapter gestartet werden sollen.
Dies kann allerdings bei einigen Adaptern erstmal zum error führen. -
@hmanfred
Und unter http://192.168.1.21:8081 ist admin nicht errechbar? Laut log werden gerade alle Adapter nach und nach installiertEdit: Hatte deinen letzten Beitrag zu spät gesehen.
Du könntest in backitup den Hacken setzen, dass nach dem restore alle Adapter gestartet werden sollen.
Dies kann allerdings bei einigen Adaptern erstmal zum error führen.@simatec
Nach einem erneuten Start der Maschine und etwas warten (hatte gesehen, dass der Dienst auf "verzögerter Start" konfiguriert ist, läuft erst mal alles wie es soll.Herzlichen Dank! Du hast mich letztendlich auf den richtigen Weg geführt.
Eine Enttäuschung habe ich dann aber doch noch erlebt:
ich wollte mit dieser Testinstallation unter anderem diesem Problem auf die Spur zu kommen.
Leider ohne Erfolg. Auch mit der Windows-Installation ist das Problem nach Einspielen des Backups vorhanden.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden