WARNING: Port 443 of computer does not appear to be accessible using hostname

I’m doing this to set up Discourse: ./discourse-setup but i am getting the error in the image.
How can i fix this error ? I use Ubuntu 18.04

My DNS records:

My sudo ufw status verbose:

You have an unprintable character in the hostname you typed in:

image

Try again, but ensure you type it cleanly. If you’re copying/pasting, ensure the source is clean.

1 Like

There was no change.

Looks like you already have Wordpress running on that IP.

Yes, Wordpress installed. Can’t i use both on the same server?

It’s possible, but not easy. And you can’t use discourse-setup. I recommend that you first try on a server that’s not running somethign else

Running other websites on the same machine as Discourse.

1 Like

I followed these steps but got no results. Meanwhile i use WEBMIN.

Anyone have any other ideas ?

If the instructions at the topic I linked earlier don’t work for you then the easiest thing is to run discourse on its own server.

It’s going to be very difficult to make it work with webmin.

I know it will be difficult, but I don’t see myself as an amateur. I tried the instructions you linked. Are there any other links i should read?

There are a few #howto topics on the issue.

1 Like

Hey @Murto

FWIW, I find Discourse, as a back end Rails application, is much easier to set up if you configure Rails to use a unix domain socket versus a TCP/IP port; and set up the Discourse application behind a reverse proxy.

In that way, the TCP/IP ports are exposed via the reverse proxy only, and the Discourse application (and the container) is exposed via a unix domain socket; and you can run as many Discourse container instances you might want and not have to worry about conflicting TCP/IP sockets. In my view, this is a very clean way to run Discourse.

There are plenty of HOWTOs and tutorials on this site to guide you to set this up, if you get stuck and want to shift directions a bit. There is a “socket” template in the Discourse distribution you can use to set up the “Discourse part of the configuration”; and then you just set up the reverse proxy (countless tutorials on how to do that) and “away you go!”.

HTH.

4 Likes

I still couldn’t fix the problem. Is there anyone who can explain in detail? :roll_eyes:

try this out:

netstat -lnptu | grep :443

and then:

kill -9 PID (replace PID with the output number of the above command)

1 Like

I advise to put a reverse proxy in your server facing the internet, and make the reverse proxy redirect to Wordpress or Discourse depending on the host.

For example, run a nginx service using ports 80 and 443 in the host, and make it proxy the requests to blog.yourdomain to the Wordpress service (either an internal port on your host, if it’s Apache + Wordpress, in which case you could redirect to the apache port, like 8080, or using fastcgi).

Then in the same server you can run Discourse, making sure to replace the ports in app.yml to unused ports on the host, like 8081, or use a unix socket as @neounix said, then proxy the requests to forum.yourdomain to that port, or to the socket. To run discourse you will need to execute ./launch rebuild app in the discourse directory (should be /var/discourse)

In this case you wouldn’t run the discourse-setup to create a 2GB swapfile (mainly used for upgrades, that may require more memory, although you may not need it if your server has a lot of memory) and create the app.yml file. Instead, you should do that yourself. If you don’t know what to put in the app.yml file, I recommend running the recommended install in a separate server, even if only to be more familiar with Discourse, and to see the generated app.yml, that you could use in your shared server (remembering to change the ports or remove them if you use the socket approach).

I advise to follow one of the #howto topics about it, if you can’t proceed forward.

2 Likes

Can you explain how to do the reverse proxy process? I learned what to do, but i don’t know how.

I don’t have an example with me because I don’t use a proxy in front, although I think I implemented it some time ago. In any case, there’s no secret, it should be as you do with other reverse proxies. The following is just an overview of what should be done using ports (and not sockets):

  1. Make sure you have a Wordpress service running in a port that’s not 80 and 443 (example: 8443) and working. You can try to expose it to the internet first to see if it’s working.

  2. Make the same with discourse, mapping to different ports.

Change:

expose:
  - "80:80"   # http
  - "443:443" # https

To (for example):

expose:
  - "8081:80"   # http
  - "8444:443" # https

In your app.yml file (if you don’t have, I advise to run discourse in a standalone machine following the official guide just to see how it works, and take a look at the generated app.yml file at /var/discourse/containers/). Here is a sample of the app.yml file: https://github.com/discourse/discourse_docker/blob/master/samples/standalone.yml

  1. Install nginx and in its configuration file, add the proxy directives. They should be similar to the following sample excerpt:
upstream blog {
    server localhost:8080;
}

server {
    server_name blog.barinaklar.com;
    server_tokens off;
    listen 80;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        return 301 https://blog.barinaklar.com$request_uri;
    }
}

server {
    server_name blog.barinaklar.com;
    server_tokens off;
    listen 443 ssl;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        proxy_pass           http://blog;
        proxy_redirect		 off;
        proxy_set_header	 Host $host;
        proxy_set_header	 X-Real-IP $remote_addr;
        proxy_set_header	 X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header	 X-Forwarded-Host $server_name;
        proxy_set_header	 X-Forwarded-Proto $scheme;
    }
}

upstream forum {
    server localhost:8081;
}

server {
    server_name forum.barinaklar.com;
    server_tokens off;
    listen 80;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        return 301 https://forum.barinaklar.com$request_uri;
    }
}

server {
    server_name forum.barinaklar.com;
    server_tokens off;
    listen 443 ssl;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        proxy_pass           http://forum;
        proxy_redirect		 off;
        proxy_set_header	 Host $host;
        proxy_set_header	 X-Real-IP $remote_addr;
        proxy_set_header	 X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header	 X-Forwarded-Host $server_name;
        proxy_set_header	 X-Forwarded-Proto $scheme;
    }
}

This assumes you have Wordpress running in port 8080 and Discourse running in port 8081). Make sure to put a firewall to block access to these ports (cloud providers commonly block all ports by default, except 22, so it should may not be needed).

In this case you should be responsible of generating the ssl/tls certificates (you can do it with certbot running periodically in a cron job, so I already included the paths /.well-known/acme-challenge/ in the nginx configuration).


As I said above, this is just an overview and there might be something that I overlooked. You should pay special attention to the base url due to the change in ports (to see if doesn’t try to redirect the user to https://yourdomain:8081 instead of https://yourdomain, and make changes to make it work if needed).

This might not be needed if Wordpress is running in a container with port 80 or 443 inside the container. With discourse it should be ok too. The problem that may arise is regarding https, it may redirect to http because it is using the http port in the proxy, so you might need to see if it happens and fix it in such case.

3 Likes

Thanks for your help. I will apply and inform the transactions.