Build a Bulletproof Private Git Server with Gitolite on Ubuntu 10.04

If you are still wrestling with Subversion (SVN) merge conflicts in 2010, you are wasting billable hours. The centralized model is dying. Distributed Version Control Systems (DVCS) are the reality, and Git is the undisputed king. But here is the problem: hosting your proprietary code on public services like GitHub or SourceForge might be fine for open source, but for a Norwegian enterprise dealing with sensitive intellectual property? It is a risk you shouldn't take.

We have seen too many development teams suffer from "SourceForge lag" or downtime. When your repository is hosted halfway across the world, a simple git fetch feels like pulling teeth. Latency matters. Data sovereignty matters.

In this guide, we are going to build a fortress. We will set up a private, high-performance Git server using Gitolite on Ubuntu 10.04 LTS (Lucid Lynx). We are doing this the hard way—the right way—so you have granular access control without the overhead of a heavy GUI.

Why Local Hosting? The Latency & Legal Argument

Why bother managing your own server? Two reasons: Physics and Law.

If your team is in Oslo or Bergen, routing traffic to a US-based server adds 100-150ms of latency per round trip. Git operations, especially cloning large repositories with thousands of small objects, are sensitive to network latency. By hosting on a VPS Norway node, specifically one peering at NIX (Norwegian Internet Exchange), you drop that latency to sub-10ms. The difference in responsiveness is night and day.

Then there is the Personopplysningsloven (Personal Data Act). If your code contains any personal data, keeping it within Norwegian borders under the oversight of Datatilsynet simplifies your compliance headache significantly compared to Safe Harbor frameworks.

The Infrastructure: SSDs are Non-Negotiable

Pro Tip: Git is essentially a filesystem map of small object files. Traditional 7.2k RPM SATA drives will choke on the random I/O required for large rebases.

For this setup, we are using a CoolVDS instance. Why? Because we need raw disk I/O. Git eats IOPS for breakfast. We strictly utilize high-performance SSD storage (Enterprise Flash) rather than spinning rust. If your VPS provider is putting you on a shared SATA RAID array with fifty other tenants, your commits will hang. Don't cheap out on storage.

Prerequisites

• A CoolVDS instance running Ubuntu 10.04 LTS.
• Root access.
• A local workstation with an SSH public key generated.

Step 1: System Prep and User Isolation

First, log into your box. We need to ensure the system is up to date and create a dedicated `git` user. Never run your repositories as root. That is sloppy administration.

# Update the repositories
apt-get update && apt-get upgrade -y

# Install Git core and Perl (required for Gitolite)
apt-get install git-core perl -y

# Create a dedicated git user with no password login
adduser --system --shell /bin/bash --group --disabled-password --home /home/git git

Step 2: Installing Gitolite

Gitolite is currently the most robust layer for managing Git access over SSH. It allows you to define permissions (RW+, R, etc.) on a per-branch, per-tag, and per-user basis using a simple configuration repo.

Login as the `git` user. We will clone the source directly.

# Switch to git user
su - git

# Create bin directory
mkdir -p ~/bin

# Clone Gitolite source
git clone git://github.com/sitaramc/gitolite

# Install it
gitolite/src/gl-system-install
sh -c "PATH=/home/git/bin:$PATH; gl-setup -q /tmp/your_admin_key.pub"

Note: You must upload your workstation's public SSH key (`id_rsa.pub`) to the server first, placing it at `/tmp/your_admin_key.pub`, so Gitolite can initialize the admin repo with your key.

Step 3: SSH Daemon Tuning

A default OpenSSH configuration on Ubuntu 10.04 is not optimized for a high-traffic Git server. Every time you connect, SSH might try to perform a DNS lookup on the client IP, causing a delay. Let's fix that.

Edit /etc/ssh/sshd_config:

# Disable DNS lookups for speed
UseDNS no

# Disable GSSAPI to prevent timeout delays
GSSAPIAuthentication no

Restart the service using Upstart:

service ssh restart

Step 4: Managing Your Repos

Here is the beauty of this setup: You don't manage the server by logging into it anymore. You manage it via Git. Go back to your local workstation.

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

Inside, you will find two folders: `conf` and `keydir`. To add a new developer, drop their public key into `keydir`. To add a new repo, edit `conf/gitolite.conf`:

repo    project-omega
        RW+     =   admin
        RW      =   johndoe
        R       =   deploy-bot

Commit and push. Gitolite's hooks will automatically create the repository on the server.

Performance Benchmark: HDD vs SSD

We ran a `git gc` (garbage collection) on the Linux Kernel repository (approx 800MB) to compare storage backends. The results speak for themselves.

Final Thoughts

In 2010, relying on FTP or SVN is negligence. Setting up your own Git server gives you total control, privacy under Norwegian law, and blazing speed if you choose the right infrastructure. Do not let your infrastructure bottleneck your development cycle.

If you need a server that can handle high-concurrency Git operations without I/O wait, deploy a managed hosting instance on CoolVDS today. Your developers will thank you.