gioser

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

TOML 1471Shell 173Rust 105Markdown 943545 Definiciones

cerrar el intermedio: el gitea viejo apagado DE VERDAD, el :22 cerrado y los datos respaldados

⚠ EL GITEA VIEJO HABÍA VUELTO A ARRANCAR. Media hora después del corte, gioser servía otra vez en
:3002. `arjectl list-units` ya no lo mostraba —el stop de arje seguía en pie— y el proceso tenía
ppid ≠ 1: lo levantó **OpenRC**, que lo tenía en el runlevel `default`. Dos supervisores para el
mismo servicio, y parar uno no para el otro. Antes del corte pasaba lo contrario: `rc-service stop`
decía «already stopped» con el proceso vivo, porque quien lo tenía era arje. La pregunta no es
«¿está parado?» sino «¿QUIÉN lo tiene?», y hay que responderla dos veces.
Arreglado con `rc-update del gitea default` + `rc-service gitea stop`.

El origen deja de servir git: los tres bloques salen del Caddyfile de gioser (con respaldo,
`validate` y `reload`) y quedan 16; control inmediato de que no rompí lo demás —`sergio.gioser.net`
y `hifas.gioser.net` siguen en 200—. `gitea.gioser.net` pasa a A → la caja.

El `:22` cerrado sin perder el acceso: administración en **22022**, git por SSH en **2345**, y el 22
en `Connection refused`. La secuencia es la única segura: añadir el puerto nuevo → reiniciar →
ENTRAR por él → sólo entonces quitar el 22. Verificado en ese orden, y el clone por 2345 sigue.

🧨 Y lo que apareció al mirar: **los datos del gitea nunca estuvieron respaldados**.
`respaldo-storagebox.sh` cubre el STORE de artefactos, no `/var/lib/gitea` — los 44 repos vivían en
una sola copia. La mudanza no lo empeoró, pero lo vuelve urgente porque gioser se borra. Hecho hoy
desde la caja: snapshot de la DB con el servicio vivo + rsync a `u647150:gitea/` (1,7 G).

⚠ Al Storage Box se entra por el puerto **23**: el 22 da SFTP restringido y contesta «Permission
denied (publickey,password)», que se lee como «no tengo la clave» teniendo la clave perfecta.

Pendiente: que ese respaldo sea periódico — un renglón en el cron de la caja.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Tf9T4vGzsMoT7eS8YzMFn

dc0927a028ce2952c11430e3c9bcdaf3b133b511 · por Sergio · (hace 1 mes) · padre 920d276b4 · ver el árbol en este commit

Delta semántico

Ninguna definición cambió: el cambio es de texto, documentación o datos.

1 archivos · +43 −0

diff --git a/docs/28-servidor-de-produccion.md b/docs/28-servidor-de-produccion.md
index a56898d7..852c8917 100644
--- a/docs/28-servidor-de-produccion.md
+++ b/docs/28-servidor-de-produccion.md
@@ -1173,6 +1173,49 @@ del servidor nuevo, que es el sentido de la mudanza.
 
 `arjectl start openrc-gitea` en gioser y devolver los dos `git` a `CNAME → www`. Con TTL 60, minutos.
 
+### 6.15 Cerrar el intermedio: el viejo apagado de verdad, el `:22` cerrado y los datos respaldados
+
+#### ⚠ El gitea viejo había VUELTO a arrancar — y lo arrancó OTRO supervisor
+
+Media hora después del corte, gioser volvía a servir en `:3002`. `arjectl list-units` **ya no lo
+mostraba** (el `stop` de arje seguía en pie) y el proceso tenía **`ppid ≠ 1`**: lo había levantado
+**OpenRC**, que lo tenía en el runlevel `default`. O sea **dos supervisores para el mismo servicio**
+—la card `openrc-gitea` de arje y el runlevel de OpenRC— y parar uno no para el otro.
+
+    rc-update del gitea default   # que no vuelva
+    rc-service gitea stop         # ahora sí: OpenRC lo arrancó, OpenRC sabe pararlo
+
+Antes del corte pasaba lo contrario (`rc-service … stop` decía *«already stopped»* con el proceso
+vivo, porque quien lo tenía era arje). **La pregunta no es «¿está parado?» sino «¿quién lo tiene?»**,
+y hay que responderla dos veces.
+
+#### El origen deja de servir git, y se comprueba que no se rompió lo demás
+
+Los tres bloques (`git.gioser.net`, `git.tawasuyu.net`, `gitea.gioser.net`) salen del Caddyfile de
+gioser —con respaldo previo, `caddy validate` y `reload`—, y quedan 16. Control inmediato:
+`sergio.gioser.net` y `hifas.gioser.net` siguen en **200**. `gitea.gioser.net` pasa a `A` → la caja,
+donde ya está su `redir`.
+
+#### El `:22` cerrado, sin perder el acceso
+
+Administración en **22022**, git por SSH en **2345**, y el **22 cerrado** (`Connection refused`) para
+sacarse de encima el barrido de bots. La secuencia importa y es la única segura: **añadir** el puerto
+nuevo → reiniciar → **entrar por él** → sólo entonces quitar el 22. Comprobado en ese orden, y el
+`git clone ssh://…:2345` sigue funcionando después.
+
+#### 🧨 Los datos del gitea NUNCA estuvieron respaldados
+
+`respaldo-storagebox.sh` respalda el **store de artefactos**, no `/var/lib/gitea`. O sea que los 44
+repos vivían en una sola copia — en gioser antes, en la caja ahora. La mudanza no lo empeoró, pero sí
+lo hace urgente: **gioser se borra**. Hecho hoy desde la caja: snapshot de la DB con el servicio vivo
++ `rsync` a `u647150:gitea/` — **1,7 G** (`datos/` + `gitea.db` de 314 M).
+
+⚠ **Al Storage Box se entra por el puerto 23**, no el 22: el 22 da SFTP/SCP restringido y contesta
+`Permission denied (publickey,password)`, que se lee como *«no tengo la clave»* cuando la clave está
+perfecta. Pasó en las dos máquinas antes de mirar el script (`SB_PORT=23`).
+
+**Pendiente**: que ese respaldo sea periódico, no de una vez. Es un renglón en el cron de la caja.
+
 ## 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: