Estoy de acuerdo, ¿se podría modificar el lanzador para advertir sobre esto o bloquearlo la próxima semana @falco?
Estoy teniendo el mismo problema. ¿Podrías aclarar exactamente a qué nombre debo cambiar el archivo .yml?
¿Es necesario incluir el TLD y el subdominio como parte del nombre del archivo .yml? Para este sitio, ¿sería meta.discourse.org.yml?
Cámbiale el nombre a meta_discourse_org.yml.
El único . en el nombre de tu archivo debe preceder a la extensión.
Gracias por aclararlo. Cambié el nombre del archivo y volví a compilar, pero aún no veo ninguna ventana modal (lightbox) ni efecto al pasar el cursor para mostrar la leyenda en ninguna imagen.
¿De qué archivo de registro se trata? Estoy tratando de confirmar si se trata del mismo problema.
También tengo activada la opción Forzar que tu sitio use solo HTTPS y el puerto 80 está bloqueado en el firewall.
cd /var/discourse
./launcher enter app
tail -f /shared/log/rails/production.log
Vea también este artículo sobre los registros de Discourse.
Si esto solo ocurre con las publicaciones existentes, pero las imágenes publicadas recientemente están bien, entonces me ayudó ejecutar
rake uploads:recover_from_tombstone
rake posts:rebake
Vea también allí.
Todo muy útil, gracias.
Parece que tengo el mismo problema con el error no se puede acceder a '/uploads/default...
La siguiente línea de mi archivo de registro es
Started GET "/posts/950" for 127.0.0.1 at 2020-07-07 08:24:05 +0000
¿Alguna idea de por qué el mío está intentando a través de la IP de loopback y no del contenedor recién nombrado o de la IP local del contenedor?
Esto parece ser específico de instalaciones no estándar que simultáneamente:
-
No utilizaron
./discourse-setupy crearon un archivo yml manualmente -
Están usando un proxy inverso
-
Este proxy inverso está configurado mágicamente usando un nombre de contenedor de Docker
Recomendaría no cambiar el nombre determinista actual del contenedor para todos para abordar este caso particular, a menos que también pueda ocurrir simplemente añadiendo un punto extra al nombre del archivo yml.
De hecho, sí lo utilicé, pero luego cambié el nombre del archivo, ya que tengo dos instancias de Discourse en ejecución y, de lo contrario, ambas se llamarían ‘app’ en la misma instancia de Docker.
Pensé que era razonable volver a habilitar el archivo con el mismo nombre que el dominio utilizado.
Probablemente sea bastante común que comunidades más pequeñas ejecuten varios sitios en un solo servidor.
No fue el proxy inverso lo que causó el problema con el nombre. Fue Docker mismo, ya que agrega automáticamente el nombre del contenedor a su DNS interno. El problema era que el nombre del contenedor de Discourse en Docker era el mismo que su nombre de DNS externo (por ejemplo, app.yml → meta.discourse.org.yml).
Propongo mostrar al menos una advertencia fuerte si el nombre del archivo coincide con el nombre de dominio proporcionado en el archivo .yml.
Sigo teniendo el mismo problema al no poder acceder a la imagen para obtener sus dimensiones.
No se puede acceder a ‘/uploads/default/original/1X/9385b0977b09b0f2239c287de980b6fc238d0da0.png’ para obtener sus dimensiones.
Esto ocurre con una instalación completamente estándar usando ./discourse-setup
¿Tienes alguna otra idea sobre cómo solucionarlo?
¿Qué sucede si intentas descargar la imagen dentro de tu aplicación Discourse?
./launcher enter app
wget https://yourdomain.com/uploads/default/original/1X/9385b0977b09b0f2239c287de980b6fc238d0da0.png
¿La resolución de nombres apunta a la dirección IP correcta?
apt-get update
apt-get install inetutils-ping
ping yourdiscoursedomain.com
o
apt-get update
apt-get install dnsutils
nslookup yourdiscoursedomain.com
Gracias de nuevo por tu ayuda, Michael, se agradece mucho.
Puedo hacer ping al dominio con éxito, pero parece que wget está intentando pasar por un proxy web.
He seguido esta guía y agregado la variable no-proxy en todos los lugares relevantes.
¿Estoy olvidando algo? ¿Cómo configuro el contenedor para que no use el proxy web que está usando el servidor? ¿Necesito agregar un no-proxy en app.yml?
Agregué mi dominio al parámetro no-proxy en el archivo app.yml y reconstruí la aplicación; ahora ignora el proxy como se requiere.
Sin embargo, sigo recibiendo errores al ejecutar wget desde dentro de la aplicación:
ADVERTENCIA: El certificado de ‘MYDOMAIN.com’ no es de confianza.
ADVERTENCIA: El certificado de ‘MYDOMAIN.com’ no tiene un emisor conocido.
Esto se debe a que mi certificado SSL proviene de una CA interna. Cuando ejecuto el mismo comando wget con la bandera --no-check-certificate, funciona correctamente.
¿Cómo puedo agregar el certificado para que sea de confianza o agregar la bandera para omitir la verificación?
@Michael_Uray ¿sabes dónde debo agregar la CA raíz para permitir que el contenedor de Discourse confíe en el certificado SSL?
He seguido esta guía (https://www.techrepublic.com/article/how-to-install-ca-certificates-in-ubuntu-server/), pero creo que se aplica al servidor en sí y no al contenedor que ejecuta Discourse.
Definitivamente tienes que entrar en el contenedor y agregarlo allí si no usas un proxy inverso, pero creo que de esta manera no será persistente. Supongo que tendrás que agregarlo de alguna manera al app.yml o hacer que la ruta correspondiente de CA dentro del contenedor sea persistente de alguna forma a través del app.yml.