manuales(RUN-20260819-A3B63B): Caddy: arquitectura de dos capas y alta de dominios con DNS-01/Route53

content/manuales/2026-08-19-run-20260819-a3b63b-caddy-arquitectura-de-dos-capas-y-alta-de-dominios-con-dns-01-route53.md

@@ -0,0 +1,99 @@
++++
+title = "Caddy: arquitectura de dos capas y alta de dominios con DNS-01/Route53"
+description = "Las dos capas de Caddy, cómo agregar un dominio interno con certificado real vía DNS-01/Route53, y los dos gotchas conocidos de propagación."
+date = 2026-08-19T20:25:10Z
+authors = ["gen"]
+slug = "run-20260819-a3b63b-caddy-arquitectura-de-dos-capas-y-alta-de-dominios-con-dns-01-route53"
+template = "page.html"
+weight = 26
+
+[taxonomies]
+categories = ["manuales"]
+tags = ["caddy", "dns-01", "route53", "tls"]
+systems = ["caddy"]
+
+[extra]
+id = "RUN-20260819-A3B63B"
+kind = "manuales"
+author_id = "gen"
+author_fingerprint = "SHA256:JhN1Tt4jYqWoJIznDJ6QkMAiOR6HFHr3xLz9aBJqmPg"
++++
+
+## Arquitectura: dos Caddys, dos capas
+
+```
+Internet ──HTTPS(443)──> Caddy #1 (mcps-vpn-server, IP pública)
+                             │ termina TLS real (Let's Encrypt)
+                             │ reenvía HTTP plano por el túnel WireGuard
+                             ▼
+                      mcps-hpc-01 (10.8.0.18)
+                             │
+                       Caddy #2 (ahí mismo)
+                             │ segundo enrutamiento por Host header
+              ┌──────────────┼──────────────┬─────────────┐
+              ▼               ▼              ▼             ▼
+        nginx/Apache/gunicorn/Grafana/etc (los backends reales)
+```
+
+- Config de Caddy #1: `/etc/caddy/Caddyfile` + `/etc/caddy/tenants/*.caddy`.
+- Config de Caddy #2: `/mnt/cephfs/hot/caddy/Caddyfile` (montado en el contenedor vía `container-caddy.service`, systemd+podman en `.18`).
+- `mcps-net` (red podman en `.18`) tiene `dns_enabled: false` — por eso el Caddyfile de ahí usa **IPs fijas**, no nombres de contenedor. Si un contenedor se recrea sin `--ip` fijo, su IP cambia y hay que actualizar el Caddyfile a mano. Ponga siempre `--ip 10.89.0.X` fijo a cualquier contenedor nuevo que Caddy vaya a referenciar ahí.
+
+## Dominios VPN-only vs. públicos
+
+Los dominios internos (Cockpit, Zammad, pgAdmin, RStudio, Jupyter, Snipe-IT, etc.) apuntan en Route53 a propósito a `10.8.0.18` (IP privada, solo alcanzable por VPN), nunca a la IP pública. Con eso, `tls internal` (certificado autofirmado) da warning de navegador — el patrón correcto es **DNS-01 vía Route53**, que da certificado real de Let's Encrypt sin necesitar reachability pública.
+
+## Prerrequisitos (infraestructura de una sola vez, ya existe)
+
+- Usuario IAM dedicado `caddy-route53-dns01`, con permisos mínimos: `route53:ChangeResourceRecordSets` y `route53:ListResourceRecordSets` sobre la zona `mcps-epcm.org` (`Z05793723RVTGN4VZAAUN`), más `GetChange`/`ListHostedZones*` (globales). Nunca usar las credenciales del usuario `Administrator`.
+- Imagen Caddy custom con el plugin de Route53 (la oficial no lo trae):
+  ```dockerfile
+  FROM caddy:builder AS builder
+  RUN xcaddy build --with github.com/caddy-dns/route53
+  FROM caddy:latest
+  COPY --from=builder /usr/bin/caddy /usr/bin/caddy
+  ```
+  Imagen: `localhost/caddy-route53:latest`.
+- Credenciales en `/etc/caddy-route53.env` (`root:root`, `600`), inyectadas al contenedor vía `--env AWS_ACCESS_KEY_ID --env AWS_SECRET_ACCESS_KEY` (forma "bare" de podman: toma el valor del entorno del proceso llamador, por eso el `EnvironmentFile=` en el systemd unit).
+
+## Procedimiento: agregar un dominio nuevo a este patrón
+
+1. En Route53, apunte el registro del dominio a `10.8.0.18` (VPN-only) o a la IP pública correspondiente (público).
+2. En `/mnt/cephfs/hot/caddy/Caddyfile`, agregue el bloque del sitio con:
+   ```caddy
+   tls {
+       dns route53 {
+           access_key_id {env.AWS_ACCESS_KEY_ID}
+           secret_access_key {env.AWS_SECRET_ACCESS_KEY}
+       }
+       propagation_delay 20s
+       propagation_timeout -1
+   }
+   ```
+3. `caddy validate` sobre el Caddyfile antes de aplicar.
+4. `caddy reload` (no reinicia el proceso, no tira el resto de sitios).
+
+## Por qué `propagation_timeout -1` y `propagation_delay 20s`, no el default
+
+La red de `.18` redirige por transparencia todo el tráfico DNS al resolver `132.248.204.1` (red UNAM), sin importar qué servidor le pidas — confirmado con `nslookup ... 8.8.8.8` desde dentro de un contenedor, devolviendo `NXDOMAIN` mientras el registro sí existía y propagaba bien visto desde `mcps-vpn-server`. El chequeo de propagación *propio* de Caddy (usando ese resolver secuestrado/con caché negativo viejo) se queda colgado indefinidamente.
+
+- `propagation_timeout -1`: Caddy no verifica localmente, deja que Let's Encrypt valide directo desde su red.
+- `propagation_delay 20s`: espera fija para dar tiempo real a Route53, evita condición de carrera si el registro aún no propagó del todo.
+
+Nota: esto **no** es una ruta de red real hacia la UNAM, solo el DNS configurado en el router — la salida real a internet de `.18` es Telmex (única default route). No hay forma de salir con IP de la UNAM desde esta infraestructura.
+
+## Verificación
+
+- `curl -v https://<dominio>.mcps-epcm.org` muestra `SSL certificate verify ok` con emisor Let's Encrypt, no un certificado autofirmado.
+- El sitio responde sin advertencia de certificado en el navegador (dentro de la VPN, si es VPN-only).
+
+## Solución de problemas
+
+- **`Duplicate Resource Record` al reintentar DNS-01**: si se mata/reinicia Caddy a medio intento, puede quedar un registro `_acme-challenge.<dominio>` huérfano en Route53 que choca con el siguiente intento. Bórrelo a mano:
+  ```bash
+  aws route53 list-resource-record-sets --hosted-zone-id Z05793723RVTGN4VZAAUN \
+    --query "ResourceRecordSets[?Name=='_acme-challenge.<dominio>.mcps-epcm.org.']"
+  # luego change-resource-record-sets con Action=DELETE y el mismo valor
+  ```
+- **El challenge se queda colgado indefinidamente**: confirme que el bloque `tls` tiene `propagation_timeout -1` — sin eso, Caddy intenta verificar la propagación usando el resolver secuestrado de la red de `.18` y nunca termina.
+- **Un contenedor backend cambia de IP y el sitio deja de responder**: confirme que el contenedor se recreó con `--ip` fijo; si no, actualice el Caddyfile a la IP nueva.

content/manuales/2026-08-19-run-20260819-e3a1c3-administrar-el-servidor-de-correo-docker-mailserver.md

@@ -0,0 +1,73 @@
++++
+title = "Administrar el servidor de correo (docker-mailserver)"
+description = "Dónde vive el servicio, cómo administrar cuentas y cómo enviar correo de prueba desde terminal."
+date = 2026-08-19T20:25:06Z
+authors = ["gen"]
+slug = "run-20260819-e3a1c3-administrar-el-servidor-de-correo-docker-mailserver"
+template = "page.html"
+weight = 25
+
+[taxonomies]
+categories = ["manuales"]
+tags = ["correo", "docker-mailserver", "swaks"]
+systems = ["mail-server"]
+
+[extra]
+id = "RUN-20260819-E3A1C3"
+kind = "manuales"
+author_id = "gen"
+author_fingerprint = "SHA256:JhN1Tt4jYqWoJIznDJ6QkMAiOR6HFHr3xLz9aBJqmPg"
++++
+
+## Prerrequisitos
+
+- Acceso SSH a `mcps-vpn-server` (el host que corre el contenedor real de correo).
+- Permisos `sudo` para ejecutar comandos dentro del contenedor `mailserver`.
+
+## Dónde vive
+
+- Contenedor `ghcr.io/docker-mailserver/docker-mailserver`, gestionado por `container-mailserver.service` (systemd + podman) en **`mcps-vpn-server`** (no en `mcps-hpc-01`).
+- Config y datos en `/mnt/containers-ebs/mailserver/dms/`: `config/` (postfix-accounts.cf, postfix-main.cf, opendkim, etc.), `mail-data/` (Maildir reales, por ejemplo `mail-data/mcps-epcm.org/<usuario>/`), `mail-logs/` (`mail.log` + 4 rotaciones, ~1 mes de retención).
+- Expuesto en `mail.mcps-epcm.org`, que resuelve directo a la IP pública del host.
+
+## Procedimiento: administrar cuentas
+
+```bash
+sudo podman exec mailserver setup email list                    # listar cuentas + tamaño
+sudo podman exec mailserver setup email update <correo> [<pass>] # cambiar password
+sudo podman exec mailserver setup email del <correo>              # dar de baja (borra Maildir)
+sudo podman exec mailserver setup email restrict add|del send|receive <correo>  # deshabilitar sin borrar (reversible)
+sudo podman exec mailserver setup email restrict list send|receive             # ver quién está restringido
+```
+
+`restrict` es la forma de "bajar" una cuenta sin perder el Maildir ni tener que volver a crearla después — útil cuando no se quiere un borrado definitivo todavía (por ejemplo, en un offboarding en curso).
+
+## Procedimiento: mandar correo de prueba desde terminal
+
+Con `swaks` (instalado vía EPEL en `mcps-vpn-server`):
+
+```bash
+swaks --to dest@ejemplo.com --from soporte@mcps-epcm.org \
+  --server mail.mcps-epcm.org:587 --helo mcps-epcm.org \
+  --auth LOGIN --auth-user soporte@mcps-epcm.org --auth-password '<pass>' \
+  --tls --header 'Subject: asunto' --body 'texto'
+```
+
+Config reusable en `~/.swaks/<cuenta>.conf` (uno por cuenta, `chmod 600`, `swaks --config ~/.swaks/soporte.conf ...`). Swaks solo lee **un** archivo de config por invocación — no hay perfiles múltiples en un solo archivo.
+
+## Configuración de cliente (IMAP/SMTP manual)
+
+- IMAP: `mail.mcps-epcm.org:993`, SSL/TLS
+- SMTP: `mail.mcps-epcm.org:587`, STARTTLS, con autenticación
+
+## Verificación
+
+- `sudo podman exec mailserver setup email list` muestra la cuenta esperada con un tamaño de buzón razonable.
+- Un `swaks` de prueba hacia una cuenta propia entrega sin rechazo.
+- `sudo podman exec mailserver setup email restrict list send|receive` no muestra cuentas restringidas que deberían estar activas.
+
+## Solución de problemas
+
+- **`swaks` falla con autenticación**: confirme que la contraseña usada es la vigente (`setup email update` la rota); una rotación reciente invalida clientes ya configurados con la contraseña anterior.
+- **Algo sugiere que el contenedor vive en `mcps-hpc-01`**: es incorrecto desde antes del 2026-06-24; el contenedor real está en `mcps-vpn-server`. Puede seguir existiendo un contenedor viejo detenido (`Exited`) en `mcps-hpc-01` — no reactivarlo pensando que es el servicio real.
+- **Una cuenta no manda ni recibe**: revise si está en la lista de restringidas (`setup email restrict list send|receive`) antes de asumir que es un problema del servidor.

content/memorias/2026-08-19-mem-20260819-51dea9-corregir-despliegue-de-clusterlog-en-caddy-y-dar-persistencia-al-runner-de-gitea-actions.md

@@ -0,0 +1,57 @@
++++
+title = "Corregir despliegue de clusterlog en Caddy y dar persistencia al runner de Gitea Actions"
+description = "Bloque de Caddy faltante para clusterlog.mcps-epcm.org agregado; runner nativo de Gitea Actions pasado de proceso manual a systemd."
+date = 2026-08-19T18:56:10Z
+authors = ["gen"]
+slug = "mem-20260819-51dea9-corregir-despliegue-de-clusterlog-en-caddy-y-dar-persistencia-al-runner-de-gitea-actions"
+template = "memory.html"
+
+[taxonomies]
+categories = ["memorias"]
+tags = ["caddy", "clusterlog", "gitea-actions", "systemd"]
+systems = ["caddy", "gitea-runner", "mcps-hpc-01"]
+
+[extra]
+id = "MEM-20260819-51DEA9"
+kind = "memory"
+author_id = "gen"
+author_fingerprint = "SHA256:JhN1Tt4jYqWoJIznDJ6QkMAiOR6HFHr3xLz9aBJqmPg"
+risk = "medium"
+ticket = ""
+review_required = true
+review_policy = "all-active"
+reviewer_snapshot = true
+reviewers = ["gen"]
+started_at = ""
+finished_at = ""
+duration_minutes = 0
+agent = "claude-code"
++++
+
+## Contexto
+
+clusterlog.mcps-epcm.org (contenedor nginx clusterlog, 10.89.0.4:80 en mcps-net) y su DNS ya existían, pero la página no cargaba: faltaba el bloque correspondiente en /mnt/cephfs/hot/caddy/Caddyfile. Al revisar la infraestructura se encontró además que el runner de Gitea Actions (act_runner v0.2.13, ya registrado contra Gitea, uuid 5844d409-..., nombre de runner mcps-hpc-01, label ubuntu-latest:host, corre jobs directo en el host sin contenedores) llevaba 7 tareas procesadas corriendo a mano como proceso del usuario gen, sin systemd, sin sobrevivir a un reinicio. De paso se encontró, sin corregir, que la cuenta ACME de Let's Encrypt de todo Caddy #2 usa como contacto angel.pacheco@mcps-epcm.org, correo restringido en un offboarding en curso — los avisos de renovación fallida ya no le llegan a nadie; pendiente cambiar el email global del bloque `{ email ... }` del Caddyfile.
+
+## Cambios realizados
+
+- Agregado el bloque de Caddy para clusterlog.mcps-epcm.org en /mnt/cephfs/hot/caddy/Caddyfile, mismo patrón DNS-01 vía Route53 que el resto de dominios
+- Creado /etc/systemd/system/gitea-runner.service (User=gen, WorkingDirectory=/opt/gitea-runner, ExecStart=/opt/gitea-runner/act_runner daemon, Restart=always), habilitado; se terminó el proceso manual y se levantó por systemd conservando el mismo uuid/identidad de runner ya registrado, sin re-registrar nada
+
+## Comandos relevantes (secretos redactados)
+
+```console
+caddy validate
+caddy reload
+systemctl enable --now gitea-runner.service
+```
+
+## Validación
+
+- caddy validate limpio antes de hacer reload
+- curl sirviendo 200 en la ruta del manual real de clusterlog.mcps-epcm.org tras el reload, sin downtime del resto de sitios detrás de Caddy
+- Certificado Let's Encrypt emitido en ~30s tras el reload
+- El runner levantado por systemd conservó el mismo uuid/identidad ya registrado en Gitea
+
+## Riesgo y reversión
+
+Quitar el bloque agregado del Caddyfile y ejecutar caddy reload revierte clusterlog.mcps-epcm.org al estado anterior (dominio sin servir). Para el runner, systemctl stop gitea-runner.service y volver a correr ./act_runner daemon a mano restauraría el modo anterior, sin persistencia (no recomendado).

content/memorias/2026-08-19-mem-20260819-6ea868-reparar-pg-danado-health-err-en-el-cluster-ceph-de-mcps-hpc-01.md

@@ -0,0 +1,60 @@
++++
+title = "Reparar PG dañado (HEALTH_ERR) en el clúster Ceph de mcps-hpc-01"
+description = "Diagnóstico y reparación de un PG_DAMAGED real (pg 3.ec) en el clúster cephadm de producción; 407 pgs sin deep-scrub a tiempo se documentan como trade-off, no como bug, y no se tocaron."
+date = 2026-08-19T18:56:05Z
+authors = ["gen"]
+slug = "mem-20260819-6ea868-reparar-pg-danado-health-err-en-el-cluster-ceph-de-mcps-hpc-01"
+template = "memory.html"
+
+[taxonomies]
+categories = ["memorias"]
+tags = ["almacenamiento", "ceph", "salud-cluster"]
+systems = ["ceph", "mcps-hpc-01"]
+
+[extra]
+id = "MEM-20260819-6EA868"
+kind = "memory"
+author_id = "gen"
+author_fingerprint = "SHA256:JhN1Tt4jYqWoJIznDJ6QkMAiOR6HFHr3xLz9aBJqmPg"
+risk = "high"
+ticket = ""
+review_required = true
+review_policy = "all-active"
+reviewer_snapshot = true
+reviewers = ["gen"]
+started_at = ""
+finished_at = ""
+duration_minutes = 0
+agent = "claude-code"
++++
+
+## Contexto
+
+El clúster Ceph de mcps-hpc-01 (cephadm, fsid 9dd39ee8-b987-11f0-9c83-3497f632acb0: 5 mons, mgr activo+standby, 2 MDS, 20 OSDs, 4 pools, 1089 pgs, ~45 TiB usados de 232 TiB) respalda cephfs_hpc, del que dependen Caddy #2, Zammad y en general /mnt/cephfs. Al revisar `ceph -s` salió HEALTH_ERR por dos causas distintas: 1 scrub error/PG_DAMAGED en pg 3.ec, y 407 pgs sin deep-scrub a tiempo (warning, no error). El repair de 3.ec (`ceph pg repair 3.ec`) quedó corriendo en segundo plano al cierre de la sesión — es un deep-scrub completo del PG (~42 GiB), tarda varios minutos; falta reconfirmar con `ceph -s` / `ceph health detail` que OSD_SCRUB_ERRORS y PG_DAMAGED ya no aparecen.
+
+## Cambios realizados
+
+- Diagnosticado pg 3.ec con rados list-inconsistent-obj: el shard primario (osd.10) está limpio (digest correcto) y el shard de la réplica (osd.13) tiene read_error puro, sin ambigüedad entre copias
+- Confirmado con smartctl que el disco de osd.13 no tenía degradación física antes de reparar (PASSED, Reallocated_Sector_Ct=0, Current_Pending_Sector=0, Offline_Uncorrectable=0)
+- Ejecutado ceph pg repair 3.ec para reescribir la copia buena sobre la réplica dañada
+- No se modificó osd_max_scrubs ni ninguna configuración de deep-scrub: los 407 pgs atrasados (la config ya tiene osd_scrub_load_threshold=8.0 y osd_deep_scrub_interval=15 días, ambos más permisivos que el default) son un trade-off de rendimiento vs. velocidad de scrub que compite con I/O de clientes reales de cephfs en horario laboral, no un bug — no se cambió sin consultar al equipo
+
+## Comandos relevantes (secretos redactados)
+
+```console
+ceph -s
+rados list-inconsistent-obj 3.ec
+smartctl -H /dev/sda
+smartctl -A /dev/sda
+ceph pg repair 3.ec
+ceph osd dump | grep flag
+```
+
+## Validación
+
+- smartctl -H y -A en el disco de osd.13 confirmaron salud del disco antes de reparar (sin sectores reasignados ni pendientes)
+- rados list-inconsistent-obj 3.ec confirmó que sólo existía una copia válida (osd.10), sin ambigüedad entre réplicas, antes de ejecutar el repair
+
+## Riesgo y reversión
+
+El pg repair no tiene una reversión directa una vez completado; si el repair fallara o el objeto siguiera inconsistent, requeriría intervención manual adicional (revisar de nuevo con rados list-inconsistent-obj y, si aplica, restaurar desde otra réplica sana).

content/memorias/2026-08-19-mem-20260819-727073-limpiar-backlog-de-ruido-en-tickets-new-de-zammad.md

@@ -0,0 +1,52 @@
++++
+title = "Limpiar backlog de ruido en tickets 'new' de Zammad"
+description = "Depuración por SQL directo del backlog new del grupo de soporte MCPS: 329 tickets de rebotes/pruebas cerrados, 12 tickets reales conservados sin tocar."
+date = 2026-08-19T18:56:01Z
+authors = ["gen"]
+slug = "mem-20260819-727073-limpiar-backlog-de-ruido-en-tickets-new-de-zammad"
+template = "memory.html"
+
+[taxonomies]
+categories = ["memorias"]
+tags = ["limpieza", "soporte", "zammad"]
+systems = ["zammad"]
+
+[extra]
+id = "MEM-20260819-727073"
+kind = "memory"
+author_id = "gen"
+author_fingerprint = "SHA256:JhN1Tt4jYqWoJIznDJ6QkMAiOR6HFHr3xLz9aBJqmPg"
+risk = "medium"
+ticket = ""
+review_required = true
+review_policy = "all-active"
+reviewer_snapshot = true
+reviewers = ["gen"]
+started_at = ""
+finished_at = ""
+duration_minutes = 0
+agent = "claude-code"
++++
+
+## Contexto
+
+Tras aplicar la estrategia B de roles en Zammad, el grupo Equipo de soporte MCPS mostraba 341 tickets en estado new, nunca tocados por un agente. Se pidió revisar qué eran realmente antes de tocar nada. Agrupando por remitente salió que casi todo era ruido: 305 rebotes de mailer-daemon@mcps-epcm.org + 7 de mailer-daemon@amazonses.com, 14 pruebas de estudiomexicanodecohorte@gmail.com (cuenta admin huérfana), 3 pruebas de soporte@mcps-epcm.org, y 12 tickets reales de personas. De esos 12, los 3 más recientes (agosto 2026) parecen solicitudes activas de acceso/seguridad; el ticket 31658 ('ERROR de conexión', angel.pacheco@mcps-epcm.org, 2026-08-07) corresponde a la persona de un offboarding en curso y no debe cerrarse ni ignorarse sin que Fernando o Alexis lo revisen a mano.
+
+## Cambios realizados
+
+- Cerrados por SQL directo 329 tickets de ruido: 312 rebotes (mailer-daemon@mcps-epcm.org / mailer-daemon@amazonses.com, por remitente+estado) y 17 de prueba (estudiomexicanodecohorte@gmail.com y soporte@mcps-epcm.org, por número de ticket exacto)
+- No se tocaron los 12 tickets reales; quedan como backlog real pendiente de respuesta humana del equipo de soporte
+
+## Comandos relevantes (secretos redactados)
+
+_No se registraron comandos._
+
+## Validación
+
+- Confirmado antes de cerrar que el trigger 'Ticket Cerrado' está inactivo (triggers.active = f) en Zammad
+- Confirmado que un UPDATE SQL directo no pasa por el motor de triggers de Zammad (corre en la app Rails, no en la base de datos), por lo que cerrar sin agregar un artículo nuevo no dispara correo al cliente
+- Estado del grupo verificado después de la limpieza: 608 closed / 23 open / 12 new (antes: 279 closed / 23 open / 341 new)
+
+## Riesgo y reversión
+
+Los tickets cerrados se pueden reabrir manualmente en Zammad por número de ticket; no se modificó ni se borró ningún dato, solo el estado de los tickets de ruido.

content/memorias/2026-08-19-mem-20260819-c255ff-desplegar-uptime-kuma-como-monitoreo-central-health-mcps-epcm-org.md

@@ -0,0 +1,55 @@
++++
+title = "Desplegar Uptime Kuma como monitoreo central (health.mcps-epcm.org)"
+description = "Contenedor Uptime Kuma en mcps-hpc-01 con 22 monitores en 3 grupos; gotcha de systemd Type=notify que causaba reinicio en loop."
+date = 2026-08-19T18:55:56Z
+authors = ["gen"]
+slug = "mem-20260819-c255ff-desplegar-uptime-kuma-como-monitoreo-central-health-mcps-epcm-org"
+template = "memory.html"
+
+[taxonomies]
+categories = ["memorias"]
+tags = ["monitoreo", "systemd", "uptime-kuma"]
+systems = ["mcps-hpc-01", "uptime-kuma"]
+
+[extra]
+id = "MEM-20260819-C255FF"
+kind = "memory"
+author_id = "gen"
+author_fingerprint = "SHA256:JhN1Tt4jYqWoJIznDJ6QkMAiOR6HFHr3xLz9aBJqmPg"
+risk = "low"
+ticket = ""
+review_required = true
+review_policy = "all-active"
+reviewer_snapshot = true
+reviewers = ["gen"]
+started_at = ""
+finished_at = ""
+duration_minutes = 0
+agent = "claude-code"
++++
+
+## Contexto
+
+Se desplegó Uptime Kuma como monitoreo centralizado de los servicios web de mcps-epcm.org y del clúster HPC, expuesto en https://health.mcps-epcm.org (VPN-only). Quedan pendientes sin resolver, encontrados por el propio monitoreo al arrancar: pgscat.mcps-epcm.org responde 502 (backend no responde) y encuestas.mcps-epcm.org responde 404 en / (posiblemente normal si esa app solo sirve rutas específicas).
+
+## Cambios realizados
+
+- Contenedor docker.io/louislam/uptime-kuma:1 desplegado en mcps-hpc-01, systemd unit container-uptime-kuma.service, IP fija 10.89.0.51 en mcps-net
+- Corregido Type=notify a Type=simple en el systemd unit: Uptime Kuma no manda la señal sd_notify y con Type=notify se quedaba en 'activating' y reiniciaba en loop
+- 22 monitores configurados en 3 grupos (servicios web mcps-epcm.org, infraestructura mcps-hpc-01, nodos del clúster HPC) mediante script Python con la librería no oficial uptime-kuma-api
+- Se quitaron del monitoreo pgscat y mta-sts a pedido explícito; los servicios detrás de Caddy siguen existiendo, solo se sacaron del monitor
+
+## Comandos relevantes (secretos redactados)
+
+```console
+pip install uptime-kuma-api
+```
+
+## Validación
+
+- Dashboard accesible en https://health.mcps-epcm.org con certificado real vía DNS-01
+- Página pública de estado sin login disponible en https://health.mcps-epcm.org/status/mcps
+
+## Riesgo y reversión
+
+Detener y deshabilitar container-uptime-kuma.service; no afecta a los servicios monitoreados, solo deja de haber monitoreo centralizado.

data/generated/site_state.json

@@ -1,15 +1,230 @@
 {
   "version": 2,
-  "generated_at": "2026-08-13T06:42:03Z",
+  "generated_at": "2026-08-19T18:56:10Z",
-  "source_sha256": "64a404e7ccb669ab6712d92141f5e2446eb3256723075a42bd7037380f285050",
+  "source_sha256": "0b1a0d13dbeb6a3805b58b7ef0c513d3be7fc1b995ba75ff2e1d6695317c1f32",
   "stats": {
     "active_admins": 1,
-    "pending_reviews": 0,
+    "pending_reviews": 4,
     "open_tasks": 1,
     "active_projects": 1
   },
-  "review_queue": [],
+  "review_queue": [
+    {
+      "entry_id": "MEM-20260819-51DEA9",
+      "title": "Corregir despliegue de clusterlog en Caddy y dar persistencia al runner de Gitea Actions",
+      "description": "Bloque de Caddy faltante para clusterlog.mcps-epcm.org agregado; runner nativo de Gitea Actions pasado de proceso manual a systemd.",
+      "date": "2026-08-19T18:56:10Z",
+      "author_id": "gen",
+      "risk": "medium",
+      "tags": [
+        "caddy",
+        "clusterlog",
+        "gitea-actions",
+        "systemd"
+      ],
+      "systems": [
+        "caddy",
+        "gitea-runner",
+        "mcps-hpc-01"
+      ],
+      "permalink": "/memorias/mem-20260819-51dea9-corregir-despliegue-de-clusterlog-en-caddy-y-dar-persistencia-al-runner-de-gitea-actions/",
+      "content_sha256": "21e603dbed0706b5438365fae7ede5f84302a12ac1360edc3a417f2bef51eff6",
+      "reviewed_by": [],
+      "missing_reviewers": [
+        "gen"
+      ],
+      "required_count": 1,
+      "reviewed_count": 0
+    },
+    {
+      "entry_id": "MEM-20260819-6EA868",
+      "title": "Reparar PG dañado (HEALTH_ERR) en el clúster Ceph de mcps-hpc-01",
+      "description": "Diagnóstico y reparación de un PG_DAMAGED real (pg 3.ec) en el clúster cephadm de producción; 407 pgs sin deep-scrub a tiempo se documentan como trade-off, no como bug, y no se tocaron.",
+      "date": "2026-08-19T18:56:05Z",
+      "author_id": "gen",
+      "risk": "high",
+      "tags": [
+        "almacenamiento",
+        "ceph",
+        "salud-cluster"
+      ],
+      "systems": [
+        "ceph",
+        "mcps-hpc-01"
+      ],
+      "permalink": "/memorias/mem-20260819-6ea868-reparar-pg-danado-health-err-en-el-cluster-ceph-de-mcps-hpc-01/",
+      "content_sha256": "ec3bf36fe97a386b876ecd332b26ce55dae983e7e0989a8ff154d1e82243b5d5",
+      "reviewed_by": [],
+      "missing_reviewers": [
+        "gen"
+      ],
+      "required_count": 1,
+      "reviewed_count": 0
+    },
+    {
+      "entry_id": "MEM-20260819-727073",
+      "title": "Limpiar backlog de ruido en tickets 'new' de Zammad",
+      "description": "Depuración por SQL directo del backlog new del grupo de soporte MCPS: 329 tickets de rebotes/pruebas cerrados, 12 tickets reales conservados sin tocar.",
+      "date": "2026-08-19T18:56:01Z",
+      "author_id": "gen",
+      "risk": "medium",
+      "tags": [
+        "limpieza",
+        "soporte",
+        "zammad"
+      ],
+      "systems": [
+        "zammad"
+      ],
+      "permalink": "/memorias/mem-20260819-727073-limpiar-backlog-de-ruido-en-tickets-new-de-zammad/",
+      "content_sha256": "642a33d4d5af8f99821ee817b4007ad11aec3b29767647cb1f5ec9d3788791ae",
+      "reviewed_by": [],
+      "missing_reviewers": [
+        "gen"
+      ],
+      "required_count": 1,
+      "reviewed_count": 0
+    },
+    {
+      "entry_id": "MEM-20260819-C255FF",
+      "title": "Desplegar Uptime Kuma como monitoreo central (health.mcps-epcm.org)",
+      "description": "Contenedor Uptime Kuma en mcps-hpc-01 con 22 monitores en 3 grupos; gotcha de systemd Type=notify que causaba reinicio en loop.",
+      "date": "2026-08-19T18:55:56Z",
+      "author_id": "gen",
+      "risk": "low",
+      "tags": [
+        "monitoreo",
+        "systemd",
+        "uptime-kuma"
+      ],
+      "systems": [
+        "mcps-hpc-01",
+        "uptime-kuma"
+      ],
+      "permalink": "/memorias/mem-20260819-c255ff-desplegar-uptime-kuma-como-monitoreo-central-health-mcps-epcm-org/",
+      "content_sha256": "a74e4f1493843970c55c3197fb2e5266c8b04cf631e7fd187890051a0f076686",
+      "reviewed_by": [],
+      "missing_reviewers": [
+        "gen"
+      ],
+      "required_count": 1,
+      "reviewed_count": 0
+    }
+  ],
   "recent_memories": [
+    {
+      "entry_id": "MEM-20260819-51DEA9",
+      "title": "Corregir despliegue de clusterlog en Caddy y dar persistencia al runner de Gitea Actions",
+      "description": "Bloque de Caddy faltante para clusterlog.mcps-epcm.org agregado; runner nativo de Gitea Actions pasado de proceso manual a systemd.",
+      "date": "2026-08-19T18:56:10Z",
+      "author_id": "gen",
+      "author_fingerprint": "SHA256:JhN1Tt4jYqWoJIznDJ6QkMAiOR6HFHr3xLz9aBJqmPg",
+      "risk": "medium",
+      "review_required": true,
+      "review_policy": "all-active",
+      "reviewer_snapshot": true,
+      "reviewers": [
+        "gen"
+      ],
+      "tags": [
+        "caddy",
+        "clusterlog",
+        "gitea-actions",
+        "systemd"
+      ],
+      "systems": [
+        "caddy",
+        "gitea-runner",
+        "mcps-hpc-01"
+      ],
+      "slug": "mem-20260819-51dea9-corregir-despliegue-de-clusterlog-en-caddy-y-dar-persistencia-al-runner-de-gitea-actions",
+      "permalink": "/memorias/mem-20260819-51dea9-corregir-despliegue-de-clusterlog-en-caddy-y-dar-persistencia-al-runner-de-gitea-actions/",
+      "source_path": "content/memorias/2026-08-19-mem-20260819-51dea9-corregir-despliegue-de-clusterlog-en-caddy-y-dar-persistencia-al-runner-de-gitea-actions.md",
+      "content_sha256": "21e603dbed0706b5438365fae7ede5f84302a12ac1360edc3a417f2bef51eff6"
+    },
+    {
+      "entry_id": "MEM-20260819-6EA868",
+      "title": "Reparar PG dañado (HEALTH_ERR) en el clúster Ceph de mcps-hpc-01",
+      "description": "Diagnóstico y reparación de un PG_DAMAGED real (pg 3.ec) en el clúster cephadm de producción; 407 pgs sin deep-scrub a tiempo se documentan como trade-off, no como bug, y no se tocaron.",
+      "date": "2026-08-19T18:56:05Z",
+      "author_id": "gen",
+      "author_fingerprint": "SHA256:JhN1Tt4jYqWoJIznDJ6QkMAiOR6HFHr3xLz9aBJqmPg",
+      "risk": "high",
+      "review_required": true,
+      "review_policy": "all-active",
+      "reviewer_snapshot": true,
+      "reviewers": [
+        "gen"
+      ],
+      "tags": [
+        "almacenamiento",
+        "ceph",
+        "salud-cluster"
+      ],
+      "systems": [
+        "ceph",
+        "mcps-hpc-01"
+      ],
+      "slug": "mem-20260819-6ea868-reparar-pg-danado-health-err-en-el-cluster-ceph-de-mcps-hpc-01",
+      "permalink": "/memorias/mem-20260819-6ea868-reparar-pg-danado-health-err-en-el-cluster-ceph-de-mcps-hpc-01/",
+      "source_path": "content/memorias/2026-08-19-mem-20260819-6ea868-reparar-pg-danado-health-err-en-el-cluster-ceph-de-mcps-hpc-01.md",
+      "content_sha256": "ec3bf36fe97a386b876ecd332b26ce55dae983e7e0989a8ff154d1e82243b5d5"
+    },
+    {
+      "entry_id": "MEM-20260819-727073",
+      "title": "Limpiar backlog de ruido en tickets 'new' de Zammad",
+      "description": "Depuración por SQL directo del backlog new del grupo de soporte MCPS: 329 tickets de rebotes/pruebas cerrados, 12 tickets reales conservados sin tocar.",
+      "date": "2026-08-19T18:56:01Z",
+      "author_id": "gen",
+      "author_fingerprint": "SHA256:JhN1Tt4jYqWoJIznDJ6QkMAiOR6HFHr3xLz9aBJqmPg",
+      "risk": "medium",
+      "review_required": true,
+      "review_policy": "all-active",
+      "reviewer_snapshot": true,
+      "reviewers": [
+        "gen"
+      ],
+      "tags": [
+        "limpieza",
+        "soporte",
+        "zammad"
+      ],
+      "systems": [
+        "zammad"
+      ],
+      "slug": "mem-20260819-727073-limpiar-backlog-de-ruido-en-tickets-new-de-zammad",
+      "permalink": "/memorias/mem-20260819-727073-limpiar-backlog-de-ruido-en-tickets-new-de-zammad/",
+      "source_path": "content/memorias/2026-08-19-mem-20260819-727073-limpiar-backlog-de-ruido-en-tickets-new-de-zammad.md",
+      "content_sha256": "642a33d4d5af8f99821ee817b4007ad11aec3b29767647cb1f5ec9d3788791ae"
+    },
+    {
+      "entry_id": "MEM-20260819-C255FF",
+      "title": "Desplegar Uptime Kuma como monitoreo central (health.mcps-epcm.org)",
+      "description": "Contenedor Uptime Kuma en mcps-hpc-01 con 22 monitores en 3 grupos; gotcha de systemd Type=notify que causaba reinicio en loop.",
+      "date": "2026-08-19T18:55:56Z",
+      "author_id": "gen",
+      "author_fingerprint": "SHA256:JhN1Tt4jYqWoJIznDJ6QkMAiOR6HFHr3xLz9aBJqmPg",
+      "risk": "low",
+      "review_required": true,
+      "review_policy": "all-active",
+      "reviewer_snapshot": true,
+      "reviewers": [
+        "gen"
+      ],
+      "tags": [
+        "monitoreo",
+        "systemd",
+        "uptime-kuma"
+      ],
+      "systems": [
+        "mcps-hpc-01",
+        "uptime-kuma"
+      ],
+      "slug": "mem-20260819-c255ff-desplegar-uptime-kuma-como-monitoreo-central-health-mcps-epcm-org",
+      "permalink": "/memorias/mem-20260819-c255ff-desplegar-uptime-kuma-como-monitoreo-central-health-mcps-epcm-org/",
+      "source_path": "content/memorias/2026-08-19-mem-20260819-c255ff-desplegar-uptime-kuma-como-monitoreo-central-health-mcps-epcm-org.md",
+      "content_sha256": "a74e4f1493843970c55c3197fb2e5266c8b04cf631e7fd187890051a0f076686"
+    },
     {
       "entry_id": "MEM-DEMO-001",
       "title": "Inicializar la estructura de la bitácora",