Running other websites on the same machine as Discourse

Hi,

I am just doing a fresh install of Discourse.
I am very surprised that :

  • The setup script does not simply allow to setup on a different port, disabling SSL support, and then it’s up to us to do reverse proxy as we want (Apache, Nging) : It seems such a common setup, it would save hundreds of hours of life to humanity
  • I am even more surprised that the setup redirects us to an outdated forum topic, in which we need to dig for the proper information, instead of a proper documentation page, kept up to date.

Thanks guys anyway for your work, but I think there is room for improvement here.
Cheers

4 Likes

Agreed, but Discourse is not expected to work on a non-standard port.

The installer may propose another default installation scheme with no port exposed, no SSL/Let’s Encrypt, and the socketed template actived by default (cf. OP’s howto).

For me, it has been the fastest way to achieve reverse proxy with an external nginx, and it would be cool to be able to bootstrap Discourse this way.

4 Likes

I don’t think that this really is a common setup, using a proxy up front is an advanced topic imho. The docs are pretty clear about it that you should start with a bare VM, still I agree that it should list 80/443 as a requirement for the setup wizard.

Editing docs on Github is a breeze, just done via browser.

If you want to help enhance the wizard, the source can be found here:

4 Likes

The setup script is designed to help people who are not system administrators install discourse. One who does not know how to edit a yml file to change the port has no business trying to configure a reverse proxy setup.

1 Like

Well, I don’t agree with that :
I don’t think anyone who does not know how to edit a yml file nor has basic system admin skilsl would be able to setup discourse anyway.

I followed the tutorial saying to use this nifty script : I would expect it to handle the basic cases.
I think adding support for reverse proxy is usefull anyway.
I will do a PR for this soon.

1 Like

The basic case is to get discourse up & running!! The script does it just fine.

I disagree. Adding reverse proxy makes it more complex to manage the installation and will not be a piece of cake for hundreds of self-supported installs that don’t understand why they need a reverse proxy.

2 Likes

Adding a question like :

Do you want to install Discourse behind an existing web server ? If so enter the port number [NO]

would be too much complex you think ?
My intention is just to add this question and change the port mapping depending of the answer.

1 Like

And my intention is to make you understand that if someone wants to do that, There are instructions readily available.

./launcher bootstrap app

should probably be enough who want to do any changes to the yml themselves.

Ok.
I lost half an hour on this, I really think hundreds of other people also did lose quite a bit on time on this (given how gigantic and outdated this instruction thread is).
But if you don’t want help on that, I have others things to do.

Cheers.

2 Likes

It is a wiki! if You feel like instructions are outdated, feel free to update them accordingly.

4 Likes

Hello
I had the same problem with Plesk.
And could solve it as follows:

Docker Ports:

expose:
         - "8060:80"   # http
          - "9443:443" # https
  • Discourse setup was standard with Docker.
  • Let´s Encrypt takes over Plesk.

The problem was. If you make 2 entries in the Docker proxy, only the last one will be written to Nginx.conf.

Why manual?
Because the following entry is important for SSL:
proxy_set_header x-Forwarded-proto HTTPS;

Otherwise you won’t be able to log in.
CSRF error

I hope it was understandable with my english :slight_smile:

I am German and cannot speak English so well. So excuse me.

3 Likes

Just wanted to share how I accomplished this, it was a little easier than I first thought.

From an already running machine, with Caddy acting as a reverse proxy for a number of existing Docker containers already.

  1. Clone discourse as per the official instructions
  2. Copy /var/discourse/samples/standalone.yml -> /var/discourse/containers/app.yml
  3. Fill in SMTP settings and website address
  4. Comment out 443:443 from the expose: section
  5. Replace 80:80 -> 3001:80, 3001 being the port I’m serving via Caddy
  6. Run ./launcher rebuild app
  7. Done

Whop!

7 Likes

@TheBestPessimist I swapped the order of the HTTP/HTTPS sections, it works better than adding a “don’t do this!” notice :slight_smile:

6 Likes

This post gave me the comprehensive plan of attack, and thank you for documenting it!

I found a simpler (and maybe cleaner?) TLS configuration already called out by Ghost, which was the first service installed, here’s how I adapted it for Discourse:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name forum.example.com;  # <-- change this

    ssl_certificate      /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key  /etc/letsencrypt/live/example.com/privkey.pem;
    include /etc/nginx/snippets/ssl-params.conf;

    http2_idle_timeout 5m; # up from 3m default

    location / {
        proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:;
        proxy_set_header Host $http_host;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

The SSL cert is a wildcard cert (for *.example.com), so I only have the one cert to manage for all sites on the server.
My version of Nginx complained that ssl on was deprecated, and apparently snippets-ssl.conf provides modern support for TLS, the details of which I don’t have to bother my pretty head about.

3 Likes

This is helpful, for anyone who never stopped running the original site installed on the server. Since the app.yml will not have been created, the var/discourse/samples/standalone.yml serves as a good starting point from which you can make the edits recommended in this thread.

This could just be me being naive, but I didn’t realize the app.yml provided here was truncated. Also explains why I wasn’t prompted for anything other than smtp password when I ran the setup script.

@riking do you think it would be valuable to add a note about where to find a full .yaml example if you are creating one from scratch, or even provided a full version with the edits. I suppose it could be an aside after the part where you mention that the guide assumes that you already have Discourse working.

Thanks so much anyways, this is helpful regardless

1 Like

is anyone using discourse with ssl enabled in the app.yml? I noticed that eventually the ssl enable setting will cause discourse to become unusuable. Commenting out:

#  - "templates/web.ssl.template.yml"
#  - "templates/web.letsencrypt.ssl.template.yml"

was the only way to get it to work well but I would perfer encryption on both the reverse proxy and discourse.

Thank you so much, this is the first time I using Discourse for my forum.

If the reverse proxy is on the same machine there is no reason for https on Discourse.

1 Like

Thanks so much. :slight_smile:

Setup reverse proxy like this, running nginx outside the container, would the outside nginx talk to discourse backend directly or go through the inside nginx? I mean is there any performance penalty?
I ask because I might need to custom the nginx setting a bit in the future.

Cheers,