Operación y mantenimiento
Pendientes operativos
Lo que falta para cerrar la operación de la Academia Deltamontero, según el manual de recuperación y el plan del proyecto, con su estado en el código.
Lista de tareas operativas abiertas. Sale del manual de recuperación (docs/drp.md) y del plan del proyecto (docs/roadmap_v4.md), contrastado con lo que el código hace hoy.
Prioridad alta: respaldo y recuperación
| Pendiente | Por qué importa | Responsable | Cómo cerrarlo |
|---|---|---|---|
| Copia fuera del servidor | Hoy los respaldos están solo en el mismo servidor: si el servidor o el nodo Proxmox se dañan, se pierden con él. Moodle lo avisa al super administrador | TI | Elegir el destino (recomendado Cloudflare R2 con cuenta de la empresa), configurar rclone con remoto cifrado y ejecutar setup-backup.sh --remote r2crypt: (Respaldos) |
| Cuenta de Cloudflare R2 de la empresa | La cuenta de R2 que se usa para videos es personal | Por confirmar | Migrar a una cuenta de la empresa antes de usarla para los respaldos |
| Snapshot de Proxmox del contenedor | Segunda línea de defensa, independiente de los scripts | TI | Programarlo en Proxmox (frecuencia y retención: Por confirmar) |
| Variables de entorno en un gestor de contraseñas | Hoy están solo en Coolify, que vive en el mismo contenedor que la Academia: si se pierde el servidor, se pierden con él. Sin ellas, una recuperación en un servidor nuevo queda sin correo, sin IA y sin poder recrear la base con las mismas credenciales | TI | Guardar todas las variables de Coolify (incluida la clave del correo), la clave de cifrado de la copia externa y las claves de rclone. Qué gestor de contraseñas se usará: Por confirmar |
| Comprobar el primer respaldo automático | Se activó el 2026-10-06; falta ver la primera ejecución programada | TI | tail /var/log/delta-lms-backup.log y la página Respaldos de la Academia en estado Al día |
| Prueba de recuperación con datos reales | Las pruebas completas se hicieron en un equipo local; falta repetirlas con un respaldo real de producción | TI | Restaurar un respaldo real de producción en otro equipo o en el contenedor nuevo, sin correo o con desvío, y anotarlo en el Registro de pruebas |
| Mudanza al contenedor nuevo | TI preparó el contenedor LXC 12030 (Ubuntu, 4 CPU, 8 GB de RAM, 4 GB de swap, 250 GB, 192.168.0.191, nesting=1). La mudanza desde el contenedor 172246 sirve además como prueba de recuperación con datos reales | TI | Seguir Recuperación → Mudanza: pausar el correo en el viejo, último respaldo, restaurar, cambiar la dirección, reanudar el correo. Fecha: Por confirmar |
Prioridad alta: servidor
| Pendiente | Por qué importa | Responsable | Cómo cerrarlo |
|---|---|---|---|
| Reloj del servidor (NTP) | El 2026-10-06 estaba unos 16 minutos adelantado y sin sincronizar (NTP service: inactive). Afecta a los códigos MFA de los administradores y a los registros | TI | Activar la sincronización en el nodo Proxmox (el servidor es un contenedor LXC de Proxmox, 172246) |
| Cambiar las contraseñas iniciales de los super administradores | El manual de la Academia lo exige en producción | Super administrador | Cambiarlas desde el perfil. Si sigue el aviso de contraseña por defecto de admin, se quita solo al cambiarla |
| Contraseñas que estuvieron publicadas | Versiones antiguas del repositorio publicaron contraseñas de ejemplo de admin y admin.respaldo. Ya no están en el código, pero siguen en el historial de Git, así que deben considerarse comprometidas | Super administrador | Verificar que ninguna cuenta las use (en particular admin y admin.respaldo) y cambiar cualquiera que todavía las tenga |
| Datos personales y contraseñas en el historial de Git | El código actual ya no contiene cédulas del personal ni esas contraseñas, pero el historial de Git del repositorio todavía las conserva | Desarrollador principal | Decidir si se limpia el historial: requiere reescribirlo (por ejemplo, con una herramienta de reescritura de historial) y forzar el envío al repositorio remoto, lo que obliga a todos los que tengan una copia a volver a clonarla |
Perímetro y endurecimiento del servidor
Planificado en el roadmap (fase F0) y en las notas de arquitectura del repositorio. Hoy la Academia se usa solo en la red interna de la empresa (http://192.168.0.192); lo relativo a Cloudflare aplica cuando se publique con dominio. Ninguno de estos elementos está en el repositorio; si ya se aplicaron directamente en el servidor: Por confirmar con TI.
| Pendiente | Detalle del plan |
|---|---|
| Publicar con dominio | Publicar learning.deltamontero.net con Cloudflare, configurar el dominio en Coolify y cambiar MOODLE_WWWROOT a https://learning.deltamontero.net (corrigiendo los enlaces con replace.php, como en el paso 10 del caso B). Fecha: Por confirmar |
| Firewall solo para Cloudflare | ufw con lista blanca de las IP de Cloudflare únicamente; perímetro en tres capas (Cloudflare WAF, lista de IP en Traefik y la cadena DOCKER-USER) |
| TLS de extremo a extremo | Certificado de origen de Cloudflare y modo Full (strict), nunca Flexible |
| Actualizaciones de seguridad automáticas | unattended-upgrades limitado al canal de seguridad |
| Endurecimiento base | Línea base CIS v8, fail2ban, acceso SSH no expuesto a internet |
| Infraestructura como código | cloud-init y un playbook o bootstrap.sh versionado que reproduzca el servidor |
Monitoreo
| Pendiente | Estado |
|---|---|
Monitoreo externo (roadmap F1.6: tool_heartbeat + Uptime Kuma para web, cron y base, con alerta a dos personas) | No implementado. Hoy existen los controles de salud de Coolify, los avisos dentro de Moodle y el correo de fallo de respaldo (Monitoreo y avisos) |
| Alerta si el respaldo deja de ejecutarse | Moodle avisa al super administrador si el último respaldo tiene más de 36 horas, pero solo cuando alguien entra; no hay correo por respaldo atrasado (solo por respaldo fallido) |
| Control de espacio en disco | No hay control automático en el repositorio |
Plataforma
| Pendiente | Estado |
|---|---|
| Compatibilidad 4.5 de los plugins (roadmap F1.0) | Los plugins ya están fijados a commits o etiquetas en el Dockerfile |
Prueba de humo de H5P (mod_hvp) y videos interactivos tras cada construcción (roadmap F1.0b) | Resultado no registrado: Por confirmar |
| App móvil de Moodle (roadmap F1.9, incluido el ingreso de un administrador con MFA) | moodle-config.sh no activa enablemobilewebservice: Por confirmar si se usará la app |
| Certificado TLS en el modo sin Coolify | infrastructure/traefik/traefik.yml no define cómo obtener el certificado: Por confirmar |
| Política de actualizaciones (roadmap §3.3: seguridad automática, resto manual en ventana trimestral) | Por confirmar si está adoptada |
| Rotación del token del servicio MCP y de las contraseñas de la base de datos | Sin procedimiento documentado: Por confirmar |
El plan del roadmap para la copia externa proponía otro diseño (bucket con clave sin permiso de borrado, cifrado asimétrico GPG con llave privada fuera de línea y aviso si el respaldo no llega). Lo implementado hoy es rclone con remoto crypt y aviso por fallo. Si se adoptan esas medidas adicionales: Por confirmar.
Cerrados recientemente
Para referencia, lo que el manual de recuperación ya da por hecho:
- Scripts de respaldo y restauración probados (local, 2026-10-06).
- Respaldo diario activo en producción desde el 2026-10-06, a las 2:00 de Ecuador (7:00 UTC), con 14 días de retención.
- Avisos en Moodle y correo de fallo de respaldo.
- Copias automáticas por curso de Moodle apagadas.
- Corrección de la detección de contenedores en
restore.sh(regla deCOMPOSE_PROJECT_NAME).
Solución de problemas
Problemas conocidos de la Academia Deltamontero y cómo resolverlos, documentados en el código, sus comentarios y el manual de recuperación.
Referencia
Material de consulta de la Academia Deltamontero, con catálogos, manual, perfiles, pruebas, pipeline de contenido, glosario e historial de documentos.