Imágenes de avatares de "letras" en Discourse rotas

Asociación GT Infraestructura
1

¡Hola! Al entrar hoy he visto que todas las imágenes en el foro de avatares que no son imágenes, sino que están basadas en las letras del alias del usuario, están rotas.

Por ejemplo, mi avatar es https://comunidad.es.python.org/letter_avatar_proxy/v2/letter/d/c5a1d2/45.png y al visitar la URL me sale un error de nginx “502 Bad Gateway”. ¿Alguna idea @yami? ¿Se ha cambiado algo? ¿Tiene algo que ver con el servicio https://github.com/discourse/letter-avatars?

2

Esta máquina me temo que yo no la he montado, ni conozco el servicio. Si no me equivoco, lo montó @pablogsal (mención ping!). Voy a echar un vistazo en la máquina por si veo algún servicio caído. Yo no soy consciente de ningún cambio en la máquina de discourse.

¿Desde cuándo te pasa?

3

Pues he entrado hoy al Discourse y es la primera vez que lo veo. Pero puede que esté así desde hace unos días.

Casi seguro que el letter_avatar_proxy apunta a un servicio en esa u otra máquina que está caído, y por eso lo del “502 Bad Gateway”.

4

En la máquina de discourse veo que hay un docker autocontenido (que está escuchando directamente en los puertos 80 y 443). Dentro del contenedor hay varios procesos levantados; he intentando ver qué dice nginx, pero parece que hay un error con la rotación de logs y no puedo ver nada.

Por otro lado, no conozco bien este container y no me queda claro cómo está corriendo, así que no me atrevo a relanzarlo, pues sería ponerme a jugar con la app en pro.

Al inspeccionar el contenedor he visto que efectivamente fue Pablo quien lo montó, así que esperaría a que él diera alguna pauta antes de lanzarnos a tocar.

5

Es raro lo que dices de la rotación de los logs. ¿Es posible que se haya quedado la máquina sin espacio para logs? ¿Puedes mirar el espacio libre?

En la config del nginx de Discourse he encontrado:

location /letter_avatar_proxy/ {
  # Don't send any client headers to the avatars service
  proxy_method GET;
  proxy_pass_request_headers off;
  proxy_pass_request_body off;

  # Don't let cookies interrupt caching, and don't pass them to the
  # client
  proxy_ignore_headers "Set-Cookie";
  proxy_hide_header "Set-Cookie";
  proxy_hide_header "X-Discourse-Username";
  proxy_hide_header "X-Runtime";

  proxy_cache one;
  # shared in multisite
  proxy_cache_key $request_uri;
  proxy_cache_valid 200 7d;
  proxy_cache_valid 404 1m;
  proxy_set_header Connection "";

  proxy_pass https://avatars.discourse.org/;
  break;
}

Así que casi seguramente sea el problema de avatars.discourse.org, que nosotros no controlamos.

6

Vale, no es un problema de ese servicio, es que la dirección IP del servidor de avatars.discourse.org ha cambiado de 62.210.249.41 a 185.172.150.128, pero el nginx creo que hace caché de la dirección IP del anterior dominio y no la recarga hasta que se reinicia nginx.

En https://www.nginx.com/blog/dns-service-discovery-nginx-plus/:

As NGINX starts up or reloads its configuration, it queries a DNS server to resolve backends.example.com . The DNS server returns the list of three backends discussed above, and NGINX uses the default Round Robin algorithm to load balance requests among them. NGINX chooses the DNS server from the OS configuration file /etc/resolv.conf .

This method is the least flexible way to do service discovery and has the following additional drawbacks:

  • If the domain name can’t be resolved, NGINX fails to start or reload its configuration.
  • NGINX caches the DNS records until the next restart or configuration reload, ignoring the records’ TTL values.

Así que yo creo que hay que recargar la configuración de nginx. Brace yourselves. :wink:

7

¡Arreglado!

  1. He hecho una copia de la base de datos haciendo sudo -u postgres pg_dump discourse > discourse-dump_2020-03-22.sql desde el contenedor.
  2. He copiado este dump a /shared dentro del contenedor.
  3. Desde el sistema host, lo he copiado a mi máquina local por SCP. El /shared del contenedor corresponde a /var/discourse/shared/standalone/.
  4. He ejecutado nginx -s reload, tal y como se describe en https://docs.nginx.com/nginx/admin-guide/basic-functionality/runtime-control/, no sin antes comprobar que la configuración era válida corriendo nginx -c /etc/nginx/nginx.conf -t.

Da bastante miedo cómo está montado todo, es magia negra interna de scripts de Discourse.

Quizá deberíamos mirar la posibilidad de cambiar la configuración para que se haga con " Setting the Domain Name in a Variable" y así se resuelva el dominio cada X tiempo, y no sólo cuando se inicia nginx. Porque si no, cualquier cambio de DNS de los servidores especificados en la config de nginx no tiene efecto y se rompen enlaces como ahora.

1 me gusta