Lessons learned from GitLab installation

Last week I was appointed a task to install and configure GitLab for my company. Right now we are using SVN and we have reached an agreement to use something less 1980s-ish to improve our everyday lives. GitLab is open source, written in Rails, backed by Sidekiq so installation went quite smooth. Here are some notes from it:

GitLab with rbenv

On the machine I was deploying GitLab to there was already Ruby 1.8.7 (!) installed and it backed some old crucial web application so I could not remove it. GitLab needs ruby 2.0 so I had to go with RVM or rbenv. I chose the latter with no strong feelings (I don’t like the idea of overwriting cd but I can live with that).

The application generally works quite well even though it does not have any explicit support for rbenv (however, I found something like Using RVM: no later in configuration checking script, but it was already too late…). The most difficult thing was to deal with non-interactive SSH session. It was run with /bin/sh and did not include .bashrc, where rbenv init scripts were put. As a result post-commit hooks were run with system 1.8.7 and, of course, failed in every possible way.

The server was running under Ubuntu so the fix was easy enough - I simply had to find the following line in Ubuntu’s default .bashrc:

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

… and put rbenv init scripts above.

However, rumor has it that it is not as simple in every Linux distribution out there. Some of them apparently does not read .bashrc in non-interactive sessions and you have to play with SSH config:

1. Enable PermitUserEnvironment in sshd_config
2. Edit ~/.ssh/environment file for git user (the one that GitLab is set on) and source .bashrc and /etc/profile there.

And you should be good too.

GitLab with LDAP

The company also uses LDAP to manage user accounts and permissions. GitLab has built-in support for LDAP and it even works with anonymous logins (when you don’t give GitLab a separate LDAP account and just pass the user’s credentials). The only trick that caused us a bit of headache was that users in LDAP directory must have email addresses assigned. Ours did not have and GitLab refused to create accounts for users when they successfully authenticated to LDAP.

I ended up with filling in emails by hand because it was only about more or less 30 people but if you have more and no emails assigned, this might be painful.

GitLab behind Apache

Officially GitLab supports nginx as proxy server and does not provide config for Apache. Luckily, they also maintain a repository of unofficial recipes for other software (i.e. puma instead of unicorn) and there is Apache configuration there too.