Installed without error but site wont come up


#1

Discourse was installed without error, but the browser displays : This site can’t provide a secure connection.

I think its Lets Encrypt thats causing this.

How can i rectify this issue ?


(Leo Davidson) #2

Does it work if you use HTTP instead of HTTPS?

Let’s Encrypt setup requires some extra steps when editing the app.yml file for the container. Were those done? You’d know if you had; if that means nothing then it’s probably what needs to be done. It isn’t automatic but is pretty simple if you look for the Let’s Encrypt guide here.

Let’s Encrypt also will only work if the DNS for the domain you are using is pointing to the server. Make sure that is changed first, and has time to propagate (based on the TTL value of your DNS entry before the change).


#3

no it doesn’t.

I checked the app.yml file. All the necessary lines were un-commented by default.

I’m sure the DNS is pointing to the server.

Everything seem right, I don’t understand why it won’t work.


(Matt Palmer) #4

ERR_SSL_PROTOCOL_ERROR means that the browser tried to talk HTTPS, but got something… mysterious… back. 99 times out of 100 it’s because nginx is misconfigured to not talk SSL on port 443; in the other instance, aliens have mucked with space-time (again!). In either event, without a way to reproduce the problem outside of your machine, there’s not going to be much anyone else can do to help you fix it. A copy of your app.yml and the generated /etc/nginx/conf.d/discourse.conf from the container might shed some light on the situation.


(Jay Pfaffman) #5

You might just do a rebuild. Perhaps something didn’t work when it built.


(Joshua Rosenfeld) #6

Please make sure to remove/censor all passwords/api keys in the file (if you upload it). Many people just copy/paste and then have to go back and change everything.


(Jay Pfaffman) #7

Sometimes I think about a script that would produce the app.yml sanitized and show disk and memory free. Then I think that it would work only for people who don’t need it.


(Jeff Atwood) #8

There are many many things like this in life.


(Joshua Rosenfeld) #9

What about extending launcher to support this? Something like ./launcher debug app or ./launcher config app?

@codinghorror is the feasible? Would it be #pr-welcome?


(Jay Pfaffman) #10

No. Launcher is intended to be not discourse specific. Discourse-setup could, but I’m still afraid that people who need it wouldn’t know to use it.


(Joshua Rosenfeld) #11

Well, the way I see it, whatever the command is, we could either say:

Can you please upload your app.yml and provide the output of free -m and df -h? Be sure to remove/censor any passwords or api keys.

or

Can you please upload the output from ./discourse-setup -debug?

The later seems a lot easier, either way someone has to ask for the information…


(Andrew Waugh) #12

I didn’t realize ./launcher wasn’t discourse specific. (so that’s my learning quota for the day satisfied).

Something like ./discourse-checkup which would return system status type info wouldn’t be a bad idea (see: Making launcher a bit more versatile)

./discourse-checkup -generate_reportfile could generate a report file with df -h, free -h, sanitized contents of the .yml file, docker info, and tail from various logs.


(Andrew Waugh) #13

I’m thinking of a triage command. The default should be for the output to indicate something like “All systems normal”, “Updates available”, “Faults detected”, running with --detail should give specifics.

A rough boilerplate:

HOST_INFO:
hostname: (hostname)
Linux Version: (uname -a, lsb_release -a)
status of updates: (apt-get -u upgrade)
Storage: (df -h)
Memory: (free -h)
Network: not sure of what would be useful here

DOCKER_INFO
Docker Install: (docker info)
Docker images: (docker images)
Docker containers: (docker ps)

DISCOURSE_INFO
app file: (sanitized content of %app.yml%)
disk use: (du -h /var/discourse/shared)
log fatal: (docker logs %container id%|grep FATAL)
log tail: (docker logs %container id% --tail 25)
What would be useful from the other logs, unicorn, prod, prod errors, nginx ?

I’m sure there is a way to filter the output of docker logs to be a bit more germain, my grep foo isn’t very strong.

What other info would be useful from a support viewpoint? AFAIK you can’t get user or post/thread count from outside the container, but the “disk use” in DISCOURSE_INFO gives you a rough idea of how much space the forum occupies.