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>
51 lines
3.1 KiB
TOML
51 lines
3.1 KiB
TOML
# pacha — `pacha daemon`, corriendo en gioser sin que nadie lo declare.
|
|
#
|
|
# El paquete es `pacha-cli` y el binario `pacha`. Sus reglas viven en `~/.config/pacha/reglas*.ron`:
|
|
# son DECISIONES del usuario, no defaults, y no las genera nada.
|
|
#
|
|
# 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 = "pacha"
|
|
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", "pacha-cli", "--bin", "pacha"]
|
|
|
|
# ── LA CUENTA (SDD 30) ──────────────────────────────────────────────────────────────────────────
|
|
# Fuera de `hash_inputs`. En gioser corre como `sergio` —nunca como root—, así que acá es una cuenta
|
|
# propia y sin privilegio. La comparte con `pacha-secretos`: son la misma familia y el mismo estado
|
|
# (`~/.local/state/tawasuyu/pacha-secretos/`), y separarlos obligaría a un grupo intermedio para que
|
|
# uno lea lo que el otro escribe.
|
|
[[user]]
|
|
name = "pacha"
|
|
uid = 965
|
|
home = "/var/lib/pacha"
|
|
|
|
# ── EL SERVICIO ─────────────────────────────────────────────────────────────────────────────────
|
|
# ⚠ La guarda EXIGE `reglas.ron`. No es celo: son **decisiones del usuario, no defaults** — sin
|
|
# ellas pacha no falla, arranca con otra política, y eso no se ve en ningún log. Mismo criterio que
|
|
# el `gateway-token` de shuma: lo que no se puede regenerar se exige, no se inventa.
|
|
[[service]]
|
|
label = "pacha"
|
|
id = "01M2EKDA00PACHADAEM0N00110"
|
|
exec = "/bin/busybox"
|
|
argv = ["sh", "-c", "/bin/grep -q '^pacha:' /etc/passwd || { echo 'pacha: falta el usuario `pacha` en /etc/passwd — lo declara esta receta con [[user]]' >&2; exit 78; }; test -s /var/lib/pacha/.config/pacha/reglas.ron || { echo 'pacha: falta /var/lib/pacha/.config/pacha/reglas.ron — son las REGLAS del usuario, no un default; vienen de ~/.config/pacha/ del origen' >&2; exit 78; }; mkdir -p /run/pacha && chown pacha:pacha /run/pacha; cd /var/lib/pacha || exit 78; exec /usr/bin/setuidgid pacha /usr/bin/pacha daemon"]
|
|
envp = [["PATH", "/usr/bin:/bin"], ["HOME", "/var/lib/pacha"], ["USER", "pacha"], ["XDG_RUNTIME_DIR", "/run/pacha"]]
|
|
networking = "full"
|
|
cgroup = "arje.slice/pacha"
|
|
restart = { initial_ms = 1000, max_ms = 30000 }
|