As we edge closer and closer to Discourse 1.0 – which should happen in the next two months – we continue to improve our install story.
This topic is for comments on the original blog entry at: http://blog.discourse.org/2014/04/install-discourse-in-under-30-minutes/
Just tried this. I hereby grant you the “Newb Friendly” sticker of approval. Thank you for all your hard work!
p.s. If the prospect of setting up a swap file bothers you, you can save yourself a lot of trouble by going with the 2GB version for $20, which is the recommended minimum amount of horsepower anyhow.
The 1GB instance runs fine provided modest reasonable number of users and load. If you know for sure your Discourse will be low volume for the foreseeable future, it is a better and less expensive choice.
The only time you typically need swap is during the /admin/docker upgrade process. And Sam’s recent Sidekiq upgrades free up about 7% more memory on top of this.
1GB is a 100% officially supported install now, the swap file is just a bit of insurance!
Awesome!! I love this!
What is recommended to keep Ubuntu up to date? I assume it doesn’t do any sort of automatic updates, or does it? A way to schedule automatic updates at 3am or something would be good, or maybe weekly?
The way that you’re “supposed” to have unattended critical updates in Ubuntu is
sudo dpkg-reconfigure -plow unattended-upgrades
It brings up a ncurses window and you choose Yes or No.
I found an easy way too to have the server email you when there are updates available:
apt-get install sendmail
apt-get install apticron
(and edit /etc/apticron/apticron.conf and just change the line: EMAIL = “root” to EMAIL = "youremail@address.com")
What’s the situation for keeping the system software installed inside the docker image up to date with security issues? Any solutions for that?
Every so often, or when a relevant security update is issued, a new “base image” is released, and you need to rebuild your container to get it. The upgrade screen should notify you if the image is out of date (@sam confirm?)
As a system administrator looking after this for a client, I’m not likely to be logging in to discourse much, unless it’s to check for these notices. Is there a command line test for available updates which could be run? IDeally something suited to scripted notifications, or to just trigger the rebuild operation being run. Is the rebuild process stable enough for that to be advisable?
You generally need to do security updates / reboot on the base Ubuntu OS every 6 months or so anyway. So while you are doing that, ssh in then
cd /var/discourse
git pull
./launcher rebuild app
done!
Like you said elsewhere Jeff, the base OS can be managed with automatic updates, and daily updates is a reasonable default schedule. There’s not a lot of systems where I’d be comfortable with a 6 month time frame for updates. The past year’s OpenSSL exploits come to mind, and https://www.drupal.org/PSA-2014-003
While it’s not perfect, it seems like it might be a good idea to run automatic updates for the container as well as the host. Updates that aren’t stored in a docker volume would be lost on the next container restart, but would at least be replaced some time over the next day, and if the container restart is a rebuild, then the updates would presumably get applied more permanently in that process anyway.
Since the unattended-upgrades package comes as standard on Ubuntu, and that’s what the container runs, the package is already there in the container. I can presumably set up a cron job outside the container to run it via docker exec.
Only certain ports of the container are visible on the parent system, though. It would have to be a vulnerability in Nginx, SSL itself (ala Heartbleed), and … that’s about it. So it’s a very narrow attack surface within the container.
Or an attack on Discourse. Which has 1-click updates.
Just in the few days since I engaged in this discussion, we’ve had updates for libcurl3 and tzdata.
I’m guessing you probably fetch something or other with curl or libcurl, and maybe with some effort there’s an exploit there. I don’t want to have to look into that closely.
You probably have some Egyptian users who care about the daylight savings changes in tzdata. It’d be much nicer if those definitions got automatically updated before the change.
This is the downside of providing a “fat” Docker image. You’re essentially providing an OS image and get all the fun that goes with that in terms of keeping up with security advisories etc…