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.
@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
I think in this case, the discourse-setup install would require you to use nano or another editor to make the necessary changes – essentially you are no longer in “E-Z install mode” and must use the old method of editing the file.
Yep, that seems totally reasonable to me. I needed to set the port, and the username or password. Was very simple to fix, and I only posted about it because now the instructions don’t explain how to do those steps. Honestly, I think it would probably be enough to just include the old instructions as an alternative if you need to configure SMTP settings and not bother changing the script at all.
@pfaffman Is there any harm in rm -rfing the ssl/ and letsencrypt/ folders during ./launcher rebuild app? Since LetsEncrypt registration is free? (To perhaps avoid issues like mine where unrelated port expose issue thwarted cert registration.)
I’m not am expert, but there are limits to how many requests you can do, so you could really break things that way. The Right Way would be to delete them only if they were broken. Otherwise you could use up all your requests. Besides, we want to be good citizens.
If acme.sh can somehow corrupt those folders while issuing a cert, we should figure out the exact steps to reproduce the problem and open an issue with acme.sh.
Can we confirm that when acme.sh fails, “stuff left about” will actually break the template?
I too am having problem installing after the ./discourse-setup command. I’ve read and reread every instruction page on github (why are there so many???), but to no avail. Perhaps something I’m inputting wrong? See for yourself:
ENTER to continue, ‘n’ to try again, or ^C to exit:
sed: containers/app.yml: No such file or directory
DISCOURSE_HOSTNAME change failed.
sed: containers/app.yml: No such file or directory
DISCOURSE_DEVELOPER_EMAILS change failed.
sed: containers/app.yml: No such file or directory
DISCOURSE_SMTP_ADDRESS change failed.
sed: containers/app.yml: No such file or directory
DISCOURSE_SMTP_USER_NAME change failed.
sed: containers/app.yml: No such file or directory
DISCOURSE_SMTP_PASSWORD change failed.
Unfortunately, there was an error changing containers/app.yml
What version of Unix are you running this on? It looks like a problem with the commands the Bash script is running. They work fine on Ubuntu 14 and 16 but I suspect you are using something else?
Are you following the official install instructions literally line by line, exactly? Have you added anything extra or deviated in any way however small?
Line by line - I can recite them by heart now, if you like. Lol
However, I am not running Ubuntu. I’m on Debian at the moment and need to keep it that way because of work environment. Hmm, does it matter that I chose the recommended Ubunto droplet even though I’m on Debian? Sounds like a silly question, but that wasn’t in the instructions and everything else I run works fine on Debian.
I can’t repro this… I just installed using our standard guide on a new Digital Ocean droplet with Debian 8.3 x64 and there were no problems with ./discourse-setup.
Are you using a very old version of Debian?
(Well, there was a redundant sudo, but it didn’t break the install in any way, and I updated the script already.)
Question: are you logged in as root? Maybe you aren’t and that’s the problem? The install guide does say you need to be root.
Try running /bin/bash -x ./discourse-setup; this will print out a stupendous amount of stuff (it prints a debug line for every line in the script), but it should show exactly why the script is attempting to edit containers/app.yml without first copying that file into place. If you can’t work out what’s going on, stick the entire output into a gist; put dummy data into the questions so there’s no private data leakage.
Hmm. Was there an earlier error when it tried to copy standalone.yml to containers/app.yml? That code doesn’t do a check to see that it actually got copied. I’ll submit code that checks this Real Soon Now.
My best guess (I’m in an airport and have limited time to check, but here are a couple things to try) is that copying the config file failed. Two reasons that I can of is that you are in the wrong directory (unlikely because you presumably typed ./launcher . . . to start the script) and a permissions problem. I suspect the latter.
Are you root? Did you type su - at some point and do you see a # in your prompt?
BTW, even though you now have the nice installer script, the old way of doing this should still be covered by the installation manual. For a moment I was baffled by not seeing in the instructions and I did not remember by heart what was the source .yml filename.
I was just thinking that a couple hours ago. I was thinking that if the script fails it should say something about why and suggest editing the config file by hand. I think that it’s mostly the case (at least if the script is as robust as it should be) that if you are using an environment in which the script fails, it is because you are using some non-standard environment, and if you are, you likely know how to use vim and can make sense of the comments in the config file.
If I’m right that the problems people are having is due to their not being root (and I don’t yet know whether I am), the old instructions won’t help.
Yeah, and not to mention if the new community happens to have any traffic (one connects it to a popular site) and/or you are making the setup on anything bigger than the cheapest VPS offerings - one should tune the .yml settings for unicorns and database cache.
Well, I just put it here too, for other lazy bastards like me:
# db_shared_buffers: 128MB for 1GB, 256MB for 2GB, or 256MB * GB, max 4096MB
# UNICORN_WORKERS: 2 * GB for 2GB or less, or 2 * CPU, max 8
BTW, on a 4GB dual-core box (Intel Xeons) I’ve settled with 5 unicorns, as suggested by your awesome Matt Palmer. This shoul take you somewhere around or below ~100K daily pageviews before choking (heavily depends on your users’ behavioral patterns). It delivers 50K pageviews of traffic with nominal load and good responsiveness.
Sorry to resurrect but this exact error shows up when running the installer on an EC2 instance.
The solution is to create a medium sized EC2 instance (4GB of RAM) or larger. If you don’t want it to be that big you can likely downsize it after installation completes.
