Escaping SVN Hell: Building a Private Git Server with Gitolite on Ubuntu 10.04

It is 2010. If you are still dealing with broken Subversion merges or waiting for CVS to commit a simple change over a slow connection, you are doing it wrong. Linus Torvalds gave us Git five years ago, yet too many teams in Oslo and Bergen are still shackled to centralized version control systems that introduce a single point of failure.

Worse, some of you are hosting proprietary code on public servers across the Atlantic. Under the Personal Data Act (Personopplysningsloven) here in Norway, and with the watchful eye of Datatilsynet, you need to know exactly where your data lives. Relying on a third-party service hosted in a US data center is a risk your CTO shouldn't be taking.

The solution is simple: Host it yourself.

In this guide, we are going to build a private, secure Git server using Gitolite on Ubuntu 10.04 LTS (Lucid Lynx). We will host this on a KVM-based Virtual Private Server (VPS) to ensure memory isolation and raw disk performance.

Why Gitolite?

You could just use bare SSH accounts, but that becomes a nightmare when you have 20 developers and need fine-grained access control. You don't want the intern rewriting the master branch history.

Gitolite acts as an access control layer on top of Git. It allows you to:

• Restrict access by branch or tag.
• Manage permissions using a simple configuration file.
• Use a single system user (git) while distinguishing between many actual developers via SSH keys.

The Infrastructure Prerequisite

Don't run this on shared hosting. You need a VPS. Specifically, you want KVM virtualization. While OpenVZ is popular for cheap hosting, it shares the kernel with neighbors. For a critical code repository, you want the isolation of KVM (Kernel-based Virtual Machine), which has been stable in the Linux kernel for a few years now.

Pro Tip: Network latency kills developer flow. Every time you git push or git pull, the handshake matters. Hosting your repo in a German or Norwegian datacenter ensures you are hitting the NIX (Norwegian Internet Exchange) with sub-20ms latency. CoolVDS instances in Europe are optimized exactly for this route.

Step 1: Initial Server Setup

We assume you have a fresh Ubuntu 10.04 LTS instance. Log in as root.

First, update your package lists. Never skip this.

apt-get update
apt-get upgrade -y

Now, install the Git core packages. We definitely need git-core. Note that in older distributions, the package is split.

apt-get install git-core openssh-server build-essential

Step 2: Create the Git User

Security 101: Never run services as root. We will create a dedicated user named git.

adduser --system --shell /bin/bash --group --disabled-password --home /home/git git

Step 3: Installing Gitolite

Gitolite isn't in the standard Ubuntu 10.04 repositories yet (or the version is archaic), so we will install it from the source. This is the battle-hardened way to ensure you have Sitaram Chamarty's latest fixes.

Login as the git user:

su - git

Clone the Gitolite source code:

git clone git://github.com/sitaramc/gitolite

Now, we create a bin directory and run the install script.

mkdir -p $HOME/bin
gitolite/src/gl-system-install

(Note: Depending on your exact Gitolite version, the install script location might vary slightly, but src/gl-system-install is standard for current builds).

Step 4: The Administrator's Key

This is where it gets clever. Gitolite uses a special Git repository to manage its own configuration. To administer the server, you don't SSH in and edit files manually; you git push changes to the configuration repo.

You need a public SSH key from your local workstation (your laptop, not the server). If you don't have one generated on your machine yet:

# Run this on your LOCAL machine, not the server
ssh-keygen -t rsa

Upload your id_rsa.pub to the VPS (let's say to /tmp/admin.pub). Then, back on the server as the git user, run the setup:

# On the server as 'git' user
~/bin/gl-setup /tmp/admin.pub

This script sets up the authorized_keys file and creates the internal repositories.

Step 5: Managing Your Repositories

Now, log out of the server. You are done there. Everything else happens from your workstation.

Clone the admin repository:

git clone git@your-coolvds-ip:gitolite-admin
cd gitolite-admin

You will see two directories: conf/ and keydir/.

Adding a New Developer

1. Get the developer's public key (e.g., john.pub).
2. Drop it into keydir/john.pub.
3. Commit and push.

Defining Access Rules

Edit conf/gitolite.conf. Let's say we have a project called "norway-logistics".

repo    norway-logistics
        RW+     =   admin
        RW      =   john
        R       =   audit-bot

This configuration gives the admin full read/write/rewind access, John gets read/write access (but cannot rewind/force push), and the audit-bot can only read.

Commit and push these changes:

git add .
git commit -m "Added John to norway-logistics project"
git push origin master

Gitolite immediately updates the server hooks. John can now clone the repo. It is seamless.

Hardware Matters: Why RAID-10?

Git is incredibly efficient, but it is I/O intensive when doing garbage collection (git gc) or repacking large repositories. If you run this on a cheap VPS with a single SATA drive, your commits will hang.

At CoolVDS, we configure our storage arrays with high-performance Enterprise SSD caching or 15k RPM SAS drives in RAID-10. This ensures that even if you are pushing a massive initial import of a legacy SVN repo, the disk queue never blocks. Low latency combined with high IOPS means your developers stay in the zone.

Summary

Centralized version control is a relic. By moving to a distributed Git workflow hosted on your own private server, you gain:

1. Compliance: You control the data location (essential for Norwegian legal standards).
2. Speed: Local routing to Oslo/Europe means faster fetches.
3. Reliability: No dependency on GitHub or Bitbucket downtime.

Don't let slow I/O or privacy concerns stall your development team. Deploy a test instance on CoolVDS in 55 seconds and feel the difference a real KVM slice makes.