la batuta: los tres repos al lado y los sitios publicándose solos

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) <noreply@anthropic.com>
This commit is contained in:
Sergio
2026-09-18 14:52:12 +00:00
co-authored by Claude Opus 5
parent 69a93a9d0d
commit 4b52acae06
+50
View File
@@ -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.