- Eliminar exposición del puerto 4430 que creaba bypass a Traefik
- Eliminar comandos destructivos rm -rf que borraban datos en cada deploy
- Restringir permisos de directorios sensibles de 755 a 750
CAMBIOS MAYORES:
- Usar paths absolutos /srv/meshcentral/* en lugar de relativos
- Limpiar datos viejos completamente (empezar de cero)
- config.json correcto:
* Puerto 443 (no 4430)
* OIDC con Authentik configurado
* Dominio mesh.nucleoriofrio.com
* TlsOffload false (Traefik maneja SSL externo)
- Traefik conecta al puerto 443 interno
- Sin middleware authentik-forward-auth (OIDC nativo)
SOLUCIÓN AL PROBLEMA:
Los paths relativos en docker-compose creaban directorios nuevos
en cada ejecución de Gitea Actions (/root/.cache/act/HASH/).
Ahora usamos /srv/meshcentral/ fijo para persistencia real.
PELIGRO EVITADO:
- *.db contienen usuarios, dispositivos y todo el estado de producción
- *.crt/*.key son certificados que los agentes usan para conectarse
- Borrar certificados = todos los agentes dejan de funcionar
Solo es seguro borrar config.json para regenerar configuración.
- Detener contenedor ANTES de eliminar config.json
- Eliminar certificados y bases de datos viejas
- Generar config.json limpio con OIDC configurado
- Evitar duplicación de steps en el workflow
Elimina el config.json existente antes de generar uno nuevo para
asegurar que siempre se use la configuración actualizada con OIDC
y el puerto correcto (4430).
Configuración completa de MeshCentral con:
- Integración OIDC con Authentik
- Docker Compose para deployment
- Gitea Actions workflow para CI/CD
- Traefik labels para routing y SSL
- Separación de rutas de usuario y agentes
