Stop Renting Your Code: Building a Fortified Git Server with Gitolite on Debian Squeeze

I still see it. Teams of five or ten developers in Oslo, pushing gigabytes of code to a centralized Subversion server hosted in a generic data center in Texas. They wonder why `svn commit` takes long enough to brew a coffee. They wonder why a single network hiccup halts the entire office.

If you are serious about development in 2012, you should have moved to Git yesterday. But moving to Git isn't just about the software; it's about owning your infrastructure. While GitHub is excellent for open source, trusting your proprietary codebase to a third-party cloud often means accepting high latency and the looming shadow of the US Patriot Act.

Today, we are going to build a private, high-performance Git server right here in Norway. We will use Gitolite for granular access control, Debian 6 (Squeeze) for rock-solid stability, and a CoolVDS KVM instance because I refuse to deal with the noisy neighbor issues plaguing OpenVZ providers.

The Latency Killer: Why Geography Matters

Before we touch the terminal, let's talk physics. The round-trip time (RTT) from Oslo to Ashburn, Virginia, is roughly 100-120ms. The RTT from Oslo to a CoolVDS server in our local data center is under 5ms. When your team performs hundreds of `git fetch` and `git push` operations a day, that difference compounds. It changes the workflow from "wait and see" to "instant."

Pro Tip: Don't underestimate disk I/O. Git is essentially a filesystem map. On traditional 7.2k RPM SATA drives, large repos with thousands of objects will crawl. We strictly use Solid State Drives (SSD) or high-speed SAS RAID-10 arrays for our git nodes to prevent I/O wait from becoming a bottleneck.

Step 1: The Foundation (Server Prep)

I am assuming you have a fresh CoolVDS instance running Debian 6. Why Debian? Because Ubuntu 12.04 is still brand new (beta), and in production, I prefer boring stability over shiny new toys.

First, log in and update your system. We never deploy on stale packages.

root@git-node:~# apt-get update && apt-get upgrade
root@git-node:~# apt-get install git-core openssh-server perl

Next, we need a dedicated user for Git. Do not run this as root. If you run git as root, you deserve the security breach that is coming for you.

root@git-node:~# adduser --system --shell /bin/bash --group --disabled-password --home /home/git git

Step 2: The Administrator's Key

Gitolite uses SSH keys for authentication. It does not use passwords. This is superior security practice. On your local workstation (not the server), generate a key pair if you haven't already:

local-user@laptop:~$ ssh-keygen -t rsa -b 2048 -f ~/.ssh/git_admin
local-user@laptop:~$ scp ~/.ssh/git_admin.pub root@your-coolvds-ip:/tmp/git_admin.pub

Step 3: Installing and Configuring Gitolite

Gitolite allows you to manage multiple repositories and users over a single SSH account. It parses the SSH command to restrict access. It's the engine behind many corporate git forges.

Back on your CoolVDS server, switch to the git user and install Gitolite. We'll clone the source directly to ensure we have the latest stable release.

root@git-node:~# su - git
git@git-node:~$ git clone git://github.com/sitaramc/gitolite
git@git-node:~$ mkdir -p $HOME/bin
git@git-node:~$ ./gitolite/install -to $HOME/bin

Now, we initialize Gitolite with the public key we uploaded earlier. This sets you as the administrator.

git@git-node:~$ $HOME/bin/gitolite setup -pk /tmp/git_admin.pub

# Output should look like:
# initialized empty Git repository in /home/git/repositories/gitolite-admin.git/
# initialized empty Git repository in /home/git/repositories/testing.git/

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

Here is where the magic happens. You don't manage the server by logging into it anymore. You manage it by pushing to a special git repo called `gitolite-admin`.

On your local machine, configure your SSH config to use the specific key:

# File: ~/.ssh/config
Host git-server
    HostName your-coolvds-ip
    User git
    IdentityFile ~/.ssh/git_admin

Now, clone the admin repository:

local-user@laptop:~$ git clone git-server:gitolite-admin
local-user@laptop:~$ cd gitolite-admin
local-user@laptop:~/gitolite-admin$ ls -F
conf/  keydir/

• keydir/: Drop your team members' public keys here (e.g., `bjorn.pub`, `astrid.pub`).
• conf/gitolite.conf: This is where you define permissions.

Let's add a new project and give access to Bjorn.

# Edit conf/gitolite.conf

repo gitolite-admin
    RW+     =   admin

repo nordic-project
    RW+     =   admin
    RW      =   bjorn
    R       =   astrid

Commit and push these changes. Gitolite hooks will instantly create the bare repository on the server and update the `~/.ssh/authorized_keys` file automatically.

local-user@laptop:~/gitolite-admin$ git add .
local-user@laptop:~/gitolite-admin$ git commit -m "Add nordic-project and users"
local-user@laptop:~/gitolite-admin$ git push origin master

Security and Data Integrity in Norway

Hosting this on CoolVDS isn't just about raw IOPS or the Intel Xeon processors we use. It's about data sovereignty. Under the Norwegian Personal Data Act (Personopplysningsloven), you are responsible for how you handle data.

When you host on a cheap US VPS, you are subject to US jurisdiction. By keeping your codebase on a server physically located in Oslo, you satisfy stricter internal compliance requirements often found in the Nordic banking and oil sectors. Plus, Datatilsynet looks much kindlier on data that stays within the EEA.

The KVM Advantage

Why do I insist on KVM (Kernel-based Virtual Machine) for Git servers? Git is resource-intensive during garbage collection (`git gc`) and repacking. On OpenVZ platforms, providers often oversell RAM. If your neighbor launches a heavy Java process, your `git push` might run out of memory and fail.

CoolVDS uses KVM virtualization, which guarantees your RAM is yours. The kernel is isolated. If you have 4GB of RAM allocated, you get 4GB of RAM. For a critical collaboration tool, anything less is negligence.

Final Configuration: SSH Hardening

Before we finish, disable password authentication entirely on the server. You are a systems administrator; act like one.

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
AllowUsers git

Restart SSH (`service ssh restart`). Now, the only way in is via your cryptographic keys.

Conclusion

You now have a Git server that is faster than GitHub for your local team, fully private, and compliant with Norwegian data standards. It costs a fraction of a managed enterprise license and gives you total control.

Don't let slow I/O or network latency kill your team's velocity. Deploy a high-performance Debian instance on CoolVDS today. With our SSD storage options and uncrowded KVM nodes, your commits will land before you even lift your finger off the Enter key.