SergioandClaude Opus 5
ec469aef6b
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>
55 lines
3.0 KiB
TOML
55 lines
3.0 KiB
TOML
# tupu — el colector de telemetría: `tupu collect --interval 10 --root /var/lib/tupu`.
|
|
#
|
|
# El paquete es `tupu-cli` y el binario `tupu`.
|
|
# ⚠ `/var/lib/tupu` es un directorio COMPARTIDO: escriben ahí `tupu`, `matilda` y
|
|
# `sandokan-watch`. Los tres necesitan el mismo dueño, o dos de ellos fallan al escribir y el
|
|
# tercero se lleva los datos incompletos sin que nada lo diga.
|
|
#
|
|
# Receta Cargo contra el monorepo de tawasuyu, pinneada al MISMO commit que `shuma-*` y
|
|
# `puriy-costura`: el árbol de fuentes se comparte por `<dep>-<sha>`, así que un pin distinto es otro
|
|
# vendoreo de 2,4 G. Estática musl con zig-cc — la caja la arranca el init y no puede depender de
|
|
# encontrar un cargador, que es justo lo que le falta al binario glibc de gioser.
|
|
|
|
name = "tupu"
|
|
version = "0.1.0"
|
|
license = "MIT OR Apache-2.0"
|
|
|
|
[source]
|
|
repo = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
|
|
commit = "23a292863f53b355c5c02d6185904f2c33d8ab42"
|
|
# tawasuyu COMMITEA su propio `vendor/` (smithay parcheado, enchufado por `[patch.crates-io]` POR
|
|
# RUTA); el `cargo vendor` de takana lo pisaría y el error habla de `taffy`, no de esto.
|
|
cargo_vendor_dir = ".hammer-cargo-vendor"
|
|
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "static"
|
|
flags = ["-p", "tupu-cli", "--bin", "tupu"]
|
|
|
|
# ── EL SERVICIO (SDD 30) ────────────────────────────────────────────────────────────────────────
|
|
# Fuera de `hash_inputs`: declararlo no re-hashea.
|
|
#
|
|
# ⚠ **CORRE COMO ROOT, Y NO ES UN DESCUIDO — ES UNA RESTRICCIÓN MEDIDA.** Lo natural sería una
|
|
# cuenta propia sin privilegio, como `shuma` o `gitea`. Acá no se puede, por dos hechos:
|
|
#
|
|
# 1. `matilda` lee `/var/log/caddy/requests.json`, que caddy crea **`-rw------- root root`** y
|
|
# recrea igual en cada rotación. Un grupo con lectura se pierde en la próxima rotación.
|
|
# 2. Los tres —`tupu`, `matilda`, `sandokan-watch`— escriben en el MISMO `/var/lib/tupu`, y en
|
|
# gioser sus 322 ficheros son `root:root`. Bajar a uno solo deja mezcla de dueños en un árbol
|
|
# compartido, que es la trampa de siempre: escribe el primero y los otros fallan al modificar.
|
|
#
|
|
# ⇒ o los tres como root, o ninguno. La salida limpia existe y está anotada para el día que se
|
|
# quiera: que caddy escriba su log con lectura de grupo (`output file … { mode 640 }`) y que el
|
|
# árbol sea de una cuenta `tupu`. Mientras tanto, esto es lo que HACE la máquina vieja, declarado
|
|
# en vez de heredado.
|
|
[[service]]
|
|
label = "tupu"
|
|
id = "01M2EKDA00TVPV000000000001"
|
|
exec = "/bin/busybox"
|
|
argv = ["sh", "-c", "test -d /var/lib/tupu || mkdir -p /var/lib/tupu || exit 78; exec /usr/bin/tupu collect --interval 10 --root /var/lib/tupu"]
|
|
envp = [["PATH", "/usr/bin:/bin"], ["HOME", "/root"]]
|
|
networking = "full"
|
|
cgroup = "arje.slice/tupu"
|
|
restart = { initial_ms = 1000, max_ms = 30000 }
|