The journey to Diaspora: setting up your own pod
The first step in the journey to Diaspora is to get your own Diaspora server because, well, that’s the whole point of a distributed social network: you get to own your stuff (you could argue that, on the other hand, I’m not running my own email server, but, err, whatever, indulge me).
Unfortunately, setting up a Diaspora pod is insanely convoluted and complex.
After the jump, we’ll get into the meat of things and hopefully it will help you with the process (if you ever want to attempt it).
Follow the guide
Looking at the complexity of setting up a Diaspora pod, there’s something to be said about the Ruby community, who often seems to degenerate into a pile of over-engineered, over-complex set of weirdly named libraries and tools, all of which end up being very slow and memory hungry. Hipsters was the worse thing that ever happened to the Ruby language.
Anyway, enough trolling, you probably want to start by following the installation guides, over at Github. My server is an Ubuntu virtual machine so I followed the Ubuntu guide which will make you
apt-get install a whole lot of packages, from system libraries to Ruby and the usual suspects (
rake, etc.). Once that’s done, you move on to the Diaspora installation guide itself, which is where things get fun (given a certain definition of “fun”), and where I’ll try to hold your hand (no homo).
Note that several “easy installer” initiatives are being worked on, mostly targeted at popular hosting companies like Heroku. By the time you read this, you may have something available for your situation.
Get an SSL certificate
The first thing you need is an SSL certificate for your domain. Since you’ll be exchanging potentially private communications between your pod and the other pods, it’s a good idea to go through
https, which means getting an SSL certificate. You could usually use a self-signed certificate for this, but the bigger pods (a.k.a “community pods”) won’t accept that, so you need a proper certificate.
The documentation will point you at StartSSL, which delivers free class 1 certificates for your domain for a year. That’s enough to get you started. Just go to their website and follow the instructions – you’ll end up with a few keys and other serious-looking files. If you plan on hosting your pod on a sub-domain, don’t forget to add your top-level domain to the alternative domains falling under the certificate.
If you keep following the installation guide, you will at that point have cloned the Diaspora repository on your server, run a few commands like
bundle install, and edited a few configuration files. Here are a few tips, though:
- Before you do all the RVM and
bundlerstuff, make sure you
apt-get install libreadline-dev libncruses-dev. Hopefully this will make the
readlinegem work right away. We’ll talk about that later.
- For some reason, the
config/application.yml.examplefile features a
pod_urlwith a port 3000 specified. Make sure you take this out when you replace it with your own domain URL. This has to be the real, public URL (otherwise your Diaspora ID will have
- For me, the
/etc/ssl/certs/ca-certificates.crt, but it of course depends on your Linux distribution.
Of course, you’ll need to follow the instructions for setting up a “production” server. Don’t set
true, there’s no need for that – Apache will serve the static assets already. Set
false, too, because it looks like it’s mostly for development/debugging purposes.
I’d recommend setting up the mailer right away (it’s the thing that sends notification emails). For some reason, even when
false, Diaspora will try to send some emails, resulting in errors and failed jobs. It’s not a huge deal (maybe), but I like to avoid false positives in my error logs. Here it goes:
- Set the
- That’s it! (although you can optionally set some nice email address for the sender).
Setting up the database
For some reason, the config files assume you’re going to run the app with the
root MySQL user. I don’t know what they’re smoking over at DiasporaHQ but there’s no way I’m going to do that, so instead I created a new database myself, called
diaspora_production, and a user with access to that database. You could call the database differently, I guess, but you would have to go and change the default name in all the configuration files. And I’m not sure if there’s any hard-coded stuff somewhere that references that database, so I went with the safe route of using their naming convention.
Once that’s done, you don’t need to run the
db:create Rake task. Just run
bundle exec rake db:migrate. You should see your database filling up with tables.
Now you’ll need a web server to actually get anything working. I’m using Apache for this.
The first thing is to make sure the SSL/
https stuff will be working:
- If you don’t have that already, add
Listen 443to your
conffiles to make Apache listen to incoming connections on port 443 (which is used for
https). You can put that next to the similar directives listening to port 80 (which is standard
- You’ll need to open port 443, obviously, in case you have a firewall (which you should have). Again, just look for where it deals with port 80, and copy/paste. If you’re using
iptables, you should end up with something like
-A INPUT -p tcp --dport 443 -j ACCEPT.
- Make sure you have
Then, add an entry for the new website (your pod). You can use this Apache configuration that they point to in the installation guide. The only modification I did is to add a reference to the
SSLCACertificateFile I got from StartSSL. So all my SSL stuff would look like this at the end:
SSLEngine On # You generated those with StartSSL SSLCertificateFile /path/to/cert.crt SSLCertificateKeyFile /path/to/private_key.key # You got those from StartSSL SSLCertificateChainFile /path/to/sub.class1.server.ca.pem SSLCACertificateFile /path/to/ca.pem
For the rest, you don’t need to change much except the path to the Diaspora repository you cloned with Git. Make sure you specify the path to the
public folder, not the root folder, otherwise it won’t find all the CSS and images and such.
Also note that you’ll need
mod_proxy_http loaded/enabled for this to work.
Running the pod
Holy shit. See, what did I tell you, that it was insanely complicated? Well, it’s not quite over yet.
Now you can at last run
./script/server, wait a bit, and go visit your brand new pod. If everything’s good, you should have a little “lock” icon in your address bar (and if you click on it, it tells you your domain is verified by StartCom Ltd.). You should also see the Diaspora welcome page.
Go and signup! It’s all yours!
When that’s done, you can go back to
config/application.yml and set
true so that nobody else can create an account (if that’s what you want).
Kill the server with CTRL+C and, while it’s down, open the Rails console with
bundle exec rails c.
Remember when I talked about the
readlinestuff? Well, if you didn’t do it well, that’s where it fails. If so, you’ll have to patch the
readlinegem like I had to.
make install. Make sure you’re using the same version of Ruby to run
extconf.rbthan the version you’re patching! (if you only have one Ruby installed, you don’t have to worry about that last detail).
Running the console is for adding your newly created user to the “administrators” role, so you can get access to the administration dashboard: go to this FAQ page and look for “Roles”. You should see a bunch of stuff you need to type in the console to make yourself an administrator.
When you’re done, start the server again with
On your pod’s website, in the top-right menu (where you have “Contacts” and “Log Out”) you should see a new entry called “Admin”. Click on it. The most useful page here is the last one: “Resque Overview”.
Resque is the background job manager, which takes care of a lot of important stuff for your pod. The overview page will show you, among other things, any failed jobs. This is useful to troubleshoot problems and send bug reports.
Another hidden page is at
/admin_panel. This is the Rails panel dashboard, where you can basically hack into your database to fix things, compare values, or clean data. It’s a bit dangerous but can be useful at times.
That’s it! If you made it this far, congratulations, you have absolutely no life. You should, at this point, be able to send useless status updates to your so-called friends, with the warm feeling that comes with using open standards.
In the next post in this series, we’ll look at all the problems you will face with your Diaspora pod – and there are many, unfortunately.