#dusk $PORTAL está en llamas hoy; originalmente pensé que actualizar un nodo en @Dusk significaba reemplazar el binario y reiniciar la misma máquina con el mismo rol.

una advertencia en la guía del operador me hizo replanteármelo.

@Dusk s el instalador conserva las claves de consenso, el estado de la cadena y la configuración de servicio seleccionada. Pero deliberadamente regenera archivos como rusk.toml, genesis.toml y la unidad systemd de Rusk.

Más importante aún, el operador tiene que repetir las flags de red y de características existentes del nodo. espera, déjame reservar mi ganancia en $CYS

Si un operador de archivos vuelve a ejecutar el instalador sin "--feature archive", la instalación se reemplaza con el binario Rusk predeterminado. La máquina aún puede seguir funcionando, conectarse a pares y avanzar en la altura de bloque, pero ya no proporciona la funcionalidad de archivo en la que dependían las aplicaciones.

esa es la parte que se me quedó.

Dusk reduce el riesgo de actualización descargando y verificando los binarios de reemplazo antes de detener Rusk. También deja el servicio detenido después para que el operador pueda revisar la configuración generada antes de volver a ponerlo en línea.

Pero la automatización no puede decidir qué ajustes personalizados antiguos siguen siendo válidos. Dusk advierte específicamente a los operadores que comparen el rusk.toml anterior y repliquen solo los ajustes que todavía necesitan, no copiar el archivo antiguo completo sobre la nueva configuración.

Así que una instalación exitosa no es lo mismo que un servicio restaurado correctamente.

¿Regenerar la configuración hace que las actualizaciones de nodos de Dusk sean más limpias y seguras, o hace que conservar el rol previsto del nodo sea la comprobación más importante del operador??

#dusk @Dusk k $DUSK

¿Qué es lo más importante después de una actualización de un nodo de Dusk?