Thanks! Done it the way you suggested. All I have left now is to wait 48 hours to see if this actually works.
The weird thing is that AWS (which I use to manage my hosted zones) usually takes just around an hour to make it all work with their own instances (and some dedicated servers from other providers). In this case (DO), I had to redeploy discourse 2 times thinking there was smthn wrong with the configuration (the dns record for the previous deploy failed to resolve after 14 or so hours). Fingers crossed.
Thatâs a consequence of your DNS TTL, not anything with the provider. Unless you chose to use Digital Ocean as your DNS provider.
What is up with this? Why is it required?
EDIT
it is required cause the rule will not work without it⌠just confirmed
From nginx.org:
If a large number of server names are defined, or unusually long server names are defined, tuning the
server_names_hash_max_size
andserver_names_hash_bucket_size
directives at thehttp
level may become necessary.
In my testing, the server/domain name was discourse.arpitjalan.com
, so increasing the server_names_hash_bucket_size
to 64 was required.
Does DISCOURSE_HOSTNAME
work with multiple domains, if I want either one of the domains to work without redirection? As in:
DISCOURSE_HOSTNAME: 'example1.com,example2.com'
?
No, why would it? You would create cookies at different domains (logged in at foo.com
but not bar.com
) and you would be subject to serious duplicate content penalties from Google.
Hello getting the below error. My forum is offline pls check
(<unknown>): did not find expected key while parsing a block mapping at line 81 column 7 -ANG=en_US.UTF-8
YAML syntax error. Please check your /var/discourse/containers/*.yml config files.
Run your app.yml file through an online YAML validator.
Is there any way we could make a command line YAML validator part of our Docker image and validate the YAML before we build? Cc: @sam
I think if we wrote a short Go program, it could get statically compiled and shipped in discourse_docker
. (Source in the repo, of course.) Would be much, much easier than trying to validate it in bashâŚ
It should be a Ruby program. I donât see why we canât ship a basic version of Ruby in the container. We need to normalize on standard code, unless there is some mission critical, absolute reason it canât be in Ruby.
(Or Node or io.js or whatever, isnât that already in our container @sam?)
I thought that the whole point was that this isnât in the container. If it was, we could just pull in Discourseâs yaml parser and use that.
./launcher invokes ruby quite a few times, so yeah we can run a validator ⌠but what I really want is to add support to toml or some other less crazy format into pups so container defs can be in a non space sensitive format (optionally)
Here is the error i get when I run the query ./launcher rebuild app
(<unknown>): did not find expected key while parsing a block mapping at line 16 column 1 -e LANG=en_US.UTF-8
YAML syntax error. Please check your /var/discourse/containers/*.yml config files.
And If I post the same code on YAML vailidator It shows the following error.
syntax error on line 51, col 2: ` DISCOURSE_SMTP_ADDRESS: 'smtp.mandrillapp.com' #(mandatory)
'
Somehow, I managed to solve the errors. Problem fixed. My forum is up now. Thank you.
I agree the better solution is to not use a format that is so easily mangled into âblow up with an exceptionâ land. Toml does seem pretty good so far.
However in the meantime it might be easier to just throw in a validation step.
Yeah this is going to take a while and @sam we should support either format as the YAML has been around a while now. So I think we should chuck a âvalidate YAML, or blow up with a specific warning that the YAML is not validâ step early in the launcher build process.
I tried this how-to and it works perfect! Thanks @techAPJ!
Only one more question: i have test my public discourse site with a SEO checker (woorank) and it shows this:
But in meta.discourse.org it shows:
Would you recommend us to add one more block following this how-to with the IP?
Something likeâŚ
- file:
path: /etc/nginx/conf.d/discourse_redirect_2.conf
contents: |
server {
listen 80;
server_name 1.222.33.444;
return 301 $scheme://talk.example.com$request_uri;
}
Can i use the same code to re-direct from https://www.mysite.com to non https://mysite.com ?
Yes you can (after making some changes in URLs), but as @riking mentioned earlier, itâs not recommended.