Hello guys,
I’m currently not able to administer my forum and want to shut it down for a while as it needs a new SSL link which I haven’t figured out how to do yet. I don’t want any of our users to risk getting hacked.
Is it possible to prevent everyone from entering the forum for a while without completely deleting it?
I would really appreciate your help with this. Thanks!
Have you considered putting your site into read only mode? This can be found in the backups section of the admin settings your-site-name/admin/backups this will make your site read only so users cannot post etc.
If it’s a standard install, a rebuild should get a new ssl cert.
If you can’t or don’t want that, then You could put it in read-only mode as suggested.
You could also do a ./launcher stop app to shut down the container.
Hi ondrej,
Thanks for your reply. I read about this but it still diesn’t stop users from going onto the forum which already poses a problem as currently it is not secure (no https at the front of the link, i.e. no security certificate).
If your intention is to bring it back up once you have time to figure out SSL, what I would do is try using the built-in SSL templates first. Discourse makes it very easy for you to get and use Let’s Encrypt for SSL so it’s probably worth giving that a go before resorting to shutting it down.
If you want to try it, remove the # from the second and third lines of these near the top of your app.yml file:
## Uncomment these two lines if you wish to add Lets Encrypt (https)
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"
Next find #LETSENCRYPT_ACCOUNT_EMAIL: me@example.com further down the same file, again remove the # and also replace the example email address.
Finally, rebuild Discourse and it should obtain a Let’s Encrypt certificate and set up HTTPS, redirecting everything from HTTP.
cd /var/discourse
./launcher rebuild app
How did you install Discourse?
Unfortunately, I do not know how one installs Discourse or how this works in general. My father set up the forum for his business but passed away this year. We have a server with Linode and it is possible that Discourse is installed on that.
Thank you Simon for your detailed explanation. My father set up this website but he passed away this year. I have no idea about how to install and setup Discourse and don’t know about websites in general. Where do I find this appl.yml file? Would my father have installed Discourse onto our domain server? We use Linode and there is a “Linode” called “Discourse” on it. I just don’t know what this means and how to access the installation.
Thanks for your help.
Sorry for your loss. 
First and foremost, I highly suggest you ensure “backups” are enabled for that “Discourse” Linode. This should be your first, immediate step.
Secondly, make sure Discourse backups are also enabled at https://yoursitedomain.com/admin/backups
Thirdly, you may want to try running an update from the admin UI panel, directly from your web browser, as this could resolve your issues: https://yoursitedomain.com/admin/upgrade
That’s terrible. I’m so sorry to hear that. If you don’t know how to ssh into that server, the easiest thing is to make a backup, do a new install, and restore the backup there.
If you can get ssh access to the server then you can do the command line stuff described here.
Theoretically they should be able to reset the Linode SSH password:
That sounds pretty easy and would make it possible to pull over the working mail configuration. I’d likely still do a fresh install, as it sounds like this one is broken.
I’m not sure I agree with that. The default as per the included sample app.yml is to not use the web.ssl or web.letsencrypt.ssl templates and the lack of any HTTP redirection described by @Mads just sounds to me like that default has been kept, i.e. it never had SSL.
That seems pretty promising as being the server hosting Discourse. If you still want to shut it down, you could just power off that Linode but depending on how it was set up, there could be other things on that server as well.
As @sdpiowa said, you can reset the password as described in the link he provided. Scroll right to the bottom to Resetting the Root Password. You don’t need to do this if you already have the root password for that server though.
With the root password at hand, the simplest way of accessing the server is going to be using the LISH console on the Linode cloud manager.
At the last step when you see login: in the console, you would type root and press enter, then type the password and press enter again. At this point you should have a shell and be able to run commands on the server - note that you should be careful not to make mistakes here, most likely a mistake would just lead to an error and nothing happening but mistakes in a root shell can lead to damaging side effects.
Before going any further, be sure to create a manual Discourse backup and after that has completed, take a manual snapshot in Linode cloud manager. This way you know you have everything you need to recover if anything goes wrong.
Start by changing directory to get you into the right place:
cd /var/discourse
Linode images generally have nano installed which is a pretty easy to use text editor. Edit the app.yml file:
nano containers/app.yml
You probably can’t use your mouse to move the cursor so use the arrow keys to move around the file and make the changes described previously. Once you are finished with that, press CTRL+X to exit and you will be asked if you want to save, press Y to answer yes and you will be asked for a filename, just press enter and it will save the file and exit nano.
Finally, rebuild Discourse and do not close the LISH window after starting this:
./launcher rebuild app
If all goes well, probably 10-20 minutes later Discourse will be back up and running with SSL.
It’s been a pretty long time since https was on by default. It’s a decent bet that the OS is beyond end of life too.
IMHO, the easiest and safest solution for a novice is a fresh installation, but you’ve generously provided instructions that have promise for helping him get this thing worked out!
Thank you everyone for your help and detailed explanations! I might have found somebody who can help me with this and I will make sure to show them your advice. I really appreciate it 
You guys are awesome!
Thanks for all that info.
Matt here helping Mads, reasonably experienced sysadmin pretty comfortable on *nix, Docker made me dig a little deeper but got there.
Letsencrypt log said:
The CA is processing your order, please just wait. (1/30)
community.fruityknitting.com:Verify error:Fetching https://community.fruityknitting.com/.well-known/acme-challenge/9NEyZhZzZQ9FwGrqGqDNblLiwtOQQGlYr-9nSFUwKhw: Connection refused**
Nginx conf had an immediate redirect from port 80 to https and then I think Andrew had Discourse check for a valid account via Patreon, that port 80 redirect with Patreon redirect prob stopped Letsencrypt validating local file.
I stopped the Nginx 80 redirect, restarted Nginx and re-ran:
/shared/letsencrypt/acme.sh --cron --home /shared/letsencrypt
and success.
Appreciate the helpful comments everyone.
All the best.
Patreon redirect was not on https?
Twas Robert, perhaps more clearly stated as:
Nginx unconditional redirect of 80 to 443, and then Discourse app immediately forwarding to Patreon for a session or cookie or something I am guessing…
Enough to break the Letsencrypt validation.
Sound right?
I believe that’s out of the box to force all communication over https from any incoming over http.
The Patreon thing sounds a bit ‘funky’?
What is it trying to do that you couldn’t do in the application layer 100% over https?
Why does the reverse proxy have to care?