takana

2,761 Commits 1 Branch 0 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
SergioandClaude Opus 5	4d77d232d3	la mudanza sin terceros: las fuentes de tawasuyu por HTTPS público, y el orden del cutover 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	2026-09-14 18:59:31 +00:00
SergioandClaude Opus 5	fd09ca77b0	arjectl en la imagen: relanzar en caliente — y el genesis NO alcanzaba para eso El servicio que falla y agota su backoff sólo se podía recuperar reiniciando la máquina entera. Ya no. Y no hubo que escribir nada: el cliente existía en tawasuyu y el crate se llama `arje-ctl` (el binario, `arjectl`). Buscarlo por `arjectl` no lo encontraba, y de ahí salió mi conclusión falsa de que había que implementarlo — el protocolo ya traía ListEntes, SpawnCardFromDisk, StopCardFromDisk, KillEnte y EnteStatus. `recipes/arjectl.toml` lo construye del MISMO commit que `arje-zero` (98db584f), y no por comodidad: el bus es un protocolo entre dos binarios y un cliente de otro árbol puede conectar sin entenderse con el init. Publica sólo `arjectl`; el crate también produce un `systemctl` de camuflaje que acá no se instala — en una distro sin systemd, ese nombre en el PATH invita a escribir runbooks con el verbo ajeno. ⚠ EL HUECO QUE SÓLO SE VE USÁNDOLO: el genesis de la seed dice qué arranca AL BOOT, pero `start`/`restart` usan `SpawnCardFromDisk`, que lee `/etc/arje/cards.d/<label>.json` — y el armado no lo escribía: $ arjectl start gitea Error: arje-zero rechazó: card gitea: No such file or directory (buscada en /etc/arje/cards.d/gitea.json) Son dos preguntas distintas —qué arranca solo, y qué se puede encarnar a pedido— y arje las responde desde sitios distintos. `inyectar-cards.py` escribe ahora los dos árboles, y en `cards.d` escribe TODAS las cards, no sólo las nuevas: `sshd` viene del product-rootfs y tampoco era relanzable. Medido con la VM arrancada UNA sola vez: la imagen trae `cards.d/{gitea,sshd}.json` · `list-units` da PID/CPU/MEM/HILOS/reinicios · poner el `app.ini` + `arjectl start gitea` ⇒ GET / 200 sin reiniciar (uptime 6 min) · `arjectl restart gitea` cambia el PID (118 → 192) y sigue en 200. ⚠ Y un aviso que costó un HTTP intermitente: `arjectl start` sobre un Ente YA VIVO lo DUPLICA — `SpawnCardFromDisk` no deduplica por label y arje le da un ULID nuevo. En gitea el síntoma fue `unable to lock level db … resource temporarily unavailable` y un `[F]`: dos servidores peleando por el mismo estado. Para relanzar se usa `restart`, o se mira `list-units` antes. Un `start` idempotente es trabajo de arje, no de esta imagen. ⚠ Deuda anotada, no barrida: `arjectl` va en `perfil.servidor` porque este frente es el que lo pagó. TODA imagen de takana corre arje-zero como PID 1 y ninguna se puede operar sin él ⇒ el argumento para subirlo a `base` es fuerte, y es una línea. Se deja como decisión. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016Tf9T4vGzsMoT7eS8YzMFn	2026-09-14 17:59:11 +00:00

Author

SHA1

Message

Date

SergioandClaude Opus 5

4d77d232d3

la mudanza sin terceros: las fuentes de tawasuyu por HTTPS público, y el orden del cutover

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

2026-09-14 18:59:31 +00:00

SergioandClaude Opus 5

fd09ca77b0

arjectl en la imagen: relanzar en caliente — y el genesis NO alcanzaba para eso

El servicio que falla y agota su backoff sólo se podía recuperar reiniciando la máquina entera.
Ya no. Y no hubo que escribir nada: **el cliente existía en tawasuyu y el crate se llama `arje-ctl`**
(el binario, `arjectl`). Buscarlo por `arjectl` no lo encontraba, y de ahí salió mi conclusión falsa
de que había que implementarlo — el protocolo ya traía ListEntes, SpawnCardFromDisk,
StopCardFromDisk, KillEnte y EnteStatus.

`recipes/arjectl.toml` lo construye del MISMO commit que `arje-zero` (98db584f), y no por comodidad:
el bus es un protocolo entre dos binarios y un cliente de otro árbol puede conectar sin entenderse
con el init. Publica sólo `arjectl`; el crate también produce un `systemctl` de camuflaje que acá no
se instala — en una distro sin systemd, ese nombre en el PATH invita a escribir runbooks con el
verbo ajeno.

⚠ EL HUECO QUE SÓLO SE VE USÁNDOLO: el genesis de la seed dice qué arranca AL BOOT, pero
`start`/`restart` usan `SpawnCardFromDisk`, que lee `/etc/arje/cards.d/<label>.json` — y el armado
no lo escribía:

    $ arjectl start gitea
    Error: arje-zero rechazó: card gitea: No such file or directory
           (buscada en /etc/arje/cards.d/gitea.json)

Son dos preguntas distintas —qué arranca solo, y qué se puede encarnar a pedido— y arje las responde
desde sitios distintos. `inyectar-cards.py` escribe ahora los dos árboles, y en `cards.d` escribe
TODAS las cards, no sólo las nuevas: `sshd` viene del product-rootfs y tampoco era relanzable.

Medido con la VM arrancada UNA sola vez: la imagen trae `cards.d/{gitea,sshd}.json` · `list-units`
da PID/CPU/MEM/HILOS/reinicios · poner el `app.ini` + `arjectl start gitea` ⇒ **GET / 200 sin
reiniciar** (uptime 6 min) · `arjectl restart gitea` cambia el PID (118 → 192) y sigue en 200.

⚠ Y un aviso que costó un HTTP intermitente: **`arjectl start` sobre un Ente YA VIVO lo DUPLICA** —
`SpawnCardFromDisk` no deduplica por label y arje le da un ULID nuevo. En gitea el síntoma fue
`unable to lock level db … resource temporarily unavailable` y un `[F]`: dos servidores peleando por
el mismo estado. Para relanzar se usa `restart`, o se mira `list-units` antes. Un `start` idempotente
es trabajo de arje, no de esta imagen.

⚠ Deuda anotada, no barrida: `arjectl` va en `perfil.servidor` porque este frente es el que lo pagó.
TODA imagen de takana corre arje-zero como PID 1 y ninguna se puede operar sin él ⇒ el argumento
para subirlo a `base` es fuerte, y es una línea. Se deja como decisión.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Tf9T4vGzsMoT7eS8YzMFn

2026-09-14 17:59:11 +00:00