Console Login
Home / Blog / DevOps & Infrastructure / Escaping Subversion Hell: Building a Private Git Server with Gitolite on Linux
DevOps & Infrastructure 10 views

Escaping Subversion Hell: Building a Private Git Server with Gitolite on Linux

@

Stop Trusting Third Parties with Your Source Code: The Case for Self-Hosted Git

If you are still using Subversion (SVN) in 2010, you are bleeding productivity. The centralized model is dead; distributed version control is the reality. But here is the problem: relying on public clouds like GitHub for private repositories gets expensive fast, and frankly, handing your intellectual property over to a US-based entity puts you in a gray area regarding the Patriot Act and corporate espionage.

For Norwegian development teams, the answer isn't a bloated proprietary appliance. It's a lean, hardened Linux VPS running Gitolite. You get granular access control, zero per-user licensing fees, and the peace of mind that your code resides on servers under Norwegian jurisdiction (Personopplysningsloven).

I’ve cleaned up enough messy SVN-to-Git migrations to know that performance depends entirely on your I/O throughput and network latency. Here is how we build a battle-ready Git server that screams.

The Hardware Reality: Latency Kills Collaboration

Before we touch the terminal, let's talk metal. Git is fast, but it generates massive amounts of small file I/O operations during cloning and garbage collection. If you host this on a budget "cloud" slice oversold by 400%, your team will spend half their day waiting for git push to complete.

We see this constantly with developers trying to host repositories in Amsterdam while working from Oslo. The latency adds up. For a seamless experience, you need:

  • Low Latency: Hosting in Norway ensures ping times under 10ms for local teams.
  • Disk I/O: You need RAID-10 SAS or the new Enterprise SSD tiers. Do not settle for standard SATA II storage for a repo server.
  • Dedicated RAM: Git's pack-objects process is memory hungry.
Pro Tip: At CoolVDS, we don't oversell memory. If you buy a 1GB Xen VPS, that RAM is ring-fenced for your kernel. This stability is why we are the reference platform for this setup.

Step 1: The Environment (Ubuntu 10.04 LTS)

We are using Ubuntu 10.04 Lucid Lynx. It is stable, supported, and handles package management cleanly. Log into your CoolVDS instance as root.

apt-get update && apt-get upgrade apt-get install git-core openssh-server

Note that the package is git-core. The transition to just "git" is still ongoing in some repositories, so stick to the core package to be safe.

Step 2: Creating the Git User

Never run your repositories as root. We create a dedicated user that will handle all SSH connections via public keys.

adduser --system --shell /bin/bash --gecos 'Git Version Control' --group --disabled-password --home /home/git git

Step 3: Installing Gitolite

Direct SSH access is messy for teams. We use Gitolite (the Perl version) to manage permissions. It uses a single system user but distinguishes developers by their SSH keys. It allows you to restrict who can push to master versus who can only read.

First, on your local workstation (not the server), generate your admin key if you haven't already:

ssh-keygen -t rsa -f ~/.ssh/git_admin

Copy the public key to your VPS:

scp ~/.ssh/git_admin.pub root@your-coolvds-ip:/tmp/git_admin.pub

Back on the server, switch to the git user and install Gitolite from the source (the package managers are often outdated):

cd /home/git git clone git://github.com/sitaramc/gitolite mkdir -p $HOME/bin gitolite/src/gl-system-install gl-setup /tmp/git_admin.pub

This script sets up the .ssh/authorized_keys file automatically. It restricts the git user to only running the Gitolite wrapper script. Security is enforced by the shell.

Step 4: Managing Repositories

Here is the beauty of this setup: You don't log into the server to create repos. You do it via Git. Clone the admin repository to your local machine:

git clone git@your-coolvds-ip:gitolite-admin

Inside, you will find a conf/gitolite.conf file. To add a new project and give access to a developer named "Bjorn", you simply edit this file:

repo project-viking RW+ = admin RW = bjorn

Commit and push that change. Gitolite hooks will instantly create the bare repository on the server. No ticket submission to IT required.

Why Infrastructure Matters: The CoolVDS Advantage

You can run this on an old desktop under your desk, but you shouldn't. Power failures and consumer-grade drives will corrupt your git objects eventually.

Feature Budget Shared Host CoolVDS Norway
Virtualization OpenVZ (Oversold) Xen / KVM (Dedicated)
Storage Shared SATA RAID-10 Enterprise Storage
SSH Access Jailed / Limited Full Root Access

When you are pushing a 2GB release branch, you need sustained throughput. Our infrastructure utilizes high-performance enterprise storage and premium tier 1 bandwidth providers in Oslo. This guarantees that your connection doesn't time out in the middle of a packfile transmission—a common issue with budget VPS Norway providers who choke on large continuous streams.

Data Sovereignty and Security

By hosting on CoolVDS, you are also adhering to best practices regarding data privacy. With the Data Inspectorate (Datatilsynet) becoming stricter about where personal data resides, keeping your code—which often contains hardcoded PII in test databases (we know you do it)—within Norwegian borders minimizes legal exposure.

Furthermore, our standard includes ddos protection at the edge. If a competitor or a script kiddie targets your IP, our mitigation scrubbers kick in, keeping your git port open so your deployment pipeline never stalls.

Final Thoughts

Git is the future of version control, but it demands respect for resources. Don't cripple your workflow with high latency or unreliable I/O.

Ready to migrate? Deploy a Debian or Ubuntu instance on CoolVDS today. We can have your root access ready in under 60 seconds, so you can get back to coding.

/// TAGS

/// RELATED POSTS

Building a CI/CD Pipeline on CoolVDS

Step-by-step guide to setting up a modern CI/CD pipeline using Firecracker MicroVMs....

Read More →

Taming the Beast: Kubernetes Networking Deep Dive (Pre-v1.0 Edition)

Google's Kubernetes is changing how we orchestrate Docker containers, but the networking model is a ...

Read More →

Stop SSH-ing into Production: Building a Git-Centric Deployment Pipeline

Manual FTP uploads and hot-patching config files are killing your stability. Here is how to implemen...

Read More →

Decomposing the Monolith: Practical Microservices Patterns for Nordic Ops

Moving from monolithic architectures to microservices introduces network complexity and latency chal...

Read More →

Beyond the Hype: Building "NoOps" Microservices Infrastructure in Norway

While Silicon Valley buzzes about AWS Lambda, pragmatic engineers know the truth: latency and vendor...

Read More →

Ditch Nagios: Monitoring Docker Microservices with Prometheus in 2015

Monolithic monitoring tools like Nagios fail in dynamic Docker environments. Learn how to deploy Pro...

Read More →
← Back to All Posts