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
This commit is contained in:
@@ -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:
|
||||
|
||||
Reference in New Issue
Block a user