6 Hours to install Discourse?
The format of forum software doesn't appear to have been updated for a long time. So I was very excited a few months back to hear about Discourse.
Yesterday I set about installing it. It took me about 6 hours. This does sounds like a surprising amount of time. However this did include signing up for linode[referral link], setting up an Ubuntu VM and following the Discourse Ubuntu installation guide.
This may still sounds like quite a long time. Whilst I've used Ubuntu before, it's certainly not my OS of choice. So, even though the install guide is good it took me a little long than I would have liked. Here's a full breakdown of what I did and the gotchas I came up against.
Note: I decided to use the latest release and not the latest source code so it may be possible that if I've come across any bugs that they've been fixed
Here are the resources I used:
Deploying Discourse with Capistrano - I didn't use Capistrano, but this article still has some useful tips in it.
Official Discourse Install Guide
Securing your server guide by Linode
Signing up for Linode[referral link] and setting up an Ubuntu 13.04 VM was super-simple.
I next followed the Linode - securing your server guide which didn't take long.
I was then ready to go with the Discourse install.
The Official Discourse Install Guide is really good. What I would recommend is that don't simply read a single step and execute it. Instead, read the full step and a little beyond, then execute.
There's also a video of installing Discourse on Ubuntu 12.04 if following a video guide is more your thing.
Gotcha 1: Don't Copy & Paste full command blocks
To start off with I would copy & paste full command blocks e.g.
# Run these commands as your normal login (e.g. "michael") sudo apt-get update && sudo apt-get -y upgrade sudo tasksel install openssh-server sudo tasksel install mail-server sudo tasksel install postgresql-server
Now, I can't 100% confirm this. But, when I did this I don't think the sudo tasksel install postgresql-server command properly executed. It wasn't until later that I noticed that postgresql hadn't actually installed.
I think I also experienced this problem when installing redis, later.
Gotcha 2: rvm requirements requires sudo permissions
This is an example of me not reading ahead. I didn't. If I had I'd have seen:
# If discourse does not have sudo permissions (likely the case), run: rvm --autolibs=read-fail requirements # and rvm will tell you which packages you (or your sysadmin) need # to install before it can proceed. Do that and then resume next:
After I'd read this properly and executed rvm --autolibs=read-fail requirements it was easy to work out which additional requirements I had to install (as the standard user) using sudo apt-get install <package_name>.
Gotcha 3: secret_token.rb
This wasn't really a big gotcha. Just a little unclear.
Execute RAILS_ENV=production rake secret
Copy the value that is output
Uncomment the line with SET_SECRET_HERE in it
Replace the SET_SECRET_HERE value with the value generated in step 1.
Delete everything else so your file will only contain a comment and:
Discourse::Application.config.secret_token = "some_generated_token_from_step_5"
Gotcha 4: rake db:migrate will fail if postgresql or redis aren't installed
Pretty obvious really! But this is where I found out that postgres hadn't installed. And then when I found out redis hadn't installed and wasn't running.
Gotcha 5: rake assets:precompile take time to complete
As above, this step isn't instantaneous. Nothing has broken, just be patient.
Gotcha 6: rake assets:precompile seems not to have worked
You may not noticed this until you think everything has completed, but if when running the app you get a message which contains something similar to:
<message>preload_store.js isn't precompiled</message>
Basically, anything saying "[something] isn't precompiled" it suggests that this rake task hasn't completed.
I checked and all assets appeared to be in place. In particular the preload_store.js file - and various other versions - where there.
I'm not 100% sure what fixed this. But I did find this discussion on meta.discourse.org which suggested setting the following in config/environments/production.rb to true:
# Disable Rails's static asset server (Apache or nginx will already do this) config.serve_static_assets = true #hack
I did that and didn't see any immediate fix. I then also set the following to true:
# stuff should be pre-compiled config.assets.compile = true # hack
Again, I saw no immediate fix.
It wasn't until I was forced to restart the VM - following my 4 hours trial time with Linode - that the problem seemed to fix itself.
Now, I had restarted discourse after each change using:
RUBY_GC_MALLOC_LIMIT=90000000 RAILS_ROOT=~/discourse RAILS_ENV=production NUM_WEBS=2 bluepill --no-privileged -c ~/.bluepill load ~/discourse/config/discourse.pill
Maybe that was wrong? So, I don't know what has actually fixed the problem I was seeing.
By this point Discourse was running.
Gotcha 7: clockwork is not running
If you go to the admin dashboard (see image above) in Discourse you get a handy set of information and warnings. I had a warning that "clockwork is not running".
I found a related and relevant discourse discussion.
As the discussion states this happens if the hostname doesn't match in ~/discourse/config/discourse.pill. However, even though I updated my hostname. See:
How do I change the hostname without a restart
echo [required_hostname] | sudo tee /etc/hostname
As suggested in the deploying discourse post clockwork still wouldn't start.
So - since I only plan to run Discourse on a single machine I edited discourse.pill to always run clockwork - no matter the hostname - by commenting out the if statement.
#if `hostname -s`.strip == "your-hostname.com" app.process("clockwork") do |process| pidfile = "#{rails_root}/tmp/pids/clockwork.pid" process.start_command = "/usr/bin/env CLOCK_LOG=#{rails_root}/log/clockwork.log RAILS_ENV=#{rails_env} bundle exec clockwork config/clock.rb" process.pid_file = pidfile process.start_grace_time = 30.seconds process.stop_grace_time = 10.seconds process.restart_grace_time = 10.seconds process.uid = user process.gid = group process.daemonize = true end #end
I appreciate this isn't a big help as it doesn't fix the problem. But, it might be handy of this weren't such a manual step.
Gotcha 8: Twitter auth results in 500 error
If you don't configure the Twitter settings then when you try to login with Twitter you get a 500 error. Simply set the settings by creating an application via dev.twitter.com and the login will work as expected.
The dashboard does actually tell you if social login is set but the appropriate settings haven't been saved. But the 500 error did raise alarms and I'm sure a nicer informative error page is on it's way - or has already been implemented.
The logs can be found in discourse/log and do provide you with the information you generally need to work out what's going on.
I'm guessing, but since I installed for production I don't think I got all that much information in there so may be a way of getting more debug information to work out why things aren't behaving.
Things I haven't done yet
I did set the SMTP settings but email isn't working.
As you can probably tell, I muddled my way through the install. So, around 6 hours - with natural breaks when my 2 year old would demand attention - probably isn't all that bad.
If I were to go through the process again I'm sure it would only take me a couple of hours. Maybe less.
I'm really excited to have my own version of Discourse up and running. And I hope that I can use it successfully and then start to contribute to the project. Maybe even if it's just pull requests against the docs - it all helps!
If you've read this far then you're clearly interested enough in trying out Discourse. I truly hope it does represent the future of discussion platforms.