Mantén el nodo en marcha

El nodo se actualiza solo y vigila su propia salud. Tu administrador mantiene al día Ubuntu y su kernel, y puede elegir el momento en que se actualizan Incus y cloudflared.

Compruébalo con doctor

sudo detachbox-node-host doctor

doctor comprueba el nodo de punta a punta y no cambia nada. Cada comprobación tiene 20 segundos e imprime su línea al terminar:

que detachbox sigue aceptando el token del nodo, node-host y su versión, y la última respuesta del servidor;
las conexiones del túnel con Cloudflare y el camino de vuelta por él, hasta node-host y hasta el gateway de terminales;
HTTPS y TLS salientes hacia api.detachbox.com;
Incus y su retención en apt, y si esperan versiones más nuevas de Incus o cloudflared;
el módulo ZFS cargado ahora y el que cargará el próximo kernel, la deduplicación, la salud del pool y lo lleno que está;
tus redes privadas frente al firewall de los terminales;
la imagen base y cuándo empezó su última construcción.

Cada ✗ viene con su solución. Una parte que se cuelga, como Incus o ZFS, muestra … within 20 s en su línea ✗, y las comprobaciones siguientes de esa parte muestran not checked: … did not answer above en lugar de esperar. Un … marca lo que no hace fallar la comprobación: lo que aún no se puede saber, como la primera respuesta del servidor en los minutos después de reiniciar node-host, o una actualización que espera. La línea de actualizaciones muestra ✓ Updates Incus <version>, cloudflared <version>: the newest builds apt knows of, o … Updates not yet: …; <build> waits: sudo detachbox-node-host upgrade installs it (node-host does on a day no terminal runs).

sudo detachbox-node-host doctor --report envía el resultado a detachbox, y tu contacto en detachbox ve lo mismo que tú.

Lo que se actualiza solo

node-host se actualiza solo a los pocos minutos de cada versión de detachbox. Solo instala lo que firmó la clave de versiones de detachbox, y vuelve a poner la versión anterior si la nueva no arranca.
La imagen base de tus terminales se reconstruye cada 6 horas con las actualizaciones de Ubuntu y las últimas versiones de Claude Code, Codex y OpenCode. Solo entra en servicio tras una prueba de humo; una construcción que falla deja la última buena en su sitio. Los terminales en marcha conservan la imagen con la que arrancaron, y un terminal nuevo o reiniciado recibe la actual.

Incus y cloudflared

Los dos se quedan retenidos en apt, y la retención no se quita nunca: tu propio apt upgrade no los toca. Reiniciar cloudflared corta una vez todas las conexiones que pasan por el túnel del nodo (pestañas de terminal, vistas previas, subidas), y reiniciar Incus corta las conexiones de las pestañas de terminal abiertas. En los dos casos se reconectan solas en segundos, y los terminales siguen en marcha con sus sesiones tmux, sus agentes y todos sus procesos. Un terminal que se inicia o se detiene en esos segundos falla una vez y funciona al pedirlo de nuevo, y una construcción de la imagen base que esté en curso falla y se vuelve a construir en menos de 6 horas. Por eso solo se actualizan en el momento que tú elijas, o un día en que no corra ningún terminal.

sudo detachbox-node-host upgrade --check      # consulta los repositorios de los dos fabricantes; nada cambia
sudo detachbox-node-host upgrade              # dice qué hay más nuevo y qué les pasa a los terminales, pregunta [y/N]
sudo detachbox-node-host upgrade --confirm    # actualiza sin preguntar

upgrade lista lo que hay más nuevo, cuántos terminales corren y qué les hacen los reinicios, y después pregunta. Si se ejecuta sin un terminal en el que preguntar, se niega y nombra --confirm. En cuanto los paquetes empiezan a instalarse, la actualización llega hasta el final pase lo que pase con tu sesión; sudo tail -f /var/lib/detachbox-node/install/install.log la sigue. Termina con doctor y ✓ Upgraded: …, tras más o menos un minuto en nuestro nodo de pruebas.

node-host intenta esa misma actualización una vez al día, la primera vez 15 minutos después de arrancar, y solo cuando no corre nada más que el edge: ningún terminal ni ninguna construcción de la imagen base. Si hay un terminal en marcha, anota en su log que la actualización espera y lo vuelve a intentar un día después. Un nodo donde siempre corre algún terminal nunca se actualiza solo: doctor sigue mostrando la actualización hasta que ejecutes upgrade.

Actualizaciones del kernel

Ubuntu y su kernel los actualizas tú. Instala cada kernel nuevo con su linux-headers, y DKMS compila para él el ZFS 2.4.4 del nodo por su cuenta; en nuestro nodo de pruebas tardó unos 4 minutos. Después doctor muestra una línea ZFS for <kernel> para el kernel en ejecución y otra para el kernel instalado más nuevo, el que carga el próximo arranque. Las dos tienen que mostrar ✓ antes de reiniciar; tras reiniciar con el kernel nuevo, el nodo vuelve solo.

Si alguna vez un kernel arranca sin el ZFS del nodo, node-host desactiva la deduplicación antes de que un terminal escriba un solo byte, y lo dice en doctor y a detachbox. Vuelve a activarla en el primer arranque con un módulo arreglado.

Reinicios

Un reinicio detiene los procesos en marcha y las sesiones tmux. node-host y el túnel arrancan con el servidor, y tus terminales vuelven solos con sus archivos, paquetes apt e imágenes Docker en su sitio; los contenedores Docker con una política restart: arrancan de nuevo. Cada agente vuelve solo a su última conversación y espera a su ingeniero. Uno que no haya vuelto arranca ahí de nuevo con Reiniciar el terminal en esta conversación.

Cuando el nodo se desconecta

Un minuto después de que el nodo deje de responder, el panel muestra Nodo desconectado desde 14:02 en la barra superior y en la página Compute, y un terminal abierto avisa de que se reconecta solo en cuanto el nodo vuelva. Los archivos siguen en el servidor. Tras 10 minutos de silencio, la cuenta dueña del nodo recibe un correo, que indica la hora y remite a sudo detachbox-node-host doctor, y otro cuando el nodo vuelve a responder. Un reinicio o una actualización de node-host nunca tarda tanto.

Más núcleos o memoria

Añádelos al servidor y avisa a tu contacto en detachbox. node-host informa a detachbox de los núcleos, la memoria y el pool del servidor, y tu contacto aplica el nuevo tamaño; nada cambia por sí solo. El Compute en marcha toma el nuevo tamaño sin reiniciar, y Actividad lo registra.

Cuando detachbox retira el nodo

Si se cancela el registro de tu nodo, doctor lo dice en una línea, «✗ Account taken off», con lo que hay que hacer: sudo detachbox-node-host uninstall --confirm, o, si no te lo esperabas, envía esa línea a tu contacto en detachbox. Hasta entonces node-host se queda en silencio, con el túnel y el edge tal como están, y pregunta a detachbox cada 15 minutos, así que un nodo rechazado por error vuelve en ese plazo. Un rechazo que no llega con las palabras del servidor de detachbox, como un proxy que pide su propio inicio de sesión, no significa que hayan retirado el nodo: doctor lo dice en la línea Account. Deja pasar el nodo por ese proxy sin inicio de sesión, o envía la línea a tu contacto en detachbox.