1# SDD 28 — El servidor de producción: instalar takana puro en una caja remota y mudarse a ella
2
3Escrito 2026-09-09 a pedido del usuario («qué tan lejos estamos de montar un server takana en
4Hetzner y que sea producción, y mover allá todo lo que tengo acá, y de una vez mantenerlo por repo
5takana»). Todo número marcado *(medido)* salió de un comando corrido ese día sobre `gioser`.
6
7Continúa [SDD 19](19-lanzamiento-publico.md) (lanzamiento público) y
8[SDD 27](27-perfiles-instalables-y-el-instalador.md) (metapaquetes e instalador). **No repite el
9instalador**: SDD 27 decide QUÉ se instala y con qué verbo; esto decide DÓNDE, y cómo se llega.
10
11---
12
13## 0. La corrección de encuadre: ya estamos en Hetzner
14
15`gioser` **es** un servidor Hetzner (hcloud id `126324694`, hel1, 4 cores / 7,6 GiB) *(medido)*. La
16pregunta no era «cómo llegar a Hetzner» sino **cómo tener una caja de takana** en vez de ser un
17inquilino más de una máquina compartida que:
18
19- sirve **19 dominios** por Caddy,
20- tiene `/mnt/vvv` al **89 %** (27 G libres) *(medido)*,
21- es **fija y sin backup** por pedido explícito del usuario (blindaje anti-borrado en `deadman.sh` y
22 `farm-down.sh`, ver [ADR 0014](adr/0014-distribucion-multiorigen.md) y la memoria del proyecto),
23- y **no publica nada de takana**: cero entradas de takana en el Caddyfile *(medido)*.
24
25### 0.1 El hallazgo que cambia el tamaño del problema
26
27```
28$ ps -p 1 -o comm=,args=
29arje-zero /usr/local/sbin/arje-zero
30$ cat /proc/cmdline
31BOOT_IMAGE=/vmlinuz-linux root=UUID=54de62df-… rw net.ifnames=0 splash \
32 init=/usr/local/sbin/arje-zero loglevel=4
33```
34
35**El init de takana ya gobierna un servidor de producción real.** Caddy, gitea, sshd, qdrant y
36act-runner cuelgan directo de PID 1 *(medido: `ps -eo pid,ppid,comm | awk '$2==1'`)*.
37
38Pero **eso no es takana puro**: es Artix con nuestro init inyectado por `init=` en el cmdline. El
39kernel, la libc y los 19 servicios son ajenos. Se probó la mitad difícil sobre userland prestado.
40
41### 0.2 ⚠ La declaración del arranque no existe en ningún sitio legible
42
43`rc-status` de OpenRC dice `stopped` para **caddy, gitea, sshd, cronie y act-runner**, y los cinco
44están **vivos** *(medido, los dos comandos)*. `/etc/arje/cards.d` tiene **4 tarjetas** (`acpid`,
45`openrc-openclaw`, `squid`, `zram-swap`) y ninguna de ellas los levanta.
46
47⇒ **La secuencia de arranque de esta caja no está escrita.** Es lo menos reproducible de toda la
48mudanza y lo primero que hay que capturar — ver §4.
49
50---
51
52## 1. Inventario de lo que hay que mudar *(medido 2026-09-09)*
53
54### Datos en `/mnt/vvv` (217 G de 255)
55
56| | |
57|---|---|
58| `tawasuyu` | **124 G** |
59| `takana` | **91 G** — incluye el store de 55 G bind-mounteado desde el otro volumen ⇒ ~36 G propios |
60| `rustup` | 29 G |
61| `act-runner` · `gioserv` · `_respaldo` | 6,5 · 5,4 · 4,1 G |
62| ~20 dirs `*-standalone` | agora, card, chasqui, cosmos, dominium, khipu, minga, mirada, nakui, nahual, pata, pineal, pluma, shuma, takiy, llimphi… |
63
64### El volumen `harkaq-cosecha` (250 G, 148 G usados)
65
66| | |
67|---|---|
68| `store` | **55 G**, **1327 artefactos** — lo irreemplazable |
69| `work-sources` + `cargo-home` + `gopath` | ~85 G — **caché regenerable**, no se muda |
70| `work-tarballs` · `devfs-cache` · `work-out` | 3,2 G · 4,5 G · 397 M |
71
72**El store no se copia por red.** Los dos volúmenes están en `hel1`; un volumen hcloud se desengancha
73de una caja y se engancha a otra en la misma ubicación. La mudanza del store son dos comandos.
74
75### Servicios vivos, todos hijos de arje-zero
76
77`caddy` :80/:443 · `gitea` :3002 · `sshd` :2345 · `act_runner` (el CI de tawasuyu) · `qdrant`
78:6333/:6334 · `openclaw` · `zeroclaw` · `shuma-gateway` :7378 · `tejido` :4102 y :33097 ·
79`puerta-f6e393ff` · `uvicorn` :8771 · `python3` :8770 · `squid` :1137 · `fail2ban` · `glances` ·
80`php-fpm` · `metalog` · **`adb` :5037**.
81
82### Lo que no está en ningún repo
83
84`/var/lib/gitea` (**2,2 G**: SQLite + los repos de git de todo, **incluido el `origin` de takana**) ·
85`/var/www` (287 M) · `/home/sergio/gioser-web/` · `/etc/caddy/Caddyfile` **+ 20 ficheros `.bak`** ·
86los certificados de letsencrypt · los crontabs · `/etc/arje/cards.d` · las 3 credenciales de
87`~/.config/hammer/*.env` · las llaves `~/.ssh/{github5,sergio}` · el token hcloud · y **la memoria
88del agente en `~/.claude/`**.
89
90### 1.1 La basura, contada — porque una mudanza fiel copia también la basura
91
92De los 19 dominios del Caddyfile *(probados uno por uno desde la propia caja)*:
93
94| responden 200 | rotos |
95|---|---|
96| gioser.net · tawasuyu.net · git.gioser.net · summa.gioser.net · sergio.gioser.net | **api.gioser.net → 502** (backend caído) |
97| | **aura · sigma · kosmofono · terapeuta.ec → sin DNS** |
98
99Y sus raíces **no existen en disco**: `/var/www` sólo tiene `terapeuta`, `goaccess`, `ogisoer`,
100`git-tawasuyu`, `letsencrypt` y un `.bak` — no hay `aura_frontend`, ni `sigma`, ni `summa/frontend`,
101ni `kosmofono`. **La mitad del Caddyfile describe un servidor que ya no existe.**
102
103⇒ **Regla de la mudanza: no se muda lo que no responde.** Lo que no tiene DNS ni ficheros se anota y
104se deja morir con la caja vieja. La utilidad del §4 tiene que saber decir *declarado / vivo / fósil*.
105
106---
107
108## 2. La caja: qué, cuánto y por qué
109
110Precios consultados a la API de hcloud el 2026-09-09 (hel1, x86, tipos no deprecados) *(medido)*:
111
112| tipo | recursos | €/mes |
113|---|---|---:|
114| **`cx53`** | **16 c / 32 G / 320 G** | **29,49** |
115| `cpx41` | 8 c / 16 G / 240 G | 32,49 |
116| `ccx23` (dedicado) | 4 c / 16 G / 160 G | 85,99 |
117
118**Elegido `cx53`**: es el mejor punto de la tabla y entra holgado el conjunto tawasuyu + takana +
119rustup (~244 G) si algún día se muda todo.
120
121**Decisiones del usuario (2026-09-09):**
122
1231. **La caja PUBLICA; el LXC prestado sigue moliendo.** `dev.gioser.net` cuesta €0 y es la máquina
124 con más RAM (6 c / 16 G + 8 G swap). Separar *servir* de *compilar* mantiene la caja chica y
125 barata. La caja nueva puede además compilar, con el LXC enchufado como segundo worker.
1262. **«Producción» = operativo pero privado.** Sin descarga pública todavía ⇒ **no** se activan los
127 bloqueantes legales del [SDD 19 §2](19-lanzamiento-publico.md) (espejo de fuentes público por
128 HTTP, marca de terceros). Lo que sí hace falta igual es la **clave de release estable** (§5).
1293. **gioser se BORRA** cuando la mudanza esté comprobada. Eso convierte esto en un experimento con
130 fecha de caducidad, y cambia el diseño entero: ver §6.
131
132⚠ **El blindaje anti-borrado de gioser es deliberado y hay que levantarlo a mano y a propósito.**
133`deadman.sh` y `farm-down.sh` lo protegen por lista negra de nombre **y** por ausencia del label
134`role=hammer-worker`. Ninguna automatización debe poder borrarlo: cuando llegue el día, se borra a
135mano, con la comprobación del §6 en verde y no antes.
136
137---
138
139## 3. Instalar takana puro en una caja remota
140
141### 3.1 Lo que ya está, y por qué está más cerca de lo que parece
142
143**El dato que lo destraba: Hetzner Cloud arranca por BIOS, no por EFI.** *(medido en gioser: no
144existe `/sys/firmware/efi`; GPT + GRUB; `/boot` es vfat de 1 G.)* Y `scripts/takana-install.sh`
145escribe **exactamente ese layout**: GPT + GRUB BIOS, `SeaBIOS → GRUB → kernel → arje-zero PID1`.
146El camino EFI —que fue el que más trabajo costó ([ADR 0010](adr/0010-arranque-grafo-mirada.md))— es
147el que Hetzner **no** necesita.
148
149| pieza | estado *(medido)* |
150|---|---|
151| kernel con virtio | `recipes/linux.toml` compila `VIRTIO`, `VIRTIO_PCI`, `VIRTIO_BLK`, `VIRTIO_NET`, `EXT4_FS` **`=y`** ⇒ sin initramfs |
152| 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 |
153| acceso | `recipes/openssh.toml` sellado; el `product-rootfs` vigente **ya trae `sshd`**; `takana-install.sh` acepta `AUTHKEYS` |
154| servir | `recipes/caddy.toml` existe |
155| escritura a disco | `scripts/takana-install.sh` (no interactivo) y `scripts/takana-live-install.sh` (TUI), probado por `scripts/install-tui-test.sh` |
156
157### 3.2 El camino remoto: rescue → `dd` → reboot
158
159Hetzner Cloud tiene un **sistema de rescate** (Debian por SSH) que se activa desde la API sin tocar
160la caja. Desde ahí se escribe la imagen al disco y se reinicia. **No hace falta ISO, ni consola, ni
161medio físico** — que es justo lo que hace innecesario el 90 % del trabajo de ISO/USB para este caso.
162
163### 3.3 Los cuatro huecos, nombrados
164
1651. **`perfil.servidor`** — **HECHO hoy** en `docs/state/targets.toml`. Ver §3.4.
1662. **`console=ttyS0` en el cmdline** — el único salvavidas si el arranque falla y no hay teclado.
167 Hetzner da consola web; sin serial en el kernel, esa consola no muestra nada útil.
1683. **IPv6** — `netup` hace DHCPv4 y Hetzner entrega un `/64` **estático**. La caja arrancaría con
169 IPv4 sola. Aceptable para empezar, pero hay que saberlo **antes**, no descubrirlo.
1704. **Un `.img` del perfil servidor** que el rescue pueda escribir. Es `hydrate-profile.py` +
171 `install-image.sh`, los dos ya existentes — ver §7.
172
173### 3.4 El perfil, y la deuda que declara *(hecho 2026-09-09)*
174
175`[perfil.servidor]` hereda `cli` (que hereda `base`, [SDD 27 §7.1](27-perfiles-instalables-y-el-instalador.md))
176y añade **5 raíces que existen** (`openssh`, `caddy`, `curl`, `wget`, `tmux`) y **5 que NO**:
177
178| raíz que no resuelve | por qué está declarada igual |
179|---|---|
180| **`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 |
181| `chrony` | sin NTP, un reloj que deriva rompe TLS y las firmas — y falla diciendo «firma inválida», no «la hora» |
182| `nftables` | `dev.gioser.net` está hoy expuesto con fuerza bruta a root en el journal; una caja nueva no debería nacer así |
183| `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** |
184| `logrotate` | en una caja que sirve, el log de acceso crece hasta llenar el disco |
185
186Quedan **`wanted`** en el grafo, y **`wanted` no es `debt`** ⇒ `drenaje.json` seguirá diciendo
187`deuda=0`. Se declaran igual porque **una deuda escrita se ve y una omitida no**: sin ellas el perfil
188saldría N/N —completo y verde— describiendo un servidor sin hora, sin cortafuegos y sin latido. Es
189la lección de `foot` en `escritorio-sway` (121/121 sellado y sin emulador de terminal), pagada por
190adelantado. **Cuenta esperada: 5.** Un sexto `wanted` es un error de tipeo, no una receta nueva.
191
192### 3.5 La caja, creada *(2026-09-10)*
193
194| | |
195|---|---|
196| nombre / id | `takana` / `165447050` |
197| tipo | **`cx33`** — 4 c / 7,6 GiB / 76,3 G — **€8,49/mes** |
198| ubicación | **hel1** — la misma que los volúmenes `vvv` y `harkaq-cosecha` y que el Storage Box |
199| IPv4 / IPv6 | `2.29.29.217` · `2a01:4f9:c014:2f9c::/64` |
200| imagen inicial | `debian-13` — **desechable**: existe sólo para recibir ficheros hasta el `dd` del §3.2 |
201| label | `role=takana-server` |
202| protección de borrado | **NO**, a propósito: es la caja de sacrificio |
203
204⚠ **El label importa**: `farm-down.sh` y `deadman.sh` borran **sólo** lo que lleva
205`role=hammer-worker`. Esta caja no lo tiene ⇒ ninguna automatización de la granja puede tocarla.
206Es la misma capa fuerte que protege a gioser, aplicada al revés: no se protege por nombre, se
207protege por no haber nacido de `farm-up`.
208
209⚠ **`cx53` no se pudo comprar: sale `Available: no` en las TRES ubicaciones.** Y la disponibilidad
210**cambia por día** — `cx33` salió `no` en hel1 el 2026-09-09 y `yes` el 2026-09-10, con la misma
211consulta. ⇒ **el precio de la tabla no dice que la máquina exista**: `hcloud server-type list`
212devuelve precios para tipos que no se pueden crear. Consultar `Available` por ubicación, y volver a
213consultarlo el día que se compra.
214
215#### Lo que la caja confirma, medido EN ELLA y no inferido de gioser
216
2171. **Arranca por BIOS** — no existe `/sys/firmware/efi`… **y sin embargo la imagen trae un ESP**
218 (`sda15`, 244 M vfat en `/boot/efi`). O sea: **la presencia de una partición EFI no indica
219 arranque EFI**. Si el instalador decidiera la rama mirando particiones en vez de
220 `/sys/firmware/efi`, elegiría mal en esta caja exacta. `takana-live-install.sh` mira lo correcto.
2212. **`console=tty1 console=ttyS0` viene en el cmdline de Debian.** Confirma que el serial es lo que
222 Hetzner espera, y que el hueco 2 del §3.3 es real: nuestra imagen tiene que traerlo o la consola
223 web no muestra nada.
2243. **`eth0` con `/32` dinámico por DHCP** — idéntico a gioser ⇒ es exactamente el caso de `netup`.
225
226#### Dos cosas pendientes en la caja, anotadas
227
228- **7,6 GiB de RAM y CERO swap** — la misma clase de máquina que ya provocó `global_oom` en gioser.
229 Coherente con la decisión de §2.1 (la caja **publica**, el LXC muele), pero significa que **no se
230 construye pesado acá** mientras siga así.
231- **`sshd` trae `PasswordAuthentication yes`** (con `PermitRootLogin without-password`, así que root
232 por clave igual). El journal del LXC muestra fuerza bruta a root desde IPs random; esta caja está
233 igual de expuesta. Se cierra cuando se instale takana puro, o antes si se queda días con Debian.
234
235### 3.6 La imagen del `perfil.servidor`, armada y validada *(2026-09-10)*
236
237**Receta del ensamblado** (todo con scripts que ya existían, §7):
238
239```sh
240# 1. base con init: el product-rootfs sellado (trae /sbin/init -> /usr/bin/arje-zero)
241cp -al /mnt/cosecha/store/5011955a…-product-rootfs/. $D/
242# 2. userland del perfil encima
243scripts/hydrate-profile.py servidor --into $D --store /mnt/cosecha/store --keep
244# 3. ⚠ restaurar el init (ver abajo) y meter la clave
245ln -sf /usr/bin/arje-zero $D/sbin/init ; cp github5.pub $D/root/.ssh/authorized_keys
246# 4. imagen
247ROOTFS=$D STAGE=/mnt/cosecha/.install-stage KERNEL=store/23f1cc43…-linux-generic/boot/bzImage \
248CMDLINE="console=ttyS0,115200 console=tty0 root=/dev/sda2 rw init=/usr/bin/arje-zero" \
249 ./scripts/install-image.sh
250```
251
252Resultado: **86 nodos, 30.500 ficheros, 2,0 G de rootfs → imagen de 7.172 M (2,1 G en disco, sparse)**.
253
254#### El kernel correcto es `linux-generic`, y `linux.toml` NO sirve para hcloud
255
256El disco de una caja hcloud lo maneja **`virtio_scsi`** (driver `sd`, disco `sda`) — no `virtio_blk`.
257`recipes/linux.toml` **apaga SCSI explícitamente** (`-d SCSI`) ⇒ su kernel arranca y **no ve el
258disco**. `linux-generic`, `linux-metal` y `linux-metal-dual` sí sirven.
259
260⚠ **Y ninguna receta nombra `SCSI_VIRTIO`.** Está encendido igual, porque `make defconfig` lo trae y
261`-e SCSI -e BLK_DEV_SD` lo mantiene. Se supo mirando el `.config` que `linux-generic` **publica en su
262artefacto** (`/boot/config-7.1.2-generic`), no leyendo la receta. La receta dice lo que se cambió;
263sólo el `.config` sellado dice lo que quedó.
264
265#### ⚠ La hidratación PISA `/sbin/init`, y el resultado arranca igual
266
267`busybox` entra en la clausura del perfil y su `/sbin/init -> ../bin/busybox` **gana por llegar
268después**, borrando el `-> /usr/bin/arje-zero` del product-rootfs. La imagen habría arrancado
269perfecta **con el init de busybox**: no takana puro, y sin un solo error. Se tapa por las dos puntas
270— restaurando el symlink al ensamblar **y** con `init=/usr/bin/arje-zero` explícito en el cmdline,
271que es lo que hace gioser y es autoritativo pase lo que pase con el symlink.
272
273**Y la guarda que existía para esto estaba INVERTIDA** (arreglada en el mismo commit): `[ -e
274"$ROOTFS/sbin/init" ]` sigue el symlink y lo resuelve contra el *host*, así que el symlink ABSOLUTO
275a arje-zero daba falso y **el rootfs correcto era rechazado**, mientras que el relativo a busybox
276—el equivocado— pasaba. Ver [[guardian-que-nunca-fallo]]: una guarda que nunca falló no se sabe si
277sirve; ésta fallaba al revés.
278
279#### EXDEV, dos veces en la misma tarde
280
281`store` y `work/out` son bind-mounts de `/dev/sdb`; `work/` está en `/dev/sdc`. Un hardlink no cruza
282un montaje **aunque sea el mismo disco**, así que reventaron (1) `hydrate-profile.py` con el destino
283fuera del montaje del store —que avisa RUIDOSO y bien— y (2) el staging de `install-image.sh`, que
284lo tenía cableado a `work/`. Ahora `STAGE` es env. Ver [[hardlink-cruza-mount-exdev]].
285
286#### La validación: arrancó en QEMU reproduciendo virtio-scsi, y se entró por SSH
287
288```
289SeaBIOS → GRUB → kernel 7.1.2 propio → EXT4-fs (sda2): mounted → Pivoted into new rootfs
290→ Run /usr/bin/arje-zero as init process → "arje-zero: despierta como PID 1"
291→ netup (DHCP) → ssh-keygen -A → sshd
292```
293
294Y desde fuera: `ssh -p 2299 root@127.0.0.1` **entra**, `/proc/1/comm` dice `arje-zero`, `ip addr` da
295la IP que negoció `netup`. Es la puerta 1 del §6 ensayada en local antes de gastar la caja.
296
297El card `sshd` de `/ente/seed.card.json` ya hacía el trabajo entero sin que hubiera que tocar nada:
298`sh -c "/usr/bin/netup; /usr/bin/ssh-keygen -A; exec /usr/sbin/sshd -D -e"` — red, claves de host y
299demonio en una línea. Lo único que hubo que inyectar fue `authorized_keys`.
300
301#### Un resto del renombre, encontrado por el arranque
302
303```
304arje-zero: hammer no corre, sin menú de arranque: No such file or directory (os error 2)
305```
306
307**`arje-zero` invoca el binario por el nombre VIEJO (`hammer`).** No es fatal —sigue arrancando— pero
308el menú de arranque por grafo del [ADR 0010](adr/0010-arranque-grafo-mirada.md) queda muerto. Y viene
309de tawasuyu, pineado por `commit` en `recipes/arje-zero.toml`, así que **no se arregla desde este
310repo**: hay que subirlo allá y re-pinear. Se suma a que la imagen tampoco trae `takana` (§3.4).
311
312### 3.7 ⚠ El muro real: la puerta de enlace de Hetzner está FUERA del prefijo
313
314La imagen validada en QEMU se escribió a la caja, arrancó… y **no se pudo entrar**. `hcloud` decía
315`running`, el puerto 22 cerrado, y desde fuera `Connection timed out` — el modo de fallo más caro de
316todos, porque no hay consola serie en hcloud para mirar.
317
318La causa, medida entrando al rescue de la propia caja:
319
320```
321inet 2.29.29.217/32 scope global eth0
322default via 172.31.1.1 dev eth0
323172.31.1.1 dev eth0 scope link ← ESTA es la que faltaba
324```
325
326**La IPv4 viene con prefijo `/32` y la puerta (`172.31.1.1`) no pertenece a ninguna red conectada.**
327`netup` mandaba el default con `RTA_GATEWAY` y scope UNIVERSE y nada más, así que el kernel lo
328rechazaba con `ENETUNREACH`: la máquina se quedaba **con IP y sin salida**, contestando el DHCP y
329levantando sshd, sin nada visiblemente roto por dentro.
330
331**Control causal**, en un netns con una dummy y una `/32`:
332
333```
334ip route add default via 172.31.1.1 dev dummy0 ⇒ Error: Nexthop has invalid gateway.
335ip route add 172.31.1.1 dev dummy0 scope link ⇒ ok
336ip route add default via 172.31.1.1 dev dummy0 ⇒ ACEPTADO
337```
338
339Arreglado con `add_onlink_host_route` (dst `/32`, scope LINK) antes del default.
340
341**Por qué no había aparecido nunca**: `netup` se validaba contra el DHCP de QEMU slirp, que entrega
342un `/24` con la puerta dentro de la subred. El escenario que rompe sólo existe en una nube de verdad.
343Es [[cache-congela-regresiones]] en su otra forma: no es que el test estuviera mal, es que el ÚNICO
344entorno donde se probaba no contenía el caso.
345
346**Y destapó un segundo problema de fondo**: el binario de `netup` venía dentro del `product-rootfs`,
347o sea **congelado en un artefacto sellado del bootstrap** ⇒ arreglar netup no llegaba a la imagen.
348Por eso `netup` pasa a ser **raíz de `perfil.servidor`**: así la hidratación lo proyecta encima y la
349imagen lleva el vigente. Verificado por sha256 (imagen `a23df20e…`, product-rootfs `a84b0a0d…`).
350
351### 3.8 ✅ Puerta 1, pasada *(2026-09-10)*
352
353```
354PID 1 : arje-zero kernel : 7.1.2 (linux-generic propio)
355IP : 2.29.29.217 rutas : default via 172.31.1.1 + 172.31.1.1 scope link
356montajes : /dev/sda3 -> /store /dev/sda4 -> /var/lib/hammer
357salida : ping 1.1.1.1 0% pérdida · curl http://1.1.1.1 -> 301 · resolv.conf escrito por netup
358```
359
360**Una caja Hetzner Cloud corriendo takana puro**: nuestro kernel, nuestro init, nuestro cliente DHCP,
361nuestro sshd — sin una línea de Debian debajo. El camino entero es
362`scripts/servidor-image.sh` + rescue + `dd`, y la escritura de los 7,1 G comprimidos tarda **~17 s**
363(gioser y la caja están las dos en hel1).
364
365Lo que la caja **todavía no** tiene, y es el paso 2: `takana` (sin receta, §3.4), el store real (el
366volumen no se engancha hasta acá) y las otras cuatro raíces `wanted`.
367
368---
369
370## 4. La utilidad de migración: absorber lo VIVO, no lo declarado
371
372`arje-absorb` ya existe, está sellado (`recipes/arje-absorb.toml`) y su `--help` dice: lee
373`sysvinit | runit | dinit | openrc | auto` y **emite una Tarjeta Semilla** con cada servicio del init
374ajeno como hija de arje-zero. Tiene parsers para los cinco (`systemd.rs`, `openrc.rs`, `runit.rs`,
375`dinit.rs`, `sysvinit.rs`).
376
377**Pero lee la declaración, y en gioser la declaración miente** (§0.2). Un `arje-absorb --from openrc`
378sobre esta caja produciría una Semilla que **no levanta el servidor**, y lo haría en silencio: la
379Semilla sería sintácticamente perfecta.
380
381⇒ Lo que falta es un **segundo lector**: absorber del **proceso vivo** (`/proc`: `ppid==1`, `cmdline`,
382`cwd`, entorno, fds en LISTEN) y **reconciliar** ambas lecturas marcando dónde discrepan. Eso es lo
383que el usuario nombró como «lo aprendido de matilda» — absorber lo que hay, no lo que está escrito.
384
385La utilidad debe clasificar en tres, no en dos:
386
387| clase | criterio | qué se hace |
388|---|---|---|
389| **vivo** | proceso corriendo **y** declarado | se muda |
390| **declarado, muerto** | en la config, sin proceso ni ficheros (los 4 dominios sin DNS) | **fósil: se anota y se deja morir** |
391| **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 |
392
393**Se construye al final**, estrenándose con la migración gioser → caja nueva, con el caso del
394`rc-status` que miente como test de aceptación. Su especificación es el §1 de este documento.
395
396---
397
398## 5. Que el servidor sirva sus propios paquetes a su propio host
399
400Existe el camino entero: `scripts/build-repo.sh` (corpus → `.swm` firmados + índice),
401`takana install --repo` que **ya acepta lista HTTP multi-origen** y verifica cada paquete contra el
402`digest` del índice firmado ([ADR 0014](adr/0014-distribucion-multiorigen.md)), `takana upgrade` con
403rollback, y caddy para servir `dist/repo` con un `file_server`.
404
405Lo que falta **no es servir**, son dos cosas:
406
4071. **La clave.** `build-repo.sh` firma hoy con una **clave efímera** por defecto (`keygen release` si
408 no se le pasa `KEY=`) *(medido, línea 33)*. Sin clave estable, «firmado» no significa nada. Es el
409 [SDD 19 §3.2](19-lanzamiento-publico.md) y es requisito aunque el repo sea privado.
4102. **La receta de `takana`** (§3.4). El host necesita `takana` instalado para consumir los paquetes,
411 y hoy no puede instalarlo desde el repo porque takana no está en el repo.
412
413### 5.1 Hecho *(2026-09-10)*: clave estable, repo firmado, y la caja sirviéndolo
414
415- **`trust/`** — la clave PÚBLICA de release en el repo; la privada en `~/.config/takana/keys/`
416 (0600, fuera de git). `scripts/repo-perfil.sh` **aborta si no la encuentra** en vez de inventar una
417 efímera, y tras firmar **verifica** el índice contra `trust/`.
418- **88/88** paquetes del perfil `servidor` publicados con `expected_hash` anclado.
419- **La caja los sirve** con `caddy file-server` sobre `/srv/repo`.
420
421**El control de la firma, en los dos sentidos**, contra el repo servido por la caja:
422
423| `--trust` | resultado |
424|---|---|
425| `./trust` | `release: trusted (by release)` ⇒ instala |
426| un directorio vacío | `release: unknown-key … clave no confiada` ⇒ **ABORTA** |
427
428### 5.2 ⚠ Lo que el lazo destapó: `strip_debug` no viajaba en el paquete
429
430La primera instalación real de `takana` desde su propio repo falló:
431
432```
433Error: expected_hash no coincide:
434 declarado = b3:941d1857… obtenido = b3:2727050e…
435```
436
437`why-differs` lo nombró: los dos binarios pesaban **exactamente lo mismo** y sólo divergían en
438`.shstrtab` — la firma de un `strip` que corrió una vez y la otra no. `swm_bridge` re-inyecta con
439cuidado `flags`, `phases`, `zig_version`, `strip_components`, `patches`, `deps`… y **se olvidaba de
440`strip_debug`**, que ni siquiera existía en `SwmBuild`. Como **entra en `hash_inputs`**, el receptor
441reconstruía en otra dirección.
442
443**Alcance: 40 recetas del corpus, 18 de las 88 de este perfil.** Una quinta parte del repo no se
444podía instalar, y nadie lo sabía porque **nunca se había cerrado el lazo**. Arreglado, con test de
445regresión y su control. Tras el arreglo, `install takana` da cache-hit en el hash anclado.
446
447### 5.3 ⚠ Y el loopback nunca se levantaba
448
449Al intentar que la caja instalara de sí misma por `http://127.0.0.1`: **timeout de 30 s**, con caddy
450escuchando en `0.0.0.0:80`. `lo` estaba **`DOWN` y sin dirección** — con systemd o OpenRC lo levanta
451el init; con arje-zero no lo hacía **nadie**. El síntoma no era «connection refused», que se
452diagnostica en un minuto: era un cuelgue que parecía del servidor. Arreglado en `netup` (es quien
453configura la red) y verificado desde la imagen, sin tocar la caja a mano.
454
455### 5.4 🚧 Lo que NO se puede todavía, y por qué importa
456
457Con todo lo anterior en verde, la caja **sigue sin poder instalar de su propio repo**:
458
459```
460release: trusted (by release) ← la firma verifica
461repo: bajados 2 .swm de http://127.0.0.1 ← descarga de sí misma
462Error: no pude leer el apk db del lab en /.dev-fs/alpine/lib/apk/db/installed.
463 El toolchain entra en el ArtifactHash, así que sin rootfs no se puede
464 calcular un hash comparable
465```
466
467O sea: **la mitad de servir está cerrada y probada; la de consumir, no** — y no por un detalle de
468instalación, sino porque `install` **reproduce desde fuente** y eso exige el LAB ENTERO en el
469cliente. No es «falta un compilador»: el lab entra en el `ArtifactHash`, así que sin él no se puede
470ni calcular el hash a comparar.
471
472Es exactamente el punto que [SDD 27 §4](27-perfiles-instalables-y-el-instalador.md) dejó planteado
473y sin decidir —*reproducir o hidratar*— visto desde el otro lado: para un servidor, o para
474cualquiera que no sea un hub de build, **reproducir no es una opción**. El camino normal tiene que
475ser hidratar artefactos firmados, con `--reproduce` como camino auditable. Mientras esa decisión no
476se tome, el repo firmado sirve para distribuir **a hubs**, no a usuarios.
477
478⚠ **Y una caja que se sirve a sí misma es un solo origen** — justo lo que el ADR 0014 existe para no
479tener. El camino normal puede ser el local, pero la lista de orígenes del host debe incluir también
480el Storage Box o gioser. Si no, el primer origen roto es el último.
481
482**Lo que esto vale**: cerrar el bucle es el ensayo de «actualización en sitio probada de verdad»
483([SDD 19 §5.2](19-lanzamiento-publico.md)), hecho sobre una máquina que importa pero que **no es el
484laptop de nadie**.
485
486### 5.5 ⚠ Dos bugs más del lazo, que sólo aparecen si el paquete NO es un binario de Rust *(2026-09-21)*
487
488Pedido del usuario: «instalar zsh con el comando takana». `zsh` es el primer paquete que se instala
489**con varios parches** y **con el binario fuera de `/usr/bin`**, y cada una de esas dos cosas era un
490fallo distinto. Los dos son de la familia del `strip_debug` del §5.2 —algo que el `.swm` no
491transportaba fiel— y los dos **se descubren sólo cerrando el lazo**, no leyendo el código.
492
493**1. Los parches viajaban CONCATENADOS, y eso cambia el hash.** `pack` unía los N parches de la
494receta en el `patch` inline único; `Recipe::hash_inputs` mete **una entrada por parche** y
495`of_inputs` va con longitud prefijada ⇒ N sueltos y N unidos hashean distinto. Medido sin esperar al
496build, con una copia de `recipes/zsh.toml` con sus 6 parches concatenados en uno:
497
498```
499b3:0be3630d… ← expected_hash anclado (y lo que hay en /store)
500b3:d6329a62… ← lo que reconstruye el receptor (= la copia concatenada, exacto)
501```
502
503O sea: `install zsh` recompilaba zsh **entero** y recién entonces moría con `expected_hash no
504coincide`. **Alcance: las 16 recetas del corpus con ≥2 parches** — waterfox 12, firefox y gnupg 11,
505parted/zsh/strace 6, doas/mandoc/giflib 4, freetype 3, libxml2/file/brotli 2…
506
507Arreglado con un campo `patches` (lista, en orden) en el `source_patch`; el `patch` único se sigue
508leyendo para no invalidar lo ya publicado. El receptor materializa **un fichero por parche**.
509Regresión con su **control negativo** en `swm_bridge`: si se concatenan, los `hash_inputs` TIENEN
510que diferir, o el test pasaría por la razón equivocada.
511
512⚠ La tentación era arreglarlo del otro lado —hashear los parches concatenados— y habría sido mucho
513peor: mueve el hash de las **50** recetas con parches e invalida sus artefactos sellados.
514
515**2. `target_bin` era una adivinanza que nadie comprobaba.** `pack` publica `/usr/bin/{name}`;
516`zsh` configura `--bindir=/bin`, así que su binario queda en `/bin/zsh`. El paquete se publicaba
517prometiendo un path que el artefacto no tiene, y el error salía **en la máquina que instala,
518después de hidratar los 1331 ficheros**:
519
520```
521Error: source_patch declara target_bin=/usr/bin/zsh pero no quedó en <prefix>/usr/bin/zsh
522```
523
524Con `--build` el artefacto está delante: ahora `pack` comprueba el path contra él y lo **corrige**
525si el binario quedó en otro bindir, diciéndolo.
526
527⚠ **Y el primer intento fue abortar, que era lo natural y estaba MAL.** Al publicar el perfil
528entero con esa versión, **65 de 175 paquetes se quedaron fuera del catálogo**: son las LIBRERÍAS
529—zlib, ncurses, openssl, musl-\*, gmp…—, que no traen ningún binario y existen para que otros las
530resuelvan como dep. Un campo que su consumidor ni mira habría tirado un tercio del repo. Así que
531no aborta: avisa, y el paquete se publica. Lo mide el barrido de abajo, no el razonamiento — esa
532versión pasaba los tests igual.
533
534**Publicando el perfil `servidor` entero con el `pack` arreglado** *(medido, store del hub)*:
535
536| | |
537|---|---|
538| publicados y firmados | **162** (el índice verifica contra su `trust`) |
539| **`target_bin` corregidos** | **8: `bash` `sed` `tar` `parted` `dhcpcd` `squid` `wpa_supplicant` `zsh`** |
540| sin binario (librerías) | 64 — se publican, con aviso |
541| sin sellar en ESTE store | 12 |
542| fallaron | 1 (`os-release`, el mismo del §6.46) |
543
544Esos 8 son paquetes que **estaban publicados prometiendo un path que no existe**: `install bash`
545habría hidratado y muerto al final. Comprobado después del arreglo, contra el repo firmado servido
546por HTTP: `parted` (6 parches **y** binario en `/usr/sbin`) instala en 0,17 s y responde
547`parted (GNU parted) 3.7`; `bash` instala y responde `5.3.0(1)-release`.
548
549⚠ **Lo que queda vivo y no se tocó:** un `install <librería>` DIRECTO sigue fallando tras hidratar,
550porque el `.swm` exige que el `target_bin` exista y para una librería no hay respuesta buena. Hacer
551`target_bin` opcional toca el formato ([SDD 06](06-swm-format.md)) y es su propia unidad de trabajo.
552Como dep funcionan, que es para lo que están en el catálogo.
553
554**El lazo, después:** `takana install zsh --repo http://… --require-signed` ⇒ cache-hit del hash
555anclado, **1331 ficheros hidratados en 0,14 s**, y el binario corre (`zsh 5.9`). Antes: recompilar
556zsh entero para morir al final.
557
558### 5.6 `takana outdated` — el aviso que faltaba *(2026-09-21)*
559
560Ningún verbo comparaba lo instalado con el catálogo (`upgrade` es de **árboles/generaciones**, no de
561paquetes), así que «avisame cuándo hay que actualizar» no tenía respuesta. `outdated` la da leyendo
562sólo el índice firmado y la DB de instalados — no construye, no baja `.swm`, no escribe nada.
563
564**Compara por hash, no por versión**, y eso es lo único que lo hace útil: un repo se re-publica sin
565que cambie la versión upstream cada vez que se mueve algo que entra en `hash_inputs` (una flag, el
566lab, un parche), y mirar la etiqueta diría «al día» sobre un artefacto que ya no es el que el repo
567sirve. La versión es el respaldo para cuando falta el ancla, y se dice que el juicio es más débil.
568
569`scripts/servidor/avisar-actualizaciones.sh` lo corre por cron y **sólo grita cuando la lista de
570novedades cambia** (un guardián que repite lo mismo cada 30 min deja de leerse). Un repo caído no se
571disfraza de «al día»: lo dice, sale ≠ 0 y **conserva el último estado bueno**.
572
573⚠ **Lo que sigue sin poder hacerse, y no lo arregla ningún verbo:** actualizar en una máquina sin
574lab. El aviso llega a cualquiera; el `install` que lo resuelve sigue siendo reproducir desde fuente
575(§5.4). Por eso `outdated` **no actualiza**: instalar es verificar, y eso no se cuelga de un cron.
576
577---
578
579## 6. La mudanza como experimento: el criterio de borrado
580
581El usuario decidió que **gioser se borra** al final. Eso no es un detalle de calendario: es lo que
582convierte la mudanza en un experimento con criterio de aceptación, y hay que escribirlo **antes**.
583
584**Regla base**: un ausente falla ruidosamente; un vacío llega hasta el final diciendo que todo fue
585bien. Aplicado acá: *«lo copié»* no es prueba de nada. **La prueba es que el servicio responde en la
586caja nueva y que el dato se verifica por contenido.**
587
588### 6.1 Las puertas, en orden. Ninguna se salta.
589
590| # | puerta | cómo se comprueba |
591|---|---|---|
592| 1 | la caja nueva arranca **takana puro** y se entra por SSH | `ssh` a la IP nueva tras el reboot del rescue |
593| 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 |
594| 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» |
595| 4 | la **granja** late en la caja nueva | una cosecha completa con el LXC enchufado por `.fleet` y artefactos que vuelven |
596| 5 | el **repo** se sirve y el host se actualiza de sí mismo | §5 en verde, con la clave estable |
597| 6 | cada dominio **vivo** responde 200 desde fuera | la tabla del §1.1, repetida contra la IP nueva |
598| 7 | el **respaldo** al Storage Box corre desde la caja nueva | una corrida completa, no un `--seco` |
599| 8 | lo **fósil** está anotado y decidido | lista del §1.1 con «muere» o «revive» al lado de cada uno |
600
601⚠ **Puerta 3 tiene una trampa conocida**: `sealed_remoto` dependía de la máquina (laptop 700, gioser
602751 sobre el MISMO corpus) y por eso se sacó del JSON. Si los grafos difieren, mirar primero si la
603diferencia es «cuánto de esto tengo en disco» y no «qué existe».
604
605### 6.3 Estado de las puertas *(2026-09-10)*
606
607| # | puerta | estado |
608|---|---|---|
609| 1 | arranca takana puro y se entra por SSH | ✅ §3.8 |
610| 2 | el store está entero | ✅ **1362 artefactos reales, 0 vacíos** |
611| 3 | los cuatro grafos idénticos | ✅ **byte a byte** — §6.7 |
612| 4 | la granja late en la caja nueva | ✅ **cosecha completa: 1369→1575, 0 vacíos** — §6.8 |
613| 5 | el repo se sirve y el host se actualiza de sí mismo | ⬖ mitad: sirve (§5.1), no consume (§5.4) |
614| 6 | cada dominio vivo responde 200 | ⬖ sondeados: **6 vivos de 19** — §6.9 |
615| 7 | el respaldo corre desde la caja | ⬖ alcanza el box y lista 3140; arreglados 3 bloqueos — §6.10 |
616| 8 | lo fósil, anotado y decidido | ✅ **decidido** — §6.9 |
617
618**Puerta 2, medida acotando al patrón `<hash>-<nombre>`**: 1362 artefactos, **0 vacíos**. Los 3 sin
619`.hammer/recipe.toml` son `stage1-rootfs`, `product-rootfs` y `seed-zig` — productos de bootstrap,
620que por diseño no salen de una receta. (El primer conteo dio «3 vacíos» y eran `.mirror-tmp`,
621`.bootstrap-tmp` y `.divergen`: directorios de trabajo con punto inicial, no artefactos. El chequeo
622tiene que acotar por el patrón, no listar el directorio.)
623
624**De paso, el disco**: la imagen ocupaba 7 G de los 76,3 G de la caja y los otros 69 eran
625inalcanzables. Arreglado en `install-image.sh` — el store pasa a ser la ÚLTIMA partición (la única
626que puede crecer sin mover datos) y el wrapper de `/sbin/init` la extiende en el primer arranque.
627Medido en la caja: **`/store` = 68,7 G**, contra los 487 M de antes. Con eso el store de 55 G entra
628en el disco local y **la mudanza no depende de mover el volumen de gioser**.
629
630### 6.4 ⚠ El muro de la puerta 3: la imagen trae 23 binarios que NO PUEDEN CORRER
631
632Al ir a computar los grafos en la caja:
633
634```
635$ python3 -c "print(1)"
636sh: python3: not found ← y `command -v python3` decía /usr/bin/python3
637```
638
639No es que falte: **está y no arranca**. `/usr/bin/python3.12` son 23 MB y es un ELF **dinámico**:
640
641```
642Requesting program interpreter: /lib/ld-musl-x86_64.so.1
643NEEDED libc.so
644```
645
646**Y en toda la imagen no hay ningún cargador dinámico.** Tampoco en el store: el artefacto `musl`
647publica sólo lo estático (`libc.a`, `crt*.o`, headers) — **no hay `libc.so` ni
648`ld-musl-x86_64.so.1` en ningún artefacto del corpus**. Lo que hace que estos binarios funcionen en
649gioser es el **rootfs Alpine del LAB**, que sí lo trae (`.dev-fs/alpine/lib/ld-musl-x86_64.so.1`).
650
651Es la fuga de [[needed-colgante-libstdcxx]] otra vez, y esta vez en el piso de abajo: *sella,
652reproduce y no corre*, porque pide algo que sólo existe en el laboratorio.
653
654**Contado sobre la imagen: 23 binarios inertes de 726 (703 estáticos están bien).** Son la suite
655`binutils` entera (`ar as ld nm objcopy objdump ranlib readelf strip addr2line c++filt elfedit gprof
656size ld.bfd`), más **`perl`**, **`python3`**, **`sqlite3`**, **`flex`** y **`nft`**.
657
658**Por qué frena la mudanza y no es un detalle**: *todo* el instrumental del proyecto es Python —
659`build-state.py`, `targets.py`, `yupana.py`, `hydrate-profile.py`, `drenar.py`, `triaje.py`. Un
660servidor takana no puede correr ni una de sus propias herramientas. La puerta 3 (los cuatro grafos)
661y la 4 (la granja) dependen de eso.
662
663**Y no se arregla de paso.** Las salidas son tres y ninguna es barata:
664
6651. **Publicar el cargador** — que `musl` emita `libc.so` + `ld-musl-x86_64.so.1`. Es lo correcto y lo
666 más chico en concepto, pero toca un componente de **Stage 1**: mueve el baseline `of_tree` del
667 selfhost y hay que rehacerlo a propósito, no de rebote.
6682. **Construir python/perl estáticos** — el camino que evita el cargador, y es un frente propio:
669 Python estático con módulos de extensión es notoriamente arisco.
6703. **Aceptar que el instrumental vive en el HUB** y que el servidor sólo sirve. Es la respuesta
671 honesta a corto plazo, pero contradice «mover allá todo lo que tengo acá»: el hub seguiría siendo
672 gioser, que es justo lo que se quiere apagar.
673
674Es decisión de ADR, y de las que conviene tomar mirando también el [SDD 27 §4](27-perfiles-instalables-y-el-instalador.md):
675las dos preguntas —«¿el cliente reproduce o hidrata?» y «¿el cliente puede correr lo que le
676mandamos?»— son la misma pregunta sobre qué es un sistema takana **sin laboratorio**.
677
678### 6.5 ✅ El muro, derribado: el corpus publica su propio cargador *(2026-09-11)*
679
680De las tres salidas del §6.4 el usuario eligió la 1 y la 2. Hecha la **1**, que resultó ser más barata
681de lo que parecía y desbloquea la 2 en vez de competir con ella.
682
683**`recipes/musl-shared.toml`** — variante dinámica de musl que publica `/usr/lib/libc.so` (4,2 M) y
684`/lib/ld-musl-x86_64.so.1`. En musl el cargador Y la libc son el mismo objeto.
685
686**Por qué una variante y no `--enable-shared` en la canónica**, con su control: `musl` es componente
687de **Stage 1** y su `of_tree` es el baseline de `selfhost-verify`. Tocarla obliga a rehacer ese
688baseline a propósito. Con el patrón `*-shared` —que el corpus ya usa 23 veces— la canónica no se
689mueve: `takana hash recipes/musl.toml` sigue dando `b3:ce952f72…`, el mismo sellado de Stage 1. Y
690además **`musl` no es dep de nadie** (medido: sólo de sí misma; el enlace estático lo resuelve el
691musl que trae zig), así que esto **suma sin mover un solo ArtifactHash del corpus**.
692
693#### ⚠ Y hubo que cambiar de compilador, medido
694
695Con `zig-cc` el `libc.so` sale con **1586 símbolos dinámicos** contra los **1654** del musl de Alpine,
696y los **68 que faltan son exactamente** los que musl implementa en ensamblador x86_64 — `memset`,
697`memcpy`, `memmove`, `memcmp`, `strlen` y toda la familia matemática (`ceil floor sqrt fmod exp log
698sin cos tan fma round trunc`) — más los `__stack_chk_*`.
699
700No es que no se compilen: en el `libc.a` del musl canónico **están**. Lo que pasa es que **zig los
701resuelve con su propio musl y los deja `FUNC LOCAL HIDDEN` de tamaño 0**, fuera de la tabla dinámica.
702El síntoma es un cargador que arranca, reloca y muere con `memset: symbol not found` — que se lee
703como «el binario está roto», no como «a la libc le faltan símbolos».
704
705Con `compiler = "gcc"`: **1651 símbolos**, `memset` y `ceil` presentes.
706
707#### El resultado, en la caja
708
709| antes | después |
710|---|---|
711| `sh: python3: not found` (con `command -v` contestando `/usr/bin/python3`) | `Python 3.12.10` |
712| 23 binarios inertes de 726 | **1** |
713
714`perl 5.040002`, `readelf`/`objdump`/`nm` (GNU Binutils 2.45.1) y el resto corren. El único que
715quedaba era **`sqlite3`**, con `Error loading shared library libz.so.1`: la zlib canónica también es
716`--disable-shared` y nadie publicaba ese soname. `zlib-shared` ya existía sellado en el corpus —
717sólo faltaba declararla en `base`.
718
719**La salida 2 (python/perl estáticos) sigue viva y ahora es opcional, no urgente**: con el cargador
720publicado el sistema ya no depende del rootfs del lab. Estático seguiría siendo mejor (un binario
721menos que puede quedar colgado de un soname), pero es un frente propio y ya no bloquea la mudanza.
722
723### 6.6 Sembrar el hub: un hub no es repo+store, es repo+store+LAB
724
725Con `python3` vivo, `takana hash` en la caja **seguía fallando**:
726
727```
728Error: no pude leer el apk db del lab en /.dev-fs/alpine/lib/apk/db/installed.
729 El toolchain entra en el ArtifactHash ⇒ sin rootfs no hay hash comparable.
730```
731
732**El lab es parte de la IDENTIDAD, no del entorno.** Una máquina sin él no puede ni preguntar «¿cuál
733es el hash vigente de esta receta?», así que no puede computar el grafo ni decidir qué falta. Sembrado
734el lab (tarball pineado + `tools/`, bajo `/store/dev-fs` porque la raíz son 6 G), el **hash testigo
735coincide byte a byte**: `takana hash recipes/zlib.toml` da `b3:dc363f26…` en las dos máquinas.
736
737⚠ **Y la caja no podía desempacar su propio lab**: el `tar` del rootfs es el de busybox y contesta
738`tar: unrecognized option: zstd`. La distro comprime todo con zstd —la imagen del lab, el respaldo,
739el `dd` remoto— y la imagen no traía el binario. `zstd` ya tenía receta sellada; declarado en `base`.
740
741#### ⚠⚠ Copiar un store con `rsync -a` es una fábrica de vacíos, y ahora se sabe POR QUÉ
742
743La primera copia murió con `No space left on device` en un `.so` de Qt, dejando el destino al 100 %
744y **1367 de 1368 artefactos VACÍOS**. La puerta 2 corrida EN EL DESTINO lo cazó en el acto.
745
746La causa, medida:
747
748| medición sobre el store de gioser | |
749|---|---:|
750| `du -sh` (hardlinks contados UNA vez) | **60 G** |
751| `du -sh --count-links` (hardlinks EXPANDIDOS) | **85 G** |
752| `.dmerge` (la caché que hardlinkea al store) | **11 G** |
753
754**`rsync` sin `-H` no preserva hardlinks: los expande en copias enteras.** Así que «el store son 60 G»
755—que es lo que dice `du` y lo que uno planifica— se convierte en 85 G + lo que `.dmerge` expanda al
756otro lado. La partición de 68,7 G no tenía ninguna chance, y el modo de fallar es el peor: el disco se
757llena a mitad y quedan cientos de nombres de artefacto sin contenido, que el store da por presentes.
758
759La copia correcta es **`rsync -aH --exclude='.dmerge'`**: `-H` preserva los enlaces (60 G reales) y
760`.dmerge` no se copia porque es caché regenerable — la misma que ya llenó un disco en el worker.
761
762**La lección de método**: `du -sh` sobre un árbol con hardlinks **no** dice cuánto ocupa copiarlo.
763Para dimensionar una copia hay que medir con `--count-links`, o preservar los enlaces.
764
765#### Y el instrumental apunta al binario de DESARROLLO, no al instalado
766
767La primera corrida de `build-state.py` en la caja devolvió **875 recetas `unhashable`** — todas —
768con el lab bien sembrado y `takana hash` funcionando a mano. La causa:
769
770```python
771HAMMER = os.environ.get("HAMMER", str(ROOT / "target/release/takana"))
772```
773
774Los scripts asumen un **árbol de desarrollo**: `target/release/takana`. En una caja **instalada** el
775binario es `/usr/bin/takana` y `target/` ni existe (la siembra lo excluye a propósito). No falla
776ruidosamente: cada `hash` falla y el grafo sale entero como `unhashable`, que se lee como «este
777corpus no se puede hashear» y no como «no encontré el binario».
778
779Se destraba con `HAMMER=/usr/bin/takana STORE=/store`, que la propia cabecera del script documenta.
780Pero la deuda queda anotada: **el instrumental debería caer a `command -v takana`** antes de rendirse,
781porque el caso «hub instalado» es justamente el que esta mudanza quiere que exista.
782
783### 6.7 ✅ PUERTA 3 EN VERDE: los dos grafos, idénticos byte a byte
784
785```
786gioser: 7435d33d62577e8ce154e8c5e354e0465139cfbc632afe710076ea2223cea605
787caja: 7435d33d62577e8ce154e8c5e354e0465139cfbc632afe710076ea2223cea605
788```
789
790`base 61/61 · cli 84/84 · escritorio-mirada 41/41 · servidor 96/96 · falta 0`, `wanted 3`
791(`chrony`, `cronie`, `logrotate` — la deuda declarada), grafo CIERRA, topo-sort OK. Las dos máquinas.
792
793**Costó tres intentos, y los dos fallos son la parte que vale.**
794
795**Intento 1 — `unhashable 875`**, todas. Ver arriba: los scripts apuntan a `target/release/takana`.
796
797**Intento 2 — dos nodos divergentes**: `aichat` y `zola`, `sealed` en gioser y `never` en la caja. No
798era deriva ni pérdida: **ninguno de los dos está en disco en gioser tampoco**. Son los «2 sellados
799que no están en esta máquina, avalados por los manifiestos» que el propio resumen imprime.
800`build-state.py` lee `work/farm-sellados.txt` y `work/respaldo-sellados.txt` — y **`work/` está
801gitignored**, así que un hub recién sembrado no los tiene y degrada esos nodos a `never` sin que nada
802falle.
803
804Es la misma familia que `scripts/farm/.fleet`: **un fichero fuera de git del que depende una medición
805compartida**. La regla que sale: *sembrar un hub no es clonar el repo — es repo + store + lab +
806los manifiestos*. Copiados los dos ficheros, los grafos coinciden exactamente.
807
808### 6.8 Puerta 4: el camino de la granja, PROBADO; la cosecha completa, sin disco
809
810**Probado desde la caja** (sin tocar el latido de gioser, todo de sólo lectura salvo el último paso):
811
812- llevada la clave de la granja (`~/.ssh/github5` → `/root/.ssh/github5`, 0600) y escrito
813 `scripts/farm/.fleet` — los dos están fuera de git a propósito y hay que copiarlos a mano;
814- la caja **alcanza al worker**: `PruebasIA`, load 3, 775 artefactos;
815- `estado-granja.sh` corre allá y lee bien el worker y el avance KDE (198/199);
816- y el paso que cierra el lazo: se **cosechó un artefacto real del worker** (`speedtest-go`, 12 M)
817 con el mismo transporte de la granja, llegó **con su `.hammer/recipe.toml`** y **su binario CORRE
818 en la caja** (`speedtest-go v1.7.10`). Worker construye → hub cosecha → binario ejecuta.
819
820#### ✅ CERRADA (2026-09-11) con el volumen `takana-store`
821
822Resuelto el disco (§6.12), la cosecha completa corrió: **1369 → 1575 artefactos, 0 vacíos**, que son
823exactamente los 206 que faltaban. 12,4 G por la red para 39 G lógicos —`speedup 3.14`, el ahorro de
824`-H`— y `/store` queda en 73,7 G de 97,9 (79 %).
825
826⚠ El enlace con el worker va a **11 MB/s**, no a los 90 MB/s de gioser↔caja: el LXC vive en el
827Proxmox de gioser, fuera de la red de Hetzner. Media hora para una cosecha de este tamaño.
828
829⚠ **Lo que faltaba no era mecanismo: era DISCO.**
830
831| | |
832|---|---:|
833| artefactos en el worker que la caja no tiene | **206** |
834| a ~113 MB de media (el artefacto medio del corpus) | **~23 G** |
835| libre en `/store` de la caja | **3,7 G** (61,5 de 68,7 · 94 %) |
836
837Una cosecha completa **no entra**, y forzarla repetiría exactamente el llenado que dejó 1367
838artefactos vacíos hace un rato. La puerta 4 queda pendiente de una decisión de CAPACIDAD, no de una
839de ingeniería:
840
8411. **Enganchar `harkaq-cosecha` (250 G) a la caja.** Es el plan original y no cuesta nada extra —
842 pero hay que DESENGANCHARLO de gioser, y ahí vive el store, `work/sources`, los tarballs y el
843 `CARGO_HOME` de la granja. O sea: **es el cutover**. gioser deja de construir en ese mismo
844 instante, y hoy está moliendo el árbol KDE.
8452. **Un volumen nuevo para la caja** (€0,052/GB/mes: 100 G ≈ €5,2/mes). No interrumpe nada y
846 destraba la cosecha ya; se paga por duplicado hasta que gioser muera, y entonces se suelta.
8473. **Podar el store de la caja** — deshace parte de la mudanza. No.
848
849### 6.9 Puerta 8: los 19 dominios, sondeados uno por uno *(2026-09-11)*
850
851El Caddyfile de gioser declara 19 sitios. Sondeados por DNS **y** por HTTP desde fuera, sólo **6**
852los sirve gioser de verdad:
853
854| dominio | DNS | HTTP | qué es |
855|---|---|---|---|
856| `gioser.net` · `tawasuyu.net` | gioser | **200** | **VIVO** — las dos landings |
857| `git.gioser.net` · `git.tawasuyu.net` | gioser | **200** | **VIVO** — el gitea (aloja el `origin` de takana) |
858| `sergio.gioser.net` · `api.sergio.gioser.net` | gioser | **200** | **VIVO** |
859| `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 |
860| `api.gioser.net` | gioser | **502** | backend caído |
861| `mail.sigma.gioser.net` | gioser | **502** | backend caído |
862| `aura` · `api.aura` · `sigma` · `kosmofono` · `api.kosmofono` | **SIN DNS** | — | fósil: ni DNS ni ficheros en `/var/www` |
863| `terapeuta.ec` · `andino.ec` | **SIN DNS** | — | fósil con datos: 279 M en `/var/www/terapeuta` |
864| `gitea.gioser.net` | **SIN DNS** | — | era un `redir` a `git.gioser.net`; inofensivo |
865
866**Lo que esto cambia respecto del §1.1**: no son «4 fósiles» sino **13 de 19 entradas que no hay que
867mudar** — 8 sin DNS, 2 con el backend caído y 3 que ya viven en otra máquina. La superficie real a
868mudar son **6 sitios**, y de esos el que pesa es el **gitea**, porque aloja el `origin` de takana.
869
870#### ✅ DECIDIDO (usuario, 2026-09-11)
871
872| fósil | decisión |
873|---|---|
874| `aura` · `api.aura` · `sigma` · `kosmofono` · `api.kosmofono` | **mueren** — ni DNS ni ficheros |
875| `gitea.gioser.net` | **muere** — era un `redir`, y `git.gioser.net` lo cubre |
876| `api.gioser.net` · `mail.sigma.gioser.net` | **mueren** — backend caído, sin dueño |
877| `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 |
878| **`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** |
879
880⇒ De las 19 entradas del Caddyfile, **13 no se mudan**. La superficie real es de **6 sitios**, y el
881que pesa es el gitea porque aloja el `origin` de takana.
882
883⚠ Que esto quede escrito ES la puerta: el día que se borre gioser, `terapeuta.ec` no va a poder
884recuperarse, y la diferencia entre «lo decidimos» y «se nos pasó» es este párrafo.
885
886### 6.10 Puerta 7: el respaldo desde la caja — y tres bloqueos que sólo se ven corriéndolo
887
888Llevadas las credenciales (`~/.config/hammer/*.env`, 0600) y la clave, **la caja alcanza el Storage
889Box** por el puerto 23 y lista su contenido. El manifiesto se refresca desde allá:
890**3140 artefactos**, y de paso el script detecta **2 VACÍOS en el respaldo** (`gnome-desktop` ×2) que
891excluye del manifiesto — su propia guarda, funcionando.
892
893Para llegar ahí hubo que arreglar **cinco** cosas, y todas son de la misma familia: *el instrumental
894asume que el hub es gioser*. El `--seco` ahora completa los tres pasos desde la caja y lee la
895ocupación del box (111 G de 1 T).
896
8971. **La raíz cableada.** `RAIZ="${RAIZ:-/mnt/vvv/takana}"` ⇒ desde cualquier otra máquina el script
898 moría con `cd: /mnt/vvv/takana: No such file or directory`. Ahora se deriva de dónde está el
899 script, como el resto de `scripts/`.
9002. **El binario de desarrollo.** `HAMMER = ROOT/target/release/takana` (§6.7).
9013. **El store no estaba donde el script creía.** Usaba `$RAIZ/store` cableado: en gioser es un
902 bind-mount DENTRO del repo, pero en una caja instalada es una partición en `/store` ⇒
903 `change_dir "/opt/takana/store" failed`. Y rsync devuelve **23**, que está en la lista de
904 reintentables, así que el bucle insistía — el cuadro que la propia cabecera del script documenta
905 («un error reintentable que se repite 40 veces no es un corte de red: es algo estructural»).
906 Ahora `STORE` es env, con una guarda que aborta ANTES del bucle si la ruta no existe.
9074. **🚨 Y una que habría costado el historial.** El paso [2/3] sube el repo **con `--delete`** —
908 correcto, para eso está git. Pero el `/opt/takana` de la caja llegó por `rsync --exclude=.git`:
909 es una COPIA, no un clon. **Una corrida real desde ahí habría borrado `.git` del Storage Box**, o
910 sea el historial entero, y en silencio: rsync haría exactamente lo que se le pidió. Añadida una
911 guarda que aborta si la raíz no tiene `.git` (escotilla `REPO_INCOMPLETO=1`), probada en los tres
912 sentidos.
913
914 **La regla que sale**: un `--delete` convierte «respaldar» en «sincronizar», y sincronizar desde
915 un origen incompleto no sube menos — BORRA. Cualquier respaldo con `--delete` necesita una guarda
916 de completitud del ORIGEN, no sólo del destino.
9175. **El rsync del corpus no puede correr el respaldo del corpus.** El script exige
918 `--compress-choice=zstd` y `recipes/rsync.toml` lo construía con `--disable-zstd` — porque cuando
919 se escribió, `zstd` no estaba en el catálogo. Hoy sí. Peor aún: el error 4 que devuelve rsync el
920 script lo clasifica como «no de red» y **no reintenta**, así que el respaldo simplemente no se
921 hacía. Arreglado por los dos lados: la receta enciende zstd (control: `zstd zlibx zlib none` vs
922 `zlibx zlib none`; radio cero, `rsync` no es dep de nadie) y **el script degrada a zlib avisando**
923 en vez de morir.
924
925### 6.11 ⚠ La distro traía un `git` que NO PODÍA CLONAR
926
927Para cerrar la puerta 7 la caja necesita un **clon de verdad** (el `--delete` del respaldo exige un
928origen completo, §6.10). Llevada la clave del gitea —que es `~/.ssh/tawasuyu`, **no** la de la
929granja— `git ls-remote` contesta… y `git clone` muere:
930
931```
932fatal: fetch-pack: invalid index-pack output
933```
934
935El informe completo, que la traza corta escondía:
936
937```
938panic: load of misaligned address 0x… for type 'const uint32_t',
939 which requires 4 byte alignment
940 in sha1_compression_states → sha1_process → SHA1DCUpdate → git_SHA1DCUpdate
941 → git_hash_update → unpack_entry_data → cmd_index_pack
942```
943
944**Dos causas, encadenadas:**
945
9461. **`-fsanitize=undefined` estaba en `CFLAGS`**, no sólo en `LDFLAGS`. El motivo original era
947 legítimo —las `libz.a` materializadas traen referencias `__ubsan_handle_*` que bajo `-static` no
948 se resuelven solas, y el flag *al enlazar* trae el runtime de zig— pero en `CFLAGS` **instrumenta
949 el código de git**. Un arreglo de ENLACE convertido en una mina de RUNTIME, justo en la ruta de
950 hash: por donde pasa todo lo que git recibe.
9512. **`sha1collisiondetection` lee palabras de 32 bits SIN alinear.** Es el backend SHA1 por defecto
952 de git, el que detecta SHAttered. En x86 la lectura desalineada funciona y por eso nadie lo nota
953 jamás; según el estándar es UB, y basta con que el runtime ubsan esté enlazado para que aborte.
954 `-DSHA1DC_FORCE_ALIGNED_ACCESS` lo hace leer byte a byte: quita el UB **en la fuente** en vez de
955 esconderlo.
956
957Con las dos: `git clone --depth 1` del propio repo desde la caja ⇒ **877 recetas**. Radio cero
958(`git` no es dep de nadie), pero **sí es raíz de `perfil.base`** ⇒ esto arregla la distro entera.
959
960**La lección**: `ls-remote` andaba, así que el fallo parecía de red. Lo que lo destapó fue leer el
961informe COMPLETO en vez de la última línea — la primera decía exactamente qué y dónde.
962
963### 6.12 ⚠ La caja dejó de ser desechable — y `hydrate` no cruza el store
964
965Dos consecuencias de que la caja ya sea un hub, y las dos cambian el procedimiento:
966
967**1. Re-escribir la imagen con `dd` ya NO es una actualización, es una pérdida.** El `dd` sobrescribe
968el disco local, y ahí viven ahora `/opt/takana` (el clon), `/root/.ssh` (las dos claves),
969`/root/.config/hammer` (las credenciales del respaldo), `/srv/repo` y la configuración de caddy. El
970store se salva sólo porque está en el volumen. **Y hay una trampa peor**: la imagen etiqueta su
971partición local como `hammer-store`, así que tras un `dd` habría **dos filesystems con esa etiqueta**
972y el `findfs` del arranque elegiría cualquiera — con suerte el volumen, con mala suerte una partición
973vacía. ⇒ el `dd` es para PROVISIONAR; actualizar es `takana upgrade` (que existe, con generaciones y
974rollback) y está sin probar en esta caja.
975
976**2. `takana hydrate` no puede proyectar al root vivo.** Hidratar enlaza en DURO, y en una caja
977instalada el store es **siempre** otra partición que `/`:
978
979```
980Error: store: hardlink /store/51aa5e13…-git/.hammer/recipe.toml → /.hammer/…: Cross-device link
981```
982
983No es culpa del volumen: en el layout original `/store` es `sda4` y `/` es `sda2`, también distintos.
984**Hidratar al FHS vivo nunca fue posible en una caja instalada** — funciona en el hub porque ahí
985store y destino están en el mismo filesystem. Es la misma familia de EXDEV que ya mordió dos veces
986(§6.6), ahora a nivel de sistema y no de herramienta.
987
988Para instalar el `git` arreglado se copió el artefacto a mano. Eso **funciona y no es el camino**: el
989camino es `takana upgrade`, y probarlo es su propia unidad de trabajo.
990
991### 6.13 ✅ `takana upgrade`, probado de verdad — y el bug de durabilidad que destapó
992
993§6.12 dejó dicho que el camino de actualización de una caja instalada es `takana upgrade`, no `dd` ni
994`hydrate`. Probado con un paquete que la caja **realmente necesitaba**: `zstd`.
995
996| paso | resultado |
997|---|---|
998| `upgrade apply …-zstd-cli` | `✓ generación 2 aplicada · + 1 añadidos, ~ 1 pisados, - 8 retirados` |
999| la prueba de uso | `zstd -dc lab-image.tar.zst \| tar -xf -` ⇒ **la caja desempaca su propio lab** |
1000| `upgrade rollback` | `✓ generación 2 revertida · 9 restaurados, 1 borrados` — `zstd` se va, `libzstd.a` vuelve |
1001| re-`apply` + **corte duro sin `sync`** | sobrevive: generación viva 1, manifiesto íntegro |
1002
1003✔ **Y cruza la frontera que `hydrate` no puede**: el store está en el volumen y `/` en el disco local,
1004y `upgrade` copia en vez de enlazar. Es, de hecho, el único camino que funciona en una caja instalada.
1005
1006#### ⚠ El bug: `write_atomic` era atómico pero NO DURABLE
1007
1008El primer intento pareció funcionar y **se perdió al reiniciar**. La caja volvió con:
1009
1010```
1011pending.json 0 bytes
1012generations/2/manifest.json 0 bytes
1013upgrade status → Error: json: EOF while parsing a value
1014upgrade recover → Error: json: EOF while parsing a value
1015```
1016
1017`write_atomic` hacía temporal + `rename`: atómico frente a otros PROCESOS, no frente a un CORTE.
1018`rename` sobre un fichero cuyos datos siguen en caché deja, tras el corte, la entrada apuntando a
1019bloques nunca escritos — cero bytes. Y `hcloud server reset` **es un corte duro**, no un apagado
1020limpio: ahí está la mitad operativa de la lección.
1021
1022Lo grave no es perder un upgrade: es que **`recover` —que existe exactamente para «un apply
1023interrumpido por un corte»— abortaba con la huella más probable de ese corte**.
1024
1025Arreglado: `fsync` del temporal antes del `rename` y `fsync` del directorio después (hacen falta los
1026dos), y un `pending.json` vacío se reporta como `PendingCorrupt`, nombrando el corte y apuntando al
1027árbol de respaldos. Con tests y su control.
1028
1029**Verificado en la máquina, en los dos sentidos**: con el binario viejo, apply + reset duro ⇒ estado
1030en 0 bytes; con el nuevo, la misma secuencia ⇒ estado íntegro y el paquete en su sitio.
1031
1032#### ⚠⚠ `upgrade apply` NO es un gestor de paquetes: cada generación ES UN ÁRBOL
1033
1034Lo destapó usarlo dos veces seguidas. Tras aplicar `zstd-cli` y después `rsync`:
1035
1036```
1037✓ generación 2 aplicada
1038 + 0 añadidos, ~ 8 pisados, - 1 retirados ← el `zstd` de la generación 1
1039$ zstd --version
1040AUSENTE
1041```
1042
1043**Aplicar un árbol nuevo RETIRA los ficheros del anterior**, porque una generación es el estado
1044completo, no un incremento. Es coherente con lo que la ayuda dice —«aplica un árbol Stage1/**producto**
1045del store»— y con que exista `rollback`: lo que se revierte es un sistema, no un paquete.
1046
1047⇒ Usarlo para instalar paquetes sueltos, como hice acá, funciona una vez y se deshace a la siguiente.
1048**La forma correcta de poner una caja al día es componer el árbol del perfil —lo que ya hace
1049`servidor-image.sh`— sellarlo, y aplicar ESO como una generación.** Eso además sería, de verdad, la
1050«actualización en sitio probada» del [SDD 19 §5.2](19-lanzamiento-publico.md): una imagen entera, con
1051rollback, sobre una caja viva.
1052
1053Mientras tanto la caja quedó con `zstd` y `rsync` puestos a mano — funciona y **no es el camino**,
1054igual que el `git`.
1055
1056⚠ Lo que NO se arregló: si el manifiesto se pierde, `recover` no puede deshacer solo — no sabe qué se
1057tocó. El árbol de respaldos tiene la información; reconstruir desde ahí es su propia unidad.
1058
1059### 6.2 Lo que la mudanza tiene que producir, además de la mudanza
1060
1061El usuario lo pidió explícito: **que este experimento saque recetas y las pruebe**. La caja vieja es
1062un catálogo de software real en producción, y cada servicio que hoy corre sobre binarios de Artix es
1063una receta candidata con un caso de uso comprobado detrás:
1064
1065| lo que corre hoy en Artix | receta |
1066|---|---|
1067| `caddy` | ✅ existe (`recipes/caddy.toml`) |
1068| `openssh` | ✅ existe |
1069| `gitea` | ✅ **SÍ existe** (`recipes/gitea.toml`) **y está sellada** (`35bb4f04…`) — ver la corrección abajo |
1070| `qdrant`, `squid`, `fail2ban`, `php-fpm`, `metalog`, `glances` | ✗ |
1071| `chrony`, `nftables`, `cronie`, `logrotate` | ✗ — ya declaradas `wanted` en `perfil.servidor` |
1072
1073> **CORRECCIÓN (2026-09-11).** Esta tabla decía que `gitea` NO tenía receta y que «es la que más
1074> peso tiene». **Las dos cosas eran falsas**: `recipes/gitea.toml` existe desde el 2026-09-09 y su
1075> artefacto está sellado. Lo escribí de memoria, sin mirar el catálogo.
1076>
1077> Lo destapó `planear.py` al cruzar cada binario contra `recipes/`: de los servicios de gioser, **4
1078> ya tienen receta takana y están sellados** (`caddy`, `gitea`, `python3`…), 4 vienen de un paquete
1079> ajeno y **11 son binarios sueltos sin dueño**. Ésos últimos son el trabajo real, no gitea.
1080>
1081> Es exactamente para esto que la herramienta existe: yo afirmé de memoria y el programa fue a mirar.
1082
1083**Cada una que se cierre se prueba sola**: el servicio o levanta en la caja nueva o no, y eso se ve
1084el mismo día. Es la diferencia entre una receta «sellada» y una receta *usada*.
1085
1086---
1087
1088### 6.11 🗄️ La imagen del perfil, con gitea, ARRANCA y SIRVE *(2026-09-14)*
1089
1090`servidor-image.sh` + QEMU: **PID 1 = `arje-zero`, gitea encarnado por él (`ppid=1`), corriendo como
1091`uid=916`, escuchando en :3000 y devolviendo `200` con `<title>takana git</title>`**, con su
1092`gitea.db` creada por él mismo. Es el primer servicio de PAQUETE que arranca en una imagen de takana:
1093los que había venían horneados en el bootstrap.
1094
1095La cadena entera, eslabón por eslabón: `[[user]]` → `/etc/passwd` de la imagen · `[[service]]` →
1096`takana service-cards` → `genesis` de la seed → arje lo encarna → `setuidgid` → sirve.
1097
1098#### Los tres fallos que sólo aparecieron AL PROBAR LA IMAGEN
1099
1100Los tres pasan el sellado, el `hash`, el resolutor de servicios y el armado. Ninguno se ve sin
1101arrancar la imagen.
1102
11031. **⚠⚠ Escribir en el rootfs hidratado es escribir DENTRO del store.** `takana users --merge` hacía
1104 `fs::write` sobre `<rootfs>/etc/passwd`, y ese fichero y el del artefacto `product-rootfs` son
1105 **el mismo inode** (medido: 1225824, `2 links`, modo `444`) — el rootfs se arma con hardlinks.
1106 Habría mutado un artefacto sellado, y toda imagen futura habría salido con la cuenta metida dentro
1107 del producto. Se salvó porque el store es de sólo lectura y salió `Permission denied`: confiar en
1108 eso es confiar en un permiso. Ahora escribe por temporal + `rename`, con un control que comprueba
1109 que el fichero del store conserva su contenido y baja a 1 link.
1110
11112. **La imagen traía el binario, la cuenta… y nadie lo arrancaba.** El `genesis` sólo tenía lo que
1112 hornea `takana-bootstrap` (`sshd`, `console-getty`, `hammerd`): `servidor-image.sh` **no inyectaba
1113 las Cards** — eso sólo existía en el camino de las imágenes de escritorio. Y ninguna métrica lo
1114 dice: `targets.py --services` responde que el perfil lo habilita, y lo habilita; lo que faltaba era
1115 el paso que lleva esa declaración a la imagen.
1116
11173. **⚡ `trap invalid opcode`: el binario sólo corría en la CPU que lo compiló.** Con la card ya en el
1118 genesis, gitea moría al instante dentro de QEMU-TCG. El sandbox exporta `CC` apuntando a un wrapper
1119 con `-mcpu=baseline` (y su comentario ya avisaba: «de paso cierra el SIGILL de AVX en qemu64»), y
1120 **la fase Go del propio builder lo pisaba** con `CC="zig cc"` a secas, que es `-mcpu=native`. No
1121 falla al compilar ni al sellar: falla al ejecutar en otra CPU. Y el `ArtifactHash` no puede
1122 cazarlo, porque la CPU del builder no entra en `hash_inputs` — **dos workers distintos sellan bytes
1123 distintos bajo la misma dirección**. Arreglado en el builder y en la receta; re-hashea las cinco
1124 recetas `cgo = true` (`gitea`, `usql`, `sq`, `gocryptfs`, `naabu`).
1125
1126#### Lo que NO está probado, y falta para la mudanza
1127
1128El `app.ini`, el usuario del sitio y los datos se pusieron **a mano** dentro de la VM para llegar al
1129200. Eso es exactamente lo que el plan de mudanza tiene que traer de gioser — `/etc/gitea` ya está en
1130`scripts/mudanza/rutas-fuera-de-git.txt`.
1131
1132Y **la imagen no trae `arjectl`**: tras poner la config hubo que REINICIAR para que arje volviera a
1133intentarlo. El backoff de `restart` se agota y no hay forma de pedirle a PID 1 que relance un ente en
1134caliente. Para una caja de producción eso es una pieza que falta, no una comodidad.
1135
1136### 6.12 🎛️ `arjectl` en la imagen: control en caliente *(2026-09-14)*
1137
1138El §6.11 cerró con «la imagen no trae `arjectl`, hubo que reiniciar la máquina para arrancar un
1139servicio». Ya lo trae, y **no hubo que escribir nada**: el cliente existía en tawasuyu y se llama
1140**`arje-ctl`** (el crate; el binario es `arjectl`). Buscarlo por `arjectl` no lo encontraba, y de ahí
1141salió la conclusión falsa de que faltaba implementarlo — el protocolo (`arje-bus::BusRequest`) ya
1142traía `ListEntes`, `SpawnCardFromDisk`, `StopCardFromDisk`, `KillEnte` y `EnteStatus`.
1143
1144`recipes/arjectl.toml` lo construye **del mismo commit que `arje-zero`** (`98db584f`), y eso no es
1145comodidad: el bus es un protocolo entre dos binarios, y un cliente de otro árbol puede conectar y no
1146entenderse con el init. Publica **sólo `arjectl`**; el crate también produce un `systemctl` de
1147camuflaje que acá no se instala — un `systemctl` en el PATH de una distro sin systemd invita a
1148escribir runbooks con el verbo ajeno.
1149
1150#### El hueco que sólo se ve usándolo: el genesis no alcanza
1151
1152Con `arjectl` en la imagen, el primer intento falló con un mensaje que nombra la causa:
1153
1154 $ arjectl start gitea
1155 Error: arje-zero rechazó: card gitea: No such file or directory
1156 (buscada en /etc/arje/cards.d/gitea.json)
1157
1158`start`/`restart` usan `SpawnCardFromDisk`, que lee **`/etc/arje/cards.d/<label>.json`** — y el
1159armado sólo escribía el `genesis` de la seed. Son dos preguntas distintas: *qué arranca solo* y *qué
1160se puede encarnar a pedido*. Con sólo la primera, un servicio que agota su backoff **no se puede
1161relanzar sin reiniciar la máquina**. `inyectar-cards.py` escribe ahora los dos árboles (y en
1162`cards.d` escribe TODAS, no sólo las nuevas: `sshd` viene del product-rootfs y tampoco era
1163relanzable).
1164
1165#### Medido, con la VM arrancada UNA sola vez
1166
1167| | |
1168|---|---|
1169| la imagen trae | `/etc/arje/cards.d/{gitea,sshd}.json` |
1170| `arjectl list-units` | tabla con PID, CPU%, MEM, HILOS y reinicios de cada Ente |
1171| poner `/etc/gitea/app.ini` + `arjectl start gitea` | **`GET /` → 200**, sin reiniciar (`uptime` 6 min) |
1172| `arjectl restart gitea` | el PID cambia (118 → 192) y sigue sirviendo 200 |
1173
1174#### ⚠ `arjectl start` sobre un Ente YA VIVO lo DUPLICA
1175
1176`SpawnCardFromDisk` no deduplica por label: encarna otra instancia y arje le da un ULID nuevo. En
1177`gitea` el síntoma fue `unable to lock level db … resource temporarily unavailable` seguido de `[F]`
1178— dos servidores peleando por el mismo estado, con el HTTP intermitente mientras duraba. **Para
1179relanzar se usa `restart`**, o se mira `list-units` antes. Un `start` idempotente es trabajo de arje,
1180no de esta imagen; queda anotado río arriba.
1181
1182### 6.13 🧪 Ensayo con los DATOS REALES de gioser — el gitea de la caja vieja corriendo en takana
1183
1184Sin tocar gioser (todo lectura) y en la VM desechable. Es el ensayo que faltaba antes de cualquier
1185cutover, y trajo cuatro cosas que no se ven en el papel.
1186
1187**El snapshot de la DB se saca en caliente y sale consistente.** `sqlite3 gitea.db ".backup …"` con
1188el servidor VIVO: **1,5 s para 314 M**, `pragma integrity_check` → `ok`, 44 filas en `repository`.
1189Copiar el fichero a pelo con el servidor escribiendo es lo que NO hay que hacer; la API de backup de
1190sqlite existe justo para esto.
1191
1192**Resultado, medido dentro de la VM:** `<title>GioSer Gitea: Git with a cup of tea</title>`, 200, y
1193`/explore/repos` listando los repos de verdad (`sergio/takana`, `tawasuyu/agora`, `card`, `chasqui`,
1194`cosmos`, `khipu`, `llimphi`…). Y el clon de uno de los repos copiados: **478 commits**, HEAD
1195correcto, ficheros reales.
1196
1197#### Los tres detalles que sólo aparecen con los datos puestos
1198
11991. **El uid del origen no es el del destino.** Los ficheros llegan con su uid NUMÉRICO (`1001` en el
1200 rsync de prueba; el gitea de gioser es **969**) y el `[[user]]` declaraba 916. O se chownean 2 G
1201 —lento, y hay que acordarse— o gitea no puede leer sus datos, **y eso no falla al copiar: falla
1202 al arrancar**. La receta pasa a declarar **969**, alineado con el origen.
12032. **El `app.ini` de gioser escucha en `127.0.0.1:3002`**, porque allá caddy hace de proxy. Copiado
1204 tal cual, la caja sirve — pero sólo desde dentro. El `HTTP_ADDR`/`HTTP_PORT` y el `ROOT_URL` son
1205 parte de la adaptación, no del copiado.
12063. 🧨 **El `git` de la distro NO puede clonar por HTTP.** `git clone http://…` dentro de la imagen:
1207
1208 git: 'remote-http' is not a git command. See 'git --help'.
1209 fatal: remote helper 'http' aborted session
1210
1211 Medido sobre el ARTEFACTO sellado: `/usr/libexec/git-core/` trae `git-remote-ext`, `git-remote-fd`
1212 y `git-http-backend` (el lado SERVIDOR), y **no** `git-remote-http`/`-https`; `strings` del binario
1213 da **0** referencias a libcurl, pese a que `curl` está en `[deps] build`. Nadie lo había notado
1214 porque en el hub el `git` que se usa es el de Artix, no el sellado. Es
1215 [[subcomando-sin-driver]] otra vez: instalado, con contenido, reproducible… y sin el camino que
1216 hace falta. **Un hub nuevo no podría clonar el repo por HTTPS.** Arreglarlo re-sella `git`, que es
1217 raíz de `perfil.base` ⇒ unidad propia, no de paso.
1218
1219### 6.14 ✅ CUTOVER DEL GITEA — sirve desde la caja, con TLS y por SSH *(2026-09-14)*
1220
1221**Hecho y verificado desde fuera:** `git.gioser.net` y `git.tawasuyu.net` responden **200 con TLS
1222válido desde `2.29.29.217`**, `git clone` funciona **por HTTPS y por SSH:2345**, y `gitea` y `caddy`
1223corren supervisados por `arje-zero` en la caja. El gitea de gioser está **parado**.
1224
1225**Mudanza incremental, no big-bang.** Los DNS de gioser son casi todos `CNAME → www`, así que mover
1226`www` habría mudado quince dominios cuyos backends siguen allá: 502 en todos. Se convirtió sólo
1227`git` (en las dos zonas) de CNAME a **A propio con TTL 60**, que es reversible en un minuto.
1228
1229#### La secuencia que funcionó, en orden
1230
12311. Caja actualizada: `arjectl` + `gitea` + la cuenta `gitea:969` + las cards en `genesis` y `cards.d`.
12322. Datos en dos fases: **1,66 GB / 18 047 ficheros** con el origen VIVO (17 s), y en el corte el
1233 `rsync --delete` incremental + `sqlite3 ".backup"` (`integrity_check ok`).
12343. **Parar el origen de verdad.** `rc-service gitea stop` dice *«already stopped»* con el proceso
1235 vivo (el `rc-status` que miente, §Los tres hechos), y matarlo **no alcanza**: lo revive
1236 `arje-zero`, que lo tiene como card `openrc-gitea` con `Restart` — **9001 reinicios** acumulados
1237 en el contador. Se paró con **`arjectl stop openrc-gitea`**, y para eso hubo que extraer su card
1238 del `genesis` y escribirla en `/etc/arje/cards.d/` (§6.12: `SpawnCardFromDisk`/`StopCardFromDisk`
1239 leen de ahí, no del genesis).
12404. DNS por la **API de Hetzner Cloud** (`/v1/zones`): el token de `hcloud` **también gestiona el
1241 DNS** desde la unificación — la API vieja `dns.hetzner.com/api/v1` redirige a la consola. Y un
1242 `PUT` sobre el rrset **no puede cambiar el tipo**: hay que `DELETE` del CNAME y `POST` del A.
12435. TLS: el primer intento de ACME **falló contra gioser** (`502`) porque el challenge salió antes de
1244 que propagara; con el DNS ya al día, `arjectl restart caddy` y *certificate obtained successfully*.
1245
1246#### La identidad SSH se muda con el servicio
1247
1248`git clone ssh://…:2345` daba **`REMOTE HOST IDENTIFICATION HAS CHANGED`**: es otra máquina. Se
1249copiaron las **claves de host** de gioser (`/etc/ssh/ssh_host_*`) a la caja ⇒ los clones existentes
1250no notan nada. El precio es que cambia también la identidad del `:22` de administración, y hay que
1251limpiar el `known_hosts` propio — a los clientes del servicio no les afecta, que es lo que importa.
1252
1253Y el `sshd` del producto escucha sólo en `:22`: el git por SSH necesitó `Port 2345` y que el usuario
1254`gitea` tenga **shell real** (su `authorized_keys` fuerza `command="gitea serv …"`, y con
1255`/bin/false` no se ejecuta nada).
1256
1257#### Lo que esto cambia para la granja
1258
1259Las 23 recetas que ahora clonan por `https://git.tawasuyu.net/…` **apuntan a la caja**. Comprobado
1260tras el cambio: el worker resuelve `2.29.29.217` y `git ls-remote` responde. La granja depende ya
1261del servidor nuevo, que es el sentido de la mudanza.
1262
1263#### Cómo se revierte, si hiciera falta
1264
1265`arjectl start openrc-gitea` en gioser y devolver los dos `git` a `CNAME → www`. Con TTL 60, minutos.
1266
1267### 6.15 Cerrar el intermedio: el viejo apagado de verdad, el `:22` cerrado y los datos respaldados
1268
1269#### ⚠ El gitea viejo había VUELTO a arrancar — y lo arrancó OTRO supervisor
1270
1271Media hora después del corte, gioser volvía a servir en `:3002`. `arjectl list-units` **ya no lo
1272mostraba** (el `stop` de arje seguía en pie) y el proceso tenía **`ppid ≠ 1`**: lo había levantado
1273**OpenRC**, que lo tenía en el runlevel `default`. O sea **dos supervisores para el mismo servicio**
1274—la card `openrc-gitea` de arje y el runlevel de OpenRC— y parar uno no para el otro.
1275
1276 rc-update del gitea default # que no vuelva
1277 rc-service gitea stop # ahora sí: OpenRC lo arrancó, OpenRC sabe pararlo
1278
1279Antes del corte pasaba lo contrario (`rc-service … stop` decía *«already stopped»* con el proceso
1280vivo, porque quien lo tenía era arje). **La pregunta no es «¿está parado?» sino «¿quién lo tiene?»**,
1281y hay que responderla dos veces.
1282
1283#### El origen deja de servir git, y se comprueba que no se rompió lo demás
1284
1285Los tres bloques (`git.gioser.net`, `git.tawasuyu.net`, `gitea.gioser.net`) salen del Caddyfile de
1286gioser —con respaldo previo, `caddy validate` y `reload`—, y quedan 16. Control inmediato:
1287`sergio.gioser.net` y `hifas.gioser.net` siguen en **200**. `gitea.gioser.net` pasa a `A` → la caja,
1288donde ya está su `redir`.
1289
1290#### El `:22` cerrado, sin perder el acceso
1291
1292Administración en **22022**, git por SSH en **2345**, y el **22 cerrado** (`Connection refused`) para
1293sacarse de encima el barrido de bots. La secuencia importa y es la única segura: **añadir** el puerto
1294nuevo → reiniciar → **entrar por él** → sólo entonces quitar el 22. Comprobado en ese orden, y el
1295`git clone ssh://…:2345` sigue funcionando después.
1296
1297#### 🧨 Los datos del gitea NUNCA estuvieron respaldados
1298
1299`respaldo-storagebox.sh` respalda el **store de artefactos**, no `/var/lib/gitea`. O sea que los 44
1300repos vivían en una sola copia — en gioser antes, en la caja ahora. La mudanza no lo empeoró, pero sí
1301lo hace urgente: **gioser se borra**. Hecho hoy desde la caja: snapshot de la DB con el servicio vivo
1302+ `rsync` a `u647150:gitea/` — **1,7 G** (`datos/` + `gitea.db` de 314 M).
1303
1304⚠ **Al Storage Box se entra por el puerto 23**, no el 22: el 22 da SFTP/SCP restringido y contesta
1305`Permission denied (publickey,password)`, que se lee como *«no tengo la clave»* cuando la clave está
1306perfecta. Pasó en las dos máquinas antes de mirar el script (`SB_PORT=23`).
1307
1308**Pendiente**: que ese respaldo sea periódico, no de una vez. Es un renglón en el cron de la caja.
1309
1310### 6.16 ⚠ SÍ se perdieron dos commits en la ventana — y cómo se detectó
1311
1312La pregunta correcta después de un cutover no es «¿arrancó?» sino **«¿entró algo en el viejo
1313mientras tanto?»**. Se contesta comparando **todos los refs de los dos lados**:
1314
1315```sh
1316for r in <repos>/*/*.git; do git -C "$r" for-each-ref --format="$r %(refname) %(objectname)"; done | sort
1317```
1318
1319845 refs a cada lado, y **dos diferencias**. Una era esperada (`sergio/takana` main, el nuevo por
1320delante con los commits posteriores al corte — `merge-base --is-ancestor` confirma fast-forward). La
1321otra **no**: `tawasuyu/tawasuyu` tenía en el VIEJO dos commits que el nuevo no tenía —
1322`b69008eb` (freebsd) y `02a9535f` (shuma, **19:48**)—, o sea **quince minutos después del snapshot
1323final**.
1324
1325**Por qué entraron**: el gitea viejo había resucitado (§6.15, OpenRC) y un cliente con el DNS
1326**cacheado** —el CNAME anterior tenía TTL 600— lo empujó a gioser aunque el autoritativo ya dijera
1327la caja. Las dos condiciones a la vez: un origen que revive y una caché que todavía apunta.
1328
1329**Recuperados** con un `git push` del ref exacto desde el clon local al gitea nuevo; la UI del nuevo
1330ya muestra `02a9535f`. Segunda pasada de comparación: **845/845 y una sola diferencia, la esperada**.
1331Y del lado de los metadatos, `action` tenía tres filas posteriores al snapshot (los mismos dos
1332repos) y **cero** issues, comentarios o releases: no se perdió nada que no fueran esos commits.
1333
1334**La lección para el resto de la mudanza**, en orden: (1) bajar el TTL **antes** del corte, no
1335durante; (2) apagar el origen de verdad —los DOS supervisores— **antes** de tocar el DNS; (3)
1336comparar refs después, siempre, porque es la única prueba de que no se perdió nada; y (4) dejar el
1337origen apagado un rato **antes** de borrarlo, precisamente para poder hacer esta comparación.
1338
1339### 6.17 ⚠ En gioser conviven arje Y OpenRC — y el prefijo `openrc-` de las cards ENGAÑA
1340
1341El usuario avisó: *«esa máquina la tengo con arje desde hace meses»*. Tiene razón, **y las dos cosas
1342son ciertas a la vez**:
1343
1344| medido | |
1345|---|---|
1346| PID 1 | **`arje-zero`** ✓ |
1347| la card `openrc-gitea` | ejecuta `sh -c "cd /var/lib/gitea && exec /usr/bin/gitea web …"` — **no llama a OpenRC** |
1348| `/run/openrc/started/` | **existe y tiene servicios**: NetworkManager, dbus, dhcpcd, fsck, hostname, hwclock, local, localmount… |
1349| `rc-update show default` | listaba `gitea` |
1350
1351⇒ **El prefijo `openrc-` es herencia del NOMBRE**, de cuando `arje-absorb` tradujo los servicios de
1352OpenRC a cards: la card no pasa por `rc-service`, encarna el binario directo. Pero **OpenRC quedó
1353como residuo ACTIVO** y puede arrancar servicios por su cuenta — que es lo que revivió al gitea con
1354`ppid ≠ 1` después de que arje lo hubiera detenido.
1355
1356**La regla para el resto de la mudanza**: antes de dar un servicio de gioser por apagado, preguntar a
1357los **dos**:
1358
1359```sh
1360arjectl list-units | grep <svc> # la capa de arje (PID 1)
1361rc-update show default | grep <svc> # el residuo de OpenRC, que también arranca
1362```
1363
1364Es [[la-etiqueta-no-es-el-hecho]] en su forma más cara: un nombre que dice `openrc-` y no es OpenRC,
1365junto a un OpenRC real que nadie esperaba que siguiera operando.
1366
1367### 6.18 Mudados `takana.gioser.net` y `hifas.gioser.net` *(estáticos puros)*
1368
1369Los dos son ficheros y nada más —sin backend—, así que mudarlos fue copiar 52 K, añadir su vhost al
1370Caddyfile de la caja, mover el DNS de CNAME a **A** y quitarlos del origen. **200 con TLS válido
1371desde `2.29.29.217`**, y control de que no se rompió lo demás: `sergio.gioser.net` sigue en 200 y
1372gioser baja de 16 a **14 vhosts**.
1373
1374Se repitió el patrón de ACME: el primer intento de certificado sale ANTES de que propague el DNS,
1375falla contra el origen y hay que forzar el reintento con `arjectl restart caddy`. **Conviene mover
1376el DNS y recién entonces añadir el vhost** — o asumir un `restart` de más.
1377
1378**Quedan en gioser 14 vhosts**, todos con backend propio (uvicorn, php-fpm, `tejido`, `shuma`…) o
1379fósiles sin DNS. Ésos no se mudan copiando un directorio: necesitan su servicio del otro lado.
1380
1381### 6.19 Los fósiles, barridos: de 19 vhosts a **2**
1382
1383Se midió cada dominio que quedaba —DNS por DoH **y** HTTP contra la IP del origen— antes de tocar
1384nada. El resultado deja la mudanza mucho más chica de lo que parecía:
1385
1386| clase | cuántos | qué son |
1387|---|---|---|
1388| **fósiles sin DNS** | 5 | `aura`, `api.aura`, `sigma`, `kosmofono`, `api.kosmofono` |
1389| **ya viven en OTRA máquina** | 3 | `summa`, `dev.summa`, `api.dev.summa` → `154.197.1.2` |
1390| **502 permanente** | 2 | `mail.sigma` (:9000 caído), `api.gioser.net` (:8000 caído) |
1391| **mudados hoy** | 5 | los tres de git + `takana` + `hifas` |
1392| **VIVOS y por mudar** | **2** | `sergio.gioser.net` y `api.sergio.gioser.net` |
1393
1394**Y ninguna de las raíces estáticas de los fósiles existe en disco**: `/var/www/{aura_frontend,
1395sigma,kosmofono,summa,summa-dev}` no están. El Caddyfile servía directorios ausentes — la
1396configuración sobrevivió a sus datos. De los backends, sólo `:8770` sigue escuchando, y su dominio
1397ya apunta a otra máquina; `:8766 :8765 :9000 :8000 :8768` están caídos.
1398
1399Los 10 bloques muertos salen del Caddyfile (con respaldo previo, `validate` y `reload`), y el control
1400confirma que los vivos siguen: `sergio` y `api.sergio` en **200**, y los mudados respondiendo desde
1401la caja. **gioser pasa de 19 vhosts a 2.**
1402
1403⚠ **El único fósil CON datos es `terapeuta.ec`: 279 M en `/var/www/terapeuta`**, sin DNS y sin vhost.
1404No se borra acá — se anota para la decisión de borrado de la máquina, que es del §6.
1405
1406**Lo que esto cambia**: mudar los dos que quedan es un frente acotado —un backend Python en `:7378`
1407y una API en `:8771`— y no las quince cosas que la lista sugería.
1408
1409### 6.20 🛟 Cinco binarios rescatados de la nada — el paso que CADUCABA
1410
1411Antes de tocar `sergio.gioser.net` apareció lo urgente: **cinco procesos vivos cuyo binario YA NO
1412EXISTE en disco** (`/proc/<pid>/exe` → `… (deleted)`). Sólo existían como inode huérfano: si el
1413proceso muere o la máquina se reinicia, se pierden. Es el paso que el SDD 29 §4.0 undecies llamó *«el
1414que caduca»*, y caducaba de verdad.
1415
1416 tejido · sandokan-mcp · pacha-secretos · puerta-f6e393ffbef3999e · shuma-gateway (240 M)
1417
1418Se recuperaron leyendo `/proc/<pid>/exe` con el proceso vivo, y ya están **fuera de gioser**: en
1419`/work/rescate-binarios/` de la caja **y** en `rescate-binarios/` del Storage Box. Cinco de los trece
1420binarios que nadie provee dejaron de depender de que nadie reinicie nada.
1421
1422### 6.21 🧱 `sergio.gioser.net`: el muro no es el sitio, es **glibc**
1423
1424El sitio son tres piezas, y sólo una se puede mudar hoy:
1425
1426| pieza | qué es | mudable a takana |
1427|---|---|---|
1428| el frontend | **117 M** de estático (`dist/`) | ✅ copiado ya a `/work/www/sergioh` |
1429| `/shuma/*` | `shuma-gateway` en `:7378` — **ELF dinámico, y su binario estaba BORRADO** | ⚠ hay que construirlo desde tawasuyu (es Rust del monorepo) |
1430| `api.sergio` | **uvicorn** con un venv de **405 M** | 🧱 **no, hoy no** |
1431
1432El backend es `fastapi + uvicorn + pydantic + google-generativeai + **langchain**`, con extensiones
1433compiladas `…cpython-314-x86_64-linux-**gnu**.so` — o sea **glibc**. Reempaquetar ese árbol de PyPI
1434como recetas no es realista, y correrlo en musl no es posible. **Es el caso de uso canónico del
1435[ADR 0015](adr/0015-imagenes-ajenas.md) (`qorpa`: imágenes ajenas glibc enjauladas)**, que está
1436PROPUESTO y sin implementar del todo.
1437
1438⇒ **El DNS de `sergio` NO se movió**: mover el nombre sin el backend deja el sitio servido y la
1439consola rota. El frontend queda copiado y esperando; el corte se hace cuando exista el camino para
1440las otras dos piezas.
1441
1442**Esto es lo que decide la fecha de borrado de gioser**: no es «mudar dominios», es que **un
1443servicio vivo no tiene hoy camino a takana**. Las salidas son tres y hay que elegir: (1) `qorpa`, que
1444es para exactamente esto; (2) que ese servicio viva en otra máquina —`summa` ya lo hace, y su DNS lo
1445demuestra—; o (3) que muera. Ninguna es técnica: es una decisión.
1446
1447### 6.22 🧨 El `curl` de la distro NO PUEDE VALIDAR TLS — y por eso nada se baja por HTTPS
1448
1449Al ir a traer la primera imagen ajena (`qorpa pull`), la caja falló con `curl failed to verify the
1450legitimacy of the server`. El certificado del servidor estaba bien; lo que falta es de este lado:
1451
1452```
1453* CApath: /etc/ssl/certs
1454* SSL certificate ... unable to get local issuer certificate (20)
1455$ curl --cacert /etc/ssl/certs/ca-certificates.crt ... → 200
1456```
1457
1458El `curl` del corpus está compilado **con `--with-ca-path=/etc/ssl/certs` y sin CAfile**, y ese
1459directorio contiene **un solo fichero**: el bundle. Un *capath* necesita **hash-links**
1460(`c_rehash`) — el índice — y no los hay. Los certificados están, el índice no.
1461
1462**Por qué faltan**: `recipes/ca-certificates.toml` deja escrito el hook
1463`/etc/ca-certificates/update.d/certhash`, que en Alpine ejecuta `apk` al instalar. **En takana no lo
1464ejecuta nadie**: la distro proyecta artefactos, no corre post-install. Es la misma familia que
1465[[subcomando-sin-driver]] — todo presente, y el paso que lo conecta no existe.
1466
1467**Alcance**: no es sólo `qorpa pull`. Es `takana install --repo https://…`, el mirror, y cualquier
1468`curl`/`wget` de un script en una caja instalada. **No falla al construir ni al instalar: falla la
1469primera vez que la máquina intenta bajar algo.** Nadie lo había visto porque el hub usa el `curl` de
1470Artix.
1471
1472**Arreglado en la receta**: los hash-links se generan **en el build** —donde `c_rehash` y perl ya
1473existen— y viajan dentro del artefacto, con una guarda que **falla ruidosamente si el rehash no
1474produce ninguno**. Re-sella `ca-certificates`, que es raíz de `perfil.base`.
1475
1476**Apaño mientras tanto**, para invocaciones puntuales: `CURL_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt`
1477(comprobado: 200).
1478
1479### 6.23 `qorpa` en la caja: preflight en verde, y el segundo muro es `tar`
1480
1481Con el backend de `sergio` sin camino a musl (§6.21), la salida elegida es **qorpa**. Estado medido
1482en la caja:
1483
1484| paso | resultado |
1485|---|---|
1486| userns anidado · overlayfs sin privilegios | ✅ ya estaban |
1487| **disco** | ❌→✅ `/var/lib/hammer` vive en la raíz (3 G) ⇒ `qorpa` **se movió a `/work`** (62 G) por symlink |
1488| `subuid`/`subgid` | ❌→✅ rango escrito para root |
1489| `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) |
1490| veredicto del preflight | **de «BLOQUEA 1 · LIMITA 4» a «LIMITA 1»** |
1491| `qorpa pull` de Arch bootstrap | baja y **verifica el sha256**, y falla al desempacar |
1492
1493El segundo muro: el rootfs de Arch es `.tar.zst` y **el `tar` de la imagen es el de busybox**, que no
1494lo entiende — el mismo tropiezo que ya costó el lab (`tar: unrecognized option: zstd`). `zstd` SÍ
1495está instalado. ⇒ `qorpa pull` tiene que descomprimir con `zstd -dc | tar -x` cuando el archivo es
1496`.zst`, en vez de dárselo entero a `tar`. Es un arreglo pequeño en el CLI, y hasta entonces la
1497alternativa es una imagen `.tar.gz` (Ubuntu base) — que además obliga a reinstalar las deps del venv,
1498porque el de gioser trae extensiones de **CPython 3.14** y Ubuntu 24.04 lleva 3.12.
1499
1500### 6.24 El TLS arreglado, la distro con nombre, y **por qué `upgrade` se quedaba sin espacio**
1501
1502**El `curl` ya valida.** Con `ca-certificates` re-sellado —**119 hash-links en el capath**, generados
1503en el build— la caja baja por HTTPS **sin ningún apaño**: `curl -I https://…` → **200**. El arreglo
1504tardó tres intentos y los dos primeros los cazó la guarda que puse en la propia receta: primero
1505`c_rehash` no estaba en el `PATH` (lo instala esa misma receta en `/out/usr/bin`), y después los
1506certificados **no estaban sueltos** en `usr/share/ca-certificates/` sino en su subdirectorio
1507`mozilla/`, así que `c_rehash` sólo veía el bundle y lo saltaba —correctamente— con «does not
1508contain exactly one certificate». Sin la guarda, las tres veces habría sellado un capath vacío.
1509
1510**`fastfetch` (2.68.1) corre en la caja** — y al correrlo apareció otra ausencia:
1511
1512```
1513OS: takana x86_64 ← ahora
1514Host: vServer (20171111)
1515Kernel: Linux 7.1.2 · CPU: AMD EPYC-Rome (4) · Memory: 393 MiB / 7.58 GiB
1516```
1517
1518…porque **`/etc/os-release` NO EXISTÍA**. La distro era anónima para cualquier programa que no fuera
1519suyo. Se resolvió con una receta propia (`os-release`, `source.dir`) en vez de una constante en
1520`takana-bootstrap`: meterlo ahí re-sellaría el `product-rootfs` —el baseline del selfhost— por cinco
1521líneas. Sin `VERSION_ID` ni fecha a propósito: un sello con la fecha del build cambiaría el hash del
1522artefacto, y con él la clausura de toda imagen que lo lleve, cada día y sin motivo.
1523
1524#### 🧨 `/var/lib/hammer` es una partición de 487 MB — y ahí viven las generaciones
1525
1526`upgrade apply` falló dos veces con `No space left on device` teniendo **3 G libres en la raíz**. Ni
1527el espacio de `/` ni los inodos (9% usados): el estado de generaciones vive en
1528**`/var/lib/hammer`, que es `sda3` y mide 487 MB** (la partición «estado» del layout). Cada
1529generación guarda una copia del árbol aplicado — el nuestro son **272 MB** — así que **dos no caben**.
1530
1531⇒ El estado se movió a `/work` por symlink, igual que `qorpa`. Tras eso: `✓ generación 6 aplicada`.
1532**El layout de la imagen necesita revisión**: 512 MB de «estado» no alcanzan para un mecanismo que
1533guarda un árbol entero por generación, y el síntoma (`ENOSPC` con la raíz medio vacía) apunta al
1534sitio equivocado.
1535
1536### 6.25 ✅ CUTOVER DE `api.sergio.gioser.net` — el primer servicio AJENO que sirve takana *(2026-09-15)*
1537
1538**`https://api.sergio.gioser.net` responde 200 con certificado público válido desde `2.29.29.217`**,
1539y su `/api/chat/` contesta con Gemini de verdad. El backend corre **dentro de una jaula `qorpa`**
1540(rootfs de Arch pineado por sha256), supervisado por `arje-zero` como el ente `sergioh-api`.
1541
1542Es el servicio que §6.21 declaró sin camino a musl —su venv trae extensiones
1543`cpython-314-x86_64-linux-**gnu**.so`— y por eso «lo que decide la fecha de borrado de gioser». El
1544camino elegido era `qorpa` (ADR 0015) y ahora está recorrido de punta a punta.
1545
1546**La coincidencia que lo hizo barato:** el Arch bootstrap pineado trae **python 3.14.7** y el venv de
1547gioser es **3.14.6**. Misma serie ⇒ las extensiones compiladas no son un problema: el venv se rehace
1548adentro con `pip`, no se copia.
1549
1550#### 🧨 EL MURO: la jaula no viajaba en NINGUNA imagen
1551
1552`takana qorpa provision` abortó con un mensaje correcto y una instrucción imposible:
1553
1554 Error: no encuentro harkaq-exec en /root/.cache/harkaq/harkaq-exec
1555 construilo: gcc -O1 -Wall -static -o … scripts/harkaq/harkaq-exec.c
1556
1557**En una caja instalada no hay `gcc`, ni `scripts/`, ni árbol de desarrollo.** El binario sólo existía
1558como un `gcc` a mano en la caché de `$HOME` del hub — o sea que la jaula del ADR 0015 funcionaba
1559**únicamente en la máquina donde alguien la había compilado**. Y su compañero estaba igual, medido en
1560`build-state.json`: **`bwrap` sellado desde hace meses con `"perfiles": []`**, CERO perfiles. Los dos
1561se invocan por PATH, y no sólo desde `qorpa`: `takana-build/src/sandbox.rs` llama a `bwrap` en cada
1562build. ⇒ **ninguna imagen de takana podía enjaular nada, ni construir**. Es
1563[[subcomando-sin-driver]] un piso más abajo: el CLI que los llama viaja en todas las imágenes y sus
1564herramientas en ninguna.
1565
1566Arreglado en la misma unidad de trabajo: `recipes/harkaq-exec.toml` (nueva, estática musl,
1567`b3:cd34954f…`, 269 K), `bwrap` + `harkaq-exec` declarados en **`perfil.base`**, y `qorpa.rs`
1568buscando el binario también en `/usr/bin` —el orden es `HARKAQ_BIN` → árbol de desarrollo → paquete,
1569para que un cambio en la jaula se pruebe sin instalar nada—. ⚠ El pin de la receta va **al commit que
1570tocó la fuente** (`1d9ddcee`, del 2026-09-03) y no a HEAD: el repo commitea cada media hora por el
1571cron de la cosecha, y pinear HEAD re-hashearía la receta cada media hora sin que su fuente se moviera.
1572
1573#### Los tres tropiezos del camino, todos de la misma familia
1574
15751. **`chown`**: el `rsync` preservó el uid 1001 de gioser, y dentro del userns ese uid queda FUERA del
1576 rango mapeado ⇒ ni siendo root adentro se puede escribir. `python -m venv` fallaba con
1577 `Permission denied` en el directorio concedido mientras andaba perfecto en `/tmp`. El árbol del
1578 sitio va a `root:root` del anfitrión, que es lo que el mapa de la jaula sí alcanza.
15792. **Una instancia, un `run`**: el segundo `qorpa run` sobre la misma instancia es rechazado por el
1580 kernel («dos overlays con el mismo `upper` corromperían la capa mutable»). Correcto y hay que
1581 saberlo: con el servicio arriba **no se entra a la instancia a hacer mantenimiento**.
15823. **`ps` de la caja no ve los procesos y `dig` no existe en el hub**. Dos herramientas ausentes que
1583 se leen como diagnóstico: el primero dice «no hay nada corriendo» y el segundo dejó un `until` de
1584 espera de DNS girando cinco minutos contra una condición que **nunca podía cumplirse**. Un
1585 guardián que no puede pasar nunca se ve igual que uno que todavía no pasó.
1586
1587#### Lo que quedó declarado, y lo que no
1588
1589- `instance.toml` es la verdad: `packages = ["python","python-pip"]`, `network = true` (pacman, pip y
1590 la propia API de Gemini la necesitan) y **un solo dir concedido** (`/work/sergioh` → `/srv/sergioh`,
1591 rw). Ni sockets, ni dispositivos, ni nada más.
1592- El código y el venv viven **fuera** de la instancia, en el anfitrión: el `upper` es caché (D3) y se
1593 tira. Y las 84 dependencias quedaron pineadas en `requirements.lock` — el `requirements.txt` del
1594 sitio no pinea nada, así que sin el lock un `recreate` traería otras versiones.
1595- La tarjeta `sergioh-api` va en `/etc/arje/cards.d/` **y** en el `genesis` de `/ente/seed.card.json`
1596 (son dos preguntas distintas: qué arranca solo y qué se puede encarnar a pedido, §6.12), con dos
1597 guardas que salen 78 nombrando el arreglo si falta la instancia o el venv.
1598- ⚠ **Todavía invoca con `HARKAQ_BIN=/usr/bin`** en la tarjeta: el `takana` de la caja es el del
1599 `commit` pineado en `recipes/takana.toml` y no trae aún la búsqueda en `/usr/bin`. Sale solo cuando
1600 se suba ese pin.
1601
1602#### El estado de la mudanza tras esto
1603
1604| | |
1605|---|---|
1606| **mudado hoy** | `api.sergio.gioser.net` (DNS: CNAME→`www` **borrado**, A→`2.29.29.217` TTL 60) |
1607| **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 |
1608| **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 |
1609| **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`) |
1610
1611### 6.26 ✅ `tawasuyu.net` y `gioser.net` MUDADOS — y el PHP que no existe en el corpus *(2026-09-15)*
1612
1613**Los dos sitios que quedaban con tráfico real sirven desde la caja `takana`**, con TLS público y
1614verificados desde fuera. Los servicios viejos **siguen corriendo en gioser a propósito** (decisión del
1615usuario: mudar el DNS y dejar el origen vivo, para poder volver en un minuto).
1616
1617| dominio | qué es | estado |
1618|---|---|---|
1619| `tawasuyu.net`, `www.` | landing + `/pkg` wasm + `/descargas` (3,8 G) | **200 desde 2.29.29.217** |
1620| `gioser.net`, `www.` | 5 raíces estáticas (428 M) + `/reencuentro` con PHP | **200 desde 2.29.29.217** |
1621| `sergio.gioser.net` | frontend + `/shuma/*` | **se queda en gioser**: su consola no tiene camino todavía |
1622
1623**`sergio` dejó de ser un `CNAME → www` y tiene su A propio** (apuntando a gioser, sin cambio
1624visible). Sin eso, mover `www` se lo habría llevado puesto — es la trampa del §6.14 vista a tiempo:
1625en esta zona **casi todo cuelga de `www`**. Lo que sí quedó colgando son tres fósiles (`api`,
1626`mail.sigma`, `monitor`): antes daban 502 desde gioser y ahora fallan el TLS contra la caja. Están
1627muertos hace meses; se anotan, no se mudan.
1628
1629**Dos cosas que el log de accesos decidió mejor que cualquier intuición:**
1630- La raíz de `tawasuyu.net` en gioser era **el monorepo entero (145 G) servido por HTTP**. El log
1631 dice que las únicas rutas con tráfico son `/`, `/descargas` y `/web` ⇒ se replicaron **sólo** los
1632 dos subárboles que el sitio usa (1,2 M + 3,8 G), con la MISMA estructura para que cada `rewrite`
1633 siga siendo el mismo.
1634- **`/hooks/*` NO se muda**: lo atiende `webhook-deploy.py`, que redespliega `aura_*`, `sigma_*`,
1635 `summa_*` y `brahman` — **los cuatro son fósiles del §6.19**, y tiene cero peticiones. Muere con la
1636 caja vieja. Un servicio vivo que sólo sirve a muertos es basura, no deuda.
1637
1638#### PHP: la segunda jaula, y por qué no entra al corpus
1639
1640`/reencuentro/` es una página con **un** `guardar.php`. PHP no está en el corpus y no tiene por qué
1641estar: lo sirve **`php-fpm 8.5.10` dentro de la instancia `gioser-php`** (ADR 0015), por
1642`127.0.0.1:9000`, supervisado por arje. Control contra el original, en los dos sentidos: `POST` con la
1643trampa anti-robots → `{"ok":true}` 200 igual que en gioser; `GET` → **405** igual que en gioser.
1644
1645⚠ **El webroot entra a la jaula EN LA MISMA RUTA** (`/work/www/gioser-web`): el `SCRIPT_FILENAME` de
1646FastCGI es una ruta absoluta del anfitrión, y si adentro viviera en otro sitio php-fpm contesta
1647«File not found» sin decir cuál. Y la config de php-fpm vive en el ANFITRIÓN
1648(`/work/etc/gioser-php/php-fpm.d/`) y entra por concesión: el `upper` de la instancia es caché y
1649`recreate` se la llevaría.
1650
1651#### 🧨 Los padres que inventa bwrap son **0700** — y eso deja la concesión fuera de alcance
1652
1653El muro real del día, y es general, no de PHP:
1654
1655 $ curl -X POST https://gioser.net/reencuentro/guardar.php
1656 File not found. ← y el fichero ESTÁ, montado, con sus modos correctos
1657
1658Para montar en `/work/www/gioser-web`, bwrap tiene que crear `/work` y `/work/www` —que la imagen de
1659Arch no trae— y **los crea `drwx------ root`**. Adentro somos root, así que todo a mano funciona; pero
1660**un servicio que baja de privilegio** (php-fpm a `http`, o cualquier instancia con `run_as`) no puede
1661ni atravesarlos. Medido con el control que lo separa de una confusión de permisos del anfitrión: como
1662`http`, leer un fichero **de la imagen** funciona y leer el **directorio concedido** da
1663`Permission denied`.
1664
1665⇒ `grants_to_args` crea ahora los ancestros que faltan con `--perms 0755 --dir`, y **sólo los que la
1666imagen no trae**: hacerlo sobre `/etc` o `/home` le cambiaría los modos a la imagen. Con test que
1667falla a propósito si la condición se rompe (`left: ["/etc","/etc/php"]` contra `right: ["/etc/php"]`).
1668Misma familia que el `--perms 1777` que ya hacía falta antes del `--tmpfs /tmp`.
1669
1670⚠ La caja corre el `takana` del `commit` pineado en `recipes/takana.toml`, así que **allá el arreglo
1671todavía no está**: el camino se abrió a mano en el `upper` de la instancia (`chmod 755 /work
1672/work/www`). Es exactamente lo que el arreglo vuelve innecesario en el próximo `takana upgrade`.
1673
1674#### Y el estado de `rust` y de `claude`, que no es el que parece
1675
1676- **`rust` está en la caja pero no instalado**: `rust-toolchain-bin` está **sellado en el store** y
1677 declarado en `perfil.servidor`, y `rustc 1.97.0` corre invocándolo por su ruta del store — pero
1678 **no está en el `PATH`** porque la caja se instaló antes de esa declaración. Proyectarlo son 798 M
1679 sobre una raíz de **5,8 G con 2,9 G libres**: entra, pero el layout de la imagen (§6.24) merece la
1680 revisión primero.
1681- **`claude` no está mudado**, y es otro caso de jaula: el binario de gioser es **glibc dinámico**
1682 (`/lib64/ld-linux-x86-64.so.2`), o sea el mismo montón que el backend de `sergio`. Lo que pesa no
1683 es el binario sino su estado: **6,8 G de `~/.claude`**, de los cuales 5,3 G son `jobs` y 976 M
1684 `projects` — y ahí vive la memoria, **indexada POR RUTA del repo**. Mudarlo es una decisión sobre
1685 qué se lleva, no una copia.
1686
1687### 6.27 🧦 `squid` mudado — y la jaula que arrancaba DEGRADADA cuando la arranca un init *(2026-09-15)*
1688
1689**El proxy de salida sirve desde la caja**: `squid 7.7` en `2.29.29.217:1137`, con la config, el
1690`passwd` de los tres usuarios y las dos ACL de gioser tal cual, dentro de la instancia `squid` y
1691supervisado por arje. **El de gioser sigue vivo e intacto** (7.6), así que los clientes que apuntan
1692a la IP vieja no se enteraron.
1693
1694Es un servicio con gente encima: el `access.log` del origen mostraba `CONNECT api.anthropic.com` y
1695`CONNECT claude.ai` **en el minuto anterior a mudarlo**, desde IPs de Venezuela y con tres usuarios
1696autenticados. Por eso se mudó entero y sin reescribir nada.
1697
1698Control en los dos sentidos: desde una IP no autorizada, **407 Proxy Authentication Required**
1699—igual que el original—; desde `localhost`, que su propia config permite, **TCP_TUNNEL/200 a
1700claude.ai y a api.anthropic.com**.
1701
1702#### Los cuatro muros, y el cuarto es el que vale
1703
17041. **`provision` con la config ya montada aborta**: pacman dice «squid.conf.default exists in
1705 filesystem» porque el paquete quiere escribir sus defaults donde está la concesión. ⇒ provisionar
1706 **primero**, montar **después**. Queda escrito en el manifiesto.
17072. **`/dev/shm` lo crea bwrap 0755 root**, y squid —que baja a `proxy`— muere con
1708 `FATAL: shm_open(...): (13) Permission denied`. Un `chmod 1777` en el arranque.
17093. **El fichero de PID sobrevive entre corridas y SIEMPRE parece fresco**: cada `run` tiene su propio
1710 namespace de PIDs, así que el `/run/squid.pid` de la corrida anterior dice `PID 2`… y en la nueva
1711 hay un PID 2 vivo. Squid concluye «Squid is already running» y se niega. ⇒ `rm -f` en el arranque.
1712 Es una trampa general de cualquier servicio con pidfile dentro de una jaula con `--unshare-pid`.
17134. 🧨 **El rango de subuid se buscaba por `$USER` — y un init no lo pone.** Bajo arje la tarjeta
1714 arranca con `PATH` y `HOME` y poco más; el nombre salía **vacío**, no había rango, y la jaula caía
1715 al **userns de un solo id**. Squid moría en `setgid(15): (22) Invalid argument` y el supervisor lo
1716 reintentaba 80 veces. El aviso de qorpa era correcto y estaba impreso —«no hay rango para `""` en
1717 /etc/subuid»— pero **lo que se ve en el bucle es el error de squid, no el nuestro: la degradación
1718 silenciosa la paga el de más abajo**. Y el mismo comando a mano, desde una shell con `$USER`,
1719 funcionaba perfecto: *el síntoma dependía de quién lo arrancaba*.
1720 ⇒ `nombre_de_usuario()` deriva el nombre del **uid real** leyendo `/etc/passwd`, y el entorno pasa
1721 a ser el último recurso. El uid es el hecho; `$USER` es una etiqueta ([[la-etiqueta-no-es-el-hecho]]).
1722 Las tarjetas llevan además `USER`/`LOGNAME` explícitos, que era el arreglo del día.
1723
1724⚠ **`arjectl start` sobre un Ente ya vivo lo DUPLICA** (se vio con `gioser-php`: dos entes, uno
1725peleando por el mismo `upper`). Y matar el proceso de adentro **no libera la instancia**: el
1726`takana qorpa run` de afuera sigue vivo y el siguiente `run` choca. Para relanzar, `stop` y después
1727`start`, mirando `status` en el medio.
1728
1729#### Y la pregunta que corresponde: ¿no va en una receta?
1730
1731**Sí, y sigue pendiente.** El propio §6.2 pone a `squid` en la lista de recetas que esta mudanza
1732tiene que producir. Lo de hoy fue la vía URGENTE —el servicio estaba en uso y la jaula lo levanta en
1733minutos, sin compilar nada—, no la respuesta final. La diferencia con `php-fpm` importa:
1734**PHP no queremos que entre al corpus** (es un intérprete ajeno al proyecto, y la jaula es su lugar
1735definitivo), mientras que **`squid` es C, se compila con el lab y su sitio natural es una receta**
1736como la de `gitea`. Cuando esté, la instancia se tira: el manifiesto es descartable a propósito.
1737
1738### 6.28 📦 `squid` YA NO ESTÁ ENJAULADO: corre desde el corpus *(2026-09-15)*
1739
1740La jaula del §6.27 duró unas horas, que es lo que tenía que durar. **Hoy el proxy de producción es
1741el artefacto sellado `b3:932ba096…`**, proyectado en la caja y arrancado por arje sin bwrap de por
1742medio: `pid 11548 · uid=968 · exe=/usr/sbin/squid`. La instancia `qorpa/squid` se borró — el
1743manifiesto es descartable por diseño (D3) y esto es exactamente para lo que existía esa salida.
1744
1745`recipes/squid.toml`: 7.7, estático de verdad (binario **y** los cuatro helpers), `[[user]] proxy`
1746con uid 968 y `[[service]]` del SDD 30. Declarado en `perfil.servidor` como paquete y en `servicios`.
1747
1748**La config NO viaja en el paquete y es a propósito**: `squid.conf`, el `passwd` de los tres usuarios
1749y las dos ACL (412 K, 40 IPs autorizadas) son datos del SITIO. El servicio los comprueba al arrancar
1750y sale **78 nombrando cuál falta**, en vez de dejar un bucle de reinicios.
1751
1752#### Los tres muros de la receta, en orden
1753
17541. **La URL de upstream devolvía una página HTML de 8985 bytes con un 200.**
1755 `squid-cache.org/Versions/v7/squid-7.7.tar.xz` no es el tarball. Pinear su sha256 habría anclado
1756 la receta a una página de error — y habría «funcionado» hasta el primer build. Va el release de
1757 GitHub, que además trae `configure` generado.
17582. 🧨 **`--export-dynamic` desactivaba el enlace estático, y el binario sellaba igual.** El primer
1759 artefacto tenía `usr/sbin/squid` **dinámico con `NEEDED libc.so`** mientras sus helpers salían
1760 estáticos: inerte en cualquier imagen sin cargador ([[needed-colgante-libstdcxx]]) pese a
1761 `link = "static"`. La cadena tiene tres eslabones y ninguno es obvio: `squid_LDFLAGS` trae
1762 `-export-dynamic` (para módulos eCAP, apagados) → **el wrapper del lab quita `-static` de
1763 cualquier enlace que mencione `--export-dynamic`**, a propósito, para poder enlazar las `.so`
1764 dlopen-ables de Python → y **libtool vuelve a añadirlo solo** en cuanto hay un `-dlopen`, así que
1765 sacarlo de la variable no alcanza. Se vacía `export_dynamic_flag_spec` en el `libtool` GENERADO,
1766 con guarda que aborta si el campo no aparece: *un `sed` que no acierta deja pasar el problema y
1767 el binario sale dinámico sin que nada falle*.
1768 ⚠ Y `-dlopen force` **no sobra**: vaciar `squid_LDFLAGS` entero rompe el enlace con
1769 `undefined symbol: lt__PROGRAM__LTX_preloaded_symbols`, que emite el propio libtool porque hay un
1770 `-dlopen`. De los dos flags estorba uno; distinguirlos costó un build y adivinar cuesta lo mismo.
17713. **`--disable-log-daemon-helpers` compilaba perfecto y no arrancaba.** El default de `access_log`
1772 es `daemon:`, así que sin `log_file_daemon` squid muere con
1773 `FATAL: logfile_daemon /usr/lib/squid/log_file_daemon: (2) No such file or directory`. **Sólo se
1774 ve levantando el servicio con la config real; el sellado, el hash y el `-k parse` pasan los tres.**
1775 Es la familia de [[subcomando-sin-driver]] otra vez.
1776
1777#### El control que hay que correr antes de tocar producción
1778
1779Con la config REAL del origen, en el hub y en un puerto aparte: `-k parse` sin FATAL, arranque
1780completo, **`CONNECT claude.ai` y `CONNECT api.anthropic.com` con TCP_TUNNEL/200**, el `access.log`
1781escrito por el log daemon, y el `basic_ncsa_auth` leyendo el `passwd` de verdad (control negativo:
1782con una clave mala contesta `ERR Wrong password`). Los dos primeros intentos de esta receta habrían
1783llegado a producción sin ese control: el binario estaba sellado y el hash era estable las dos veces.
1784
1785### 6.29 ⏱️ La caja tiene HORA, LATIDO y ROTACIÓN — y el respaldo del gitea dejó de ser a mano *(2026-09-15)*
1786
1787`planear.py --revisar` sobre el censo del día ordena lo que queda, y lo primero de la lista no eran
1788los servicios del usuario sino **tres capacidades que ninguna métrica reclama**: el disparador
1789periódico, la hora y la rotación de logs. Los tres paquetes ya estaban sellados y declarados en
1790`perfil.servidor` desde que ese perfil nació — **lo que faltaba era el eslabón que los ARRANCA**.
1791
1792| | antes | ahora |
1793|---|---|---|
1794| `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 |
1795| `crond` | no existía el latido | ejecuta el crontab real, verificado con una entrada `* * * * *` |
1796| `logrotate` | `/var/log/squid` sin rotar | diario con `squid -k rotate`, 14 copias |
1797| respaldo del gitea | **a mano, una vez** (§6.15) | `17 3 * * *`, con el snapshot consistente de la sqlite |
1798
1799**El respaldo, medido:** `scripts/respaldo-gitea.sh` sube **44 repos (23 `sergio` + 21 `tawasuyu`,
18001,5 G)** y un `gitea.db` de **332 M** tomado con `.backup` —consistente con el servidor vivo— al
1801Storage Box. El control no es que el script salga 0: es **contar los repos de los dos lados**, que
1802es lo que se hizo.
1803
1804⚠ **`chrony` y `cronie` NO declaraban `[[service]]`**, como `squid` antes: el paquete llegaba a la
1805imagen y no lo arrancaba nadie. Ahora lo declaran (fuera de `hash_inputs`: los hashes no se movieron)
1806y `perfil.servidor` los habilita en `servicios`.
1807
1808⚠ **La config va aparte y el servicio sale 78 si falta**, igual que gitea: a qué NTP se pregunta y
1809qué logs se guardan son decisiones del SITIO. Una caja que se sincroniza contra un pool que nadie
1810eligió es peor que una sin hora, porque nadie lo mira.
1811
1812#### Tres cosas medidas que valen más que el resultado
1813
18141. **La deriva era de gioser, no de la caja.** Antes de chrony la caja iba 15 s atrás; después, la
1815 caja quedó en hora de NTP y **el hub pasó a estar 3 s adelantado**. La máquina de referencia era
1816 la equivocada — medir «contra el otro» sin un tercero no dice quién está mal.
18172. **El spool de cronie es `/var/spool/cron/<usuario>`, no `…/crontabs/<usuario>`.** `crontab -l`
1818 mostraba las entradas y `crontabs/` estaba vacío. El día que alguien restaure un crontab a mano
1819 en el sitio equivocado va a tener un fichero perfecto que nadie lee. Lo decide un control y no la
1820 intuición: meter un `* * * * *` en el crontab REAL y ver si dispara.
18213. 🧨 **`sqlite3` seguía inerte en la caja** (`Error relocating: compressBound: symbol not found`):
1822 es el último de los 23 binarios del §6.4, y le faltaba `zlib-shared` — **sellado y declarado en
1823 `perfil.base` desde el 2026-09-11**, pero la caja se instaló antes. Sin él no había snapshot
1824 consistente, o sea que el respaldo habría copiado la sqlite a lo bruto. *Un paquete declarado no
1825 es un paquete instalado: en una caja viva, lo que vale es lo que el `upgrade` proyectó.*
1826
1827### 6.30 ⚰️ Tres servicios que MUEREN — y el cortafuegos que no puede correr todavía *(2026-09-15)*
1828
1829Decisión del usuario sobre lo que quedaba del censo, y las tres son «no se muda»:
1830
1831| servicio | por qué muere |
1832|---|---|
1833| **`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. |
1834| **`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. |
1835| **`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. |
1836
1837#### 🧨 Pero el sustituto NO PUEDE CORRER: el kernel de la caja no trae `nf_tables`
1838
1839 $ nft list ruleset
1840 netlink: Error: cache initialization failed: Invalid argument
1841
1842`nft 1.1.6` **está instalado** (`nftables` es raíz de `perfil.servidor` y está sellado). Lo que falta
1843está un piso más abajo, en el `.config` que el artefacto publica:
1844
1845 CONFIG_NETFILTER=y ← sí
1846 CONFIG_NF_CONNTRACK=y ← sí
1847 # CONFIG_NF_TABLES is not set ← AQUÍ
1848 # CONFIG_NETFILTER_ADVANCED is not set ← y ésta es la causa: NF_TABLES cuelga de ella
1849
1850Es otra vez la lección del §6.4 muro 1: **la receta dice lo que se CAMBIÓ; sólo el `.config` sellado
1851dice lo que QUEDÓ**. `linux-generic` sale de un `make defconfig`, y defconfig deja `NETFILTER_ADVANCED`
1852apagado, que arrastra a `NF_TABLES` con él.
1853
1854⇒ **Hoy la caja no tiene cortafuegos de ninguna clase**: ni fail2ban (que no se muda), ni el
1855sustituto (que no arranca), ni una regla. Con `:22022`, `:2345`, `:1137`, `:80` y `:443` públicos,
1856eso hay que decirlo entero y no dejarlo implícito. La cura es un kernel con
1857`CONFIG_NETFILTER_ADVANCED=y` + `NF_TABLES` (y `NFT_CT`, `NFT_LIMIT`, `NFT_COUNTER`, `NFT_LOG`),
1858que es trabajo del SDD 22 y termina en un **reinicio de la caja de producción**.
1859
1860#### La mitigación que NO depende del kernel, hecha hoy
1861
1862El `sshd` de la caja ofrecía `password` y `keyboard-interactive` — su config eran **cuatro líneas**
1863y ninguna decía nada de autenticación, así que regía el default de OpenSSH. Sin cortafuegos y sin
1864fail2ban, eso es exactamente la puerta que aquéllos cerraban. Ahora es **sólo claves**, con los
1865cuatro controles corridos: la clave entra ✅, `:22022` contesta `Permission denied (publickey)` sin
1866ofrecer contraseña ✅, `:2345` igual ✅, y el `git ls-remote` por SSH sigue funcionando ✅.
1867
1868**Lo que enseña:** *una defensa que se muda tiene que mudarse con su capacidad, no con su nombre*.
1869Decidir «fail2ban muere porque tenemos algo mejor» es correcto **y** deja un hueco abierto hasta que
1870ese algo mejor pueda ejecutarse. Entre la decisión y la capacidad hay un kernel de por medio.
1871
1872### 6.31 ✅ La caja arrancó con `nf_tables` — y el init la levantó ENTERA sola *(2026-09-15)*
1873
1874 $ nft list ruleset
1875 $ ← sin error: vacío, que es lo correcto en una caja sin reglas
1876
1877El kernel `b3:63fdd57c…` bootea, y con él **`nft` funciona por primera vez en una máquina takana**.
1878Comprobado con el mecanismo exacto que reemplaza a fail2ban, no con una regla de adorno: un
1879`set ... flags dynamic; timeout 10s` con `add @ban4 { ip saddr timeout 10s limit rate over 5/minute }
1880drop` — aceptado por el kernel (`rc=0`) y releído tal cual. Eso es el ban por IP **dentro del
1881kernel**, sin daemon.
1882
1883#### Lo que el reinicio probó de paso, y vale más que el kernel
1884
1885**La Semilla levantó los OCHO entes sola, todos con `↻ 0`:** `sshd`, `gitea`, `caddy`, `squid`,
1886`crond`, `chronyd`, `sergioh-api` y `gioser-php` — o sea los dos servicios enjaulados en `qorpa`
1887(con su `newuidmap`, su overlay y su `harkaq`) **arrancan desde el genesis igual que un binario
1888nativo**. Todo lo que se fue editando en `/ente/seed.card.json` a lo largo del día era, hasta este
1889momento, una declaración sin probar: un reinicio es el único examen que toma.
1890
1891Desde fuera, al minuto: los siete dominios en **200**, el proxy en **407** y `git ls-remote` por
1892SSH:2345 devolviendo el commit. Cero intervención.
1893
1894#### ⚠ `reboot` NO reinicia una caja con arje-zero
1895
1896`reboot` de busybox le pide a PID 1 que lo haga, y **arje-zero no implementa ese protocolo**: el
1897comando vuelve, no dice nada, y la máquina sigue arriba (`up 4 days` después de «reiniciar»). Lo que
1898sí funciona es **`reboot -f`**, que llama a `reboot(2)` directo saltándose al init. Con `sync` antes,
1899claro: el corte es duro por definición.
1900
1901⇒ **Y falta la pieza**: un init que gobierna un servidor de producción tiene que atender un apagado
1902ordenado. Hoy la única vía es el corte duro, que ya costó el `write_atomic` no durable del §6.13.
1903
1904#### 🧨 Casi reinicio el HUB por un backtick en un `echo`
1905
1906Escribiendo el aviso del reinicio, el mensaje decía ``… no atiende el `reboot` normal …`` dentro de
1907comillas DOBLES. La shell ejecutó lo que había entre backticks: **`reboot`, en gioser**. No pasó nada
1908por una razón que no es mérito de nadie —la sesión no es root y OpenRC contestó «you must be root»—
1909y el hub lleva 11 días arriba, con la granja y el cron encima.
1910
1911Es la **tercera vez en el día** que un backtick dentro de un texto se ejecuta
1912([[heredoc-sin-comillas-ejecuta-comentarios]]), y las dos anteriores sólo se comieron un comentario.
1913La regla deja de ser de estilo: **nunca un backtick dentro de comillas dobles en una shell** —
1914comillas simples, o `$(printf '%s' …)`, o directamente no poner el acento grave en el texto.
1915
1916#### Lo que queda para cerrar el frente del cortafuegos
1917
1918El kernel ya no estorba; falta **la política**: `PoliticaEntrada` (.ron) → `generate-input` →
1919`apply-input` del cortafuegos de tawasuyu, con los puertos reales de la caja (`22022`, `2345`, `80`,
1920`443`, `1137`). ⚠ Y hay que aplicarla con **interruptor de hombre muerto** (aplicar, esperar, y
1921`flush` automático si nadie confirma): una regla mal puesta en una caja **sin consola serie** deja
1922la única salida en `hcloud server enable-rescue`.
1923
1924### 6.32 🧱 El cortafuegos, puesto — y el primer baneado fui yo *(2026-09-15)*
1925
1926La caja filtra: `table inet tawasuyu_input`, **`policy drop`**, 15 reglas de puerto, y el set `ban4`
1927llenándose solo con lo que golpea desde internet. A los pocos minutos: **27 IPs baneadas y paquetes
1928tirados por el contador**. Eso es el reemplazo de fail2ban funcionando sobre tráfico real, dentro del
1929kernel y sin daemon.
1930
1931La política vive en `scripts/servidor/cortafuegos-entrada.ron` (formato `PoliticaEntrada` del
1932cortafuegos de tawasuyu) y declara los cinco puertos públicos: `22022` admin, `2345` git, `80`, `443`
1933y `1137` el proxy. El reglaset se genera con `cortafuegos generate-input` **en el hub** —el binario es
1934glibc y la caja es musl— y se aplica allá con `nft -f`.
1935
1936#### 🧨 El primer baneado fui yo, en segundos
1937
1938Aplicada la primera versión, desde fuera: `ssh` ✅, `https` ✅… y **`http`, el proxy y el git por SSH
1939muertos**. Al minuto, la caja entera dejó de contestarme.
1940
1941La causa no es una regla mal escrita: **el set `@ban4` es UNO SOLO para todos los servicios**, y la
1942regla `ip saddr @ban4 drop` está antes que todo. O sea que pasarse de tasa en *un* puerto te tira en
1943*todos*. Y el `nuevas_por_min: 5` del puerto de administración —correcto contra internet— es
1944exactamente lo que **me** pasa a mí: cada comando remoto de esta sesión es una conexión nueva.
1945
1946Lo que devolvió la máquina fue el **interruptor de hombre muerto**: antes de aplicar se deja
1947programado un `nft flush ruleset` a 180 s, y sólo se desarma si la verificación desde fuera sale
1948bien. Sin consola serie, esa es la diferencia entre un susto y un rescue.
1949
1950⚠ **Y el tipo ya lo avisaba.** `PoliticaEntrada` tiene un campo `confiables` cuyo comentario dice,
1951palabra por palabra, lo que me acababa de pasar: *«un `nuevas_por_min` chico en el puerto de SSH es
1952exactamente lo que se quiere contra internet y exactamente lo que te deja afuera cuando el que abre
1953seis sesiones en un minuto sos vos»*. Copié el `.ron` de ejemplo en vez de leer el tipo. Es
1954[[lei-hasta-donde-me-daba-la-razon]] otra vez, y la cura fue una línea:
1955`confiables: ["204.168.193.248", "154.197.1.13"]` — el hub y el worker, que se aceptan **antes** de
1956la lógica de tasa y por lo tanto no pueden entrar al set.
1957
1958#### Lo que este kernel todavía no puede, dicho en voz alta
1959
1960`nft -c` rechazó **cinco reglas** antes de aplicar nada:
1961
1962 tcp dport 22022 ct count over 10 drop
1963 ^^^^^^^^ Error: Could not process rule: No such file or directory
1964
1965`ct count` es `CONFIG_NFT_CONNLIMIT`, que el kernel de hoy no trae (el `.config` lo dice:
1966`# CONFIG_NFT_CONNLIMIT is not set`). Es el tope de conexiones **concurrentes** por servicio — el ban
1967por tasa, que es lo que reemplaza a fail2ban, no depende de él. Las cinco reglas quedan
1968**comentadas, no borradas**, en el fichero que se aplica: *lo que la política declara y el kernel no
1969puede tiene que verse*. El símbolo ya entró a `recipes/linux-generic.toml` y vuelve con el próximo
1970kernel; hasta entonces el mensaje —que no nombra la opción que falta— queda explicado ahí mismo.
1971
1972#### Que sobreviva al reinicio: un servicio `oneshot`
1973
1974`recipes/nftables.toml` declara ahora su `[[service]]` con `lifecycle = "oneshot"`: **cargar un
1975reglaset no es un daemon, es un acto**. Va **primero en el genesis**, antes que sshd y los demás:
1976entre que la red está y que las reglas cargan, la caja está abierta, y ese hueco se hace lo más
1977corto posible. Probado de verdad — `nft flush ruleset` y después `arjectl start cortafuegos`: las 15
1978reglas vuelven.
1979
1980Su guarda sale **78 nombrando el fichero** si el reglaset no está, en vez de dejar la caja sin
1981filtrar creyendo que está protegida: *un cortafuegos ausente y uno vacío se ven igual desde afuera
1982hasta que alguien prueba*.
1983
1984### 6.33 🧨 EL CORTAFUEGOS BANEÓ A LOS USUARIOS DEL PROXY — y squid nunca se cayó *(2026-09-16)*
1985
1986El usuario preguntó si el proxy estaba caído. **No lo estaba**: el ente `squid` llevaba horas
1987`corriendo` con `↻ 0`, escuchando en `:1137` y contestando `407` a quien preguntara. Lo que estaba
1988caído era **el acceso**: el cortafuegos que puse ayer estaba baneando a los usuarios autorizados.
1989
1990La prueba, en una línea: **`154.197.1.2` —una IP que está en la ACL de squid, o sea gente con
1991contraseña— apareció en `@ban4`**. Y el contador del ban iba en **38.246 paquetes tirados**.
1992
1993#### La causa no es la tasa: es la RÁFAGA
1994
1995 tcp dport 1137 ct state new add @ban4 { ip saddr timeout 300s limit rate over 300/minute burst 5 packets } drop
1996
1997`burst 5` significa «tolero cinco conexiones por encima del promedio». **Un navegador o un agente
1998detrás de un proxy abre decenas de CONNECT en el mismo instante**, aunque su promedio sea bajísimo:
1999seis de golpe y ya estás en el set. Y como **`@ban4` es UN SOLO set consultado antes que todo**,
2000caer por el puerto del proxy te tira también el web y el git.
2001
2002⚠ El tipo del cortafuegos ya traía el campo (`rafaga`, default 5) con un comentario que decía
2003«para un servicio web va alto (100-200)». Otra vez: **leí el `.ron` de ejemplo y no el tipo**.
2004
2005#### Lo que se hizo, en orden de urgencia
2006
20071. **`nft flush set … ban4/ban6`** — servicio restaurado en el acto.
20082. **Los usuarios del proxy a `confiables`**: la misma lista que la ACL de squid (21 IPs + 5 redes).
2009 Un proxy que autentica no necesita que el kernel le cuente las conexiones a un usuario conocido;
2010 lo que el ban tiene que parar son las fuentes DESCONOCIDAS.
20113. **`rafaga` por servicio, según su clientela**: ssh 5 · git 20 · web 100 · **proxy 200**. Y el
2012 proxy pasa a `1200/min` con ban de 60 s: red de contención contra un flood, no control de uso.
20134. Control después: **cero autorizados en el set**, 24 baneados (escáneres, que es lo que se quiere),
2014 y tráfico real pasando — `154.194.14.37 … CONNECT api.deepseek.com:443 sigma`, 298 K tunelados.
2015
2016⚠⚠ **Y un fallo de método que casi lo tapa: `nft -f` SUMA a la tabla existente.** Cargué el reglaset
2017corregido encima del viejo y quedaron **30 reglas**: las viejas ADELANTE, así que los `confiables`
2018nuevos no llegaban a evaluarse nunca. Se vio contando (`grep -c dport` daba 30 y no 15) y mirando
2019qué `saddr` salía primero. Por eso `cortafuegos apply-input` **borra la tabla antes de cargar** —
2020usar `nft -f` a pelo se saltea esa mitad.
2021
2022#### La hora exacta, reconstruida del `access.log`
2023
2024El usuario preguntó a qué hora se bloqueó, y el log lo dice sin ambigüedad. Su IP —`45.234.61.160`,
2025autenticada como `sergio`, **2709 peticiones**— tuvo estos silencios:
2026
2027| silencio | desde | hasta |
2028|---:|---|---|
2029| **93,2 min** | 16-09 **11:59:37** UTC | **13:32:49** UTC ← cuando vacié los sets |
2030| 50,1 min | 10:44:58 | 11:35:06 |
2031| 10,0 min | 11:45:06 | 11:55:05 |
2032
2033Los tres son el **`timeout` de 10 minutos del ban disparándose una y otra vez**: cada vez que volvía,
2034su primera ráfaga lo baneaba de nuevo. `154.197.1.2`, que usa el proxy de forma sostenida pero sin
2035ráfagas, sólo perdió huecos de 5 minutos.
2036
2037🧨 **Y la exención que tenía no servía: su IP no estaba en la red eximida.** La ACL histórica de squid
2038exime `45.234.60.0/24` y él entra desde `45.234.61.160` — **una red de al lado**. Parecía cubierto y
2039no lo estaba: la pertenencia se MIDE (`ip in red`), no se deduce del parecido del prefijo. Con el
2040`/23` que nft dedujo al unir los dos `/24`, ahora sí.
2041
2042#### Y la decisión de fondo: en un servicio que YA AUTORIZA, no va límite por tasa
2043
2044El uso real de esta caja es **intensivo** —varias sesiones de agente en paralelo, cada una abriendo
2045túneles a la vez—, y un límite calibrado para «una persona normal navegando» no protege de nada: el
2046atacante ajusta su ritmo, el usuario no puede trabajar más despacio. Squid ya pide usuario y
2047contraseña y tiene su ACL; el ban por tasa ahí no agrega seguridad, agrega cortes. Queda apagado
2048(60000/min, ráfaga 1000: números que ningún cliente real alcanza) y contra un flood queda el tope
2049GLOBAL `syn_nuevas_por_seg`, que no distingue usuarios ni banea a nadie por ser rápido.
2050
2051#### Lo que esto enseña del cortafuegos como herramienta
2052
2053Un cortafuegos correcto y un cortafuegos usable no son lo mismo, y la diferencia **no se ve al
2054aplicarlo**: las reglas cargan, el `nft -c` pasa, los sitios responden, y el daño aparece sólo cuando
2055un cliente REAL hace lo que los clientes reales hacen. El único control que lo habría cazado antes es
2056el que no corrí: **una ráfaga de conexiones desde una IP que NO esté en `confiables`**.
2057
2058### 6.34 📋 Censo del 2026-09-16: queda UN vhost — y el censo sin privilegio no veía 572 M
2059
2060Censo fresco de gioser (`censar.py --local --probe-dns`, sólo lee), para saber **qué falta de
2061verdad** en vez de arrastrar la lista del 11.
2062
2063```
2064 servicios vivo 23 · no-declarado 17 · declarado-muerto 81 · descartados 6
2065 dominios apunta-aca 1 · ya-mudado 6 · fosil-sin-dns 7
2066 datos /home 25 G (copiar 27 G) · /var/lib 8,1 G · /opt 1,2 G · /var/www 288 M
2067```
2068
2069**De los 29 dominios del Caddyfile sólo UNO sigue sirviéndose desde gioser: `sergio.gioser.net`.**
2070Comprobado desde fuera, resolución + HTTP, no por el fichero de config:
2071
2072| dominio | resuelve a | HTTP |
2073|---|---|---|
2074| `tawasuyu.net` · `gioser.net` · `git.tawasuyu.net` · `takana.gioser.net` · `hifas.gioser.net` · `api.sergio.gioser.net` | `2.29.29.217` | 200 |
2075| `gitea.gioser.net` | `2.29.29.217` | 301 |
2076| **`sergio.gioser.net`** | **`204.168.193.248` (gioser)** | 200 |
2077| `api.summa.gioser.net` | `154.197.1.2` (otra máquina) | — |
2078| `terapeuta.ec`, `andino.ec`, `api.sigma…` y 4 más | **sin DNS** | — |
2079
2080⇒ la lista de «tres vhosts» del §9 quedó vieja: `gioser.net` y `tawasuyu.net` ya están mudados
2081(§6.26) con su origen vivo a propósito. **Lo único que ata el DNS a gioser es la consola de `sergio`.**
2082
2083#### El rescate del §6.20 sigue vigente — y caduca de verdad
2084
2085Seis procesos corren hoy desde un **inodo borrado**. Cuatro tienen su copia en
2086`work/mudanza/rescate/` y el sha256 del `/proc/<pid>/exe` vivo **coincide bit a bit** con lo
2087rescatado el 12. Los otros dos (`/usr/local/bin/tejido` y `/usr/local/bin/shuma-daemon`) **no están
2088en el rescate**, pero en disco hay una versión **más nueva** de cada uno (hoy 11:13 y 14:20): no se
2089perdió nada porque el usuario los está reconstruyendo. La lección es la del §6.20 y no cambió: *ese
2090paso caduca, y quién caducó se ve mirando `/proc`, no el directorio*.
2091
2092#### 🕳️ Y el hallazgo del día: `-e` contesta «no existe» cuando lo que pasa es «no puedo mirar»
2093
2094El censo tiene tres estados a propósito (`ausente` / `sin_permiso` / `ok`) porque un `ls` sin
2095permiso se lee igual que un directorio vacío. Pero el tercer estado sólo se detectaba **sobre la
2096propia ruta**: cuando el que no deja pasar es un **ANCESTRO**, `[ -e "$p" ]` contesta que no, y la
2097ruta caía en `ausente` — que el censo **descarta sin decir nada**.
2098
2099```
2100 /root/.local drwx------ root root ← 0700
2101 /root/.local/bin 572 M de binarios a mano que NINGÚN paquete provee
2102```
2103
2104Corrido como `sergio`, el censo decía que `/root/.local/bin` no existe. Corrido como root, son
2105**572 M** de exactamente la clase que la mudanza no puede reconstruir: binarios puestos a mano.
2106Arreglado —si un ancestro existe y no es atravesable, el estado es `sin_permiso`— y probado en los
2107dos sentidos, que es lo que distingue un guardián de un adorno:
2108
2109```
2110 ancestro 0700 de otro dueño → sin_permiso (y sale en el ⚠ del resumen)
2111 ruta que NO existe de verdad → ausente (y NO se reporta) ← el control que tiene que pasar
2112```
2113
2114Con el arreglo, el censo como `sergio` pasa de **2 rutas ciegas a 13** — entre ellas el home entero
2115de `artix`, que antes no figuraba de ninguna manera. **El censo se corre como root**; la lista de
2116ciegas es el recibo de lo que una corrida sin privilegio no puede ver.
2117
2118#### Lo que queda, y por qué no lo decide el programa
2119
2120Descontados los que ya se decidieron (§6.30: `qdrant`, `act_runner`, `fail2ban` mueren) y los que
2121provee el init del destino, lo que sigue vivo en gioser es **un montón de daemons de tawasuyu que
2122ningún paquete provee** — binarios a mano en `/usr/local/bin` (1,2 G) y `~/.local/bin` (765 M + 572 M
2123en el home de root):
2124
2125```
2126 shuma-daemon · shuma-gateway (:7378) la consola de sergio.gioser.net — el único vhost que queda
2127 willay-daemon · willay-crosscheck · tejido (:4102,:33097) · pacha · pacha-secretos
2128 matilda · tupu · thasnuna · sandokan-watch · openclaw · zeroclaw
2129 puerta-f6e393ffbef3999e (:34221,:44961) binario de test en target/debug, BORRADO del disco
2130 webhook-deploy.py
2131```
2132
2133`planear.py --revisar` los saca con su motivo, pero **la decisión es del usuario y el programa no la
2134va a inventar**: son las herramientas propias del usuario, no servicios de un catálogo. Y los
2135**datos** tampoco se recomiendan solos (§3): `/home` son 25 G que incluyen 6,8 G de `.claude` y
21361,3 G de binarios sueltos.
2137
2138### 6.35 🧳 Los binarios sueltos, desglosados — y qué de `.claude` viaja *(2026-09-16)*
2139
2140Decisión del usuario sobre el §6.34: **shuma se construye desde tawasuyu** (ya está encolado:
2141`recipes/incoming/shuma-{gateway,daemon}.toml`), **los daemons de tawasuyu viven todos**, y de
2142`.claude` decide el criterio de quien lo usa. Falta el detalle de los sueltos, que es esto.
2143
2144#### Son 2,7 G en tres directorios, y casi nada de eso es irreemplazable
2145
2146| clase | cuánto | qué es | se reconstruye |
2147|---|---|---|---|
2148| **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 |
2149| **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** |
2150| **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 |
2151| **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 |
2152
2153⇒ **lo caro no es lo valioso**. De los 2,7 G, 1,8 G son reconstruibles o duplicados, y lo que no
2154está en ningún repo ni en ningún paquete son **27 guiones que suman menos de un megabyte** — el
2155pegamento que nadie recuerda hasta que falta. Van al plan como una sola entrada, y con nombre.
2156
2157Y los **572 M de `/root/.local/bin`** que el censo no veía (§6.34) resultaron ser exactamente eso:
2158la copia de `kiro-cli*` que ya está en el home de `sergio`. La lección no cambia —un censo que dice
2159«no hay nada» de lo que no pudo mirar es peor que uno que falla—, pero el contenido, esta vez, era
2160duplicado.
2161
2162#### `.claude`: 6,8 G en disco, **15 M es lo que hace falta para seguir funcionando igual**
2163
2164Criterio, porque es lo que me deja trabajar allá como acá:
2165
2166| viaja | qué | tamaño |
2167|---|---|---|
2168| ✅ | `projects/*/memory/` de los 18 proyectos — la memoria destilada | **6,2 M** |
2169| ✅ | `settings.json`, `plugins/`, `history.jsonl` | ~8,6 M |
2170| ⛔ | `jobs/` (5,3 G), `downloads/` (228 M), `archivo-sesiones/` (286 M), `file-history/`, `shell-snapshots/`, `cache/`, `paste-cache/` | 6,1 G |
2171| ⚠ | `projects/*/*.jsonl` — los transcripts crudos (973 M) | ver abajo |
2172
2173Los **transcripts no hacen falta para funcionar**: la memoria es su destilado y es lo que se lee al
2174arrancar una sesión. Lo que se pierde sin ellos es `--resume` de una sesión vieja y la posibilidad
2175de releer una conversación que nadie resumió. Por eso no van a la caja —que tiene 42 G libres en
2176`/work` y los quiere para el store— sino al **Storage Box del respaldo**, que es donde vive lo que
2177se guarda por si acaso. La memoria, en cambio, viaja con la máquina.
2178
2179#### ⚠ Y una trampa de ruta que haría todo esto inútil
2180
2181**La memoria se indexa POR RUTA**: el directorio se llama `-mnt-vvv-takana` porque el repo vive en
2182`/mnt/vvv/takana`. En la caja el repo está en **`/opt/takana`** ⇒ copiar `memory/` tal cual deja los
2183163 ficheros en disco y **ninguno se encuentra**, sin que nada falle. Las dos salidas son renombrar
2184el directorio a la ruta de destino (`-opt-takana`) o darle al repo la misma ruta que acá. Se elige
2185al copiar, no después.
2186
2187#### 🕳️ La caja no tiene usuario `sergio`
2188
2189`/etc/passwd` de `2.29.29.217`: `root`, `sshd`, `gitea`, `proxy`. Nada más. En gioser,
2190`shuma-daemon` corre como `sergio` —y `shuma-gateway` también—, así que la tarjeta de arje que los
2191declare tiene que **crear la cuenta primero**; y el payload `Native` de arje **no tiene campo de
2192usuario** (SDD 29 §4.0 quinquies), así que declararlos sin más los pone a correr como root. Es la
2193misma advertencia que ya lleva `recipes/incoming/shuma-daemon.toml` en su cabecera, escrita donde se
2194va a leer.
2195
2196### 6.36 🚚 Lo que se movió hoy — y las cuatro verificaciones que se hicieron EN DESTINO *(2026-09-16)*
2197
2198Con las decisiones del §6.35 puestas, se movió lo que no dependía de nada más. **Cada copia se
2199verificó del lado del destino**, que es la regla que el `rsync` con exit 0 y 1367 artefactos vacíos
2200dejó escrita (§6.13, y la regla 2 de `aplicar.py`).
2201
2202| qué | a dónde | verificación en destino |
2203|---|---|---|
2204| **los 27 guiones** (75 KB) | `takana:/work/rescate-guiones/` | `sha256sum -c SHA256SUMS` ⇒ **27 OK** |
2205| **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** |
2206| **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 |
2207| **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` |
2208| credenciales y config (gitconfig, npmrc, gh, ssh, crontabs, Caddyfile) | `takana:/work/mudanza-secretos/` 0700 | 27 ficheros en origen y **27 en destino** |
2209| 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 |
2210
2211#### ⚠ Las credenciales NO se instalaron en su sitio, a propósito
2212
2213La caja **ya tiene** su `/root/.ssh` (con `github5`), su crontab (el latido de la caja, §6.29) y su
2214`/etc/caddy/Caddyfile` con los siete vhosts que ya sirve. Pisar cualquiera de los tres con el de
2215gioser rompe lo que hoy funciona. Quedan en `/work/mudanza-secretos/` con su `LEEME.txt`, y se
2216instalan **cuando se mude el hub**, que es otra unidad de trabajo. El `.gitconfig` es el caso más
2217claro: trae los `insteadOf` que **reescriben remotos**, así que instalarlo cambia a dónde empuja
2218`git push` sin que nadie lo pida.
2219
2220La **única** excepción es la clave de release, que sí fue a su ruta canónica: sin ella nadie puede
2221volver a firmar el repo, y ese fallo no aparece el día que se borra gioser sino la próxima vez que
2222alguien publica.
2223
2224#### 🔍 Un «576 M contra 1,3 G» que parecía una copia a medias
2225
2226`du -sh` en el Storage Box decía **576 M** de los 1,3 G subidos. Con el antecedente del rsync que
2227llenó el disco, eso se lee como copia truncada. No lo era: el Storage Box **comprime**, y su shell
2228restringida no tiene `find` ni acepta tuberías, así que el conteo de ficheros —la verificación
2229obvia— ahí no se puede hacer. Lo que sí se puede es **preguntarle a rsync**: una corrida `-an`
2230compara tamaño y fecha contra el destino real y dijo **1 fichero pendiente**, el que estaba
2231creciendo mientras se copiaba.
2232
2233⇒ *la verificación tiene que poder correrse en el destino que hay, no en el que uno imagina*. Y un
2234número que no cuadra merece una segunda medición antes de un diagnóstico: `du` medía otra cosa.
2235
2236#### Lo que NO se movió, y no es olvido
2237
2238**~10 G de árboles personales en `/home/sergio`** —`android-sdk` 1 G, `maps`, `imm`, `humanoid`,
2239`hifas`, `fdroid`, `valens-conversion`, `pyswisseph`, `accordion`…— y `/opt` (1,2 G, que es
2240`android-sdk` otra vez y `google`). **Qué datos valen no se deduce de la máquina** (§3), y éstos son
2241proyectos del usuario, no servicios de un censo: van a la lista de decisiones, no a una copia hecha
2242por criterio ajeno.
2243
2244De `/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
2245el gitea, que ya está mudado desde el §6.14.
2246
2247### 6.37 ✅ CUTOVER DE `sergio.gioser.net` — el último vhost, y gioser deja de servir *(2026-09-16)*
2248
2249**Ya no queda ningún dominio sirviéndose desde gioser.** El último era éste, y lo que lo ataba no
2250era el sitio sino su consola: `/shuma/*`. Verificado desde fuera, contra la IP nueva:
2251
2252```
2253 https://sergio.gioser.net/ → 200 408 bytes, la SPA
2254 https://sergio.gioser.net/shuma/ → 200 «shuma-gateway ok» ← el gateway, no la SPA
2255 https://sergio.gioser.net/ruta-inventada → 200 la SPA (el fallback, que es lo correcto)
2256```
2257
2258⚠ **El `200` de `/shuma/` había que mirarlo dos veces.** El bloque termina en
2259`try_files {path} {path}/ /index.html`, así que **cualquier ruta inexistente devuelve 200 con la
2260SPA**: un `curl -o /dev/null` que sólo mira el código habría dado el mismo verde con el proxy mal
2261puesto. Lo que decide es el CUERPO — 17 bytes que dicen `shuma-gateway ok` — y el control es
2262compararlo con lo que el origen viejo sigue sirviendo, byte por byte. Igual con `/shuma/rpc`: las
2263dos máquinas contestan el MISMO `400 {"error":"bad json: …"}`.
2264
2265#### Lo que hubo que construir, en orden
2266
22671. **Las dos recetas** (§6.34) sellaron en el worker: `b3:107dfb54…-shuma-gateway` (6,3 M) y
2268 `b3:f9b92acc…-shuma-daemon` (5,6 M) — los hashes que `takana hash` había anticipado antes de
2269 encolarlas. `file` dice **`statically linked`**: nada de cargador, que era exactamente lo que le
2270 faltaba al binario glibc de gioser (y cuyo inodo, además, ya estaba borrado del disco).
22712. **La cuenta, declarada y sin privilegio.** `[[user]] shuma` (uid 967) en la receta del daemon, y
2272 el descenso con `setuidgid` dentro del `argv` de la Card, igual que gitea — porque el payload
2273 `Native` de arje **no tiene campo de usuario**. Declararlo «como estaba» lo habría puesto de
2274 root, y esto es un demonio que abre PTYs y lanza shells.
22753. **⚠ Y la shell de la cuenta NO es un detalle.** El default de `[[user]]` es `/bin/false`, que es
2276 lo correcto para gitea o squid y **exactamente lo contrario** para éste: con la shell inerte el
2277 servicio arranca, se supervisa, contesta 200… y cada pestaña que alguien abra muere al instante.
2278 Un fallo que no se ve al desplegar: se ve al usarlo. Va `shell = "/bin/sh"`.
22794. **La config que no se regenera.** El `gateway-token` (32 B) y `keys/identity.x25519` viajaron a
2280 `/var/lib/shuma/.config/shuma/`: generar unos nuevos deja fuera a los clientes ya emparejados.
2281 Por eso la guarda de la Card **exige** el token y no lo crea, y dice de dónde sale.
22825. **Las dos Cards** entran en `/etc/arje/cards.d/` **y** en el `genesis` de `/ente/seed.card.json`
2283 (son dos preguntas distintas: qué se puede encarnar a pedido y qué arranca solo). La semilla
2284 quedó con 13 entradas y vuelve a parsear.
22856. **Declarado en `perfil.servidor`**: los dos paquetes y los dos labels en `servicios`. Entran como
2286 PAR — el gateway sin el daemon es un puente a ninguna parte.
2287
2288`[[user]]` y `[[service]]` están **fuera de `hash_inputs`**, así que declarar todo eso no movió
2289ningún ArtifactHash: comprobado en los dos, antes y después.
2290
2291#### 🔁 El DNS: la API tiene una acción para esto y el §6.25 no la había encontrado
2292
2293Aquel cutover dejó escrito «un `PUT` sobre el rrset no puede cambiar el tipo: hay que `DELETE` del
2294CNAME y `POST` del A». Es cierto para un cambio de TIPO. Para cambiar el VALOR, el `PUT` tampoco
2295sirve —`can't update records with this endpoint`— pero existe una acción que lo hace **atómica**:
2296
2297```
2298POST /v1/zones/<id>/rrsets/<nombre>/<tipo>/actions/set_records {"records":[{"value":"…"}]}
2299```
2300
2301Sin ventana sin registro, que es lo que sí tiene el `DELETE`+`POST`. Con TTL 60 la resolución
2302pública cambió **en menos de 8 segundos**, y volver atrás es la misma llamada con la IP vieja.
2303
2304#### El origen sigue vivo, a propósito
2305
2306Como en §6.26: en gioser `shuma-daemon`, `shuma-gateway` y su bloque de caddy **siguen corriendo**.
2307Mudar el nombre y dejar el origen encendido permite volver en un minuto, y no cuesta nada mientras
2308la máquina exista. Lo que ya no existe es la dependencia: **ningún dominio resuelve a gioser**.
2309
2310⚠ Pendiente menor, anotado donde se va a leer: el daemon avisa al arrancar que no encuentra
2311`shuma-askpass` («sudo/ssh pedirán la clave por el TTY»). Es otro crate del mismo workspace y es
2312otra receta — no bloquea la consola.
2313
2314### 6.38 🧩 Los primeros cuatro daemons propios, corriendo en la caja *(2026-09-16)*
2315
2316De las diez recetas encoladas, cuatro sellaron y ya corren supervisadas por arje:
2317
2318| | cuenta | qué hace, comprobado |
2319|---|---|---|
2320| `matilda` | **root** | lee el access log de caddy y archivó **78 ficheros** en `/var/lib/tupu/takana/` |
2321| `pacha` | `pacha` (965) | vivo, 0 reinicios, con SUS reglas (`reglas.ron`), no las de fábrica |
2322| `pacha-secretos` | `pacha` | vivo, 0 reinicios — y su binario en gioser era un **inodo borrado** |
2323| `sandokan-watch` | root | **frenado a propósito**: no puede trabajar acá (ver abajo) |
2324
2325#### ⚠ Tres corren como ROOT, y está declarado en vez de heredado
2326
2327Lo natural sería una cuenta sin privilegio por servicio, como `shuma` o `gitea`. Con el trío de la
2328telemetría **no se puede**, y las dos razones son medidas:
2329
23301. `matilda` lee `/var/log/caddy/requests.json`, que caddy crea **`-rw------- root root`** y recrea
2331 igual en cada rotación: un grupo con permiso de lectura se pierde en la próxima.
23322. `tupu`, `matilda` y `sandokan-watch` escriben en el MISMO `/var/lib/tupu`, y en gioser sus 322
2333 ficheros son `root:root`. Bajar uno solo deja **mezcla de dueños en un árbol compartido**: escribe
2334 el primero y los otros fallan al modificar.
2335
2336⇒ o los tres como root, o ninguno. La salida limpia está anotada en la receta para el día que se
2337quiera: que caddy escriba con `mode 640` y que el árbol sea de una cuenta propia. `pacha` y
2338`pacha-secretos` sí bajan a una cuenta propia, porque en gioser tampoco corrían como root.
2339
2340#### 🕳️ La caja se llamaba «(none)» — y eso se archivaba
2341
2342`matilda` archiva POR MÁQUINA, y sus primeros 72 ficheros fueron a `/var/lib/tupu/**none**/`:
2343
2344```
2345 $ hostname → (none)
2346 $ cat /etc/hostname → no existe
2347```
2348
2349**Ninguna caja takana fija su hostname**: no lo hace `netup`, no está en el product-rootfs, no hay
2350`/etc/hostname`. Nunca importó porque nada archivaba por nombre — hasta que llegó algo que sí. Y no
2351falla: archiva bajo `none`, y dos máquinas distintas archivarían en la misma carpeta.
2352
2353Puesto `/etc/hostname` + una Card **OneShot** `hostname` en el genesis, para que sobreviva al
2354reinicio sin depender de que alguien se acuerde. Con el nombre puesto, matilda re-archiva en
2355`/var/lib/tupu/takana/`. Quedan 72 ficheros huérfanos bajo `none/`: son los 20 minutos anteriores.
2356
2357⇒ **lo correcto es que lo haga `netup`**, que es quien configura la identidad de red de la máquina;
2358la Card es la mitigación de hoy, y está dicho en su propia guarda.
2359
2360#### 🛡️ Un vigía que no vigila es PEOR que uno caído, porque el caído se ve
2361
2362`sandokan-watch` arrancó, quedó «corriendo · 0 reinicios»… y no guardaba una línea. Lo dice él mismo
2363si uno lo corre a mano:
2364
2365```
2366sandokan-watch · sin fuente de accesos (ni /var/log/auth.log ni journalctl): no se guarda nada
2367```
2368
2369En gioser lee el `auth.log` de un syslog que **en takana no existe** — no hay systemd ni syslog. Su
2370Card ahora lleva una guarda que sale **78** nombrando el problema, así que el servicio no queda
2371verde mintiendo; y **no entra al `genesis`**, sólo a `cards.d`, porque no tiene sentido que arranque
2372al boot para fallar. Destrabarlo es darle el diario de arje como fuente, y eso es trabajo de su repo.
2373
2374#### Dos herramientas que no existen donde se prueba
2375
2376Dos veredictos falsos en una tarde, los dos por probar con algo que la caja no tiene:
2377
2378- **`/dev/tcp/host/puerto` no existe en busybox `ash`** ⇒ un barrido de puertos contra gioser dio
2379 «cerrado» para los cinco, incluidos `:80` y `:443`, que sirven. Con `curl telnet://` el resultado
2380 es el contrario: `:2345` y `:443` **abiertos**, `:22` cerrado.
2381- **La expansión de llaves (`{a,b}`) tampoco** ⇒ un `ls /store/*-{matilda,pacha}` dijo que los
2382 artefactos no habían llegado. Habían llegado.
2383
2384Es la misma lección del §6.23 (`ps` y `dig` ausentes) y merece repetirse: *una prueba que no puede
2385pasar se ve igual que una que todavía no pasó*.
2386
2387### 6.39 🕸️ Los nueve daemons propios, y la línea que separa «se muda» de «se INTERCAMBIA» *(2026-09-16)*
2388
2389Nueve de las diez recetas sellaron. Cinco corren; cuatro están instaladas y **frenadas a propósito**,
2390cada una por un motivo distinto y con su guarda diciéndolo.
2391
2392| corriendo | | frenado | por qué |
2393|---|---|---|---|
2394| `matilda` · `tupu` | root, escriben `/var/lib/tupu/takana/` | `sandokan-watch` | en takana no hay `auth.log` ni journalctl |
2395| `pacha` · `pacha-secretos` | cuenta `pacha` (965) | `tejido` | **misma identidad libp2p que el de gioser** |
2396| `willay-daemon` | root, con su índice mudado | `willay-crosscheck` | necesita el roster de tejido |
2397| `shuma-daemon` · `shuma-gateway` | cuenta `shuma` (§6.37) | `thasnuna` | pide `claude` autenticado y `sandokan-mcp` |
2398
2399#### ⚠ La regla que sirvió para los vhosts NO sirve para una identidad
2400
2401Con los sitios web la pauta fue: **mudá el DNS y dejá el origen encendido**, así volver cuesta un
2402minuto (§6.26). Con `tejido` eso es exactamente lo que NO hay que hacer, y el README del propio
2403tejido lo dice: *«la clave que el roster atesta ES la identidad de transporte libp2p»*
2404(`~/.tejido/device.seed`). Dos máquinas con la misma semilla no son dos réplicas del mismo servicio:
2405son **el mismo PeerId en dos sitios**, o sea dos impostores mutuos para el resto de la flota.
2406
2407⇒ `tejido` se **intercambia**: se apaga allá, se enciende acá, en ese orden. Está todo listo para el
2408intercambio —binario, cuenta `tejido` (964), identidad instalada 700 en `/var/lib/tejido/.tejido/`—
2409y su Card vive en `cards.d` pero **no en el `genesis`**, para que un reinicio no lo encienda solo.
2410
2411Y arrastra a otro: `willay-crosscheck` **no es independiente**. Corriendo su línea a mano:
2412
2413```
2414Error: no hay roster en /root/.tejido/roster.postcard — emparejá primero (`tejido serve` / `tejido join`)
2415```
2416
2417Vive dentro de la red de tejido, así que hereda su condición. Se enciende en el mismo movimiento.
2418
2419#### Lo que cada guarda evita
2420
2421- `thasnuna`: su `INSTALAR.md` —escrito hoy por el frente tawasuyu para esta misma mudanza— pide
2422 tres cosas, y dos no están: `sandokan-mcp` en el PATH («el agente contesta pero no tiene
2423 herramientas») y **`claude` instalado y AUTENTICADO** («no hay anfitrión»). El CLI de claude es un
2424 binario **glibc de ~300 M**: en una caja musl pide jaula qorpa, como `sergioh-api`.
2425- Y de ahí sale un hallazgo que vale para el respaldo entero: ese documento explica por qué el token
2426 no va en la Card, y el motivo está medido en la máquina vieja — **la Card `openrc-openclaw` de
2427 gioser lleva la API key de su proveedor EN CLARO dentro del JSON de `/etc/arje/cards.d/`**, que es
2428 un directorio que se respalda y se copia. Un secreto dentro de una Card viaja a todas partes.
2429- `willay-crosscheck`: `--label` **nombra a la máquina**. En gioser decía `momento`; copiarlo tal
2430 cual habría hecho que la caja nueva se anunciara con el nombre de la que se borra. Ahora sale de
2431 `hostname`, y si no hay, la guarda lo dice.
2432
2433#### 🔁 Tres veredictos falsos en una tarde, los tres por probar con lo que la caja no tiene
2434
2435Van con el §6.38 y ya son patrón, no anécdota:
2436
2437| la prueba | lo que dijo | lo que pasaba |
2438|---|---|---|
2439| `/dev/tcp/host/puerto` | los 5 puertos de gioser «cerrados» | busybox `ash` no tiene `/dev/tcp` |
2440| `ls /store/*-{a,b}` | «los artefactos no llegaron» | busybox no expande llaves |
2441| `find … -newermt "-2 minutes"` | «tupu no escribe hace 2 min» | tupu **sí** escribe: su `mtime` avanza cada 10 s |
2442
2443El de `tupu` es el más instructivo porque casi produce un diagnóstico al revés: el fichero tiene
2444**tamaño constante** (es una serie de tamaño fijo), así que «no cambió de bytes» tampoco probaba
2445nada. Lo que decide es el `mtime`, medido dos veces con 40 s de por medio.
2446
2447### 6.40 🚪 Las ocho puertas, medidas de nuevo *(2026-09-16)* — y la que falta es UNA
2448
2449La tabla del §6.3 es del 10 de septiembre. Re-medida hoy, entera:
2450
2451| # | puerta | estado | medido |
2452|---|---|---|---|
2453| 1 | arranca takana puro, se entra por SSH | ✅ | sigue en pie |
2454| 2 | el store está entero | ✅ | **1632 artefactos, 0 vacíos** (eran 1362) · ⚠ `/store` al 88 %, 11,3 G libres |
2455| 3 | los cuatro grafos idénticos | ✅ | §6.7 |
2456| 4 | **la granja late en la caja nueva** | ❌ | **el latido sigue en gioser**: la caja no tiene el cron |
2457| 5 | el repo se sirve y el host se actualiza solo | ⬖ | sirve; consumir exige el lab entero (SDD 27 §4) |
2458| 6 | cada dominio vivo responde 200 desde fuera | ✅ | **los 8 contra `2.29.29.217`** — y `sergio` ya entre ellos |
2459| 7 | el respaldo corre desde la caja | ⬖ | el script **corre y lista** el Storage Box desde la caja; falta una corrida completa |
2460| 8 | lo fósil, anotado y decidido | ✅ | §6.9 + `docs/state/mudanza-decisiones.txt` |
2461
2462#### La puerta 4 es ahora una línea de crontab — y por qué no la puse
2463
2464La caja ya tiene **todo** lo que el latido necesita, comprobado uno por uno: `git`, `python3`,
2465`rsync`, `ssh`, `takana`, `flock`, la llave del worker en `/root/.ssh/github5` y el `.fleet` con
2466`dev.gioser.net`. Le faltaban dos costuras y están hechas:
2467
2468```
2469 /opt/takana/store -> /store (el script espera `./store`; acá es partición)
2470 /opt/takana/target/release/takana -> /usr/bin/takana (no hay árbol de build en una caja instalada)
2471```
2472
2473Y el repo de `/opt/takana`, que estaba **5 días atrasado**, quedó en `origin/main` exacto (0
2474diferencias contra el remoto), con un tar de respaldo de los 92 ficheros que el árbol tenía antes.
2475⚠ Esos 92 no eran trabajo local: eran **contenido que ya estaba río arriba** —el cambio de SSH a
2476HTTPS de las recetas de tawasuyu, entre otros— metido en el árbol sin commitear. Un árbol «sucio»
2477que en realidad está *atrasado*, que es el mismo espejismo que el §5 del informe de tawasuyu
2478describe para el monorepo.
2479
2480Prueba de sólo lectura desde la caja, que es lo más lejos que se puede llegar sin cambiar nada:
2481
2482```
2483 ▶ dev.gioser.net (154.197.1.13) load: 2.72 · store: 895 artefactos
2484 ══ AVANCE KDE ══ 197/198 sellado
2485 ══ CRON DE COSECHA ══ ⚠ NO instalado en el crontab
2486```
2487
2488**No lo instalé, y el motivo es el mismo que el de `tejido`**: con el cron puesto en las dos
2489máquinas, las dos harían `rsync --delete` del repo al worker y las dos cosecharían y commitearían.
2490El latido **se intercambia, no se duplica** — se apaga en gioser y se enciende acá, en ese orden, y
2491es el último movimiento antes del borrado.
2492
2493⇒ **de las ocho, una sola está en rojo, y es una decisión de corte, no trabajo pendiente.**
2494
2495### 6.41 🔀 INTERCAMBIO de `tejido` — la identidad cambió de máquina, no de dueño *(2026-09-17)*
2496
2497Hecho, y en este orden, que es el único posible: **apagar allá → encender acá**.
2498
2499```
2500 gioser tejido relay (964) · tejido serve (29240) · willay-crosscheck (15334) → detenidos
2501 takana tejido 4102 · willay-crosscheck 4103 → corriendo
2502```
2503
2504**La prueba de que la identidad VIAJÓ y no se generó otra** no es que el servicio arranque —eso
2505pasaría igual con semillas nuevas, y sería el fallo silencioso que esto existe para evitar— sino que
2506la semilla sea la misma:
2507
2508```
2509 device.seed gioser cad6f35b633e8637… caja cad6f35b633e8637… ✓ idéntica
2510 roster.postcard gioser 590f2713075ac934… caja 590f2713075ac934… ✓ idéntica
2511```
2512
2513El `PeerId` sale de esa semilla, así que sigue siendo `12D3KooWBw2u8mt2ciUjX69qpVAZiJZ8sZMGxz8eHJEnz4rzg37L`.
2514
2515#### ⚠ LO QUE SÍ CAMBIA, Y HAY QUE TOCARLO A MANO: el multiaddr
2516
2517Los clientes tienen configurada la dirección COMPLETA del relay, IP incluida — se leyó del proceso
2518que corría en gioser:
2519
2520```
2521 antes: /ip4/204.168.193.248/tcp/4102/p2p/12D3KooWBw2u…
2522 ahora: /ip4/2.29.29.217/tcp/4102/p2p/12D3KooWBw2u… ← mismo PeerId, otra IP
2523```
2524
2525Un cliente con el viejo no falla «mal»: reintenta contra una IP que pronto no existirá. **El PeerId
2526no hay que tocarlo; la IP sí, en cada equipo del roster.**
2527
2528#### 🧱 Sin el cortafuegos, el intercambio habría sido un verde falso
2529
2530El reglaset de la caja abría `80, 443, 1137, 2345, 22022` **y nada más**: `4102` estaba cerrado. Con
2531el relay encendido y el puerto filtrado, `arjectl status` diría «corriendo · 0 reinicios» y la flota
2532no llegaría — el peor de los verdes. Se abrieron `4102` (relay) y `4103` (crosscheck), con su ban
2533por tasa como el resto. **No se abrió `33097`**: ése era el puerto efímero de un `tejido serve`
2534(cliente), no un servicio que alguien busque.
2535
2536Y el reglaset quedó **idempotente**, que era deuda del §6.33: sus dos primeras líneas crean y borran
2537la tabla antes de definirla, así que `nft -f` **reemplaza** en vez de acumular. Comprobado contando:
253815 reglas `dport` antes, 21 después (no 36).
2539
2540⚠ **La política que genera ese fichero NO EXISTE EN NINGÚN DISCO.** Su cabecera dice «GENERADO, no
2541editar a mano — regenerar con `cortafuegos generate-input --policy <ruta>`», pero esa ruta no está
2542ni en la caja, ni en gioser, ni en el repo (sólo dos `politica_*_ejemplo.ron` en tawasuyu), y el
2543binario `cortafuegos` tampoco está instalado en ninguna de las dos. **El generado sobrevivió a su
2544fuente**: hasta que la política se escriba y se versione, esto se edita a mano — justo lo que su
2545primera línea pide no hacer.
2546
2547#### 🆔 `takana` acepta ULIDs que `arje-zero` RECHAZA
2548
2549La Card de tejido no encarnaba: `arje-zero rechazó: card tejido JSON: invalid character at line 7`.
2550La línea 7 es el `id`, y el id era `01M2EKDA00TEJ1D0RELAY00001` — que tiene una **`L`**, carácter
2551**excluido del alfabeto Crockford** de ULID (junto con `I`, `O`, `U`). `takana service-cards` lo
2552validó como bueno («26 caracteres alfanuméricos») y el consumidor lo tiró.
2553
2554Dos cosas de esto: el validador del PRODUCTOR es más laxo que el del consumidor —y eso siempre
2555termina en un fallo lejos de donde se escribió—, y el barrido propio que ya corrí sobre todos los
2556`id` del repo con el alfabeto correcto había marcado justo ése. Era el único con `L` (venía de
2557«RELAY»); ahora es `01M2EKDA00TEJ1D0RE1AY00001`.
2558
2559#### Estabilidad, medida y no supuesta
2560
2561`willay-crosscheck` marcaba **4296 reinicios**, que asusta hasta mirar de dónde vienen: son las
2562horas en que su guarda lo frenó a propósito por falta de roster. Con el mismo pid a los 70 s y
25631 m 53 s de vida, está estable. `tejido`: 0 reinicios. Los dos puertos aceptan conexión desde fuera.
2564
2565⚠ De paso, un detalle feo: `arjectl status | head -2` hace que **arjectl paniquee** con
2566`failed printing to stdout: Broken pipe`. No rompe nada, pero un `EPIPE` sin manejar en una
2567herramienta de operación aparece justo cuando alguien la encadena con `head`/`grep -q`.
2568
2569#### Cómo volver, si hiciera falta
2570
2571Está escrito en `work/mudanza/volver-atras-tejido.txt`: apagar los dos de la caja y relanzar los tres
2572de gioser con las líneas exactas que se leyeron de `/proc/<pid>/environ` y `cmdline`. **Nunca las dos
2573a la vez**: es la misma identidad.
2574
2575### 6.42 ❌ El latido NO se puede mudar todavía — y el motivo redefine qué es un «hub» *(2026-09-17)*
2576
2577Se intentó el último intercambio: apagar el cron de la cosecha en gioser y encenderlo en la caja.
2578**Salió mal, se vio en el primer ciclo, y se volvió atrás en minutos.** Queda escrito porque el
2579motivo no era ninguno de los que se habían previsto.
2580
2581#### Lo que sí funcionó
2582
2583La caja tiene todo lo del latido y el ciclo corrió de punta a punta: sembró el repo al worker, leyó
2584su manifiesto, regeneró los ocho ficheros de estado, pasó los vigías, **se puso al día por
2585fast-forward y commiteó+empujó**. El `git config` de identidad y el `pull --ff-only` nuevo hicieron
2586su parte.
2587
2588#### 🕳️ Lo que publicó, que es el problema
2589
2590```
2591 totals que publicó la CAJA : {recipes: 1112, nodes: 1115, unhashable: 1112, ajeno: 3}
2592 totals de gioser : {recipes: 1112, nodes: 1115, sealed: 1105, never: 5, debt: 2}
2593```
2594
2595**`unhashable: 1112`** — no es «no está sellado»: es que **no se pudo CALCULAR el hash de ninguna
2596receta**. Y la causa es la misma que el §5.2 documenta desde el otro lado: **el lab entra en el
2597ArtifactHash**, así que una máquina sin el rootfs del lab no puede hashear nada. La caja de
2598producción no lo tiene — a propósito, no es un olvido.
2599
2600El daño era real y silencioso: el commit `45b5685a` dejó en `main` un `build-state*.json` que dice
2601que **el corpus entero no existe**. Cualquiera que lo lea —o cualquier vigía que lo compare— vería
26021112 recetas en cero.
2603
2604#### La lección, que vale más que el intento
2605
2606**Un hub no es «la máquina que tiene el repo y la llave»: es la que tiene el LAB.** El latido parece
2607tarea de cron —siembra, cosecha, commitea— pero su tercer paso es *pensar sobre el corpus*, y eso
2608exige el toolchain. Por eso la puerta 4 **no** era una línea de crontab, aunque todas las piezas que
2609se miraron (git, python3, rsync, ssh, takana, flock, `.fleet`, la llave) estuvieran.
2610
2611⇒ Las salidas son tres, y ninguna es «poner el cron»:
26121. **darle el lab a la caja** (`/.dev-fs/…`) — deja de ser sólo servidor y pasa a ser también hub;
26132. **partir el latido**: siembra+cosecha en la caja, regeneración del grafo donde haya lab;
26143. **que el hub sea otra máquina** (el LXC prestado ya tiene lab y muele 24/7).
2615
2616Es decisión del usuario, y es **lo único que queda entre esto y borrar gioser**.
2617
2618#### Vuelta atrás, en minutos
2619
2620Cron de la caja borrado, cron de gioser reactivado (estaba comentado, no borrado). El propio latido
2621de gioser **repara el daño solo** en su siguiente ciclo: regenera el grafo desde SU store —que sí
2622tiene el lab— y vuelve a publicar los números buenos.
2623
2624#### 🧰 Y de paso, tres cosas que el ciclo destapó en la caja
2625
2626- **`poda-fuentes.sh` no corre en takana**: `/dev/fd/63: No such file or directory` y
2627 `viejos: unbound variable`. Es **sustitución de procesos** (`<(...)`), que busybox `ash` no tiene —
2628 el cuarto tropiezo del día con la misma forma. El podador de `work/sources` es justo lo que un hub
2629 necesita para no llenarse.
2630- Los vigías corrieron y hablaron: **1 ofensor nuevo de raíces (`bzip2`)**, **3 herramientas
2631 selladas que no se pueden invocar**, y `servicios.txt` con 7 errores y 30 avisos. Son hallazgos del
2632 corpus, no de la mudanza, y quedan anotados donde el humano los mira.
2633- `arjectl status | head -2` **hace paniquear a arjectl** (`failed printing to stdout: Broken pipe`).
2634 No rompe nada, pero un `EPIPE` sin manejar en una herramienta de operación aparece justo cuando
2635 alguien la encadena.
2636
2637### 6.43 🧪 La caja ya es un HUB: el lab viajó, y con él la puerta 4 *(2026-09-17)*
2638
2639El §6.42 dejó dicho qué faltaba y el usuario eligió: **darle el lab a la caja**. Hecho, y el latido
2640ya late desde allá.
2641
2642#### El lab no se copia: se PINEA y se trae
2643
2644`scripts/lab-image.sh` empaqueta `.dev-fs/alpine` de forma **determinista** (`--sort=name
2645--mtime=@1 --owner=0 --group=0 --numeric-owner`, excluyendo `var/log/apk.log`, que es lo único que
2646difiere entre dos labs por lo demás iguales), lo publica al Storage Box con el sha en el nombre, y
2647del otro lado `--traer` **verifica el sha antes de extraer**. Eso es lo que hace que las dos máquinas
2648hasheen igual, y es un contrato, no una copia.
2649
2650**Y el empaquetado de hoy devolvió el sha que el repo ya pineaba:**
2651
2652```
2653 empaquetado hoy en gioser : d1e341d5dd434a11e2290b0340069ce4a83563eac8e4481f379b4951b1162045
2654 pineado en bootstrap-devfs.sh: d1e341d5dd434a11e2290b0340069ce4a83563eac8e4481f379b4951b1162045
2655```
2656
2657O sea dos cosas de una: **el lab de gioser nunca derivó** desde que se publicó esa imagen, y **el
2658empaquetado es reproducible de verdad** — no era una promesa del comentario.
2659
2660#### La prueba que decide, y no es que arranque
2661
2662Con el lab instalado, la caja calcula los MISMOS `ArtifactHash` que gioser:
2663
2664```
2665 zlib b3:dc363f26… busybox b3:2a2b1280…
2666 caddy b3:c915987d… shuma-daemon b3:f9b92acc…
2667```
2668
2669Cuatro de cuatro. Si el lab fuera otro, estos números serían otros y el store no lo notaría — es el
2670agujero que `hash_inputs` cerró (§lab en el hash) y la razón por la que esto se verifica con hashes
2671y no con un «arrancó bien».
2672
2673#### Los stores, convergidos — y una trampa que me tendí solo
2674
2675El grafo seguía discrepando porque el store de la caja no tenía 24 artefactos vigentes de gioser
2676(3,0 G). Al copiarlos con `rsync -a --files-from=<lista de DIRECTORIOS>` pasó lo peor posible:
2677
2678```
2679 sent 2,281 bytes … total size is 0 ← no copió NADA
2680 artefactos en la caja: 1631 → 1655 ← pero creó los 24 DIRECTORIOS
2681```
2682
2683**`--files-from` no recursa sin `-r`**: creó 24 directorios vacíos en el store. Y un directorio vacío
2684en el store **es un cache-hit** (§3 de CLAUDE.md, [[artefacto-vacio-envenena-cache]]): `build` lo
2685habría dado por sellado y habría salido OK sin construir. Se detectó al contar, se borraron los 24 y
2686se repitió con `-r`: 3,18 GB transferidos, **0 vacíos de 1655**.
2687
2688Después faltaban dos más (`obs-studio` y `spectacle`, justo los que el worker no logra construir),
2689copiados también. Resultado:
2690
2691| | gioser | caja |
2692|---|---|---|
2693| corpus | sealed 929 · debt 2 | **sealed 930 · debt 1** |
2694| KDE | sealed 1105 · debt 2 | **sealed 1106 · debt 1** |
2695
2696La caja no empata: **gana por uno** en los dos grafos.
2697
2698#### El latido, mudado
2699
2700Cron apagado en gioser, encendido en la caja, y un ciclo completo corrido a mano para mirar lo que
2701publica: `==> repo al día (ff)` → `==> estado commiteado+pusheado`, con los números buenos. El
2702`build-state` que hay en `main` ahora lo escribió la caja.
2703
2704⚠ **Lo que queda apretado es el disco**: `/store` de la caja está al **91 %, 8,2 G libres**. Un hub
2705sella y cosecha, así que ése es el próximo muro — `scripts/store-gc.sh` es la herramienta y todavía
2706no se corrió allá.
2707
2708⇒ **puerta 4 en verde.** Con eso, de las ocho quedan sólo las dos a medias (5 y 7) y ninguna en rojo.
2709
2710### 6.44 🧹 Primer `store-gc` en la caja: 26,8 G — y dos bugs que sólo salen fuera de GNU *(2026-09-17)*
2711
2712El store estaba al **91 %** (8,2 G libres) justo cuando la caja pasó a ser hub, que es la peor
2713combinación: un hub sella y cosecha.
2714
2715```
2716 antes: 84,7 G usados · 8,2 G libres · 91 % · 1657 artefactos
2717 después: 57,9 G usados · 35,0 G libres · 62 % · 1320 artefactos
2718```
2719
2720**337 artefactos superados borrados y verificados (0 sobrevivientes), 26,8 G.** El default del gc no
2721toca los **150 huérfanos** —`11,4 G`, los que son el único ejemplar de su nombre— y eso está bien:
2722borrarlos es la diferencia entre «se reconstruye en dos minutos» y «hay que rehacer la torre».
2723
2724#### El control que hay que correr DESPUÉS de un gc en esta caja, y que no es obvio
2725
2726**11 binarios de `/usr/bin` son symlinks que apuntan DENTRO del store** — los daemons que se
2727instalaron estos dos días. Un gc que borre el artefacto equivocado no rompe el store: rompe el
2728`/usr/bin` de una máquina en producción. Antes de `--aplicar` se comprobó que los 11 enlazan al hash
2729**vigente** (y por lo tanto están en el conjunto protegido); después, que los 11 siguen resolviendo y
2730que los 21 entes siguen corriendo. Los dos controles pasaron.
2731
2732⚠ Y la advertencia que el propio gc imprime y que en esa caja **no se puede satisfacer**: «sin
2733`.config` legible (ni `/proc/config.gz` ni `/boot/config-…`) ⇒ NO se protege ningún kernel por esta
2734vía». Con el default da igual; con `--huerfanos` en una máquina que arranca de su store, no.
2735
2736#### Los dos números que el gc no sabía decir
2737
2738Funcionó, pero sus dos cifras salieron vacías — y son las que uno mira para decidir si vale la pena:
2739
2740```
2741 ==> espacio: superados · huérfanos
2742 ==> 337 artefactos borrados y VERIFICADOS · libres: Available → Available
2743```
2744
27451. **`du -sch --files0-from=-` es de GNU y busybox no lo tiene** ⇒ `espacio()` devolvía vacío. *Un
2746 número que falta se lee como un número chico.*
27472. **`df -h /home` estaba cableado** y el store no vive ahí: en gioser es un bind-mount del volumen,
2748 en la caja es `/store`. Sin `/home`, `tail -1` se quedó con la CABECERA — de ahí
2749 «Available → Available».
2750
2751Arreglados los dos… y el primer arreglo **también estaba mal**: `xargs -d '\n'` es otra extensión
2752GNU. Eso imprimió `huérfanos ?`, y ese `?` es deliberado: cuando el total no se puede calcular, la
2753función lo DICE en vez de escribir 0 — un cero inventado habría dicho «no hay nada que ganar» con
275411,4 G en huérfanos. Con `tr '\n' '\0' | xargs -0`, que busybox sí tiene, la caja ya contesta
2755**`espacio: superados 0 · huérfanos 11.4G`**.
2756
2757⇒ Van **cinco** tropiezos del mismo día con la misma forma (`/dev/tcp`, expansión de llaves,
2758`find -newermt`, sustitución de procesos, y estos dos). El patrón ya no es anécdota: **un script del
2759hub escrito en una máquina GNU no corre en la caja hasta que se prueba ahí.**
2760
2761### 6.45 🧯 `poda-fuentes` tampoco corría — y la causa no era el script: **la caja no tiene `/dev/fd`** *(2026-09-17)*
2762
2763El latido, desde la caja, moría así en su paso de poda:
2764
2765```
2766 poda-fuentes.sh: line 72: /dev/fd/63: No such file or directory
2767 poda-fuentes.sh: line 73: viejos: unbound variable
2768 ⚠ poda de fuentes falló (rc=1) — sigo
2769```
2770
2771El segundo error es consecuencia del primero (el `mapfile` nunca corrió) y el primero **no nombra la
2772causa**: la sustitución de procesos de bash (`<(...)`) necesita `/dev/fd`, y **una caja takana no lo
2773tiene**. gioser sí: `/dev/fd -> /proc/self/fd`. O sea que no era este script: **ningún `<(...)` de
2774ningún script del hub funcionaba allá**, y éste fue el primero en toparse.
2775
2776Por eso los arreglos son dos, y los dos hacían falta:
2777
27781. **En la caja**: `/dev/fd -> /proc/self/fd`, con una Card **OneShot** en el `genesis` para que
2779 sobreviva al reinicio (como la de `hostname`). Comprobado después:
2780 `bash -c 'cat <(echo funciona)'` responde. ⇒ *lo correcto a futuro es que lo haga el init o el
2781 product-rootfs, no una Card.* Van dos parches de esta forma; es una lista que conviene no alargar.
27822. **En el script**: fuera `<(...)` (fichero temporal) y fuera `df -B1 --output=avail`, que es GNU —
2783 con `df -k` + awk. Sin eso el script corría pero decía **`libres 0.0 G`**, porque el `df` fallaba
2784 en silencio y el 0 se lee como un disco lleno.
2785
2786Con las dos cosas, la poda hizo su trabajo por primera vez en la caja:
2787
2788```
2789 2 árbol(es) por encima del suelo · borrados 2 · libres 46.1 G · LIBERADO 5.4 G
2790```
2791
2792⇒ **En total, 32,2 G recuperados hoy en la caja**: 26,8 G de artefactos superados (§6.44) y 5,4 G de
2793árboles de fuentes. `/store` al 62 %, `/work` al 29 %.
2794
2795### 6.46 🚪 Puerta 5 verde: la caja publica su repo firmado **y se instala de él** *(2026-09-17)*
2796
2797La puerta 5 estaba a medias desde el §5.4 y el motivo era el de siempre: *el host no se puede
2798actualizar de sí mismo porque `install` reproduce desde fuente y eso exige el LAB*. Con el lab ya
2799instalado (§6.43), se cerró en dos movimientos, los dos corridos **en la caja**:
2800
2801**1. Publicar** — con su propia clave de release, la que se mudó el 2026-09-16 a
2802`/root/.config/takana/keys/`:
2803
2804```
2805 ==> ✓ el índice verifica contra ./trust
2806 publicado: 171 con expected_hash anclado, 3 sin ancla. FALLARON: os-release
2807```
2808
2809**2. Instalar de ese repo, en modo estricto** (`--require-signed`, que exige autoría del catálogo
2810verificada y no se conforma con que el `.swm` reproduzca):
2811
2812```
2813 release: trusted (by release)
2814 install duf 0.9.1 ← dist/repo/duf-0.9.1.tkn
2815 deps: resolviendo catálogo para 1 dep(s): go
2816 caché: artefacto ya en el store hash=b3:abb3527d… name=duf
2817 apply OK — source_patch=1 config_edit=0 init_rule=0 file_drop=0
2818 registrado duf (2 fichero(s))
2819```
2820
2821Se instaló bajo `--prefix /tmp/prueba-install` y con `--db` propio, para no tocar el sistema.
2822
2823⚠ **Y el matiz honesto, que vale más que el verde**: el artefacto **ya estaba en el store**, así que
2824el camino que se ejercitó fue *resolver + verificar firma + hidratar*, **no** *reproducir desde
2825fuente*. Lo que el lab destrabó y sí quedó probado aparte es el **hash** (§6.43: cuatro de cuatro
2826iguales a gioser), que era exactamente donde moría antes —«no pude leer el apk db del lab»—. Queda
2827sin ejercitar el caso «paquete que NO está en el store», que en una caja de producción además es
2828discutible que se quiera: un servidor no tiene por qué compilar.
2829
2830⇒ `os-release` es la única receta del perfil que no se pudo publicar; es la que lleva el logo y la
2831identidad de la distro, y su fallo queda anotado para mirarlo aparte.
2832
2833### 6.47 🚪 Las ocho, al cierre del 2026-09-17
2834
2835| # | puerta | estado |
2836|---|---|---|
2837| 1 | arranca takana puro, se entra por SSH | ✅ |
2838| 2 | el store está entero | ✅ **1320 artefactos, 0 vacíos** tras el gc · `/store` al 62 % |
2839| 3 | los cuatro grafos idénticos | ✅ |
2840| 4 | **la granja late en la caja** | ✅ **§6.43** — con el lab pineado; la caja gana por uno en los dos grafos |
2841| 5 | **el repo se sirve y el host se instala de él** | ✅ **§6.46** — 171 paquetes publicados y `install --require-signed` en verde |
2842| 6 | cada dominio vivo responde 200 | ✅ los 8 |
2843| 7 | el respaldo corre desde la caja | ✅ **§6.48** — corrida completa, 0 errores, y **0 artefactos de la caja sin respaldar** |
2844| 8 | lo fósil, anotado y decidido | ✅ |
2845
2846⇒ **LAS OCHO EN VERDE** (§6.48 cerró la última). Lo que separa a esto del borrado de gioser ya no es
2847técnico: es la decisión del usuario, que es como el §6 dice que tiene que ser — a mano, con las ocho
2848en verde, **nunca por automatización**.
2849
2850Y lo que queda vivo en gioser es el trabajo de la mudanza, no servicios: los ~10 G de árboles
2851personales de `/home` sin decidir (§6.35) y el montón de `[[datos]]` que el censo dejó sin decisión.
2852
2853### 6.48 ✅ Puerta 7: el respaldo corre desde la caja — y el parcial que la envenenaba *(2026-09-17)*
2854
2855```
2856 respaldados (manifiesto del Storage Box) : 3686
2857 en el store de la caja : 1320
2858 de la caja, NO respaldados : 0 ← la cuenta que decide
2859 errores y reintentos en la corrida : 0 y 0
2860```
2861
2862**Las ocho puertas quedan en verde.**
2863
2864#### ⚠ Pero la primera corrida NO terminó, y el motivo vale por sí solo
2865
2866Se cayó **40 veces seguidas con el MISMO fichero**:
2867
2868```
2869 open ".../fonts/dejavu/.rsync-partial/DejaVuSans-Oblique.ttf" failed: No such file… (2)
2870 .. store: corte de red (rsync 23). Intento 39; reanudo en 60s.
2871 !! store: 40 intentos y sigue cayéndose. Dejo lo subido y paro.
2872```
2873
2874No era red. Una transferencia interrumpida **el 11 de septiembre** había dejado ese parcial en el
2875destino con el modo del origen —`-r--r--r--`, porque el store es de sólo lectura por diseño— y
2876**ningún intento posterior puede reescribirlo**. El fallo es ETERNO: esa ruta quedaba envenenada
2877para siempre, y el bucle la golpeaba cada 60 segundos llamándola «corte de red». Es exactamente la
2878pared que la cabecera de esa función dice que no hay que golpear cuarenta veces.
2879
2880Dos arreglos, y el segundo importa más que el primero:
2881
28821. **`--chmod=Fu+w`** en el rsync: los ficheros del respaldo quedan escribibles por su dueño, así que
2883 un corte a mitad se RETOMA en vez de trabarse. El precio —no conservar el bit de sólo-lectura en
2884 la copia— es bajo: lo que se respalda es el contenido, y los permisos los reconstruye el store.
28852. **Al `rsync 23` se le dan TRES intentos, no cuarenta**, y al tercero se NOMBRA la causa probable.
2886 El 23 es «some files were not transferred», que tanto puede ser un cable como una pared; tratarlo
2887 siempre como cable es lo que convirtió un fallo permanente en cuarenta minutos de ruido.
2888
2889#### 🪤 Y dos veces el mismo error mío: `pgrep -f <patrón>` se encuentra a SÍ MISMO
2890
2891Para saber si el respaldo seguía vivo usé `pgrep -f respaldo-storagebox`… y el patrón está en la
2892línea de comando del propio `pgrep` (y del `ssh` que lo lanza). Resultado: **decía «sigue corriendo»
2893para siempre**, incluso con el script muerto hacía rato — y el vigía que armé con esa condición
2894nunca podía dispararse. Pasó dos veces en la misma tarde, en las dos máquinas.
2895
2896La forma correcta es el truco del corchete —`ps ... | grep "[r]espaldo-storagebox"`—, que no coincide
2897consigo mismo porque el patrón literal `[r]espaldo` no aparece en la línea del grep. Es hermano del
2898`pkill -f` que mata tu propia shell, ya anotado en las memorias.
2899
2900### 6.49 📋 Lo único que queda: 150 decisiones sobre datos *(2026-09-17)*
2901
2902Con las ocho puertas en verde, de la mudanza no queda trabajo técnico: queda **decidir**. La hoja
2903está en `docs/state/mudanza-decisiones-pendientes.txt` — 150 entradas, **31,9 G**, ordenadas por
2904tamaño, con lo que la herramienta se anima a sugerir por un HECHO entre corchetes y **en blanco lo
2905que sólo sabe el dueño**:
2906
2907```
2908 /home/sergio/.claude 6.8G [ ] lo más nuevo: 2026-09-16
2909 /home/sergio/.local 6.2G [muda ] lo usa act_runner, tejido, thasnuna
2910 /var/lib/swap 6.1G [muere] (es swap)
2911 /home/sergio/.cache 4.3G [muere] caché
2912 /var/lib/gitea 1.9G [ ] ← ya mudado en el §6.14; la entrada es un fósil del censo
2913 /home/sergio/imm 200M [ ] lo más nuevo: 2026-03-23
2914```
2915
2916Se aplica en una pasada con `planear.py --decidir`, que ya no necesita teclas unitarias (§3 bis).
2917
2918⚠ Y la hoja **dice qué no cubre**, porque una lista titulada «lo que falta» que omite 329 G se lee
2919mal: no están `/mnt/vvv` —el monorepo, este repo, el store, `rustup`— ni los servicios y dominios.
2920Lo de `/mnt/vvv` no necesita decisión: **el store está respaldado (puerta 7) y los repos viven en el
2921gitea de la caja**.
2922
2923#### Lo último que se rescató antes de cerrar
2924
2925`/mnt/vvv/gioserv` tenía **26 entradas sin commitear** y su remoto era
2926`/var/lib/gitea/repositories/sergio/gioserv.git` — una ruta LOCAL de la máquina que se borra. Lo
2927commiteado está a salvo (su `HEAD` es el mismo que el del gitea nuevo); lo que no estaba en ningún
2928lado —el `git diff HEAD` completo (`api/main.py`, +92/−23, y 25 borrados) más los 4 no rastreados—
2929quedó en `takana:/work/mudanza-secretos/gioserv-pendiente/`, verificado: **0 ficheros del origen
2930faltan en el destino**.
2931
2932*No se reapuntó el remoto ni se commiteó nada*: cambiar el remoto de un clon ajeno y decidir si ese
2933`api/main.py` se publica es del dueño del repo, no de la mudanza. El `LEEME.txt` del paquete lleva el
2934comando exacto para reapuntarlo.
2935
2936### 6.50 🤖 El agente corre en la caja — y puede construir *(2026-09-17)*
2937
2938Pedido del usuario, y es la condición que él mismo puso para borrar gioser: *«no borramos gioser
2939hasta tenerte corriendo de aquel lado, con capacidad de compilar tawasuyu y las recetas de takana»*.
2940
2941```
2942 $ claude -p "Decí exactamente: CLAUDE CORRIENDO EN LA CAJA"
2943 CLAUDE CORRIENDO EN LA CAJA
2944```
2945
2946Eso es un turno REAL —API, credenciales, respuesta— desde `2.29.29.217`.
2947
2948#### Por qué va enjaulado, y qué se le concedió
2949
2950El CLI es un **ELF glibc de 360 M** (`interpreter /lib64/ld-linux-x86-64.so.2`, `NEEDED libc.so.6`)
2951y la caja es musl: no hay camino nativo. Es el caso del ADR 0015, el mismo de `sergioh-api`. La
2952instancia `claude` declara, y **conviene decir que es ANCHA en vez de disimularlo**: red, `nesting`,
2953y seis directorios —`/opt/takana` (el trabajo), `/work/dev-fs` (lab + zig/go), `/store`,
2954`/root/.claude` (memoria y credenciales), `/root/.ssh` (ro) y el CLI (ro)—. Un agente que construye,
2955commitea y empuja necesita lo mismo que un humano haciendo ese trabajo; lo que la jaula compra es
2956que ese alcance esté **escrito y acotado**, no que sea pequeño.
2957
2958⚠ El `takana` que construye **no se instala adentro**: sale del store, que ya está concedido. Es
2959estático musl y corre igual dentro de una imagen glibc — comprobado (`takana 0.0.1`).
2960
2961#### La caja construye: dos recetas selladas hoy
2962
2963Antes faltaba una pieza que el lab no traía: **`.dev-fs/tools`** (zig 0.13/0.16 y go, 1 G). El
2964primer intento murió con `zig no encontrado en .dev-fs/tools/zig/zig` — la imagen del lab empaqueta
2965`alpine/` y **nada más**. Copiado eso:
2966
2967```
2968 intel-ucode → sellado: 156 signatures + GenuineIntel.bin (17 MB)
2969 sof-firmware → sellado: 2 firmware + 8 topologías (IPC3 v2.2, TigerLake)
2970```
2971
2972#### 🧱 Lo que NO funciona, y su rodeo
2973
2974**`takana build` NO corre DENTRO de la jaula**, aunque la instancia declare `nesting = true`:
2975
2976```
2977 bwrap: Can't mount proc on /proc: Operation not permitted
2978```
2979
2980Y no es que el anidamiento esté roto: **un `bwrap --dev-bind / / --proc /proc` a mano SÍ funciona
2981adentro**, con y sin `--unshare-pid`. Lo que falla es el userns anidado que arma el sandbox del
2982build. Probado también con `root = false` —la sospecha que el propio código documenta (§`grants.root`
2983⚠ del 2026-09-03)— y falla igual: no es el remapeo a root.
2984
2985El rodeo que sí anda, y quedó escrito en el lanzador para que el agente lo use:
2986
2987```sh
2988 ssh -p 22022 -i /root/.ssh/github5 root@127.0.0.1 \
2989 'cd /opt/takana && flock -o work/.farm-build.lock takana --store /store build <receta>'
2990```
2991
2992Con eso, **desde dentro de la jaula se selló `sof-firmware`**. El agente vive enjaulado y le pide
2993los builds al anfitrión, que es donde el sandbox del build tiene los permisos que necesita.
2994
2995#### Cómo se entra
2996
2997`claude` en el PATH de la caja (`/usr/bin/claude`), que envuelve
2998`takana qorpa run claude -- env HOME=/root …`. El manifiesto y el lanzador están versionados en
2999`scripts/servidor/`, porque una instancia que sólo existe en la caja se pierde con la caja.
3000
3001⚠ Pendiente menor: la memoria del agente está en `/root/.claude/projects/-mnt-vvv-takana/`, y allá el
3002repo vive en `/opt/takana` ⇒ **el índice por ruta no coincide**. Se resuelve renombrando el
3003directorio a `-opt-takana` o dándole al repo la misma ruta; hasta entonces el agente arranca sin su
3004memoria del proyecto aunque los 733 ficheros estén en disco.
3005
3006### 6.50 bis 🔑 La cuenta necesitaba sus LLAVES, no su contraseña *(2026-09-17)*
3007
3008Creada la cuenta, el primer intento del usuario falló:
3009
3010```
3011 $ ssh -i ~/.ssh/tawasuyu sergio@gioser.net -p 2345
3012 sergio@gioser.net: Permission denied (publickey).
3013```
3014
3015Y era exacto: **el `sshd` de la caja tiene `PasswordAuthentication no`**, así que la contraseña
3016`tawasuyu` sirve para `su` y para la consola, **no para entrar por SSH**. Lo que faltaba era su
3017`~/.ssh/authorized_keys`, que se creó vacío con la cuenta. Copiado el de gioser —dos llaves,
3018`tawasuyu` y `sergio@tatata`— entra:
3019
3020```
3021 $ ssh -i ~/.ssh/tawasuyu sergio@gioser.net -p 2345
3022 ENTRA como sergio en takana · /home/sergio
3023 $ claude -p "…" → ENTRÉ POR SSH Y ABRÍ CLAUDE
3024```
3025
3026Dos detalles que hacen que esto se sienta como la máquina de siempre: **`gioser.net` ya resuelve a la
3027caja**, y **la llave de host es la MISMA que la de gioser** (se copiaron en el cutover del gitea,
3028§6.25) — comprobado: `SHA256:ltSl+rgr2Uc…` en las dos. Por eso no aparece el aviso rojo de
3029«REMOTE HOST IDENTIFICATION HAS CHANGED» al entrar al nombre de siempre.
3030
3031⚠ El `sshd` escucha en **22022 y 2345**, los dos generales: `2345` es el puerto que los clones de
3032git ya usaban, y sirve igual para entrar.
3033
3034### 6.50 ter 🧰 `sudo` y el taller: dónde se programa en la caja *(2026-09-17)*
3035
3036**`sudo` no andaba por dos cosas a la vez, y una era el corte de energía.** `/usr/bin/sudo` **no
3037tenía el bit setuid** (`sudo: must be owned by uid 0 and have the setuid bit set`), y además
3038`/etc/sudoers.d/sergio` **había desaparecido**: lo escribí minutos antes del `reset` del §6.51 y se
3039fue con el mismo corte que dejó el cortafuegos en NULs. Repuestos los dos —y con `sync`—,
3040`sudo id` devuelve `uid=0(root)`. `visudo` no está instalado, pero **no hace falta**: el fichero
3041suelto en `/etc/sudoers.d/` es la forma correcta, y `sudo` lo valida solo.
3042
3043⚠ `doas` sigue dando `Operation not permitted` aun estando setuid. No hizo falta perseguirlo —`sudo`
3044resolvió— pero queda anotado como rareza sin explicar.
3045
3046#### Dónde están los repositorios
3047
3048**Los 44 están en la caja**, en el gitea que se mudó el 14-sep: `/var/lib/gitea/repositories/`
3049(`sergio/` 939 M, `tawasuyu/` 547 M). Lo que NO había era un **clon de trabajo**: sólo `/opt/takana`,
3050que es el del hub.
3051
3052```
3053 ~/src → /work/sergio ← el taller
3054 /work/sergio/tawasuyu 478 M ← clonado, origin al gitea de la caja
3055```
3056
3057⚠ **El taller va en `/work`, no en el home.** La raíz de esta caja tiene **2,4 G libres** y `/work`
3058**43 G**: un clon del monorepo en `/home` llena la raíz y tumba la máquina.
3059
3060⚠ **Y clonar acá tiene dos trampas medidas:**
30611. **El `git` del corpus no tiene `remote-https`** (`git: 'remote-https' is not a git command`), así
3062 que **no se puede clonar por HTTPS** desde la propia caja. Es la deuda ya anotada del §bloqueantes.
30632. Clonar por **SSH** (`ssh://gitea@git.gioser.net:2345/…`) exige que la llave esté registrada **en
3064 la cuenta de gitea**, no basta con el `authorized_keys` del sistema. Hasta que se registre, el
3065 camino es el **sistema de ficheros** (`git clone /var/lib/gitea/repositories/<org>/<repo>.git`) —
3066 con dos detalles: el directorio de cada organización es `0700` del usuario `gitea`, así que hay
3067 que clonar como root y `chown` después; y git rechaza el repo por `dubious ownership` hasta que se
3068 le dice `git config --global --add safe.directory "*"`.
3069
3070Y el agente se abre sobre cualquiera de ellos:
3071
3072```
3073 PROY=/work/sergio/tawasuyu claude
3074 → «Es tawasuyu (/work/sergio/tawasuyu, origin git.gioser.net:2345/…), último commit 55e5f0f27»
3075```
3076
3077### 6.50 quater 📦 Cómo se instala software de tawasuyu en la caja — y por qué NO con `actualizar-servidor.sh` *(2026-09-17)*
3078
3079Pregunta del usuario: *«¿ahí tengo la confianza de `install-tawasuyu` y `actualizar-servidor`? ¿o
3080cómo es la forma de instalar, por ejemplo, `shuma-tui`?»*
3081
3082**Esos guiones existen y siguen ahí** —el monorepo está clonado en `/work/sergio/tawasuyu`— pero lo
3083que hacen es:
3084
3085```
3086 cargo build --release <crates> …y después… install -m755 <nuevo> /usr/local/bin/<x>
3087```
3088
3089O sea: **producen exactamente la clase de binario que la mudanza encontró irreproducible** — 2,7 G
3090de sueltos que ningún paquete provee (§6.35), de los cuales tres corrían desde un inodo BORRADO.
3091Además `actualizar-servidor.sh` escribe servicios en `/etc/init.d/`, que en esta caja no existe: el
3092init es arje.
3093
3094#### La forma de acá, hecha de punta a punta con `shuma-tui`
3095
3096```
3097 1. receta recipes/shuma-tui.toml — pinneada al commit del monorepo, zig-cc, musl, estática
3098 2. build takana build ⇒ b3:f795ee0f… sellado en el store
3099 3. viaja worker → hub → caja (rsync del artefacto, que es content-addressed)
3100 4. instalar ln -s /store/<hash>-shuma-tui/usr/bin/shuma-tui /usr/bin/
3101 5. control shuma-tui --help → contesta
3102```
3103
3104Los pasos 3 y 4 son el atajo honesto de hoy; el camino completo es el del §6.46 —publicar en el repo
3105firmado y `takana install <nombre> --require-signed`—, que ya está probado y es lo que convierte
3106«copiar un binario» en «instalar un paquete».
3107
3108⚠ **El paso 2 NO se puede hacer en la caja todavía**, y el motivo es la deuda ya conocida: su `git`
3109**no tiene `remote-https`**.
3110
3111```
3112 git: 'remote-https' is not a git command
3113 Error: git ["clone","--mirror",…,"https://git.tawasuyu.net/…"] falló
3114```
3115
3116Las recetas del corpus que bajan tarballs con `curl` **sí** construyen ahí (hoy se sellaron
3117`intel-ucode` y `sof-firmware`); las que clonan por HTTPS —todas las de tawasuyu— hay que
3118construirlas en el worker, que sí tiene git completo. Arreglar eso es re-sellar `git` con libcurl, y
3119es raíz de `perfil.base`: unidad propia.
3120
3121### 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)*
3122
3123El §6.50 quater dejó anotado el muro: la caja no tiene `git-remote-http`, así que las 36 recetas que
3124clonan de `git.tawasuyu.net` —y las ~90 de GitHub— no se podían construir ahí. La salida es la que
3125pidió el usuario: **usar SSH**. Y sale gratis en hashes, porque **la URL es un LOCALIZADOR y no entra
3126en `hash_inputs`** (ADR 0013): el mismo commit por otro transporte sella el mismo artefacto.
3127
3128No se toca ninguna receta —el worker sigue clonando por HTTPS, que es lo que puede— sino la caja:
3129
3130```
3131 git config --global url."ssh://gitea@git.gioser.net:2345/".insteadOf "https://git.tawasuyu.net/"
3132 git config --global url."ssh://git@github.com/".insteadOf "https://github.com/"
3133```
3134
3135Tres cosas que costaron una vuelta cada una, las tres MEDIDAS:
3136
31371. **`takana` clona bien, pero `cargo vendor` clona aparte.** cargo honra el `insteadOf`, pero usa su
3138 propio cliente SSH: primero se plantó por la clave del host —la tenía como `[git.gioser.net]:2345`
3139 y cargo la busca **sin puerto**, misma clave reexpresada— y después por autenticación, porque no
3140 sabe leer `IdentityFile` de `~/.ssh/config`. Se resuelve delegando en el git de verdad:
3141
3142 ```toml
3143 # ~/.cargo/config.toml
3144 [net]
3145 git-fetch-with-cli = true
3146 ```
3147
31482. **La huella de `github.com` se PINEA, no se acepta a ciegas.** `ssh-keyscan` dio
3149 `SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU`, idéntica a la que GitHub publica, y **por eso**
3150 entró a `known_hosts`. La clave de esta caja autentica como deploy key de otro repo y aun así lee
3151 repos públicos ajenos: comprobado con `uutils/coreutils`.
3152
31533. **Y la que dolió: la raíz son 5,9 G y `cargo` la llenó.** `CARGO_HOME` estaba en `/root/.cargo`, o
3154 sea en `sda2`. El vendor del monorepo bajó 2,7 G, la raíz llegó al **100 %**, y la caja **no se
3155 degradó: se cayó entera** — sin HTTP, sin SSH y **sin responder al ping**, con Hetzner informando
3156 `running`. Hubo que entrar por rescate otra vez.
3157
3158 Lo que el disco lleno deja como rastro, y conviene saber leer:
3159
3160 ```
3161 caddy → «write error: write /var/log/caddy/requests.json: no space left on device»
3162 mis → /root/.ssh/config quedó con 105 BYTES NULOS al final: el append entró a medias
3163 escrituras (el mismo daño que el corte de luz le hizo al reglaset del cortafuegos, §6.51)
3164 ```
3165
3166 **Un `>>` que falla por ENOSPC no deja el fichero como estaba: lo deja extendido y relleno de
3167 ceros.** Es exactamente la clase de avería que el §3 de `CLAUDE.md` describe para los artefactos
3168 vacíos — llega hasta el final diciendo que todo fue bien.
3169
3170**Reparado en el rescate, y las tres piezas son permanentes:**
3171
3172| qué | dónde | por qué |
3173|---|---|---|
3174| `/root/.cargo` → `/work/cargo-home` | symlink | 2,7 G de caché no caben en una raíz de 5,9 G |
3175| 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** |
3176| `.ssh/config` y `.gitconfig` | reescritos | tenían NULs de las escrituras a medias |
3177
3178Tras el arranque: raíz al **54 %**, los 18 entes corriendo y **los 7 dominios de la caja en 200**
3179(`terapeuta.ec` sigue en gioser a propósito — se decidió respaldar, no mudar).
3180
3181> **La lección, que no es sobre cargo.** La raíz de esta caja es **5,9 G** y todo lo que crece sin
3182> dueño vive ahí: logs, cachés, spool. No hay margen para «ya lo limpio después», y el modo de fallo
3183> no es un error: es la máquina entera apagándose en silencio. Cualquier cosa que acumule bytes en la
3184> caja **se declara dónde vive antes de correrla por primera vez**.
3185
3186#### El control que cierra esto: la caja construyó una receta de tawasuyu de punta a punta
3187
3188`puriy-costura` era la única de las 36 que **no** estaba en el store de la caja — o sea, un fallo de
3189caché de verdad, no un cache-hit disfrazado de éxito ([[cache-congela-regresiones]] es justo esto).
3190La caja la hizo entera y sola: clonó por SSH (111,7 M de mirror), vendoreó, compiló y selló.
3191
3192```
3193 hash que predice el HUB b3:7d63655aa5fea3cbc08724887617d7f58b325fcb2e00ac050b1937966c2459e6
3194 hash que selló la CAJA b3:7d63655aa5fea3cbc08724887617d7f58b325fcb2e00ac050b1937966c2459e6
3195 contenido 2,2 M · usr/bin/puriy-costura · corre y muestra su ayuda
3196```
3197
3198**Idéntico**, que es lo único que prueba que el transporte no contamina el artefacto. Con esto la
3199caja cumple la condición que puso el usuario para poder borrar gioser —«con capacidad de compilar
3200tawasuyu y las recetas de takana»— **desde fuente y por su cuenta**, no por artefactos que le llegan
3201del worker.
3202
3203El guion `scripts/servidor/fuentes-por-ssh.sh` deja esto reproducible: idempotente, con la huella de
3204github pineada (si el host anuncia otra, **sale con error en vez de aceptarla**) y con un control
3205final que CLONA de los dos orígenes. Probados sus dos negativos: un repo inexistente lo hace fallar,
3206y una huella cambiada la rechaza.
3207
3208### 6.50 sexies ✅ Pagada la deuda: el `git` del corpus vuelve a clonar por HTTPS *(2026-09-17)*
3209
3210El §6.50 quinquies dejó la caja trayendo fuentes por SSH porque su `git` no tenía `remote-https`.
3211Eso era el síntoma; **la causa estaba un paso antes de donde todos mirábamos** —incluida la nota que
3212yo mismo había escrito, que culpaba al Makefile—.
3213
3214El tarball de git trae `configure`, y takana lo corre. Su test de libcurl es `AC_CHECK_LIB`, que
3215enlaza `conftest.c -lcurl` **y nada más**. Con libcurl **estática** eso no resuelve: faltan
3216`-lssl -lcrypto -lz`, que son sus privadas.
3217
3218```
3219 checking for SHA1_Init in -lcrypto... yes
3220 checking for curl_global_init in -lcurl... no ← acá se decidía todo
3221 checking for XML_ParserCreate in -lexpat... no
3222```
3223
3224El test falla, `config.mak.autogen` se lleva `NO_CURL=YesPlease`, el Makefile excluye
3225`git-remote-http`, `git-http-fetch` y `git-http-push` —**y conserva `git-http-backend`, que es el
3226lado servidor y no usa curl**: esa asimetría en el artefacto era la firma del fallo, y estuvo a la
3227vista desde el 2026-09-14—. El build **termina en verde**. Es el §3 de `CLAUDE.md` en su forma más
3228cara: un ausente falla ruidosamente, un vacío llega hasta el final diciendo que todo fue bien.
3229
3230**La cura, tres líneas en la receta**, cada una con su motivo:
3231
3232| línea | por qué |
3233|---|---|
3234| `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 |
3235| 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 |
3236| `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í |
3237
3238**Medido sobre el artefacto, nunca sobre el `git` del host** (`ls $(git --exec-path) | grep remote-http`):
3239`b3:215742cb…` trae `git-remote-http`, `git-remote-https`, `git-http-fetch` y los `ftp`. Y **clona**
3240—no `ls-remote`: `clone`, que es donde murió la vez del ubsan—: árbol en disco y `rev-list` contesta.
3241En la caja, hidratado y con la reescritura a SSH **apagada**, `git clone https://…` funciona, y
3242`git clone --mirror` —el comando exacto que usa `takana build` para traer fuentes— también.
3243
3244> **El radio, medido en vez de temido.** La nota vieja decía que arreglar esto «re-sella `git`, que es
3245> raíz de `perfil.base` ⇒ radio grande». `yupana radio git` dice otra cosa: **cero** dependientes
3246> directos y **cero** transitivos. Toca las 7 imágenes que lo incluyen —que es re-ensamblar, no
3247> reconstruir—. El miedo escrito a mano había sobrestimado el costo de arreglarlo, y eso lo mantuvo
3248> roto tres días.
3249
3250Las reescrituras `url.insteadOf` quedaron **retiradas** de la caja: ya no hacen falta.
3251`scripts/servidor/fuentes-por-ssh.sh` se conserva como salida de emergencia, no como el camino normal.
3252
3253### 6.52 🧩 Las proc-macros SÍ se pueden compilar en la caja — falta un `cc`, no un parche *(2026-09-18)*
3254
3255Con `rust` sellado, la caja compila y corre binarios **estáticos** sin tocar nada. Lo que no compilaba
3256es cualquier **dylib**, y eso incluye **todas las proc-macros** (`serde_derive`, `clap_derive`…), o sea
3257media ecología de Rust:
3258
3259```
3260 ld.lld: error: unable to find library -lgcc_s
3261 ld.lld: error: unable to find library -lc
3262```
3263
3264#### Por qué el `-L` obvio empeora las cosas
3265
3266La reacción natural es darle el camino: `-L /usr/lib`. **Y eso rompe los estáticos**, que hoy
3267funcionan. Cuatro controles lo aíslan:
3268
3269| | enlace | resultado |
3270|---|---|---|
3271| A | estático, sin `-L` | ✅ enlaza — es lo que hay hoy |
3272| B | estático, con `libgcc.a` a la vista | ✅ enlaza — el arreglo de `gcc-libs` no rompe nada |
3273| C | estático, con `-L /usr/lib` + `libgcc.a` | ❌ rompe |
3274| D | estático, **sólo** con `-L /usr/lib` | ❌ rompe ← la culpable |
3275
3276```
3277 ld.lld: error: relocation R_X86_64_32S cannot be used against symbol '__malloc_size_classes';
3278 recompile with -fPIC ← sale de /usr/lib/libc.a, que NO es PIC
3279```
3280
3281rustc enlaza musl **static-PIE** con su copia *self-contained*; meter `/usr/lib` en el camino le hace
3282preferir la `libc.a` del sistema, que no sirve para PIE. **El camino de librerías no puede ser
3283global: el estático lo quiere fuera y el dinámico lo quiere dentro.** Ningún `RUSTFLAGS` global
3284arregla esto — apaga un caso y enciende el otro.
3285
3286#### Lo que sí funciona, medido de punta a punta
3287
3288Quien sabe distinguir los dos casos es un **driver de C**. La caja no tiene `gcc` ni `clang`
3289—`clang18` en el store son sólo cabeceras y librerías, sin binario— **pero sí tiene `zig`**: el
3290artefacto `seed-zig` del bootstrap trae `zig 0.16.0` y **corre**. `zig cc` es un driver de C completo
3291con musl adentro.
3292
3293```
3294 cc → zig cc
3295 RUSTFLAGS → -C linker=cc -C linker-flavor=gcc -C link-self-contained=no
3296```
3297
3298Las tres banderas hacen falta y cada una por su motivo: `linker`+`linker-flavor` para que el enlace
3299pase por el driver, y `link-self-contained=no` porque si no rustc pide su propio `rust-lld` —que este
3300toolchain **no tiene**, ya que `rust.lld = true` es incompatible con el `llvm-config` externo (§ la
3301receta lo documenta)— y muere con *«the self-contained linker was requested… it wasn't found»*.
3302⚠ La variante fina `-C link-self-contained=-linker` **no sirve**: es inestable en este triple y exige
3303`-Z unstable-options`. La gruesa, `=no`, es estable.
3304
3305Con eso, la cadena completa que nunca había compilado:
3306
3307```
3308 1. la proc-macro ⇒ libpm.so
3309 2. el programa que la usa ⇒ imprime «PROC-MACRO VIVA»
3310 3. y el estático de siempre ⇒ sigue enlazando
3311```
3312
3313#### Entregado: `scripts/servidor/cc-por-zig.sh`
3314
3315El envoltorio existe y está puesto en la caja. **No mete nada nuevo en el corpus**: usa el `seed-zig`
3316que YA está en el store —producto del bootstrap (SDD 11), como `stage1-rootfs`— y sólo lo envuelve en
3317`/usr/bin/cc` y `/usr/bin/c++`, más las tres banderas en `/etc/profile.d/`. Volver a zig el
3318compilador de C **oficial** de la distro es otra cosa —ahí sí haría falta receta y pin propios— y es
3319decisión de ADR, no de un guion de puesta a punto.
3320
3321Es idempotente y sus cuatro controles preguntan por el HECHO:
3322
3323```
3324 ✓ C: C en takana ← compila y EJECUTA un hola mundo
3325 ✓ rust: proc-macro: 42 ← la macro enlaza, el que la usa corre
3326 ✓ rust estático (sin banderas): estático ok ← el remedio no rompió lo que funcionaba
3327 ✓ entorno: una shell de login trae RUSTFLAGS puesto
3328```
3329
3330Ese último control encontró algo de paso, y es la clase de cosa que este repo persigue: **en la caja
3331`/etc/profile.d` no lo leía NADIE**, porque `/etc/profile` no existía. El fichero de las banderas
3332habría quedado presente, con contenido y sin ningún efecto — y el `bash_completion.sh` que ya estaba
3333ahí llevaba quién sabe cuánto igual de mudo. Se creó el `/etc/profile` con el bucle estándar. La
3334caché de `zig cc` vive en `/work/zig-cache` (54 M) y **no** en la raíz de 5,9 G, por lo aprendido en
3335§6.50 quinquies.
3336
3337### 6.53 🔧 Borré `/usr/bin/id` probando el setuid *(2026-09-18)*
3338
3339Para saber si el bit setuid elevaba en esta caja copié `busybox` sobre **`/usr/bin/id`** —porque
3340busybox elige el applet por `argv[0]` y necesitaba un nombre válido— y después borré «mis» copias de
3341prueba. Una de ellas **era el `id` del sistema**. Resultado, del lado del usuario:
3342
3343```
3344 $ claude --dangerously-skip-permissions
3345 /usr/bin/claude: line 23: id: not found
3346 $ id
3347 -bash: /usr/bin/id: No such file or directory
3348```
3349
3350No quedaba ninguno: `/bin/id` tampoco existía. Se restauró como sus hermanos de identidad —`whoami`
3351y `groups` apuntan a `../../bin/busybox`— y se comprobó con `id` de root, de `sergio` y con el
3352`id -un` que usa el lanzador. Barrido posterior: **0 enlaces colgados** en `/bin`, `/usr/bin`,
3353`/sbin` y `/usr/sbin`, y presentes los ocho comandos de los que dependen el arranque y el lanzador.
3354
3355> **La lección, que es de método:** para probar una propiedad del sistema —¿eleva el setuid?— **no se
3356> usa un nombre que el sistema ya ocupa**. La sonda correcta era la que terminé escribiendo: cinco
3357> líneas de C compiladas con el `cc` nuevo a un nombre inventado (`probe-suid`). Copiar sobre `id`
3358> fue elegir el camino corto, y el camino corto se llevó un binario del que depende hasta el script
3359> que abre al agente. Es la misma familia que el `/etc/shadow` del §6.51: **la caja no avisa cuando
3360> le falta algo esencial — se entera el que lo usa**.
3361
3362### 6.54 🧭 Trabajar DESDE la jaula: lo que el agente de adentro reportó *(2026-09-18)*
3363
3364El agente enjaulado pasó un informe de defectos —el primero hecho **desde adentro**— y vale más que
3365cualquier inspección desde el anfitrión, porque son las cosas con las que se choca al usarla.
3366
3367#### Lo que se arregló, y dónde vive cada arreglo
3368
3369| # | defecto | dónde queda el arreglo |
3370|---|---|---|
3371| 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) |
3372| 2 | `/etc/ssh/ssh_config.d` es de la capa inferior, dueño fuera del mapa ⇒ `ssh` **aborta**, no degrada | `jaula-preparar.sh` (upper) |
3373| 3 | `~/.ssh` en `ro` ⇒ `ssh` no puede escribir `known_hosts` | **manifiesto**: pasa a `rw` + semilla desde el anfitrión |
3374| 4 | sin clave para el worker ⇒ `Permission denied (publickey)`, cero granja | clave **propia** de la caja autorizada en el worker |
3375| 5 | sin `rsync`/`python`/`jq`/`b3sum`, y sin `takana` ejecutable | **manifiesto**: `packages`; y un `takana` que sale del store |
3376
3377El **1 y el 2 viven en el `upper`**, que por el D3 es caché descartable: al primer `recreate` se
3378pierden. Por eso existe `scripts/servidor/jaula-preparar.sh`, que los repone —escribiendo como la
3379persona, no como root, para no dejarle ficheros que después no puede tocar—.
3380
3381Sobre el **4**: se autorizó en el worker la clave **de la caja** (`sergio@caja`), no la de root. Es
3382una credencial distinta y revocable: quitarla del `authorized_keys` del worker corta ese acceso sin
3383tocar ningún otro. Comprobado: `ssh root@dev.gioser.net hostname` desde la caja contesta `PruebasIA`.
3384
3385Sobre el **5**: `takana` **no se compila adentro**. El binario es el musl estático del store y corre
3386igual dentro de una imagen glibc; lo que fallaba es que
3387`/opt/takana/target/release/takana` del anfitrión es un enlace a `/usr/bin/takana`, y **adentro
3388`/usr/bin` es el de Arch**. Queda `/work/sergio/bin/takana`, que elige el más reciente del store —no
3389un hash cableado, para que sobreviva a un re-sellado— y el `target/release/takana` del clon apunta
3390ahí.
3391
3392#### Las tres trampas de orientación, que no son defectos pero cuestan una hora
3393
3394- **El store real es `/store`**, 61 G y 1333 artefactos. Los runbooks y el `CLAUDE.md` dicen
3395 `takana build --store ./store` porque están escritos para el HUB; copiado literal en la caja, eso
3396 apunta a un store vacío dentro del clon. Desde la caja va `--store /store`.
3397- **Hay dos checkouts y no son intercambiables**: `/work/sergio/takana` es el de trabajo —suyo, con
3398 push propio—, y `/opt/takana` es el del sistema: el que usan el cron, la granja y los servicios.
3399 Editar el segundo por costumbre es pisarle el árbol al latido.
3400- **`scripts/farm/.fleet` ausente NO es un defecto** —el propio informe lo retiró—: `flota-permanente`
3401 está versionado y `cosecha-cron` lo repone.
3402
3403### 6.55 🔓 «Una sola sesión» es del KERNEL; «un solo Claude» era nuestro *(2026-09-18)*
3404
3405El usuario chocó con `Resource busy` al abrir un segundo agente y lo llamó por su nombre: *«no quiero
3406restricciones arbitrarias»*. Tiene razón en la queja y conviene separar qué es qué, porque las tres
3407cosas se sienten igual desde afuera y son muy distintas:
3408
3409**1. Lo que impone el kernel.** Dos overlays sobre el **mismo `upper`** los niega `overlayfs`, no
3410nosotros: la capa mutable se corrompería. `qorpa` reintenta seis veces y después explica la causa en
3411vez de dejar el error crudo de bwrap. **Eso no se toca.**
3412
3413**2. Lo que era empaquetado nuestro** — y sí se toca: *una instancia por persona*. De ahí salía «un
3414solo Claude». Instancias distintas tienen `upper` distintos y conviven sin problema. Medido: crear la
3415segunda cuesta **0 s y 16 K**, porque la imagen se comparte de sólo lectura.
3416
3417**3. Lo que era un accidente**, y se arregló al encontrarlo:
3418
3419| | estaba | ahora |
3420|---|---|---|
3421| `/var/lib/hammer/qorpa/instances` | `root:root 755` ⇒ una persona **no podía crear su propia instancia** | `root:sergio 2775` (setgid) |
3422| `~/.ssh` en la jaula | `ro` ⇒ `ssh` no escribe `known_hosts` | `rw` |
3423| `/store` en la jaula | `ro` ⇒ el agente lee y **no puede sellar** | `rw` |
3424| `claude` | abría `/opt/takana` siempre | abre `$PWD` |
3425| `/usr/bin/claude` | **copia** congelada del guion | enlace al del repo |
3426
3427⚠ **Y queda un defecto de verdad, que hoy bloquea el punto 2**: aprovisionar una instancia nueva
3428muere con `bwrap: Can't mkdir parents for /run/user/0: Permission denied`. La causa está medida:
3429**esta caja no tiene `/run/user`** —no hay logind— y `qorpa.rs:1542` arma la ruta del runtime dir
3430como `/run/user/<uid>` sin alternativa. `XDG_RUNTIME_DIR` no alcanza: lo honra otra rama del código
3431(`1244`/`1549`), no ésta. Es arreglo en el crate, no en un manifiesto.
3432
3433> **Lo que conviene no confundir.** La jaula restringe al **agente**, no a la persona: `sergio` tiene
3434> `sudo`, entra por ssh y manda en la caja entera. Y dentro de la jaula el alcance es **declarativo**
3435> (D7): lo que no está en `grants` no se ve, pero agregarlo es editar un fichero, no pedir permiso.
3436> Lo indefendible no es que haya límites — es que un límite **accidental** parezca de diseño, que es
3437> exactamente lo que pasó con los cinco de la tabla.
3438
3439### 6.51 🔥 Me dejé afuera de la caja — 20 minutos caída, y tres causas encadenadas *(2026-09-17)*
3440
3441Crear una cuenta de usuario tiró el servidor de producción. Queda escrito entero porque **ninguna de
3442las tres causas era la que parecía**, y las tres siguen ahí para quien venga.
3443
3444#### 1. `/etc/shadow` no existía, y crearlo cerró el SSH de root
3445
3446La caja nunca tuvo `/etc/shadow`: todas las cuentas llevan `x` en `/etc/passwd` y entran por llave.
3447Para darle contraseña a `sergio` creé el fichero con **todas las cuentas bloqueadas (`!`)** y la suya
3448con su hash. Efecto inmediato: **`ssh` de root empezó a dar `Permission denied (publickey)`** con la
3449misma llave de siempre. Este `sshd` **rechaza la llave de una cuenta cuyo hash está bloqueado**.
3450
3451⇒ La forma correcta acá es la vieja: **el hash va en el campo 2 de `/etc/passwd`** y no hay
3452`/etc/shadow`. Así quedó, y así funciona `su - sergio`.
3453
3454#### 2. La caja NO reinicia por ACPI
3455
3456Con el SSH cerrado, `hcloud server reboot` (ACPI) **no hizo absolutamente nada**: arje-zero no
3457atiende esa señal. La web siguió sirviendo como si nada. Para un mantenimiento remoto eso importa:
3458**la única forma de reiniciar esta caja desde fuera es `reset`, que es un corte de energía.**
3459
3460#### 3. Y el corte de energía dejó el cortafuegos a medio escribir — eso fue lo que la aisló
3461
3462Tras el `reset` la caja **arrancaba** —los logs de arje lo probaban: gitea y caddy escribiendo— pero
3463**nadie llegaba**. La causa, encontrada mirando el fichero:
3464
3465```
3466 $ head -c 90 /etc/takana/cortafuegos-entrada.nft | od -c
3467 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
3468```
3469
3470**El reglaset era TODO NULs.** Se había escrito minutos antes del corte: ext4 journaló el tamaño y
3471los datos nunca llegaron al disco. Un fichero de 5 KB de ceros — o, peor y más probable en el primer
3472arranque, **medio fichero válido**: la tabla con `policy drop` y las reglas de `accept` cortadas.
3473Eso es exactamente una caja que arranca, corre todo, y no deja entrar a nadie.
3474
3475⇒ **Después de escribir algo que el arranque necesita, `sync` ANTES de cualquier `reset`.** Y el
3476corolario amargo: un `reset` no es un `reboot`, y lo que se perdió no avisa.
3477
3478#### Lo que el rodeo destapó, y vale más que el susto
3479
3480- **El cortafuegos NO se estaba aplicando en ningún arranque.** Su card sale 78 si `nft -c` falla, y
3481 con el fichero corrupto fallaba siempre: la caja llevaba días **arrancando sin filtrar**, en
3482 silencio, porque «no aplicar nada» es su modo seguro y nadie mira un 78 en un log de boot.
3483 Reparado el fichero, ahora el arranque deja **21 reglas `dport`**, comprobado tras un reinicio.
3484- **`netup` es DHCP-only y falló dos veces seguidas** («sin respuesta DHCP (tipo 2)»). Una caja con
3485 IP fija no debería depender de que el DHCP conteste: si no contesta no hay segundo intento, y el
3486 síntoma —desde fuera— es idéntico al de una máquina que no bootea. Se le añadió al init una
3487 **dirección estática de respaldo** con la forma que pide Hetzner (IP `/32` + puerta `scope link`).
3488- **Esa red de respaldo no corría**: su guarda era `[ -d /sys/class/net/eth0 ]` y el init **no monta
3489 `/sys`**. El diagnóstico que lo probó tuvo que escribirse a FICHERO, porque `/dev/kmsg` no
3490 sobrevive al reinicio y sin red no hay forma de mirar. *Cuando no hay red, el log tiene que estar
3491 en el disco.*
3492- Del rescate salió el mapa real de particiones, que no era el que yo creía:
3493 `sda2 hammer-root` · `sda3 hammer-state` · `sda4 hammer-work` · `sdb hammer-store`.
3494
3495#### El costo, dicho sin adornos
3496
3497**~20 minutos de caída** de los ocho dominios, cuatro ciclos rescate↔sistema y tres `reset` duros —
3498uno de ellos, el que corrompió el fichero, disparado por mí a los 400 s de espera **mientras la caja
3499estaba haciendo su trabajo**. La lección que queda no es «hay que tener cuidado»: es que **en esta
3500caja el diagnóstico remoto cuesta un ciclo de 6 a 8 minutos**, así que conviene gastar el primero en
3501dejar evidencia en disco antes que en probar una corazonada.
3502
3503## 7. Reusar los scripts que ya existen, y no escribir de nuevo
3504
3505Pedido explícito del usuario. El inventario de lo que ya hace el trabajo:
3506
3507| para | script existente | qué le falta |
3508|---|---|---|
3509| armar el rootfs de un perfil | `scripts/hydrate-profile.py` | nada — es el camino bueno (los `hydrate-*.sh` por escritorio **divergen** de `targets.toml`) |
3510| producir el `.img` | `scripts/install-image.sh` / `scripts/product-image.sh` | apuntar al `perfil.servidor` |
3511| escribir a disco | `scripts/takana-install.sh` | el envoltorio de rescue del §3.2 |
3512| instalador con TUI | `scripts/takana-live-install.sh` | ser el **mismo motor** que el remoto, con las respuestas por fichero |
3513| provisionar un worker | `scripts/farm/vps-setup.sh` | ya soporta apt **y** dnf; le falta la rama «takana puro» (sin gestor de paquetes ajeno) |
3514| enchufar a la granja | `scripts/farm/.fleet` | **está en `.gitignore`** ⇒ un hub recién clonado nace con la flota vacía **en silencio** |
3515| latido | `scripts/farm/cosecha-cron.sh` | decidir cron vs tarjeta de arje (§3.4) |
3516| respaldo | `scripts/respaldo-storagebox.sh` | nada — es interrumpible y continuable |
3517| absorber el init ajeno | `arje-absorb` | el lector de procesos vivos (§4) |
3518
3519⚠ **Un motor, tres frentes.** La tentación es escribir el instalador remoto aparte del TUI. Ahí es
3520donde divergen: ya pasó con los `hydrate-*.sh` contra `targets.toml`, y con la unidad systemd del
3521worker que quedó vieja mientras el repo estaba al día. La instalación remota tiene que ser **la misma
3522que hace la persona**, grabada en un fichero de respuestas.
3523
3524---
3525
3526## 8. `churay` como instalador centralizado — la dirección, no la decisión
3527
3528El usuario lo planteó el 2026-09-09: **un instalador único, con CLI y TUI**, que sirva para
3529
3530- las **apps de tawasuyu**,
3531- **paquetes sueltos en cualquier distro**, al estilo nix (instalar sin ser root, sin tocar el
3532 sistema anfitrión),
3533- **takana** mismo,
3534- y **`llimphi`**.
3535
3536Encaja con lo que ya hay y por eso vale escribirlo: `takana install` ya resuelve por nombre contra un
3537índice firmado y **ya acepta múltiples orígenes**; `qorpa` ([ADR 0015](adr/0015-imagenes-ajenas.md))
3538ya corre imágenes ajenas enjauladas sobre el mismo kernel; y el vigía de espejos de churay ya corre
3539en cron desde gioser.
3540
3541**No se decide acá.** Es un ADR propio, y tiene al menos tres preguntas abiertas antes de escribir
3542una línea: (1) si el instalador «en cualquier distro» hidrata binarios o reproduce desde fuente —la
3543misma pregunta del [SDD 27 §4](27-perfiles-instalables-y-el-instalador.md), y la respuesta puede no
3544ser la misma fuera de takana; (2) quién es el dueño del verbo, si `takana install` crece o si
3545`churay` lo envuelve; (3) qué pasa con un host glibc, que es exactamente lo que el ADR 0015 aparta
3546del store a propósito. Queda anotado para que se **decida**, no para que se descubra a mitad.
3547
3548---
3549
3550## 9. Estado y orden
3551
3552**Decisión del usuario (2026-09-14): la mudanza NO pasa por terceros.** Nada de espejar a GitHub
3553para «tener copia fuera»: la copia fuera **la da la propia mudanza** — en cuanto el gitea vive en la
3554caja nueva, los 26 repos dejan de existir sólo en la máquina que se borra. El objetivo es dejar de
3555pagar dos máquinas, no montar una dependencia más. `scripts/mudanza/espejar-repos.sh` queda como
3556herramienta disponible, no como paso del plan.
3557
3558**Y el worker no necesita credenciales: las fuentes de tawasuyu se sirven por HTTPS público.**
3559Las 23 recetas que apuntaban a `gitea@git.tawasuyu.net` (SSH) pasaron a `https://git.tawasuyu.net/…`
3560— la URL es locator y no entra en `hash_inputs` (ADR 0013), así que se cambió **con control y sin
3561mover un solo ArtifactHash**. Medido en el worker: clona y `git archive` extrae el árbol (155 M) sin
3562ninguna clave. Un usuario propio en gitea sólo haría falta para un repo PRIVADO, y hoy ninguna
3563receta usa uno.
3564
3565### Lo que YA está, y no hay que volver a tocar
3566
3567| | |
3568|---|---|
3569| la caja `takana` (`2.29.29.217`) | arranca takana puro, PID 1 `arje-zero` — §3.8 |
3570| store, grafos, granja, respaldo | puertas 2, 3, 4 y 7 — §6.3, §6.7, §6.8, §6.10 |
3571| repo firmado servido por la caja | §5.1 |
3572| **la imagen del perfil `servidor` con gitea** | **arranca y sirve 200, supervisado por arje** — §6.11 |
3573| **`arjectl` para operar sin reiniciar** | §6.12 |
3574| **el gitea de gioser corriendo sobre takana, con sus datos** | ensayo completo — §6.13 |
3575
3576### Lo que falta para el cutover, en este orden
3577
3578⚠ **La lista de abajo es del 2026-09-11 y los pasos 1-5 YA ESTÁN** (gitea mudado y sirviendo, §6.14;
3579estáticos mudados, §6.18; fósiles barridos, §6.19; `api.sergio` mudado, §6.25; `tawasuyu.net` y
3580`gioser.net` mudados, §6.26; squid, §6.27-28; hora, latido y rotación, §6.29; cortafuegos, §6.31-33).
3581
3582**El estado vigente está medido en el §6.34 (2026-09-16), y es más corto de lo que decía esta lista:
3583queda UN solo vhost sirviéndose desde gioser — `sergio.gioser.net` — y el montón de daemons propios
3584del usuario que ningún paquete provee.** Los pasos 6 y 7 son lo único que sigue abierto.
3585
3586
35871. **Actualizar la caja a la imagen nueva** (gitea + `arjectl` + las cuentas de `[[user]]`).
3588 `takana upgrade` está probado (§6.13 del SDD 27 y §5.4 acá); el `dd` es para provisionar, no para
3589 actualizar — sobrescribe el disco local y re-etiqueta la partición.
35902. **Mudar los datos del gitea**: `sqlite3 … ".backup"` (1,5 s, consistente con el servidor vivo) +
3591 `rsync -aH` de `/var/lib/gitea` y `/etc/gitea`. El corte final se hace con el gitea del origen
3592 **parado**, para que el último snapshot no pierda escrituras.
35933. **Caddy en la caja**: los **6 dominios vivos** del §6.9, con su TLS. Los otros 13 no se mudan.
35944. **DNS**: apuntar esos 6 a la IP nueva. El resto de los clones y remotos no se toca — siguen
3595 resolviendo al mismo nombre.
35965. **Verificar desde fuera**: cada dominio vivo responde 200 contra la IP nueva **y** un `git clone`
3597 real contra el gitea mudado.
35986. **El resto de servicios vivos** del censo (qdrant, squid, act-runner, php-fpm…), por el plan que
3599 `planear.py` ya emite.
36007. **Borrar gioser** — sólo con las 8 puertas en verde, a mano, nunca por automatización (§6).
3601
3602### Bloqueantes conocidos, con su tamaño
3603
3604- **`git` sellado sin `remote-http`** (§6.13): afecta a clonar POR HTTPS *desde* una caja takana, no
3605 al gitea que sirve. Re-sella `git`, raíz de `perfil.base` ⇒ unidad propia.
3606- **Puerta 5** sigue a medias: la caja sirve su repo pero no se instala de él (`install` reproduce y
3607 eso exige el lab entero). No bloquea la mudanza; bloquea «el servidor se sirve a sí mismo».
3608
3609**El volumen del store NO se engancha a la caja hasta que pase la puerta 1** — ya pasó, y el store
3610local de 68,7 G alcanza, así que la mudanza no depende de mover el volumen de gioser.
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):
- 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.
- «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).
- 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
perfil.servidor — HECHO hoy en docs/state/targets.toml. Ver §3.4.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.- 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.
- 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
- 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.
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.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:
- 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.
- 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.
⚠ 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.
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:
- 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.
- 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.
- 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:
- 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.
- 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.
- 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).
-
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/.
-
El binario de desarrollo. HAMMER = ROOT/target/release/takana (§6.7).
-
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.
-
🚨 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.
-
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:
-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.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.
-
⚠⚠ 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.
-
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.
-
⚡ 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
-
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.
-
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.
-
🧨 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
- Caja actualizada:
arjectl + gitea + la cuenta gitea:969 + las cards en genesis y cards.d.
- 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).
- 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).
- 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.
- 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
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.- 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.
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
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./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.- 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.
- 🧨 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
- 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.
- 🧨
--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.
--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
- 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.
- 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.
- 🧨
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
nft flush set … ban4/ban6 — servicio restaurado en el acto.- 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.
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.- 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
- 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).
- 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.
- ⚠ 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".
- 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.
- 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.
- 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:
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.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»:
- darle el lab a la caja (
/.dev-fs/…) — deja de ser sólo servidor y pasa a ser también hub;
- partir el latido: siembra+cosecha en la caja, regeneración del grafo donde haya lab;
- 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
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.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:
- 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.
- 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:
--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.- 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:
- 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.
- 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:
-
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
-
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.
-
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.
- 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.
- 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.
- Caddy en la caja: los 6 dominios vivos del §6.9, con su TLS. Los otros 13 no se mudan.
- DNS: apuntar esos 6 a la IP nueva. El resto de los clones y remotos no se toca — siguen
resolviendo al mismo nombre.
- Verificar desde fuera: cada dominio vivo responde 200 contra la IP nueva y un
git clone
real contra el gitea mudado.
- El resto de servicios vivos del censo (qdrant, squid, act-runner, php-fpm…), por el plan que
planear.py ya emite.
- 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.