GitLab Server

From Worcester State University Computer Science Department Wiki
Revision as of 13:16, 30 December 2013 by (Talk | contribs)

Jump to: navigation, search

Here's how we set up our GitLab server


  • The first step is installing CentOS
    • GitLab recommends Ubuntu, so there's a few workarounds that need to be done for this.
  • We followed this guide:
    • Use nginx for the webserver
      • For nginx, edit the /etc/nginx/sites-enabled/gitlab you create and change all instances of to
      • modify /home/git/gitlab-shell/config.yml for https and enable self-signed cert and also edit /home/git/gitlab/config/gitlab.yml for https and port 443.
    • Fix SSH:
      • $ sudo usermod -U git
        • CentOS by default locks accounts without passwords, this unlocks it.
      • after logging in and adding an SSH key and run
        • $ restorecon -R -v /home/git/.ssh
          • This fixes SELinux permissions so it'll use SSH keys.
  • known issues: https clone/push doesn't seem to work with a self-signed certificate unless you disable ssl verification on git with this command:
    • $ git config --global http.sslVerify false
      • It's recommended you renable ssl verification after cloning something with this command:
    • $ git config --global http.sslVerify true
      • You can always disable ssl verification in an already-exiting repo with the same command minus the --global flag in that repo.


You should be able to follow the official upgrade guides with no issue. Check the current version of gitlab on the help page after logging in and follow each upgrade to the latest- don't skip versions as you may miss some important updates.

  • I had two issues getting things working,
    • sudo: bundle: command not found
      • You can fix this by commenting out secure_path in the sudo config, edit with the command visudo and comment out the following line:
        • Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin
      • and add (or uncomment) this line:
        • Defaults  !secure_path
      • Save the file and re-login as the user you had issues with before. If all went well, you should get the next error:
    • env: ruby: command not found
      • Not sure what the best way to fix this is, I did the following commands:
        • # cd /bin
        • # link -s /usr/local/bin/ruby
      • This fixed all errors.
    • Because I am not sure of the security with those two solutions, I undid them after completing the upgrades. Uncomment the original lines in visudo and comment out your new line. To get rid of the ruby symlink, execute the following commands:
      • # cd /bin
      • # unlink ruby