Building a Fortified Private Git Server with Gitolite on Ubuntu 12.04 LTS

Let’s be honest: Subversion (SVN) is dying, and CVS has been rotting for a decade. If your development team hasn't migrated to Git yet, you are bleeding productivity. But here is the dilemma facing every CTO and Lead Systems Architect in Norway right now: Do you host your intellectual property on GitHub's public cloud in the US, subject to the Patriot Act, or do you take control of your data?

For those of us dealing with strict client NDAs or operating under the scrutiny of Datatilsynet (The Norwegian Data Inspectorate), outsourcing our code repository isn't just a risk—it's often a compliance violation. Furthermore, if your team is sitting in Oslo or Bergen, why route your git push traffic through a data center in Virginia? The latency kills the workflow.

Today, I’m going to walk you through deploying a production-grade, self-hosted Git server using Gitolite on Ubuntu 12.04 LTS (Precise Pangolin). We will focus on security, access control, and raw disk performance.

The Architecture: Why KVM and SSDs Matter

Git is not just a version control system; it is a content-addressable filesystem. It is I/O heavy. When you run a git gc (garbage collection) or clone a massive repository, your server is thrashing the disk, calculating SHA-1 hashes and compressing objects.

Most budget VPS providers oversell their storage using standard spinning HDDs (SAS/SATA) in crowded RAID arrays. This leads to "I/O Wait"—the silent killer of server performance. In a multi-tenant environment, you cannot afford to wait for a neighbor's PHP script to finish writing logs before your commit goes through.

Pro Tip: Always insist on KVM (Kernel-based Virtual Machine) virtualization. Unlike OpenVZ, KVM provides a dedicated kernel and strict resource isolation. At CoolVDS, we pair KVM with Enterprise SSD storage. The random Read/Write speeds on SSDs are essential for Git's object database. Do not settle for spinning rust in 2012.

Prerequisites

• A fresh CoolVDS KVM instance running Ubuntu 12.04 LTS.
• Root access via SSH.
• A local workstation with Git installed (1.7.x recommended).

Step 1: Secure the Foundation

First, we secure the server. We never run services as root, and we definitely don't allow password authentication. If you are still using passwords for SSH in 2012, you are asking to be part of a botnet.

Update your system and install the essentials:

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

Now, create a dedicated git user. This user will manage the repositories. No developer will ever get a shell account; Gitolite handles the authentication logic via Perl scripts triggered by SSH.

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

Step 2: SSH Key-Based Administration

Gitolite uses a unique bootstrapping method. You use your local workstation's public SSH key to initialize the server. On your local machine (not the server), generate a key pair if you haven't already:

local-user@workstation:~$ ssh-keygen -t rsa -b 2048 -f ~/.ssh/git_admin

Upload the public key to your new CoolVDS server:

local-user@workstation:~$ scp ~/.ssh/git_admin.pub root@192.0.2.10:/tmp/git_admin.pub

Step 3: Installing and Configuring Gitolite

Back on the server, switch to the git user and install Gitolite. We are compiling from source to ensure we have the latest v3 features, which offer significantly better access control granularity than the older v2 packages in the Ubuntu repo.

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

# Setup the admin repo with the key we uploaded
git@git-node01:~$ ~/bin/gitolite setup -pk /tmp/git_admin.pub

If you see output referencing authorized_keys being initialized, you are in business. Gitolite has now hijacked the SSH execution for the git user. When a user connects, Gitolite parses the command, checks the config, and either allows or denies the read/write operation.

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

Here is the beauty of this setup: You never log into the server to create repos or add users again. You administer the server using Git.

On your local workstation, add the server to your SSH config to simplify commands. Edit ~/.ssh/config:

Host git-server
    HostName 192.0.2.10
    User git
    IdentityFile ~/.ssh/git_admin

Now, clone the admin repository:

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

To add a new developer, say "Lars", you simply drop his public key (lars.pub) into the keydir/ directory. To create a new repository for a project, you edit conf/gitolite.conf.

Example gitolite.conf:

repo gitolite-admin
    RW+     =   admin-user

repo project-viking
    RW+     =   admin-user
    RW      =   lars
    R       =   deploy-bot

Commit and push these changes. Gitolite's hooks on the server will automatically create the project-viking bare repository and update the ~/.ssh/authorized_keys file to allow Lars access.

local-user@workstation:~/gitolite-admin$ git add .
local-user@workstation:~/gitolite-admin$ git commit -m "Added Lars to Project Viking"
local-user@workstation:~/gitolite-admin$ git push origin master

Step 5: Hardening the Network

Since this server houses your company's intellectual property, network security is paramount. Use iptables to whitelist only your office static IP and the VPN endpoints. Do not leave port 22 open to the world.

# Flush existing rules
iptables -F

# Allow established connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH only from specific Norwegian Office IP
iptables -A INPUT -p tcp --dport 22 -s 84.211.x.x -j ACCEPT

# Drop everything else
iptables -P INPUT DROP

Ensure you make these rules persistent using iptables-save, or you will lock yourself out on the next reboot.

Why Hosting in Norway Matters

Beyond the technical setup, physical location dictates performance. If your team is in Oslo, a round-trip to a server in Frankfurt adds 20-30ms. A round-trip to the US East Coast adds 90-110ms. For interactive SSH operations, that lag is noticeable. Hosting locally on CoolVDS means ping times below 10ms.

Furthermore, adhering to the Personal Data Act (Personopplysningsloven) is far simpler when your data never crosses national borders. While the "Cloud" is a trendy buzzword, data sovereignty is a legal reality we must respect.

Conclusion

You now have a secure, private Git server that costs a fraction of GitHub Enterprise and offers superior performance. By leveraging the low latency of VPS Norway infrastructure and the raw I/O power of SSDs, you ensure your developers spend time coding, not waiting on push/pull operations.

Ready to reclaim your data? Don't let slow I/O kill your team's velocity. Deploy a high-performance SSD instance on CoolVDS today and experience the difference of local, optimized hosting.