DistOS-2011W Diaspora
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 covers my experience in setting up a Diaspora pod, Section 4 includes additional details in regards to the management of the cha0sPod, Section 5 covers my experience in using Diaspora as a client, Section 6 contains my conclusion, and Section 7 includes all references made in the document.
What Is Diaspora?
Diaspora: Distributed Social Networking
Diaspora is designed to decentralize social networks, so that privacy can more easily be managed by the individual user. With a centralized social network, all information, messages, and pictures posted are effectively owned by the corporation hosting the network. The idea of sacrificing all of your privacy in exchange for a service is exactly what Diaspora hopes to prevent.
How it accomplishes this is the utilization of user-owned servers, called "pods". Pods are used to host content, such as status updates and pictures, and communicate with other pods so that the content is available across the network. Users may either create a pod, join an associate's, or sign up in a pod open to the public. In any case, Diaspora prioritizes user privacy using a number of methods, which are described below.
Aspects
Aspects are used to maintain multiple identities in the social network. By default, every user starts with the "Home", "Family", and "Work" aspects. When the user posts, they can specify which aspects to post to. For example, if the user posts to the home aspect, only friends associated with the home aspect will see the post. When a friend is added, the user specifies which aspects the friend should be associated with.
New aspects can be created at any time, so that users can customize the privacy of their content on a per-update basis. This means that a user may have "Employees" and "Supervisors" aspects, so that messages can be sent to a manager's employees based on the level of privacy the message needs.
Content Ownership
Users maintain ownership of all content posted, including pictures. This means that the user has control over how photos are distributed. Again, this is done through the aspect system, so that photos are only seen by the people you want them to.
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).