ioBroker Node Red palettenmanager fehlt
-
@haus-automatisierung sagte in ioBroker Node Red palettenmanager fehlt:
Achso? Da muss ich mir mal anschauen, was da genau für Dateien angelegt werden.
Nein mit dem neuen Backup werden diese Verzeichnisse mitgesichert - in meinen Augen insofern kein Handlungsbedarf.
Das ist auch nicht festgelegt, da jede Node selbst ein Verzeichnis für Filekonext erstellen kann.
Hier nur mal ein Beispiel meiner NodeRed Instanz - wobei ich jetzt nicht jedes Verzeichnis sagen kann, ist auch auf keines verzichtbar.
lib - enthält die in der lokalen Bibliothek gespeicherten Flows
cronplusdata - enthält Konfigurationen der cronplus node
homekit-persist - enthält die yahka entsprechenden Nodesaber wie gesagt - alles wird über die eigene NodeRed Sicherung mitgesichert und es sollten auch alle Verzeichnisse gesichert werden.
-
@haus-automatisierung sagte in ioBroker Node Red palettenmanager fehlt:
Kann doch aber über die Instanzkonfiguration wieder aktiviert werden? Mit 5.1.0 funktioniert das bei mir jedenfalls:
Ja ist doch auch gut - es geht ja nur über die Warnmeldung, die den Threadersteller verunsichert hat.
-
@haus-automatisierung sagte in ioBroker Node Red palettenmanager fehlt:
Das ist ja bei jedem Adapter so (History, SQL, ...). Zumindest wäre es nicht unbedingt "best practice" wenn eine Instanz die Einstellungen einer anderen ändert (habe ich so zumindest noch nirgendwo gesehen).
Müsste ja nicht sein, wenn die NodeRed Sicherung bei Installation des Adapters diese automatisch ausführt. Aber egal - wie gesagt, ich will mich da nicht einmischen.
-
@mickym sagte in ioBroker Node Red palettenmanager fehlt:
@haus-automatisierung sagte in ioBroker Node Red palettenmanager fehlt:
Hier nur mal ein Beispiel meiner NodeRed Instanz
Interessant, auch wenn es jetzt noch weiter OT geht: Die erste NodeRed Instanz wird im Ordner
/opt/iobroker/iobroker-data/node-red/, die zweite Instanz im Ordner
/opt/iobroker/iobroker-data/node-red.1angelegt. Ein Restore der ersten Instanz wird wiederum in Ordner
/opt/iobroker/iobroker-data/node-red.0erstellt. Auf einem frischen System hat die Wiederherstellung deshalb bei mir nicht funktioniert. Ich musste die Dateien erst umkopieren. Ich würde ein Issue aufmachen, aber wo liegt der Fehler? Node-Red oder Backitup?
-
@marc-berg Ja habe ich auch schon festgestellt - Umbennen der node-red.0 Verzeichnisses hätte auch funktioniert.
Das Problem mit den Instanz Nummern kam erst mit der Adapter-Version 4 glaub dazu - da vorher waren nicht mehrere Instanzen möglich.
-
@marc-berg sagte in ioBroker Node Red palettenmanager fehlt:
Ich würde ein Issue aufmachen, aber wo liegt der Fehler? Node-Red oder Backitup?
Aus irgend einem Grund wurde damals im Node-RED-Adapter bei der ersten Instanz die Nummer nicht angehangen. Das ist schon ewig so. Wahrscheinlich, weil mal nur eine erlaubt wurde (?).
Ob das eine schlaue Entscheidung war? Wahrscheinlich eher nicht. Dennoch sollte sich der Backitup-Adapter auch an diese Ausnahme halten.
-
@haus-automatisierung sagte in ioBroker Node Red palettenmanager fehlt:
Dennoch sollte sich der Backitup-Adapter auch an diese Ausnahme halten.
Verstehe. Nicht schön, aber die Alternative wäre wahrscheinlich kaum umsetzbar.
-
@mickym sagte in ioBroker Node Red palettenmanager fehlt:
Es fehlt lediglich das letzte npm install im Node-Red Datenverzeichnis der jeweiligen Instanz. Keine Ahnung, ob das inzwischen mit beim Restore ausgeführt wird oder nicht.
Nö, wird nicht. Es kommt aber ein Hinweis (der im Moment natürlich im falschen Pfad ins Leere läuft)
[DEBUG] [nodered] - Node-Red Restore completed successfully [DEBUG] [nodered] - To complete the restore, please run an "npm install" in the path "/opt/iobroker/iobroker-data/node-red.0". -
@marc-berg sagte in ioBroker Node Red palettenmanager fehlt:
Nicht schön, aber die Alternative wäre wahrscheinlich kaum umsetzbar.
Die Alternative wäre ja noch komplizierter. Wenn man jetzt im Node-RED-Adapter ein Upgrade-Script baut, welches ab 5.2.0 oder so alles in
node-red.0speichert, dann müsste der Backitup-Adapter ja schauen, welche Adapter-Version das war und entweder das eine oder das andere Verzeichnis wiederherstellen.Aktuell ist die Regel ja klar: Falls
node-red.0, dannnode-red. -
@haus-automatisierung sagte in ioBroker Node Red palettenmanager fehlt:
Die Alternative wäre ja noch komplizierter.
Äh, ja. Das meinte ich mit "kaum umsetzbar".
-
@marc-berg Aber immerhin geht das jetzt alles - vor einem halben Jahr hattest du, wenn Du den Paletten-Manager verwendet hast, gar keine Chance gehabt, Dein System wiederherzustellen - bzw. hättest Node-Typ für Node-Typ nachinstallieren müssen.
-
@marc-berg In v2.9.10 von Backitup habe ich die Instanz 0 gefixt und einen automatischen
npm installeingebaut.
Aufgrund fehlender node-red Installation würde ich dich bitten, das mal zu testen.Sollte heute Nacht ins latest kommen, oder halt über Github
-
@simatec sagte in ioBroker Node Red palettenmanager fehlt:
Aufgrund fehlender node-red Installation würde ich dich bitten, das mal zu testen.
Die Wiederherstellung erfolgt jetzt im korrekten Verzeichnis und
npm installwird ausgeführt.
Wenn ich allerdings von einem jungfräulichen ioB System ausgehe und nur die Node-Red Sicherung wiederherstelle, so können die Credentials nicht entschlüsselt werden. (Node-Red Adapter Version Quelle+Ziel jeweils 5.1.0)
Die Frage ist, ob dies ein sinnvoller Use Case ist und betrachtet werden müsste?
-
Hallo
Habe ioBroker neu installiert.
Jetzt geht auch in Node-red der Palettenmanager.
Vielen Dank unf einen Guten Rutsch ins neue Jahr- -
@marc-berg Müsste man mal schauen, was Backitup da noch machen kann... Wie sieht der händische Weg aus, um die Credentials richtig zu setzen?
-
@simatec sagte in ioBroker Node Red palettenmanager fehlt:
Wie sieht der händische Weg aus, um die Credentials richtig zu setzen?
Keine Ahnung, da muss ich auf @haus-automatisierung und @mickym verweisen.
-
Normalerweise sollte das mit den Credentials gar nicht mehr passieren, da glaub das konstant vom iobroker in der settings.js gesetzt wird. Es gab nur mal ein Problem mit der Version 5.0.1 wegen Hochkomma. Wenn Du da keinen Zahlendreher, wegen der Version drin hast, dann sollte es kein Problem mit den Credentials geben, ansonsten kann ich hier nicht weiterhelfen. Ich gehe mal davon aus, dass der String mit dem verschlüsselt wird, konstant ist und irgendwo in der Adapterkonfiguration steckt, die man aber selbst nicht beeinflussen kann.
Keine Ahnung wo und ob man die Adapterkonfig auslesen kann.
/** By default, credentials are encrypted in storage using a generated key. To * specify your own secret, set the following property. * If you want to disable encryption of credentials, set this property to false. * Note: once you set this property, do not change it - doing so will prevent * node-red from being able to decrypt your existing credentials and they will be * lost. */ credentialSecret: "'%%credentialSecret%%'", -
@marc-berg sagte in ioBroker Node Red palettenmanager fehlt:
Wenn ich allerdings von einem jungfräulichen ioB System ausgehe und nur die Node-Red Sicherung wiederherstelle, so können die Credentials nicht entschlüsselt werden.
Ja, weil als Schlüssel das Secret aus
system.configgenutzt wird: -
@haus-automatisierung sagte in ioBroker Node Red palettenmanager fehlt:
Ja, weil als Schlüssel das Secret aus
system.configgenutzt wird:Okay. Dann würde ich dafür plädieren, alles zu lassen wie es jetzt (mit Backitup Version 2.9.10) ist. Ein Node-Red Backup kann nun ohne Nacharbeiten wiederhergestellt werden. Und wenn der (eher theoretische?) Fall eintritt, dass man eine Sicherung auf ein jungfräuliches oder Fremdsystem einspielen möchte, muss man die Credentials halt neu eingeben.
