Discourse automatically switched from http to https


(Tom Hsiung) #1

Couple of days ago I have configured and enabled my SSL apache web service. It seems after that the Discourse failed to work.

CONTAINER ID        IMAGE                 COMMAND             CREATED             STATUS                  PORTS               NAMES
344d2f37baed        local_discourse/app   "/sbin/boot"        6 weeks ago         Exited (9) 3 days ago                       app

By the command of sudo docker ps -all I could see that the app was in exit status. Then I ran the command of sudo docker start app and the system feedback:

Error response from daemon: driver failed programming external connectivity on endpoint app (9f4af91af7f844403674367dc1c7652e0db30c70abcf23f879cec57a16332f63): Error starting userland proxy: listen tcp 0.0.0.0:443: listen: address already in use

Error: failed to start containers: app

In addition to the configuration of SSL, I also have rebooted my service several times. I have not done anything to Docker. So, it seems that the docker and Discourse switched itself from http to https.


(Bhanu Sharma) #2

Here is Your problem.
apache is using the port 443 on your server. You should configure discourse container so that the external requests are handled by apache and then internally forwarded to discourse.

one way is to use sockets if apache supports them. or else use a proxy pass


(Tom Hsiung) #3

Thanks for the answer, you meant like this:

## 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
  - "60000:443" # https

(Bhanu Sharma) #4

This is the app.yml part.

you will also need apache to be configured so that it forwards all ssl requests made to your discourse domain to passed to port 60000


(Tom Hsiung) #5

However, before I enabled the SSL. I left the port 80 to Discourse and I assigned another port to apache http service (e.g., I changed the default port of http service rom 80 to 81).

At present, the https web service use default 443 port. So I am think to leave the port 443 for https web service, and to switch the Discourse (https)'s port from 443 to others (e.g., 444)


(Bhanu Sharma) #6

Why would you run services to weird ports when you can configure them to run at their own hostname using SNI.

take some help about configuring apache from this topic.


(Tom Hsiung) #7

It seems that the Discourse will check both http port and https port, while server rebooted. And because I have assigned port 443 to my https web service, so after the server rebooted, the Discourse check both the 80 port and 443 port, after which the Discourse found that 443 had been taken, and then later the Discourse boosting failed.

Tom


(Bhanu Sharma) #8

Can you please describe what you’re trying to achieve? are you trying to host another website alongside of discourse on the same server?

there are tutorials with nginx if you want to do so.


(Tom Hsiung) #9

After changing the 443:443 to 6000:443, and rebuilding the app, my Discourse site got back. I could access my Discourse site via 80 port (I had assigned another port other than 80 to my http web service).

Tom


(Stephen) #10

You need to properly explain what it is you’re trying to achieve, rather than how you think you need to go about implementing it.

Discourse is capable of SSL without the need for Apache, Let’s Encrypt is part of the setup. Are you attempting to run other HTTPS sites alongside it on the same host?


(Tom Hsiung) #11

Yes. I host apache2 on my server, along with discourse too. So I have assigned port 80 to Discourse and Discourse works well at present with that port. And I have assigned another port for my apache web service (http).

Just a few days before, I enabled the SSL apache web service, with default 443 port. Because I thought my Discourse used port 80, so I did not modify the SSL apache web service’s default port (443). And this was the cause. Like the booting check of a computer, the booting of Docker also checks (I guess so) if the ports (both http and https) that Docker use are free. And if there is conflict of port assignment, the docker program fails.


(Stephen) #12

(Tom Hsiung) #13

Thank you guys, the issue has been fixed.