DistOS-2011W Diaspora

From Soma-notes

cha0sPod

cha0sPod is currently offline, as I am setting a pod up on a remote server rather than a home server, for better performance. Link will be posted in this section upon it going live.

Introduction

For my implementation report, I will be setting up and using a server running Diaspora. Diaspora is a distributed social network meant to directly compete with centralized social networks such as Facebook and Twitter. My report will focus on my personal experience with Diaspora, both as an administrator as well as a client. Due to time constraints, most of the administrator reporting will involve setting up the pod, while the client portion will focus on the interactions of two test user accounts.

Section 2 describes the specifics of Diaspora, particularly how it functions from the client's perspective, Section 3 describes how Diaspora pods communicate with each other, Section 4 covers my experience in setting up a Diaspora pod, Section 5 includes additional details in regards to the management of the cha0sPod, Section 6 covers my experience in using Diaspora as a client, Section 7 contains my conclusion, and Section 8 includes all references made in the document.

What Is Diaspora?

How It Works

Setting Up Diaspora

Preparation

For the purposes of evaluating a Diaspora implementation, I have opted to set up a home server. The home server in question is an old Dell Dimension 3000 running Ubuntu 10.04 and an Apache server. After registering the domain cha0sNet.com and configuring my router, my server was online.

Steps used in setting up cha0sPod can be found at Diaspora's main site.[1]

The next step is installing some additional software. The following section includes the title of the software, a brief explanation of what it does, and the command for installing it in Ubuntu.

Build Tools: Specific Build Tools used to compile the other software packages.

            sudo apt-get install build-essential libxslt1.1 libxslt1-dev libxml2

Ruby: A programming language.

            sudo apt-get install ruby-full

MySQL: A database for the server.

            sudo apt-get install mysql-server libmysqlclient-dev libmysql-ruby

OpenSSL: An open-source (durr) encryption library.

            sudo apt-get install libssl-dev

ImageMagick: Image processing library used to compress and resize uploaded images.

            sudo apt-get install imagemagick libmagick9-dev

Git: A version control system used to download and update Diaspora.

            sudo apt-get install git-core

Redis: key-value store used for background job processing.

            sudo apt-get install redis-server

RubyGems: Package manager for the Ruby programming language. Used to install “library” gems.

            sudo add-apt-repository ppa:maco.m/ruby
            sudo apt-get update
            sudo apt-get install rubygems

Bundler: Manages gems.

            sudo gem install bundler

With all the prep work completed, my system is ready to host a new Diaspora pod. The details of that are outlined in the next section.

Setting up the Pod

The first obvious step is to actually download Diaspora from the git repository, which can be done with the following command:

            git clone http://github.com/diaspora/diaspora.git

Next, change directories so that you are in the diaspora root directory. The diaspora directory is located wherever you ran the git command, unless specified otherwise. Not realizing this, I ended up installing it in my home directory, before eventually moving it to /var. Successfully switching to the diaspora directory (tricky I know), running the command:

            bundle install

will install Diaspora’s gem dependencies.

The next step is starting MySQL, which I had previously set up while configuring my Apache server. It says to run

            sudo service mysql start

to get the database started, but for me it started automatically on installation.

With all this out of the way, it’s time to configure Diaspora so that it actually works (An important feature).

Configuring cha0sPod

Up to this point, everything was going fine. I followed each step outlined by the main site, and more or less it all went smoothly. This is the moment where it stopped going smoothly.

The first bout with configuration comes in the app_config file. To create it, run the code:

            cp config/app_config.yml.example config/app_config.yml

and then change certain values within the file. The only field I changed during my initial configuration was:

            pod_url: http://www.cha0sNet.com

though, I’m not really sure if that was necessary. So, everything fine here.

Configuring the database comes next, a process similar to the above configuration. Run the code:

            cp config/database.yml.example config/database.yml

The values in this file are more important, since this is where you configure the user/password Diaspora uses to access your MySQL database. Just enter username/password used for the test, development, and production databases. I used the same account for each one, because I’m risky I guess. Obviously the user account needs to be created before or at this stage, unless you just used root. But that’s probably I bad idea, which is why I went ahead and created a new user account for Diaspora purposes.

With the database information all properly configured, it’s time to create the databases and tables. Luckily Diaspora automates this, and initializes the databases with the following code:

            Bundle exec rake db:create
            Bundle exec rake db:migrate

Of course, this is all works theoretically and there must not be many people struggling with this step, otherwise there would be some sort of warning. Despite that, this is the first instance of something going wrong.

Diaspora uses three databases, one for each stage of development. For whatever reason, the diaspora_production table was never created. I didn’t discover this until much later, as prior to my launching my pod into the internet, Diaspora used the first two databases.

The fix was simple enough; I simply copied diaspora_test and named the copy diaspora_production. Overall, this was the easiest obstacle to overcome.

Running cha0sPod (First Attempt)

Now, prior to deciding to run it on my Apache server, I attempted to run the server using the default configuration using thin. To do this, run the code:

            ./script/server

while I was able to access my local instance, I was unable to access it neither through the local area network nor over the internet. Eventually I figured out that it was because I wasn’t running it as root [2]. The command to get it running is thus:

            sudo ./script/server

And it appeared to work. At least, the command line showed no errors. However, accessing through the LAN and WAN resulted in a blank page being rendered client-side, and an error I couldn’t really find much documentation on. In search of a solution, I ventured beyond the basic setup page, and found one detailing how a Diaspora instance can be run through Apache[3]. Since I already had a server set up, I decided to try this option out.

Attaching Pod to Apache

As I already have an Apache server set up, the first step to attaching my Diaspora instance to my Apache server is to install the passenger module. The passenger module allows Apache to serve Ruby on Rails applications, such as Diaspora. The code to install passenger is as follows: gem install passenger

passenger-install-apache2-module

The guide says to load the module into Apache Config, but it did this automatically for me, so I just skipped that step.

All that’s left to do is create a new virtual host for the Diaspora instance, which is fairly simple. I simply used the default Apache virtual host file and changed it to reflect this:

            <VirtualHost *:80>
            ServerAdmin webmaster@localhost
            DocumentRoot "/var/diaspora/public"
            <Directory "/var/diaspora/public">
            Allow from all
            AllowOverride None
            Options -MultiViews 
            </Directory>

And then ran the following code:

            sudo a2dissite 000-default
            sudo a2ensite default
            sudo /etc/init.d/apache2 reload

To activate my Diaspora server. This is of course when the fact that diaspora_production didn’t actually exist came to light, but the problem was solved easily using the method described earlier. And thus, cha0sPod was online.

Managing The Pod

Using Diaspora As A Client

Conclusion

Summarize the report, point to future work.

References

Give references in proper form (not just URLs if possible, give dates of access).