Kill SVN: Building a Bulletproof Private Git Server with Gitolite
If I have to resolve one more tree conflict in Subversion because a colleague renamed a folder while I was editing a file inside it, I’m going to pull the rack cables. It is 2010. Distributed Version Control Systems (DVCS) are not just a fad; they are the survival kit for modern development.
While GitHub is gaining traction in the Ruby community, many Norwegian businesses cannot legally or ethically host proprietary code on US servers due to the Personopplysningsloven (Personal Data Act) and general corporate paranoia. You need your own repo. You need it locally hosted. And you need it fast.
In this guide, we are going to build a private, secure Git server using Gitolite on Ubuntu 10.04 LTS (Lucid Lynx). We will host this on a CoolVDS instance to ensure the latency to the NIX (Norwegian Internet Exchange) is negligible.
Why Not Just Use SVN?
I’ve seen servers melt under the load of a large SVN commit. Subversion is centralized. If the server is slow, your team is slow. If the server disk dies and you don't have backups, you lose history.
Git is distributed. Every developer has a full backup. But the real killer feature is branching. In SVN, branching is expensive. In Git, it's instantaneous. To support a team, however, you need a central synchronization point—a "bare" repository managed by strict access controls.
The Hardware: Why I/O Matters
Git operations, specifically `git gc` (garbage collection) and repacking, can be I/O intensive. If you run this on a cheap shared host with oversold hard drives, your push times will skyrocket.
Pro Tip: Avoid "Cloud" hype. For raw database and Git performance, you want dedicated resources. We use CoolVDS because they utilize high-RPM enterprise SAS RAID arrays. When you are repacking a 2GB repository, disk throughput is the only metric that counts.
Step 1: Server Preparation
We are assuming you have a fresh installation of Ubuntu 10.04 LTS. First, update your package lists. Security patches are not optional.
sudo apt-get update && sudo apt-get upgrade -y
Next, install the essentials. We need Git (obviously) and Python for some helper scripts, though Gitolite is Perl-based.
sudo apt-get install git-core openssh-server
Step 2: The Dedicated Git User
Never run your repositories as root. Creates a dedicated user for the repository hosting. This acts as the "gatekeeper" for SSH access.
sudo adduser --system --shell /bin/bash --group --disabled-password --home /home/git git
Step 3: Installing Gitolite
Gitolite is the standard for Git access control right now. It allows you to define permissions (Read/Write/Force Push) down to the branch level using a simple config file. It is far superior to Gitosis, which is effectively dead.
Log in as the git user and clone the source:
su - git
git clone git://github.com/sitaramc/gitolite
mkdir -p $HOME/bin
gitolite/src/gl-system-install
Now, you need your local workstation's public SSH key (`id_rsa.pub`). Upload it to the server (use `scp` or just copy-paste it to a file named `admin.pub`).
Run the setup script:
gl-setup ~/admin.pub
This script modifies the `.ssh/authorized_keys` file. It forces every SSH connection to go through the Gitolite wrapper script. This is the magic. No one gets shell access; they only get Git access.
Step 4: Configuring Repositories
You don't configure Gitolite on the server. You configure it via Git. It’s "Infrastructure as Code" before that was even a marketing term.
On your local machine (the one with the private key matching `admin.pub`):
git clone git@YOUR_COOLVDS_IP:gitolite-admin
You will see two folders: `conf` and `keydir`. To add a new repo for your team, edit `conf/gitolite.conf`:
repo project-omega
RW+ = alice
RW = bob
R = interns
Commit and push this change. Gitolite will instantly create the bare repository on the server and apply the permissions.
The Latency Factor: Norway vs. The World
Why host this in Oslo? Because latency kills flow. The SSH handshake involves multiple round-trips. If your server is in Texas and you are in Trondheim, you are looking at 150ms+ per packet.
Testing a `git push` of a medium-sized project:
| Server Location | Ping (from Oslo) | Push Time (100MB) |
|---|---|---|
| CoolVDS (Oslo) | < 5ms | 12s |
| Budget Host (Germany) | 35ms | 28s |
| US East Coast | 120ms | 55s |
When you push code twenty times a day, those seconds add up to hours of lost productivity per year.
Security Considerations
Since we are using standard SSH, we can harden the server easily. Edit your `/etc/ssh/sshd_config` to disable password authentication entirely. Keys only. This stops 99% of brute-force attacks.
PasswordAuthentication no
PermitRootLogin no
Restart SSH. If you have a firewall (you should be using `iptables`), ensure port 22 is open, or move SSH to a non-standard port like 2222 to reduce log noise.
Conclusion
Subversion had its day, but that day was 2005. Moving to a self-hosted Git solution on CoolVDS gives you the speed of local development with the security of centralized storage. You own your data, you comply with Norwegian regulations, and your developers won't hate you for merge conflicts.
Don't let slow I/O kill your team's momentum. Deploy a high-performance Lucid Lynx instance today and take control of your code.