La tabla del §6.3 era del 10 de septiembre. Hoy, entera:
2 store entero ✅ 1632 artefactos, 0 vacíos (eran 1362) · ⚠ /store al 88%
4 la granja late allá ❌ el latido SIGUE en gioser
6 dominios vivos 200 ✅ los 8 contra 2.29.29.217, `sergio` incluido
7 respaldo desde allá ⬖ el script corre y LISTA el Storage Box desde la caja
1,3,8 ✅ · 5 ⬖ (sirve, no consume: reproducir exige el lab entero)
La puerta 4 es ahora UNA LÍNEA DE CRONTAB. La caja ya tiene git, python3, rsync, ssh, takana, flock,
la llave del worker y el `.fleet`; le faltaban dos costuras y están hechas: `store -> /store` (el
script espera ./store, acá es partición) y `target/release/takana -> /usr/bin/takana` (no hay árbol
de build en una caja instalada). Prueba de sólo lectura: `estado-granja.sh` desde la caja ve al
worker, lee el grafo KDE y dice «CRON DE COSECHA: NO instalado».
NO lo instalé, por el mismo motivo que tejido: con el cron en las dos máquinas, las dos harían
`rsync --delete` al worker y las dos cosecharían y commitearían. El latido se INTERCAMBIA, no se
duplica, y es el último movimiento antes del borrado.
De paso, el repo de /opt/takana estaba 5 días atrasado y quedó en origin/main exacto (0 diferencias),
con tar de respaldo de los 92 ficheros previos. ⚠ Esos 92 no eran trabajo local: era contenido que
YA estaba río arriba metido en el árbol sin commitear — un árbol que parece sucio y está atrasado.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`/etc/arje/cards.d/openrc-openclaw.json` de gioser tiene una credencial en claro adentro del JSON —
2 coincidencias con patrón de api_key/token. Ese directorio está en `fuera_de_git`, así que la
mudanza lo copia y un respaldo lo multiplica.
No lo toco: rotar una credencial es del dueño. Queda anotado con las dos salidas (rotarla y moverla
a un fichero 600 que la Card EXIJA, como hace thasnuna; o que openclaw muera y se revoque igual), y
con la que no es opción: copiarla tal cual.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Nueve de las diez sellaron y están promovidas. Cinco corren en la caja (matilda, tupu, pacha,
pacha-secretos, willay-daemon, más el par de shuma de ayer); cuatro quedan instaladas y FRENADAS a
propósito, cada una con su guarda diciendo qué falta.
⚠ LA PAUTA DE LOS VHOSTS NO SIRVE PARA UNA IDENTIDAD. Con los sitios la regla fue «mudá el DNS y
dejá el origen encendido, así volver cuesta un minuto» (§6.26). Con `tejido` es justo lo contrario:
su README dice que la clave que el roster atesta ES la identidad de transporte libp2p
(`~/.tejido/device.seed`), así que dos máquinas con la misma semilla no son dos réplicas — son el
MISMO PeerId en dos sitios, dos impostores mutuos para la flota. `tejido` se INTERCAMBIA: se apaga
allá, se enciende acá, en ese orden. Todo listo para el intercambio (binario, cuenta 964, identidad
700 instalada) y su Card en `cards.d` pero NO en el `genesis`, para que un reinicio no lo encienda.
Y arrastra a `willay-crosscheck`, que no es independiente: corriendo su línea a mano dice «no hay
roster en /root/.tejido/roster.postcard — emparejá primero». Vive dentro de la red de tejido.
`thasnuna` tampoco puede: su INSTALAR.md —escrito hoy por el frente tawasuyu para esta mudanza—
pide `sandokan-mcp` y `claude` AUTENTICADO, y el CLI de claude es glibc de ~300 M (jaula qorpa).
De ahí sale un hallazgo que vale para el respaldo entero: la Card `openrc-openclaw` de gioser lleva
la API key de su proveedor EN CLARO dentro del JSON de /etc/arje/cards.d/, que se respalda y se
copia. Un secreto dentro de una Card viaja a todas partes.
`--label` de willay-crosscheck NOMBRA A LA MÁQUINA: en gioser decía `momento`. Ahora sale de
`hostname` y la guarda frena si no hay.
Y tres veredictos FALSOS en una tarde, los tres por probar con lo que la caja no tiene: `/dev/tcp`
(busybox ash no lo tiene) dio los 5 puertos de gioser «cerrados»; la expansión de llaves dijo que
los artefactos no habían llegado; y `find -newermt "-2 minutes"` dijo que tupu no escribía. Tupu SÍ
escribe: su fichero tiene tamaño CONSTANTE —es una serie fija— así que ni los bytes ni ese find
prueban nada; lo que decide es el mtime, medido dos veces con 40 s de por medio.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sellaron `matilda`, `pacha`, `pacha-secretos` y `sandokan-watch`; las cuatro promovidas a canónicas
(hash idéntico antes y después de moverlas) y las tres primeras ya supervisadas por arje.
`matilda` archivó 78 ficheros leyendo el access log de caddy; `pacha` corre con SUS reglas y no con
las de fábrica; `pacha-secretos` vuelve a existir como binario — en gioser era un inodo borrado.
TRES CORREN COMO ROOT, declarado en vez de heredado. No es descuido: `matilda` lee
`/var/log/caddy/requests.json`, que caddy crea `-rw------- root root` y recrea igual en cada
rotación; y los tres del trío escriben en el MISMO `/var/lib/tupu`, cuyos 322 ficheros en gioser son
root:root — bajar a uno solo deja mezcla de dueños en un árbol compartido. O los tres, o ninguno. La
salida limpia (caddy con `mode 640` + cuenta propia del árbol) queda anotada en la receta. `pacha` y
`pacha-secretos` sí bajan a cuenta propia: en gioser tampoco corrían como root.
🕳️ LA CAJA NO TENÍA HOSTNAME. `hostname` decía `(none)` y `/etc/hostname` no existía — NINGUNA caja
takana lo fija: ni netup, ni el product-rootfs. Nunca importó porque nada archivaba por nombre,
hasta que llegó matilda: sus primeros 72 ficheros fueron a `/var/lib/tupu/none/`, y dos máquinas
distintas archivarían en la misma carpeta sin que nada falle. Puesto `/etc/hostname` + una Card
OneShot en el genesis para que sobreviva al reinicio. Lo correcto es que lo haga `netup`.
🛡️ Y `sandokan-watch` quedaba VERDE SIN VIGILAR: en takana no hay `auth.log` ni journalctl, así que
arrancaba, decía «sin fuente de accesos: no se guarda nada» y se quedaba «corriendo · 0 reinicios».
Su Card ahora sale 78 nombrando el problema y NO entra al genesis: un vigía que no vigila es peor
que uno caído, porque el caído se ve.
De paso, dos veredictos FALSOS en una tarde por probar con algo que la caja no tiene: `/dev/tcp` no
existe en busybox ash (dio «cerrado» para los cinco puertos de gioser, incluidos :80 y :443, que
sirven) y la expansión de llaves tampoco (dijo que los artefactos no habían llegado; habían
llegado). Misma familia que el §6.23.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`work/` está en .gitignore, así que el fichero donde vive lo que el usuario decidió —con el motivo de
cada línea— no sobrevivía a la máquina que la mudanza borra. Ahora es `docs/state/`.
Nueve entradas marcadas `respalda`: terapeuta.ec (279 M, sin DNS hace tiempo), los cuatro «valens»,
`los-grandes-mensajes.pdf`, `kkk` (46 B, credencial en claro) y los tres clones de terceros CON
cambios sin commitear — lo commiteado se vuelve a clonar, lo de encima existe sólo en este disco.
Juntas en `/mnt/cosecha/respaldo-mudanza` (475 M) con LEEME y SHA256SUMS de 5472 ficheros. El
control se hizo ANTES del manifiesto: ficheros contados en origen y en corral, las nueve coinciden
(3805, 1243, 183, 1, 164, 1, 1, 72, 1).
⚠ NO entraron `~/hammer`, `~/takana` ni `~/tawasuyu`: son SYMLINKS a /mnt/vvv. El censo los veía
como entradas de 0 bytes CON remoto git —porque `git -C` sigue el enlace— y la recomendación
automática decía «respalda» por tener cambios sin commitear. Respaldarlos habría guardado tres
enlaces rotos. Un dato que parece del objeto y es del enlace.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El SDD 27 §2 dice que el repo mezcla tres capas —piso, escritorio, extras— en una sola
lista por escritorio, y que esa es la causa de que la composición no esté definida. El
firmware es un cuarto caso que el SDD no nombra y que sigue la misma lógica: no es un
escritorio ni un toolbox, es lo que hace falta para que un METAL CONCRETO arranque con todo
su hardware vivo.
Por eso va como perfil propio y se compone, en vez de duplicarse en los cuatro escritorios:
scripts/targets.py cli metal-tigerlake escritorio-kde
Otro metal = otro perfil de estos con su propia receta firmware-<plataforma> derivada del
mismo linux-firmware. Ese es el punto de haber partido el firmware en base + derivada.
La máquina, medida con lspci/cpuinfo sobre el metal real:
CPU i7-11370H · family 6 · model 140 (0x8c) · stepping 1 ⇒ intel-ucode/06-8c-01
GPU TigerLake-LP GT2 [Iris Xe] [8086:9a49] ⇒ i915 / xe
WiFi Intel Wi-Fi 6 AX201 [8086:a0f0] ⇒ iwlwifi
Audio 500 Series HD Audio [8086:a0c8] ⇒ snd_sof_pci_intel_tgl
Y zsh entra en `cli`, no en `base`: base define el shell del SISTEMA (bash) y esto es el
del usuario. Dos hechos distintos, como `paquetes` y `servicios` un piso más abajo.
El runbook deja el encargo para el worker, y su parte útil son los dos muros que aparecieron
al cruzar ficheros que nadie había leído juntos:
1. takana-live-install.sh:275 bifurca «UEFI ⇒ rama EFI-stub soberana», y metal-usb-sdboot.sh
dice que el EFI-stub «en el firmware del usuario se cuelga tras Measured initrd PCR 9».
ES EL MISMO FIRMWARE. El lazo de instalación EFI está validado en OVMF, que no tiene ese
quirk ⇒ el instalador va a pasar la prueba y colgarse en el metal de destino. La salida
es llevar el instalador a systemd-boot, que es el camino ya probado en esta máquina.
2. El instalador reparticiona en MBR el disco entero, y ese disco tiene /home con 893 G
usados. Si la instalación conserva /home o se lleva el disco con respaldo previo es
decisión del usuario, no del runbook — y hasta que se decida, no correrlo sobre el NVMe.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`https://sergio.gioser.net/` y `/shuma/` contestan 200 contra 2.29.29.217, con TLS público.
**Ningún dominio resuelve ya a gioser.**
⚠ Y el 200 de `/shuma/` había que mirarlo dos veces: el bloque termina en `try_files … /index.html`,
así que CUALQUIER ruta inexistente devuelve 200 con la SPA — un `curl -o /dev/null` habría dado el
mismo verde con el proxy mal puesto. Lo que decide es el cuerpo (17 bytes: «shuma-gateway ok») y el
control es compararlo con lo que el origen viejo sigue sirviendo. Igual con `/shuma/rpc`: las dos
máquinas contestan el mismo 400 con el mismo JSON.
Lo construido, en orden: las dos recetas sellaron en el worker con los hashes anticipados y salen
`statically linked` (nada de cargador, que era lo que le faltaba al binario glibc de gioser) · la
cuenta `shuma` declarada con `[[user]]`, uid 967, y el descenso con `setuidgid` en el argv de la
Card porque el payload Native de arje NO tiene campo de usuario · la config que no se regenera
(`gateway-token`, `identity.x25519`) instalada, y la guarda de la Card la EXIGE en vez de crearla:
un token nuevo deja fuera a los clientes ya emparejados · las dos Cards en `cards.d` Y en el genesis
de la semilla · las dos recetas y los dos labels declarados en `perfil.servidor`.
⚠ LA SHELL DE LA CUENTA NO ES UN DETALLE: el default de `[[user]]` es `/bin/false` —correcto para
gitea o squid, exactamente lo contrario para un demonio que abre PTYs—. Con la shell inerte el
servicio arranca, se supervisa, contesta 200 y cada pestaña muere al instante: un fallo que no se ve
al desplegar, se ve al usarlo. Va `shell = "/bin/sh"`.
`[[user]]` y `[[service]]` están fuera de `hash_inputs`: declarar todo eso no movió ningún
ArtifactHash, comprobado antes y después en los dos.
Y una corrección al §6.25: para cambiar el VALOR de un rrset no hace falta DELETE+POST (que deja una
ventana sin registro). La API tiene
`POST /v1/zones/<id>/rrsets/<n>/<t>/actions/set_records`, que es atómica. Con TTL 60 la resolución
pública cambió en menos de 8 segundos.
El origen de gioser sigue corriendo a propósito, como en §6.26: volver atrás es una llamada.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Pedido del usuario: «una lista de cada cosa con una corta descripción y la opción de yo elegir mudar,
mover a un directorio para respaldar ese directorio, o abandonarlo». Eran tres huecos distintos.
1. «CADA COSA». El censo medía RAÍCES: `/home` era UNA entrada de 25 G y UNA decisión, con repos,
SDKs, 4,3 G de caché y trabajo irrepetible adentro. Ahora emite un renglón por cosa —169 en
gioser contra 5—, un nivel hacia adentro de cada raíz y DOS en `/home`, porque su primer nivel
son usuarios y la decisión no es por usuario. `--solo-totales` conserva la vista vieja, que es la
que dimensiona la mudanza; las dos viajan en el censo (`datos` y `datos_raiz`).
⚠ El primer intento mandaba las ~110 sondas en UNA llamada, se pasaba del timeout y devolvía
lista VACÍA: «no hay datos» en vez de «no pude medirlos». Va en tandas, y una tanda que falla se
nombra.
2. «UNA CORTA DESCRIPCIÓN», y son hechos: lo sirve el servidor web · lo usa un proceso vivo · es
repo git y a dónde apunta · tiene cambios sin commitear · adentro hay node_modules/target/venv ·
lo más nuevo que hay dentro. «Sin señales» también es un hecho, y es el que dice dónde mirar.
3. «ELEGIR ENTRE TRES»: DECISIONES pasa de (muda, muere) a (muda, RESPALDA, muere). Faltaba el
camino que se usa de verdad —no lo quiero corriendo allá, tampoco lo quiero perder—; con dos
opciones, todo lo dudoso se marcaba `muda` y la mudanza engordaba.
La regla de fondo no cambió (qué datos VALEN no lo dice la máquina), pero cuatro hechos sí los
sabe: servido/usado ⇒ muda · caché ⇒ muere · repo limpio con remoto ⇒ muere · repo sin remoto o
sucio ⇒ respalda. Y el cruce que evita el peor error: un remoto que apunta a ESTA MISMA máquina
no es un respaldo, es el mismo disco (medido: /mnt/vvv/humanoid → ssh://git@127.0.0.1:2345).
4. LAS DECISIONES SE GUARDAN. `--decide` las usaba sólo para el plan de esa corrida: cerrabas la
terminal y se perdían las 169. Ahora reescribe el censo (temporal+fsync+rename, `.bak`, y releído
antes de pisar nada; aborta si perdió alguna). Para eso hubo que hacer el emisor IDEMPOTENTE:
escribía `decision = ""` fijo, así que re-emitir un censo decidido duplicaba la clave y el TOML
dejaba de parsear — la herramienta no podía reescribir su propio fichero.
5. EL PASO `respaldo`: corral por defecto leído de respaldo-storagebox.sh (no una segunda dirección
a mano), nombre aplanado, y NO se instala en el destino. Sin corral, aborta: un rsync a ninguna
parte devuelve 0 y se lee como un respaldo. Probarlo con rotura a propósito Y con el control que
tiene que pasar destapó dos bugs: `--mkpath` es obligatorio (el primer respaldo siempre estrena
un nivel) y un FICHERO no lleva barra final — `rsync fichero/ dst/` es un error, y el paso de
`datos` tenía el mismo defecto latente. La verificación es rsync en seco contra el destino real,
no `du` ni `find`: el Storage Box no tiene find, no acepta tuberías, y su `du` comprime.
6. De paso: `aplicar.py --dry-run` decía «✅ todos los pasos ejecutados y verificados» sin haber
ejecutado nada. Ahora dice EN SECO: N mostrados, NINGUNO ejecutado y NINGUNO verificado.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Con las decisiones puestas, se movió lo que no dependía de nada más. Cada copia se verificó del lado
del destino, que es lo que el rsync con exit 0 y 1367 artefactos vacíos dejó escrito:
27 guiones (75 KB) → takana:/work/rescate-guiones sha256sum -c ⇒ 27 OK
memoria de Claude (6,3 M) → takana:/root/.claude 733 ficheros = 733
transcripts (1,3 G) → StorageBox claude-gioser rsync -an ⇒ 1 pendiente (el vivo)
clave PRIVADA de release → takana:/root/.config/takana/keys sha256 igual + pública == trust/
credenciales y config → takana:/work/mudanza-secretos 27 ficheros = 27
estado de sigma/tupu/willay → takana:/work/mudanza-estado 351 ficheros, 68 M
Las credenciales NO se instalaron en su sitio a propósito: la caja ya tiene su /root/.ssh, su
crontab y su Caddyfile, y pisarlos rompe lo que funciona. El .gitconfig es el caso más claro — trae
los `insteadOf` que reescriben remotos. Se instalan cuando se mude el hub. La 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 eso no
falla el día que se borra gioser sino la próxima vez que alguien publica.
Y un «576 M contra 1,3 G» que parecía copia truncada: el Storage Box COMPRIME, y su shell
restringida no tiene find ni acepta tuberías, así que el conteo de ficheros ahí no se puede hacer.
Lo que sí: preguntarle a rsync en seco, que compara contra el destino real. Un número que no cuadra
merece una segunda medición antes de un diagnóstico.
No se movieron ~10 G de árboles personales de /home ni /opt: qué datos valen no se deduce de la
máquina, y ésos son proyectos del usuario, no servicios de un censo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El pin de `puriy-costura` subio a `23a292863` y con eso se apagaron los dos rojos del cable. La suite
entera sobre `b3:e556024b`: **19 verdes, 0 rojos, 32,1 min**. No se toco ningun guardian — que la
suite existiera ANTES del arreglo es lo que permite afirmarlo: el cuadro de ayer y el de hoy son el
mismo instrumento.
La medicion que cierra es la que abrio el §7.quinquies, leida al reves: `strings` sobre el binario
sellado da `vault` **10** veces donde daba 0, con `cas`/`sct` de control; y `vigia-atuq-verbos` pasa
de 3 verbos sin dueno a cero, con su control positivo intacto.
Lo destrabo publicar el `Cargo.lock` de tawasuyu (`23a292863` alla), regenerado en un arbol limpio:
215 lineas, todas de contabilidad de deps por ruta, cero `checksum` y cero `source` movidos. Y el
remate, que es la leccion: **ese lock era byte a byte el que la otra sesion ya tenia en su arbol sin
commitear**. Tres semanas de bloqueo y el fichero correcto estaba escrito, sin empujar, a un
directorio de distancia. Antes de decir «bloqueado por otro repo», mirar si lo que falta no esta ya
hecho y sin publicar.
Commiteado alla con indice temporal (`GIT_INDEX_FILE` + `commit-tree`), que es la unica forma de
publicar una ruta en `MM` sin llevarse por delante lo del otro agente: su arbol quedo byte a byte
igual, comprobado con `cmp` antes y despues.
⚠ Y la cabecera del runner se desmintio SOLA dos veces: anuncio «un rojo» cuando eran dos, y «dos»
cuando ya no quedaba ninguno. Un numero escrito como prediccion envejece callado. Con todo en verde
el numero ya no distingue un producto sano de un runner que no corre nada, asi que lo que sostiene la
corrida queda escrito: la puerta del sello (verificada contra un store vacio) y el control interno de
cada guardian.
Sergio
sergioandClaude Opus 5