What is the best way to set the discourse hostname?

(Cyril Rohr) #1

Hello, I’m the maintainer of the discourse debian/ubuntu packages (hosted at https://pkgr.io/apps/pkgr/discourse). I can get Discourse up and running easily, but can’t figure out how to properly set the discourse hostname.

Based on the official discourse docker documentation, I should be able to set a DISCOURSE_HOSTNAME environment variable to something such as www.example.com, restart everything, and be done with it.

However, it does not seem to work (while other env variables such as DISCOURSE_DEVELOPER_EMAILS, and smtp stuff are correctly picked up), and I’m forced to set the force_hostname setting in the admin settings, as per the unofficial how to install on heroku documentation (in docs/install-HEROKU.md – sorry, can’t post the full link as it seems I’m limited to two links only…).

What is the correct way to do this?
Also, I must be blind, but I can’t see where all those environment variables are picked up in the code. Any pointers?


(Cyril Rohr) #2

Well, this part I found (GlobalSetting class, I was looking for uppercased settings).

(Cyril Rohr) #3

I’ve added some debug output to that GlobalSetting class, and it looks like my DISCOURSE_HOSTNAME is correctly picked up, but I still receive emails with as hostname in the url. Only when I force the hostname via the admin UI does it become correct.

Here is the output of the logging function

"lookup key=hostname, default="www.example.com", result="ec2-54-82-225-40.compute-1.amazonaws.com"

(Sam Saffron) #4

The only place force_hostname is used is here:

The code is certainly working:

 DISCOURSE_HOSTNAME=bla.com RAILS_ENV=production bin/rails c
Loading production environment (Rails 4.0.4)
irb(main):001:0> GlobalSetting.hostname
=> "bla.com"
irb(main):002:0> Discourse.current_hostname
=> "bla.com"

There are 2 options here:

  1. You are not passing your ENV in properly to sidekiq.
  2. You are using config/discourse.conf which overrides ENV.

(Cyril Rohr) #5

Thanks for the reply. Actually it seems there is indeed an issue in how sidekiq jobs get the hostname.

Adding debug output just before a job is performed, with DISCOURSE_HOSTNAME set to “ec2-54-82-117-17.compute-1.amazonaws.com”, I get:

GlobalSetting.hostname => "ec2-54-82-117-17.compute-1.amazonaws.com"
Discourse.current_hostname => ""

If we look at how Discourse.current_hostname works…

…we see that since force_hostname is not set, it delegates to RailsMultisite::ConnectionManagement.current_hostname:

Which, to my surprise, attempts to fetch the current hostname from database.yml! Mine does not have a host_names entry (heroku style), so it falls back to host, which in this case is

The question is: why doesn’t it try to fetch the current hostname from GlobalSetting?

Also, how do the docker images deal with that? I had a look at the discourse_docker repo but can’t find where the host_names entry is updated.

(Sam Saffron) #6

database.yml is checked into source control, it is not meant to be touched.

also see:

(Cyril Rohr) #7

I saw that piece of code, and I added a bit of debug in GlobalSetting.database_config to display the returned hash (https://github.com/discourse/discourse/blob/master/app/models/global_setting.rb#L29), and here is what I get when loading in production environment:

$ DISCOURSE_HOSTNAME=ec2-54-82-117-17.compute-1.amazonaws.com RAILS_ENV=production bin/rails c
[:hash, {"adapter"=>"postgresql", "pool"=>5, "timeout"=>5000, "username"=>"discourse", "host_names"=>["ec2-54-82-117-17.compute-1.amazonaws.com"], "database"=>"discourse"}]
Loading production environment (Rails 4.0.4)
irb(main):001:0> ActiveRecord::Base.connection_pool.spec.config
=> {:adapter=>"postgresql", :username=>"user", :password=>"pass", :database=>"discourse", :host=>""}
irb(main):002:0> GlobalSetting.hostname
=> "ec2-54-82-117-17.compute-1.amazonaws.com"
irb(main):003:0> Discourse.current_hostname
=> "ec2-54-82-117-17.compute-1.amazonaws.com"

So the global config looks correct, but when I get the spec from ActiveRecord::Base.connection_pool, it does not seem to be using that global config for the host_names entry. Not sure what goes wrong, as I haven’t had time yet to properly understand the ConnectionManagement class.

(Cyril Rohr) #8

Just a short update to let you know that v1.0.1 no longer has this issue, and everything works as expected when setting DISCOURSE_HOSTNAME. New packages are available at Packages for pkgr/discourse.

(Bersaelor) #9

Dear crohr, I used Packages for pkgr/discourse to install discourse on my debian wheezy.

There seems to be an issue how the host-url is resolved when using login via Google/Twitter/Facebook.
The redirect url back to my discourse-forum is never using the proper url but always just “localhost:6000”.
(I first posted about this here: Login via twitter/fb/google always uses “localhost:6000” )