Part #2 of the Data Liberation series

Mozilla, the organisation behind the ubiquitous Firefox web browser, kindly publishes its source code powering a key service which it provides – Firefox Sync.  Because of this, we are able to run our own password sync servers securely and not necessarily be the target of a large-scale data-mining break-in, such as might be performed by a malicious cracker, or the NSA.  Sorry, of course they are the same thing.

Firefox Sync is a neat service which allows you to, quite literally, sync your settings in Firefox across multiple devices.  These settings can include bookmarks, web browsing history, cookies, form-filling data and passwords.  Anyway, I too was keen to run my own password sync server, so I set about doing just that.

I host quite a bit of stuff using Virtualmin, another superbly produced piece of software which facilitates the set-up of multiple domains on a single box. Setting up Firefox Sync on your own server under virtualmin is actually very straightforward.

The main task at hand is to follow the detailed instructions published by Mozilla.

As per the instructions, I had to run the following, in order to install required software:

# apt-get install python-dev mercurial sqlite3 python-virtualenv libssl-dev

In addition, I also needed to install and enable the WSGI Apache module, which wasn’t present on my system (drawing in dependencies as needed):

# apt-get install libapache2-mod-wsgi

I decided to install the Mozilla sync software in the home directory of my newly created domain, which in Virtualmin is either “/home/domain” or “/home/domain/domains/subdomain”, depending on whether you have created a subdomain for this specific purpose or not.  In the subdomain situation, the folder path would end up being: /home/domain/domains/subdomain/server-full.

Once installed, I inspected the Apache config file. A key change I had to make was to the WSGI configuration within this file. On my Debian box, the Apache config files are located in the standard place: /etc/apache2/sites-available – the same would be true for Ubuntu (on CentOS and other RHEL/Fedora derivatives, you’ll probably find them in /etc/httpd/conf.d/). Once you have created your domain in Virtualmin, your domain’s config file should be within this folder, appropriately named “domain.com.conf”.

In the “domain.com.conf”, there are a few lines to add and one to edit:

Firstly, find the DocumentRoot declaration:

DocumentRoot /home/mydomain/domains/subdomain/public_html

and change it to:
DocumentRoot /home/mydomain/domains/subdomain/server-full

Next, you’ll need to insert the following lines, within the same stanza as DocumentRoot (the best thing is to adjust and paste these lines directly after DocumentRoot:

WSGIProcessGroup sync-http
WSGIDaemonProcess sync-http user=<your-virtualmin-domain's-user> group=<your-virtualmin-domain's-group> processes=2 threads=25
WSGIPassAuthorization On
WSGIScriptAlias / /home/mydomain/domains/subdomain/server-full/sync.wsgi

The above example assumes that you are working within the :80> stanza. If you have enabled SSL on your virtual server, within Virtualmin, then you’ll also have a :443> stanza to add these lines to, with one or two exceptions!

A WSGIDaemonProcess is assigned to each virtual server in Apache. In doing so, it creates a system process which requires a name. According to the WSGI docs, this name must be unique:

“[…] note that the name of the daemon process group must be unique for the whole server. That is, it is not possible to use the same daemon process group name in different virtual hosts. “

When you come to pasting in the additional lines in your :443 stanza, you are dealing with a separate virtual server in Apache.  So, within your Apache config file, be sure to rename your WSGIDaemonProcess process name. E.g.:

WSGIProcessGroup sync-https
WSGIDaemonProcess sync-https user=<your-virtualmin-domain's-user> group=<your-virtualmin-domain's-group> processes=2 threads=25

This configuration should now be valid. You can test this with:

service apache2 reload

This won’t stop the current Apache process, but it will attempt to load the new configuration file. If it fails to load the config, it will tell you without stopping Apache.

Once this works, simply issue:

service apache2 restart

Syncing on mobile

If you intend to use Firefox on Android, or any other mobile Firefox (or clone) that supports the same syncing protocol, there is one caveat.  If you are using an unsigned or self-signed SSL certificate on your sync server, you should visit the site first in your mobile Firefox and add a permanent exception.  Once done, set up firefox sync in the normal way, by typing the characters into your desktop browser’s sync dialog, and the two browsers will shortly be synced up nicely!