- Cambiar extra_hosts a IP de Traefik (172.19.0.6)
- Agregar aliasPort: 443 para URLs externas correctas
- Usar issuer HTTPS público (via Traefik con SSL)
- Deshabilitar IPv6 en el contenedor (sysctls)
- Optimizar resolución DNS (dns_opt)
- Forzar resolución interna de authentik.nucleoriofrio.com a 172.19.0.5
- 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.
MeshCentral ya tiene OIDC configurado directamente en config.json
con authStrategies, por lo que no necesita el proxy outpost de
Authentik. El SSO se maneja nativamente a través de OIDC.
Agregar ulimits para resolver error EMFILE "too many open files"
- soft: 65536
- hard: 65536
MeshCentral requiere abrir muchos archivos simultáneamente para
file watchers, superando el límite por defecto de contenedores.
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
