Escaping SVN Hell: Building a Bulletproof Private Git Server on Debian Lenny
If I have to resolve one more tree conflict in Subversion because two developers breathed on the same file at the same time, I might just pull the power cord on the rack. It is 2009. We should be done with centralized locking and single points of failure. Distributed Version Control Systems (DVCS) are not just a fad for kernel hackers anymore; they are a necessity for any team that cares about shipping code without an ulcer.
While GitHub is making waves in the open-source community, let's be real: most of us in the enterprise cannot push proprietary client code to a third-party server hosted in the US. Between the Personopplysningsloven (Personal Data Act) here in Norway and generic corporate paranoia, self-hosting is the only viable path. You need total control, you need low latency for those massive pushes, and you need it private.
Today, we are going to build a high-performance, private Git server using Gitosis on a standard CoolVDS instance running Debian 5.0 (Lenny). Why CoolVDS? Because Git is metadata-heavy. It thrashes disks. If you run this on a cheap shared host or a container with "burstable" RAM, you will see timeouts during git-gc. You need the dedicated I/O throughput of a proper Xen-based VDS.
The Architecture: Why Gitosis?
You could just create a UNIX user for every developer, but that is a security nightmare. Do you really want your junior frontend dev having shell access to your production repository server? didn't think so.
Gitosis manages authorized_keys for you. It allows all your developers to connect via a single SSH user (usually git), but it restricts them to only running Git commands. It also provides granular access control to repositories. It is the industry standard right now for a reason.
Prerequisites
- A CoolVDS instance (The "Standard" plan with 512MB RAM is plenty for this).
- Debian 5.0 (Lenny) or Ubuntu 8.04 LTS.
- Root access.
- Your local public SSH key (
~/.ssh/id_rsa.pub).
Step 1: System Prep and Dependencies
First, log into your CoolVDS blade. We need to grab git-core and the Python setups tools required to build Gitosis.
apt-get update
apt-get install -y git-core python-setuptools
This pulls the latest stable Git from the Debian repositories. While you're at it, verify your locale settings. I've seen Perl warnings explode in logs when Norwegian locales aren't generated properly on minimal images.
Step 2: Create the Git User
This user will own the repositories. We create it as a system user with a disabled password.
useradd -r -d /home/git -c 'git version control' -m -s /bin/bash git
passwd -l git
Step 3: Installing Gitosis
Gitosis isn't in the standard stable apt repos for Lenny yet, so we clone it directly from the source. This is better anyway, as we want the latest patches.
cd /tmp
git clone git://eagain.net/gitosis.git
cd gitosis
python setup.py install
If you see output ending in Processing dependencies for gitosis==0.2, you are golden.
Step 4: Initializing the Server
Here is the clever part. You don't configure Gitosis by editing files on the server manually. You configure it by pushing changes to a special administrative Git repository. To set this up, you need to upload your local public key to the server.
Assuming you SCP'd your key to /tmp/my_key.pub on the server:
sudo -H -u git gitosis-init < /tmp/my_key.pub
You should see output indicating that the repository has been initialized in /home/git/repositories. Finally, make sure the post-update hook is executable (a common gotcha):
chmod 755 /home/git/repositories/gitosis-admin.git/hooks/post-update
Step 5: Configuration from Your Workstation
Log out of the server. You are done there. This is the beauty of the system. From your local machine in Oslo (or wherever your dev team sits), you clone the admin repo:
git clone git@your-coolvds-ip:gitosis-admin.git
cd gitosis-admin
You will see a file named gitosis.conf and a directory named keydir.
Adding a New Team Member and Project
Let's say we have a developer named "Olav" and a new project called "fjord-mapping".
- Get the key: Put Olav's public key file (
olav.pub) into thekeydir/directory. - Edit the config: Open
gitosis.confand add the following block:
[group fjord-devs]
members = your-username olav
writable = fjord-mapping
Commit and push these changes:
git add keydir/olav.pub gitosis.conf
git commit -m "Added Olav to fjord project"
git push
The magic happens instantly. The Gitosis scripts on the server parse this push and update the ~git/.ssh/authorized_keys file automatically. Olav can now clone and push to the fjord-mapping repo without you ever touching the server again.
Pro Tip: For massive repositories, Git's garbage collection (git gc) can be memory intensive. On a VDS, if you are running other services like Apache or MySQL, you might hit the RAM ceiling. I recommend settinggit config --global pack.windowMemory "256m"to prevent Git from swallowing all available RAM and triggering the OOM killer.
Why Infrastructure Matters for Git
You might ask, "Why not just run this on an old box in the office closet?"
Two reasons: Power and Latency.
Here in Norway, we have stable power, but your office DSL connection? Not so much. Distributed Version Control means developers are pulling the entire history of the project. If you have a 2GB repository, serving that over an asymmetrical DSL uplink is painful. You want a 100Mbit or 1Gbit uplink found in a datacenter.
Furthermore, reliability is key. CoolVDS uses enterprise-grade SAS 15k RPM RAID-10 storage arrays. When twenty developers run git fetch simultaneously on Monday morning, a standard SATA drive will choke on the random I/O. The seek times will kill your productivity. Our RAID-10 arrays handle that concurrency without breaking a sweat, ensuring your git status returns instantly.
Network Latency Checks
When choosing a VDS provider, ping times matter for SSH responsiveness. From downtown Oslo (NIX), typical latency to CoolVDS infrastructure is negligible:
| Origin | Target | Latency |
|---|---|---|
| Oslo (Telenor) | CoolVDS (DC1) | ~4ms |
| Bergen (NextGenTel) | CoolVDS (DC1) | ~9ms |
| US East Coast | CoolVDS (DC1) | ~110ms |
Keeping your data within Norwegian borders also simplifies compliance with Datatilsynet guidelines regarding where your intellectual property and potential embedded customer data resides.
Conclusion
Subversion had its day, but the era of the distributed workflow is here. Setting up a private Git server on Debian Lenny with Gitosis takes less than 15 minutes, costs a fraction of a commercial proprietary license, and gives you total sovereignty over your code.
Don't let slow I/O or network lag disrupt your team's flow. Spin up a CoolVDS instance today and experience what version control feels like on professional-grade hardware.