feadulta/docs/cutover/RUNBOOK-cutover-wordpress.md

Runbook del cutover — WordPress feadulta.com: CDMON → Hetzner

Fecha prevista: lunes 3 de agosto de 2026. Plan maestro: gitea rafa/feadulta#180. Todos los tiempos de abajo están medidos en el ensayo del 31-jul, no estimados.

---

Antes de empezar (verde obligatorio)

• Freeze editorial avisado a Inma. El cutover no puede caer el día de publicación de la carta.
• CDMON sigue vivo (§1). Es el rollback: si no está, no se ejecuta.
• Modo SSL de la zona en Cloudflare = Full (strict). Si está en Flexible, Cloudflare habla HTTP con el origen mientras Traefik fuerza HTTPS → bucle de redirección y sitio caído. Nuestro token no puede leer este ajuste: lo confirma Inma.
• Inventario del wildcard. La zona tiene *.feadulta.com → apex, proxied. Al mover el A del apex, todo subdominio no declarado se va a Hetzner y Traefik devolverá su 404. Comprobado pendiente: info.feadulta.com.

Tiempos medidos (ensayo del 31-jul)

Fase	Medido	¿Se repite el lunes?
Dump CDMON → WSL (105 MB)	25 s	Sí
WSL → Hetzner	74 s	Sí
Saneo de collations + exclusión *_bak	2 s	Sí
Import en MySQL 8.4	107 s	Sí
Instalar plugins + tema + 28 mu-plugins	4 min 19 s	No (ya hecho)
Pre-sync de uploads 5,9 GB	ver #180	No (ya hecho; el lunes solo el delta)
Camino crítico de la ventana	≈ 3 min 30 s + delta de uploads

El corte real percibido por el visitante es solo el cambio del A record, que en Cloudflare es instantáneo. Todo lo de arriba se hace antes, con el sitio viejo aún sirviendo.

---

1. Backup de última hora en el origen

No fiarse del cron de UpdraftPlus de las 05:09: forzar uno nuevo o confirmar que el del día existe.

sshpass -p "$FEA_PROD_SSH_PASS" ssh feadulta@134.0.10.170 \
  'ls -lt /web/wp-content/updraft/*-db.gz | head -3'

2. Traer el dump del día

bash scripts/cutover/01-traer-dump.sh        # CDMON → WSL → Hetzner, con sha256 en los 3 puntos

Dos saltos a propósito: scp/sftp no funcionan contra la jaula de CDMON, y no queremos dejar la contraseña de CDMON escrita en el Hetzner.

3. Sanear el dump ⚠️ el paso que no se puede saltar

El origen es MariaDB 11.8.6 y el destino MySQL 8.4.10. El dump trae 20 tablas con collations uca1400_* que solo existen en MariaDB 11+; MySQL las rechaza en el CREATE TABLE y el import aborta.

utf8mb4_uca1400_ai_ci  →  utf8mb4_0900_ai_ci
utf8mb3_uca1400_ai_ci  →  utf8mb4_0900_ai_ci   (+ CHARSET=utf8mb3 → utf8mb4)
utf8mb4_unicode_520_ci →  sin tocar (válida en MySQL 8.4)

También excluye las 5 tablas de respaldo (wp_options_bak, wp_posts_bak, wp_postmeta_bak, wp_usermeta_bak, wp_fea_date_slug_posts_backup).

Verificación antes de importar (las tres deben dar 0):

grep -c 'uca1400' feadulta-saneado.sql
grep -c 'utf8mb3'  feadulta-saneado.sql
grep -oE '^CREATE TABLE `[^`]+`' feadulta-saneado.sql | grep -cE '_bak|backup'

4. Importar

--default-character-set=utf8mb4 en el CLIENTE es obligatorio. Omitirlo es exactamente lo que produjo el mojibake ’ en summaraise.

docker exec -i mysql-r2ssjifwj0r0ghyoqd528uaa \
  mysql --default-character-set=utf8mb4 -uroot -p"$RP" wordpress < feadulta-saneado.sql

Verificación: 29 tablas, y las filas deben cuadrar con (líneas que empiezan por " (") + (nº de sentencias INSERT) de cada tabla — la primera fila de cada INSERT va pegada al VALUES. Ignora el # Approximate rows expected del dump: es la estimación de InnoDB y para wp_posts dice 64.160 cuando las filas reales son 43.941.

5. Delta de uploads

rsync -a --info=progress2 --stats --exclude='*.php' \
  -e "sshpass -p ... ssh" feadulta@134.0.10.170:/web/wp-content/uploads/ <destino>/

Solo mueve lo publicado desde el pre-sync. --delete únicamente tras revisar un --dry-run.

6. Higiene de seguridad — SIEMPRE después de cada import

bash scripts/cutover/post-import-seguridad.sh

El dump trae las cuentas de administrador con sus hashes, incluidas las tres deshabilitadas en el incidente #183: reimportar las revive. El script rota la contraseña de los 6 administradores (leyéndolas de ~/.hermes/profiles/feadulta/.env), retira el rol a pabloarias/josek/andrey, y limpia los cron huérfanos de Yoast y WP Profile Builder.

Doble cinturón: además del rol retirado, el mu-plugin fea-security-blocked-users.php bloquea wp_authenticate_user y allow_password_reset para esos tres IDs. Va en el manifiesto de docs/cutover/mu-plugins-manifest.txt, no en un glob fea-* — un glob se lo dejaría fuera.

El script retira además la opción wordfence_core_options, que no es de Wordfence: es el payload de SEO spam que dejó el atacante (div oculto con enlaces a un casino, cifrado con un césar de una letra). Está inerte —quien lo leía era wp-highlits, en cuarentena— pero viaja dentro del dump y cada import lo reintroduce.

6b. Plugins de seguridad — son 8, no 7

A los 7 plugins de producción se añade Wordfence (8.2.2, instalado limpio desde wordpress.org el 31-jul). Motivo: CDMON tenía ModSecurity delante a nivel de hosting —fue lo que detectó las subidas de wp-cl.php y health-check.php en el #183—, y en Hetzner con Traefik no hay WAF ninguno. Sin Wordfence, el servidor nuevo estrenaría con una capa defensiva menos que la que tenía el sitio comprometido.

⚠️ Wordfence queda con protección básica (a nivel de plugin). El extended protection exige configurar auto_prepend_file desde su asistente; se hace después del cutover y con calma, no en la ventana.

⚠️ Wordfence y limit-login-attempts-reloaded solapan en el bloqueo de login. No es un conflicto, pero conviene decidir cuál manda para no acabar con dos contadores distintos.

7. Quitar el WP_HOME/WP_SITEURL del staging

Coolify → servicio feadulta-wp → borrar la variable WORDPRESS_CONFIG_EXTRA → redeploy

No hace falta ningún search-replace: la base de datos ya trae siteurl/home = https://www.feadulta.com, que es la URL final. La constante era solo para el staging. Esto ahorra la pasada más lenta de todo el proceso.

8. Cambiar el A record en Cloudflare

# feadulta.com y www.feadulta.com → 188.40.120.157, MANTENIENDO proxied=true (naranja)

El token sí tiene permiso de escritura, verificado el 31-jul creando nuevo.feadulta.com. Después: purgar la caché de Cloudflare.

9. Verificación en caliente

• Portada en los 5 idiomas (/, /en/, /fr/, /it/, /pt/) — /es/ responde 301, es lo normal.
• Carta de la semana, evangelios, EFFA, autores con avatar.
• Buscador (índice FULLTEXT) devuelve resultados.
• Audio TTS suena.
• Imágenes cargan (depende del delta de uploads).
• wp-login.php entra con la contraseña rotada, y las 3 cuentas del incidente NO entran.
• Certificado Let's Encrypt para apex y www.
• Cero errores PHP en la portada y en docker logs.
• GA4 en tiempo real.

10. Application passwords — con Inma delante, no antes

Solo existe una en todo el sitio: publicabot, del usuario icalvotorre (ID 1048), creada el 27-jun-2026, último uso el 29-jul-2026 desde 213.94.23.1. Es la que usan los bots de la carta.

Rotarla sin coordinar para la publicación de la carta semanal y nadie sabrá por qué. Se rota con Inma delante, generando la nueva y actualizándola en el bot en el mismo momento.

(Rotar la contraseña de un usuario no revoca sus application passwords: el paso 6 no la afecta.)

---

Rollback

Revertir el A record en Cloudflare + purgar caché. Segundos. El Joomla/WordPress de CDMON sigue intacto y sirviendo — comprobado con curl --resolve contra 134.0.10.170.

Esto solo funciona mientras CDMON siga vivo. Es la razón por la que el §1 no es opcional.

Después (no el mismo día)

• Backups en Hetzner: hoy NO HAY NINGUNO. La tabla scheduled_database_backups de Coolify está vacía y no hay cron. Summaraise lleva semanas así. Hay que darle dueño.
• Actualizar los scripts y guías que apuntan a 134.0.10.170 y a /web/ (cierra #158).
• Retirar nuevo.feadulta.com de Cloudflare cuando ya no haga falta.