GitLab is a Git web frontend designed to be similar to GitHub and other social coding sites. It's written entirely in Ruby and has a new release monthly. It also supports a literally huge volume of features from code check-in, key management, project management, and so forth.
These instructions are adapted from GitLab Recipes. Naturally if you're using an automation solution like Puppet for any of the below-referenced services I'd strongly recommend sticking with that over the below-listed instructions as it'll save you some headache in the future.
For RedHat-based distributions, ensure the prerequisite software is installed:
Note: make sure to update username/password in config/database.yml. You only need to adapt the production settings (first part).
# PostgreSQL example config/database.yml # disable host/port in order to support the default postgresql ident auth # PRODUCTION production: adapter: postgresql encoding: unicode database: gitlabhq_production pool: 5 username: git password: "<db password>" #host: localhost #port: 5432 # socket: /tmp/postgresql.sock
Note: if you followed the database guide then please do as follows:
#Change root to gitlab.
#Change secure password with the value you have given to a secure value.
You can keep the double quotes around the password.
Make config/database.yml readable to git only.
chmod o-rwx config/database.yml
Install the Charlock Holmes gem to connect with the database.
su -gem install charlock_holmes --version '0.6.9.4'
Do the bundle install for the database. Assuming MySQL, run:
cd /home/git/gitlab/bundle install --deployment --without development test postgres puma aws
Initialize Database and Activate Advanced Features
cd /home/git/gitlabbundle exec rake gitlab:setup RAILS_ENV=production
Note: type 'yes' to create the database. When done you see 'Administrator account created:'
Download the init script (will be /etc/init.d/gitlab).
su -wget -O /etc/init.d/gitlab https://raw.github.com/gitlabhq/gitlab-recipes/master/init/sysvinit/centos/gitlab-unicornchmod +x /etc/init.d/gitlabchkconfig --add gitlab
Make GitLab start on boot.
chkconfig gitlab on
Check if GitLab and its environment are configured correctly.
su - gitcd gitlab/bundle exec rake gitlab:env:info RAILS_ENV=productionexit
Start up GitLab.
service gitlab start
Double-check GitLab's status.
su - gitcd gitlab/bundle exec rake gitlab:check RAILS_ENV=production
Note: the output will complain that your init script is not up-to-date as follows. You can safely ignore that warning.
Init script up-to-date? ... no Try fixing it: Redownload the init script For more information see: doc/install/installation.md in section "Install Init Script" Please fix the error above and rerun the checks.
We will configure apache with module mod_proxy which is loaded by default when installing apache:
Open /etc/httpd/conf.d/gitlab.conf with your editor and replace git.example.org with your FQDN.
Add LoadModule ssl_module /etc/httpd/modules/mod_ssl.so in /etc/httpd/conf/httpd.conf.
If you want to run other websites on the same system, you'll need to add in /etc/httpd/conf/httpd.conf:
NameVirtualHost *:80<IfModule mod_ssl.c> # If you add NameVirtualHost *:443 here, you will also have to change # the VirtualHost statement in /etc/httpd/conf.d/gitlab.conf # to <VirtualHost *:443> NameVirtualHost *:443 Listen 443</IfModule>
Poke a selinux hole for httpd so it can be in front of GitLab:
setsebool -P httpd_can_network_connect on
service httpd start
Poke an iptables hole so users can access the httpd (http and https ports) and ssh.
lokkit -s http -s https -s ssh
Restart the service for the changes to take effect.
service iptables restart
Visit the URL you set up for your first GitLab login. The setup has created an admin account for you which you can use at this time.
You will then be redirected to change the default admin password.
In version 6.2.x of GitLab if you're configuring via LDAP the first time a user logs in to the system it will send the user a "confirmation e-mail." Unfortunately this is broken as A)the user does not need to confirm their account in the first place and B)the link in it is bogus. There is no way to disable this e-mail so you'll have to simply notify the users to ignore it. Supposedly a fix will be coming in later versions.
In version 6.2.x of GitLab when a user is added to a project a bogus e-mail goes out with a dysfunctional link to the group. The user can safely ignore the e-mail and simply navigate to it using GitLab's native web interface.
The /home/git/.ssh/authorized_keys file is automatically managed by GitLab. Generally do NOT touch it.