From 2e3b8101c03a1a003746d4ca8d85a686fe48b3c6 Mon Sep 17 00:00:00 2001 From: Sergio Date: Mon, 21 Sep 2026 19:16:05 +0000 Subject: [PATCH] =?UTF-8?q?publicar-repo:=20como=20root,=20el=20scratch=20?= =?UTF-8?q?de=20build=20va=20aparte=20=E2=80=94=20si=20no,=20envenena=20el?= =?UTF-8?q?=20=C3=A1rbol=20del=20usuario?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `work_root` sale de `dirname(store)/work`, o sea `/work` con el store en `/store`, y ahí `sources` y `out` son ENLACES a `/work/sergio/work/…`, que es del usuario. Publicar como root dejaría directorios de root en su árbol y su siguiente build moriría con un permiso denegado que no menciona la causa. No es hipotético: root ya congeló el clon de tawasuyu del dueño dejándole 24 entradas suyas dentro del `.git`, y del lado de root no falló nada (ver publicar-webs.sh). Si corre como root y nadie fijó TAKANA_WORK, lo manda a /var/tmp/takana-publicar-work y lo dice. Comprobado que el override no mueve el hash: zsh sella en b3:0be3630d… con y sin él. Y el mensaje final deja de decir «falta el vhost» cuando lo acaba de poner: si se instaló y aun así no responde, lo que hay que mirar es el certificado, el DNS y el repo, en ese orden. --- docs/28-servidor-de-produccion.md | 8 ++++++++ scripts/servidor/publicar-repo.sh | 13 +++++++++++++ 2 files changed, 21 insertions(+) diff --git a/docs/28-servidor-de-produccion.md b/docs/28-servidor-de-produccion.md index 63a589f8..ff5e2d68 100644 --- a/docs/28-servidor-de-produccion.md +++ b/docs/28-servidor-de-produccion.md @@ -589,6 +589,14 @@ no tiene el admin abierto)*: El orden es lo único que lo hace seguro: copia → añadir → `caddy validate` → **sólo entonces** `reload`. Un reload con la config rota no tira el sitio nuevo: tira los 19. +⚠ **Y root no escribe en el árbol del usuario.** `work_root` sale de `dirname(store)/work` ⇒ con el +store en `/store` es `/work`, donde `sources` y `out` son **enlaces a `/work/sergio/work/…`**, que es +del usuario (CLAUDE.md §3 bis). Publicar como root dejaría ahí directorios de root y el siguiente +build suyo moriría con un permiso denegado que no menciona la causa — es exactamente lo que ya pasó +cuando root hizo `git pull` en el clon de tawasuyu y lo congeló para el dueño (`publicar-webs.sh`). +El guion, si corre como root y nadie fijó `TAKANA_WORK`, lo manda a `/var/tmp/takana-publicar-work` +y lo dice. Comprobado que el override no mueve el hash: `zsh` sella en `b3:0be3630d…` igual. + ⚠ **Y trae su propia guarda contra el error más fácil de cometer:** si el `takana` de la caja es anterior al §5.5 (se detecta porque no conoce `outdated`), **aborta antes de publicar**. Con uno viejo el repo sale con las 16 recetas multi-parche irreproducibles y 8 paquetes prometiendo un diff --git a/scripts/servidor/publicar-repo.sh b/scripts/servidor/publicar-repo.sh index 1025d3c2..b164d3cf 100755 --- a/scripts/servidor/publicar-repo.sh +++ b/scripts/servidor/publicar-repo.sh @@ -68,6 +68,19 @@ export KEY exit 2 } +# ⚠ ROOT NO ESCRIBE EN EL ÁRBOL DEL USUARIO. `work_root` sale de `dirname(store)/work`, o sea `/work` +# con el store en `/store` — y ahí `sources` y `out` son ENLACES a `/work/sergio/work/…`, que es del +# usuario. Publicar como root dejaría directorios de root en su árbol y el siguiente build suyo +# moriría con un permiso denegado que no menciona esto. Ya pasó con otro guion: root hizo `git pull` +# en el clon de tawasuyu, dejó 24 entradas suyas dentro del `.git` y congeló el clon para el dueño +# sin que nada fallara del lado de root (ver `publicar-webs.sh`). Así que el scratch va aparte. +if [ "$(id -u)" = "0" ] && [ -z "${TAKANA_WORK:-}" ]; then + TAKANA_WORK="${TAKANA_WORK_ROOT:-/var/tmp/takana-publicar-work}" + export TAKANA_WORK + install -d -m 755 "$TAKANA_WORK" + echo "==> como root: scratch de build en $TAKANA_WORK (no en el árbol del usuario)" +fi + echo "==> publicando el perfil '$PERFIL' en $DESTINO" install -d -m 755 "$DESTINO" PERFIL="$PERFIL" STORE="$STORE" REPO="$DESTINO" TRUST="$TRUST" TAKANA="$TAKANA" \