Our discourse Images are not lightboxed

I agree, can launcher be modified to warn about this or block it next week @falco?

3 Likes

i am having the same issue, can you clarify exactly what you need to rename the .yml file to.

Do you need to include the TLD and subdomain as part of yml file. For this site would it be meta.discourse.org.yml

Rename it to meta_discourse_org.yml.

1 Like

The only . in your file name should precede the extension.

2 Likes

Thanks for clarifying. I changed the filename and rebuilt but I am still not seeing any lightbox or hover to show the caption on any images.

Which log file is this? I am trying to confirm if this is the same issue.

I also have Force your site to use HTTPS only on and port 80 blocked on the firewall.

cd /var/discourse
./launcher enter app
tail -f /shared/log/rails/production.log

See also this article regarding Discourse logs.

If this happens only to the existing posts, but the new posted images are fine, then it helped to me to run

rake uploads:recover_from_tombstone
rake posts:rebake

Please see also there.

1 Like

All really useful thank you.

It looks like i am having the same issue with the error can't reach '/uploads/default...

The next line of my log file is
Started GET "/posts/950" for 127.0.0.1 at 2020-07-07 08:24:05 +0000

Any ideas why mine is trying through the loopback IP and not the newly named container or the container local IP ?

This appears to be specific to non-standard installs that simultaneously:

  • Didnā€™t use ./discourse-setup and created a yml file manually

  • Are using a reverse proxy

  • This reverse proxy is magically configured using a docker container name

Iā€™d advise against changing the current deterministic container name for everyone to address this corner case, unless it can also happens by simply adding an extra dot to the yml file name.

3 Likes

I actually did use it, but renamed the file later since a have two Discourse instances running and otherwise both would be called app in the same Docker instance.
Thought it is reasonable to renable the file like the used domain.

Probably pretty common for smaller communities to run multiple sites on one server.

It was not the reverse proxy which caused the name issue. It was Docker itself since it automatically adds the container name to its internal DNS. The problem was, that the Discourse container name in Docker was the same name as its external DNS name (eg. app.yml -> meta.discourse.org.yml).

I propose to show at least a strong warning if the file name matches the given domain name in the .yml file.

Im still having the same issue with not being able to reach the image to get the dimensions.

Canā€™t reach ā€˜/uploads/default/original/1X/9385b0977b09b0f2239c287de980b6fc238d0da0.pngā€™ to get its dimension.

This is with a completely standard install using ./discourse-setup

Any other ideas on how to fix this?

What happens if you try to download the image inside your Discourse app?

./launcher enter app
wget https://yourdomain.com/uploads/default/original/1X/9385b0977b09b0f2239c287de980b6fc238d0da0.png

Does the name resolution point to the correct IP address?

apt-get update
apt-get install inetutils-ping
ping yourdiscoursedomain.com

or

apt-get update
apt-get install dnsutils
nslookup yourdiscoursedomain.com
1 Like

Thanks again for your help Michael, it is much appreciated.

I can ping the domain successfully but it looks like the wget is trying to go through a web proxy.

I have followed this guide and added the no-proxy variable in all the relevant places.

Am i missing something ? How do i configure the container to not use the web proxy the server is using. Do i need to add a no proxy to app.yml ?

i added my domian to the no-proxy parameter in the app.yml file and rebuilt and this now ignores the proxy as required.

I am still getting errors when doing a wget from within the app

WARNING: The certificate of ā€˜MYDOMAIN.comā€™ is not trusted.
WARNING: The certificate of ā€˜MYDOMAIN.comā€™ doesnā€™t have a known issuer.

This is because my SSL cert is from an internal CA. When i run the same wget command with the flag --no-check-certificate it works fine.

How can i either add the cert to be trusted or add the flag to not check.

@Michael_Uray do you know where i need to add the root CA to allow the discourse container to trust the SSL cert.

I have followed this guide however i think this applies to the server itself and not the container running discourse.

You have to go for sure inside the container and add it there if you donā€™t use a reverse proxy, but I think it will not be persistent on this way. I guess you have to add it somehow to the app.yml or to make the according CA path within the container persistent somehow via the app.yml.

1 Like