traefik 404 not found con huarpe en despliegue con múltiples nombres de dominio

Expediente Electrónico Integrado SUDOCU - Técnicos
1

Buenas,

Estamos avanzando con el despliegue de producción y lo venimos trabajando con múltiples dominios, las peticiones entran desde un nginx fuera de la vm del cluster. En el nginx servimos sudocu.unpaz.edu.ar, lo mismo con idm, idp araidocumentos el front y en los labels de traefik deshabilitamos las entradas

#- "traefik.http.routers.huarpe.entrypoints=web-secured"
#- "traefik.http.routers.huarpe.tls=true"

ya que nginx se encarga de los certs tls

Nos anda todo ok, pero con huarpe no le podemos encontrar la vuelta, nos aparece el 404 page not found como si no existiera la ruta.

la regla host que tenemos en huarpe.yml es

        - "traefik.http.routers.huarpe.rule=Host(`siuhuarpe.unpaz.edu.ar`) && (Path(`/`) || PathPrefix(`/saml`, `/js`, `/img`, `/bloque`, `/css`, `/perfil`, `/avatar`, `/docu>

el servicio está corriendo y en los logs muestra


(1034)-[siuclustermanager1]-[vie feb 11 18:40:43]-[/usr/local/proyectos/sudocu/sudocu-unpaz/prod/arai]
[root] # docker service logs lsktgbzfdv78
huarpe_memcached-server.1.co5orh02uuet@siuclustermanager1    | memcached 18:07:15.63 
huarpe_memcached-server.1.co5orh02uuet@siuclustermanager1    | memcached 18:07:15.64 Welcome to the Bitnami memcached container
huarpe_memcached-server.1.co5orh02uuet@siuclustermanager1    | memcached 18:07:15.64 Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-memcached
huarpe_memcached-server.1.co5orh02uuet@siuclustermanager1    | memcached 18:07:15.65 Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-memcached/issues
huarpe_memcached-server.1.co5orh02uuet@siuclustermanager1    | memcached 18:07:15.66 
huarpe_memcached-server.1.co5orh02uuet@siuclustermanager1    | memcached 18:07:15.67 INFO  ==> ** Starting Memcached setup **
huarpe_memcached-server.1.co5orh02uuet@siuclustermanager1    | memcached 18:07:15.72 INFO  ==> Initializing Memcached
huarpe_memcached-server.1.co5orh02uuet@siuclustermanager1    | 
huarpe_memcached-server.1.co5orh02uuet@siuclustermanager1    | memcached 18:07:15.78 INFO  ==> ** Memcached setup finished! **
huarpe_memcached-server.1.co5orh02uuet@siuclustermanager1    | memcached 18:07:15.81 INFO  ==> ** Starting Memcached **
(1035)-[siuclustermanager1]-[vie feb 11 18:41:06]-[/usr/local/proyectos/sudocu/sudocu-unpaz/prod/arai]
[root] # docker service logs ghnzp72b1ekl
huarpe_webapp.1.2i05sydipglc@siuclustermanager1    | 
huarpe_webapp.1.2i05sydipglc@siuclustermanager1    |  // Clearing the cache for the prod environment with debug                      
huarpe_webapp.1.2i05sydipglc@siuclustermanager1    |  // false                                                                       
huarpe_webapp.1.2i05sydipglc@siuclustermanager1    | 
huarpe_webapp.1.2i05sydipglc@siuclustermanager1    |  [OK] Cache for the "prod" environment (debug=false) was successfully cleared.  
huarpe_webapp.1.2i05sydipglc@siuclustermanager1    | 
huarpe_webapp.1.2i05sydipglc@siuclustermanager1    | sirviendo . . .
huarpe_webapp.1.2i05sydipglc@siuclustermanager1    | AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.0.1.215. Set the 'ServerName' directive globally to suppress this message
huarpe_webapp.1.2i05sydipglc@siuclustermanager1    | AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 10.0.1.215. Set the 'ServerName' directive globally to suppress this message
huarpe_webapp.1.2i05sydipglc@siuclustermanager1    | [Fri Feb 11 18:07:20.577217 2022] [mpm_prefork:notice] [pid 28] AH00163: Apache/2.4.39 (Unix) PHP/7.1.28 configured -- resuming normal operations
huarpe_webapp.1.2i05sydipglc@siuclustermanager1    | [Fri Feb 11 18:07:20.577272 2022] [core:notice] [pid 28] AH00094: Command line: 'httpd -D FOREGROUND'

y en el log de traefik vemos la regla con el host ok.

en la instalación de prueba todo con un único dominio en una misma vm todo funciona ok, quizás tenga que ver con eso y el path / ?? con el idp nos pasó algo similar y debimos levantarlo con idp.unpaz.edu.ar/idp, porque con sólo / nos pasaba lo mismo, pero con huarpe estamos intentando, sudocu e idm con sudocu.unpaz.edu.ar e idm.unpaz.edu.ar (quitando /sudocu y /idm) van bien.

quizás sea algo simple pero no estamos logrando verlo, alguien tiene un despliegue similar o algo de info que nos pueda servir para investigar el tema?
gracias!

2

Hola Maximiliano,

Huarpe estaba pensado para desplegarse en / y funcionar en ese punto, por ej, https://eei-universidad.edu.ar/ normalmente te lleva a Huarpe.

Por otro lado, para validar que este todo bien, pueden probar acceder a alguna URL directa de Huarpe y ver si pueden descargar el favicon.ico


wget https://siuhuarpe.unpaz.edu.ar/favicon.ico

Si eso les da 404, es porque es un problema de config de las URL. Traefik tiene el dashboard que les permitiría revisar las reglas que pudo levantar y el matcheo entre la entrada, procesamiento, salida. Con eso pueden corroborar visualmente si tuvieron algún error en las URL o config.

Saludos!

3

Hola! Gracias por la respuesta.
Efectivamente teníamos un error en un label de traefik en huarpe.yml y no levantaba.

Ahora ya no da 400, sin embargo al acceder aparece error 500, haciendo docker service logs nos muestra:


huarpe_webapp.1.tq29ihplzdsv@siuclustermanager1    | [Wed Feb 16 17:57:26.860606 2022] [php7:notice] [pid 31] [client 10.0.1.219:52048] [2022-02-16 17:57:26] security.ERROR: The response was received at http://siuhuarpe.unpaz.edu.ar/saml/acs instead of https://siuhuarpe.unpaz.edu.ar/saml/acs [] [], referer: https://idp.unpaz.edu.ar/
huarpe_webapp.1.tq29ihplzdsv@siuclustermanager1    | 10.0.1.219 - - [16/Feb/2022:17:57:26 +0000] "POST /saml/acs HTTP/1.1" 302 524 "https://idp.unpaz.edu.ar/" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:97.0) Gecko/20100101 Firefox/97.0"
huarpe_webapp.1.tq29ihplzdsv@siuclustermanager1    | 10.0.1.219 - - [16/Feb/2022:17:57:26 +0000] "POST /saml/acs HTTP/1.1" 302 524
huarpe_webapp.1.tq29ihplzdsv@siuclustermanager1    | [Wed Feb 16 17:57:26.924566 2022] [php7:notice] [pid 31] [client 10.0.1.219:52048] [2022-02-16 17:57:26] app.ERROR: The response was received at http://siuhuarpe.unpaz.edu.ar/saml/acs instead of https://siuhuarpe.unpaz.edu.ar/saml/acs [] []
huarpe_webapp.1.tq29ihplzdsv@siuclustermanager1    | [Wed Feb 16 17:57:26.928936 2022] [php7:notice] [pid 31] [client 10.0.1.219:52048] [2022-02-16 17:57:26] request.CRITICAL: Uncaught PHP Exception Symfony\\Component\\Debug\\Exception\\FatalThrowableError: "Call to a member function getAplicacionesAccesibles() on string" at /usr/local/app/src/CoreBundle/Menu/MenuProvider.php line 56 {"exception":"[object] (Symfony\\\\Component\\\\Debug\\\\Exception\\\\FatalThrowableError(code: 0): Call to a member function getAplicacionesAccesibles() on string at /usr/local/app/src/CoreBundle/Menu/MenuProvider.php:56)"} []
huarpe_webapp.1.tq29ihplzdsv@siuclustermanager1    | 10.0.1.219 - - [16/Feb/2022:17:57:26 +0000] "GET /saml/login HTTP/1.1" 500 1215 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:97.0) Gecko/20100101 Firefox/97.0"
huarpe_webapp.1.tq29ihplzdsv@siuclustermanager1    | 10.0.1.219 - - [16/Feb/2022:17:57:26 +0000] "GET /saml/login HTTP/1.1" 500 1215

En Araí tenemos configurado los datos de SAML así:


{
   "https://siuhuarpe.unpaz.edu.ar/saml/metadata": {
      "AssertionConsumerService": "https://siuhuarpe.unpaz.edu.ar/saml/acs",
      "SingleLogoutService": "https://siuhuarpe.unpaz.edu.ar/saml/logout"
   }
}

Al ingresar sin estar logueado a siuhuarpe.unpaz.edu.ar va correctamente al idp, pero al loguearse correctamente va a huarpe y sucede el error (lo mismo estando desde araí usuarios y clickeando el ícono de huarpe en el menú de aplicaciones).

Qué podrá ser?

4

Hola Maximiliano,

Bien, lo que sucede es que se están topando con un problema de SAML y el manejo de HTTP y HTTPS. En EEI por defecto todo sale con HTTPS detrás del proxy reverso traefik por lo cual no hay inconveniente.

En el caso de Uds, al usar un proxy externo que maneje HTTPS y luego se haga HTTP la comunicación hacia traefik, Huarpe no puede acceder a nada que le indique que está detrás de un proxy reverso https (porque en el caso de uds, no es un salto directo, se trata de un segundo proxy reverso, los headers X_FORWARDED_ se pierden entre el primero y el segundo).

La recomendación sería comenzar a mirar en este punto el código de Huarpe, quiźa cambiando y estableciendo en $ip la IP del proxy reverso ngnix (es configurable en HUARPE_PROXY acá).

Saludos!

5

Hola Sergio, gracias por responder.

Configuré la ip del nginx en HUARPE_PROXY y nada, lo mismo.
Respecto del código de huarpe creo faltó el link al punto del código en tu respuesta, igualmente revise en el código de huarpe y agregué la IP del nginx en Request::setTrustedProxies en web/app.php (no sé si te referías a este archivo) pero sigue igual.

Quizás debería replantear el despliegue, no sé si tienen alguna recomendación alternativa de desplegar con múltiples dominios ya que la documentación supone las apps en rutas y fuimos por esto del nginx ya que nos era conocido. Logramos tener andando sudocu, el idp, el idm y fluye entre las tres cosas pero con huarpe nos pasa esto.

Sigo revisando y haciendo algunas pruebas, cualquier otra información / idea es bienvenida, mil gracias!

6

Hola!

Actualicé el post anterior, con la URL, disculpas! De todos modos, ese era el punto a observar: Huarpe (Symfony) necesita ser configurado para operar detrás de un proxy reverso. Allí se modifica para confiar el origen del proxy en $ip y luego para confiar en los tipos de headers.

Puede estar pasando que tu proxy reverso NO sea la IP que le están proporcionando, prueben (tip: para descartar cualquier error adicional, prueben Request::setTrustedProxies([‘0.0.0.0/0’]) o similar. Si funciona, es porque la IP que proporcionan del ngnix no logra llegar como el intermediario “REMOTE”. tip2: prueben dumpear los headers de la petición en ese punto, para conocer si dichos headers X-Forwarded-XXX son reenviados por ngnix y por traefik, otra posible causa de que no funcione).

EDIT: respecto a la pregunta de cambiar los dominios, es cierto EEI en el ejemplo está lanzado con paths para los módulos en vez de subdominios. Tranquilamente pueden editar las reglas del traefik en cada despliegue para solo tenga las reglas “host(subdominoi.domino.com)” y por supuesto ir actualizando en cada módulo a conciencia su URL (ej: IDP_URL, IDM_URL_XXX, etc)

Saludos!

7

Maximiliano,

En esta doc de Traefik, se muestra como ajustar para permitir que los headers de proxy reverso Ngnix atravise Traefik para llegar a Huarpe.

No lo hemos probado aún… se los dejo a modo comentario! Saludos!