- Agregar ambos dominios al certificado SSL (APP_DOMAIN y MESH_AGENTS_DOMAIN)
- Configurar tlsPort: 443 para que MeshCentral escuche HTTPS
- Cambiar TLSOffload a false para que MeshCentral maneje su propio SSL
- Actualizar certUrl para apuntar al dominio de agentes
- Agregar configuraciones adicionales: minify, localSessionRecording, allowedOrigin
- Eliminar variable MESH_PORT no utilizada
- Mejorar mensajes de deployment
- Remover REVERSE_PROXY y REVERSE_PROXY_TLS_PORT que sobrescribían config.json
- MeshCentral ahora usará tlsPort: 443 definido en config.json
- Esto permite que el TCP passthrough funcione correctamente
- Corregir sintaxis del label TCP que causaba error de interpolación
- Agregar variable MESH_AGENTS_DOMAIN al workflow
- Reemplazar bash parameter expansion por variable de entorno estándar
- Configurado router TCP con SNI para mesh-agents subdomain
- Habilitado TLS passthrough para que MeshCentral maneje su propio certificado SSL
- TCP service apunta al puerto 443 interno del contenedor
- Mejorada organización de labels con secciones HTTP y TCP
- 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.
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).
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
