Console Login

Absolute Control: Deploying a Private Git Server with Gitolite on Ubuntu 12.04

Absolute Control: Deploying a Private Git Server with Gitolite on Ubuntu 12.04

Let’s be honest: relying on GitHub or Bitbucket for your company's core intellectual property is a gamble. Sure, it’s convenient. But when US-EAST-1 has a hiccup, or when you read the fine print about data sovereignty under the US Patriot Act, the convenience starts to look like a liability. For Norwegian development teams, the latency to San Francisco is a productivity killer. When you type git push, you shouldn't have time to grab coffee.

I have seen development teams grind to a halt because their "cloud" provider throttled connection speeds during peak US hours. That is unacceptable. If you are serious about code, you host it yourself. You keep it on local soil, protected by Norwegian law (Personopplysningsloven), and you run it on metal you control.

In this guide, we are going to build a bulletproof, private Git server using Gitolite on Ubuntu 12.04 LTS (Precise Pangolin). We will focus on security, SSH key management, and optimizing the file system for the heavy I/O operations Git demands.

The Hardware Reality: Why Virtualization Tech Matters

Before we touch the terminal, we need to talk about the underlying infrastructure. Git is brutal on file I/O. Every status check, every commit, and every garbage collection routine hammers the disk with thousands of small file operations.

Many budget VPS providers in Europe try to sell you OpenVZ containers. Do not use them for Git hosting. OpenVZ shares the kernel and file descriptors too aggressively. Under high load, you will hit "resource temporarily unavailable" errors during a large git clone operation because of noisy neighbors.

Pro Tip: Always insist on KVM (Kernel-based Virtual Machine) virtualization. You need a dedicated kernel and guaranteed RAM. This is why I default to CoolVDS for these setups—they use strict KVM isolation, meaning your memory pages aren't being swapped out by someone else's PHP script.

Step 1: Server Preparation & Security

We assume you have a fresh installation of Ubuntu 12.04 LTS. First, we secure the perimeter. We want only SSH traffic. Latency to the Norwegian Internet Exchange (NIX) is low, so we want to keep the handshake fast but secure.

# Update the repositories sudo apt-get update && sudo apt-get upgrade -y # Install essential tools sudo apt-get install git-core openssh-server vim

Create a dedicated user for Git. This isolates the repositories from the rest of the system.

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

Step 2: SSH Key Management

Gitolite uses a single system user (git) but differentiates developers via their SSH keys. This is far superior to creating Unix users for every developer. On your local workstation, generate your admin key:

# On your local machine (not the server) ssh-keygen -t rsa -b 2048 -f ~/.ssh/git_admin

Copy the public key to your new server. Replace 10.0.0.1 with your CoolVDS IP address:

scp ~/.ssh/git_admin.pub root@10.0.0.1:/tmp/git_admin.pub

Step 3: Installing and Configuring Gitolite

Gitolite is the industry standard for granular access control. It allows you to define who can read or write to specific branches and tags. Log into your server as root and switch to the git user.

# Switch to the git user su - git # Create a bin directory for local binaries mkdir -p ~/bin # Clone the Gitolite source (Stable v3) git clone git://github.com/sitaramc/gitolite # Install Gitolite ./gitolite/install -to ~/bin

Now, we use the public key we uploaded earlier to initialize the setup.

~/bin/gitolite setup -pk /tmp/git_admin.pub

If successful, you will see output confirming the initialization of the gitolite-admin repository. This repository is special: you manage your server by pushing changes to this repo.

Step 4: Performance Tuning for SSDs

Git performance is I/O bound. While CoolVDS instances come with high-performance Enterprise SSD storage, the default Linux filesystem settings in 12.04 can be conservative.

We need to modify how the file system handles access times. By default, Linux writes an access time metadata update every time you read a file. For a Git repo with 50,000 files, a simple grep can cause 50,000 write operations. That kills performance.

Edit your /etc/fstab to include the noatime flag:

# Open fstab sudo vim /etc/fstab # Modify the line for / (or your data partition) to look like this: UUID=xxxx-xxxx-xxxx / ext4 errors=remount-ro,noatime,barrier=0 0 1

Remount the filesystem:

sudo mount -o remount /

Additionally, we should tune the Git garbage collection on the server side to pack objects more aggressively, saving disk space and speeding up clones.

# Inside /home/git/.gitconfig [gc] auto = 256 aggressiveWindow = 250 [core] packedGitWindowSize = 64m packedGitLimit = 256m

Step 5: Managing Your Repositories

Back on your local workstation, you can now clone the admin repository. This is how you add new projects and users. No need to SSH into the server anymore.

# Configure your local SSH config to use the admin key
Host git-server
    HostName 10.0.0.1
    User git
    IdentityFile ~/.ssh/git_admin

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

Inside the gitolite-admin folder, you will find conf/gitolite.conf. Adding a new repo is as simple as editing this file:

repo    new-project
        RW+     =   alice
        R       =   bob

Commit and push this change, and Gitolite instantly creates the bare repository on the server.

Why Latency and Sovereignty Matter

If your team is based in Oslo or Bergen, hosting on a server in Virginia introduces 100ms+ latency. While that sounds small, it compounds during large rebase operations or CI triggers. By hosting on a CoolVDS instance in a Nordic datacenter, you drop that latency to single digits.

Furthermore, the Data Protection Directive (95/46/EC) and the Norwegian Personopplysningsloven place strict requirements on data handling. While Safe Harbor exists, many CTOs are uncomfortable with the legal ambiguity of US-hosted code. Self-hosting ensures you are the only one with the keys.

Conclusion

You now have a secure, private Git server that rivals any commercial offering in terms of speed and beats them all on privacy. You own the metal, you own the keys, and you own the data.

Don't let slow I/O or noisy neighbors compromise your development workflow. If you need a robust, KVM-based foundation for your infrastructure, deploy a test instance on CoolVDS today. Their SSD-backed storage is exactly what high-churn Git repositories need to stay responsive.