sergio/takana

1# sandokan-watch — vigía: `--every 60 --state /var/lib/sandokan-watch.json --record --root /var/lib/tupu`.
2#
3# El paquete es `sandokan-seguridad-core` y el binario `sandokan-watch`.
4# ⚠ Escribe en `/var/lib/tupu`, el mismo directorio que `tupu` y `matilda` (ver esa receta).
5#
6# Receta Cargo contra el monorepo de tawasuyu, pinneada al MISMO commit que `shuma-*` y
7# `puriy-costura`: el árbol de fuentes se comparte por `<dep>-<sha>`, así que un pin distinto es otro
8# vendoreo de 2,4 G. Estática musl con zig-cc — la caja la arranca el init y no puede depender de
9# encontrar un cargador, que es justo lo que le falta al binario glibc de gioser.
10
11name    = "sandokan-watch"
12version = "0.1.0"
13license = "MIT OR Apache-2.0"
14
15[source]
16repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
17commit = "3bfb9799b8fd26bbe151008e6060f6f74b0f3c6b"
18# tawasuyu COMMITEA su propio `vendor/` (smithay parcheado, enchufado por `[patch.crates-io]` POR
19# RUTA); el `cargo vendor` de takana lo pisaría y el error habla de `taffy`, no de esto.
20cargo_vendor_dir = ".hammer-cargo-vendor"
21
22[build]
23compiler = "zig-cc"
24target   = "x86_64-linux-musl"
25link     = "static"
26flags    = ["-p", "sandokan-seguridad-core", "--bin", "sandokan-watch"]
27
28# ── EL SERVICIO (SDD 30) ────────────────────────────────────────────────────────────────────────
29# Fuera de `hash_inputs`: declararlo no re-hashea.
30#
31# ⚠ **CORRE COMO ROOT, Y NO ES UN DESCUIDO — ES UNA RESTRICCIÓN MEDIDA.** Lo natural sería una
32# cuenta propia sin privilegio, como `shuma` o `gitea`. Acá no se puede, por dos hechos:
33#
34#   1. `matilda` lee `/var/log/caddy/requests.json`, que caddy crea **`-rw------- root root`** y
35#      recrea igual en cada rotación. Un grupo con lectura se pierde en la próxima rotación.
36#   2. Los tres —`tupu`, `matilda`, `sandokan-watch`— escriben en el MISMO `/var/lib/tupu`, y en
37#      gioser sus 322 ficheros son `root:root`. Bajar a uno solo deja mezcla de dueños en un árbol
38#      compartido, que es la trampa de siempre: escribe el primero y los otros fallan al modificar.
39#
40# ⇒ o los tres como root, o ninguno. La salida limpia existe y está anotada para el día que se
41# quiera: que caddy escriba su log con lectura de grupo (`output file … { mode 640 }`) y que el
42# árbol sea de una cuenta `tupu`. Mientras tanto, esto es lo que HACE la máquina vieja, declarado
43# en vez de heredado.
44[[service]]
45label      = "sandokan-watch"
46id         = "01M2EKDA005AND0KANWATCH001"
47exec       = "/bin/busybox"
48argv = ["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"]
49envp       = [["PATH", "/usr/bin:/bin"], ["HOME", "/root"]]
50networking = "full"
51cgroup     = "arje.slice/sandokan-watch"
52restart    = { initial_ms = 1000, max_ms = 30000 }
53
54# ⚠ MEDIDO EN LA CAJA (2026-09-16): acá NO PUEDE TRABAJAR, y lo dice él mismo:
55#
56#     sandokan-watch · sin fuente de accesos (ni /var/log/auth.log ni journalctl): no se guarda nada
57#
58# En gioser lee el `auth.log` de un syslog que en takana no existe —no hay systemd ni syslog— así
59# que el servicio arrancaba, quedaba «corriendo · 0 reinicios» y no guardaba una línea. Por eso la
60# guarda de arriba sale 78 en vez de dejarlo verde: **un vigía que no vigila es peor que uno caído,
61# porque el caído se ve**. Destrabarlo es darle el diario de arje como fuente, y eso es trabajo de
62# su propio repo, no de esta receta.