SergioandClaude Opus 5
4d77d232d3
Tres cosas, y las tres quitan vueltas. 1. NO HACE FALTA NINGUNA CREDENCIAL EN EL WORKER, Y TAMPOCO UN USUARIO NUEVO `tawasuyu/tawasuyu` y `sergio/takana` son repos PÚBLICOS en el gitea. Las 23 recetas que apuntaban a `gitea@git.tawasuyu.net` (SSH, que exige la clave que es el SSH de todo) pasan a `https://git.tawasuyu.net/…`. La URL es locator y NO entra en `hash_inputs` (ADR 0013): hecho con control antes/después, **ningún ArtifactHash se movió**. Medido en el worker: `git clone --mirror --filter=blob:none` + `git archive` extrae el árbol (155 M) **sin una sola credencial**. Un usuario propio en gitea sólo haría falta para un repo PRIVADO; hoy ninguna receta usa uno. Si mañana hace falta, es una cuenta de máquina con acceso al repo que toque — nunca la clave personal. De paso, tres recetas decían «HUB-ONLY: el worker secretless recibe Connection refused». Ya no es cierto y el comentario decía lo contrario de lo que pasa: corregido en las tres. 2. LA COPIA FUERA LA DA LA MUDANZA, NO GITHUB (decisión del usuario) El «paso 1: espejar los 26 repos» deja de ser el paso 1. En cuanto el gitea vive en la caja nueva, esos repos dejan de existir sólo en la máquina que se borra — que es lo que el paso pedía. El objetivo es dejar de pagar dos máquinas, no sumar una dependencia. `espejar-repos.sh` queda como herramienta disponible. 3. EL §9 REESCRITO: qué está hecho, qué falta y en qué orden Hecho y cerrado: la caja arranca takana puro · store/grafos/granja/respaldo · repo firmado · la imagen del perfil servidor con gitea sirviendo 200 supervisado por arje · `arjectl` · y el ensayo con los datos REALES de gioser corriendo sobre takana. Falta, en orden: actualizar la caja a la imagen nueva (`upgrade`, no `dd`) → mudar los datos del gitea (`.backup` + rsync, con el origen parado en el corte) → caddy con los 6 dominios vivos → DNS → verificar desde fuera con un clone real → el resto de servicios del censo → borrar gioser con las 8 puertas en verde. Bloqueantes con su tamaño: `git` sellado sin `remote-http` (afecta a clonar DESDE una caja takana, no al gitea que sirve; re-sella una raíz de `base`) y la puerta 5, que no bloquea la mudanza. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016Tf9T4vGzsMoT7eS8YzMFn
54 lines
3.6 KiB
TOML
54 lines
3.6 KiB
TOML
# arje-zero — init PID 1 de arje (ADR 0007), construido por el lab de takana como **puente
|
|
# build-side** hacia "arje es el init de takana".
|
|
#
|
|
# Receta Cargo: la fuente es el monorepo tawasuyu a un commit fijado (ADR 0006), `-p arje-zero`
|
|
# para construir sólo ese binario; las deps se vendorean en el fetch (Lote 6) ⇒ build `--offline`
|
|
# hermético. Estático con zig cc cross al target — lo que pide un PID 1 (sin loader del host).
|
|
#
|
|
# Es un PUENTE, no el init todavía: prueba que el lab cruza al repo de tawasuyu y produce el
|
|
# binario del init. Hacerlo PID 1 del rootfs (seed `card.json`, `arje-bus`, hammerd como Card de
|
|
# servicio) es el paso "init real" posterior (plan B.2 + contrato de runtime de arje). El plan C.3
|
|
# prefiere extraer arje-zero a un front-door standalone para no vendorear el monorepo entero;
|
|
# sourcearlo del monorepo pinned es el interino, igual que hammerd desde el repo takana.
|
|
|
|
name = "arje-zero"
|
|
version = "0.0.1"
|
|
license = "MIT"
|
|
|
|
# ── POR QUÉ SE MOVIÓ EL PIN (2026-07-30) ────────────────────────────────────────────────────────
|
|
# El runbook de GNOME pedía «arreglar el `identity mismatch` del Announce al bus del fractal (hoy
|
|
# sólo un WARN)». Eran dos cosas mal: no lo emite arje-logind-compat sino el `bus_mediator` de
|
|
# arje-zero, y **no había nada que arreglar acá — ya estaba arreglado río arriba**, en tawasuyu
|
|
# `ce96cfa8d` (2026-07-29). Nuestro binario era viejo, nada más: el log de la VM decía
|
|
# `identity mismatch — rechazando request` y la fuente actual dice `sigo como anónimo`.
|
|
#
|
|
# Y no era cosmético, aunque el log lo pareciera. El commit del fix se llama «apagar/reiniciar moría
|
|
# por un ENTE_ID heredado, no por permisos»: `ENTE_ID` se inyecta en el entorno del Ente y **lo
|
|
# hereda todo el árbol de procesos**, así que cualquier nieto reclamaba esa identidad con su propio
|
|
# pid, el mediador veía pid distinto y RECHAZABA la request entera. Con el fix degrada a anónimo, que
|
|
# es lo correcto: la identidad no se prueba, pero los verbos anónimos siguen andando.
|
|
#
|
|
# EL COMMIT ELEGIDO no es nuevo: es **el mismo que ya usa `arje-polkit-compat`**, de la rama
|
|
# `selfhost/arje-zero-attest-lockfile`. Se llegó a él descartando el camino obvio: la rama vieja
|
|
# (`selfhost/arje-zero-lockfile`, 9967b02c) está **3951 commits detrás de main** y el cherry-pick del
|
|
# fix choca contra ficheros que allá ni existen — este mismo `bus_mediator.rs` creció 966 líneas en el
|
|
# medio. O sea que arje-zero se reescribió, y traer «sólo el fix» era ficción. La rama de attest, en
|
|
# cambio, ya CONTIENE `ce96cfa8d`, ya versiona el `Cargo.lock` de la raíz (lo mismo que motivaba la
|
|
# rama vieja) y ya está probada: es el árbol del que salen los dos compat daemons. Las tres recetas
|
|
# tawasuyu quedan en un solo commit, que es una propiedad que vale por sí sola.
|
|
[source]
|
|
# El `commit` es el identificador inmutable (la URL es sólo locator, no entra al hash). Sin el
|
|
# `Cargo.lock` del workspace el monorepo lo gitignora, el fetch vendorea SIN --locked ⇒ las deps
|
|
# derivan en el tiempo y arje-zero (y of_tree(stage1)) deja de ser reproducible.
|
|
repo = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
|
|
commit = "98db584fd28d9ff2bf34c9cf7d7db2e1de0b3fd0"
|
|
# Este árbol COMMITEA su propio `vendor/` (la copia parcheada de smithay que mirada necesita) y el
|
|
# `cargo vendor` de takana lo pisaría. Ver [[takana-cargo-vendor-clobbers-project-vendor]].
|
|
cargo_vendor_dir = ".hammer-cargo-vendor"
|
|
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "static"
|
|
flags = ["-p", "arje-zero"]
|