+++
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).