un poquito

Debian (Wheezy) Gitlab 5.2 installation

Its been a while since my last post, and it has been even longer since the last time I installed a production application on a server. I rely on tons of hosted web applications and don’t host my own anymore. However, yesterday I decided to dust off my Linux admin skills and host my git repositories. The whole installation took over 3 hours since I ran into some issues, but I’m happy to say that it was a success!

Digital Ocean’s Droplet setup

First, I needed some hardware. After some research, I chose Digital Ocean’s (DO) $5/month VPS (Droplet in DO speak) because of its price (cheap!). This caused me some headaches though. The Droplet barely meet GitLab’s requirements and this led into some random crashes…until I noticed that the Droplet had NO swap at all. Fixing is easy and following Gitlab’s copy paste instructions, here is how you create and enable a 512MB swap file:

sudo dd if=/dev/zero of=/swapfile bs=1024 count=512k
sudo mkswap /swapfile
sudo swapon /swapfile
echo "/swapfile       none    swap    sw      0       0" >> /etc/fstab
sudo chown root:root /swapfile
sudo chmod 0600 /swapfile

Gitlab 5.2

Once that’s done, Gitlab’s installation is almost a copy paste experience thanks to Gitlab’s amazing instructions. My desired setup required some modifications that I’ll detail below though.

The first unexpected result came when verifying the application status:

sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production

The above command failed, but the suggested solution worked perfectly:

sudo -u git -H bundle exec rake sidekiq:start RAILS_ENV=production

Additionally, there are some documented issues with Debian’s older redis version so you have to install a newer one. As root paste:

echo "deb squeeze-backports main" >> /etc/apt/sources.list
apt-get update
apt-get -t squeeze-backports install redis-server

That finalized Gitlab’s installation. Now on to the web server.


This is where my desired setup diverges a bit from the vanilla instructions. To avoid having to rush into updating Gitlab in case a vulnerability arises, I decided to only allow local access to my web server and to Gitlab.

First, disable Nginx default “Welcome to Nginx!” site:

sudo rm /etc/nginx/sites-enabled/default

Then edit Gitlab’s Nginx configuration to include localhost:

sudo vim /etc/nginx/sites-enabled/gitlab

I also had to uncomment this line for Nginx to work:

server_names_hash_bucket_size 64;

And finally, filter all Internet incoming traffic to port 80:

sudo iptables -A INPUT ! -i lo -p tcp --destination-port 80 -j DROP
sudo iptables -A INPUT ! -i lo -p tcp --destination-port 25 -j DROP
sudo ip6tables -A INPUT ! -i lo -p tcp --destination-port 80 -j DROP
sudo ip6tables -A INPUT ! -i lo -p tcp --destination-port 25 -j DROP

Make sure that the iptables rules persist across reboots:

sudo apt-get iptables-persistent

And you’re DONE! Everything should be working great now, except…if all Internet port 80 traffic is being filtered, how do we access Gitlab? Well…we access it through an encrypted tunnel via ssh.

On your computer modify and run this command:

ssh -N -q -L 8080:localhost:80

Now you have a nice encrypted ssh forward. Fire up your preferred browser and enter http://localhost:8080 on your status bar. Or you could just click http://localhost:8080 :)