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
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 http://backports.debian.org/debian-backports 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
... server_name your.domain.com localhost; ...
I also had to uncomment this line for Nginx to work:
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 yourUser@yourDomain.com
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 :)