SergioandClaude Opus 5
98cd672a10
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>
55 lines
3.2 KiB
TOML
55 lines
3.2 KiB
TOML
# matilda — grabador: `matilda record --interval 60 --root /var/lib/tupu --access-log …`.
|
|
#
|
|
# ⚠ Lee el ACCESS LOG de caddy (`/var/log/caddy/requests.json`). En la caja nueva ese fichero
|
|
# existe sólo si el Caddyfile importa el snippet `acceso` — que sí lo hace. Si algún día deja
|
|
# de hacerlo, matilda no falla: graba vacío.
|
|
# El crate vive en `02_ruway/shuma/baremetal/matilda-app` y su paquete se llama `matilda`.
|
|
#
|
|
# 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 = "matilda"
|
|
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", "matilda", "--bin", "matilda"]
|
|
|
|
# ── 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 = "matilda"
|
|
id = "01M2EKDA00MAT1DA0GRABA0001"
|
|
exec = "/bin/busybox"
|
|
argv = ["sh", "-c", "test -d /var/lib/tupu || mkdir -p /var/lib/tupu || exit 78; test -r /var/log/caddy/requests.json || { echo 'matilda: no puedo leer /var/log/caddy/requests.json — sin el access log de caddy graba VACÍO y nadie lo nota' >&2; exit 78; }; exec /usr/bin/matilda record --interval 60 --root /var/lib/tupu --access-log /var/log/caddy/requests.json"]
|
|
envp = [["PATH", "/usr/bin:/bin"], ["HOME", "/root"]]
|
|
networking = "full"
|
|
cgroup = "arje.slice/matilda"
|
|
restart = { initial_ms = 1000, max_ms = 30000 }
|