Files
takana/scripts/farm/worker-depositar.sh
Sergio aacee245d6 takana: el worker pasa a /opt/takana y takana-farm.service
Renombrado el directorio del worker y la unit, con las tres units del repo
(farm, deadman service y timer). Todas las rutas /opt/hammer del hub pasan a
/opt/takana: eran defaults REMOTE= y HAMMER_DIR=, mas los systemctl/journalctl
que nombraban la unit sin el sufijo .service, que el primer sed no casaba.

Orden, para que no quedara partido: el hub siembra por rsync a una ruta fija,
asi que se saco el cron ANTES de mover. Si se movia el worker con el hub
apuntando a la ruta vieja, la siguiente cosecha recreaba /opt/hammer y quedaban
dos arboles.

Verificado de punta a punta:
- el worker cerro un ciclo de build REAL desde /opt/takana (dunst sellado, 1/1)
- una cosecha completa del hub contra la ruta nueva: siembra, manifiesto, los
  nueve grafos, static-audit (691 estaticos, MIENTEN 0) y estado pusheado
- la unit vieja quedo deshabilitada y borrada; /opt tiene una sola entrada

NO se tocan dos referencias a /opt/hammer que siguen siendo CORRECTAS:
docs/23-plan-rehasheo.md describe rutas EMBEBIDAS en artefactos ya construidos
—que literalmente dicen /opt/hammer/work en sus secciones .debug— y el HANDOFF
de la noche de KDE es registro. Cambiarlas haria que los documentos mientan.
2026-09-09 20:20:16 +00:00

57 lines
3.8 KiB
Bash
Executable File

#!/usr/bin/env bash
# worker-depositar.sh — CORRE EN EL WORKER. Sube al buzón del Storage Box lo que selló y todavía no
# está respaldado. El laptop no participa: la ruta es worker→box, por dentro de Hetzner.
#
# ── POR QUÉ NO LO HACE EL LAPTOP ───────────────────────────────────────────────────────────────
# Medido el 2026-08-09: el uplink de la oficina da 440 kB/s y el tramo interno de Hetzner 122 MB/s
# — 280 veces más. Cualquier diseño que haga pasar los bytes por el laptop no se completa nunca.
# El laptop manda ÓRDENES (la promoción es un `mv`, cero bytes); los DATOS van por acá.
#
# ── LAS DOS CREDENCIALES, Y POR QUÉ HACEN FALTA LAS DOS ────────────────────────────────────────
# `sub1` (sólo lectura, home `takana`) sirve para PREGUNTAR qué hay ya respaldado. Sin eso el worker
# resubiría el corpus entero en cada ciclo.
# `sub2` (escritura, home `incoming`) es el BUZÓN donde deposita. No alcanza a `takana/store`: el
# respaldo consolidado no está dentro de su home. Ver `respaldo-subcuenta.sh`.
#
# ── UN SOLO rsync CON --files-from, NO UNO POR ARTEFACTO ───────────────────────────────────────
# El store comparte ficheros entre artefactos por ENLACE DURO. `-H` sólo preserva los enlaces que ve
# DENTRO de una misma corrida: con un rsync por directorio, cada artefacto viaja como si fuera único
# y el buzón llega inflado. Una sola invocación con la lista completa los ve todos.
set -uo pipefail
STORE="${STORE:-/opt/takana/store}"
KEY="${KEY:-/root/.ssh/sb_sub}"
RO_HOST="${RO_HOST:-u647150-sub1.your-storagebox.de}"; RO_USER="${RO_USER:-u647150-sub1}"
BZ_HOST="${BZ_HOST:-u647150-sub2.your-storagebox.de}"; BZ_USER="${BZ_USER:-u647150-sub2}"
SSH_SB="ssh -4 -p 23 -i $KEY -o StrictHostKeyChecking=no -o ServerAliveInterval=30"
ART='^[0-9a-f]{64}-'
TMP="$(mktemp -d)"; trap 'rm -rf "$TMP"' EXIT
ls "$STORE" 2>/dev/null | grep -E "$ART" | sort -u > "$TMP/local.txt"
$SSH_SB "$RO_USER@$RO_HOST" 'ls store' 2>/dev/null | grep -E "$ART" | sort -u > "$TMP/resp.txt"
N_L=$(wc -l < "$TMP/local.txt"); N_R=$(wc -l < "$TMP/resp.txt")
# Un listado vacío del respaldo es un fallo de red disfrazado de «no hay nada respaldado». Tomarlo
# por bueno significaría resubir el corpus entero por gusto.
if [ "$N_R" -eq 0 ]; then
echo "⚠ el respaldo devolvió 0 artefactos — no deposito (¿enlace caído?)" >&2; exit 1
fi
comm -23 "$TMP/local.txt" "$TMP/resp.txt" > "$TMP/nuevos.txt"
N_N=$(wc -l < "$TMP/nuevos.txt")
echo "==> store $N_L · respaldo $N_R ⇒ a depositar $N_N"
[ "$N_N" -eq 0 ] && { echo " nada nuevo"; exit 0; }
# `--files-from` con los nombres a secas (son directorios del store) + `-r` para bajar en cada uno.
# `--info=progress2` SÓLO con terminal: sin TTY reescribe la misma línea con \r y, como nadie
# interpreta el retorno de carro, el «progreso» se acumula en miles de copias de la misma línea. Un
# depósito de 8 segundos dejó así un log ilegible; en el latido, cada media hora, sería peor.
PROG=""; [ -t 1 ] && PROG="--info=progress2"
# shellcheck disable=SC2086
rsync -aHr --files-from="$TMP/nuevos.txt" --partial-dir=.rsync-partial $PROG \
-e "$SSH_SB" "$STORE/" "$BZ_USER@$BZ_HOST:store/" || { echo "⚠ el depósito falló"; exit 1; }
# Guardián: recontar el buzón. «rsync salió 0» no es «llegaron N».
EN_BUZON=$($SSH_SB "$BZ_USER@$BZ_HOST" 'ls store' 2>/dev/null | grep -cE "$ART")
echo "==> buzón: $EN_BUZON artefactos (depositados esperados: $N_N)"
[ "$EN_BUZON" -ge "$N_N" ] || { echo "⚠ el buzón tiene MENOS de lo depositado"; exit 1; }
echo " ahora el hub promueve con scripts/farm/respaldo-promover.sh"