#dusk $PORTAL ist heute in Flammen originally dachte ich, dass ein Upgrade eines Nodes bei @Dusk bedeutet, dass man das Binary ersetzt und die gleiche Maschine mit der gleichen Rolle neu startet.

eine Warnung im Operator-Guide hat mich da umdenken lassen.

@Dusk_Foundation s Installer bewahrt Consensus-Keys, den Chain-Status und die ausgewählte Service-Konfiguration. Aber er erzeugt ganz bewusst Dateien wie rusk.toml, genesis.toml und die Rusk-systemd-Unit neu.

Am wichtigsten ist jedoch: Der Operator muss die bestehenden Netzwerk- und Feature-Flags des Nodes wiederholen. wait let me book my profit in $CYS

Wenn ein Archiv-Operator den Installer erneut ausführt, ohne "--feature archive", wird die Installation durch das Standard-Rusk-Binary ersetzt. Die Maschine kann möglicherweise weiterhin laufen, sich mit Peers verbinden und die Blockhöhe vorantreiben, aber sie bietet dann nicht mehr die Archiv-Funktionalität, auf die die Anwendungen angewiesen waren.

das ist der Teil, der hängen blieb.

Dusk reduziert das Upgrade-Risiko, indem es Ersatz-Binaries herunterlädt und verifiziert, bevor Rusk gestoppt wird. Außerdem lässt es den Service danach gestoppt, damit der Operator die erzeugte Konfiguration prüfen kann, bevor er ihn wieder online bringt.

Aber Automatisierung kann nicht entscheiden, welche alten benutzerdefinierten Einstellungen weiterhin gültig sind. Dusk warnt Operatoren ausdrücklich, die vorherige rusk.toml zu vergleichen und nur die Einstellungen erneut anzuwenden, die sie noch brauchen—nicht die gesamte alte Datei in die neue Konfiguration zu kopieren.

Eine erfolgreiche Installation ist also nicht das Gleiche wie ein korrekt wiederhergestellter Service.

Macht das Neugenerieren der Konfiguration Dusk-Node-Upgrades sauberer und sicherer, oder ist das Erhalten der vorgesehenen Rolle des Nodes der wichtigste Operator-Check??

#dusk @Dusk k $DUSK

Was ist nach einem Dusk-Node-Upgrade am wichtigsten?