takana/docs/28-servidor-de-produccion.md

SDD 28 — El servidor de producción: instalar takana puro en una caja remota y mudarse a ella

Escrito 2026-09-09 a pedido del usuario («qué tan lejos estamos de montar un server takana en Hetzner y que sea producción, y mover allá todo lo que tengo acá, y de una vez mantenerlo por repo takana»). Todo número marcado (medido) salió de un comando corrido ese día sobre gioser.

Continúa SDD 19 (lanzamiento público) y SDD 27 (metapaquetes e instalador). No repite el instalador: SDD 27 decide QUÉ se instala y con qué verbo; esto decide DÓNDE, y cómo se llega.

---

0. La corrección de encuadre: ya estamos en Hetzner

gioser es un servidor Hetzner (hcloud id 126324694, hel1, 4 cores / 7,6 GiB) (medido). La pregunta no era «cómo llegar a Hetzner» sino cómo tener una caja de takana en vez de ser un inquilino más de una máquina compartida que:

• sirve 19 dominios por Caddy,
• tiene /mnt/vvv al 89 % (27 G libres) (medido),
• es fija y sin backup por pedido explícito del usuario (blindaje anti-borrado en deadman.sh y farm-down.sh, ver ADR 0014 y la memoria del proyecto),
• y no publica nada de takana: cero entradas de takana en el Caddyfile (medido).

0.1 El hallazgo que cambia el tamaño del problema

$ ps -p 1 -o comm=,args=
arje-zero  /usr/local/sbin/arje-zero
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-linux root=UUID=54de62df-… rw net.ifnames=0 splash \
  init=/usr/local/sbin/arje-zero loglevel=4

El init de takana ya gobierna un servidor de producción real. Caddy, gitea, sshd, qdrant y act-runner cuelgan directo de PID 1 (medido: ps -eo pid,ppid,comm | awk '$2==1').

Pero eso no es takana puro: es Artix con nuestro init inyectado por init= en el cmdline. El kernel, la libc y los 19 servicios son ajenos. Se probó la mitad difícil sobre userland prestado.

0.2 ⚠ La declaración del arranque no existe en ningún sitio legible

rc-status de OpenRC dice stopped para caddy, gitea, sshd, cronie y act-runner, y los cinco están vivos (medido, los dos comandos). /etc/arje/cards.d tiene 4 tarjetas (acpid, openrc-openclaw, squid, zram-swap) y ninguna de ellas los levanta.

⇒ La secuencia de arranque de esta caja no está escrita. Es lo menos reproducible de toda la mudanza y lo primero que hay que capturar — ver §4.

---

1. Inventario de lo que hay que mudar (medido 2026-09-09)

Datos en /mnt/vvv (217 G de 255)

tawasuyu	124 G
takana	91 G — incluye el store de 55 G bind-mounteado desde el otro volumen ⇒ ~36 G propios
rustup	29 G
act-runner · gioserv · _respaldo	6,5 · 5,4 · 4,1 G
~20 dirs *-standalone	agora, card, chasqui, cosmos, dominium, khipu, minga, mirada, nakui, nahual, pata, pineal, pluma, shuma, takiy, llimphi…

El volumen harkaq-cosecha (250 G, 148 G usados)

store	55 G, 1327 artefactos — lo irreemplazable
work-sources + cargo-home + gopath	~85 G — caché regenerable, no se muda
work-tarballs · devfs-cache · work-out	3,2 G · 4,5 G · 397 M

El store no se copia por red. Los dos volúmenes están en hel1; un volumen hcloud se desengancha de una caja y se engancha a otra en la misma ubicación. La mudanza del store son dos comandos.

Servicios vivos, todos hijos de arje-zero

caddy :80/:443 · gitea :3002 · sshd :2345 · act_runner (el CI de tawasuyu) · qdrant :6333/:6334 · openclaw · zeroclaw · shuma-gateway :7378 · tejido :4102 y :33097 · puerta-f6e393ff · uvicorn :8771 · python3 :8770 · squid :1137 · fail2ban · glances · php-fpm · metalog · adb :5037.

Lo que no está en ningún repo

/var/lib/gitea (2,2 G: SQLite + los repos de git de todo, incluido el origin de takana) · /var/www (287 M) · /home/sergio/gioser-web/ · /etc/caddy/Caddyfile + 20 ficheros .bak · los certificados de letsencrypt · los crontabs · /etc/arje/cards.d · las 3 credenciales de ~/.config/hammer/*.env · las llaves ~/.ssh/{github5,sergio} · el token hcloud · y la memoria del agente en ~/.claude/.

1.1 La basura, contada — porque una mudanza fiel copia también la basura

De los 19 dominios del Caddyfile (probados uno por uno desde la propia caja):

responden 200	rotos
gioser.net · tawasuyu.net · git.gioser.net · summa.gioser.net · sergio.gioser.net	api.gioser.net → 502 (backend caído)
	aura · sigma · kosmofono · terapeuta.ec → sin DNS

Y sus raíces no existen en disco: /var/www sólo tiene terapeuta, goaccess, ogisoer, git-tawasuyu, letsencrypt y un .bak — no hay aura_frontend, ni sigma, ni summa/frontend, ni kosmofono. La mitad del Caddyfile describe un servidor que ya no existe.

⇒ Regla de la mudanza: no se muda lo que no responde. Lo que no tiene DNS ni ficheros se anota y se deja morir con la caja vieja. La utilidad del §4 tiene que saber decir declarado / vivo / fósil.

---

2. La caja: qué, cuánto y por qué

Precios consultados a la API de hcloud el 2026-09-09 (hel1, x86, tipos no deprecados) (medido):

tipo	recursos	€/mes
cx53	16 c / 32 G / 320 G	29,49
cpx41	8 c / 16 G / 240 G	32,49
ccx23 (dedicado)	4 c / 16 G / 160 G	85,99

Elegido cx53: es el mejor punto de la tabla y entra holgado el conjunto tawasuyu + takana + rustup (~244 G) si algún día se muda todo.

Decisiones del usuario (2026-09-09):

1. La caja PUBLICA; el LXC prestado sigue moliendo. dev.gioser.net cuesta €0 y es la máquina con más RAM (6 c / 16 G + 8 G swap). Separar servir de compilar mantiene la caja chica y barata. La caja nueva puede además compilar, con el LXC enchufado como segundo worker.
2. «Producción» = operativo pero privado. Sin descarga pública todavía ⇒ no se activan los bloqueantes legales del SDD 19 §2 (espejo de fuentes público por HTTP, marca de terceros). Lo que sí hace falta igual es la clave de release estable (§5).
3. gioser se BORRA cuando la mudanza esté comprobada. Eso convierte esto en un experimento con fecha de caducidad, y cambia el diseño entero: ver §6.

⚠ El blindaje anti-borrado de gioser es deliberado y hay que levantarlo a mano y a propósito. deadman.sh y farm-down.sh lo protegen por lista negra de nombre y por ausencia del label role=hammer-worker. Ninguna automatización debe poder borrarlo: cuando llegue el día, se borra a mano, con la comprobación del §6 en verde y no antes.

---

3. Instalar takana puro en una caja remota

3.1 Lo que ya está, y por qué está más cerca de lo que parece

El dato que lo destraba: Hetzner Cloud arranca por BIOS, no por EFI. (medido en gioser: no existe /sys/firmware/efi; GPT + GRUB; /boot es vfat de 1 G.) Y scripts/takana-install.sh escribe exactamente ese layout: GPT + GRUB BIOS, SeaBIOS → GRUB → kernel → arje-zero PID1. El camino EFI —que fue el que más trabajo costó (ADR 0010)— es el que Hetzner no necesita.

pieza	estado (medido)
kernel con virtio	recipes/linux.toml compila VIRTIO, VIRTIO_PCI, VIRTIO_BLK, VIRTIO_NET, EXT4_FS =y ⇒ sin initramfs
red	crates/netup = cliente DHCPv4 propio en Rust sobre netlink, autodetecta interfaz y espera carrier. gioser toma su IP por DHCP en eth0 (/32, net.ifnames=0, DNS 185.12.64.2) ⇒ es justo su caso
acceso	recipes/openssh.toml sellado; el product-rootfs vigente ya trae sshd; takana-install.sh acepta AUTHKEYS
servir	recipes/caddy.toml existe
escritura a disco	scripts/takana-install.sh (no interactivo) y scripts/takana-live-install.sh (TUI), probado por scripts/install-tui-test.sh

3.2 El camino remoto: rescue → dd → reboot

Hetzner Cloud tiene un sistema de rescate (Debian por SSH) que se activa desde la API sin tocar la caja. Desde ahí se escribe la imagen al disco y se reinicia. No hace falta ISO, ni consola, ni medio físico — que es justo lo que hace innecesario el 90 % del trabajo de ISO/USB para este caso.

3.3 Los cuatro huecos, nombrados

1. perfil.servidor — HECHO hoy en docs/state/targets.toml. Ver §3.4.
2. console=ttyS0 en el cmdline — el único salvavidas si el arranque falla y no hay teclado. Hetzner da consola web; sin serial en el kernel, esa consola no muestra nada útil.
3. IPv6 — netup hace DHCPv4 y Hetzner entrega un /64 estático. La caja arrancaría con IPv4 sola. Aceptable para empezar, pero hay que saberlo antes, no descubrirlo.
4. Un .img del perfil servidor que el rescue pueda escribir. Es hydrate-profile.py + install-image.sh, los dos ya existentes — ver §7.

3.4 El perfil, y la deuda que declara (hecho 2026-09-09)

[perfil.servidor] hereda cli (que hereda base, SDD 27 §7.1) y añade 5 raíces que existen (openssh, caddy, curl, wget, tmux) y 5 que NO:

raíz que no resuelve	por qué está declarada igual
takana	el propio takana no tiene receta. El corpus construye 869 recetas y no la suya ⇒ el binario sólo existe como cargo build sobre un clon. Es EL bloqueante del §5
chrony	sin NTP, un reloj que deriva rompe TLS y las firmas — y falla diciendo «firma inválida», no «la hora»
nftables	dev.gioser.net está hoy expuesto con fuerza bruta a root en el journal; una caja nueva no debería nacer así
cronie	el latido son tres líneas de crontab, y sin systemd no hay timers: o hay cron, o el latido es una tarjeta de arje-zero. Decisión pendiente
logrotate	en una caja que sirve, el log de acceso crece hasta llenar el disco

Quedan wanted en el grafo, y wanted no es debt ⇒ drenaje.json seguirá diciendo deuda=0. Se declaran igual porque una deuda escrita se ve y una omitida no: sin ellas el perfil saldría N/N —completo y verde— describiendo un servidor sin hora, sin cortafuegos y sin latido. Es la lección de foot en escritorio-sway (121/121 sellado y sin emulador de terminal), pagada por adelantado. Cuenta esperada: 5. Un sexto wanted es un error de tipeo, no una receta nueva.

3.5 La caja, creada (2026-09-10)

nombre / id	takana / 165447050
tipo	cx33 — 4 c / 7,6 GiB / 76,3 G — €8,49/mes
ubicación	hel1 — la misma que los volúmenes vvv y harkaq-cosecha y que el Storage Box
IPv4 / IPv6	2.29.29.217 · 2a01:4f9:c014:2f9c::/64
imagen inicial	debian-13 — desechable: existe sólo para recibir ficheros hasta el dd del §3.2
label	role=takana-server
protección de borrado	NO, a propósito: es la caja de sacrificio

⚠ El label importa: farm-down.sh y deadman.sh borran sólo lo que lleva role=hammer-worker. Esta caja no lo tiene ⇒ ninguna automatización de la granja puede tocarla. Es la misma capa fuerte que protege a gioser, aplicada al revés: no se protege por nombre, se protege por no haber nacido de farm-up.

⚠ cx53 no se pudo comprar: sale Available: no en las TRES ubicaciones. Y la disponibilidad cambia por día — cx33 salió no en hel1 el 2026-09-09 y yes el 2026-09-10, con la misma consulta. ⇒ el precio de la tabla no dice que la máquina exista: hcloud server-type list devuelve precios para tipos que no se pueden crear. Consultar Available por ubicación, y volver a consultarlo el día que se compra.

Lo que la caja confirma, medido EN ELLA y no inferido de gioser

1. Arranca por BIOS — no existe /sys/firmware/efi… y sin embargo la imagen trae un ESP (sda15, 244 M vfat en /boot/efi). O sea: la presencia de una partición EFI no indica arranque EFI. Si el instalador decidiera la rama mirando particiones en vez de /sys/firmware/efi, elegiría mal en esta caja exacta. takana-live-install.sh mira lo correcto.
2. console=tty1 console=ttyS0 viene en el cmdline de Debian. Confirma que el serial es lo que Hetzner espera, y que el hueco 2 del §3.3 es real: nuestra imagen tiene que traerlo o la consola web no muestra nada.
3. eth0 con /32 dinámico por DHCP — idéntico a gioser ⇒ es exactamente el caso de netup.

Dos cosas pendientes en la caja, anotadas

• 7,6 GiB de RAM y CERO swap — la misma clase de máquina que ya provocó global_oom en gioser. Coherente con la decisión de §2.1 (la caja publica, el LXC muele), pero significa que no se construye pesado acá mientras siga así.
• sshd trae PasswordAuthentication yes (con PermitRootLogin without-password, así que root por clave igual). El journal del LXC muestra fuerza bruta a root desde IPs random; esta caja está igual de expuesta. Se cierra cuando se instale takana puro, o antes si se queda días con Debian.

3.6 La imagen del perfil.servidor, armada y validada (2026-09-10)

Receta del ensamblado (todo con scripts que ya existían, §7):

# 1. base con init: el product-rootfs sellado (trae /sbin/init -> /usr/bin/arje-zero)
cp -al /mnt/cosecha/store/5011955a…-product-rootfs/. $D/
# 2. userland del perfil encima
scripts/hydrate-profile.py servidor --into $D --store /mnt/cosecha/store --keep
# 3. ⚠ restaurar el init (ver abajo) y meter la clave
ln -sf /usr/bin/arje-zero $D/sbin/init ; cp github5.pub $D/root/.ssh/authorized_keys
# 4. imagen
ROOTFS=$D STAGE=/mnt/cosecha/.install-stage KERNEL=store/23f1cc43…-linux-generic/boot/bzImage \
CMDLINE="console=ttyS0,115200 console=tty0 root=/dev/sda2 rw init=/usr/bin/arje-zero" \
  ./scripts/install-image.sh

Resultado: 86 nodos, 30.500 ficheros, 2,0 G de rootfs → imagen de 7.172 M (2,1 G en disco, sparse).

El kernel correcto es linux-generic, y linux.toml NO sirve para hcloud

El disco de una caja hcloud lo maneja virtio_scsi (driver sd, disco sda) — no virtio_blk. recipes/linux.toml apaga SCSI explícitamente (-d SCSI) ⇒ su kernel arranca y no ve el disco. linux-generic, linux-metal y linux-metal-dual sí sirven.

⚠ Y ninguna receta nombra SCSI_VIRTIO. Está encendido igual, porque make defconfig lo trae y -e SCSI -e BLK_DEV_SD lo mantiene. Se supo mirando el .config que linux-generic publica en su artefacto (/boot/config-7.1.2-generic), no leyendo la receta. La receta dice lo que se cambió; sólo el .config sellado dice lo que quedó.

⚠ La hidratación PISA /sbin/init, y el resultado arranca igual

busybox entra en la clausura del perfil y su /sbin/init -> ../bin/busybox gana por llegar después, borrando el -> /usr/bin/arje-zero del product-rootfs. La imagen habría arrancado perfecta con el init de busybox: no takana puro, y sin un solo error. Se tapa por las dos puntas — restaurando el symlink al ensamblar y con init=/usr/bin/arje-zero explícito en el cmdline, que es lo que hace gioser y es autoritativo pase lo que pase con el symlink.

Y la guarda que existía para esto estaba INVERTIDA (arreglada en el mismo commit): [ -e "$ROOTFS/sbin/init" ] sigue el symlink y lo resuelve contra el host, así que el symlink ABSOLUTO a arje-zero daba falso y el rootfs correcto era rechazado, mientras que el relativo a busybox —el equivocado— pasaba. Ver guardian-que-nunca-fallo: una guarda que nunca falló no se sabe si sirve; ésta fallaba al revés.

EXDEV, dos veces en la misma tarde

store y work/out son bind-mounts de /dev/sdb; work/ está en /dev/sdc. Un hardlink no cruza un montaje aunque sea el mismo disco, así que reventaron (1) hydrate-profile.py con el destino fuera del montaje del store —que avisa RUIDOSO y bien— y (2) el staging de install-image.sh, que lo tenía cableado a work/. Ahora STAGE es env. Ver hardlink-cruza-mount-exdev.

La validación: arrancó en QEMU reproduciendo virtio-scsi, y se entró por SSH

SeaBIOS → GRUB → kernel 7.1.2 propio → EXT4-fs (sda2): mounted → Pivoted into new rootfs
→ Run /usr/bin/arje-zero as init process → "arje-zero: despierta como PID 1"
→ netup (DHCP) → ssh-keygen -A → sshd

Y desde fuera: ssh -p 2299 root@127.0.0.1 entra, /proc/1/comm dice arje-zero, ip addr da la IP que negoció netup. Es la puerta 1 del §6 ensayada en local antes de gastar la caja.

El card sshd de /ente/seed.card.json ya hacía el trabajo entero sin que hubiera que tocar nada: sh -c "/usr/bin/netup; /usr/bin/ssh-keygen -A; exec /usr/sbin/sshd -D -e" — red, claves de host y demonio en una línea. Lo único que hubo que inyectar fue authorized_keys.

Un resto del renombre, encontrado por el arranque

arje-zero: hammer no corre, sin menú de arranque: No such file or directory (os error 2)

arje-zero invoca el binario por el nombre VIEJO (hammer). No es fatal —sigue arrancando— pero el menú de arranque por grafo del ADR 0010 queda muerto. Y viene de tawasuyu, pineado por commit en recipes/arje-zero.toml, así que no se arregla desde este repo: hay que subirlo allá y re-pinear. Se suma a que la imagen tampoco trae takana (§3.4).

3.7 ⚠ El muro real: la puerta de enlace de Hetzner está FUERA del prefijo

La imagen validada en QEMU se escribió a la caja, arrancó… y no se pudo entrar. hcloud decía running, el puerto 22 cerrado, y desde fuera Connection timed out — el modo de fallo más caro de todos, porque no hay consola serie en hcloud para mirar.

La causa, medida entrando al rescue de la propia caja:

inet 2.29.29.217/32 scope global eth0
default via 172.31.1.1 dev eth0
172.31.1.1 dev eth0 scope link      ← ESTA es la que faltaba

La IPv4 viene con prefijo /32 y la puerta (172.31.1.1) no pertenece a ninguna red conectada. netup mandaba el default con RTA_GATEWAY y scope UNIVERSE y nada más, así que el kernel lo rechazaba con ENETUNREACH: la máquina se quedaba con IP y sin salida, contestando el DHCP y levantando sshd, sin nada visiblemente roto por dentro.

Control causal, en un netns con una dummy y una /32:

ip route add default via 172.31.1.1 dev dummy0   ⇒ Error: Nexthop has invalid gateway.
ip route add 172.31.1.1 dev dummy0 scope link    ⇒ ok
ip route add default via 172.31.1.1 dev dummy0   ⇒ ACEPTADO

Arreglado con add_onlink_host_route (dst /32, scope LINK) antes del default.

Por qué no había aparecido nunca: netup se validaba contra el DHCP de QEMU slirp, que entrega un /24 con la puerta dentro de la subred. El escenario que rompe sólo existe en una nube de verdad. Es cache-congela-regresiones en su otra forma: no es que el test estuviera mal, es que el ÚNICO entorno donde se probaba no contenía el caso.

Y destapó un segundo problema de fondo: el binario de netup venía dentro del product-rootfs, o sea congelado en un artefacto sellado del bootstrap ⇒ arreglar netup no llegaba a la imagen. Por eso netup pasa a ser raíz de perfil.servidor: así la hidratación lo proyecta encima y la imagen lleva el vigente. Verificado por sha256 (imagen a23df20e…, product-rootfs a84b0a0d…).

3.8 ✅ Puerta 1, pasada (2026-09-10)

PID 1    : arje-zero          kernel : 7.1.2 (linux-generic propio)
IP       : 2.29.29.217        rutas  : default via 172.31.1.1 + 172.31.1.1 scope link
montajes : /dev/sda3 -> /store      /dev/sda4 -> /var/lib/hammer
salida   : ping 1.1.1.1 0% pérdida · curl http://1.1.1.1 -> 301 · resolv.conf escrito por netup

Una caja Hetzner Cloud corriendo takana puro: nuestro kernel, nuestro init, nuestro cliente DHCP, nuestro sshd — sin una línea de Debian debajo. El camino entero es scripts/servidor-image.sh + rescue + dd, y la escritura de los 7,1 G comprimidos tarda ~17 s (gioser y la caja están las dos en hel1).

Lo que la caja todavía no tiene, y es el paso 2: takana (sin receta, §3.4), el store real (el volumen no se engancha hasta acá) y las otras cuatro raíces wanted.

---

4. La utilidad de migración: absorber lo VIVO, no lo declarado

arje-absorb ya existe, está sellado (recipes/arje-absorb.toml) y su --help dice: lee sysvinit | runit | dinit | openrc | auto y emite una Tarjeta Semilla con cada servicio del init ajeno como hija de arje-zero. Tiene parsers para los cinco (systemd.rs, openrc.rs, runit.rs, dinit.rs, sysvinit.rs).

Pero lee la declaración, y en gioser la declaración miente (§0.2). Un arje-absorb --from openrc sobre esta caja produciría una Semilla que no levanta el servidor, y lo haría en silencio: la Semilla sería sintácticamente perfecta.

⇒ Lo que falta es un segundo lector: absorber del proceso vivo (/proc: ppid==1, cmdline, cwd, entorno, fds en LISTEN) y reconciliar ambas lecturas marcando dónde discrepan. Eso es lo que el usuario nombró como «lo aprendido de matilda» — absorber lo que hay, no lo que está escrito.

La utilidad debe clasificar en tres, no en dos:

clase	criterio	qué se hace
vivo	proceso corriendo y declarado	se muda
declarado, muerto	en la config, sin proceso ni ficheros (los 4 dominios sin DNS)	fósil: se anota y se deja morir
vivo, no declarado	proceso con ppid==1 que ningún init declara (caddy, gitea, sshd, act-runner)	se escribe la tarjeta que faltaba — es el trabajo real

Se construye al final, estrenándose con la migración gioser → caja nueva, con el caso del rc-status que miente como test de aceptación. Su especificación es el §1 de este documento.

---

5. Que el servidor sirva sus propios paquetes a su propio host

Existe el camino entero: scripts/build-repo.sh (corpus → .swm firmados + índice), takana install --repo que ya acepta lista HTTP multi-origen y verifica cada paquete contra el digest del índice firmado (ADR 0014), takana upgrade con rollback, y caddy para servir dist/repo con un file_server.

Lo que falta no es servir, son dos cosas:

1. La clave. build-repo.sh firma hoy con una clave efímera por defecto (keygen release si no se le pasa KEY=) (medido, línea 33). Sin clave estable, «firmado» no significa nada. Es el SDD 19 §3.2 y es requisito aunque el repo sea privado.
2. La receta de takana (§3.4). El host necesita takana instalado para consumir los paquetes, y hoy no puede instalarlo desde el repo porque takana no está en el repo.

5.1 Hecho (2026-09-10): clave estable, repo firmado, y la caja sirviéndolo

• trust/ — la clave PÚBLICA de release en el repo; la privada en ~/.config/takana/keys/ (0600, fuera de git). scripts/repo-perfil.sh aborta si no la encuentra en vez de inventar una efímera, y tras firmar verifica el índice contra trust/.
• 88/88 paquetes del perfil servidor publicados con expected_hash anclado.
• La caja los sirve con caddy file-server sobre /srv/repo.

El control de la firma, en los dos sentidos, contra el repo servido por la caja:

--trust	resultado
./trust	release: trusted (by release) ⇒ instala
un directorio vacío	release: unknown-key … clave no confiada ⇒ ABORTA

5.2 ⚠ Lo que el lazo destapó: strip_debug no viajaba en el paquete

La primera instalación real de takana desde su propio repo falló:

Error: expected_hash no coincide:
  declarado = b3:941d1857…   obtenido = b3:2727050e…

why-differs lo nombró: los dos binarios pesaban exactamente lo mismo y sólo divergían en .shstrtab — la firma de un strip que corrió una vez y la otra no. swm_bridge re-inyecta con cuidado flags, phases, zig_version, strip_components, patches, deps… y se olvidaba de strip_debug, que ni siquiera existía en SwmBuild. Como entra en hash_inputs, el receptor reconstruía en otra dirección.

Alcance: 40 recetas del corpus, 18 de las 88 de este perfil. Una quinta parte del repo no se podía instalar, y nadie lo sabía porque nunca se había cerrado el lazo. Arreglado, con test de regresión y su control. Tras el arreglo, install takana da cache-hit en el hash anclado.

5.3 ⚠ Y el loopback nunca se levantaba

Al intentar que la caja instalara de sí misma por http://127.0.0.1: timeout de 30 s, con caddy escuchando en 0.0.0.0:80. lo estaba DOWN y sin dirección — con systemd o OpenRC lo levanta el init; con arje-zero no lo hacía nadie. El síntoma no era «connection refused», que se diagnostica en un minuto: era un cuelgue que parecía del servidor. Arreglado en netup (es quien configura la red) y verificado desde la imagen, sin tocar la caja a mano.

5.4 🚧 Lo que NO se puede todavía, y por qué importa

Con todo lo anterior en verde, la caja sigue sin poder instalar de su propio repo:

release: trusted (by release)              ← la firma verifica
repo: bajados 2 .swm de http://127.0.0.1   ← descarga de sí misma
Error: no pude leer el apk db del lab en /.dev-fs/alpine/lib/apk/db/installed.
       El toolchain entra en el ArtifactHash, así que sin rootfs no se puede
       calcular un hash comparable

O sea: la mitad de servir está cerrada y probada; la de consumir, no — y no por un detalle de instalación, sino porque install reproduce desde fuente y eso exige el LAB ENTERO en el cliente. No es «falta un compilador»: el lab entra en el ArtifactHash, así que sin él no se puede ni calcular el hash a comparar.

Es exactamente el punto que SDD 27 §4 dejó planteado y sin decidir —reproducir o hidratar— visto desde el otro lado: para un servidor, o para cualquiera que no sea un hub de build, reproducir no es una opción. El camino normal tiene que ser hidratar artefactos firmados, con --reproduce como camino auditable. Mientras esa decisión no se tome, el repo firmado sirve para distribuir a hubs, no a usuarios.

⚠ Y una caja que se sirve a sí misma es un solo origen — justo lo que el ADR 0014 existe para no tener. El camino normal puede ser el local, pero la lista de orígenes del host debe incluir también el Storage Box o gioser. Si no, el primer origen roto es el último.

Lo que esto vale: cerrar el bucle es el ensayo de «actualización en sitio probada de verdad» (SDD 19 §5.2), hecho sobre una máquina que importa pero que no es el laptop de nadie.

5.5 ⚠ Dos bugs más del lazo, que sólo aparecen si el paquete NO es un binario de Rust (2026-09-21)

Pedido del usuario: «instalar zsh con el comando takana». zsh es el primer paquete que se instala con varios parches y con el binario fuera de /usr/bin, y cada una de esas dos cosas era un fallo distinto. Los dos son de la familia del strip_debug del §5.2 —algo que el .swm no transportaba fiel— y los dos se descubren sólo cerrando el lazo, no leyendo el código.

1. Los parches viajaban CONCATENADOS, y eso cambia el hash. pack unía los N parches de la receta en el patch inline único; Recipe::hash_inputs mete una entrada por parche y of_inputs va con longitud prefijada ⇒ N sueltos y N unidos hashean distinto. Medido sin esperar al build, con una copia de recipes/zsh.toml con sus 6 parches concatenados en uno:

b3:0be3630d…   ← expected_hash anclado (y lo que hay en /store)
b3:d6329a62…   ← lo que reconstruye el receptor  (= la copia concatenada, exacto)

O sea: install zsh recompilaba zsh entero y recién entonces moría con expected_hash no coincide. Alcance: las 16 recetas del corpus con ≥2 parches — waterfox 12, firefox y gnupg 11, parted/zsh/strace 6, doas/mandoc/giflib 4, freetype 3, libxml2/file/brotli 2…

Arreglado con un campo patches (lista, en orden) en el source_patch; el patch único se sigue leyendo para no invalidar lo ya publicado. El receptor materializa un fichero por parche. Regresión con su control negativo en swm_bridge: si se concatenan, los hash_inputs TIENEN que diferir, o el test pasaría por la razón equivocada.

⚠ La tentación era arreglarlo del otro lado —hashear los parches concatenados— y habría sido mucho peor: mueve el hash de las 50 recetas con parches e invalida sus artefactos sellados.

2. target_bin era una adivinanza que nadie comprobaba. pack publica /usr/bin/{name}; zsh configura --bindir=/bin, así que su binario queda en /bin/zsh. El paquete se publicaba prometiendo un path que el artefacto no tiene, y el error salía en la máquina que instala, después de hidratar los 1331 ficheros:

Error: source_patch declara target_bin=/usr/bin/zsh pero no quedó en <prefix>/usr/bin/zsh

Con --build el artefacto está delante: ahora pack comprueba el path contra él y lo corrige si el binario quedó en otro bindir, diciéndolo.

⚠ Y el primer intento fue abortar, que era lo natural y estaba MAL. Al publicar el perfil entero con esa versión, 65 de 175 paquetes se quedaron fuera del catálogo: son las LIBRERÍAS —zlib, ncurses, openssl, musl-*, gmp…—, que no traen ningún binario y existen para que otros las resuelvan como dep. Un campo que su consumidor ni mira habría tirado un tercio del repo. Así que no aborta: avisa, y el paquete se publica. Lo mide el barrido de abajo, no el razonamiento — esa versión pasaba los tests igual.

Publicando el perfil servidor entero con el pack arreglado (medido, store del hub):

publicados y firmados	162 (el índice verifica contra su trust)
target_bin corregidos	8: bash sed tar parted dhcpcd squid wpa_supplicant zsh
sin binario (librerías)	64 — se publican, con aviso
sin sellar en ESTE store	12
fallaron	1 (os-release, el mismo del §6.46)

Esos 8 son paquetes que estaban publicados prometiendo un path que no existe: install bash habría hidratado y muerto al final. Comprobado después del arreglo, contra el repo firmado servido por HTTP: parted (6 parches y binario en /usr/sbin) instala en 0,17 s y responde parted (GNU parted) 3.7; bash instala y responde 5.3.0(1)-release.

5.7 El nombre ya existe: repo.gioser.net (2026-09-21)

Dado de alta en la zona de Hetzner (la DNS de gioser.net está ahí: helium/hydrogen/oxygen), con la convención que ya usaban takana, git, gitea, sergio y www: repo A → 2.29.29.217, ttl 60. Resuelve (comprobado contra Cloudflare; el resolutor de Google todavía servía el NXDOMAIN cacheado — negativo de 1 h por el minimum del SOA, no es un fallo del alta).

⚠ La API vieja de DNS de Hetzner ya no es la buena. dns.hetzner.com/api/v1/zones con Auth-API-Token devuelve HTML de la consola web (301 → 200 de una SPA), que es lo peor que puede devolver: no falla, contesta. Las zonas viven hoy en la API de cloud y las lee el MISMO token de ~/.config/hcloud/cli.toml:

curl -H "Authorization: Bearer $TOKEN" https://api.hetzner.cloud/v1/zones          # gioser.net = 986350
curl -H "Authorization: Bearer $TOKEN" https://api.hetzner.cloud/v1/zones/986350/rrsets

Durante unas horas el nombre resolvió y no sirvió nada —http:// daba el 308 global de Caddy y el HTTPS moría en el handshake (tlsv1 alert internal error) porque sin site block no hay certificado—, hasta que se pudo entrar como root a la caja. Cerrado el 2026-09-21 con scripts/servidor/publicar-repo.sh --install-vhost, que publica y firma en /srv/repo, añade el bloque y lo aplica; por defecto imprime el bloque sin tocar el Caddyfile, porque en esta caja Caddy sirve 19 dominios y su config ya acumula 20 .bak.

⚠ Publicar no es construir, y repo-perfil.sh no lo acotaba. pack --build es instantáneo con cache-hit y una compilación entera si el artefacto no está sellado. Medido al ensayar el guion: la corrida se puso a compilar libnftnl —y después habría seguido con rust— en una caja de 4 cores que ya estaba a load 46. build-repo.sh llevaba timeout desde siempre; el que se corre en producción, no. Ahora BUILD_TIMEOUT (120 s) y SKIP_UNSEALED=1: un vencimiento no es un error, significa «ése no estaba sellado». Con eso, el perfil entero publica 173 anclados, 0 sin ancla, 2 saltados (os-release, rust) sin compilar nada.

El --install-vhost, probado en sus dos caminos (con un Caddy de juguete, porque el de la caja no tiene el admin abierto):

camino	qué pasó
reload OK	✓ la config valida → ✓ recargado; el admin muestra el srv1 nuevo sirviendo el repo y el sitio que ya estaba sigue en pie
reload FALLA	copia restaurada byte a byte (b"repo.local" not in el fichero final), y no recarga nada

El orden es lo único que lo hace seguro: copia → añadir → caddy validate → sólo entonces reload. Un reload con la config rota no tira el sitio nuevo: tira los 19.

⚠ Y root no escribe en el árbol del usuario. work_root sale de dirname(store)/work ⇒ con el store en /store es /work, donde sources y out son enlaces a /work/sergio/work/…, que es del usuario (CLAUDE.md §3 bis). Publicar como root dejaría ahí directorios de root y el siguiente build suyo moriría con un permiso denegado que no menciona la causa — es exactamente lo que ya pasó cuando root hizo git pull en el clon de tawasuyu y lo congeló para el dueño (publicar-webs.sh). El guion, si corre como root y nadie fijó TAKANA_WORK, lo manda a /var/tmp/takana-publicar-work y lo dice. Comprobado que el override no mueve el hash: zsh sella en b3:0be3630d… igual.

⚠ Y trae su propia guarda contra el error más fácil de cometer: si el takana de la caja es anterior al §5.5 (se detecta porque no conoce outdated), aborta antes de publicar. Con uno viejo el repo sale con las 16 recetas multi-parche irreproducibles y 8 paquetes prometiendo un binario que no existe — y eso no se nota hasta que alguien instala.

⚠ Lo que queda vivo y no se tocó: un install <librería> DIRECTO sigue fallando tras hidratar, porque el .swm exige que el target_bin exista y para una librería no hay respuesta buena. Hacer target_bin opcional toca el formato (SDD 06) y es su propia unidad de trabajo. Como dep funcionan, que es para lo que están en el catálogo.

El lazo, después: takana install zsh --repo http://… --require-signed ⇒ cache-hit del hash anclado, 1331 ficheros hidratados en 0,14 s, y el binario corre (zsh 5.9). Antes: recompilar zsh entero para morir al final.

5.6 takana outdated — el aviso que faltaba (2026-09-21)

Ningún verbo comparaba lo instalado con el catálogo (upgrade es de árboles/generaciones, no de paquetes), así que «avisame cuándo hay que actualizar» no tenía respuesta. outdated la da leyendo sólo el índice firmado y la DB de instalados — no construye, no baja .swm, no escribe nada.

Compara por hash, no por versión, y eso es lo único que lo hace útil: un repo se re-publica sin que cambie la versión upstream cada vez que se mueve algo que entra en hash_inputs (una flag, el lab, un parche), y mirar la etiqueta diría «al día» sobre un artefacto que ya no es el que el repo sirve. La versión es el respaldo para cuando falta el ancla, y se dice que el juicio es más débil.

scripts/servidor/avisar-actualizaciones.sh lo corre por cron y sólo grita cuando la lista de novedades cambia (un guardián que repite lo mismo cada 30 min deja de leerse). Un repo caído no se disfraza de «al día»: lo dice, sale ≠ 0 y conserva el último estado bueno.

⚠ Lo que sigue sin poder hacerse, y no lo arregla ningún verbo: actualizar en una máquina sin lab. El aviso llega a cualquiera; el install que lo resuelve sigue siendo reproducir desde fuente (§5.4). Por eso outdated no actualiza: instalar es verificar, y eso no se cuelga de un cron.

5.8 Puerta 5, de verdad: repo.gioser.net sirve el repo firmado (2026-09-21)

$ takana install zsh --repo https://repo.gioser.net --trust ./trust --require-signed
release: trusted (by release)
repo: bajados 6 .swm de https://repo.gioser.net
caché: artefacto ya en el store hash=b3:0be3630d… name=zsh
  → hidratados 1331 archivo(s)                                    real 0m0,286s

173 paquetes anclados, 0 sin ancla, índice firmado con la clave de release de la caja y certificado CN=repo.gioser.net de Let's Encrypt. Los 2 que faltan (os-release, rust) no estaban sellados y el SKIP_UNSEALED los saltó en vez de ponerse a compilar.

Lo que había que descubrir para poder aplicarlo, y no estaba escrito en ningún sitio:

• caddy reload NO sirve en esta caja. El Caddyfile lleva admin off (por eso el :2019 siempre estuvo cerrado) y el reload de Caddy habla justamente por ese admin. La recarga real es arjectl restart caddy: caddy es un Ente de arje (/etc/arje/cards.d/caddy.json, Restart{initial:1000,max:30000}), no un proceso suelto.
• Un restart no es un reload: levanta los 19 dominios o ninguno. Por eso el guion saca un testigo de la config PREVIA —el primer dominio con nombre propio, acá gitea.gioser.net— y espera a que vuelva a responder; si no vuelve, restaura la copia y revierte. Comprobado después: los 8 dominios vivos siguen en pie (gitea 301 a git, el resto 200).
• El certificado tarda más que la comprobación. El guion dio ✗ todavía no responde y la misma URL respondía 200 unos segundos después: Caddy pide el certificado en la primera petición. El mensaje ahora dice «reintentá el curl antes de buscar nada» en vez de mandar a leer logs.

El espejo provisional se quitó. Mientras no hubo root, el catálogo estuvo servido sin firmar bajo takana.gioser.net/repo (un árbol escribible sin root, con certificado válido). Funcionó —install zsh en 0,22 s— y sirvió para probar el mecanismo, pero un origen sin firma no es un origen: con repo.gioser.net firmado en pie, se borró. Lo que quedó de aquello vale la pena recordarlo: firmar con una clave que no es la de release habría sido peor que no firmar, porque una autoría inventada se lee igual que una real; se publicó sin firma y con --require-signed rechazándolo, que es lo único honesto que se podía hacer sin la clave.

⚠ Sigue siendo un solo origen (ADR 0014). La caja se sirve a sí misma; la lista de --repo de los clientes debería llevar también el Storage Box. El primer origen roto, si es el único, es el último.

5.9 El aviso, enchufado en la caja (2026-09-21)

41 * * * * en el crontab de root → /usr/local/bin/avisar-actualizaciones, un envoltorio de tres líneas que sólo fija las rutas de la caja (REPO, DB, TRUST, STATE, TAKANA) y llama al guion del repo. La lógica no se copia a propósito: el día que el guion cambie, el cron no se queda con una versión vieja — y se comprobó en vivo, arreglando el guion en el clon y viendo cambiar la salida del envoltorio sin volver a desplegar nada.

Tres piezas que faltaban en la caja y ahora están:

/var/lib/hammer/trust/release.ed25519.pub	el almacén de confianza por defecto de la CLI, que no existía ⇒ install/outdated verifican la firma sin pasar --trust
/usr/local/bin/takana	build release con el arreglo del §5.5. ⚠ El PATH de la caja no incluye /usr/local/bin, así que un takana a secas sigue siendo el del store (que no conoce outdated). El cron usa rutas absolutas. Ponerlo canónico es reconstruir la receta takana e hidratarla — su propia unidad de trabajo
/var/log/takana-actualizaciones.log	una línea por hora

⚠ Y la primera corrida real destapó un defecto del propio aviso: con la DB de instalados vacía decía «al día». Es verdad y no dice nada — peor, se lee como «comprobado y correcto» cuando lo cierto es que no había nada que comprobar. Un aviso que suena igual cuando vigila que cuando no vigila nada es exactamente cómo se deja de mirar un aviso. Ahora distingue: «nada instalado por takana en esta máquina (DB …) — no hay qué comparar». Control en la caja con una DB de juguete (un zsh a otro hash): grita 1 con novedad · hash distinto, y en la segunda corrida calla.

Hoy la caja no instala de su propio repo —viene de imágenes—, así que el aviso dirá esa línea hasta que lo haga; se pone igual para que el día que instale algo ya esté, y porque una línea por hora no es ruido. Cada hora y no cada 30 minutos: el repo cambia cuando alguien publica.

5.10 takana install zsh en el sistema de verdad — cinco cosas que faltaban (2026-09-21)

El usuario escribió sudo takana install zsh en la caja y le contestó «paquete 'zsh' no está en el repo /var/lib/hammer/repo. Disponibles: (ninguno)». Reproducido tal cual. Debajo de ese mensaje había cinco cosas distintas, y ninguna se ve hasta que alguien instala de verdad.

1. El repo por defecto no existía. DEFAULT_REPO está cableado a /var/lib/hammer/repo y el repo publicado vive en /srv/repo. Un enlace (/var/lib/hammer/repo → /srv/repo) hace que install <nombre> sin --repo funcione y sin pasar por la red: un directorio local sirve igual que la URL.

2. El lab no se encontraba desde /root. install reproduce desde fuente y el toolchain entra en el ArtifactHash, así que sin .dev-fs ni siquiera puede calcular el hash a comparar (§5.4). La resolución es TAKANA_LAB → hermano del store → hacia arriba desde el CWD; con el store en /store y el CWD en /root, ninguna acertaba. Enlace /.dev-fs → /work/dev-fs y la regla del hermano del store acierta desde cualquier directorio y para cualquier usuario. (Los dos labs de la caja tienen el mismo apk db byte a byte, así que el LabFingerprint es el mismo.)

3. El takana del sistema no podía leer los paquetes nuevos. Los .tkn de hoy llevan los parches como lista (§5.5) y un cliente anterior ignora ese campo —serde salta lo desconocido—, así que reconstruiría sin parches y moriría contra el expected_hash. Se reemplazó por el build release. ⚠ Y se comprobó ANTES de tocar que /usr/bin/takana tenía enlaces=1 e inodo distinto al del store: es una copia, no un hardlink. Un cp encima de un fichero hidratado que SÍ fuera hardlink reescribiría el artefacto del store por debajo — se borra y se pone uno nuevo, nunca se sobrescribe.

4. ⚠ La instalación quedó PARTIDA, y eso no lo dice ningún mensaje. Sin --prefix, install abre un overlay sobre el FHS… pero sólo sobre siete directorios clásicos (/bin, /usr/bin, /sbin, /usr/sbin, /lib, /usr/lib, /etc). /usr/share no está entre ellos, así que de los 1331 ficheros de zsh, 1296 fueron directos al FHS real y sólo los 2 binarios quedaron en el upper esperando el commit. El mensaje final dice apply OK igual. Un discard en ese estado habría borrado el binario y dejado 1296 ficheros huérfanos: el experimento no era reversible y parecía que sí.

5. ⚠ commit no puede desmontar /bin en una máquina viva. Los procesos tienen su ejecutable mapeado desde ahí —empezando por PID 1, /usr/bin/arje-zero— y un ejecutable mapeado pin-ea el montaje. Resultado: desmontó 5 de 7 targets, murió con target is busy en /bin, y dejó dos overlays montados con el estado sin promocionar, que es el peor de los finales. El comentario del propio do_umount_lenient prometía el desmontaje perezoso desde la Fase 2 y el código nunca pasaba -l. Arreglado: ante busy reintenta perezoso, que desengancha el montaje ya mismo (las rutas vuelven a resolver al directorio real, que es lo que el promote necesita) y libera cuando el último proceso que lo miraba se muere.

El arreglo, probado en la caja viva con un segundo paquete instalado de cero:

$ takana install tree           ⇒ overlay 1790022033-1575-000000
$ takana commit 1790022033-1575-000000
WARN takana_overlay: umount: el target estaba ocupado (procesos con ejecutables mapeados ahí,
     normal en un FHS vivo) ⇒ desmontaje perezoso  target=/usr/bin
commit OK — 1 archivo(s) promocionados, 0 eliminado(s) (anotado en el diario)
⇒ overlays montados: 0 · /usr/bin/tree real · `tree v2.3.2` corriendo

Mientras tanto la caja se dejó limpia a mano: los dos binarios copiados al /bin REAL —visto a través de un mount --bind / no recursivo, porque el overlay tapaba el destino—, los dos montajes sueltos en perezoso y el estado borrado. Ahora: zsh 5.9 en /bin/zsh, 1296 ficheros en /usr/share/zsh, cero overlays, y takana installed lo lista.

Y la trampa del §5.7 se cobró su pieza: root dejó un /work/swm-recipes suyo dentro del /work del usuario (el catálogo de recetas que install materializa; work_root sale de dirname(store)/work). Devuelto a sergio. El guion de publicar ya exporta TAKANA_WORK para esto; install a secas no tiene esa defensa, y es deuda anotada.

5.11 chsh no funcionaba, y las dos razones eran distintas (2026-09-21)

Pedido del usuario después de instalar zsh. Dos capas, y sólo la primera es un arreglo.

1. /etc/shells no existía. chsh de shadow rechaza cualquier shell que no esté en esa lista —para un usuario normal es un rechazo duro, no un aviso— y el fichero no estaba en la caja. Escrito con lo que EXISTE, comprobado -x uno por uno (/bin/sh, /bin/ash, /bin/bash, /bin/zsh) y no copiado de otra distro: un shell listado que no está deja a quien lo elija sin poder entrar, y eso no se descubre hasta el siguiente login. Con eso, chsh -s /bin/zsh sergio funciona y su - sergio entra con zsh 5.9.

2. ⚠ Pero sergio sigue sin poder cambiárselo él mismo, y eso no es un fichero que falte.

$ su sergio -c "chsh -s /bin/bash"
Cannot change ID to root.

Los cinco binarios de shadow que necesitan setuid root —chsh, passwd, su, chfn, newgrp— salen del store como r-xr-xr-x. No es que la hidratación pierda el bit: la receta lleva --disable-account-tools-setuid, heredado del APKBUILD de Alpine (donde esos binarios los hace setuid el empaquetado, no el configure — y acá no hay quien se lo reponga).

Y hay una segunda capa debajo: ArtifactHash::of_tree sólo hashea el bit de EJECUCIÓN (mode & 0o111). O sea que hoy el modelo de artefactos no puede ni expresar ni garantizar un binario setuid: aunque la receta lo pusiera, el hash no lo cubriría y nadie notaría si se pierde o si aparece.

⇒ Quitar la bandera no alcanza y no es un arreglo de receta: es una decisión de seguridad. Un setuid root en una distro de artefactos sellados necesita contestar quién lo pone, quién lo verifica y qué significa que el hash no lo cubra. Anotado, sin decidir.

⚠⚠ Y lo que de verdad hay que llevarse de esto: un overlay abierto se traga TODA la máquina. Mientras el /etc/shells y el chsh se escribían, había un overlay abierto sobre el FHS —de un takana install sin --prefix que alguien había dejado sin commitear— y las dos escrituras cayeron dentro de él, aunque no tenían nada que ver con ese paquete ni pasaron por takana (fueron un cat > y el chsh de shadow). Medido con un mount --bind / no recursivo, que enseña el directorio real sin el overlay encima:

	/etc real	lo que se veía
/etc/shells	no existe	existe
shell de sergio	/bin/bash	/bin/zsh

O sea: el trabajo estaba hecho «según la pantalla» y un discard o un reinicio lo borraba. Se resolvió con commit (5 ficheros promocionados: passwd, passwd-, shells, zsh, zsh-5.9) y ahí el desmontaje perezoso del §5.10 se ganó el sueldo: saltó en /bin y en /usr/bin.

⇒ install sin --prefix no es «un experimento para ese paquete»: cambia la semántica de escritura de la máquina entera hasta que alguien commitea o descarta. Cualquiera que toque /etc mientras tanto —otro agente, un servicio, un humano por ssh— escribe en el upper sin enterarse. El overlay no avisa: no hay nada en el prompt, ni en mount a simple vista, ni un aviso al entrar. Como mínimo takana status tendría que salir en el arranque de sesión, y install debería decir qué queda pendiente en vez de un overlay listo que se lee como «terminé». Anotado.

Consecuencia práctica mientras tanto: los cambios de shell y de contraseña en esta caja los hace root. Y una observación que sale de mirar esto: no hay /etc/shadow; las contraseñas viven en /etc/passwd, que es legible por todos, con hash DES clásico. No lo toqué — es su propia unidad de trabajo y afecta al arranque de la caja.

---

6. La mudanza como experimento: el criterio de borrado

El usuario decidió que gioser se borra al final. Eso no es un detalle de calendario: es lo que convierte la mudanza en un experimento con criterio de aceptación, y hay que escribirlo antes.

Regla base: un ausente falla ruidosamente; un vacío llega hasta el final diciendo que todo fue bien. Aplicado acá: «lo copié» no es prueba de nada. La prueba es que el servicio responde en la caja nueva y que el dato se verifica por contenido.

6.1 Las puertas, en orden. Ninguna se salta.

#	puerta	cómo se comprueba
1	la caja nueva arranca takana puro y se entra por SSH	ssh a la IP nueva tras el reboot del rescue
2	el store está entero	1327 artefactos y ninguno vacío — respaldo-storagebox.sh --listar separa los vacíos; un directorio vacío no es un artefacto
3	los grafos salen idénticos	build-state.py en las dos máquinas ⇒ los cuatro grafos byte a byte. Es la prueba de que un hub está bien montado, no que «funcione»
4	la granja late en la caja nueva	una cosecha completa con el LXC enchufado por .fleet y artefactos que vuelven
5	el repo se sirve y el host se actualiza de sí mismo	§5 en verde, con la clave estable
6	cada dominio vivo responde 200 desde fuera	la tabla del §1.1, repetida contra la IP nueva
7	el respaldo al Storage Box corre desde la caja nueva	una corrida completa, no un --seco
8	lo fósil está anotado y decidido	lista del §1.1 con «muere» o «revive» al lado de cada uno

⚠ Puerta 3 tiene una trampa conocida: sealed_remoto dependía de la máquina (laptop 700, gioser 751 sobre el MISMO corpus) y por eso se sacó del JSON. Si los grafos difieren, mirar primero si la diferencia es «cuánto de esto tengo en disco» y no «qué existe».

6.3 Estado de las puertas (2026-09-10)

#	puerta	estado
1	arranca takana puro y se entra por SSH	✅ §3.8
2	el store está entero	✅ 1362 artefactos reales, 0 vacíos
3	los cuatro grafos idénticos	✅ byte a byte — §6.7
4	la granja late en la caja nueva	✅ cosecha completa: 1369→1575, 0 vacíos — §6.8
5	el repo se sirve y el host se actualiza de sí mismo	⬖ mitad: sirve (§5.1), no consume (§5.4)
6	cada dominio vivo responde 200	⬖ sondeados: 6 vivos de 19 — §6.9
7	el respaldo corre desde la caja	⬖ alcanza el box y lista 3140; arreglados 3 bloqueos — §6.10
8	lo fósil, anotado y decidido	✅ decidido — §6.9

Puerta 2, medida acotando al patrón <hash>-<nombre>: 1362 artefactos, 0 vacíos. Los 3 sin .hammer/recipe.toml son stage1-rootfs, product-rootfs y seed-zig — productos de bootstrap, que por diseño no salen de una receta. (El primer conteo dio «3 vacíos» y eran .mirror-tmp, .bootstrap-tmp y .divergen: directorios de trabajo con punto inicial, no artefactos. El chequeo tiene que acotar por el patrón, no listar el directorio.)

De paso, el disco: la imagen ocupaba 7 G de los 76,3 G de la caja y los otros 69 eran inalcanzables. Arreglado en install-image.sh — el store pasa a ser la ÚLTIMA partición (la única que puede crecer sin mover datos) y el wrapper de /sbin/init la extiende en el primer arranque. Medido en la caja: /store = 68,7 G, contra los 487 M de antes. Con eso el store de 55 G entra en el disco local y la mudanza no depende de mover el volumen de gioser.

6.4 ⚠ El muro de la puerta 3: la imagen trae 23 binarios que NO PUEDEN CORRER

Al ir a computar los grafos en la caja:

$ python3 -c "print(1)"
sh: python3: not found          ← y `command -v python3` decía /usr/bin/python3

No es que falte: está y no arranca. /usr/bin/python3.12 son 23 MB y es un ELF dinámico:

Requesting program interpreter: /lib/ld-musl-x86_64.so.1
NEEDED  libc.so

Y en toda la imagen no hay ningún cargador dinámico. Tampoco en el store: el artefacto musl publica sólo lo estático (libc.a, crt*.o, headers) — no hay libc.so ni ld-musl-x86_64.so.1 en ningún artefacto del corpus. Lo que hace que estos binarios funcionen en gioser es el rootfs Alpine del LAB, que sí lo trae (.dev-fs/alpine/lib/ld-musl-x86_64.so.1).

Es la fuga de needed-colgante-libstdcxx otra vez, y esta vez en el piso de abajo: sella, reproduce y no corre, porque pide algo que sólo existe en el laboratorio.

Contado sobre la imagen: 23 binarios inertes de 726 (703 estáticos están bien). Son la suite binutils entera (ar as ld nm objcopy objdump ranlib readelf strip addr2line c++filt elfedit gprof size ld.bfd), más perl, python3, sqlite3, flex y nft.

Por qué frena la mudanza y no es un detalle: todo el instrumental del proyecto es Python — build-state.py, targets.py, yupana.py, hydrate-profile.py, drenar.py, triaje.py. Un servidor takana no puede correr ni una de sus propias herramientas. La puerta 3 (los cuatro grafos) y la 4 (la granja) dependen de eso.

Y no se arregla de paso. Las salidas son tres y ninguna es barata:

1. Publicar el cargador — que musl emita libc.so + ld-musl-x86_64.so.1. Es lo correcto y lo más chico en concepto, pero toca un componente de Stage 1: mueve el baseline of_tree del selfhost y hay que rehacerlo a propósito, no de rebote.
2. Construir python/perl estáticos — el camino que evita el cargador, y es un frente propio: Python estático con módulos de extensión es notoriamente arisco.
3. Aceptar que el instrumental vive en el HUB y que el servidor sólo sirve. Es la respuesta honesta a corto plazo, pero contradice «mover allá todo lo que tengo acá»: el hub seguiría siendo gioser, que es justo lo que se quiere apagar.

Es decisión de ADR, y de las que conviene tomar mirando también el SDD 27 §4: las dos preguntas —«¿el cliente reproduce o hidrata?» y «¿el cliente puede correr lo que le mandamos?»— son la misma pregunta sobre qué es un sistema takana sin laboratorio.

6.5 ✅ El muro, derribado: el corpus publica su propio cargador (2026-09-11)

De las tres salidas del §6.4 el usuario eligió la 1 y la 2. Hecha la 1, que resultó ser más barata de lo que parecía y desbloquea la 2 en vez de competir con ella.

recipes/musl-shared.toml — variante dinámica de musl que publica /usr/lib/libc.so (4,2 M) y /lib/ld-musl-x86_64.so.1. En musl el cargador Y la libc son el mismo objeto.

Por qué una variante y no --enable-shared en la canónica, con su control: musl es componente de Stage 1 y su of_tree es el baseline de selfhost-verify. Tocarla obliga a rehacer ese baseline a propósito. Con el patrón *-shared —que el corpus ya usa 23 veces— la canónica no se mueve: takana hash recipes/musl.toml sigue dando b3:ce952f72…, el mismo sellado de Stage 1. Y además musl no es dep de nadie (medido: sólo de sí misma; el enlace estático lo resuelve el musl que trae zig), así que esto suma sin mover un solo ArtifactHash del corpus.

⚠ Y hubo que cambiar de compilador, medido

Con zig-cc el libc.so sale con 1586 símbolos dinámicos contra los 1654 del musl de Alpine, y los 68 que faltan son exactamente los que musl implementa en ensamblador x86_64 — memset, memcpy, memmove, memcmp, strlen y toda la familia matemática (ceil floor sqrt fmod exp log sin cos tan fma round trunc) — más los __stack_chk_*.

No es que no se compilen: en el libc.a del musl canónico están. Lo que pasa es que zig los resuelve con su propio musl y los deja FUNC LOCAL HIDDEN de tamaño 0, fuera de la tabla dinámica. El síntoma es un cargador que arranca, reloca y muere con memset: symbol not found — que se lee como «el binario está roto», no como «a la libc le faltan símbolos».

Con compiler = "gcc": 1651 símbolos, memset y ceil presentes.

El resultado, en la caja

antes	después
sh: python3: not found (con command -v contestando /usr/bin/python3)	Python 3.12.10
23 binarios inertes de 726	1

perl 5.040002, readelf/objdump/nm (GNU Binutils 2.45.1) y el resto corren. El único que quedaba era sqlite3, con Error loading shared library libz.so.1: la zlib canónica también es --disable-shared y nadie publicaba ese soname. zlib-shared ya existía sellado en el corpus — sólo faltaba declararla en base.

La salida 2 (python/perl estáticos) sigue viva y ahora es opcional, no urgente: con el cargador publicado el sistema ya no depende del rootfs del lab. Estático seguiría siendo mejor (un binario menos que puede quedar colgado de un soname), pero es un frente propio y ya no bloquea la mudanza.

6.6 Sembrar el hub: un hub no es repo+store, es repo+store+LAB

Con python3 vivo, takana hash en la caja seguía fallando:

Error: no pude leer el apk db del lab en /.dev-fs/alpine/lib/apk/db/installed.
       El toolchain entra en el ArtifactHash ⇒ sin rootfs no hay hash comparable.

El lab es parte de la IDENTIDAD, no del entorno. Una máquina sin él no puede ni preguntar «¿cuál es el hash vigente de esta receta?», así que no puede computar el grafo ni decidir qué falta. Sembrado el lab (tarball pineado + tools/, bajo /store/dev-fs porque la raíz son 6 G), el hash testigo coincide byte a byte: takana hash recipes/zlib.toml da b3:dc363f26… en las dos máquinas.

⚠ Y la caja no podía desempacar su propio lab: el tar del rootfs es el de busybox y contesta tar: unrecognized option: zstd. La distro comprime todo con zstd —la imagen del lab, el respaldo, el dd remoto— y la imagen no traía el binario. zstd ya tenía receta sellada; declarado en base.

⚠⚠ Copiar un store con rsync -a es una fábrica de vacíos, y ahora se sabe POR QUÉ

La primera copia murió con No space left on device en un .so de Qt, dejando el destino al 100 % y 1367 de 1368 artefactos VACÍOS. La puerta 2 corrida EN EL DESTINO lo cazó en el acto.

La causa, medida:

medición sobre el store de gioser
du -sh (hardlinks contados UNA vez)	60 G
du -sh --count-links (hardlinks EXPANDIDOS)	85 G
.dmerge (la caché que hardlinkea al store)	11 G

rsync sin -H no preserva hardlinks: los expande en copias enteras. Así que «el store son 60 G» —que es lo que dice du y lo que uno planifica— se convierte en 85 G + lo que .dmerge expanda al otro lado. La partición de 68,7 G no tenía ninguna chance, y el modo de fallar es el peor: el disco se llena a mitad y quedan cientos de nombres de artefacto sin contenido, que el store da por presentes.

La copia correcta es rsync -aH --exclude='.dmerge': -H preserva los enlaces (60 G reales) y .dmerge no se copia porque es caché regenerable — la misma que ya llenó un disco en el worker.

La lección de método: du -sh sobre un árbol con hardlinks no dice cuánto ocupa copiarlo. Para dimensionar una copia hay que medir con --count-links, o preservar los enlaces.

Y el instrumental apunta al binario de DESARROLLO, no al instalado

La primera corrida de build-state.py en la caja devolvió 875 recetas unhashable — todas — con el lab bien sembrado y takana hash funcionando a mano. La causa:

HAMMER = os.environ.get("HAMMER", str(ROOT / "target/release/takana"))

Los scripts asumen un árbol de desarrollo: target/release/takana. En una caja instalada el binario es /usr/bin/takana y target/ ni existe (la siembra lo excluye a propósito). No falla ruidosamente: cada hash falla y el grafo sale entero como unhashable, que se lee como «este corpus no se puede hashear» y no como «no encontré el binario».

Se destraba con HAMMER=/usr/bin/takana STORE=/store, que la propia cabecera del script documenta. Pero la deuda queda anotada: el instrumental debería caer a command -v takana antes de rendirse, porque el caso «hub instalado» es justamente el que esta mudanza quiere que exista.

6.7 ✅ PUERTA 3 EN VERDE: los dos grafos, idénticos byte a byte

gioser: 7435d33d62577e8ce154e8c5e354e0465139cfbc632afe710076ea2223cea605
caja:   7435d33d62577e8ce154e8c5e354e0465139cfbc632afe710076ea2223cea605

base 61/61 · cli 84/84 · escritorio-mirada 41/41 · servidor 96/96 · falta 0, wanted 3 (chrony, cronie, logrotate — la deuda declarada), grafo CIERRA, topo-sort OK. Las dos máquinas.

Costó tres intentos, y los dos fallos son la parte que vale.

Intento 1 — unhashable 875, todas. Ver arriba: los scripts apuntan a target/release/takana.

Intento 2 — dos nodos divergentes: aichat y zola, sealed en gioser y never en la caja. No era deriva ni pérdida: ninguno de los dos está en disco en gioser tampoco. Son los «2 sellados que no están en esta máquina, avalados por los manifiestos» que el propio resumen imprime. build-state.py lee work/farm-sellados.txt y work/respaldo-sellados.txt — y work/ está gitignored, así que un hub recién sembrado no los tiene y degrada esos nodos a never sin que nada falle.

Es la misma familia que scripts/farm/.fleet: un fichero fuera de git del que depende una medición compartida. La regla que sale: sembrar un hub no es clonar el repo — es repo + store + lab + los manifiestos. Copiados los dos ficheros, los grafos coinciden exactamente.

6.8 Puerta 4: el camino de la granja, PROBADO; la cosecha completa, sin disco

Probado desde la caja (sin tocar el latido de gioser, todo de sólo lectura salvo el último paso):

• llevada la clave de la granja (~/.ssh/github5 → /root/.ssh/github5, 0600) y escrito scripts/farm/.fleet — los dos están fuera de git a propósito y hay que copiarlos a mano;
• la caja alcanza al worker: PruebasIA, load 3, 775 artefactos;
• estado-granja.sh corre allá y lee bien el worker y el avance KDE (198/199);
• y el paso que cierra el lazo: se cosechó un artefacto real del worker (speedtest-go, 12 M) con el mismo transporte de la granja, llegó con su .hammer/recipe.toml y su binario CORRE en la caja (speedtest-go v1.7.10). Worker construye → hub cosecha → binario ejecuta.

✅ CERRADA (2026-09-11) con el volumen takana-store

Resuelto el disco (§6.12), la cosecha completa corrió: 1369 → 1575 artefactos, 0 vacíos, que son exactamente los 206 que faltaban. 12,4 G por la red para 39 G lógicos —speedup 3.14, el ahorro de -H— y /store queda en 73,7 G de 97,9 (79 %).

⚠ El enlace con el worker va a 11 MB/s, no a los 90 MB/s de gioser↔caja: el LXC vive en el Proxmox de gioser, fuera de la red de Hetzner. Media hora para una cosecha de este tamaño.

⚠ Lo que faltaba no era mecanismo: era DISCO.

artefactos en el worker que la caja no tiene	206
a ~113 MB de media (el artefacto medio del corpus)	~23 G
libre en /store de la caja	3,7 G (61,5 de 68,7 · 94 %)

Una cosecha completa no entra, y forzarla repetiría exactamente el llenado que dejó 1367 artefactos vacíos hace un rato. La puerta 4 queda pendiente de una decisión de CAPACIDAD, no de una de ingeniería:

1. Enganchar harkaq-cosecha (250 G) a la caja. Es el plan original y no cuesta nada extra — pero hay que DESENGANCHARLO de gioser, y ahí vive el store, work/sources, los tarballs y el CARGO_HOME de la granja. O sea: es el cutover. gioser deja de construir en ese mismo instante, y hoy está moliendo el árbol KDE.
2. Un volumen nuevo para la caja (€0,052/GB/mes: 100 G ≈ €5,2/mes). No interrumpe nada y destraba la cosecha ya; se paga por duplicado hasta que gioser muera, y entonces se suelta.
3. Podar el store de la caja — deshace parte de la mudanza. No.

6.9 Puerta 8: los 19 dominios, sondeados uno por uno (2026-09-11)

El Caddyfile de gioser declara 19 sitios. Sondeados por DNS y por HTTP desde fuera, sólo 6 los sirve gioser de verdad:

dominio	DNS	HTTP	qué es
gioser.net · tawasuyu.net	gioser	200	VIVO — las dos landings
git.gioser.net · git.tawasuyu.net	gioser	200	VIVO — el gitea (aloja el origin de takana)
sergio.gioser.net · api.sergio.gioser.net	gioser	200	VIVO
summa · api.summa · dev.summa	154.197.1.2	200	YA MUDADOS a otra máquina: el bloque de Caddy en gioser es fósil aunque el sitio viva
api.gioser.net	gioser	502	backend caído
mail.sigma.gioser.net	gioser	502	backend caído
aura · api.aura · sigma · kosmofono · api.kosmofono	SIN DNS	—	fósil: ni DNS ni ficheros en /var/www
terapeuta.ec · andino.ec	SIN DNS	—	fósil con datos: 279 M en /var/www/terapeuta
gitea.gioser.net	SIN DNS	—	era un redir a git.gioser.net; inofensivo

Lo que esto cambia respecto del §1.1: no son «4 fósiles» sino 13 de 19 entradas que no hay que mudar — 8 sin DNS, 2 con el backend caído y 3 que ya viven en otra máquina. La superficie real a mudar son 6 sitios, y de esos el que pesa es el gitea, porque aloja el origin de takana.

✅ DECIDIDO (usuario, 2026-09-11)

fósil	decisión
aura · api.aura · sigma · kosmofono · api.kosmofono	mueren — ni DNS ni ficheros
gitea.gioser.net	muere — era un redir, y git.gioser.net lo cubre
api.gioser.net · mail.sigma.gioser.net	mueren — backend caído, sin dueño
summa · api.summa · dev.summa	no se mudan: ya viven en 154.197.1.2. Sólo hay que sacar sus bloques del Caddyfile al apagar gioser
terapeuta.ec · andino.ec	MUEREN — decisión explícita del usuario. Los 279 M de /var/www/terapeuta se van con la caja; no se archivan

⇒ De las 19 entradas del Caddyfile, 13 no se mudan. La superficie real es de 6 sitios, y el que pesa es el gitea porque aloja el origin de takana.

⚠ Que esto quede escrito ES la puerta: el día que se borre gioser, terapeuta.ec no va a poder recuperarse, y la diferencia entre «lo decidimos» y «se nos pasó» es este párrafo.

6.10 Puerta 7: el respaldo desde la caja — y tres bloqueos que sólo se ven corriéndolo

Llevadas las credenciales (~/.config/hammer/*.env, 0600) y la clave, la caja alcanza el Storage Box por el puerto 23 y lista su contenido. El manifiesto se refresca desde allá: 3140 artefactos, y de paso el script detecta 2 VACÍOS en el respaldo (gnome-desktop ×2) que excluye del manifiesto — su propia guarda, funcionando.

Para llegar ahí hubo que arreglar cinco cosas, y todas son de la misma familia: el instrumental asume que el hub es gioser. El --seco ahora completa los tres pasos desde la caja y lee la ocupación del box (111 G de 1 T).

1. La raíz cableada. RAIZ="${RAIZ:-/mnt/vvv/takana}" ⇒ desde cualquier otra máquina el script moría con cd: /mnt/vvv/takana: No such file or directory. Ahora se deriva de dónde está el script, como el resto de scripts/.

2. El binario de desarrollo. HAMMER = ROOT/target/release/takana (§6.7).

3. El store no estaba donde el script creía. Usaba $RAIZ/store cableado: en gioser es un bind-mount DENTRO del repo, pero en una caja instalada es una partición en /store ⇒ change_dir "/opt/takana/store" failed. Y rsync devuelve 23, que está en la lista de reintentables, así que el bucle insistía — el cuadro que la propia cabecera del script documenta («un error reintentable que se repite 40 veces no es un corte de red: es algo estructural»). Ahora STORE es env, con una guarda que aborta ANTES del bucle si la ruta no existe.

4. 🚨 Y una que habría costado el historial. El paso [2/3] sube el repo con --delete — correcto, para eso está git. Pero el /opt/takana de la caja llegó por rsync --exclude=.git: es una COPIA, no un clon. Una corrida real desde ahí habría borrado .git del Storage Box, o sea el historial entero, y en silencio: rsync haría exactamente lo que se le pidió. Añadida una guarda que aborta si la raíz no tiene .git (escotilla REPO_INCOMPLETO=1), probada en los tres sentidos.

   La regla que sale: un --delete convierte «respaldar» en «sincronizar», y sincronizar desde un origen incompleto no sube menos — BORRA. Cualquier respaldo con --delete necesita una guarda de completitud del ORIGEN, no sólo del destino.

5. El rsync del corpus no puede correr el respaldo del corpus. El script exige --compress-choice=zstd y recipes/rsync.toml lo construía con --disable-zstd — porque cuando se escribió, zstd no estaba en el catálogo. Hoy sí. Peor aún: el error 4 que devuelve rsync el script lo clasifica como «no de red» y no reintenta, así que el respaldo simplemente no se hacía. Arreglado por los dos lados: la receta enciende zstd (control: zstd zlibx zlib none vs zlibx zlib none; radio cero, rsync no es dep de nadie) y el script degrada a zlib avisando en vez de morir.

6.11 ⚠ La distro traía un git que NO PODÍA CLONAR

Para cerrar la puerta 7 la caja necesita un clon de verdad (el --delete del respaldo exige un origen completo, §6.10). Llevada la clave del gitea —que es ~/.ssh/tawasuyu, no la de la granja— git ls-remote contesta… y git clone muere:

fatal: fetch-pack: invalid index-pack output

El informe completo, que la traza corta escondía:

panic: load of misaligned address 0x… for type 'const uint32_t',
       which requires 4 byte alignment
  in sha1_compression_states → sha1_process → SHA1DCUpdate → git_SHA1DCUpdate
  → git_hash_update → unpack_entry_data → cmd_index_pack

Dos causas, encadenadas:

1. -fsanitize=undefined estaba en CFLAGS, no sólo en LDFLAGS. El motivo original era legítimo —las libz.a materializadas traen referencias __ubsan_handle_* que bajo -static no se resuelven solas, y el flag al enlazar trae el runtime de zig— pero en CFLAGS instrumenta el código de git. Un arreglo de ENLACE convertido en una mina de RUNTIME, justo en la ruta de hash: por donde pasa todo lo que git recibe.
2. sha1collisiondetection lee palabras de 32 bits SIN alinear. Es el backend SHA1 por defecto de git, el que detecta SHAttered. En x86 la lectura desalineada funciona y por eso nadie lo nota jamás; según el estándar es UB, y basta con que el runtime ubsan esté enlazado para que aborte. -DSHA1DC_FORCE_ALIGNED_ACCESS lo hace leer byte a byte: quita el UB en la fuente en vez de esconderlo.

Con las dos: git clone --depth 1 del propio repo desde la caja ⇒ 877 recetas. Radio cero (git no es dep de nadie), pero sí es raíz de perfil.base ⇒ esto arregla la distro entera.

La lección: ls-remote andaba, así que el fallo parecía de red. Lo que lo destapó fue leer el informe COMPLETO en vez de la última línea — la primera decía exactamente qué y dónde.

6.12 ⚠ La caja dejó de ser desechable — y hydrate no cruza el store

Dos consecuencias de que la caja ya sea un hub, y las dos cambian el procedimiento:

1. Re-escribir la imagen con dd ya NO es una actualización, es una pérdida. El dd sobrescribe el disco local, y ahí viven ahora /opt/takana (el clon), /root/.ssh (las dos claves), /root/.config/hammer (las credenciales del respaldo), /srv/repo y la configuración de caddy. El store se salva sólo porque está en el volumen. Y hay una trampa peor: la imagen etiqueta su partición local como hammer-store, así que tras un dd habría dos filesystems con esa etiqueta y el findfs del arranque elegiría cualquiera — con suerte el volumen, con mala suerte una partición vacía. ⇒ el dd es para PROVISIONAR; actualizar es takana upgrade (que existe, con generaciones y rollback) y está sin probar en esta caja.

2. takana hydrate no puede proyectar al root vivo. Hidratar enlaza en DURO, y en una caja instalada el store es siempre otra partición que /:

Error: store: hardlink /store/51aa5e13…-git/.hammer/recipe.toml → /.hammer/…: Cross-device link

No es culpa del volumen: en el layout original /store es sda4 y / es sda2, también distintos. Hidratar al FHS vivo nunca fue posible en una caja instalada — funciona en el hub porque ahí store y destino están en el mismo filesystem. Es la misma familia de EXDEV que ya mordió dos veces (§6.6), ahora a nivel de sistema y no de herramienta.

Para instalar el git arreglado se copió el artefacto a mano. Eso funciona y no es el camino: el camino es takana upgrade, y probarlo es su propia unidad de trabajo.

6.13 ✅ takana upgrade, probado de verdad — y el bug de durabilidad que destapó

§6.12 dejó dicho que el camino de actualización de una caja instalada es takana upgrade, no dd ni hydrate. Probado con un paquete que la caja realmente necesitaba: zstd.

paso	resultado
upgrade apply …-zstd-cli	✓ generación 2 aplicada · + 1 añadidos, ~ 1 pisados, - 8 retirados
la prueba de uso	zstd -dc lab-image.tar.zst | tar -xf - ⇒ la caja desempaca su propio lab
upgrade rollback	✓ generación 2 revertida · 9 restaurados, 1 borrados — zstd se va, libzstd.a vuelve
re-apply + corte duro sin sync	sobrevive: generación viva 1, manifiesto íntegro

✔ Y cruza la frontera que hydrate no puede: el store está en el volumen y / en el disco local, y upgrade copia en vez de enlazar. Es, de hecho, el único camino que funciona en una caja instalada.

⚠ El bug: write_atomic era atómico pero NO DURABLE

El primer intento pareció funcionar y se perdió al reiniciar. La caja volvió con:

pending.json                   0 bytes
generations/2/manifest.json    0 bytes
upgrade status  → Error: json: EOF while parsing a value
upgrade recover → Error: json: EOF while parsing a value

write_atomic hacía temporal + rename: atómico frente a otros PROCESOS, no frente a un CORTE. rename sobre un fichero cuyos datos siguen en caché deja, tras el corte, la entrada apuntando a bloques nunca escritos — cero bytes. Y hcloud server reset es un corte duro, no un apagado limpio: ahí está la mitad operativa de la lección.

Lo grave no es perder un upgrade: es que recover —que existe exactamente para «un apply interrumpido por un corte»— abortaba con la huella más probable de ese corte.

Arreglado: fsync del temporal antes del rename y fsync del directorio después (hacen falta los dos), y un pending.json vacío se reporta como PendingCorrupt, nombrando el corte y apuntando al árbol de respaldos. Con tests y su control.

Verificado en la máquina, en los dos sentidos: con el binario viejo, apply + reset duro ⇒ estado en 0 bytes; con el nuevo, la misma secuencia ⇒ estado íntegro y el paquete en su sitio.

⚠⚠ upgrade apply NO es un gestor de paquetes: cada generación ES UN ÁRBOL

Lo destapó usarlo dos veces seguidas. Tras aplicar zstd-cli y después rsync:

✓ generación 2 aplicada
  + 0 añadidos, ~ 8 pisados, - 1 retirados      ← el `zstd` de la generación 1
$ zstd --version
AUSENTE

Aplicar un árbol nuevo RETIRA los ficheros del anterior, porque una generación es el estado completo, no un incremento. Es coherente con lo que la ayuda dice —«aplica un árbol Stage1/producto del store»— y con que exista rollback: lo que se revierte es un sistema, no un paquete.

⇒ Usarlo para instalar paquetes sueltos, como hice acá, funciona una vez y se deshace a la siguiente. La forma correcta de poner una caja al día es componer el árbol del perfil —lo que ya hace servidor-image.sh— sellarlo, y aplicar ESO como una generación. Eso además sería, de verdad, la «actualización en sitio probada» del SDD 19 §5.2: una imagen entera, con rollback, sobre una caja viva.

Mientras tanto la caja quedó con zstd y rsync puestos a mano — funciona y no es el camino, igual que el git.

⚠ Lo que NO se arregló: si el manifiesto se pierde, recover no puede deshacer solo — no sabe qué se tocó. El árbol de respaldos tiene la información; reconstruir desde ahí es su propia unidad.

6.2 Lo que la mudanza tiene que producir, además de la mudanza

El usuario lo pidió explícito: que este experimento saque recetas y las pruebe. La caja vieja es un catálogo de software real en producción, y cada servicio que hoy corre sobre binarios de Artix es una receta candidata con un caso de uso comprobado detrás:

lo que corre hoy en Artix	receta
caddy	✅ existe (recipes/caddy.toml)
openssh	✅ existe
gitea	✅ SÍ existe (recipes/gitea.toml) y está sellada (35bb4f04…) — ver la corrección abajo
qdrant, squid, fail2ban, php-fpm, metalog, glances	✗
chrony, nftables, cronie, logrotate	✗ — ya declaradas wanted en perfil.servidor

CORRECCIÓN (2026-09-11). Esta tabla decía que gitea NO tenía receta y que «es la que más peso tiene». Las dos cosas eran falsas: recipes/gitea.toml existe desde el 2026-09-09 y su artefacto está sellado. Lo escribí de memoria, sin mirar el catálogo.

Lo destapó planear.py al cruzar cada binario contra recipes/: de los servicios de gioser, 4 ya tienen receta takana y están sellados (caddy, gitea, python3…), 4 vienen de un paquete ajeno y 11 son binarios sueltos sin dueño. Ésos últimos son el trabajo real, no gitea.

Es exactamente para esto que la herramienta existe: yo afirmé de memoria y el programa fue a mirar.

Cada una que se cierre se prueba sola: el servicio o levanta en la caja nueva o no, y eso se ve el mismo día. Es la diferencia entre una receta «sellada» y una receta usada.

---

6.11 🗄️ La imagen del perfil, con gitea, ARRANCA y SIRVE (2026-09-14)

servidor-image.sh + QEMU: PID 1 = arje-zero, gitea encarnado por él (ppid=1), corriendo como uid=916, escuchando en :3000 y devolviendo 200 con <title>takana git</title>, con su gitea.db creada por él mismo. Es el primer servicio de PAQUETE que arranca en una imagen de takana: los que había venían horneados en el bootstrap.

La cadena entera, eslabón por eslabón: [[user]] → /etc/passwd de la imagen · [[service]] → takana service-cards → genesis de la seed → arje lo encarna → setuidgid → sirve.

Los tres fallos que sólo aparecieron AL PROBAR LA IMAGEN

Los tres pasan el sellado, el hash, el resolutor de servicios y el armado. Ninguno se ve sin arrancar la imagen.

1. ⚠⚠ Escribir en el rootfs hidratado es escribir DENTRO del store. takana users --merge hacía fs::write sobre <rootfs>/etc/passwd, y ese fichero y el del artefacto product-rootfs son el mismo inode (medido: 1225824, 2 links, modo 444) — el rootfs se arma con hardlinks. Habría mutado un artefacto sellado, y toda imagen futura habría salido con la cuenta metida dentro del producto. Se salvó porque el store es de sólo lectura y salió Permission denied: confiar en eso es confiar en un permiso. Ahora escribe por temporal + rename, con un control que comprueba que el fichero del store conserva su contenido y baja a 1 link.

2. La imagen traía el binario, la cuenta… y nadie lo arrancaba. El genesis sólo tenía lo que hornea takana-bootstrap (sshd, console-getty, hammerd): servidor-image.sh no inyectaba las Cards — eso sólo existía en el camino de las imágenes de escritorio. Y ninguna métrica lo dice: targets.py --services responde que el perfil lo habilita, y lo habilita; lo que faltaba era el paso que lleva esa declaración a la imagen.

3. ⚡ trap invalid opcode: el binario sólo corría en la CPU que lo compiló. Con la card ya en el genesis, gitea moría al instante dentro de QEMU-TCG. El sandbox exporta CC apuntando a un wrapper con -mcpu=baseline (y su comentario ya avisaba: «de paso cierra el SIGILL de AVX en qemu64»), y la fase Go del propio builder lo pisaba con CC="zig cc" a secas, que es -mcpu=native. No falla al compilar ni al sellar: falla al ejecutar en otra CPU. Y el ArtifactHash no puede cazarlo, porque la CPU del builder no entra en hash_inputs — dos workers distintos sellan bytes distintos bajo la misma dirección. Arreglado en el builder y en la receta; re-hashea las cinco recetas cgo = true (gitea, usql, sq, gocryptfs, naabu).

Lo que NO está probado, y falta para la mudanza

El app.ini, el usuario del sitio y los datos se pusieron a mano dentro de la VM para llegar al 200. Eso es exactamente lo que el plan de mudanza tiene que traer de gioser — /etc/gitea ya está en scripts/mudanza/rutas-fuera-de-git.txt.

Y la imagen no trae arjectl: tras poner la config hubo que REINICIAR para que arje volviera a intentarlo. El backoff de restart se agota y no hay forma de pedirle a PID 1 que relance un ente en caliente. Para una caja de producción eso es una pieza que falta, no una comodidad.

6.12 🎛️ arjectl en la imagen: control en caliente (2026-09-14)

El §6.11 cerró con «la imagen no trae arjectl, hubo que reiniciar la máquina para arrancar un servicio». Ya lo trae, y no hubo que escribir nada: el cliente existía en tawasuyu y se llama arje-ctl (el crate; el binario es arjectl). Buscarlo por arjectl no lo encontraba, y de ahí salió la conclusión falsa de que faltaba implementarlo — el protocolo (arje-bus::BusRequest) ya traía ListEntes, SpawnCardFromDisk, StopCardFromDisk, KillEnte y EnteStatus.

recipes/arjectl.toml lo construye del mismo commit que arje-zero (98db584f), y eso no es comodidad: el bus es un protocolo entre dos binarios, y un cliente de otro árbol puede conectar y no entenderse con el init. Publica sólo arjectl; el crate también produce un systemctl de camuflaje que acá no se instala — un systemctl en el PATH de una distro sin systemd invita a escribir runbooks con el verbo ajeno.

El hueco que sólo se ve usándolo: el genesis no alcanza

Con arjectl en la imagen, el primer intento falló con un mensaje que nombra la causa:

$ arjectl start gitea
Error: arje-zero rechazó: card gitea: No such file or directory
       (buscada en /etc/arje/cards.d/gitea.json)

start/restart usan SpawnCardFromDisk, que lee /etc/arje/cards.d/<label>.json — y el armado sólo escribía el genesis de la seed. Son dos preguntas distintas: qué arranca solo y qué se puede encarnar a pedido. Con sólo la primera, un servicio que agota su backoff no se puede relanzar sin reiniciar la máquina. inyectar-cards.py escribe ahora los dos árboles (y en cards.d escribe TODAS, no sólo las nuevas: sshd viene del product-rootfs y tampoco era relanzable).

Medido, con la VM arrancada UNA sola vez

la imagen trae	/etc/arje/cards.d/{gitea,sshd}.json
arjectl list-units	tabla con PID, CPU%, MEM, HILOS y reinicios de cada Ente
poner /etc/gitea/app.ini + arjectl start gitea	GET / → 200, sin reiniciar (uptime 6 min)
arjectl restart gitea	el PID cambia (118 → 192) y sigue sirviendo 200

⚠ arjectl start sobre un Ente YA VIVO lo DUPLICA

SpawnCardFromDisk no deduplica por label: encarna otra instancia y arje le da un ULID nuevo. En gitea el síntoma fue unable to lock level db … resource temporarily unavailable seguido de [F] — dos servidores peleando por el mismo estado, con el HTTP intermitente mientras duraba. Para relanzar se usa restart, o se mira list-units antes. Un start idempotente es trabajo de arje, no de esta imagen; queda anotado río arriba.

6.13 🧪 Ensayo con los DATOS REALES de gioser — el gitea de la caja vieja corriendo en takana

Sin tocar gioser (todo lectura) y en la VM desechable. Es el ensayo que faltaba antes de cualquier cutover, y trajo cuatro cosas que no se ven en el papel.

El snapshot de la DB se saca en caliente y sale consistente. sqlite3 gitea.db ".backup …" con el servidor VIVO: 1,5 s para 314 M, pragma integrity_check → ok, 44 filas en repository. Copiar el fichero a pelo con el servidor escribiendo es lo que NO hay que hacer; la API de backup de sqlite existe justo para esto.

Resultado, medido dentro de la VM: <title>GioSer Gitea: Git with a cup of tea</title>, 200, y /explore/repos listando los repos de verdad (sergio/takana, tawasuyu/agora, card, chasqui, cosmos, khipu, llimphi…). Y el clon de uno de los repos copiados: 478 commits, HEAD correcto, ficheros reales.

Los tres detalles que sólo aparecen con los datos puestos

1. El uid del origen no es el del destino. Los ficheros llegan con su uid NUMÉRICO (1001 en el rsync de prueba; el gitea de gioser es 969) y el [[user]] declaraba 916. O se chownean 2 G —lento, y hay que acordarse— o gitea no puede leer sus datos, y eso no falla al copiar: falla al arrancar. La receta pasa a declarar 969, alineado con el origen.

2. El app.ini de gioser escucha en 127.0.0.1:3002, porque allá caddy hace de proxy. Copiado tal cual, la caja sirve — pero sólo desde dentro. El HTTP_ADDR/HTTP_PORT y el ROOT_URL son parte de la adaptación, no del copiado.

3. 🧨 El git de la distro NO puede clonar por HTTP. git clone http://… dentro de la imagen:

   git: 'remote-http' is not a git command. See 'git --help'.
   fatal: remote helper 'http' aborted session
   

   Medido sobre el ARTEFACTO sellado: /usr/libexec/git-core/ trae git-remote-ext, git-remote-fd y git-http-backend (el lado SERVIDOR), y no git-remote-http/-https; strings del binario da 0 referencias a libcurl, pese a que curl está en [deps] build. Nadie lo había notado porque en el hub el git que se usa es el de Artix, no el sellado. Es subcomando-sin-driver otra vez: instalado, con contenido, reproducible… y sin el camino que hace falta. Un hub nuevo no podría clonar el repo por HTTPS. Arreglarlo re-sella git, que es raíz de perfil.base ⇒ unidad propia, no de paso.

6.14 ✅ CUTOVER DEL GITEA — sirve desde la caja, con TLS y por SSH (2026-09-14)

Hecho y verificado desde fuera: git.gioser.net y git.tawasuyu.net responden 200 con TLS válido desde 2.29.29.217, git clone funciona por HTTPS y por SSH:2345, y gitea y caddy corren supervisados por arje-zero en la caja. El gitea de gioser está parado.

Mudanza incremental, no big-bang. Los DNS de gioser son casi todos CNAME → www, así que mover www habría mudado quince dominios cuyos backends siguen allá: 502 en todos. Se convirtió sólo git (en las dos zonas) de CNAME a A propio con TTL 60, que es reversible en un minuto.

La secuencia que funcionó, en orden

1. Caja actualizada: arjectl + gitea + la cuenta gitea:969 + las cards en genesis y cards.d.
2. Datos en dos fases: 1,66 GB / 18 047 ficheros con el origen VIVO (17 s), y en el corte el rsync --delete incremental + sqlite3 ".backup" (integrity_check ok).
3. Parar el origen de verdad. rc-service gitea stop dice «already stopped» con el proceso vivo (el rc-status que miente, §Los tres hechos), y matarlo no alcanza: lo revive arje-zero, que lo tiene como card openrc-gitea con Restart — 9001 reinicios acumulados en el contador. Se paró con arjectl stop openrc-gitea, y para eso hubo que extraer su card del genesis y escribirla en /etc/arje/cards.d/ (§6.12: SpawnCardFromDisk/StopCardFromDisk leen de ahí, no del genesis).
4. DNS por la API de Hetzner Cloud (/v1/zones): el token de hcloud también gestiona el DNS desde la unificación — la API vieja dns.hetzner.com/api/v1 redirige a la consola. Y un PUT sobre el rrset no puede cambiar el tipo: hay que DELETE del CNAME y POST del A.
5. TLS: el primer intento de ACME falló contra gioser (502) porque el challenge salió antes de que propagara; con el DNS ya al día, arjectl restart caddy y certificate obtained successfully.

La identidad SSH se muda con el servicio

git clone ssh://…:2345 daba REMOTE HOST IDENTIFICATION HAS CHANGED: es otra máquina. Se copiaron las claves de host de gioser (/etc/ssh/ssh_host_*) a la caja ⇒ los clones existentes no notan nada. El precio es que cambia también la identidad del :22 de administración, y hay que limpiar el known_hosts propio — a los clientes del servicio no les afecta, que es lo que importa.

Y el sshd del producto escucha sólo en :22: el git por SSH necesitó Port 2345 y que el usuario gitea tenga shell real (su authorized_keys fuerza command="gitea serv …", y con /bin/false no se ejecuta nada).

Lo que esto cambia para la granja

Las 23 recetas que ahora clonan por https://git.tawasuyu.net/… apuntan a la caja. Comprobado tras el cambio: el worker resuelve 2.29.29.217 y git ls-remote responde. La granja depende ya del servidor nuevo, que es el sentido de la mudanza.

Cómo se revierte, si hiciera falta

arjectl start openrc-gitea en gioser y devolver los dos git a CNAME → www. Con TTL 60, minutos.

6.15 Cerrar el intermedio: el viejo apagado de verdad, el :22 cerrado y los datos respaldados

⚠ El gitea viejo había VUELTO a arrancar — y lo arrancó OTRO supervisor

Media hora después del corte, gioser volvía a servir en :3002. arjectl list-units ya no lo mostraba (el stop de arje seguía en pie) y el proceso tenía ppid ≠ 1: lo había levantado OpenRC, que lo tenía en el runlevel default. O sea dos supervisores para el mismo servicio —la card openrc-gitea de arje y el runlevel de OpenRC— y parar uno no para el otro.

rc-update del gitea default   # que no vuelva
rc-service gitea stop         # ahora sí: OpenRC lo arrancó, OpenRC sabe pararlo

Antes del corte pasaba lo contrario (rc-service … stop decía «already stopped» con el proceso vivo, porque quien lo tenía era arje). La pregunta no es «¿está parado?» sino «¿quién lo tiene?», y hay que responderla dos veces.

El origen deja de servir git, y se comprueba que no se rompió lo demás

Los tres bloques (git.gioser.net, git.tawasuyu.net, gitea.gioser.net) salen del Caddyfile de gioser —con respaldo previo, caddy validate y reload—, y quedan 16. Control inmediato: sergio.gioser.net y hifas.gioser.net siguen en 200. gitea.gioser.net pasa a A → la caja, donde ya está su redir.

El :22 cerrado, sin perder el acceso

Administración en 22022, git por SSH en 2345, y el 22 cerrado (Connection refused) para sacarse de encima el barrido de bots. La secuencia importa y es la única segura: añadir el puerto nuevo → reiniciar → entrar por él → sólo entonces quitar el 22. Comprobado en ese orden, y el git clone ssh://…:2345 sigue funcionando después.

🧨 Los datos del gitea NUNCA estuvieron respaldados

respaldo-storagebox.sh respalda el store de artefactos, no /var/lib/gitea. O sea que los 44 repos vivían en una sola copia — en gioser antes, en la caja ahora. La mudanza no lo empeoró, pero sí lo hace urgente: gioser se borra. Hecho hoy desde la caja: snapshot de la DB con el servicio vivo

• rsync a u647150:gitea/ — 1,7 G (datos/ + gitea.db de 314 M).

⚠ Al Storage Box se entra por el puerto 23, no el 22: el 22 da SFTP/SCP restringido y contesta Permission denied (publickey,password), que se lee como «no tengo la clave» cuando la clave está perfecta. Pasó en las dos máquinas antes de mirar el script (SB_PORT=23).

Pendiente: que ese respaldo sea periódico, no de una vez. Es un renglón en el cron de la caja.

6.16 ⚠ SÍ se perdieron dos commits en la ventana — y cómo se detectó

La pregunta correcta después de un cutover no es «¿arrancó?» sino «¿entró algo en el viejo mientras tanto?». Se contesta comparando todos los refs de los dos lados:

for r in <repos>/*/*.git; do git -C "$r" for-each-ref --format="$r %(refname) %(objectname)"; done | sort

845 refs a cada lado, y dos diferencias. Una era esperada (sergio/takana main, el nuevo por delante con los commits posteriores al corte — merge-base --is-ancestor confirma fast-forward). La otra no: tawasuyu/tawasuyu tenía en el VIEJO dos commits que el nuevo no tenía — b69008eb (freebsd) y 02a9535f (shuma, 19:48)—, o sea quince minutos después del snapshot final.

Por qué entraron: el gitea viejo había resucitado (§6.15, OpenRC) y un cliente con el DNS cacheado —el CNAME anterior tenía TTL 600— lo empujó a gioser aunque el autoritativo ya dijera la caja. Las dos condiciones a la vez: un origen que revive y una caché que todavía apunta.

Recuperados con un git push del ref exacto desde el clon local al gitea nuevo; la UI del nuevo ya muestra 02a9535f. Segunda pasada de comparación: 845/845 y una sola diferencia, la esperada. Y del lado de los metadatos, action tenía tres filas posteriores al snapshot (los mismos dos repos) y cero issues, comentarios o releases: no se perdió nada que no fueran esos commits.

La lección para el resto de la mudanza, en orden: (1) bajar el TTL antes del corte, no durante; (2) apagar el origen de verdad —los DOS supervisores— antes de tocar el DNS; (3) comparar refs después, siempre, porque es la única prueba de que no se perdió nada; y (4) dejar el origen apagado un rato antes de borrarlo, precisamente para poder hacer esta comparación.

6.17 ⚠ En gioser conviven arje Y OpenRC — y el prefijo openrc- de las cards ENGAÑA

El usuario avisó: «esa máquina la tengo con arje desde hace meses». Tiene razón, y las dos cosas son ciertas a la vez:

medido
PID 1	arje-zero ✓
la card openrc-gitea	ejecuta sh -c "cd /var/lib/gitea && exec /usr/bin/gitea web …" — no llama a OpenRC
/run/openrc/started/	existe y tiene servicios: NetworkManager, dbus, dhcpcd, fsck, hostname, hwclock, local, localmount…
rc-update show default	listaba gitea

⇒ El prefijo openrc- es herencia del NOMBRE, de cuando arje-absorb tradujo los servicios de OpenRC a cards: la card no pasa por rc-service, encarna el binario directo. Pero OpenRC quedó como residuo ACTIVO y puede arrancar servicios por su cuenta — que es lo que revivió al gitea con ppid ≠ 1 después de que arje lo hubiera detenido.

La regla para el resto de la mudanza: antes de dar un servicio de gioser por apagado, preguntar a los dos:

arjectl list-units | grep <svc>          # la capa de arje (PID 1)
rc-update show default | grep <svc>      # el residuo de OpenRC, que también arranca

Es la-etiqueta-no-es-el-hecho en su forma más cara: un nombre que dice openrc- y no es OpenRC, junto a un OpenRC real que nadie esperaba que siguiera operando.

6.18 Mudados takana.gioser.net y hifas.gioser.net (estáticos puros)

Los dos son ficheros y nada más —sin backend—, así que mudarlos fue copiar 52 K, añadir su vhost al Caddyfile de la caja, mover el DNS de CNAME a A y quitarlos del origen. 200 con TLS válido desde 2.29.29.217, y control de que no se rompió lo demás: sergio.gioser.net sigue en 200 y gioser baja de 16 a 14 vhosts.

Se repitió el patrón de ACME: el primer intento de certificado sale ANTES de que propague el DNS, falla contra el origen y hay que forzar el reintento con arjectl restart caddy. Conviene mover el DNS y recién entonces añadir el vhost — o asumir un restart de más.

Quedan en gioser 14 vhosts, todos con backend propio (uvicorn, php-fpm, tejido, shuma…) o fósiles sin DNS. Ésos no se mudan copiando un directorio: necesitan su servicio del otro lado.

6.19 Los fósiles, barridos: de 19 vhosts a 2

Se midió cada dominio que quedaba —DNS por DoH y HTTP contra la IP del origen— antes de tocar nada. El resultado deja la mudanza mucho más chica de lo que parecía:

clase	cuántos	qué son
fósiles sin DNS	5	aura, api.aura, sigma, kosmofono, api.kosmofono
ya viven en OTRA máquina	3	summa, dev.summa, api.dev.summa → 154.197.1.2
502 permanente	2	mail.sigma (:9000 caído), api.gioser.net (:8000 caído)
mudados hoy	5	los tres de git + takana + hifas
VIVOS y por mudar	2	sergio.gioser.net y api.sergio.gioser.net

Y ninguna de las raíces estáticas de los fósiles existe en disco: /var/www/{aura_frontend, sigma,kosmofono,summa,summa-dev} no están. El Caddyfile servía directorios ausentes — la configuración sobrevivió a sus datos. De los backends, sólo :8770 sigue escuchando, y su dominio ya apunta a otra máquina; :8766 :8765 :9000 :8000 :8768 están caídos.

Los 10 bloques muertos salen del Caddyfile (con respaldo previo, validate y reload), y el control confirma que los vivos siguen: sergio y api.sergio en 200, y los mudados respondiendo desde la caja. gioser pasa de 19 vhosts a 2.

⚠ El único fósil CON datos es terapeuta.ec: 279 M en /var/www/terapeuta, sin DNS y sin vhost. No se borra acá — se anota para la decisión de borrado de la máquina, que es del §6.

Lo que esto cambia: mudar los dos que quedan es un frente acotado —un backend Python en :7378 y una API en :8771— y no las quince cosas que la lista sugería.

6.20 🛟 Cinco binarios rescatados de la nada — el paso que CADUCABA

Antes de tocar sergio.gioser.net apareció lo urgente: cinco procesos vivos cuyo binario YA NO EXISTE en disco (/proc/<pid>/exe → … (deleted)). Sólo existían como inode huérfano: si el proceso muere o la máquina se reinicia, se pierden. Es el paso que el SDD 29 §4.0 undecies llamó «el que caduca», y caducaba de verdad.

tejido · sandokan-mcp · pacha-secretos · puerta-f6e393ffbef3999e · shuma-gateway   (240 M)

Se recuperaron leyendo /proc/<pid>/exe con el proceso vivo, y ya están fuera de gioser: en /work/rescate-binarios/ de la caja y en rescate-binarios/ del Storage Box. Cinco de los trece binarios que nadie provee dejaron de depender de que nadie reinicie nada.

6.21 🧱 sergio.gioser.net: el muro no es el sitio, es glibc

El sitio son tres piezas, y sólo una se puede mudar hoy:

pieza	qué es	mudable a takana
el frontend	117 M de estático (dist/)	✅ copiado ya a /work/www/sergioh
/shuma/*	shuma-gateway en :7378 — ELF dinámico, y su binario estaba BORRADO	⚠ hay que construirlo desde tawasuyu (es Rust del monorepo)
api.sergio	uvicorn con un venv de 405 M	🧱 no, hoy no

El backend es fastapi + uvicorn + pydantic + google-generativeai + **langchain**, con extensiones compiladas …cpython-314-x86_64-linux-**gnu**.so — o sea glibc. Reempaquetar ese árbol de PyPI como recetas no es realista, y correrlo en musl no es posible. Es el caso de uso canónico del ADR 0015 (qorpa: imágenes ajenas glibc enjauladas), que está PROPUESTO y sin implementar del todo.

⇒ El DNS de sergio NO se movió: mover el nombre sin el backend deja el sitio servido y la consola rota. El frontend queda copiado y esperando; el corte se hace cuando exista el camino para las otras dos piezas.

Esto es lo que decide la fecha de borrado de gioser: no es «mudar dominios», es que un servicio vivo no tiene hoy camino a takana. Las salidas son tres y hay que elegir: (1) qorpa, que es para exactamente esto; (2) que ese servicio viva en otra máquina —summa ya lo hace, y su DNS lo demuestra—; o (3) que muera. Ninguna es técnica: es una decisión.

6.22 🧨 El curl de la distro NO PUEDE VALIDAR TLS — y por eso nada se baja por HTTPS

Al ir a traer la primera imagen ajena (qorpa pull), la caja falló con curl failed to verify the legitimacy of the server. El certificado del servidor estaba bien; lo que falta es de este lado:

* CApath: /etc/ssl/certs
* SSL certificate ... unable to get local issuer certificate (20)
$ curl --cacert /etc/ssl/certs/ca-certificates.crt ...   → 200

El curl del corpus está compilado con --with-ca-path=/etc/ssl/certs y sin CAfile, y ese directorio contiene un solo fichero: el bundle. Un capath necesita hash-links (c_rehash) — el índice — y no los hay. Los certificados están, el índice no.

Por qué faltan: recipes/ca-certificates.toml deja escrito el hook /etc/ca-certificates/update.d/certhash, que en Alpine ejecuta apk al instalar. En takana no lo ejecuta nadie: la distro proyecta artefactos, no corre post-install. Es la misma familia que subcomando-sin-driver — todo presente, y el paso que lo conecta no existe.

Alcance: no es sólo qorpa pull. Es takana install --repo https://…, el mirror, y cualquier curl/wget de un script en una caja instalada. No falla al construir ni al instalar: falla la primera vez que la máquina intenta bajar algo. Nadie lo había visto porque el hub usa el curl de Artix.

Arreglado en la receta: los hash-links se generan en el build —donde c_rehash y perl ya existen— y viajan dentro del artefacto, con una guarda que falla ruidosamente si el rehash no produce ninguno. Re-sella ca-certificates, que es raíz de perfil.base.

Apaño mientras tanto, para invocaciones puntuales: CURL_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt (comprobado: 200).

6.23 qorpa en la caja: preflight en verde, y el segundo muro es tar

Con el backend de sergio sin camino a musl (§6.21), la salida elegida es qorpa. Estado medido en la caja:

paso	resultado
userns anidado · overlayfs sin privilegios	✅ ya estaban
disco	❌→✅ /var/lib/hammer vive en la raíz (3 G) ⇒ qorpa se movió a /work (62 G) por symlink
subuid/subgid	❌→✅ rango escrito para root
newuidmap/newgidmap sin capability	❌→✅ setcap aplicado — y el artefacto del store NO se tocó (inodes distintos: en una caja instalada esos binarios son copias, no hardlinks)
veredicto del preflight	de «BLOQUEA 1 · LIMITA 4» a «LIMITA 1»
qorpa pull de Arch bootstrap	baja y verifica el sha256, y falla al desempacar

El segundo muro: el rootfs de Arch es .tar.zst y el tar de la imagen es el de busybox, que no lo entiende — el mismo tropiezo que ya costó el lab (tar: unrecognized option: zstd). zstd SÍ está instalado. ⇒ qorpa pull tiene que descomprimir con zstd -dc | tar -x cuando el archivo es .zst, en vez de dárselo entero a tar. Es un arreglo pequeño en el CLI, y hasta entonces la alternativa es una imagen .tar.gz (Ubuntu base) — que además obliga a reinstalar las deps del venv, porque el de gioser trae extensiones de CPython 3.14 y Ubuntu 24.04 lleva 3.12.

6.24 El TLS arreglado, la distro con nombre, y por qué upgrade se quedaba sin espacio

El curl ya valida. Con ca-certificates re-sellado —119 hash-links en el capath, generados en el build— la caja baja por HTTPS sin ningún apaño: curl -I https://… → 200. El arreglo tardó tres intentos y los dos primeros los cazó la guarda que puse en la propia receta: primero c_rehash no estaba en el PATH (lo instala esa misma receta en /out/usr/bin), y después los certificados no estaban sueltos en usr/share/ca-certificates/ sino en su subdirectorio mozilla/, así que c_rehash sólo veía el bundle y lo saltaba —correctamente— con «does not contain exactly one certificate». Sin la guarda, las tres veces habría sellado un capath vacío.

fastfetch (2.68.1) corre en la caja — y al correrlo apareció otra ausencia:

OS: takana x86_64          ← ahora
Host: vServer (20171111)
Kernel: Linux 7.1.2 · CPU: AMD EPYC-Rome (4) · Memory: 393 MiB / 7.58 GiB

…porque /etc/os-release NO EXISTÍA. La distro era anónima para cualquier programa que no fuera suyo. Se resolvió con una receta propia (os-release, source.dir) en vez de una constante en takana-bootstrap: meterlo ahí re-sellaría el product-rootfs —el baseline del selfhost— por cinco líneas. Sin VERSION_ID ni fecha a propósito: un sello con la fecha del build cambiaría el hash del artefacto, y con él la clausura de toda imagen que lo lleve, cada día y sin motivo.

🧨 /var/lib/hammer es una partición de 487 MB — y ahí viven las generaciones

upgrade apply falló dos veces con No space left on device teniendo 3 G libres en la raíz. Ni el espacio de / ni los inodos (9% usados): el estado de generaciones vive en /var/lib/hammer, que es sda3 y mide 487 MB (la partición «estado» del layout). Cada generación guarda una copia del árbol aplicado — el nuestro son 272 MB — así que dos no caben.

⇒ El estado se movió a /work por symlink, igual que qorpa. Tras eso: ✓ generación 6 aplicada. El layout de la imagen necesita revisión: 512 MB de «estado» no alcanzan para un mecanismo que guarda un árbol entero por generación, y el síntoma (ENOSPC con la raíz medio vacía) apunta al sitio equivocado.

6.25 ✅ CUTOVER DE api.sergio.gioser.net — el primer servicio AJENO que sirve takana (2026-09-15)

https://api.sergio.gioser.net responde 200 con certificado público válido desde 2.29.29.217, y su /api/chat/ contesta con Gemini de verdad. El backend corre dentro de una jaula qorpa (rootfs de Arch pineado por sha256), supervisado por arje-zero como el ente sergioh-api.

Es el servicio que §6.21 declaró sin camino a musl —su venv trae extensiones cpython-314-x86_64-linux-**gnu**.so— y por eso «lo que decide la fecha de borrado de gioser». El camino elegido era qorpa (ADR 0015) y ahora está recorrido de punta a punta.

La coincidencia que lo hizo barato: el Arch bootstrap pineado trae python 3.14.7 y el venv de gioser es 3.14.6. Misma serie ⇒ las extensiones compiladas no son un problema: el venv se rehace adentro con pip, no se copia.

🧨 EL MURO: la jaula no viajaba en NINGUNA imagen

takana qorpa provision abortó con un mensaje correcto y una instrucción imposible:

Error: no encuentro harkaq-exec en /root/.cache/harkaq/harkaq-exec
  construilo:  gcc -O1 -Wall -static -o … scripts/harkaq/harkaq-exec.c

En una caja instalada no hay gcc, ni scripts/, ni árbol de desarrollo. El binario sólo existía como un gcc a mano en la caché de $HOME del hub — o sea que la jaula del ADR 0015 funcionaba únicamente en la máquina donde alguien la había compilado. Y su compañero estaba igual, medido en build-state.json: bwrap sellado desde hace meses con "perfiles": [], CERO perfiles. Los dos se invocan por PATH, y no sólo desde qorpa: takana-build/src/sandbox.rs llama a bwrap en cada build. ⇒ ninguna imagen de takana podía enjaular nada, ni construir. Es subcomando-sin-driver un piso más abajo: el CLI que los llama viaja en todas las imágenes y sus herramientas en ninguna.

Arreglado en la misma unidad de trabajo: recipes/harkaq-exec.toml (nueva, estática musl, b3:cd34954f…, 269 K), bwrap + harkaq-exec declarados en perfil.base, y qorpa.rs buscando el binario también en /usr/bin —el orden es HARKAQ_BIN → árbol de desarrollo → paquete, para que un cambio en la jaula se pruebe sin instalar nada—. ⚠ El pin de la receta va al commit que tocó la fuente (1d9ddcee, del 2026-09-03) y no a HEAD: el repo commitea cada media hora por el cron de la cosecha, y pinear HEAD re-hashearía la receta cada media hora sin que su fuente se moviera.

Los tres tropiezos del camino, todos de la misma familia

1. chown: el rsync preservó el uid 1001 de gioser, y dentro del userns ese uid queda FUERA del rango mapeado ⇒ ni siendo root adentro se puede escribir. python -m venv fallaba con Permission denied en el directorio concedido mientras andaba perfecto en /tmp. El árbol del sitio va a root:root del anfitrión, que es lo que el mapa de la jaula sí alcanza.
2. Una instancia, un run: el segundo qorpa run sobre la misma instancia es rechazado por el kernel («dos overlays con el mismo upper corromperían la capa mutable»). Correcto y hay que saberlo: con el servicio arriba no se entra a la instancia a hacer mantenimiento.
3. ps de la caja no ve los procesos y dig no existe en el hub. Dos herramientas ausentes que se leen como diagnóstico: el primero dice «no hay nada corriendo» y el segundo dejó un until de espera de DNS girando cinco minutos contra una condición que nunca podía cumplirse. Un guardián que no puede pasar nunca se ve igual que uno que todavía no pasó.

Lo que quedó declarado, y lo que no

• instance.toml es la verdad: packages = ["python","python-pip"], network = true (pacman, pip y la propia API de Gemini la necesitan) y un solo dir concedido (/work/sergioh → /srv/sergioh, rw). Ni sockets, ni dispositivos, ni nada más.
• El código y el venv viven fuera de la instancia, en el anfitrión: el upper es caché (D3) y se tira. Y las 84 dependencias quedaron pineadas en requirements.lock — el requirements.txt del sitio no pinea nada, así que sin el lock un recreate traería otras versiones.
• La tarjeta sergioh-api va en /etc/arje/cards.d/ y en el genesis de /ente/seed.card.json (son dos preguntas distintas: qué arranca solo y qué se puede encarnar a pedido, §6.12), con dos guardas que salen 78 nombrando el arreglo si falta la instancia o el venv.
• ⚠ Todavía invoca con HARKAQ_BIN=/usr/bin en la tarjeta: el takana de la caja es el del commit pineado en recipes/takana.toml y no trae aún la búsqueda en /usr/bin. Sale solo cuando se suba ese pin.

El estado de la mudanza tras esto

mudado hoy	api.sergio.gioser.net (DNS: CNAME→www borrado, A→2.29.29.217 TTL 60)
pendiente inmediato	apagar el sergioh_backend de gioser cuando propague (OpenRC y arje: rc-update del + rc-service stop + arjectl stop openrc-…, §6.17). Hasta entonces sirve a los resolutores que aún tengan el CNAME cacheado
lo que falta de sergio.gioser.net	el frontend ya está copiado en /work/www/sergioh; falta /shuma/* → shuma-gateway (:7378), que es glibc dinámico y cabe en esta misma jaula (el binario está rescatado en /work/rescate-binarios/) pero cuelga de shuma-daemon, que es un sistema entero, no un binario
y los otros dos vivos	gioser.net/www (estáticos + /hooks/* en :8770 + /reencuentro con php-fpm) y tawasuyu.net (estático, raíz en /mnt/vvv/tawasuyu)

6.26 ✅ tawasuyu.net y gioser.net MUDADOS — y el PHP que no existe en el corpus (2026-09-15)

Los dos sitios que quedaban con tráfico real sirven desde la caja takana, con TLS público y verificados desde fuera. Los servicios viejos siguen corriendo en gioser a propósito (decisión del usuario: mudar el DNS y dejar el origen vivo, para poder volver en un minuto).

dominio	qué es	estado
tawasuyu.net, www.	landing + /pkg wasm + /descargas (3,8 G)	200 desde 2.29.29.217
gioser.net, www.	5 raíces estáticas (428 M) + /reencuentro con PHP	200 desde 2.29.29.217
sergio.gioser.net	frontend + /shuma/*	se queda en gioser: su consola no tiene camino todavía

sergio dejó de ser un CNAME → www y tiene su A propio (apuntando a gioser, sin cambio visible). Sin eso, mover www se lo habría llevado puesto — es la trampa del §6.14 vista a tiempo: en esta zona casi todo cuelga de www. Lo que sí quedó colgando son tres fósiles (api, mail.sigma, monitor): antes daban 502 desde gioser y ahora fallan el TLS contra la caja. Están muertos hace meses; se anotan, no se mudan.

Dos cosas que el log de accesos decidió mejor que cualquier intuición:

• La raíz de tawasuyu.net en gioser era el monorepo entero (145 G) servido por HTTP. El log dice que las únicas rutas con tráfico son /, /descargas y /web ⇒ se replicaron sólo los dos subárboles que el sitio usa (1,2 M + 3,8 G), con la MISMA estructura para que cada rewrite siga siendo el mismo.
• /hooks/* NO se muda: lo atiende webhook-deploy.py, que redespliega aura_*, sigma_*, summa_* y brahman — los cuatro son fósiles del §6.19, y tiene cero peticiones. Muere con la caja vieja. Un servicio vivo que sólo sirve a muertos es basura, no deuda.

PHP: la segunda jaula, y por qué no entra al corpus

/reencuentro/ es una página con un guardar.php. PHP no está en el corpus y no tiene por qué estar: lo sirve php-fpm 8.5.10 dentro de la instancia gioser-php (ADR 0015), por 127.0.0.1:9000, supervisado por arje. Control contra el original, en los dos sentidos: POST con la trampa anti-robots → {"ok":true} 200 igual que en gioser; GET → 405 igual que en gioser.

⚠ El webroot entra a la jaula EN LA MISMA RUTA (/work/www/gioser-web): el SCRIPT_FILENAME de FastCGI es una ruta absoluta del anfitrión, y si adentro viviera en otro sitio php-fpm contesta «File not found» sin decir cuál. Y la config de php-fpm vive en el ANFITRIÓN (/work/etc/gioser-php/php-fpm.d/) y entra por concesión: el upper de la instancia es caché y recreate se la llevaría.

🧨 Los padres que inventa bwrap son 0700 — y eso deja la concesión fuera de alcance

El muro real del día, y es general, no de PHP:

$ curl -X POST https://gioser.net/reencuentro/guardar.php
File not found.          ← y el fichero ESTÁ, montado, con sus modos correctos

Para montar en /work/www/gioser-web, bwrap tiene que crear /work y /work/www —que la imagen de Arch no trae— y los crea drwx------ root. Adentro somos root, así que todo a mano funciona; pero un servicio que baja de privilegio (php-fpm a http, o cualquier instancia con run_as) no puede ni atravesarlos. Medido con el control que lo separa de una confusión de permisos del anfitrión: como http, leer un fichero de la imagen funciona y leer el directorio concedido da Permission denied.

⇒ grants_to_args crea ahora los ancestros que faltan con --perms 0755 --dir, y sólo los que la imagen no trae: hacerlo sobre /etc o /home le cambiaría los modos a la imagen. Con test que falla a propósito si la condición se rompe (left: ["/etc","/etc/php"] contra right: ["/etc/php"]). Misma familia que el --perms 1777 que ya hacía falta antes del --tmpfs /tmp.

⚠ La caja corre el takana del commit pineado en recipes/takana.toml, así que allá el arreglo todavía no está: el camino se abrió a mano en el upper de la instancia (chmod 755 /work /work/www). Es exactamente lo que el arreglo vuelve innecesario en el próximo takana upgrade.

Y el estado de rust y de claude, que no es el que parece

• rust está en la caja pero no instalado: rust-toolchain-bin está sellado en el store y declarado en perfil.servidor, y rustc 1.97.0 corre invocándolo por su ruta del store — pero no está en el PATH porque la caja se instaló antes de esa declaración. Proyectarlo son 798 M sobre una raíz de 5,8 G con 2,9 G libres: entra, pero el layout de la imagen (§6.24) merece la revisión primero.
• claude no está mudado, y es otro caso de jaula: el binario de gioser es glibc dinámico (/lib64/ld-linux-x86-64.so.2), o sea el mismo montón que el backend de sergio. Lo que pesa no es el binario sino su estado: 6,8 G de ~/.claude, de los cuales 5,3 G son jobs y 976 M projects — y ahí vive la memoria, indexada POR RUTA del repo. Mudarlo es una decisión sobre qué se lleva, no una copia.

6.27 🧦 squid mudado — y la jaula que arrancaba DEGRADADA cuando la arranca un init (2026-09-15)

El proxy de salida sirve desde la caja: squid 7.7 en 2.29.29.217:1137, con la config, el passwd de los tres usuarios y las dos ACL de gioser tal cual, dentro de la instancia squid y supervisado por arje. El de gioser sigue vivo e intacto (7.6), así que los clientes que apuntan a la IP vieja no se enteraron.

Es un servicio con gente encima: el access.log del origen mostraba CONNECT api.anthropic.com y CONNECT claude.ai en el minuto anterior a mudarlo, desde IPs de Venezuela y con tres usuarios autenticados. Por eso se mudó entero y sin reescribir nada.

Control en los dos sentidos: desde una IP no autorizada, 407 Proxy Authentication Required —igual que el original—; desde localhost, que su propia config permite, TCP_TUNNEL/200 a claude.ai y a api.anthropic.com.

Los cuatro muros, y el cuarto es el que vale

1. provision con la config ya montada aborta: pacman dice «squid.conf.default exists in filesystem» porque el paquete quiere escribir sus defaults donde está la concesión. ⇒ provisionar primero, montar después. Queda escrito en el manifiesto.
2. /dev/shm lo crea bwrap 0755 root, y squid —que baja a proxy— muere con FATAL: shm_open(...): (13) Permission denied. Un chmod 1777 en el arranque.
3. El fichero de PID sobrevive entre corridas y SIEMPRE parece fresco: cada run tiene su propio namespace de PIDs, así que el /run/squid.pid de la corrida anterior dice PID 2… y en la nueva hay un PID 2 vivo. Squid concluye «Squid is already running» y se niega. ⇒ rm -f en el arranque. Es una trampa general de cualquier servicio con pidfile dentro de una jaula con --unshare-pid.
4. 🧨 El rango de subuid se buscaba por $USER — y un init no lo pone. Bajo arje la tarjeta arranca con PATH y HOME y poco más; el nombre salía vacío, no había rango, y la jaula caía al userns de un solo id. Squid moría en setgid(15): (22) Invalid argument y el supervisor lo reintentaba 80 veces. El aviso de qorpa era correcto y estaba impreso —«no hay rango para "" en /etc/subuid»— pero lo que se ve en el bucle es el error de squid, no el nuestro: la degradación silenciosa la paga el de más abajo. Y el mismo comando a mano, desde una shell con $USER, funcionaba perfecto: el síntoma dependía de quién lo arrancaba. ⇒ nombre_de_usuario() deriva el nombre del uid real leyendo /etc/passwd, y el entorno pasa a ser el último recurso. El uid es el hecho; $USER es una etiqueta (la-etiqueta-no-es-el-hecho). Las tarjetas llevan además USER/LOGNAME explícitos, que era el arreglo del día.

⚠ arjectl start sobre un Ente ya vivo lo DUPLICA (se vio con gioser-php: dos entes, uno peleando por el mismo upper). Y matar el proceso de adentro no libera la instancia: el takana qorpa run de afuera sigue vivo y el siguiente run choca. Para relanzar, stop y después start, mirando status en el medio.

Y la pregunta que corresponde: ¿no va en una receta?

Sí, y sigue pendiente. El propio §6.2 pone a squid en la lista de recetas que esta mudanza tiene que producir. Lo de hoy fue la vía URGENTE —el servicio estaba en uso y la jaula lo levanta en minutos, sin compilar nada—, no la respuesta final. La diferencia con php-fpm importa: PHP no queremos que entre al corpus (es un intérprete ajeno al proyecto, y la jaula es su lugar definitivo), mientras que squid es C, se compila con el lab y su sitio natural es una receta como la de gitea. Cuando esté, la instancia se tira: el manifiesto es descartable a propósito.

6.28 📦 squid YA NO ESTÁ ENJAULADO: corre desde el corpus (2026-09-15)

La jaula del §6.27 duró unas horas, que es lo que tenía que durar. Hoy el proxy de producción es el artefacto sellado b3:932ba096…, proyectado en la caja y arrancado por arje sin bwrap de por medio: pid 11548 · uid=968 · exe=/usr/sbin/squid. La instancia qorpa/squid se borró — el manifiesto es descartable por diseño (D3) y esto es exactamente para lo que existía esa salida.

recipes/squid.toml: 7.7, estático de verdad (binario y los cuatro helpers), [[user]] proxy con uid 968 y [[service]] del SDD 30. Declarado en perfil.servidor como paquete y en servicios.

La config NO viaja en el paquete y es a propósito: squid.conf, el passwd de los tres usuarios y las dos ACL (412 K, 40 IPs autorizadas) son datos del SITIO. El servicio los comprueba al arrancar y sale 78 nombrando cuál falta, en vez de dejar un bucle de reinicios.

Los tres muros de la receta, en orden

1. La URL de upstream devolvía una página HTML de 8985 bytes con un 200. squid-cache.org/Versions/v7/squid-7.7.tar.xz no es el tarball. Pinear su sha256 habría anclado la receta a una página de error — y habría «funcionado» hasta el primer build. Va el release de GitHub, que además trae configure generado.
2. 🧨 --export-dynamic desactivaba el enlace estático, y el binario sellaba igual. El primer artefacto tenía usr/sbin/squid dinámico con NEEDED libc.so mientras sus helpers salían estáticos: inerte en cualquier imagen sin cargador (needed-colgante-libstdcxx) pese a link = "static". La cadena tiene tres eslabones y ninguno es obvio: squid_LDFLAGS trae -export-dynamic (para módulos eCAP, apagados) → el wrapper del lab quita -static de cualquier enlace que mencione --export-dynamic, a propósito, para poder enlazar las .so dlopen-ables de Python → y libtool vuelve a añadirlo solo en cuanto hay un -dlopen, así que sacarlo de la variable no alcanza. Se vacía export_dynamic_flag_spec en el libtool GENERADO, con guarda que aborta si el campo no aparece: un sed que no acierta deja pasar el problema y el binario sale dinámico sin que nada falle. ⚠ Y -dlopen force no sobra: vaciar squid_LDFLAGS entero rompe el enlace con undefined symbol: lt__PROGRAM__LTX_preloaded_symbols, que emite el propio libtool porque hay un -dlopen. De los dos flags estorba uno; distinguirlos costó un build y adivinar cuesta lo mismo.
3. --disable-log-daemon-helpers compilaba perfecto y no arrancaba. El default de access_log es daemon:, así que sin log_file_daemon squid muere con FATAL: logfile_daemon /usr/lib/squid/log_file_daemon: (2) No such file or directory. Sólo se ve levantando el servicio con la config real; el sellado, el hash y el -k parse pasan los tres. Es la familia de subcomando-sin-driver otra vez.

El control que hay que correr antes de tocar producción

Con la config REAL del origen, en el hub y en un puerto aparte: -k parse sin FATAL, arranque completo, CONNECT claude.ai y CONNECT api.anthropic.com con TCP_TUNNEL/200, el access.log escrito por el log daemon, y el basic_ncsa_auth leyendo el passwd de verdad (control negativo: con una clave mala contesta ERR Wrong password). Los dos primeros intentos de esta receta habrían llegado a producción sin ese control: el binario estaba sellado y el hash era estable las dos veces.

6.29 ⏱️ La caja tiene HORA, LATIDO y ROTACIÓN — y el respaldo del gitea dejó de ser a mano (2026-09-15)

planear.py --revisar sobre el censo del día ordena lo que queda, y lo primero de la lista no eran los servicios del usuario sino tres capacidades que ninguna métrica reclama: el disparador periódico, la hora y la rotación de logs. Los tres paquetes ya estaban sellados y declarados en perfil.servidor desde que ese perfil nació — lo que faltaba era el eslabón que los ARRANCA.

	antes	ahora
chronyd	la caja iba 15 s atrasada y nadie la corregía	stratum 3 contra ntp{1,2,3}.hetzner.de, 0,000005 s de NTP
crond	no existía el latido	ejecuta el crontab real, verificado con una entrada * * * * *
logrotate	/var/log/squid sin rotar	diario con squid -k rotate, 14 copias
respaldo del gitea	a mano, una vez (§6.15)	17 3 * * *, con el snapshot consistente de la sqlite

El respaldo, medido: scripts/respaldo-gitea.sh sube 44 repos (23 sergio + 21 tawasuyu, 1,5 G) y un gitea.db de 332 M tomado con .backup —consistente con el servidor vivo— al Storage Box. El control no es que el script salga 0: es contar los repos de los dos lados, que es lo que se hizo.

⚠ chrony y cronie NO declaraban [[service]], como squid antes: el paquete llegaba a la imagen y no lo arrancaba nadie. Ahora lo declaran (fuera de hash_inputs: los hashes no se movieron) y perfil.servidor los habilita en servicios.

⚠ La config va aparte y el servicio sale 78 si falta, igual que gitea: a qué NTP se pregunta y qué logs se guardan son decisiones del SITIO. Una caja que se sincroniza contra un pool que nadie eligió es peor que una sin hora, porque nadie lo mira.

Tres cosas medidas que valen más que el resultado

1. La deriva era de gioser, no de la caja. Antes de chrony la caja iba 15 s atrás; después, la caja quedó en hora de NTP y el hub pasó a estar 3 s adelantado. La máquina de referencia era la equivocada — medir «contra el otro» sin un tercero no dice quién está mal.
2. El spool de cronie es /var/spool/cron/<usuario>, no …/crontabs/<usuario>. crontab -l mostraba las entradas y crontabs/ estaba vacío. El día que alguien restaure un crontab a mano en el sitio equivocado va a tener un fichero perfecto que nadie lee. Lo decide un control y no la intuición: meter un * * * * * en el crontab REAL y ver si dispara.
3. 🧨 sqlite3 seguía inerte en la caja (Error relocating: compressBound: symbol not found): es el último de los 23 binarios del §6.4, y le faltaba zlib-shared — sellado y declarado en perfil.base desde el 2026-09-11, pero la caja se instaló antes. Sin él no había snapshot consistente, o sea que el respaldo habría copiado la sqlite a lo bruto. Un paquete declarado no es un paquete instalado: en una caja viva, lo que vale es lo que el upgrade proyectó.

6.30 ⚰️ Tres servicios que MUEREN — y el cortafuegos que no puede correr todavía (2026-09-15)

Decisión del usuario sobre lo que quedaba del censo, y las tres son «no se muda»:

servicio	por qué muere
qdrant (:6333, :6334)	es la base vectorial de gioser_api, y ese backend es un fósil: api.gioser.net da 502 permanente desde el §6.9. Una base sin consumidor no se muda. La receta recipes/qdrant.toml queda en el catálogo —catálogo ≠ imagen, y eso no es deuda—, pero no entra en ningún perfil.
act_runner (:41027)	el runner de CI del gitea, un binario suelto en ~/.local/bin que nadie provee. Muere con la caja; si mañana hace falta CI, entra por receta y no por un binario copiado.
fail2ban-server	tawasuyu ya tiene el sustituto, y es mejor: shared/cortafuegos (§1 de su SDD-ENTRADA) no mira logs con un daemon, usa dos sets dinámicos del kernel (ban4/ban6, flags dynamic, timeout) con limit rate over N/minute por IP de origen. El ban lo aplica nftables sin proceso y sin latencia; fail2ban es un daemon de Python leyendo ficheros para hacer lo mismo peor.

🧨 Pero el sustituto NO PUEDE CORRER: el kernel de la caja no trae nf_tables

$ nft list ruleset
netlink: Error: cache initialization failed: Invalid argument

nft 1.1.6 está instalado (nftables es raíz de perfil.servidor y está sellado). Lo que falta está un piso más abajo, en el .config que el artefacto publica:

CONFIG_NETFILTER=y          ← sí
CONFIG_NF_CONNTRACK=y       ← sí
# CONFIG_NF_TABLES is not set   ← AQUÍ
# CONFIG_NETFILTER_ADVANCED is not set   ← y ésta es la causa: NF_TABLES cuelga de ella

Es otra vez la lección del §6.4 muro 1: la receta dice lo que se CAMBIÓ; sólo el .config sellado dice lo que QUEDÓ. linux-generic sale de un make defconfig, y defconfig deja NETFILTER_ADVANCED apagado, que arrastra a NF_TABLES con él.

⇒ Hoy la caja no tiene cortafuegos de ninguna clase: ni fail2ban (que no se muda), ni el sustituto (que no arranca), ni una regla. Con :22022, :2345, :1137, :80 y :443 públicos, eso hay que decirlo entero y no dejarlo implícito. La cura es un kernel con CONFIG_NETFILTER_ADVANCED=y + NF_TABLES (y NFT_CT, NFT_LIMIT, NFT_COUNTER, NFT_LOG), que es trabajo del SDD 22 y termina en un reinicio de la caja de producción.

La mitigación que NO depende del kernel, hecha hoy

El sshd de la caja ofrecía password y keyboard-interactive — su config eran cuatro líneas y ninguna decía nada de autenticación, así que regía el default de OpenSSH. Sin cortafuegos y sin fail2ban, eso es exactamente la puerta que aquéllos cerraban. Ahora es sólo claves, con los cuatro controles corridos: la clave entra ✅, :22022 contesta Permission denied (publickey) sin ofrecer contraseña ✅, :2345 igual ✅, y el git ls-remote por SSH sigue funcionando ✅.

Lo que enseña: una defensa que se muda tiene que mudarse con su capacidad, no con su nombre. Decidir «fail2ban muere porque tenemos algo mejor» es correcto y deja un hueco abierto hasta que ese algo mejor pueda ejecutarse. Entre la decisión y la capacidad hay un kernel de por medio.

6.31 ✅ La caja arrancó con nf_tables — y el init la levantó ENTERA sola (2026-09-15)

$ nft list ruleset
$                       ← sin error: vacío, que es lo correcto en una caja sin reglas

El kernel b3:63fdd57c… bootea, y con él nft funciona por primera vez en una máquina takana. Comprobado con el mecanismo exacto que reemplaza a fail2ban, no con una regla de adorno: un set ... flags dynamic; timeout 10s con add @ban4 { ip saddr timeout 10s limit rate over 5/minute } drop — aceptado por el kernel (rc=0) y releído tal cual. Eso es el ban por IP dentro del kernel, sin daemon.

Lo que el reinicio probó de paso, y vale más que el kernel

La Semilla levantó los OCHO entes sola, todos con ↻ 0: sshd, gitea, caddy, squid, crond, chronyd, sergioh-api y gioser-php — o sea los dos servicios enjaulados en qorpa (con su newuidmap, su overlay y su harkaq) arrancan desde el genesis igual que un binario nativo. Todo lo que se fue editando en /ente/seed.card.json a lo largo del día era, hasta este momento, una declaración sin probar: un reinicio es el único examen que toma.

Desde fuera, al minuto: los siete dominios en 200, el proxy en 407 y git ls-remote por SSH:2345 devolviendo el commit. Cero intervención.

⚠ reboot NO reinicia una caja con arje-zero

reboot de busybox le pide a PID 1 que lo haga, y arje-zero no implementa ese protocolo: el comando vuelve, no dice nada, y la máquina sigue arriba (up 4 days después de «reiniciar»). Lo que sí funciona es reboot -f, que llama a reboot(2) directo saltándose al init. Con sync antes, claro: el corte es duro por definición.

⇒ Y falta la pieza: un init que gobierna un servidor de producción tiene que atender un apagado ordenado. Hoy la única vía es el corte duro, que ya costó el write_atomic no durable del §6.13.

🧨 Casi reinicio el HUB por un backtick en un echo

Escribiendo el aviso del reinicio, el mensaje decía … no atiende el `reboot` normal … dentro de comillas DOBLES. La shell ejecutó lo que había entre backticks: reboot, en gioser. No pasó nada por una razón que no es mérito de nadie —la sesión no es root y OpenRC contestó «you must be root»— y el hub lleva 11 días arriba, con la granja y el cron encima.

Es la tercera vez en el día que un backtick dentro de un texto se ejecuta (heredoc-sin-comillas-ejecuta-comentarios), y las dos anteriores sólo se comieron un comentario. La regla deja de ser de estilo: nunca un backtick dentro de comillas dobles en una shell — comillas simples, o $(printf '%s' …), o directamente no poner el acento grave en el texto.

Lo que queda para cerrar el frente del cortafuegos

El kernel ya no estorba; falta la política: PoliticaEntrada (.ron) → generate-input → apply-input del cortafuegos de tawasuyu, con los puertos reales de la caja (22022, 2345, 80, 443, 1137). ⚠ Y hay que aplicarla con interruptor de hombre muerto (aplicar, esperar, y flush automático si nadie confirma): una regla mal puesta en una caja sin consola serie deja la única salida en hcloud server enable-rescue.

6.32 🧱 El cortafuegos, puesto — y el primer baneado fui yo (2026-09-15)

La caja filtra: table inet tawasuyu_input, policy drop, 15 reglas de puerto, y el set ban4 llenándose solo con lo que golpea desde internet. A los pocos minutos: 27 IPs baneadas y paquetes tirados por el contador. Eso es el reemplazo de fail2ban funcionando sobre tráfico real, dentro del kernel y sin daemon.

La política vive en scripts/servidor/cortafuegos-entrada.ron (formato PoliticaEntrada del cortafuegos de tawasuyu) y declara los cinco puertos públicos: 22022 admin, 2345 git, 80, 443 y 1137 el proxy. El reglaset se genera con cortafuegos generate-input en el hub —el binario es glibc y la caja es musl— y se aplica allá con nft -f.

🧨 El primer baneado fui yo, en segundos

Aplicada la primera versión, desde fuera: ssh ✅, https ✅… y http, el proxy y el git por SSH muertos. Al minuto, la caja entera dejó de contestarme.

La causa no es una regla mal escrita: el set @ban4 es UNO SOLO para todos los servicios, y la regla ip saddr @ban4 drop está antes que todo. O sea que pasarse de tasa en un puerto te tira en todos. Y el nuevas_por_min: 5 del puerto de administración —correcto contra internet— es exactamente lo que me pasa a mí: cada comando remoto de esta sesión es una conexión nueva.

Lo que devolvió la máquina fue el interruptor de hombre muerto: antes de aplicar se deja programado un nft flush ruleset a 180 s, y sólo se desarma si la verificación desde fuera sale bien. Sin consola serie, esa es la diferencia entre un susto y un rescue.

⚠ Y el tipo ya lo avisaba. PoliticaEntrada tiene un campo confiables cuyo comentario dice, palabra por palabra, lo que me acababa de pasar: «un nuevas_por_min chico en el puerto de SSH es exactamente lo que se quiere contra internet y exactamente lo que te deja afuera cuando el que abre seis sesiones en un minuto sos vos». Copié el .ron de ejemplo en vez de leer el tipo. Es lei-hasta-donde-me-daba-la-razon otra vez, y la cura fue una línea: confiables: ["204.168.193.248", "154.197.1.13"] — el hub y el worker, que se aceptan antes de la lógica de tasa y por lo tanto no pueden entrar al set.

Lo que este kernel todavía no puede, dicho en voz alta

nft -c rechazó cinco reglas antes de aplicar nada:

tcp dport 22022 ct count over 10 drop
                ^^^^^^^^  Error: Could not process rule: No such file or directory

ct count es CONFIG_NFT_CONNLIMIT, que el kernel de hoy no trae (el .config lo dice: # CONFIG_NFT_CONNLIMIT is not set). Es el tope de conexiones concurrentes por servicio — el ban por tasa, que es lo que reemplaza a fail2ban, no depende de él. Las cinco reglas quedan comentadas, no borradas, en el fichero que se aplica: lo que la política declara y el kernel no puede tiene que verse. El símbolo ya entró a recipes/linux-generic.toml y vuelve con el próximo kernel; hasta entonces el mensaje —que no nombra la opción que falta— queda explicado ahí mismo.

Que sobreviva al reinicio: un servicio oneshot

recipes/nftables.toml declara ahora su [[service]] con lifecycle = "oneshot": cargar un reglaset no es un daemon, es un acto. Va primero en el genesis, antes que sshd y los demás: entre que la red está y que las reglas cargan, la caja está abierta, y ese hueco se hace lo más corto posible. Probado de verdad — nft flush ruleset y después arjectl start cortafuegos: las 15 reglas vuelven.

Su guarda sale 78 nombrando el fichero si el reglaset no está, en vez de dejar la caja sin filtrar creyendo que está protegida: un cortafuegos ausente y uno vacío se ven igual desde afuera hasta que alguien prueba.

6.33 🧨 EL CORTAFUEGOS BANEÓ A LOS USUARIOS DEL PROXY — y squid nunca se cayó (2026-09-16)

El usuario preguntó si el proxy estaba caído. No lo estaba: el ente squid llevaba horas corriendo con ↻ 0, escuchando en :1137 y contestando 407 a quien preguntara. Lo que estaba caído era el acceso: el cortafuegos que puse ayer estaba baneando a los usuarios autorizados.

La prueba, en una línea: 154.197.1.2 —una IP que está en la ACL de squid, o sea gente con contraseña— apareció en @ban4. Y el contador del ban iba en 38.246 paquetes tirados.

La causa no es la tasa: es la RÁFAGA

tcp dport 1137 ct state new add @ban4 { ip saddr timeout 300s limit rate over 300/minute burst 5 packets } drop

burst 5 significa «tolero cinco conexiones por encima del promedio». Un navegador o un agente detrás de un proxy abre decenas de CONNECT en el mismo instante, aunque su promedio sea bajísimo: seis de golpe y ya estás en el set. Y como @ban4 es UN SOLO set consultado antes que todo, caer por el puerto del proxy te tira también el web y el git.

⚠ El tipo del cortafuegos ya traía el campo (rafaga, default 5) con un comentario que decía «para un servicio web va alto (100-200)». Otra vez: leí el .ron de ejemplo y no el tipo.

Lo que se hizo, en orden de urgencia

1. nft flush set … ban4/ban6 — servicio restaurado en el acto.
2. Los usuarios del proxy a confiables: la misma lista que la ACL de squid (21 IPs + 5 redes). Un proxy que autentica no necesita que el kernel le cuente las conexiones a un usuario conocido; lo que el ban tiene que parar son las fuentes DESCONOCIDAS.
3. rafaga por servicio, según su clientela: ssh 5 · git 20 · web 100 · proxy 200. Y el proxy pasa a 1200/min con ban de 60 s: red de contención contra un flood, no control de uso.
4. Control después: cero autorizados en el set, 24 baneados (escáneres, que es lo que se quiere), y tráfico real pasando — 154.194.14.37 … CONNECT api.deepseek.com:443 sigma, 298 K tunelados.

⚠⚠ Y un fallo de método que casi lo tapa: nft -f SUMA a la tabla existente. Cargué el reglaset corregido encima del viejo y quedaron 30 reglas: las viejas ADELANTE, así que los confiables nuevos no llegaban a evaluarse nunca. Se vio contando (grep -c dport daba 30 y no 15) y mirando qué saddr salía primero. Por eso cortafuegos apply-input borra la tabla antes de cargar — usar nft -f a pelo se saltea esa mitad.

La hora exacta, reconstruida del access.log

El usuario preguntó a qué hora se bloqueó, y el log lo dice sin ambigüedad. Su IP —45.234.61.160, autenticada como sergio, 2709 peticiones— tuvo estos silencios:

silencio	desde	hasta
93,2 min	16-09 11:59:37 UTC	13:32:49 UTC ← cuando vacié los sets
50,1 min	10:44:58	11:35:06
10,0 min	11:45:06	11:55:05

Los tres son el timeout de 10 minutos del ban disparándose una y otra vez: cada vez que volvía, su primera ráfaga lo baneaba de nuevo. 154.197.1.2, que usa el proxy de forma sostenida pero sin ráfagas, sólo perdió huecos de 5 minutos.

🧨 Y la exención que tenía no servía: su IP no estaba en la red eximida. La ACL histórica de squid exime 45.234.60.0/24 y él entra desde 45.234.61.160 — una red de al lado. Parecía cubierto y no lo estaba: la pertenencia se MIDE (ip in red), no se deduce del parecido del prefijo. Con el /23 que nft dedujo al unir los dos /24, ahora sí.

Y la decisión de fondo: en un servicio que YA AUTORIZA, no va límite por tasa

El uso real de esta caja es intensivo —varias sesiones de agente en paralelo, cada una abriendo túneles a la vez—, y un límite calibrado para «una persona normal navegando» no protege de nada: el atacante ajusta su ritmo, el usuario no puede trabajar más despacio. Squid ya pide usuario y contraseña y tiene su ACL; el ban por tasa ahí no agrega seguridad, agrega cortes. Queda apagado (60000/min, ráfaga 1000: números que ningún cliente real alcanza) y contra un flood queda el tope GLOBAL syn_nuevas_por_seg, que no distingue usuarios ni banea a nadie por ser rápido.

Lo que esto enseña del cortafuegos como herramienta

Un cortafuegos correcto y un cortafuegos usable no son lo mismo, y la diferencia no se ve al aplicarlo: las reglas cargan, el nft -c pasa, los sitios responden, y el daño aparece sólo cuando un cliente REAL hace lo que los clientes reales hacen. El único control que lo habría cazado antes es el que no corrí: una ráfaga de conexiones desde una IP que NO esté en confiables.

6.34 📋 Censo del 2026-09-16: queda UN vhost — y el censo sin privilegio no veía 572 M

Censo fresco de gioser (censar.py --local --probe-dns, sólo lee), para saber qué falta de verdad en vez de arrastrar la lista del 11.

  servicios   vivo 23 · no-declarado 17 · declarado-muerto 81 · descartados 6
  dominios    apunta-aca 1 · ya-mudado 6 · fosil-sin-dns 7
  datos       /home 25 G (copiar 27 G) · /var/lib 8,1 G · /opt 1,2 G · /var/www 288 M

De los 29 dominios del Caddyfile sólo UNO sigue sirviéndose desde gioser: sergio.gioser.net. Comprobado desde fuera, resolución + HTTP, no por el fichero de config:

dominio	resuelve a	HTTP
tawasuyu.net · gioser.net · git.tawasuyu.net · takana.gioser.net · hifas.gioser.net · api.sergio.gioser.net	2.29.29.217	200
gitea.gioser.net	2.29.29.217	301
sergio.gioser.net	204.168.193.248 (gioser)	200
api.summa.gioser.net	154.197.1.2 (otra máquina)	—
terapeuta.ec, andino.ec, api.sigma… y 4 más	sin DNS	—

⇒ la lista de «tres vhosts» del §9 quedó vieja: gioser.net y tawasuyu.net ya están mudados (§6.26) con su origen vivo a propósito. Lo único que ata el DNS a gioser es la consola de sergio.

El rescate del §6.20 sigue vigente — y caduca de verdad

Seis procesos corren hoy desde un inodo borrado. Cuatro tienen su copia en work/mudanza/rescate/ y el sha256 del /proc/<pid>/exe vivo coincide bit a bit con lo rescatado el 12. Los otros dos (/usr/local/bin/tejido y /usr/local/bin/shuma-daemon) no están en el rescate, pero en disco hay una versión más nueva de cada uno (hoy 11:13 y 14:20): no se perdió nada porque el usuario los está reconstruyendo. La lección es la del §6.20 y no cambió: ese paso caduca, y quién caducó se ve mirando /proc, no el directorio.

🕳️ Y el hallazgo del día: -e contesta «no existe» cuando lo que pasa es «no puedo mirar»

El censo tiene tres estados a propósito (ausente / sin_permiso / ok) porque un ls sin permiso se lee igual que un directorio vacío. Pero el tercer estado sólo se detectaba sobre la propia ruta: cuando el que no deja pasar es un ANCESTRO, [ -e "$p" ] contesta que no, y la ruta caía en ausente — que el censo descarta sin decir nada.

  /root/.local        drwx------ root root        ← 0700
  /root/.local/bin    572 M de binarios a mano que NINGÚN paquete provee

Corrido como sergio, el censo decía que /root/.local/bin no existe. Corrido como root, son 572 M de exactamente la clase que la mudanza no puede reconstruir: binarios puestos a mano. Arreglado —si un ancestro existe y no es atravesable, el estado es sin_permiso— y probado en los dos sentidos, que es lo que distingue un guardián de un adorno:

  ancestro 0700 de otro dueño   →  sin_permiso   (y sale en el ⚠ del resumen)
  ruta que NO existe de verdad  →  ausente       (y NO se reporta)   ← el control que tiene que pasar

Con el arreglo, el censo como sergio pasa de 2 rutas ciegas a 13 — entre ellas el home entero de artix, que antes no figuraba de ninguna manera. El censo se corre como root; la lista de ciegas es el recibo de lo que una corrida sin privilegio no puede ver.

Lo que queda, y por qué no lo decide el programa

Descontados los que ya se decidieron (§6.30: qdrant, act_runner, fail2ban mueren) y los que provee el init del destino, lo que sigue vivo en gioser es un montón de daemons de tawasuyu que ningún paquete provee — binarios a mano en /usr/local/bin (1,2 G) y ~/.local/bin (765 M + 572 M en el home de root):

  shuma-daemon · shuma-gateway (:7378)   la consola de sergio.gioser.net — el único vhost que queda
  willay-daemon · willay-crosscheck · tejido (:4102,:33097) · pacha · pacha-secretos
  matilda · tupu · thasnuna · sandokan-watch · openclaw · zeroclaw
  puerta-f6e393ffbef3999e (:34221,:44961)   binario de test en target/debug, BORRADO del disco
  webhook-deploy.py

planear.py --revisar los saca con su motivo, pero la decisión es del usuario y el programa no la va a inventar: son las herramientas propias del usuario, no servicios de un catálogo. Y los datos tampoco se recomiendan solos (§3): /home son 25 G que incluyen 6,8 G de .claude y 1,3 G de binarios sueltos.

6.35 🧳 Los binarios sueltos, desglosados — y qué de .claude viaja (2026-09-16)

Decisión del usuario sobre el §6.34: shuma se construye desde tawasuyu (ya está encolado: recipes/incoming/shuma-{gateway,daemon}.toml), los daemons de tawasuyu viven todos, y de .claude decide el criterio de quien lo usa. Falta el detalle de los sueltos, que es esto.

Son 2,7 G en tres directorios, y casi nada de eso es irreemplazable

clase	cuánto	qué es	se reconstruye
tawasuyu	57 ficheros · 1003 M	pata-llimphi 105 M, nahual-shell-llimphi 98 M, shuma-shell-llimphi 76 M, los 14 mirada-*, pata-*, shuma-*, sandokan-*, willay-*, pacha, tejido, tupu, matilda, thasnuna…	sí: son salida del monorepo, que ya vive en el gitea de la caja
terceros	10 ficheros · 841 M	kiro-cli* 571 M (tres binarios), kcl 95 M, qdrant 91 M (muere, §6.30), gitea-runner 21 M, act_runner 21 M (muere), listmonk 19 M, hcloud 18 M, goaccess 3,4 M	no, pero se vuelven a bajar de su origen
respaldo / duplicado	21 ficheros · 876 M	/root/.local/bin es una copia entera de kiro-cli* (571 M) más el CLI de claude (219 M); el resto son .respaldo-FECHA, .previo y .bak	no hace falta
guiones	27 ficheros · < 1 M	git-deploy, webhook-deploy.py, update-squid-allowed-ips.sh, mirada-session*, huellita-aviso…	NO ← lo único de verdad frágil

⇒ lo caro no es lo valioso. De los 2,7 G, 1,8 G son reconstruibles o duplicados, y lo que no está en ningún repo ni en ningún paquete son 27 guiones que suman menos de un megabyte — el pegamento que nadie recuerda hasta que falta. Van al plan como una sola entrada, y con nombre.

Y los 572 M de /root/.local/bin que el censo no veía (§6.34) resultaron ser exactamente eso: la copia de kiro-cli* que ya está en el home de sergio. La lección no cambia —un censo que dice «no hay nada» de lo que no pudo mirar es peor que uno que falla—, pero el contenido, esta vez, era duplicado.

.claude: 6,8 G en disco, 15 M es lo que hace falta para seguir funcionando igual

Criterio, porque es lo que me deja trabajar allá como acá:

viaja	qué	tamaño
✅	projects/*/memory/ de los 18 proyectos — la memoria destilada	6,2 M
✅	settings.json, plugins/, history.jsonl	~8,6 M
⛔	jobs/ (5,3 G), downloads/ (228 M), archivo-sesiones/ (286 M), file-history/, shell-snapshots/, cache/, paste-cache/	6,1 G
⚠	projects/*/*.jsonl — los transcripts crudos (973 M)	ver abajo

Los transcripts no hacen falta para funcionar: la memoria es su destilado y es lo que se lee al arrancar una sesión. Lo que se pierde sin ellos es --resume de una sesión vieja y la posibilidad de releer una conversación que nadie resumió. Por eso no van a la caja —que tiene 42 G libres en /work y los quiere para el store— sino al Storage Box del respaldo, que es donde vive lo que se guarda por si acaso. La memoria, en cambio, viaja con la máquina.

⚠ Y una trampa de ruta que haría todo esto inútil

La memoria se indexa POR RUTA: el directorio se llama -mnt-vvv-takana porque el repo vive en /mnt/vvv/takana. En la caja el repo está en /opt/takana ⇒ copiar memory/ tal cual deja los 163 ficheros en disco y ninguno se encuentra, sin que nada falle. Las dos salidas son renombrar el directorio a la ruta de destino (-opt-takana) o darle al repo la misma ruta que acá. Se elige al copiar, no después.

🕳️ La caja no tiene usuario sergio

/etc/passwd de 2.29.29.217: root, sshd, gitea, proxy. Nada más. En gioser, shuma-daemon corre como sergio —y shuma-gateway también—, así que la tarjeta de arje que los declare tiene que crear la cuenta primero; y el payload Native de arje no tiene campo de usuario (SDD 29 §4.0 quinquies), así que declararlos sin más los pone a correr como root. Es la misma advertencia que ya lleva recipes/incoming/shuma-daemon.toml en su cabecera, escrita donde se va a leer.

6.36 🚚 Lo que se movió hoy — y las cuatro verificaciones que se hicieron EN DESTINO (2026-09-16)

Con las decisiones del §6.35 puestas, se movió lo que no dependía de nada más. Cada copia se verificó del lado del destino, que es la regla que el rsync con exit 0 y 1367 artefactos vacíos dejó escrita (§6.13, y la regla 2 de aplicar.py).

qué	a dónde	verificación en destino
los 27 guiones (75 KB)	takana:/work/rescate-guiones/	sha256sum -c SHA256SUMS ⇒ 27 OK
la memoria de Claude (733 ficheros, 6,3 M) + settings.json, plugins, history.jsonl	takana:/root/.claude/	733 ficheros en origen y 733 en destino
los transcripts crudos (1 966 ficheros, 1,3 G)	Storage Box claude-gioser/	rsync -an de vuelta: 1 solo fichero pendiente, y es el transcript de la sesión que estaba escribiéndolo
la clave PRIVADA de release	takana:/root/.config/takana/keys/ 0600	sha256 idéntico en los dos lados y su pública == trust/release.ed25519.pub
credenciales y config (gitconfig, npmrc, gh, ssh, crontabs, Caddyfile)	takana:/work/mudanza-secretos/ 0700	27 ficheros en origen y 27 en destino
estado de los daemons que viven (sigma, tupu, willay, sandokan-watch.json) + /var/www/para-respaldar	takana:/work/mudanza-estado/	351 ficheros y 68 M en los dos lados

⚠ Las credenciales NO se instalaron en su sitio, a propósito

La caja ya tiene su /root/.ssh (con github5), su crontab (el latido de la caja, §6.29) y su /etc/caddy/Caddyfile con los siete vhosts que ya sirve. Pisar cualquiera de los tres con el de gioser rompe lo que hoy funciona. Quedan en /work/mudanza-secretos/ con su LEEME.txt, y se instalan cuando se mude el hub, que es otra unidad de trabajo. El .gitconfig es el caso más claro: trae los insteadOf que reescriben remotos, así que instalarlo cambia a dónde empuja git push sin que nadie lo pida.

La única excepción es la clave de release, que sí fue a su ruta canónica: sin ella nadie puede volver a firmar el repo, y ese fallo no aparece el día que se borra gioser sino la próxima vez que alguien publica.

🔍 Un «576 M contra 1,3 G» que parecía una copia a medias

du -sh en el Storage Box decía 576 M de los 1,3 G subidos. Con el antecedente del rsync que llenó el disco, eso se lee como copia truncada. No lo era: el Storage Box comprime, y su shell restringida no tiene find ni acepta tuberías, así que el conteo de ficheros —la verificación obvia— ahí no se puede hacer. Lo que sí se puede es preguntarle a rsync: una corrida -an compara tamaño y fecha contra el destino real y dijo 1 fichero pendiente, el que estaba creciendo mientras se copiaba.

⇒ la verificación tiene que poder correrse en el destino que hay, no en el que uno imagina. Y un número que no cuadra merece una segunda medición antes de un diagnóstico: du medía otra cosa.

Lo que NO se movió, y no es olvido

~10 G de árboles personales en /home/sergio —android-sdk 1 G, maps, imm, humanoid, hifas, fdroid, valens-conversion, pyswisseph, accordion…— y /opt (1,2 G, que es android-sdk otra vez y google). Qué datos valen no se deduce de la máquina (§3), y éstos son proyectos del usuario, no servicios de un censo: van a la lista de decisiones, no a una copia hecha por criterio ajeno.

De /var/lib (8,1 G) se movió sólo el estado de los daemons que viven: 6,1 G son swap y 1,9 G el gitea, que ya está mudado desde el §6.14.

6.37 ✅ CUTOVER DE sergio.gioser.net — el último vhost, y gioser deja de servir (2026-09-16)

Ya no queda ningún dominio sirviéndose desde gioser. El último era éste, y lo que lo ataba no era el sitio sino su consola: /shuma/*. Verificado desde fuera, contra la IP nueva:

  https://sergio.gioser.net/           → 200   408 bytes, la SPA
  https://sergio.gioser.net/shuma/     → 200   «shuma-gateway ok»   ← el gateway, no la SPA
  https://sergio.gioser.net/ruta-inventada → 200  la SPA (el fallback, que es lo correcto)

⚠ El 200 de /shuma/ había que mirarlo dos veces. El bloque termina en try_files {path} {path}/ /index.html, así que cualquier ruta inexistente devuelve 200 con la SPA: un curl -o /dev/null que sólo mira el código habría dado el mismo verde con el proxy mal puesto. Lo que decide es el CUERPO — 17 bytes que dicen shuma-gateway ok — y el control es compararlo con lo que el origen viejo sigue sirviendo, byte por byte. Igual con /shuma/rpc: las dos máquinas contestan el MISMO 400 {"error":"bad json: …"}.

Lo que hubo que construir, en orden

1. Las dos recetas (§6.34) sellaron en el worker: b3:107dfb54…-shuma-gateway (6,3 M) y b3:f9b92acc…-shuma-daemon (5,6 M) — los hashes que takana hash había anticipado antes de encolarlas. file dice statically linked: nada de cargador, que era exactamente lo que le faltaba al binario glibc de gioser (y cuyo inodo, además, ya estaba borrado del disco).
2. La cuenta, declarada y sin privilegio. [[user]] shuma (uid 967) en la receta del daemon, y el descenso con setuidgid dentro del argv de la Card, igual que gitea — porque el payload Native de arje no tiene campo de usuario. Declararlo «como estaba» lo habría puesto de root, y esto es un demonio que abre PTYs y lanza shells.
3. ⚠ Y la shell de la cuenta NO es un detalle. El default de [[user]] es /bin/false, que es lo correcto para gitea o squid y exactamente lo contrario para éste: con la shell inerte el servicio arranca, se supervisa, contesta 200… y cada pestaña que alguien abra muere al instante. Un fallo que no se ve al desplegar: se ve al usarlo. Va shell = "/bin/sh".
4. La config que no se regenera. El gateway-token (32 B) y keys/identity.x25519 viajaron a /var/lib/shuma/.config/shuma/: generar unos nuevos deja fuera a los clientes ya emparejados. Por eso la guarda de la Card exige el token y no lo crea, y dice de dónde sale.
5. Las dos Cards entran en /etc/arje/cards.d/ y en el genesis de /ente/seed.card.json (son dos preguntas distintas: qué se puede encarnar a pedido y qué arranca solo). La semilla quedó con 13 entradas y vuelve a parsear.
6. Declarado en perfil.servidor: los dos paquetes y los dos labels en servicios. Entran como PAR — el gateway sin el daemon es un puente a ninguna parte.

[[user]] y [[service]] están fuera de hash_inputs, así que declarar todo eso no movió ningún ArtifactHash: comprobado en los dos, antes y después.

🔁 El DNS: la API tiene una acción para esto y el §6.25 no la había encontrado

Aquel cutover dejó escrito «un PUT sobre el rrset no puede cambiar el tipo: hay que DELETE del CNAME y POST del A». Es cierto para un cambio de TIPO. Para cambiar el VALOR, el PUT tampoco sirve —can't update records with this endpoint— pero existe una acción que lo hace atómica:

POST /v1/zones/<id>/rrsets/<nombre>/<tipo>/actions/set_records   {"records":[{"value":"…"}]}

Sin ventana sin registro, que es lo que sí tiene el DELETE+POST. Con TTL 60 la resolución pública cambió en menos de 8 segundos, y volver atrás es la misma llamada con la IP vieja.

El origen sigue vivo, a propósito

Como en §6.26: en gioser shuma-daemon, shuma-gateway y su bloque de caddy siguen corriendo. Mudar el nombre y dejar el origen encendido permite volver en un minuto, y no cuesta nada mientras la máquina exista. Lo que ya no existe es la dependencia: ningún dominio resuelve a gioser.

⚠ Pendiente menor, anotado donde se va a leer: el daemon avisa al arrancar que no encuentra shuma-askpass («sudo/ssh pedirán la clave por el TTY»). Es otro crate del mismo workspace y es otra receta — no bloquea la consola.

6.38 🧩 Los primeros cuatro daemons propios, corriendo en la caja (2026-09-16)

De las diez recetas encoladas, cuatro sellaron y ya corren supervisadas por arje:

	cuenta	qué hace, comprobado
matilda	root	lee el access log de caddy y archivó 78 ficheros en /var/lib/tupu/takana/
pacha	pacha (965)	vivo, 0 reinicios, con SUS reglas (reglas.ron), no las de fábrica
pacha-secretos	pacha	vivo, 0 reinicios — y su binario en gioser era un inodo borrado
sandokan-watch	root	frenado a propósito: no puede trabajar acá (ver abajo)

⚠ Tres corren como ROOT, y está declarado en vez de heredado

Lo natural sería una cuenta sin privilegio por servicio, como shuma o gitea. Con el trío de la telemetría no se puede, y las dos razones son medidas:

1. matilda lee /var/log/caddy/requests.json, que caddy crea -rw------- root root y recrea igual en cada rotación: un grupo con permiso de lectura se pierde en la próxima.
2. tupu, matilda y sandokan-watch escriben en el MISMO /var/lib/tupu, y en gioser sus 322 ficheros son root:root. Bajar uno solo deja mezcla de dueños en un árbol compartido: escribe el primero y los otros fallan al modificar.

⇒ o los tres como root, o ninguno. La salida limpia está anotada en la receta para el día que se quiera: que caddy escriba con mode 640 y que el árbol sea de una cuenta propia. pacha y pacha-secretos sí bajan a una cuenta propia, porque en gioser tampoco corrían como root.

🕳️ La caja se llamaba «(none)» — y eso se archivaba

matilda archiva POR MÁQUINA, y sus primeros 72 ficheros fueron a /var/lib/tupu/**none**/:

  $ hostname          →  (none)
  $ cat /etc/hostname →  no existe

Ninguna caja takana fija su hostname: no lo hace netup, no está en el product-rootfs, no hay /etc/hostname. Nunca importó porque nada archivaba por nombre — hasta que llegó algo que sí. Y no falla: archiva bajo none, y dos máquinas distintas archivarían en la misma carpeta.

Puesto /etc/hostname + una Card OneShot hostname en el genesis, para que sobreviva al reinicio sin depender de que alguien se acuerde. Con el nombre puesto, matilda re-archiva en /var/lib/tupu/takana/. Quedan 72 ficheros huérfanos bajo none/: son los 20 minutos anteriores.

⇒ lo correcto es que lo haga netup, que es quien configura la identidad de red de la máquina; la Card es la mitigación de hoy, y está dicho en su propia guarda.

🛡️ Un vigía que no vigila es PEOR que uno caído, porque el caído se ve

sandokan-watch arrancó, quedó «corriendo · 0 reinicios»… y no guardaba una línea. Lo dice él mismo si uno lo corre a mano:

sandokan-watch · sin fuente de accesos (ni /var/log/auth.log ni journalctl): no se guarda nada

En gioser lee el auth.log de un syslog que en takana no existe — no hay systemd ni syslog. Su Card ahora lleva una guarda que sale 78 nombrando el problema, así que el servicio no queda verde mintiendo; y no entra al genesis, sólo a cards.d, porque no tiene sentido que arranque al boot para fallar. Destrabarlo es darle el diario de arje como fuente, y eso es trabajo de su repo.

Dos herramientas que no existen donde se prueba

Dos veredictos falsos en una tarde, los dos por probar con algo que la caja no tiene:

• /dev/tcp/host/puerto no existe en busybox ash ⇒ un barrido de puertos contra gioser dio «cerrado» para los cinco, incluidos :80 y :443, que sirven. Con curl telnet:// el resultado es el contrario: :2345 y :443 abiertos, :22 cerrado.
• La expansión de llaves ({a,b}) tampoco ⇒ un ls /store/*-{matilda,pacha} dijo que los artefactos no habían llegado. Habían llegado.

Es la misma lección del §6.23 (ps y dig ausentes) y merece repetirse: una prueba que no puede pasar se ve igual que una que todavía no pasó.

6.39 🕸️ Los nueve daemons propios, y la línea que separa «se muda» de «se INTERCAMBIA» (2026-09-16)

Nueve de las diez recetas sellaron. Cinco corren; cuatro están instaladas y frenadas a propósito, cada una por un motivo distinto y con su guarda diciéndolo.

corriendo		frenado	por qué
matilda · tupu	root, escriben /var/lib/tupu/takana/	sandokan-watch	en takana no hay auth.log ni journalctl
pacha · pacha-secretos	cuenta pacha (965)	tejido	misma identidad libp2p que el de gioser
willay-daemon	root, con su índice mudado	willay-crosscheck	necesita el roster de tejido
shuma-daemon · shuma-gateway	cuenta shuma (§6.37)	thasnuna	pide claude autenticado y sandokan-mcp

⚠ La regla que sirvió para los vhosts NO sirve para una identidad

Con los sitios web la pauta fue: mudá el DNS y dejá el origen encendido, así volver cuesta un minuto (§6.26). Con tejido eso es exactamente lo que NO hay que hacer, y el README del propio tejido lo dice: «la clave que el roster atesta ES la identidad de transporte libp2p» (~/.tejido/device.seed). Dos máquinas con la misma semilla no son dos réplicas del mismo servicio: son el mismo PeerId en dos sitios, o sea dos impostores mutuos para el resto de la flota.

⇒ tejido se intercambia: se apaga allá, se enciende acá, en ese orden. Está todo listo para el intercambio —binario, cuenta tejido (964), identidad instalada 700 en /var/lib/tejido/.tejido/— y su Card vive en cards.d pero no en el genesis, para que un reinicio no lo encienda solo.

Y arrastra a otro: willay-crosscheck no es independiente. Corriendo su línea a mano:

Error: no hay roster en /root/.tejido/roster.postcard — emparejá primero (`tejido serve` / `tejido join`)

Vive dentro de la red de tejido, así que hereda su condición. Se enciende en el mismo movimiento.

Lo que cada guarda evita

• thasnuna: su INSTALAR.md —escrito hoy por el frente tawasuyu para esta misma mudanza— pide tres cosas, y dos no están: sandokan-mcp en el PATH («el agente contesta pero no tiene herramientas») y claude instalado y AUTENTICADO («no hay anfitrión»). El CLI de claude es un binario glibc de ~300 M: en una caja musl pide jaula qorpa, como sergioh-api.
• Y de ahí sale un hallazgo que vale para el respaldo entero: ese documento explica por qué el token no va en la Card, y el motivo está medido en la máquina vieja — la Card openrc-openclaw de gioser lleva la API key de su proveedor EN CLARO dentro del JSON de /etc/arje/cards.d/, que es un directorio que se respalda y se copia. Un secreto dentro de una Card viaja a todas partes.
• willay-crosscheck: --label nombra a la máquina. En gioser decía momento; copiarlo tal cual habría hecho que la caja nueva se anunciara con el nombre de la que se borra. Ahora sale de hostname, y si no hay, la guarda lo dice.

🔁 Tres veredictos falsos en una tarde, los tres por probar con lo que la caja no tiene

Van con el §6.38 y ya son patrón, no anécdota:

la prueba	lo que dijo	lo que pasaba
/dev/tcp/host/puerto	los 5 puertos de gioser «cerrados»	busybox ash no tiene /dev/tcp
ls /store/*-{a,b}	«los artefactos no llegaron»	busybox no expande llaves
find … -newermt "-2 minutes"	«tupu no escribe hace 2 min»	tupu sí escribe: su mtime avanza cada 10 s

El de tupu es el más instructivo porque casi produce un diagnóstico al revés: el fichero tiene tamaño constante (es una serie de tamaño fijo), así que «no cambió de bytes» tampoco probaba nada. Lo que decide es el mtime, medido dos veces con 40 s de por medio.

6.40 🚪 Las ocho puertas, medidas de nuevo (2026-09-16) — y la que falta es UNA

La tabla del §6.3 es del 10 de septiembre. Re-medida hoy, entera:

#	puerta	estado	medido
1	arranca takana puro, se entra por SSH	✅	sigue en pie
2	el store está entero	✅	1632 artefactos, 0 vacíos (eran 1362) · ⚠ /store al 88 %, 11,3 G libres
3	los cuatro grafos idénticos	✅	§6.7
4	la granja late en la caja nueva	❌	el latido sigue en gioser: la caja no tiene el cron
5	el repo se sirve y el host se actualiza solo	⬖	sirve; consumir exige el lab entero (SDD 27 §4)
6	cada dominio vivo responde 200 desde fuera	✅	los 8 contra 2.29.29.217 — y sergio ya entre ellos
7	el respaldo corre desde la caja	⬖	el script corre y lista el Storage Box desde la caja; falta una corrida completa
8	lo fósil, anotado y decidido	✅	§6.9 + docs/state/mudanza-decisiones.txt

La puerta 4 es ahora una línea de crontab — y por qué no la puse

La caja ya tiene todo lo que el latido necesita, comprobado uno por uno: git, python3, rsync, ssh, takana, flock, la llave del worker en /root/.ssh/github5 y el .fleet con dev.gioser.net. Le faltaban dos costuras y están hechas:

  /opt/takana/store              -> /store            (el script espera `./store`; acá es partición)
  /opt/takana/target/release/takana -> /usr/bin/takana (no hay árbol de build en una caja instalada)

Y el repo de /opt/takana, que estaba 5 días atrasado, quedó en origin/main exacto (0 diferencias contra el remoto), con un tar de respaldo de los 92 ficheros que el árbol tenía antes. ⚠ Esos 92 no eran trabajo local: eran contenido que ya estaba río arriba —el cambio de SSH a HTTPS de las recetas de tawasuyu, entre otros— metido en el árbol sin commitear. Un árbol «sucio» que en realidad está atrasado, que es el mismo espejismo que el §5 del informe de tawasuyu describe para el monorepo.

Prueba de sólo lectura desde la caja, que es lo más lejos que se puede llegar sin cambiar nada:

  ▶ dev.gioser.net (154.197.1.13)   load: 2.72 · store: 895 artefactos
  ══ AVANCE KDE ══  197/198 sellado
  ══ CRON DE COSECHA ══  ⚠ NO instalado en el crontab

No lo instalé, y el motivo es el mismo que el de tejido: con el cron puesto en las dos máquinas, las dos harían rsync --delete del repo al worker y las dos cosecharían y commitearían. El latido se intercambia, no se duplica — se apaga en gioser y se enciende acá, en ese orden, y es el último movimiento antes del borrado.

⇒ de las ocho, una sola está en rojo, y es una decisión de corte, no trabajo pendiente.

6.41 🔀 INTERCAMBIO de tejido — la identidad cambió de máquina, no de dueño (2026-09-17)

Hecho, y en este orden, que es el único posible: apagar allá → encender acá.

  gioser   tejido relay (964) · tejido serve (29240) · willay-crosscheck (15334)   → detenidos
  takana   tejido        4102   ·  willay-crosscheck  4103                         → corriendo

La prueba de que la identidad VIAJÓ y no se generó otra no es que el servicio arranque —eso pasaría igual con semillas nuevas, y sería el fallo silencioso que esto existe para evitar— sino que la semilla sea la misma:

  device.seed     gioser cad6f35b633e8637…   caja cad6f35b633e8637…   ✓ idéntica
  roster.postcard gioser 590f2713075ac934…   caja 590f2713075ac934…   ✓ idéntica

El PeerId sale de esa semilla, así que sigue siendo 12D3KooWBw2u8mt2ciUjX69qpVAZiJZ8sZMGxz8eHJEnz4rzg37L.

⚠ LO QUE SÍ CAMBIA, Y HAY QUE TOCARLO A MANO: el multiaddr

Los clientes tienen configurada la dirección COMPLETA del relay, IP incluida — se leyó del proceso que corría en gioser:

  antes:  /ip4/204.168.193.248/tcp/4102/p2p/12D3KooWBw2u…
  ahora:  /ip4/2.29.29.217/tcp/4102/p2p/12D3KooWBw2u…        ← mismo PeerId, otra IP

Un cliente con el viejo no falla «mal»: reintenta contra una IP que pronto no existirá. El PeerId no hay que tocarlo; la IP sí, en cada equipo del roster.

🧱 Sin el cortafuegos, el intercambio habría sido un verde falso

El reglaset de la caja abría 80, 443, 1137, 2345, 22022 y nada más: 4102 estaba cerrado. Con el relay encendido y el puerto filtrado, arjectl status diría «corriendo · 0 reinicios» y la flota no llegaría — el peor de los verdes. Se abrieron 4102 (relay) y 4103 (crosscheck), con su ban por tasa como el resto. No se abrió 33097: ése era el puerto efímero de un tejido serve (cliente), no un servicio que alguien busque.

Y el reglaset quedó idempotente, que era deuda del §6.33: sus dos primeras líneas crean y borran la tabla antes de definirla, así que nft -f reemplaza en vez de acumular. Comprobado contando: 15 reglas dport antes, 21 después (no 36).

⚠ La política que genera ese fichero NO EXISTE EN NINGÚN DISCO. Su cabecera dice «GENERADO, no editar a mano — regenerar con cortafuegos generate-input --policy <ruta>», pero esa ruta no está ni en la caja, ni en gioser, ni en el repo (sólo dos politica_*_ejemplo.ron en tawasuyu), y el binario cortafuegos tampoco está instalado en ninguna de las dos. El generado sobrevivió a su fuente: hasta que la política se escriba y se versione, esto se edita a mano — justo lo que su primera línea pide no hacer.

🆔 takana acepta ULIDs que arje-zero RECHAZA

La Card de tejido no encarnaba: arje-zero rechazó: card tejido JSON: invalid character at line 7. La línea 7 es el id, y el id era 01M2EKDA00TEJ1D0RELAY00001 — que tiene una L, carácter excluido del alfabeto Crockford de ULID (junto con I, O, U). takana service-cards lo validó como bueno («26 caracteres alfanuméricos») y el consumidor lo tiró.

Dos cosas de esto: el validador del PRODUCTOR es más laxo que el del consumidor —y eso siempre termina en un fallo lejos de donde se escribió—, y el barrido propio que ya corrí sobre todos los id del repo con el alfabeto correcto había marcado justo ése. Era el único con L (venía de «RELAY»); ahora es 01M2EKDA00TEJ1D0RE1AY00001.

Estabilidad, medida y no supuesta

willay-crosscheck marcaba 4296 reinicios, que asusta hasta mirar de dónde vienen: son las horas en que su guarda lo frenó a propósito por falta de roster. Con el mismo pid a los 70 s y 1 m 53 s de vida, está estable. tejido: 0 reinicios. Los dos puertos aceptan conexión desde fuera.

⚠ De paso, un detalle feo: arjectl status | head -2 hace que arjectl paniquee con failed printing to stdout: Broken pipe. No rompe nada, pero un EPIPE sin manejar en una herramienta de operación aparece justo cuando alguien la encadena con head/grep -q.

Cómo volver, si hiciera falta

Está escrito en work/mudanza/volver-atras-tejido.txt: apagar los dos de la caja y relanzar los tres de gioser con las líneas exactas que se leyeron de /proc/<pid>/environ y cmdline. Nunca las dos a la vez: es la misma identidad.

6.42 ❌ El latido NO se puede mudar todavía — y el motivo redefine qué es un «hub» (2026-09-17)

Se intentó el último intercambio: apagar el cron de la cosecha en gioser y encenderlo en la caja. Salió mal, se vio en el primer ciclo, y se volvió atrás en minutos. Queda escrito porque el motivo no era ninguno de los que se habían previsto.

Lo que sí funcionó

La caja tiene todo lo del latido y el ciclo corrió de punta a punta: sembró el repo al worker, leyó su manifiesto, regeneró los ocho ficheros de estado, pasó los vigías, se puso al día por fast-forward y commiteó+empujó. El git config de identidad y el pull --ff-only nuevo hicieron su parte.

🕳️ Lo que publicó, que es el problema

  totals que publicó la CAJA :  {recipes: 1112, nodes: 1115, unhashable: 1112, ajeno: 3}
  totals de gioser           :  {recipes: 1112, nodes: 1115, sealed: 1105, never: 5, debt: 2}

unhashable: 1112 — no es «no está sellado»: es que no se pudo CALCULAR el hash de ninguna receta. Y la causa es la misma que el §5.2 documenta desde el otro lado: el lab entra en el ArtifactHash, así que una máquina sin el rootfs del lab no puede hashear nada. La caja de producción no lo tiene — a propósito, no es un olvido.

El daño era real y silencioso: el commit 45b5685a dejó en main un build-state*.json que dice que el corpus entero no existe. Cualquiera que lo lea —o cualquier vigía que lo compare— vería 1112 recetas en cero.

La lección, que vale más que el intento

Un hub no es «la máquina que tiene el repo y la llave»: es la que tiene el LAB. El latido parece tarea de cron —siembra, cosecha, commitea— pero su tercer paso es pensar sobre el corpus, y eso exige el toolchain. Por eso la puerta 4 no era una línea de crontab, aunque todas las piezas que se miraron (git, python3, rsync, ssh, takana, flock, .fleet, la llave) estuvieran.

⇒ Las salidas son tres, y ninguna es «poner el cron»:

1. darle el lab a la caja (/.dev-fs/…) — deja de ser sólo servidor y pasa a ser también hub;
2. partir el latido: siembra+cosecha en la caja, regeneración del grafo donde haya lab;
3. que el hub sea otra máquina (el LXC prestado ya tiene lab y muele 24/7).

Es decisión del usuario, y es lo único que queda entre esto y borrar gioser.

Vuelta atrás, en minutos

Cron de la caja borrado, cron de gioser reactivado (estaba comentado, no borrado). El propio latido de gioser repara el daño solo en su siguiente ciclo: regenera el grafo desde SU store —que sí tiene el lab— y vuelve a publicar los números buenos.

🧰 Y de paso, tres cosas que el ciclo destapó en la caja

• poda-fuentes.sh no corre en takana: /dev/fd/63: No such file or directory y viejos: unbound variable. Es sustitución de procesos (<(...)), que busybox ash no tiene — el cuarto tropiezo del día con la misma forma. El podador de work/sources es justo lo que un hub necesita para no llenarse.
• Los vigías corrieron y hablaron: 1 ofensor nuevo de raíces (bzip2), 3 herramientas selladas que no se pueden invocar, y servicios.txt con 7 errores y 30 avisos. Son hallazgos del corpus, no de la mudanza, y quedan anotados donde el humano los mira.
• arjectl status | head -2 hace paniquear a arjectl (failed printing to stdout: Broken pipe). No rompe nada, pero un EPIPE sin manejar en una herramienta de operación aparece justo cuando alguien la encadena.

6.43 🧪 La caja ya es un HUB: el lab viajó, y con él la puerta 4 (2026-09-17)

El §6.42 dejó dicho qué faltaba y el usuario eligió: darle el lab a la caja. Hecho, y el latido ya late desde allá.

El lab no se copia: se PINEA y se trae

scripts/lab-image.sh empaqueta .dev-fs/alpine de forma determinista (--sort=name --mtime=@1 --owner=0 --group=0 --numeric-owner, excluyendo var/log/apk.log, que es lo único que difiere entre dos labs por lo demás iguales), lo publica al Storage Box con el sha en el nombre, y del otro lado --traer verifica el sha antes de extraer. Eso es lo que hace que las dos máquinas hasheen igual, y es un contrato, no una copia.

Y el empaquetado de hoy devolvió el sha que el repo ya pineaba:

  empaquetado hoy en gioser : d1e341d5dd434a11e2290b0340069ce4a83563eac8e4481f379b4951b1162045
  pineado en bootstrap-devfs.sh: d1e341d5dd434a11e2290b0340069ce4a83563eac8e4481f379b4951b1162045

O sea dos cosas de una: el lab de gioser nunca derivó desde que se publicó esa imagen, y el empaquetado es reproducible de verdad — no era una promesa del comentario.

La prueba que decide, y no es que arranque

Con el lab instalado, la caja calcula los MISMOS ArtifactHash que gioser:

  zlib          b3:dc363f26…   busybox   b3:2a2b1280…
  caddy         b3:c915987d…   shuma-daemon b3:f9b92acc…

Cuatro de cuatro. Si el lab fuera otro, estos números serían otros y el store no lo notaría — es el agujero que hash_inputs cerró (§lab en el hash) y la razón por la que esto se verifica con hashes y no con un «arrancó bien».

Los stores, convergidos — y una trampa que me tendí solo

El grafo seguía discrepando porque el store de la caja no tenía 24 artefactos vigentes de gioser (3,0 G). Al copiarlos con rsync -a --files-from=<lista de DIRECTORIOS> pasó lo peor posible:

  sent 2,281 bytes … total size is 0        ← no copió NADA
  artefactos en la caja: 1631 → 1655        ← pero creó los 24 DIRECTORIOS

--files-from no recursa sin -r: creó 24 directorios vacíos en el store. Y un directorio vacío en el store es un cache-hit (§3 de CLAUDE.md, artefacto-vacio-envenena-cache): build lo habría dado por sellado y habría salido OK sin construir. Se detectó al contar, se borraron los 24 y se repitió con -r: 3,18 GB transferidos, 0 vacíos de 1655.

Después faltaban dos más (obs-studio y spectacle, justo los que el worker no logra construir), copiados también. Resultado:

	gioser	caja
corpus	sealed 929 · debt 2	sealed 930 · debt 1
KDE	sealed 1105 · debt 2	sealed 1106 · debt 1

La caja no empata: gana por uno en los dos grafos.

El latido, mudado

Cron apagado en gioser, encendido en la caja, y un ciclo completo corrido a mano para mirar lo que publica: ==> repo al día (ff) → ==> estado commiteado+pusheado, con los números buenos. El build-state que hay en main ahora lo escribió la caja.

⚠ Lo que queda apretado es el disco: /store de la caja está al 91 %, 8,2 G libres. Un hub sella y cosecha, así que ése es el próximo muro — scripts/store-gc.sh es la herramienta y todavía no se corrió allá.

⇒ puerta 4 en verde. Con eso, de las ocho quedan sólo las dos a medias (5 y 7) y ninguna en rojo.

6.44 🧹 Primer store-gc en la caja: 26,8 G — y dos bugs que sólo salen fuera de GNU (2026-09-17)

El store estaba al 91 % (8,2 G libres) justo cuando la caja pasó a ser hub, que es la peor combinación: un hub sella y cosecha.

  antes:  84,7 G usados · 8,2 G libres · 91 %  · 1657 artefactos
  después: 57,9 G usados · 35,0 G libres · 62 % · 1320 artefactos

337 artefactos superados borrados y verificados (0 sobrevivientes), 26,8 G. El default del gc no toca los 150 huérfanos —11,4 G, los que son el único ejemplar de su nombre— y eso está bien: borrarlos es la diferencia entre «se reconstruye en dos minutos» y «hay que rehacer la torre».

El control que hay que correr DESPUÉS de un gc en esta caja, y que no es obvio

11 binarios de /usr/bin son symlinks que apuntan DENTRO del store — los daemons que se instalaron estos dos días. Un gc que borre el artefacto equivocado no rompe el store: rompe el /usr/bin de una máquina en producción. Antes de --aplicar se comprobó que los 11 enlazan al hash vigente (y por lo tanto están en el conjunto protegido); después, que los 11 siguen resolviendo y que los 21 entes siguen corriendo. Los dos controles pasaron.

⚠ Y la advertencia que el propio gc imprime y que en esa caja no se puede satisfacer: «sin .config legible (ni /proc/config.gz ni /boot/config-…) ⇒ NO se protege ningún kernel por esta vía». Con el default da igual; con --huerfanos en una máquina que arranca de su store, no.

Los dos números que el gc no sabía decir

Funcionó, pero sus dos cifras salieron vacías — y son las que uno mira para decidir si vale la pena:

  ==> espacio: superados  · huérfanos
  ==> 337 artefactos borrados y VERIFICADOS · libres: Available → Available

1. du -sch --files0-from=- es de GNU y busybox no lo tiene ⇒ espacio() devolvía vacío. Un número que falta se lee como un número chico.
2. df -h /home estaba cableado y el store no vive ahí: en gioser es un bind-mount del volumen, en la caja es /store. Sin /home, tail -1 se quedó con la CABECERA — de ahí «Available → Available».

Arreglados los dos… y el primer arreglo también estaba mal: xargs -d '\n' es otra extensión GNU. Eso imprimió huérfanos ?, y ese ? es deliberado: cuando el total no se puede calcular, la función lo DICE en vez de escribir 0 — un cero inventado habría dicho «no hay nada que ganar» con 11,4 G en huérfanos. Con tr '\n' '\0' | xargs -0, que busybox sí tiene, la caja ya contesta espacio: superados 0 · huérfanos 11.4G.

⇒ Van cinco tropiezos del mismo día con la misma forma (/dev/tcp, expansión de llaves, find -newermt, sustitución de procesos, y estos dos). El patrón ya no es anécdota: un script del hub escrito en una máquina GNU no corre en la caja hasta que se prueba ahí.

6.45 🧯 poda-fuentes tampoco corría — y la causa no era el script: la caja no tiene /dev/fd (2026-09-17)

El latido, desde la caja, moría así en su paso de poda:

  poda-fuentes.sh: line 72: /dev/fd/63: No such file or directory
  poda-fuentes.sh: line 73: viejos: unbound variable
  ⚠ poda de fuentes falló (rc=1) — sigo

El segundo error es consecuencia del primero (el mapfile nunca corrió) y el primero no nombra la causa: la sustitución de procesos de bash (<(...)) necesita /dev/fd, y una caja takana no lo tiene. gioser sí: /dev/fd -> /proc/self/fd. O sea que no era este script: ningún <(...) de ningún script del hub funcionaba allá, y éste fue el primero en toparse.

Por eso los arreglos son dos, y los dos hacían falta:

1. En la caja: /dev/fd -> /proc/self/fd, con una Card OneShot en el genesis para que sobreviva al reinicio (como la de hostname). Comprobado después: bash -c 'cat <(echo funciona)' responde. ⇒ lo correcto a futuro es que lo haga el init o el product-rootfs, no una Card. Van dos parches de esta forma; es una lista que conviene no alargar.
2. En el script: fuera <(...) (fichero temporal) y fuera df -B1 --output=avail, que es GNU — con df -k + awk. Sin eso el script corría pero decía libres 0.0 G, porque el df fallaba en silencio y el 0 se lee como un disco lleno.

Con las dos cosas, la poda hizo su trabajo por primera vez en la caja:

   2 árbol(es) por encima del suelo · borrados 2 · libres 46.1 G · LIBERADO 5.4 G

⇒ En total, 32,2 G recuperados hoy en la caja: 26,8 G de artefactos superados (§6.44) y 5,4 G de árboles de fuentes. /store al 62 %, /work al 29 %.

6.46 🚪 Puerta 5 verde: la caja publica su repo firmado y se instala de él (2026-09-17)

La puerta 5 estaba a medias desde el §5.4 y el motivo era el de siempre: el host no se puede actualizar de sí mismo porque install reproduce desde fuente y eso exige el LAB. Con el lab ya instalado (§6.43), se cerró en dos movimientos, los dos corridos en la caja:

1. Publicar — con su propia clave de release, la que se mudó el 2026-09-16 a /root/.config/takana/keys/:

  ==> ✓ el índice verifica contra ./trust
  publicado: 171 con expected_hash anclado, 3 sin ancla. FALLARON: os-release

2. Instalar de ese repo, en modo estricto (--require-signed, que exige autoría del catálogo verificada y no se conforma con que el .swm reproduzca):

  release: trusted (by release)
  install duf 0.9.1 ← dist/repo/duf-0.9.1.tkn
  deps: resolviendo catálogo para 1 dep(s): go
  caché: artefacto ya en el store hash=b3:abb3527d… name=duf
  apply OK — source_patch=1 config_edit=0 init_rule=0 file_drop=0
  registrado duf (2 fichero(s))

Se instaló bajo --prefix /tmp/prueba-install y con --db propio, para no tocar el sistema.

⚠ Y el matiz honesto, que vale más que el verde: el artefacto ya estaba en el store, así que el camino que se ejercitó fue resolver + verificar firma + hidratar, no reproducir desde fuente. Lo que el lab destrabó y sí quedó probado aparte es el hash (§6.43: cuatro de cuatro iguales a gioser), que era exactamente donde moría antes —«no pude leer el apk db del lab»—. Queda sin ejercitar el caso «paquete que NO está en el store», que en una caja de producción además es discutible que se quiera: un servidor no tiene por qué compilar.

⇒ os-release es la única receta del perfil que no se pudo publicar; es la que lleva el logo y la identidad de la distro, y su fallo queda anotado para mirarlo aparte.

6.47 🚪 Las ocho, al cierre del 2026-09-17

#	puerta	estado
1	arranca takana puro, se entra por SSH	✅
2	el store está entero	✅ 1320 artefactos, 0 vacíos tras el gc · /store al 62 %
3	los cuatro grafos idénticos	✅
4	la granja late en la caja	✅ §6.43 — con el lab pineado; la caja gana por uno en los dos grafos
5	el repo se sirve y el host se instala de él	✅ §6.46 — 171 paquetes publicados y install --require-signed en verde
6	cada dominio vivo responde 200	✅ los 8
7	el respaldo corre desde la caja	✅ §6.48 — corrida completa, 0 errores, y 0 artefactos de la caja sin respaldar
8	lo fósil, anotado y decidido	✅

⇒ LAS OCHO EN VERDE (§6.48 cerró la última). Lo que separa a esto del borrado de gioser ya no es técnico: es la decisión del usuario, que es como el §6 dice que tiene que ser — a mano, con las ocho en verde, nunca por automatización.

Y lo que queda vivo en gioser es el trabajo de la mudanza, no servicios: los ~10 G de árboles personales de /home sin decidir (§6.35) y el montón de [[datos]] que el censo dejó sin decisión.

6.48 ✅ Puerta 7: el respaldo corre desde la caja — y el parcial que la envenenaba (2026-09-17)

  respaldados (manifiesto del Storage Box) : 3686
  en el store de la caja                   : 1320
  de la caja, NO respaldados               : 0        ← la cuenta que decide
  errores y reintentos en la corrida       : 0 y 0

Las ocho puertas quedan en verde.

⚠ Pero la primera corrida NO terminó, y el motivo vale por sí solo

Se cayó 40 veces seguidas con el MISMO fichero:

  open ".../fonts/dejavu/.rsync-partial/DejaVuSans-Oblique.ttf" failed: No such file… (2)
  ..  store: corte de red (rsync 23). Intento 39; reanudo en 60s.
  !!  store: 40 intentos y sigue cayéndose. Dejo lo subido y paro.

No era red. Una transferencia interrumpida el 11 de septiembre había dejado ese parcial en el destino con el modo del origen —-r--r--r--, porque el store es de sólo lectura por diseño— y ningún intento posterior puede reescribirlo. El fallo es ETERNO: esa ruta quedaba envenenada para siempre, y el bucle la golpeaba cada 60 segundos llamándola «corte de red». Es exactamente la pared que la cabecera de esa función dice que no hay que golpear cuarenta veces.

Dos arreglos, y el segundo importa más que el primero:

1. --chmod=Fu+w en el rsync: los ficheros del respaldo quedan escribibles por su dueño, así que un corte a mitad se RETOMA en vez de trabarse. El precio —no conservar el bit de sólo-lectura en la copia— es bajo: lo que se respalda es el contenido, y los permisos los reconstruye el store.
2. Al rsync 23 se le dan TRES intentos, no cuarenta, y al tercero se NOMBRA la causa probable. El 23 es «some files were not transferred», que tanto puede ser un cable como una pared; tratarlo siempre como cable es lo que convirtió un fallo permanente en cuarenta minutos de ruido.

🪤 Y dos veces el mismo error mío: pgrep -f <patrón> se encuentra a SÍ MISMO

Para saber si el respaldo seguía vivo usé pgrep -f respaldo-storagebox… y el patrón está en la línea de comando del propio pgrep (y del ssh que lo lanza). Resultado: decía «sigue corriendo» para siempre, incluso con el script muerto hacía rato — y el vigía que armé con esa condición nunca podía dispararse. Pasó dos veces en la misma tarde, en las dos máquinas.

La forma correcta es el truco del corchete —ps ... | grep "[r]espaldo-storagebox"—, que no coincide consigo mismo porque el patrón literal [r]espaldo no aparece en la línea del grep. Es hermano del pkill -f que mata tu propia shell, ya anotado en las memorias.

6.49 📋 Lo único que queda: 150 decisiones sobre datos (2026-09-17)

Con las ocho puertas en verde, de la mudanza no queda trabajo técnico: queda decidir. La hoja está en docs/state/mudanza-decisiones-pendientes.txt — 150 entradas, 31,9 G, ordenadas por tamaño, con lo que la herramienta se anima a sugerir por un HECHO entre corchetes y en blanco lo que sólo sabe el dueño:

  /home/sergio/.claude         6.8G  [     ]  lo más nuevo: 2026-09-16
  /home/sergio/.local          6.2G  [muda ]  lo usa act_runner, tejido, thasnuna
  /var/lib/swap                6.1G  [muere]  (es swap)
  /home/sergio/.cache          4.3G  [muere]  caché
  /var/lib/gitea               1.9G  [     ]  ← ya mudado en el §6.14; la entrada es un fósil del censo
  /home/sergio/imm             200M  [     ]  lo más nuevo: 2026-03-23

Se aplica en una pasada con planear.py --decidir, que ya no necesita teclas unitarias (§3 bis).

⚠ Y la hoja dice qué no cubre, porque una lista titulada «lo que falta» que omite 329 G se lee mal: no están /mnt/vvv —el monorepo, este repo, el store, rustup— ni los servicios y dominios. Lo de /mnt/vvv no necesita decisión: el store está respaldado (puerta 7) y los repos viven en el gitea de la caja.

Lo último que se rescató antes de cerrar

/mnt/vvv/gioserv tenía 26 entradas sin commitear y su remoto era /var/lib/gitea/repositories/sergio/gioserv.git — una ruta LOCAL de la máquina que se borra. Lo commiteado está a salvo (su HEAD es el mismo que el del gitea nuevo); lo que no estaba en ningún lado —el git diff HEAD completo (api/main.py, +92/−23, y 25 borrados) más los 4 no rastreados— quedó en takana:/work/mudanza-secretos/gioserv-pendiente/, verificado: 0 ficheros del origen faltan en el destino.

No se reapuntó el remoto ni se commiteó nada: cambiar el remoto de un clon ajeno y decidir si ese api/main.py se publica es del dueño del repo, no de la mudanza. El LEEME.txt del paquete lleva el comando exacto para reapuntarlo.

6.50 🤖 El agente corre en la caja — y puede construir (2026-09-17)

Pedido del usuario, y es la condición que él mismo puso para borrar gioser: «no borramos gioser hasta tenerte corriendo de aquel lado, con capacidad de compilar tawasuyu y las recetas de takana».

  $ claude -p "Decí exactamente: CLAUDE CORRIENDO EN LA CAJA"
  CLAUDE CORRIENDO EN LA CAJA

Eso es un turno REAL —API, credenciales, respuesta— desde 2.29.29.217.

Por qué va enjaulado, y qué se le concedió

El CLI es un ELF glibc de 360 M (interpreter /lib64/ld-linux-x86-64.so.2, NEEDED libc.so.6) y la caja es musl: no hay camino nativo. Es el caso del ADR 0015, el mismo de sergioh-api. La instancia claude declara, y conviene decir que es ANCHA en vez de disimularlo: red, nesting, y seis directorios —/opt/takana (el trabajo), /work/dev-fs (lab + zig/go), /store, /root/.claude (memoria y credenciales), /root/.ssh (ro) y el CLI (ro)—. Un agente que construye, commitea y empuja necesita lo mismo que un humano haciendo ese trabajo; lo que la jaula compra es que ese alcance esté escrito y acotado, no que sea pequeño.

⚠ El takana que construye no se instala adentro: sale del store, que ya está concedido. Es estático musl y corre igual dentro de una imagen glibc — comprobado (takana 0.0.1).

La caja construye: dos recetas selladas hoy

Antes faltaba una pieza que el lab no traía: .dev-fs/tools (zig 0.13/0.16 y go, 1 G). El primer intento murió con zig no encontrado en .dev-fs/tools/zig/zig — la imagen del lab empaqueta alpine/ y nada más. Copiado eso:

  intel-ucode   → sellado: 156 signatures + GenuineIntel.bin (17 MB)
  sof-firmware  → sellado: 2 firmware + 8 topologías (IPC3 v2.2, TigerLake)

🧱 Lo que NO funciona, y su rodeo

takana build NO corre DENTRO de la jaula, aunque la instancia declare nesting = true:

  bwrap: Can't mount proc on /proc: Operation not permitted

Y no es que el anidamiento esté roto: un bwrap --dev-bind / / --proc /proc a mano SÍ funciona adentro, con y sin --unshare-pid. Lo que falla es el userns anidado que arma el sandbox del build. Probado también con root = false —la sospecha que el propio código documenta (§grants.root ⚠ del 2026-09-03)— y falla igual: no es el remapeo a root.

El rodeo que sí anda, y quedó escrito en el lanzador para que el agente lo use:

  ssh -p 22022 -i /root/.ssh/github5 root@127.0.0.1 \
    'cd /opt/takana && flock -o work/.farm-build.lock takana --store /store build <receta>'

Con eso, desde dentro de la jaula se selló sof-firmware. El agente vive enjaulado y le pide los builds al anfitrión, que es donde el sandbox del build tiene los permisos que necesita.

Cómo se entra

claude en el PATH de la caja (/usr/bin/claude), que envuelve takana qorpa run claude -- env HOME=/root …. El manifiesto y el lanzador están versionados en scripts/servidor/, porque una instancia que sólo existe en la caja se pierde con la caja.

⚠ Pendiente menor: la memoria del agente está en /root/.claude/projects/-mnt-vvv-takana/, y allá el repo vive en /opt/takana ⇒ el índice por ruta no coincide. Se resuelve renombrando el directorio a -opt-takana o dándole al repo la misma ruta; hasta entonces el agente arranca sin su memoria del proyecto aunque los 733 ficheros estén en disco.

6.50 bis 🔑 La cuenta necesitaba sus LLAVES, no su contraseña (2026-09-17)

Creada la cuenta, el primer intento del usuario falló:

  $ ssh -i ~/.ssh/tawasuyu sergio@gioser.net -p 2345
  sergio@gioser.net: Permission denied (publickey).

Y era exacto: el sshd de la caja tiene PasswordAuthentication no, así que la contraseña tawasuyu sirve para su y para la consola, no para entrar por SSH. Lo que faltaba era su ~/.ssh/authorized_keys, que se creó vacío con la cuenta. Copiado el de gioser —dos llaves, tawasuyu y sergio@tatata— entra:

  $ ssh -i ~/.ssh/tawasuyu sergio@gioser.net -p 2345
  ENTRA como sergio en takana · /home/sergio
  $ claude -p "…"   →  ENTRÉ POR SSH Y ABRÍ CLAUDE

Dos detalles que hacen que esto se sienta como la máquina de siempre: gioser.net ya resuelve a la caja, y la llave de host es la MISMA que la de gioser (se copiaron en el cutover del gitea, §6.25) — comprobado: SHA256:ltSl+rgr2Uc… en las dos. Por eso no aparece el aviso rojo de «REMOTE HOST IDENTIFICATION HAS CHANGED» al entrar al nombre de siempre.

⚠ El sshd escucha en 22022 y 2345, los dos generales: 2345 es el puerto que los clones de git ya usaban, y sirve igual para entrar.

6.50 ter 🧰 sudo y el taller: dónde se programa en la caja (2026-09-17)

sudo no andaba por dos cosas a la vez, y una era el corte de energía. /usr/bin/sudo no tenía el bit setuid (sudo: must be owned by uid 0 and have the setuid bit set), y además /etc/sudoers.d/sergio había desaparecido: lo escribí minutos antes del reset del §6.51 y se fue con el mismo corte que dejó el cortafuegos en NULs. Repuestos los dos —y con sync—, sudo id devuelve uid=0(root). visudo no está instalado, pero no hace falta: el fichero suelto en /etc/sudoers.d/ es la forma correcta, y sudo lo valida solo.

⚠ doas sigue dando Operation not permitted aun estando setuid. No hizo falta perseguirlo —sudo resolvió— pero queda anotado como rareza sin explicar.

Dónde están los repositorios

Los 44 están en la caja, en el gitea que se mudó el 14-sep: /var/lib/gitea/repositories/ (sergio/ 939 M, tawasuyu/ 547 M). Lo que NO había era un clon de trabajo: sólo /opt/takana, que es el del hub.

  ~/src  →  /work/sergio          ← el taller
  /work/sergio/tawasuyu  478 M    ← clonado, origin al gitea de la caja

⚠ El taller va en /work, no en el home. La raíz de esta caja tiene 2,4 G libres y /work 43 G: un clon del monorepo en /home llena la raíz y tumba la máquina.

⚠ Y clonar acá tiene dos trampas medidas:

1. El git del corpus no tiene remote-https (git: 'remote-https' is not a git command), así que no se puede clonar por HTTPS desde la propia caja. Es la deuda ya anotada del §bloqueantes.
2. Clonar por SSH (ssh://gitea@git.gioser.net:2345/…) exige que la llave esté registrada en la cuenta de gitea, no basta con el authorized_keys del sistema. Hasta que se registre, el camino es el sistema de ficheros (git clone /var/lib/gitea/repositories/<org>/<repo>.git) — con dos detalles: el directorio de cada organización es 0700 del usuario gitea, así que hay que clonar como root y chown después; y git rechaza el repo por dubious ownership hasta que se le dice git config --global --add safe.directory "*".

Y el agente se abre sobre cualquiera de ellos:

  PROY=/work/sergio/tawasuyu claude
  → «Es tawasuyu (/work/sergio/tawasuyu, origin git.gioser.net:2345/…), último commit 55e5f0f27»

6.50 quater 📦 Cómo se instala software de tawasuyu en la caja — y por qué NO con actualizar-servidor.sh (2026-09-17)

Pregunta del usuario: «¿ahí tengo la confianza de install-tawasuyu y actualizar-servidor? ¿o cómo es la forma de instalar, por ejemplo, shuma-tui?»

Esos guiones existen y siguen ahí —el monorepo está clonado en /work/sergio/tawasuyu— pero lo que hacen es:

  cargo build --release <crates>        …y después…        install -m755 <nuevo> /usr/local/bin/<x>

O sea: producen exactamente la clase de binario que la mudanza encontró irreproducible — 2,7 G de sueltos que ningún paquete provee (§6.35), de los cuales tres corrían desde un inodo BORRADO. Además actualizar-servidor.sh escribe servicios en /etc/init.d/, que en esta caja no existe: el init es arje.

La forma de acá, hecha de punta a punta con shuma-tui

  1. receta      recipes/shuma-tui.toml   — pinneada al commit del monorepo, zig-cc, musl, estática
  2. build       takana build             ⇒ b3:f795ee0f… sellado en el store
  3. viaja       worker → hub → caja      (rsync del artefacto, que es content-addressed)
  4. instalar    ln -s /store/<hash>-shuma-tui/usr/bin/shuma-tui /usr/bin/
  5. control     shuma-tui --help  →  contesta

Los pasos 3 y 4 son el atajo honesto de hoy; el camino completo es el del §6.46 —publicar en el repo firmado y takana install <nombre> --require-signed—, que ya está probado y es lo que convierte «copiar un binario» en «instalar un paquete».

⚠ El paso 2 NO se puede hacer en la caja todavía, y el motivo es la deuda ya conocida: su git no tiene remote-https.

  git: 'remote-https' is not a git command
  Error: git ["clone","--mirror",…,"https://git.tawasuyu.net/…"] falló

Las recetas del corpus que bajan tarballs con curl sí construyen ahí (hoy se sellaron intel-ucode y sof-firmware); las que clonan por HTTPS —todas las de tawasuyu— hay que construirlas en el worker, que sí tiene git completo. Arreglar eso es re-sellar git con libcurl, y es raíz de perfil.base: unidad propia.

6.50 quinquies 🔑 Las fuentes git se traen por SSH — y la raíz de 5,9 G tiró la caja entera (2026-09-17)

El §6.50 quater dejó anotado el muro: la caja no tiene git-remote-http, así que las 36 recetas que clonan de git.tawasuyu.net —y las ~90 de GitHub— no se podían construir ahí. La salida es la que pidió el usuario: usar SSH. Y sale gratis en hashes, porque la URL es un LOCALIZADOR y no entra en hash_inputs (ADR 0013): el mismo commit por otro transporte sella el mismo artefacto.

No se toca ninguna receta —el worker sigue clonando por HTTPS, que es lo que puede— sino la caja:

  git config --global url."ssh://gitea@git.gioser.net:2345/".insteadOf "https://git.tawasuyu.net/"
  git config --global url."ssh://git@github.com/".insteadOf        "https://github.com/"

Tres cosas que costaron una vuelta cada una, las tres MEDIDAS:

1. takana clona bien, pero cargo vendor clona aparte. cargo honra el insteadOf, pero usa su propio cliente SSH: primero se plantó por la clave del host —la tenía como [git.gioser.net]:2345 y cargo la busca sin puerto, misma clave reexpresada— y después por autenticación, porque no sabe leer IdentityFile de ~/.ssh/config. Se resuelve delegando en el git de verdad:

   # ~/.cargo/config.toml
   [net]
   git-fetch-with-cli = true
   

2. La huella de github.com se PINEA, no se acepta a ciegas. ssh-keyscan dio SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU, idéntica a la que GitHub publica, y por eso entró a known_hosts. La clave de esta caja autentica como deploy key de otro repo y aun así lee repos públicos ajenos: comprobado con uutils/coreutils.

3. Y la que dolió: la raíz son 5,9 G y cargo la llenó. CARGO_HOME estaba en /root/.cargo, o sea en sda2. El vendor del monorepo bajó 2,7 G, la raíz llegó al 100 %, y la caja no se degradó: se cayó entera — sin HTTP, sin SSH y sin responder al ping, con Hetzner informando running. Hubo que entrar por rescate otra vez.

   Lo que el disco lleno deja como rastro, y conviene saber leer:

     caddy   → «write error: write /var/log/caddy/requests.json: no space left on device»
     mis     → /root/.ssh/config quedó con 105 BYTES NULOS al final: el append entró a medias
     escrituras  (el mismo daño que el corte de luz le hizo al reglaset del cortafuegos, §6.51)
   

   Un >> que falla por ENOSPC no deja el fichero como estaba: lo deja extendido y relleno de ceros. Es exactamente la clase de avería que el §3 de CLAUDE.md describe para los artefactos vacíos — llega hasta el final diciendo que todo fue bien.

Reparado en el rescate, y las tres piezas son permanentes:

qué	dónde	por qué
/root/.cargo → /work/cargo-home	symlink	2,7 G de caché no caben en una raíz de 5,9 G
poda horaria de logs	/usr/local/sbin/poda-logs.sh + cron 17 * * * *	ente-gitea.log había llegado solo a 114 M y nadie lo rotaba
.ssh/config y .gitconfig	reescritos	tenían NULs de las escrituras a medias

Tras el arranque: raíz al 54 %, los 18 entes corriendo y los 7 dominios de la caja en 200 (terapeuta.ec sigue en gioser a propósito — se decidió respaldar, no mudar).

La lección, que no es sobre cargo. La raíz de esta caja es 5,9 G y todo lo que crece sin dueño vive ahí: logs, cachés, spool. No hay margen para «ya lo limpio después», y el modo de fallo no es un error: es la máquina entera apagándose en silencio. Cualquier cosa que acumule bytes en la caja se declara dónde vive antes de correrla por primera vez.

El control que cierra esto: la caja construyó una receta de tawasuyu de punta a punta

puriy-costura era la única de las 36 que no estaba en el store de la caja — o sea, un fallo de caché de verdad, no un cache-hit disfrazado de éxito (cache-congela-regresiones es justo esto). La caja la hizo entera y sola: clonó por SSH (111,7 M de mirror), vendoreó, compiló y selló.

  hash que predice el HUB  b3:7d63655aa5fea3cbc08724887617d7f58b325fcb2e00ac050b1937966c2459e6
  hash que selló la CAJA   b3:7d63655aa5fea3cbc08724887617d7f58b325fcb2e00ac050b1937966c2459e6
  contenido                2,2 M · usr/bin/puriy-costura · corre y muestra su ayuda

Idéntico, que es lo único que prueba que el transporte no contamina el artefacto. Con esto la caja cumple la condición que puso el usuario para poder borrar gioser —«con capacidad de compilar tawasuyu y las recetas de takana»— desde fuente y por su cuenta, no por artefactos que le llegan del worker.

El guion scripts/servidor/fuentes-por-ssh.sh deja esto reproducible: idempotente, con la huella de github pineada (si el host anuncia otra, sale con error en vez de aceptarla) y con un control final que CLONA de los dos orígenes. Probados sus dos negativos: un repo inexistente lo hace fallar, y una huella cambiada la rechaza.

6.50 sexies ✅ Pagada la deuda: el git del corpus vuelve a clonar por HTTPS (2026-09-17)

El §6.50 quinquies dejó la caja trayendo fuentes por SSH porque su git no tenía remote-https. Eso era el síntoma; la causa estaba un paso antes de donde todos mirábamos —incluida la nota que yo mismo había escrito, que culpaba al Makefile—.

El tarball de git trae configure, y takana lo corre. Su test de libcurl es AC_CHECK_LIB, que enlaza conftest.c -lcurl y nada más. Con libcurl estática eso no resuelve: faltan -lssl -lcrypto -lz, que son sus privadas.

  checking for SHA1_Init in -lcrypto...       yes
  checking for curl_global_init in -lcurl...  no      ← acá se decidía todo
  checking for XML_ParserCreate in -lexpat... no

El test falla, config.mak.autogen se lleva NO_CURL=YesPlease, el Makefile excluye git-remote-http, git-http-fetch y git-http-push —y conserva git-http-backend, que es el lado servidor y no usa curl: esa asimetría en el artefacto era la firma del fallo, y estuvo a la vista desde el 2026-09-14—. El build termina en verde. Es el §3 de CLAUDE.md en su forma más cara: un ausente falla ruidosamente, un vacío llega hasta el final diciendo que todo fue bien.

La cura, tres líneas en la receta, cada una con su motivo:

línea	por qué
LIBS="$(curl-config --libs)" al configure	le da al test lo que el enlace estático necesita — y sale de curl-config, no escrito a mano: si curl gana privadas mañana, las trae solo
guardián sobre config.mak.autogen	el modo de fallo es silencioso ⇒ se comprueba el HECHO (NO_CURL=YesPlease) y se corta, en vez de enterarse meses después
NO_EXPAT=1	con curl encendido el Makefile agrega http-push.o, que pide -lexpat, y expat no está en deps. http-push es el push por WebDAV: clonar y traer no pasa por ahí

Medido sobre el artefacto, nunca sobre el git del host (ls $(git --exec-path) | grep remote-http): b3:215742cb… trae git-remote-http, git-remote-https, git-http-fetch y los ftp. Y clona —no ls-remote: clone, que es donde murió la vez del ubsan—: árbol en disco y rev-list contesta. En la caja, hidratado y con la reescritura a SSH apagada, git clone https://… funciona, y git clone --mirror —el comando exacto que usa takana build para traer fuentes— también.

El radio, medido en vez de temido. La nota vieja decía que arreglar esto «re-sella git, que es raíz de perfil.base ⇒ radio grande». yupana radio git dice otra cosa: cero dependientes directos y cero transitivos. Toca las 7 imágenes que lo incluyen —que es re-ensamblar, no reconstruir—. El miedo escrito a mano había sobrestimado el costo de arreglarlo, y eso lo mantuvo roto tres días.

Las reescrituras url.insteadOf quedaron retiradas de la caja: ya no hacen falta. scripts/servidor/fuentes-por-ssh.sh se conserva como salida de emergencia, no como el camino normal.

6.52 🧩 Las proc-macros SÍ se pueden compilar en la caja — falta un cc, no un parche (2026-09-18)

Con rust sellado, la caja compila y corre binarios estáticos sin tocar nada. Lo que no compilaba es cualquier dylib, y eso incluye todas las proc-macros (serde_derive, clap_derive…), o sea media ecología de Rust:

  ld.lld: error: unable to find library -lgcc_s
  ld.lld: error: unable to find library -lc

Por qué el -L obvio empeora las cosas

La reacción natural es darle el camino: -L /usr/lib. Y eso rompe los estáticos, que hoy funcionan. Cuatro controles lo aíslan:

	enlace	resultado
A	estático, sin -L	✅ enlaza — es lo que hay hoy
B	estático, con libgcc.a a la vista	✅ enlaza — el arreglo de gcc-libs no rompe nada
C	estático, con -L /usr/lib + libgcc.a	❌ rompe
D	estático, sólo con -L /usr/lib	❌ rompe ← la culpable

  ld.lld: error: relocation R_X86_64_32S cannot be used against symbol '__malloc_size_classes';
          recompile with -fPIC            ← sale de /usr/lib/libc.a, que NO es PIC

rustc enlaza musl static-PIE con su copia self-contained; meter /usr/lib en el camino le hace preferir la libc.a del sistema, que no sirve para PIE. El camino de librerías no puede ser global: el estático lo quiere fuera y el dinámico lo quiere dentro. Ningún RUSTFLAGS global arregla esto — apaga un caso y enciende el otro.

Lo que sí funciona, medido de punta a punta

Quien sabe distinguir los dos casos es un driver de C. La caja no tiene gcc ni clang —clang18 en el store son sólo cabeceras y librerías, sin binario— pero sí tiene zig: el artefacto seed-zig del bootstrap trae zig 0.16.0 y corre. zig cc es un driver de C completo con musl adentro.

  cc        →  zig cc
  RUSTFLAGS →  -C linker=cc -C linker-flavor=gcc -C link-self-contained=no

Las tres banderas hacen falta y cada una por su motivo: linker+linker-flavor para que el enlace pase por el driver, y link-self-contained=no porque si no rustc pide su propio rust-lld —que este toolchain no tiene, ya que rust.lld = true es incompatible con el llvm-config externo (§ la receta lo documenta)— y muere con «the self-contained linker was requested… it wasn't found». ⚠ La variante fina -C link-self-contained=-linker no sirve: es inestable en este triple y exige -Z unstable-options. La gruesa, =no, es estable.

Con eso, la cadena completa que nunca había compilado:

  1. la proc-macro            ⇒ libpm.so
  2. el programa que la usa   ⇒ imprime «PROC-MACRO VIVA»
  3. y el estático de siempre ⇒ sigue enlazando

Entregado: scripts/servidor/cc-por-zig.sh

El envoltorio existe y está puesto en la caja. No mete nada nuevo en el corpus: usa el seed-zig que YA está en el store —producto del bootstrap (SDD 11), como stage1-rootfs— y sólo lo envuelve en /usr/bin/cc y /usr/bin/c++, más las tres banderas en /etc/profile.d/. Volver a zig el compilador de C oficial de la distro es otra cosa —ahí sí haría falta receta y pin propios— y es decisión de ADR, no de un guion de puesta a punto.

Es idempotente y sus cuatro controles preguntan por el HECHO:

  ✓ C: C en takana                                  ← compila y EJECUTA un hola mundo
  ✓ rust: proc-macro: 42                            ← la macro enlaza, el que la usa corre
  ✓ rust estático (sin banderas): estático ok       ← el remedio no rompió lo que funcionaba
  ✓ entorno: una shell de login trae RUSTFLAGS puesto

Ese último control encontró algo de paso, y es la clase de cosa que este repo persigue: en la caja /etc/profile.d no lo leía NADIE, porque /etc/profile no existía. El fichero de las banderas habría quedado presente, con contenido y sin ningún efecto — y el bash_completion.sh que ya estaba ahí llevaba quién sabe cuánto igual de mudo. Se creó el /etc/profile con el bucle estándar. La caché de zig cc vive en /work/zig-cache (54 M) y no en la raíz de 5,9 G, por lo aprendido en §6.50 quinquies.

6.53 🔧 Borré /usr/bin/id probando el setuid (2026-09-18)

Para saber si el bit setuid elevaba en esta caja copié busybox sobre /usr/bin/id —porque busybox elige el applet por argv[0] y necesitaba un nombre válido— y después borré «mis» copias de prueba. Una de ellas era el id del sistema. Resultado, del lado del usuario:

  $ claude --dangerously-skip-permissions
  /usr/bin/claude: line 23: id: not found
  $ id
  -bash: /usr/bin/id: No such file or directory

No quedaba ninguno: /bin/id tampoco existía. Se restauró como sus hermanos de identidad —whoami y groups apuntan a ../../bin/busybox— y se comprobó con id de root, de sergio y con el id -un que usa el lanzador. Barrido posterior: 0 enlaces colgados en /bin, /usr/bin, /sbin y /usr/sbin, y presentes los ocho comandos de los que dependen el arranque y el lanzador.

La lección, que es de método: para probar una propiedad del sistema —¿eleva el setuid?— no se usa un nombre que el sistema ya ocupa. La sonda correcta era la que terminé escribiendo: cinco líneas de C compiladas con el cc nuevo a un nombre inventado (probe-suid). Copiar sobre id fue elegir el camino corto, y el camino corto se llevó un binario del que depende hasta el script que abre al agente. Es la misma familia que el /etc/shadow del §6.51: la caja no avisa cuando le falta algo esencial — se entera el que lo usa.

6.54 🧭 Trabajar DESDE la jaula: lo que el agente de adentro reportó (2026-09-18)

El agente enjaulado pasó un informe de defectos —el primero hecho desde adentro— y vale más que cualquier inspección desde el anfitrión, porque son las cosas con las que se choca al usarla.

Lo que se arregló, y dónde vive cada arreglo

#	defecto	dónde queda el arreglo
1	sin entrada en /etc/passwd para el uid de adentro ⇒ ssh/git mueren con No user exists for uid 1001	jaula-preparar.sh (upper)
2	/etc/ssh/ssh_config.d es de la capa inferior, dueño fuera del mapa ⇒ ssh aborta, no degrada	jaula-preparar.sh (upper)
3	~/.ssh en ro ⇒ ssh no puede escribir known_hosts	manifiesto: pasa a rw + semilla desde el anfitrión
4	sin clave para el worker ⇒ Permission denied (publickey), cero granja	clave propia de la caja autorizada en el worker
5	sin rsync/python/jq/b3sum, y sin takana ejecutable	manifiesto: packages; y un takana que sale del store

El 1 y el 2 viven en el upper, que por el D3 es caché descartable: al primer recreate se pierden. Por eso existe scripts/servidor/jaula-preparar.sh, que los repone —escribiendo como la persona, no como root, para no dejarle ficheros que después no puede tocar—.

Sobre el 4: se autorizó en el worker la clave de la caja (sergio@caja), no la de root. Es una credencial distinta y revocable: quitarla del authorized_keys del worker corta ese acceso sin tocar ningún otro. Comprobado: ssh root@dev.gioser.net hostname desde la caja contesta PruebasIA.

Sobre el 5: takana no se compila adentro. El binario es el musl estático del store y corre igual dentro de una imagen glibc; lo que fallaba es que /opt/takana/target/release/takana del anfitrión es un enlace a /usr/bin/takana, y adentro /usr/bin es el de Arch. Queda /work/sergio/bin/takana, que elige el más reciente del store —no un hash cableado, para que sobreviva a un re-sellado— y el target/release/takana del clon apunta ahí.

Las tres trampas de orientación, que no son defectos pero cuestan una hora

• El store real es /store, 61 G y 1333 artefactos. Los runbooks y el CLAUDE.md dicen takana build --store ./store porque están escritos para el HUB; copiado literal en la caja, eso apunta a un store vacío dentro del clon. Desde la caja va --store /store.
• Hay dos checkouts y no son intercambiables: /work/sergio/takana es el de trabajo —suyo, con push propio—, y /opt/takana es el del sistema: el que usan el cron, la granja y los servicios. Editar el segundo por costumbre es pisarle el árbol al latido.
• scripts/farm/.fleet ausente NO es un defecto —el propio informe lo retiró—: flota-permanente está versionado y cosecha-cron lo repone.

6.55 🔓 «Una sola sesión» es del KERNEL; «un solo Claude» era nuestro (2026-09-18)

El usuario chocó con Resource busy al abrir un segundo agente y lo llamó por su nombre: «no quiero restricciones arbitrarias». Tiene razón en la queja y conviene separar qué es qué, porque las tres cosas se sienten igual desde afuera y son muy distintas:

1. Lo que impone el kernel. Dos overlays sobre el mismo upper los niega overlayfs, no nosotros: la capa mutable se corrompería. qorpa reintenta seis veces y después explica la causa en vez de dejar el error crudo de bwrap. Eso no se toca.

2. Lo que era empaquetado nuestro — y sí se toca: una instancia por persona. De ahí salía «un solo Claude». Instancias distintas tienen upper distintos y conviven sin problema. Medido: crear la segunda cuesta 0 s y 16 K, porque la imagen se comparte de sólo lectura.

3. Lo que era un accidente, y se arregló al encontrarlo:

	estaba	ahora
/var/lib/hammer/qorpa/instances	root:root 755 ⇒ una persona no podía crear su propia instancia	root:sergio 2775 (setgid)
~/.ssh en la jaula	ro ⇒ ssh no escribe known_hosts	rw
/store en la jaula	ro ⇒ el agente lee y no puede sellar	rw
claude	abría /opt/takana siempre	abre $PWD
/usr/bin/claude	copia congelada del guion	enlace al del repo

⚠ Y queda un defecto de verdad, que hoy bloquea el punto 2: aprovisionar una instancia nueva muere con bwrap: Can't mkdir parents for /run/user/0: Permission denied. La causa está medida: esta caja no tiene /run/user —no hay logind— y qorpa.rs:1542 arma la ruta del runtime dir como /run/user/<uid> sin alternativa. XDG_RUNTIME_DIR no alcanza: lo honra otra rama del código (1244/1549), no ésta. Es arreglo en el crate, no en un manifiesto.

Lo que conviene no confundir. La jaula restringe al agente, no a la persona: sergio tiene sudo, entra por ssh y manda en la caja entera. Y dentro de la jaula el alcance es declarativo (D7): lo que no está en grants no se ve, pero agregarlo es editar un fichero, no pedir permiso. Lo indefendible no es que haya límites — es que un límite accidental parezca de diseño, que es exactamente lo que pasó con los cinco de la tabla.

6.51 🔥 Me dejé afuera de la caja — 20 minutos caída, y tres causas encadenadas (2026-09-17)

Crear una cuenta de usuario tiró el servidor de producción. Queda escrito entero porque ninguna de las tres causas era la que parecía, y las tres siguen ahí para quien venga.

1. /etc/shadow no existía, y crearlo cerró el SSH de root

La caja nunca tuvo /etc/shadow: todas las cuentas llevan x en /etc/passwd y entran por llave. Para darle contraseña a sergio creé el fichero con todas las cuentas bloqueadas (!) y la suya con su hash. Efecto inmediato: ssh de root empezó a dar Permission denied (publickey) con la misma llave de siempre. Este sshd rechaza la llave de una cuenta cuyo hash está bloqueado.

⇒ La forma correcta acá es la vieja: el hash va en el campo 2 de /etc/passwd y no hay /etc/shadow. Así quedó, y así funciona su - sergio.

2. La caja NO reinicia por ACPI

Con el SSH cerrado, hcloud server reboot (ACPI) no hizo absolutamente nada: arje-zero no atiende esa señal. La web siguió sirviendo como si nada. Para un mantenimiento remoto eso importa: la única forma de reiniciar esta caja desde fuera es reset, que es un corte de energía.

3. Y el corte de energía dejó el cortafuegos a medio escribir — eso fue lo que la aisló

Tras el reset la caja arrancaba —los logs de arje lo probaban: gitea y caddy escribiendo— pero nadie llegaba. La causa, encontrada mirando el fichero:

  $ head -c 90 /etc/takana/cortafuegos-entrada.nft | od -c
  0000000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0

El reglaset era TODO NULs. Se había escrito minutos antes del corte: ext4 journaló el tamaño y los datos nunca llegaron al disco. Un fichero de 5 KB de ceros — o, peor y más probable en el primer arranque, medio fichero válido: la tabla con policy drop y las reglas de accept cortadas. Eso es exactamente una caja que arranca, corre todo, y no deja entrar a nadie.

⇒ Después de escribir algo que el arranque necesita, sync ANTES de cualquier reset. Y el corolario amargo: un reset no es un reboot, y lo que se perdió no avisa.

Lo que el rodeo destapó, y vale más que el susto

• El cortafuegos NO se estaba aplicando en ningún arranque. Su card sale 78 si nft -c falla, y con el fichero corrupto fallaba siempre: la caja llevaba días arrancando sin filtrar, en silencio, porque «no aplicar nada» es su modo seguro y nadie mira un 78 en un log de boot. Reparado el fichero, ahora el arranque deja 21 reglas dport, comprobado tras un reinicio.
• netup es DHCP-only y falló dos veces seguidas («sin respuesta DHCP (tipo 2)»). Una caja con IP fija no debería depender de que el DHCP conteste: si no contesta no hay segundo intento, y el síntoma —desde fuera— es idéntico al de una máquina que no bootea. Se le añadió al init una dirección estática de respaldo con la forma que pide Hetzner (IP /32 + puerta scope link).
• Esa red de respaldo no corría: su guarda era [ -d /sys/class/net/eth0 ] y el init no monta /sys. El diagnóstico que lo probó tuvo que escribirse a FICHERO, porque /dev/kmsg no sobrevive al reinicio y sin red no hay forma de mirar. Cuando no hay red, el log tiene que estar en el disco.
• Del rescate salió el mapa real de particiones, que no era el que yo creía: sda2 hammer-root · sda3 hammer-state · sda4 hammer-work · sdb hammer-store.

El costo, dicho sin adornos

~20 minutos de caída de los ocho dominios, cuatro ciclos rescate↔sistema y tres reset duros — uno de ellos, el que corrompió el fichero, disparado por mí a los 400 s de espera mientras la caja estaba haciendo su trabajo. La lección que queda no es «hay que tener cuidado»: es que en esta caja el diagnóstico remoto cuesta un ciclo de 6 a 8 minutos, así que conviene gastar el primero en dejar evidencia en disco antes que en probar una corazonada.

7. Reusar los scripts que ya existen, y no escribir de nuevo

Pedido explícito del usuario. El inventario de lo que ya hace el trabajo:

para	script existente	qué le falta
armar el rootfs de un perfil	scripts/hydrate-profile.py	nada — es el camino bueno (los hydrate-*.sh por escritorio divergen de targets.toml)
producir el .img	scripts/install-image.sh / scripts/product-image.sh	apuntar al perfil.servidor
escribir a disco	scripts/takana-install.sh	el envoltorio de rescue del §3.2
instalador con TUI	scripts/takana-live-install.sh	ser el mismo motor que el remoto, con las respuestas por fichero
provisionar un worker	scripts/farm/vps-setup.sh	ya soporta apt y dnf; le falta la rama «takana puro» (sin gestor de paquetes ajeno)
enchufar a la granja	scripts/farm/.fleet	está en .gitignore ⇒ un hub recién clonado nace con la flota vacía en silencio
latido	scripts/farm/cosecha-cron.sh	decidir cron vs tarjeta de arje (§3.4)
respaldo	scripts/respaldo-storagebox.sh	nada — es interrumpible y continuable
absorber el init ajeno	arje-absorb	el lector de procesos vivos (§4)

⚠ Un motor, tres frentes. La tentación es escribir el instalador remoto aparte del TUI. Ahí es donde divergen: ya pasó con los hydrate-*.sh contra targets.toml, y con la unidad systemd del worker que quedó vieja mientras el repo estaba al día. La instalación remota tiene que ser la misma que hace la persona, grabada en un fichero de respuestas.

---

8. churay como instalador centralizado — la dirección, no la decisión

El usuario lo planteó el 2026-09-09: un instalador único, con CLI y TUI, que sirva para

• las apps de tawasuyu,
• paquetes sueltos en cualquier distro, al estilo nix (instalar sin ser root, sin tocar el sistema anfitrión),
• takana mismo,
• y llimphi.

Encaja con lo que ya hay y por eso vale escribirlo: takana install ya resuelve por nombre contra un índice firmado y ya acepta múltiples orígenes; qorpa (ADR 0015) ya corre imágenes ajenas enjauladas sobre el mismo kernel; y el vigía de espejos de churay ya corre en cron desde gioser.

No se decide acá. Es un ADR propio, y tiene al menos tres preguntas abiertas antes de escribir una línea: (1) si el instalador «en cualquier distro» hidrata binarios o reproduce desde fuente —la misma pregunta del SDD 27 §4, y la respuesta puede no ser la misma fuera de takana; (2) quién es el dueño del verbo, si takana install crece o si churay lo envuelve; (3) qué pasa con un host glibc, que es exactamente lo que el ADR 0015 aparta del store a propósito. Queda anotado para que se decida, no para que se descubra a mitad.

---

9. Estado y orden

Decisión del usuario (2026-09-14): la mudanza NO pasa por terceros. Nada de espejar a GitHub para «tener copia fuera»: la copia fuera la da la propia mudanza — en cuanto el gitea vive en la caja nueva, los 26 repos dejan de existir sólo en la máquina que se borra. El objetivo es dejar de pagar dos máquinas, no montar una dependencia más. scripts/mudanza/espejar-repos.sh queda como herramienta disponible, no como paso del plan.

Y el worker no necesita credenciales: las fuentes de tawasuyu se sirven por HTTPS público. Las 23 recetas que apuntaban a gitea@git.tawasuyu.net (SSH) pasaron a https://git.tawasuyu.net/… — la URL es locator y no entra en hash_inputs (ADR 0013), así que se cambió con control y sin mover un solo ArtifactHash. Medido en el worker: clona y git archive extrae el árbol (155 M) sin ninguna clave. Un usuario propio en gitea sólo haría falta para un repo PRIVADO, y hoy ninguna receta usa uno.

Lo que YA está, y no hay que volver a tocar

la caja takana (2.29.29.217)	arranca takana puro, PID 1 arje-zero — §3.8
store, grafos, granja, respaldo	puertas 2, 3, 4 y 7 — §6.3, §6.7, §6.8, §6.10
repo firmado servido por la caja	§5.1
la imagen del perfil servidor con gitea	arranca y sirve 200, supervisado por arje — §6.11
arjectl para operar sin reiniciar	§6.12
el gitea de gioser corriendo sobre takana, con sus datos	ensayo completo — §6.13

Lo que falta para el cutover, en este orden

⚠ La lista de abajo es del 2026-09-11 y los pasos 1-5 YA ESTÁN (gitea mudado y sirviendo, §6.14; estáticos mudados, §6.18; fósiles barridos, §6.19; api.sergio mudado, §6.25; tawasuyu.net y gioser.net mudados, §6.26; squid, §6.27-28; hora, latido y rotación, §6.29; cortafuegos, §6.31-33).

El estado vigente está medido en el §6.34 (2026-09-16), y es más corto de lo que decía esta lista: queda UN solo vhost sirviéndose desde gioser — sergio.gioser.net — y el montón de daemons propios del usuario que ningún paquete provee. Los pasos 6 y 7 son lo único que sigue abierto.

1. Actualizar la caja a la imagen nueva (gitea + arjectl + las cuentas de [[user]]). takana upgrade está probado (§6.13 del SDD 27 y §5.4 acá); el dd es para provisionar, no para actualizar — sobrescribe el disco local y re-etiqueta la partición.
2. Mudar los datos del gitea: sqlite3 … ".backup" (1,5 s, consistente con el servidor vivo) + rsync -aH de /var/lib/gitea y /etc/gitea. El corte final se hace con el gitea del origen parado, para que el último snapshot no pierda escrituras.
3. Caddy en la caja: los 6 dominios vivos del §6.9, con su TLS. Los otros 13 no se mudan.
4. DNS: apuntar esos 6 a la IP nueva. El resto de los clones y remotos no se toca — siguen resolviendo al mismo nombre.
5. Verificar desde fuera: cada dominio vivo responde 200 contra la IP nueva y un git clone real contra el gitea mudado.
6. El resto de servicios vivos del censo (qdrant, squid, act-runner, php-fpm…), por el plan que planear.py ya emite.
7. Borrar gioser — sólo con las 8 puertas en verde, a mano, nunca por automatización (§6).

Bloqueantes conocidos, con su tamaño

• git sellado sin remote-http (§6.13): afecta a clonar POR HTTPS desde una caja takana, no al gitea que sirve. Re-sella git, raíz de perfil.base ⇒ unidad propia.
• Puerta 5 sigue a medias: la caja sirve su repo pero no se instala de él (install reproduce y eso exige el lab entero). No bloquea la mudanza; bloquea «el servidor se sirve a sí mismo».

El volumen del store NO se engancha a la caja hasta que pase la puerta 1 — ya pasó, y el store local de 68,7 G alcanza, así que la mudanza no depende de mover el volumen de gioser.