Forging a Private Git Bunker: Secure Collaboration with Gitolite on Linux

Let's be honest: Subversion (SVN) is on life support. If your team is still locking files and dreading merge conflicts, you are bleeding productivity. The distributed nature of Git is the standard for modern development, but there is a catch. Public hosting platforms like GitHub are excellent for open source, but do you really want your proprietary code sitting on a server in the US, subject to the Patriot Act?

For Norwegian development houses, the answer is usually "nei". Between the Personopplysningsloven (Personal Data Act) and the need for absolute intellectual property control, self-hosting is the only responsible path.

In this guide, we are not just installing Git; we are building a fortress using Gitolite on Ubuntu 10.04 LTS (Lucid Lynx). We will cover why the underlying hardware matters for performance and how to keep your latency to Oslo minimal.

Why Bare SSH Isn't Enough

You could just create a `git` user and throw some SSH keys in `authorized_keys`. That works for a team of two. But when you have a team of ten, plus contractors, and you need to restrict who can push to the `master` branch or who can only read specific repositories, bare SSH fails.

Gitolite sits on top of SSH and acts as a gatekeeper. It parses the incoming command, checks the user's permissions against a config file, and allows or denies the action. It is the same logic used by the big hosting providers, but under your control.

The Hardware Reality: Latency and I/O

Before we touch the terminal, let's talk about the metal. Git operations—specifically `git gc` (garbage collection) and massive rebases—are heavy on disk I/O. If you are hosting this on a cheap, oversold OpenVZ container where you're fighting 500 other neighbors for disk access, your pushes will hang. I've seen deployment pipelines time out simply because the host node's hard drives were thrashing.

Pro Tip: For serious development teams, disk latency is the enemy. While standard SAS drives are common, looking for a provider offering Enterprise SSD storage tiers can reduce `git clone` times on massive repos by over 40%.

At CoolVDS, we prioritize I/O throughput. Our KVM virtualization ensures that your RAM and Disk I/O are truly yours, not shared dynamically. Plus, our servers are peered directly at NIX (Norwegian Internet Exchange). If your team is in Oslo or Bergen, your ping to the repo should be negligible—often under 5ms.

Step-by-Step Deployment

We are using Ubuntu 10.04 LTS for stability. Ensure you have root access.

1. Preparation

First, update your package lists and install the essentials. We need Git and Perl.

root@server:~# apt-get update
root@server:~# apt-get install git-core perl

2. Create the Git User

We need a dedicated user to handle the repositories. Do not use root for this.

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

3. Install Gitolite

Switch to the git user. We will clone the Gitolite source directly (ensure you are using the latest stable branch).

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

4. The Admin Key

You need your local workstation's public key (`id_rsa.pub`) uploaded to the server. Let's assume you scp'd it to `/tmp/admin.pub`. Run the setup script using this key to establish yourself as the administrator.

git@server:~$ $HOME/bin/gitolite-setup -pk /tmp/admin.pub

If successful, Gitolite creates two repositories: `gitolite-admin` and `testing`. You can now delete the upload public key.

Managing Access (The Magic Part)

Here is where Gitolite shines. You don't log into the server to add users. You administer the server via Git. From your local machine:

local$ git clone git@your-coolvds-ip:gitolite-admin.git
local$ cd gitolite-admin

Inside, you will find a `conf/` folder and a `keydir/` folder. To add a new developer, "Ola":

1. Get Ola's public SSH key.
2. Save it as `keydir/ola.pub`.
3. Edit `conf/gitolite.conf`:

repo backend-project
    RW+     =   admin
    RW      =   ola
    R       =   interns

Commit and push these changes. Gitolite's hooks will automatically update the server's `authorized_keys` file. It’s clean, auditable, and version-controlled.

Security & Datatilsynet

Hosting internally satisfies the strict requirements of the Data Protection Directive. You know exactly where the physical drives are located. However, a private server needs protection.

• Disable Password Auth: Edit `/etc/ssh/sshd_config` and set `PasswordAuthentication no`. Only SSH keys should be allowed.
• Firewalling: Use `iptables` to allow port 22 only from known IPs if your team has static addresses.
• Backups: RAID is not a backup. Use a cron job to `rsync` your `/home/git` directory to a remote location nightly.

The Verdict

Moving to Git is non-negotiable in 2011, but handing your source code to a third party isn't mandatory. By setting up Gitolite on a high-performance VPS, you gain granular access control, better performance for large binary assets, and complete legal compliance.

Don't let slow I/O kill your developers' flow state. If you need a robust, low-latency environment to host your code, deploy a CoolVDS instance today. We offer pure KVM virtualization and high-speed storage options that keep your commits flying.