From ef2f9391d95d66bc92a59a33e2ab316c79325858 Mon Sep 17 00:00:00 2001 From: Sergio Date: Thu, 17 Sep 2026 16:05:48 +0000 Subject: [PATCH] =?UTF-8?q?puerta=205=20verde:=20la=20caja=20publica=20su?= =?UTF-8?q?=20repo=20firmado=20y=20se=20instala=20de=20=C3=A9l?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Estaba a medias desde el §5.4 por el lab. Con el lab instalado (§6.43), cerrada en dos movimientos, los dos en la caja: publicar: 171 paquetes con expected_hash anclado, 3 sin ancla, índice verificado contra ./trust, firmado con la clave de release que se mudó el 16-sep. Falló uno: os-release. instalar: `takana install duf --require-signed --trust ./trust` ⇒ «release: trusted (by release)», deps resueltas, apply OK, registrado. Bajo --prefix y --db propios, sin tocar el sistema. ⚠ El matiz honesto vale más que el verde: el artefacto YA ESTABA en el store, así que se ejercitó resolver + verificar firma + hidratar, NO reproducir desde fuente. Lo que el lab destrabó y sí quedó probado aparte es el HASH (§6.43, cuatro de cuatro iguales a gioser), que es donde moría antes. Queda sin ejercitar «paquete que no está en el store» — y en una caja de producción es discutible que se quiera: un servidor no tiene por qué compilar. Co-Authored-By: Claude Opus 5 (1M context) --- docs/28-servidor-de-produccion.md | 38 +++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/docs/28-servidor-de-produccion.md b/docs/28-servidor-de-produccion.md index f4cab48a..cd2b8770 100644 --- a/docs/28-servidor-de-produccion.md +++ b/docs/28-servidor-de-produccion.md @@ -2701,6 +2701,44 @@ Con las dos cosas, la poda hizo su trabajo por primera vez en la caja: ⇒ **En total, 32,2 G recuperados hoy en la caja**: 26,8 G de artefactos superados (§6.44) y 5,4 G de árboles de fuentes. `/store` al 62 %, `/work` al 29 %. +### 6.46 🚪 Puerta 5 verde: la caja publica su repo firmado **y se instala de él** *(2026-09-17)* + +La puerta 5 estaba a medias desde el §5.4 y el motivo era el de siempre: *el host no se puede +actualizar de sí mismo porque `install` reproduce desde fuente y eso exige el LAB*. Con el lab ya +instalado (§6.43), se cerró en dos movimientos, los dos corridos **en la caja**: + +**1. Publicar** — con su propia clave de release, la que se mudó el 2026-09-16 a +`/root/.config/takana/keys/`: + +``` + ==> ✓ el índice verifica contra ./trust + publicado: 171 con expected_hash anclado, 3 sin ancla. FALLARON: os-release +``` + +**2. Instalar de ese repo, en modo estricto** (`--require-signed`, que exige autoría del catálogo +verificada y no se conforma con que el `.swm` reproduzca): + +``` + release: trusted (by release) + install duf 0.9.1 ← dist/repo/duf-0.9.1.tkn + deps: resolviendo catálogo para 1 dep(s): go + caché: artefacto ya en el store hash=b3:abb3527d… name=duf + apply OK — source_patch=1 config_edit=0 init_rule=0 file_drop=0 + registrado duf (2 fichero(s)) +``` + +Se instaló bajo `--prefix /tmp/prueba-install` y con `--db` propio, para no tocar el sistema. + +⚠ **Y el matiz honesto, que vale más que el verde**: el artefacto **ya estaba en el store**, así que +el camino que se ejercitó fue *resolver + verificar firma + hidratar*, **no** *reproducir desde +fuente*. Lo que el lab destrabó y sí quedó probado aparte es el **hash** (§6.43: cuatro de cuatro +iguales a gioser), que era exactamente donde moría antes —«no pude leer el apk db del lab»—. Queda +sin ejercitar el caso «paquete que NO está en el store», que en una caja de producción además es +discutible que se quiera: un servidor no tiene por qué compilar. + +⇒ `os-release` es la única receta del perfil que no se pudo publicar; es la que lleva el logo y la +identidad de la distro, y su fallo queda anotado para mirarlo aparte. + ## 7. Reusar los scripts que ya existen, y no escribir de nuevo Pedido explícito del usuario. El inventario de lo que ya hace el trabajo: