For months I’ve been following the Diaspora* project. On 9/15/2010, they opened up their git repository, so that eager IT people like me could go grab their code, and start poking at it.
So, on 9/15, I watched their site eagerly waiting for the announcement. Sometime late evening (around 8-9PM EST) it finally popped up, the link to the git repo. I donwloaded it within minutes, and started tinkering on my laptop (Fedora 13), and had it up and running in about an hour.
I thought I’d write a little blog entry about the setup, and my initial thoughts.
First, i’ll say that Diaspora* runs on top of some rather new software. Fedora is a testing bed, it’s usually full of bleeding edge software, things that are being tested and vetted for eventual use in RHEL. I’ve had issues in the past where the versions of software in Fedora were so new, they were alpha, and i actually had to downgrade them in order to get things working.
Not so with Diaspora*. Diaspora* is written in ruby, and its data is stored in a noSQL implementation called MongoDB. There are no packages for MongoDB for Fedora, and the version of Ruby packaged in Fedora is one sub-revision too old. None of this was a huge issue on Fedora however. I grabbed Fedora Rawhide rpm’s for Ruby 1.8.7, and MongoDB is distributed in binary form, so i just grabbed the binaries and put them in place, which is actually detailed in Diaspora’s README.
This was all well and good, but i wanted to run this on a web server, not my laptop. I like Fedora for my workstations, but for a server.. I like things a little more conservative. So i run CentOS for all of my personal systems, and RHEL on all of the systems at work. Both distributions are similar, in fact, CentOS is based on RHEL, its just free, where RHEL requires a subscription. Generally, there are compatibility issues with bleeding edge software like Diaspora, and RHEL and its clones. This is because when a package reaches RHEL, its supposed to be completely stable. Bleeding edge is rarely completely stable.
So I built myself a new VM, which will host Diaspora. At this stage, I don’t fully trust the security of Diaspora, even the developers have come out and said that they know there are security issues with this release, but its pre-alpha! The VM makes it segregated, and means I can play with packages that I may not be willing to do on my production web server. If i hose it, just junk it and start over.
What I started with
CentOS 5.5
1GB of memory
1CPU
40GB Disk
Hypervisor: xen
Extra repositories
EPEL
RPMFusion (Free and non-free)
CentOS Install
Nothing special here, i installed the bare minimum, just the base packages, and networking.
Preparation
Once the OS was installed, I ran a yum upgrade, to get the latest packages for the base install, and rebooted.
After the reboot, i installed the following from yum:
screen
openssl
openssl-devel
git
vim-enhanced
gcc
libxslt
libxslt-devel
libxml2
libxml2-devel
ImageMagick
gcc
gcc-c++
You’ll notice that Ruby isnt in that list. Thats because ruby is at version 1.8.5 on CentOS, we need 1.8.7.
So, i installed the following from Source:
ruby-1.8.7-p302
rubygems-1.3.7
I ran into an issue when I built ruby that ruby-openssl didn’t build. I think this was because I didnt intially have openssl-devel installed. I added it later, and then built ruby-openssl by running “ruby extconf.rb” in (ruby source dir)/ext/openssl. This built and I was on my way. If it doesn’t build for you, you’ll find out when you try to launch Diaspora for the first time. if it gives you an error about openssl being missing, make sure openssl-devel is installed, and then build it for ruby as I’ve mentioned.
Now, we need Ruby’s bundler gem, so install from gem:
bundler (gem intall bundler)
Setting up MongoDB
This is noted in the Diaspora* README.md.
Essentially, unpack the MongoDB binary package, and then copy everything in (mongo directory)/bin to /bin on your system.
Then create /data/db with “mkdir -p /data/db”.
The Diaspora directions say to chmod -R 777 /data, but this seems insecure to me. mongod runs as root, so I gave some tighter perms a try. /data is owned by root:root, i set permissions to 700 recursively, mongo appears to start, and Diaspora functions.
Starting mongo is as easy as running “mongod” as root. I send it to the background so that I can free up my terminal.
Setting up Disapora* itself
If you don’t already have it, go get Disapora’s source. You can get it at GitHub or via git on the command line with “git clone http://github.com/diaspora/diaspora.git”. I put Diaspora in /var/diaspora.
Once you have the package, run “bundler install” in diaspora’s root directory.
If you run into errors here, you’ll need to track them down. Most commonly its caused by a missing package, or some other mis-configuration.
Once that finishes, you;re just about ready to run diaspora!
Running diaspora
Diaspora runs via ruby’s “thin” http server. To start diaspora run “bundle exec thin start”. You’ll see something like:
>> Using rack adapter >> Thin web server (v1.2.7 codename No Hup) >> Maximum connections set to 1024 >> Listening on 0.0.0.0:3000, CTRL+C to stop
This means that Diaspora is up and running! You can connect to it via http://yourserversip:3000
Some notes on running diaspora.
To run on standard port 80, you’ll need to add a -p 80 to your command line. “bundle exec thin start -p 80”
Also, i like to run it via screen, so i can detach it, and re-attach it later. “screen bundle exec thin start -p 80”
Then once its started, use ctrl-a, ctrl-d to detach from screen, then screen -list to find it again, and re-attach with screen -r (id from list).
Using Diaspora*
Now you should be to a point where you can actually login, and use Disapora.
Pointing a browser to your install will get you to the login page, first you’ll need to sign up. There’s a link for that on the page. Once you’ve signed up, if you intend for this to be your own little playground, and not open to registration, you can disable new signups by following the entry in the Diaspora FAQ regarding disabling outside registrations.
Keeping Diaspora up to date
If you’re running this pre-alpha code publicly, I’d highly recommend keeping it fresh with what’s available on the git repo. You can download it manually, or if you downloaded it via git in the first place, you can use “git pull” to grab the latest via the command line. Once you’ve done so, you’ll need to stop the server, and run “bundle install” again, and then “rake”. You could run this via a scheduler. I intend to write a script which does all of this. I’ll post it whenever i’ve done so.
A quick and dirty updater script, as promised.
[root@pod ~]# cat bin/updatediaspora.sh
#!/bin/bash
cd /var/diaspora
/usr/bin/git pull
/usr/local/bin/bundle install
/usr/local/bin/rake
/bin/kill `ps awx | /bin/grep 'thin start -p 80' | /bin/grep -v grep | /bin/grep -v SCREEN | $AWK '{print $1}'`
/usr/bin/screen -d -m /usr/local/bin/bundle exec thin start -p 80
Conclusion
I really like this project thus far. I’d like to learn more about how things are going to be linked later. Right now i’m unable to link to users on any other systems, I don’t know yet if this is an issue with the state of the project (i.e. not yet implemented) or a config issue on my part.
I have a few co-workers and friends using my install, its fun to toy with, I’ve not yet dug into any of the code. i don’t know ruby, so I’ll need to learn something about ruby before I’ll be able to make much sense of the source.
I like the idea of aspects for separating co-workers from friends, from whatever else. It does seem like this could get confusing until you get used to the idea however. The UI is nice, i like the styling and it doesn’t feel overly clunky. Which is saying something this early on. All in all, I can’t wait for this project to pick up more followers. …