Redirect additional domain(s) to your Discourse instance

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 and server_names_hash_bucket_size directives at the http 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.

2 Likes

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.

3 Likes

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

2 Likes

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.

2 Likes

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.

1 Like

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.

1 Like