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! :slight_smile:

I just ran it with letsencrypt on a fresh 2GB droplet (too lazy to fuss with setting up swap on a 1GB, but that should work too if you configure swap). wget -qO- https://get.docker.com/ | sh git clone https://github.com/discourse/discourse_docker.git /var/discourse cd /var/discourse/ ./discourse-setup app ./launcher start app And that was it! I’m glad it worked, as I’m dangerously close to hitting letsencrypt’s rate limits. [image] pztrick: 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. @pztrick’s problem probably is due to stuff left about when the ports were broken and le.sh failed. That would make sense because letsencrypt needs access to those ports as part of the certification process, so that’s a fragility of the letsencrypt template. (@tgxworld, maybe we need to have that script delete those directories if le.sh fails? Or test on the front end to look for bogus certs and delete them before it runs again?) I think that discourse-setup should probably not call ./launcher bootstrap app itself in case people need to fuss with something. Right now, people will need to edit app.yml by hand to deal with (1) allowing no SMTP username and password (requiring something explicit to make sure that people don’t omit them carelessly) and (2) SiteSetting.notification_email if they use sparkpost. I hope to get the script to deal with those cases tomorrow, but there will always be edge cases. Having discourse-setup do just the, you know, Discourse setup seems reasonable, and it can say Successfully configured, to bootstrap use ./launcher start app just like launcher bootstrap does.

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.

[image] downey: The container also isn’t listening on port 80 or 443 … I think I’m experiencing this problem too, is there a way to manually fix this till discourse_docker can be updated?

[image] savef: I think I’m experiencing this problem too, is there a way to manually fix this till discourse_docker can be updated? I didn’t notice any changes that should have broken launcher (in a quick look on my phone), so you should be able to: cp samples/standalone.yml containers/app.yml And then edit app.yml with your favorite editor and ./launcher bootstrap app

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. :frowning2:

I can’t imagine what’s up with the port stuff. Is expose: - "80:80" # http - "443:443" # https in your app.yml? [image] savef: I should also mention that this started after an out of memory exception during an upgrade If you have a 1GB droplet, do you have swap enabled? How much ram do you have? And if you had a working Discourse already I’m not sure why you’d have used this code. Do you have your old app.yml still around?

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.

[image] pfaffman: Is [ports] in your app.yml? 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! :stuck_out_tongue: 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… :confounded:

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 found the problem. and solved. in discourse-setup shell script at line 281 sed -i -e "s/^ #LETSENCRYPT_ACCOUNT_EMAIL: your.email@example.com/ LETSENCRYPT_ACCOUNT_EMAIL: $letsencrypt_account_email/w $changelog" $config_file you have to replace your.email@example.com with me@example.com and after that the script works

Problems with INSTALL-cloud.md directions

Product Support Self-hosting

pfaffman (Jay Pfaffman) April 27, 2016, 12:59pm 2

Thanks for the report! I’ll see if I can fix those things in the next few hours.

Topic		Replies	Views
Discourse not serving pages Self-hosting	25	3457	August 4, 2020
Discourse installation for beginners but are willing to be part of the community Self-hosting	62	5262	September 17, 2019
After Discourse installation can’t reach it in browser Self-hosting	24	4370	September 5, 2020
My Discourse is Down. Certificate Issue? Self-hosting	23	2294	February 22, 2023
Bootstrap error during Discourse install: ENOENT - /etc/runit/1.d/letsencrypt Self-hosting	24	808	November 21, 2025

Problems with INSTALL-cloud.md directions

Related topics