sergio/takana

1# matilda — grabador: `matilda record --interval 60 --root /var/lib/tupu --access-log …`.
2#
3# ⚠ Lee el ACCESS LOG de caddy (`/var/log/caddy/requests.json`). En la caja nueva ese fichero
4# existe sólo si el Caddyfile importa el snippet `acceso` — que sí lo hace. Si algún día deja
5# de hacerlo, matilda no falla: graba vacío.
6# El crate vive en `02_ruway/shuma/baremetal/matilda-app` y su paquete se llama `matilda`.
7#
8# Receta Cargo contra el monorepo de tawasuyu, pinneada al MISMO commit que `shuma-*` y
9# `puriy-costura`: el árbol de fuentes se comparte por `<dep>-<sha>`, así que un pin distinto es otro
10# vendoreo de 2,4 G. Estática musl con zig-cc — la caja la arranca el init y no puede depender de
11# encontrar un cargador, que es justo lo que le falta al binario glibc de gioser.
12
13name    = "matilda"
14version = "0.1.0"
15license = "MIT OR Apache-2.0"
16
17[source]
18repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
19commit = "619431cac9753cd55d0f9e2d99ff8efe7fab651b"
20# tawasuyu COMMITEA su propio `vendor/` (smithay parcheado, enchufado por `[patch.crates-io]` POR
21# RUTA); el `cargo vendor` de takana lo pisaría y el error habla de `taffy`, no de esto.
22cargo_vendor_dir = ".hammer-cargo-vendor"
23
24[build]
25compiler = "zig-cc"
26target   = "x86_64-linux-musl"
27link     = "static"
28flags    = ["-p", "matilda", "--bin", "matilda"]
29
30# ── EL SERVICIO (SDD 30) ────────────────────────────────────────────────────────────────────────
31# Fuera de `hash_inputs`: declararlo no re-hashea.
32#
33# ⚠ **CORRE COMO ROOT, Y NO ES UN DESCUIDO — ES UNA RESTRICCIÓN MEDIDA.** Lo natural sería una
34# cuenta propia sin privilegio, como `shuma` o `gitea`. Acá no se puede, por dos hechos:
35#
36#   1. `matilda` lee `/var/log/caddy/requests.json`, que caddy crea **`-rw------- root root`** y
37#      recrea igual en cada rotación. Un grupo con lectura se pierde en la próxima rotación.
38#   2. Los tres —`tupu`, `matilda`, `sandokan-watch`— escriben en el MISMO `/var/lib/tupu`, y en
39#      gioser sus 322 ficheros son `root:root`. Bajar a uno solo deja mezcla de dueños en un árbol
40#      compartido, que es la trampa de siempre: escribe el primero y los otros fallan al modificar.
41#
42# ⇒ o los tres como root, o ninguno. La salida limpia existe y está anotada para el día que se
43# quiera: que caddy escriba su log con lectura de grupo (`output file … { mode 640 }`) y que el
44# árbol sea de una cuenta `tupu`. Mientras tanto, esto es lo que HACE la máquina vieja, declarado
45# en vez de heredado.
46[[service]]
47label      = "matilda"
48id         = "01M2EKDA00MAT1DA0GRABA0001"
49exec       = "/bin/busybox"
50argv = ["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"]
51envp       = [["PATH", "/usr/bin:/bin"], ["HOME", "/root"]]
52networking = "full"
53cgroup     = "arje.slice/matilda"
54restart    = { initial_ms = 1000, max_ms = 30000 }