Our discourse Images are not lightboxed

[codinghorror (Jeff Atwood)]

@Michael_Uray

I renamed the app.yml with domain.name.yml and this caused docker to change the DNS name of domain.name to its internal IP address. I renamed it to domain_name.yml and everything is working fine now.

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

[eherman]

@Michael_Uray

Edit: I found out, that I renamed the app.yml with domain.name.yml and this caused docker to change the DNS name of domain.name to its internal IP address. I renamed it to domain_name.yml and everything is working fine now.

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

[Michael_Uray]

@eherman

meta.discourse.org.yml

Rename it to meta_discourse_org.yml.

[Stephen]

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

[eherman]

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.

@Michael_Uray

It shows me an error in the log file, that it cannot access /uploads/....

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.

[Michael_Uray]

@eherman

Which log file is this?

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

See also this article regarding Discourse logs.

Where does Discourse store and show logs?

When troubleshooting issues or errors with Discourse it is important you look at your logs. Here’s a listing of where they are and what’s in there. Your site domain Administration logs shown in the UI The Discourse admin panel contains several forms of logging: Emails that are sent, skipped, bounced, received and rejected are logged at https://=DOMAIN=/admin/email/sent and the neighboring tabs. Staff actions are logged at https://=DOMAIN=/admin/logs/staff_action_logs Email addresses and …

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.

Old image uploads become broken images

Lest anyone thinks that this query went unanswered, many thanks to @zogstrip for solving this. It seems that Discourse got confused about whether those uploaded images were being used and moved them for subsequent deletion. Though you will probably never need it, the fix went something like this: # copy the "deleted" images from their to-be-deleted staging area cd /var/discourse ./launcher enter app rake uploads:recover_from_tombstone # rebake to see that it doesn't happen again rake posts:re…

[eherman]

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 ?

[Falco]

@codinghorror

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

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.

[Michael_Uray]

@Falco

Didn’t use ./discourse-setup and created a yml file manually

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.

@Falco

Are using a reverse proxy

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

@Falco

This reverse proxy is magically configured using a docker container name

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.

[eherman]

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?

[Michael_Uray]

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

[eherman]

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 ?

[eherman]

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.

[eherman]

@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.

[Michael_Uray]

@Michael_Uray

./launcher enter app

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.