From 4b52acae06670c152875b6d41ba675faa4f38f0b Mon Sep 17 00:00:00 2001 From: Sergio Date: Fri, 18 Sep 2026 14:52:12 +0000 Subject: [PATCH] =?UTF-8?q?la=20batuta:=20los=20tres=20repos=20al=20lado?= =?UTF-8?q?=20y=20los=20sitios=20public=C3=A1ndose=20solos?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit terapeuta y los .ec quedan decididos —respaldar, no mudar, y los dominios vencieron hace tiempo—, lo que explica el NXDOMAIN del §10 y lo saca de los bloqueos. El gitea de la caja YA tenía sergio/takana.git al lado de sergio/tawasuyu.git; lo que faltaba era el árbol de trabajo. Los tres clones quedan en /work/sergio de sergio:sergio y los tres EMPUJAN: se le generó clave en la caja y se registró en su cuenta de gitea por la API con un token de `gitea admin`. Y los sitios pasan a servirse de los clones, así que publicar es `git pull`. El contenido estaba al día —se comparó lo servido con lo que generan hoy los repos y coincidía byte a byte—; lo roto era el modelo: cuando el repo cambiara, la web no se iba a enterar, y eso no se nota porque un sitio viejo responde 200 igual que uno nuevo. Lo de humanoid es distinto: su repo es el proyecto Android y lo que se sirve son APK ya construidos, salida de release que no vive en ningún repo. Refrescar esa página no es publicar, es compilar. Co-Authored-By: Claude Opus 5 (1M context) --- docs/29-mudanza.md | 50 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/docs/29-mudanza.md b/docs/29-mudanza.md index 3d45f9fd..eb6cfd9e 100644 --- a/docs/29-mudanza.md +++ b/docs/29-mudanza.md @@ -1116,3 +1116,53 @@ Eso importa porque **quedan 127 de 150 entradas de datos SIN DECIDIR** en > borrado no es capacidad sino **datos sin clasificar en una máquina en la que ya no se puede entrar**. > El orden correcto es: rescate → bajar lo que el usuario marque → recién ahí borrar. > ⛔ Y nada de esto se hace sin que el usuario lo pida por su nombre: gioser es servidor protegido. + +## 11. La batuta: repos y sitios listos para trabajar DESDE la caja *(2026-09-18)* + +### terapeuta y los `.ec` — decidido + +El usuario decidió **respaldar, no mudar**, y los dominios `.ec` **vencieron hace tiempo**. Eso +explica el NXDOMAIN del §10 y **cierra el punto**: no son un bloqueo para apagar gioser. + +### Los repos: los tres al lado, y de `sergio` + +``` + /work/sergio/takana ← sergio/takana.git (estaba en gitea; faltaba el clon de trabajo) + /work/sergio/tawasuyu ← tawasuyu/tawasuyu.git + /work/sergio/gioser-web ← sergio/gioser-web.git (sólo estaba en gitea: no había clon) +``` + +El gitea de la caja ya tenía `sergio/takana.git` **al lado de** `sergio/tawasuyu.git` —y la org +`tawasuyu` con sus 21 repos—; lo que faltaba era el **árbol de trabajo**. Los tres quedan en +`/work/sergio`, de `sergio:sergio`, y **los tres empujan**: se le generó a `sergio` una clave en la +caja y se registró en su cuenta de gitea por la API (con un token de `gitea admin`). Comprobado con +`git push --dry-run` en los tres. + +### Los sitios: publicar pasa a ser `git pull` + +Lo que la mudanza dejó eran **copias a mano** —4,2 G del monorepo sólo para `tawasuyu.net`— sin forma +de refrescarlas. El contenido estaba, de hecho, **al día**: se comparó lo servido con lo que generan +hoy los repos y coincidía byte a byte. Lo que estaba roto era el **modelo**: cuando el repo cambiara, +la web no se iba a enterar, y eso no se nota, porque **un sitio viejo responde 200 igual que uno +nuevo**. + +Ahora Caddy sirve directo de los clones: + +| sitio | raíz | +|---|---| +| `tawasuyu.net`, `www` | `/work/sergio/tawasuyu` (con los rewrites a `web/tawasuyu-web`) | +| `gioser.net` | `/work/sergio/gioser-web/` | +| `takana.gioser.net`, `hifas.gioser.net` | `/work/sergio/gioser-web/{takana,hifas}` — las genera `hermanas.py` | +| `gioser.net/{humanoid,muestras,vivo,ende,reencuentro}` | `/work/www/gioser-web/…` — **medios**, no están en git | + +`scripts/servidor/publicar-webs.sh` hace el ciclo entero: `pull --ff-only` (no pisa cambios locales +de un árbol que está sirviendo), regenera las dos hermanas —`hermanas.py` trae el destino **cableado** +a `/home/sergio/gioser-web`, ruta de gioser que acá no existe, así que se le pasa el del clon sin +tocar ese repo— y **comprueba**: lo servido byte a byte contra el disco, los medios en 200, y +`/.git/config` en **404**, porque servir desde un clon no puede exponer el repo. Liberados **4,2 G**. + +⚠ **Lo de `humanoid` es distinto y conviene decirlo:** su repo es el proyecto **Android** (gradle: +consola, cubo, keyboard, launcher, matiz, nimbo, nonet, notas), y lo que se sirve en +`gioser.net/humanoid` son **APK ya construidos** — salida de release que no vive en ningún repo. +Refrescar esa página no es publicar: es **compilar**, y pide Android SDK + Java, que la caja no tiene. +