sergio/takana
> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…
los nueve daemons propios declarados — y la línea entre «se muda» y «se INTERCAMBIA»
1# tupu — el colector de telemetría: `tupu collect --interval 10 --root /var/lib/tupu`.
2#
3# El paquete es `tupu-cli` y el binario `tupu`.
4# ⚠ `/var/lib/tupu` es un directorio COMPARTIDO: escriben ahí `tupu`, `matilda` y
5# `sandokan-watch`. Los tres necesitan el mismo dueño, o dos de ellos fallan al escribir y el
6# tercero se lleva los datos incompletos sin que nada lo diga.
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 = "tupu"
14version = "0.1.0"
15license = "MIT OR Apache-2.0"
16
17[source]
18repo = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
19commit = "23a292863f53b355c5c02d6185904f2c33d8ab42"
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", "tupu-cli", "--bin", "tupu"]
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 = "tupu"
48id = "01M2EKDA00TVPV000000000001"
49exec = "/bin/busybox"
50argv = ["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"]
51envp = [["PATH", "/usr/bin:/bin"], ["HOME", "/root"]]
52networking = "full"
53cgroup = "arje.slice/tupu"
54restart = { initial_ms = 1000, max_ms = 30000 }