I see that some images on this forum have an image lightbox where you can click on an image thumbnail and view the original image. Is there an admin setting to enable this as it does not appear to be working on our forum? I couldn’t anything relevant when searching the settings or this forum.
See Getting Tag-Informations from BuildChangeset does not work - VSoft Technologies Forums. The first image is 1307x207 and the markup (which was automatically generated when pasting the image into the editor) is . The original image is available If I right-click and open the image in a new tab but there is no light box available when I click on the image.
The setting is called ‘create thumbnails’. It is enabled by default. When enabled, it will create thumbnails and lightbox images that are too large to fit in a post.
The ‘create thumbnails’ setting is enabled. It appears to be creating thumbnails but not linking to a light box. We are running the latest version 2.2.0.beta4 +238
This implies your Discourse is not set up correctly, primarily because the background sidekick tasks necessary to do the background image work are not running.
I guess this could be related to our subfolder install (which is otherwise working very well).
If I navigate to /forums/sidekiq I just get forbidden.
This is our app,yml with the recommended mods for subfolder installation :
## this is the all-in-one, standalone Discourse Docker container template
##
## After making changes to this file, you MUST rebuild
## /var/discourse/launcher rebuild app
##
## BE *VERY* CAREFUL WHEN EDITING!
## YAML FILES ARE SUPER SUPER SENSITIVE TO MISTAKES IN WHITESPACE OR ALIGNMENT!
## visit http://www.yamllint.com/ to validate this file as needed
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Uncomment these two lines if you wish to add Lets Encrypt (https)
## - "templates/web.ssl.template.yml"
## - "templates/web.letsencrypt.ssl.template.yml"
## which TCP/IP ports should this container expose?
## If you want Discourse to share a port with another webserver like Apache or nginx,
## see https://meta.discourse.org/t/17247 for details
expose:
- "80:80" # http
- "443:443" # https
- "5432:5432" #postgres
params:
db_default_text_search_config: "pg_catalog.english"
## Set db_shared_buffers to a max of 25% of the total memory.
## will be set automatically by bootstrap based on detected RAM, or you can override
db_shared_buffers: "128MB"
upload_size: 20m
## can improve sorting performance, but adds memory usage per-connection
#db_work_mem: "40MB"
## Which Git revision should this container use? (default: tests-passed)
#version: tests-passed
env:
LANG: en_US.UTF-8
# DISCOURSE_DEFAULT_LOCALE: en
## How many concurrent web requests are supported? Depends on memory and CPU cores.
## will be set automatically by bootstrap based on detected CPUs, or you can override
UNICORN_WORKERS: 4
## TODO: The domain name this Discourse instance will respond to
## Required. Discourse will not work with a bare IP number.
DISCOURSE_HOSTNAME: www.xxxx.com
DISCOURSE_RELATIVE_URL_ROOT: /forums
## Uncomment if you want the container to be started with the same
## hostname (-h option) as specified above (default "$hostname-$config")
#DOCKER_USE_HOSTNAME: true
## TODO: List of comma delimited emails that will be made admin and developer
## on initial signup example 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'vincent@xxxx.com'
## TODO: The SMTP mail server used to validate new accounts and send notifications
# SMTP ADDRESS, username, and password are required
# WARNING the char '#' in SMTP password can cause problems!
DISCOURSE_SMTP_ADDRESS: mail.xxxx.com
DISCOURSE_SMTP_PORT: 25
DISCOURSE_SMTP_USER_NAME: vincent@xxxx.com
DISCOURSE_SMTP_PASSWORD: "xxxx"
DISCOURSE_SMTP_AUTHENTICATION: login
DISCOURSE_SMTP_ENABLE_START_TLS: true # (optional, default true)
## If you added the Lets Encrypt template, uncomment below to get a free SSL certificate
LETSENCRYPT_ACCOUNT_EMAIL: vincent@xxxx.com
## The CDN address for this Discourse instance (configured to pull)
## see https://meta.discourse.org/t/14857 for details
#DISCOURSE_CDN_URL: //discourse-cdn.example.com
# RATE LIMITING
DISCOURSE_MAX_REQS_PER_IP_MODE: 9999999
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: 999999
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: 999999
DISCOURSE_MAX_ASSET_REQS_PER_IP_PER_10_SECONDS: 999999
## The Docker container is stateless; all data is stored in /shared
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log
## Plugins go here
## see https://meta.discourse.org/t/19157 for details
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/discourse/discourse-voting.git
- git clone https://github.com/discourse/discourse-solved.git
## Any custom commands to run after building
run:
- exec: echo "Beginning of custom commands"
## If you want to set the 'From' email address for your first registration, uncomment and change:
## After getting the first signup email, re-comment the line. It only needs to run once.
#- exec: rails r "SiteSetting.notification_email='info@unconfigured.discourse.org'"
- exec:
cd: $home
cmd:
- mkdir -p public/forums
- cd public/forums && ln -s ../uploads && ln -s ../backups
- replace:
global: true
filename: /etc/nginx/conf.d/discourse.conf
from: proxy_pass http://discourse;
to: |
rewrite ^/(.*)$ /forums/$1 break;
proxy_pass http://discourse;
- replace:
filename: /etc/nginx/conf.d/discourse.conf
from: etag off;
to: |
etag off;
location /forums {
rewrite ^/forums/?(.*)$ /$1;
}
- replace:
filename: /etc/nginx/conf.d/discourse.conf
from: $proxy_add_x_forwarded_for
to: $http_x_real_ip
global: true
- exec: echo "End of custom commands"
Yes, yes, subfolder… I know (I spent a day getting it working). Surely if you are so against subfolders you would remove the guide and say absolutely not supported? It seems like it’s mostly there, so why wouldn’t you help resolve the issues as they are found and update the guide? In the end there would less topics like this, and more people using discourse.
I can navigate to /forums/logs ok, so I guessing something needs to change in the routing for sidekiq web?
Seeing this occurring a lot :
Job exception: Failed to open TCP connection to localhost:8080 (Cannot assign requested address - connect(2) for "localhost" port 8080)
I can confirm that sidekiq is running (and scheduled backups are still working).
You’re talking about the fundamental difference between sharing information and offering best-effort support. One doesn’t mandate the other.
The choice to share information to get you started with something doesn’t create any onus or responsibility to support it. We’ve suggested several times that you’re choosing to walk an unnecessarily painful path, this is another of those pain points - it almost certainly won’t be the last.
In 2018 there’s no good reason to run subfolder, which you’ve heard from us previously, it’s not deterring anyone from deploying the software.
@Stephen It just seems odd that each topic that has any info about subfolders get’s the standard “subfolders, world of hurt” type reply, when really there is usually something to be learned from the topic.
I also get that this is open source/free etc and we’re ‘on our own’ since we’re hosting it ourselves.
My recommendation would be to remove all references to subfolder installs, then no one will be enticed by a guide that looks doable at first glance.
As @jomaxro already quoted, the support statement is right there in the #howto for #subfolder. I don’t think it needs to be hidden, it’s there for any hosted enterprise customers or sites willing to accept the likelihood for complications, which you did when you read the document and continued down that path with your install.
All your experience has really done is prove that point. The team are very honest about what Discourse can and can’t do, all of the recommendations are there to give would-be administrators and developers a chance to enjoy and succeed with the product.
For those who choose to go off the beaten track the odd ‘thar be dragons’ sign is erected. The thing about dragons is that for the right price someone is usually willing to assume the time and risk to come kill them.
I won’t promise to have looked carefully at all of this, but Discourse should be on a non-standard port so that your external web server can do the reverse proxying. So I’m confused how it’s working at all. Can you really access other stuff on the server at, say https://yourodmain.com/?
My suggestion was going to be to try to curl http://localhost:PORT/sidekiq to see if you could access sidekiq.
If I access http://localhost/sidekiq in the container I get the standard this page is private or doesn’t exist response. If I try http://www.finalbuilder.com/forums/sidekiq I just get ‘Forbiddden’. Not sure about the non standard port, haven’t seen that mentioned anywhere with regards to subfolder installs. I get the feeling this is an issue with the proxy not passing enough info for sidekiq to authenticate.
I’m going to have a go at setting up a dev environment over the next few days and see if I can figure out what is going on, but not being a ruby dev (mostly c# and typescript) I’m not sure how far I will get.
So how am I ended up with another session with the root path? Anyway, putting this up here in case it proves useful info for someone. Still trying to figure out why I can’t access the sidekiq web interface (the intention being to see if there was any info on why the lightbox stuff isn’t working).
Ok, got past the Sidekiq issue, I found this in the unicorn.stderr.log
WARN -- : attack prevented by Rack::Protection::IPSpoofing
which lead me to look at the IPSpoofing source code and figured out the problem was the HTTP_X_REAL_IP header I was forwarding… removed it and now I an access sidekiq.
Sidekiq appears to be running normally, but lightbox is still not working. Any other suggestions on where to look?
Edit (since I can’t post more than 3 consecutive replies!) :
Problem solved. I found the same error as this case
in our production logs, and he mentioned dns. DNS appeared to be working, however I had it as 1.1.1.1, 8.8.8.8 on the host, I changed that around to 8.8.8.8, 8.8.4.4, 1.1.1.1 and rebooted the host (restarting the container didn’t seem to help).
I have no idea why this change worked, as I could curl the image url in the container just fine, and dns appeared to be working.
(which is otherwise working very well).
