I haven’t tried following the INSTALL-cloud.md instructions for a while, and they’ve changed and now there’s this new ./discourse-setup script. Problem is, it doesn’t work, at least on the base Ubuntu image for DigitalOcean.
First, there isn’t execute permission on the ./discourse-setup script. Easy enough to change but might block some.
After answering the prompts, I get the following.
Press ENTER to continue, 'n' to try again, or ^C to exit:
LETSENCRYPT_ACCOUNT_EMAIL change failed.
web.ssl.template.yml enabled
letsencrypt.ssl.template.yml enabled
Unfortunately, there was an error changing containers/app.yml
root@host:/var/discourse#
This seems like some type of permissions issue, but not sure.
Update: Apparently these is super (like hours) new, so I guess someone had to be first!
And, hmm … FWIW, I manually kicked off the bootstrap process, but it ended up giving me letsencrypt errors. (I haven’t messed with let’s encrypt before, so not sure how to fix it, so I’m just removing it from my app.yml for now and rebuilding.)
The container also isn’t listening on port 80 or 443 …
Never really had these kind of problems before, so not sure what’s going on.
Thanks for the quick reply, I should’ve provided more information in my last message. I was having this issue with the ports not being bound with my existing app.yml, but am continuing to get it after generating a new one (with the discourse-setup). I’ve rebuilt several times and rebooted the containers, docker and the server quite a few times and can’t figure out what’s happened.
I should also mention that this started after an out of memory exception during an upgrade (through /admin/upgrade). I had to change my SMTP settings anyway so after the exception I just did a launcher rebuild and my forum hasn’t been online since. I know the container and nginx are running because inside the container I can do nc localhost 80 and get a response, whereas on the host I’ll get a connection refused.
But it’s as if some changes have been made to discourse_docker that have simply broken the app config file’s ability to declare the ports it needs to forward.
I agree. My app settings look correct AFAICT with regard to ports exposed, and the ports are listening inside the container, but not on the host. Unfortunately I used all the time I allocated for this install already today, so it will be a while before I can investigate further. Maybe someone can repro with a new clean install.
Yep, in both (the old working one and the newly generated one). It sounds like @downey is experiencing the same thing so I’m at least glad it’s not just my machine and not my fault.
If you have a 1GB droplet, do you have swap enabled? How much ram do you have?
Yes, 1GB droplet with 1GB of swap. A long time ago these used to be quite common for us during upgrades, but adding the swap back then fixed it. This is the first time I’ve seen one since.
And if you had a working Discourse already I’m not sure why you’d have used this code.
Because my working Discourse isn’t working!
And yes I kept my old app.yml. It has quite a few customisations so I’ll be switching back to it once this ports issue is sorted.
The main reason I tried using the script is because I figured my app.yml must’ve been outdated, so I was expecting that after generating a new one I’d be able to see what was different and go from there in terms of fixing mine, but since the newly generated one didn’t work either…
My server is back online, unfortunately I don’t have time at all to look into what’s going on though. I checked out HEAD~25 and rebuilt and it works. Hopefully that’ll narrow down where the problem might be for whoever looks into it.
Edit: I decided to take a quick look anyway, my guess is it’s this bit which was removed from launcher.
I’ve fixed the sed replacement so that it’s not so finicky about those addresses in a soon-to-be submitted PR. This seems to fix the config_file edits, but it looks to me that the launcher problem above is the real culprit.
I’ll submit a PR that fixes launcher in a few minutes.
I went through the directions again (doing my app.yml manually for now) with a fresh/clean install starting from nothing, but the ports still weren’t active. I’m trying to the workaround (commenting out the line in launcher) in the other post, though, and that worked… but Lets Encrypt is still causing errors so the site isn’t functional.
@downey After pulling latest changes for port expose, port 80 worked but not SSL.
Then, for SSL, I also had to follow advice in another thread and delete the /var/discourse/shared/standalone/ssl and /var/discourse/shared/standalone/letsencrypt folders. Then, SSL worked. Could try that?
Sorry for the issues, the port problem was 100% my mistake! Thanks for that fix @tgxworld.
We’re trying to make setup a bit easier by prompting people for common values using the discourse-setup script. I can confirm the version as of right now works fine, I just built and bootstrapped a site with it.
I am not 100% sure the Let’s Encrypt stuff works, but @pfaffman will be testing it and looking into it today or tomorrow.
I found I still had to manually edit app.yml and then run sudo ./launcher bootstrap app. This was because the discourse-setup script requires SMTP username and password, and I don’t need to set that (it’s an internal SMTP server at my company). Fortunately I’d gone through the process recently so I knew what to do, but if I hadn’t done so before I might’ve been lost when the discourse-setup process said it couldn’t continue. Just posting in case anyone else runs into that.
