Neues Release. Stoppe den Node. Ersetze die Binaries. Und dann herausfinden, ob das, was du heruntergeladen hast, tatsächlich auch richtig war.
So eine Wartungsroutine hatte ich erwartet, die Dusk-Operatoren einfach sorgfältig im Griff haben müssen. Aber der neueste Ablauf des Node-Installers hat eine Kleinigkeit geändert, die meiner Meinung nach wichtiger ist, als sie klingt. Version 0.5.22 hat Upgrades so gehärtet, dass Ersatz-Artefakte zwischengestapelt und verifiziert werden, bevor die Live-Dateien ersetzt werden. Dusk’ Upgrade-Verfahren folgt derselben Reihenfolge: Der Installer lädt die unterstützten Rusk- und Wallet-Binaries herunter, prüft sie und erst dann stoppt er den laufenden Rusk-Dienst. Außerdem bewahrt es den Chain-Status des Operators, die Consensus-Keys und die beabsichtigten Service-Overrides auf, statt ein Upgrade wie eine frische Node-Installation zu behandeln. Der Dienst bleibt danach gestoppt, sodass der Operator die neu generierte Konfiguration überprüfen, Rusk gezielt starten und bestätigen kann, dass Peers und Block-Height-Fortschritt stimmen, bevor er den Job als abgeschlossen meldet.
Das ist ein kleines, aber nützliches operatives Meilenstein.
Das Upgrade-Fenster beginnt jetzt, nachdem der Ersatz bereit ist—nicht während der Operator noch herausfindet, ob er überhaupt verwendbar ist.
Für Infrastruktur, die verfügbar bleiben soll, ist diese Reihenfolge mehr wert als ein weiterer bequemer Befehl.
@Dusk_Foundation $DUSK #dusk
So eine Wartungsroutine hatte ich erwartet, die Dusk-Operatoren einfach sorgfältig im Griff haben müssen. Aber der neueste Ablauf des Node-Installers hat eine Kleinigkeit geändert, die meiner Meinung nach wichtiger ist, als sie klingt. Version 0.5.22 hat Upgrades so gehärtet, dass Ersatz-Artefakte zwischengestapelt und verifiziert werden, bevor die Live-Dateien ersetzt werden. Dusk’ Upgrade-Verfahren folgt derselben Reihenfolge: Der Installer lädt die unterstützten Rusk- und Wallet-Binaries herunter, prüft sie und erst dann stoppt er den laufenden Rusk-Dienst. Außerdem bewahrt es den Chain-Status des Operators, die Consensus-Keys und die beabsichtigten Service-Overrides auf, statt ein Upgrade wie eine frische Node-Installation zu behandeln. Der Dienst bleibt danach gestoppt, sodass der Operator die neu generierte Konfiguration überprüfen, Rusk gezielt starten und bestätigen kann, dass Peers und Block-Height-Fortschritt stimmen, bevor er den Job als abgeschlossen meldet.
Das ist ein kleines, aber nützliches operatives Meilenstein.
Das Upgrade-Fenster beginnt jetzt, nachdem der Ersatz bereit ist—nicht während der Operator noch herausfindet, ob er überhaupt verwendbar ist.
Für Infrastruktur, die verfügbar bleiben soll, ist diese Reihenfolge mehr wert als ein weiterer bequemer Befehl.
@Dusk_Foundation $DUSK #dusk