SergioandClaude Opus 5
fd09ca77b0
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
146 lines
9.3 KiB
Bash
Executable File
146 lines
9.3 KiB
Bash
Executable File
#!/bin/sh
|
|
# servidor-image.sh — arma la imagen de disco del `perfil.servidor` lista para escribir en una caja
|
|
# Hetzner Cloud por rescue (SDD 28 §3). No inventa nada: encadena `hydrate-profile.py` +
|
|
# `install-image.sh`, que ya existían, y agrega lo que ninguno de los dos puede saber solo.
|
|
#
|
|
# ── LO QUE ESTE SCRIPT EXISTE PARA NO OLVIDAR (todo medido el 2026-09-10) ────────────────────────
|
|
#
|
|
# 1. EL KERNEL. `recipes/linux.toml` NO sirve para hcloud: apaga SCSI (`-d SCSI`) y el disco de una
|
|
# caja Hetzner lo maneja virtio-SCSI ⇒ arranca y no ve el disco. Va `linux-generic`, que sí trae
|
|
# `CONFIG_SCSI_VIRTIO=y` — dato que NO está en la receta (lo enciende `make defconfig`) y que sólo
|
|
# se ve en el `.config` que el artefacto publica.
|
|
#
|
|
# 2. EL INIT SE PISA. La clausura del perfil trae `busybox`, y su `/sbin/init -> ../bin/busybox` gana
|
|
# por hidratarse DESPUÉS del product-rootfs, borrando el `-> /usr/bin/arje-zero`. La imagen
|
|
# arrancaría perfecta con el init equivocado. Se restaura acá y además `install-image.sh` escribe
|
|
# su propio wrapper encima; el cmdline no lleva `init=` para que ese wrapper —que monta /store y
|
|
# /var/lib/hammer— sea el que corre.
|
|
#
|
|
# 3. EXDEV. El staging y la hidratación HARDLINKEAN, y un hardlink no cruza un montaje aunque sea el
|
|
# mismo disco. Con el store en un volumen (el layout normal de este repo) hay que trabajar del
|
|
# lado del store. Se comprueba y se aborta con un mensaje claro en vez de fallar fichero a fichero.
|
|
#
|
|
# 4. LA CLAVE. Sin `authorized_keys` la instalación remota deja una máquina viva e INALCANZABLE, que
|
|
# es peor que una que no arrancó. Es obligatoria: sin `AUTHKEYS` no se arma la imagen.
|
|
#
|
|
# Uso:
|
|
# AUTHKEYS=~/.ssh/github5.pub ./scripts/servidor-image.sh
|
|
#
|
|
# Env:
|
|
# AUTHKEYS pubkey a instalar para root (OBLIGATORIO)
|
|
# PERFIL perfil de targets.toml a hidratar (def servidor)
|
|
# STORE store desde el que hidratar (def /mnt/cosecha/store)
|
|
# WORKDIR dir de trabajo, MISMO montaje que STORE (def /mnt/cosecha/servidor-build)
|
|
# IMG imagen de salida (def $WORKDIR/servidor.img)
|
|
# KERNELPKG paquete del kernel (def linux-generic)
|
|
# ROOT_SIZE/STORE_SIZE/STATE_SIZE MiB de cada partición (def 6144/512/512)
|
|
set -eu
|
|
ROOT="$(cd "$(dirname "$0")/.." && pwd)"; cd "$ROOT"
|
|
|
|
PERFIL="${PERFIL:-servidor}"
|
|
STORE="${STORE:-/mnt/cosecha/store}"
|
|
WORKDIR="${WORKDIR:-/mnt/cosecha/servidor-build}"
|
|
IMG="${IMG:-$WORKDIR/servidor.img}"
|
|
KERNELPKG="${KERNELPKG:-linux-generic}"
|
|
ROOT_SIZE="${ROOT_SIZE:-6144}"; STORE_SIZE="${STORE_SIZE:-512}"; STATE_SIZE="${STATE_SIZE:-512}"
|
|
# El binario: en un hub de desarrollo está en `target/release`, en una caja instalada es
|
|
# `/usr/bin/takana` y `target/` ni existe. Es el bloqueo que ya costó una vez en la caja nueva
|
|
# («unhashable 875» con el lab bien): los scripts asumían árbol de desarrollo.
|
|
TAKANA="${TAKANA:-$ROOT/target/release/takana}"
|
|
[ -x "$TAKANA" ] || TAKANA="$(command -v takana || true)"
|
|
[ -n "$TAKANA" ] && [ -x "$TAKANA" ] || { echo "!! no encuentro el binario takana (probá TAKANA=/usr/bin/takana)" >&2; exit 2; }
|
|
|
|
[ -n "${AUTHKEYS:-}" ] || { echo "!! falta AUTHKEYS: una imagen sin clave deja la caja INALCANZABLE" >&2; exit 2; }
|
|
[ -r "$AUTHKEYS" ] || { echo "!! no puedo leer AUTHKEYS=$AUTHKEYS" >&2; exit 2; }
|
|
|
|
# ── guarda de EXDEV: el rootfs se arma con hardlinks contra el store ─────────────────────────────
|
|
mkdir -p "$WORKDIR"
|
|
m_store=$(findmnt -no TARGET -T "$STORE")
|
|
m_work=$(findmnt -no TARGET -T "$WORKDIR")
|
|
[ "$m_store" = "$m_work" ] || {
|
|
echo "!! STORE ($STORE → montaje $m_store) y WORKDIR ($WORKDIR → montaje $m_work) están en" >&2
|
|
echo " montajes DISTINTOS. El armado hardlinkea y un hardlink no cruza un montaje aunque sea" >&2
|
|
echo " el mismo disco. Poné WORKDIR bajo $m_store." >&2
|
|
exit 1
|
|
}
|
|
|
|
# ── 1. base: el product-rootfs sellado, que es quien trae /sbin/init -> arje-zero ────────────────
|
|
PDIR=$(ls -dt "$STORE"/*-product-rootfs 2>/dev/null | head -1)
|
|
[ -n "$PDIR" ] || { echo "!! no hay product-rootfs sellado en $STORE (corré 'takana bootstrap product')" >&2; exit 1; }
|
|
KDIR=$(ls -dt "$STORE"/*-"$KERNELPKG" 2>/dev/null | head -1)
|
|
[ -n "$KDIR" ] && [ -r "$KDIR/boot/bzImage" ] || { echo "!! no hay $KERNELPKG sellado con /boot/bzImage en $STORE" >&2; exit 1; }
|
|
|
|
RFS="$WORKDIR/rootfs"
|
|
echo "==> base : $(basename "$PDIR")"
|
|
echo "==> kernel : $(basename "$KDIR")"
|
|
rm -rf "$RFS"; mkdir -p "$RFS"
|
|
cp -al "$PDIR/." "$RFS/"
|
|
|
|
# ── 2. userland del perfil encima ────────────────────────────────────────────────────────────────
|
|
echo "==> hidratando perfil '$PERFIL'"
|
|
python3 scripts/hydrate-profile.py "$PERFIL" --into "$RFS" --store "$STORE" --keep
|
|
|
|
# ── 2 bis. las CUENTAS que los paquetes del perfil declaran (`[[user]]`, SDD 30) ─────────────────
|
|
# El `/etc/passwd` del product-rootfs trae `root` y `sshd` y nada más, porque es una constante de
|
|
# Rust. Un paquete cuyo demonio se niega a correr como root —`gitea` lo hace explícitamente— tiene
|
|
# su Card haciendo `setuidgid`, así que SIN esta línea el servicio arranca, muere y reintenta para
|
|
# siempre, y el log dice «unknown user», no «a la imagen le falta una cuenta».
|
|
#
|
|
# `--merge` fusiona por clave y es idempotente: componer dos veces no duplica. Si una cuenta ya está
|
|
# con OTRA línea, sale ≠0 sin tocar ningún fichero — y acá eso ABORTA la imagen a propósito: un
|
|
# rootfs con el uid equivocado produce ficheros de un dueño que no existe, y eso se descubre dentro
|
|
# de la VM, varios pasos más tarde.
|
|
USERPATHS=$(python3 scripts/targets.py --user-paths "$PERFIL")
|
|
if [ -n "$USERPATHS" ]; then
|
|
echo "==> cuentas : $(echo "$USERPATHS" | wc -l) receta(s) declaran usuarios"
|
|
# shellcheck disable=SC2086
|
|
"$TAKANA" --store "$STORE" users $USERPATHS --merge "$RFS"
|
|
else
|
|
echo "==> cuentas : ninguna receta del perfil declara [[user]]"
|
|
fi
|
|
|
|
# ── 2 ter. las CARDS de los servicios que el perfil arranca (SDD 30 §4c) ─────────────────────────
|
|
# Sin esto la imagen trae el binario, trae la cuenta… y NADIE lo arranca: la seed del producto sólo
|
|
# conoce las cards que `takana-bootstrap` hornea (`sshd`, `console-getty`, `hammerd`). Medido en la
|
|
# primera imagen de este perfil: `gitea` instalado, su usuario en `/etc/passwd`, y en el `genesis`
|
|
# NADA — un servidor que arranca perfecto sin el servicio por el que existe. La métrica no lo ve:
|
|
# `--services` dice que el perfil lo habilita, y lo habilita; lo que faltaba era el paso que lleva
|
|
# esa declaración a la imagen.
|
|
#
|
|
# `service-cards` es la ÚNICA traducción `[[service]]` → Card, y `inyectar-cards.py` sólo compone la
|
|
# seed (idempotente por label, y con `os.replace` porque la seed es un hardlink al store).
|
|
SVCPATHS=$(python3 scripts/targets.py --service-paths "$PERFIL")
|
|
if [ -n "$SVCPATHS" ]; then
|
|
# shellcheck disable=SC2086
|
|
"$TAKANA" --store "$STORE" service-cards $SVCPATHS > "$WORKDIR/cards.json"
|
|
echo "==> cards : $(python3 -c 'import json,sys; print(len(json.load(open(sys.argv[1]))))' "$WORKDIR/cards.json") card(s) de $(echo "$SVCPATHS" | wc -l) receta(s)"
|
|
python3 scripts/gnome/inyectar-cards.py "$RFS/ente/seed.card.json" "$WORKDIR/cards.json" "$RFS/etc/arje/cards.d"
|
|
else
|
|
echo "==> cards : el perfil no arranca ningún servicio de paquete"
|
|
fi
|
|
|
|
# ── 3. reparar el init que la hidratación pisó (ver cabecera, punto 2) ───────────────────────────
|
|
antes=$(readlink "$RFS/sbin/init" 2>/dev/null || echo "(fichero)")
|
|
ln -sf /usr/bin/arje-zero "$RFS/sbin/init"
|
|
echo "==> init : $antes → $(readlink "$RFS/sbin/init")"
|
|
[ -x "$RFS/usr/bin/arje-zero" ] || { echo "!! el rootfs no tiene /usr/bin/arje-zero" >&2; exit 1; }
|
|
|
|
# ── 4. la clave ──────────────────────────────────────────────────────────────────────────────────
|
|
install -d -m 700 "$RFS/root/.ssh"
|
|
install -m 600 "$AUTHKEYS" "$RFS/root/.ssh/authorized_keys"
|
|
echo "==> clave : $(wc -l < "$RFS/root/.ssh/authorized_keys") línea(s) en /root/.ssh/authorized_keys"
|
|
|
|
# ── 5. la imagen. SIN `init=`: así corre el wrapper de install-image.sh, que monta /store y el diario
|
|
# El serial primero y tty0 al final ⇒ /dev/console es tty0, que es lo que muestra la consola web
|
|
# de Hetzner; los mensajes del kernel salen por los dos.
|
|
CMDLINE="console=ttyS0,115200 console=tty0 root=PARTLABEL=hammer-root rw"
|
|
echo "==> cmdline : $CMDLINE"
|
|
ROOTFS="$RFS" STAGE="$WORKDIR/.stage" KERNEL="$KDIR/boot/bzImage" IMG="$IMG" \
|
|
ROOT_SIZE="$ROOT_SIZE" STORE_SIZE="$STORE_SIZE" STATE_SIZE="$STATE_SIZE" CMDLINE="$CMDLINE" \
|
|
./scripts/install-image.sh
|
|
|
|
echo
|
|
echo "✓ imagen del perfil '$PERFIL': $IMG"
|
|
echo " escribir en una caja Hetzner (con la caja en RESCUE):"
|
|
echo " zstd -T2 -3 -c $IMG | ssh root@<ip> 'zstd -d -c | dd of=/dev/sda bs=4M conv=fsync && sync'"
|