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>
63 lines
3.9 KiB
TOML
63 lines
3.9 KiB
TOML
# sandokan-watch — vigía: `--every 60 --state /var/lib/sandokan-watch.json --record --root /var/lib/tupu`.
|
|
#
|
|
# El paquete es `sandokan-seguridad-core` y el binario `sandokan-watch`.
|
|
# ⚠ Escribe en `/var/lib/tupu`, el mismo directorio que `tupu` y `matilda` (ver esa receta).
|
|
#
|
|
# 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 = "sandokan-watch"
|
|
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", "sandokan-seguridad-core", "--bin", "sandokan-watch"]
|
|
|
|
# ── 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 = "sandokan-watch"
|
|
id = "01M2EKDA005AND0KANWATCH001"
|
|
exec = "/bin/busybox"
|
|
argv = ["sh", "-c", "test -d /var/lib/tupu || mkdir -p /var/lib/tupu || exit 78; test -r /var/log/auth.log || command -v journalctl >/dev/null || { echo 'sandokan-watch: no hay FUENTE DE ACCESOS en esta máquina (ni /var/log/auth.log ni journalctl). El binario arranca igual y NO GUARDA NADA: un vigía verde que no vigila. En takana hace falta darle el diario de arje o una fuente equivalente.' >&2; exit 78; }; exec /usr/bin/sandokan-watch --every 60 --state /var/lib/sandokan-watch.json --record --root /var/lib/tupu"]
|
|
envp = [["PATH", "/usr/bin:/bin"], ["HOME", "/root"]]
|
|
networking = "full"
|
|
cgroup = "arje.slice/sandokan-watch"
|
|
restart = { initial_ms = 1000, max_ms = 30000 }
|
|
|
|
# ⚠ MEDIDO EN LA CAJA (2026-09-16): acá NO PUEDE TRABAJAR, y lo dice él mismo:
|
|
#
|
|
# 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— así
|
|
# que el servicio arrancaba, quedaba «corriendo · 0 reinicios» y no guardaba una línea. Por eso la
|
|
# guarda de arriba sale 78 en vez de dejarlo verde: **un vigía que no vigila es peor que uno caído,
|
|
# porque el caído se ve**. Destrabarlo es darle el diario de arje como fuente, y eso es trabajo de
|
|
# su propio repo, no de esta receta.
|