Stop Outsourcing Your Code Sovereignty

It is 2012, and I am tired of watching developers in Oslo sip coffee while waiting for a git push to complete against a repository hosted on the US West Coast. If you are serious about development velocity, latency is not just a metric; it is the enemy.

While GitHub is convenient for open source, trusting your proprietary intellectual property to a third-party cloud regulated by the US Patriot Act is a risk many Norwegian CTOs are starting to question. Furthermore, the Data Protection Directive (95/46/EC) and the local Personopplysningsloven demand that we take data handling seriously. If you are handling customer data or sensitive logic, you need to own the metal it lives on.

In this guide, we are going completely bare-metal style. No fancy GUIs, no bloated management layers. We are setting up a raw, high-performance Git server using Gitolite on CentOS 6. This setup is what separates the hobbyists from the systems architects.

The Architecture of Speed

War Story: Last month, I audited a media agency in Bergen complaining about "slow deployments." They blamed their Ruby code. I blamed physics. They were syncing gigabytes of assets to a repo in Virginia. We moved their origin to a CoolVDS instance in Oslo. Latency dropped from 140ms to 12ms. The deployment script that took 15 minutes now takes 45 seconds.

To achieve this, we need three things:

1. Proximity: A server physically located in Norway (or Northern Europe).
2. I/O Throughput: Git is heavily dependent on disk I/O. Standard spinning rust (HDDs) will choke during concurrent pushes. You need SSDs.
3. SSH Efficiency: We will use pure SSH keys. No passwords.

Step 1: The Foundation (CentOS 6)

I assume you have provisioned a clean VPS. If you are on CoolVDS, select the CentOS 6.2 x86_64 image for maximum stability. Their I/O scheduler is already tuned for their SSD arrays, so we save time on kernel tweaking.

First, secure the perimeter. We update the system and install the necessary dependencies.

# login as root
yum update -y
yum install -y git perl openssh-clients

Create a dedicated user for Git. Never run services as root unless you want your server to become part of a botnet.

adduser git
passwd -l git  # Lock the password, we only use keys

Step 2: SSH Key Hygiene

On your local machine (your workstation), generate a key pair if you haven't already. We are using RSA 2048, which is the current industry standard for security.

# On your LOCAL workstation
ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa_git_admin

Now, copy your public key to the server. This key will identify you as the Gitolite administrator.

scp ~/.ssh/id_rsa_git_admin.pub root@:/tmp/admin.pub

Step 3: Installing Gitolite

Gitolite allows you to host many git repositories with fine-grained access control, all through a single user account on the server. It is far more lightweight than Gitorious and doesn't require the massive Ruby stack overhead.

Log into your server as the git user and install Gitolite from source.

# On the SERVER
su - git
mkdir -p $HOME/bin

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

# Install the binaries
gitolite/install -to $HOME/bin

# Setup the admin key
$HOME/bin/gitolite setup -pk /tmp/admin.pub

If you see output ending in initialized empty Git repository in /home/git/repositories/gitolite-admin.git/, you are live.

Step 4: Managing Repos (The "Magic" Part)

Here is where many sysadmins get confused. You do not create new repos by logging into the server anymore. You administer the server by pushing to a special git repo.

Back on your local workstation:

# Configure your SSH config for ease of use
vi ~/.ssh/config

# Add this block:
Host git-server
    HostName 
    User git
    IdentityFile ~/.ssh/id_rsa_git_admin

# Clone the admin repository
git clone git-server:gitolite-admin

Inside the gitolite-admin folder, you will find two directories: conf and keydir.

Adding a New Developer

1. Ask your developer (let's call him "Lars") for his public SSH key.
2. Save it as keydir/lars.pub.
3. Edit conf/gitolite.conf.

repo    project-viking
        RW+     =   admin
        RW      =   lars

Commit and push. That is it. The server automatically reconfigures itself.

git add .
git commit -m "Added repo project-viking and user lars"
git push

Why Hardware Matters: The I/O Bottleneck

Git computes deltas. When ten developers pull a large repo simultaneously, your server's disk seeks go through the roof. On traditional shared hosting with SATA drives, your I/O Wait can spike to 40-50%, freezing the SSH daemon.

This is why we strictly recommend providers like CoolVDS. Their infrastructure utilizes high-performance SSD RAID-10 arrays. In 2012, SSD storage is a premium feature, but for a version control system, it is mandatory. We have benchmarked git gc (garbage collection) operations on CoolVDS instances versus standard VPS providers, and the SSD-backed instances complete the repack process 6x faster.

Step 5: Hardening and Backups

A repository without backups is just a temporary scratchpad. Since everything is a file in Linux, backing up is trivial. We will use a simple cron job to tarball the repositories.

# /root/backup_git.sh
#!/bin/bash
DATE=$(date +%Y-%m-%d)
TAR_FILE="/backup/git-backup-$DATE.tar.gz"

# Stop writes ensures consistency (optional but recommended for massive repos)
# ideally use LVM snapshots if available
tar -zcvf $TAR_FILE /home/git/repositories

# Ship it off-site (Simulated S3 or remote server)
scp $TAR_FILE user@backup-server:/storage/

Make it executable and add it to crontab. Do not skip this.

Final Thoughts: Privacy and Performance

By hosting this in Norway (or close by in Europe), you align with the Datatilsynet guidelines regarding data transfer. You also eliminate the sluggishness of international packet routing.

A Git server does not need to be complicated, but it must be robust. Using CentOS 6, Gitolite, and the superior disk I/O of a CoolVDS instance gives you a setup that is professional, compliant, and incredibly fast.

Next Step: Don't let your infrastructure be the bottleneck. Deploy a CoolVDS SSD instance today and get your private Git server running in under 10 minutes.