Difference between revisions of "GitLab"

From ArchWiki
Jump to: navigation, search
(merge request)
(GitLab: Change tip to note, some style changes)
 
(474 intermediate revisions by 75 users not shown)
Line 1: Line 1:
 
[[Category:Version Control System]]
 
[[Category:Version Control System]]
{{Article summary start}}
+
[[Category:Web applications]]
{{Article summary text|This page gives guidelines for the installation and configuration of Gitlab on Archlinux.}}
+
[[ja:Gitlab]]
{{Article summary heading|Related}}
+
{{Related articles start}}
{{Article summary wiki|Gitolite}}
+
{{Related|Gitolite}}
{{Article summary wiki|Ruby on Rails}}
+
{{Related|Ruby on Rails}}
{{Article summary end}}
+
{{Related articles end}}
{{Merge|Gitlab2|Most of the article is duplicated.}}
 
{{Out of date|As of version 5.0,Gitlab will no longer depend on gitolite. Also redis is replaced by sidekiq. A rewrite is scheduled when 5.0 comes out on March 22nd.}}
 
  
[http://gitlabhq.com/ Gitlab] is a free git repository management application based on [[Ruby on Rails]] and [[Gitolite]]. It is distributed under the MIT License and its source code can be found on [https://github.com/gitlabhq/gitlabhq Github]. It is a very active project with a monthly release cycle and ideal for businesses that want to keep their code private. Consider it as a self hosted Github but open source. You can try a demo page [http://gitlabhq.com/ here].
+
From [https://about.gitlab.com/ GitLab's homepage]:
  
{{Note|Throughout the article, sudo is heavily used, assuming that the user that is running the commands is root or someone with equal privileges. There is no need to edit the sudoers file whatsoever. It is only used to change to the appropriate user. For more info read {{ic|man sudo}}.}}
+
:GitLab offers git repository management, code reviews, issue tracking, activity feeds and wikis. Enterprises install GitLab on-premise and connect it with LDAP and Active Directory servers for secure authentication and authorization. A single GitLab server can handle more than 25,000 users but it is also possible to create a high availability setup with multiple active servers.
  
==Required packages==
+
An example live version can be found at [https://gitlab.com/ GitLab.com].
  
Install the packages below as they are needed to proceed further.
+
== Installation ==
  
# pacman -Syu --needed sudo git wget curl checkinstall libxml2 libxslt mysql++ base-devel zlib icu redis openssh python2 python2-pygments python2-pip libyaml ruby libpqxx
+
{{Note|This article covers installing and configuring GitLab without HTTPS at first. If needed, see [[#Advanced Configuration]] to set up SSL.}}
  
==Create user accounts==
+
GitLab requires [[Redis]] and a database backend. If you plan to run it on the same machine, first install either [[MySQL]] or [[PostgreSQL]].
  
Add {{ic|git}} and {{ic|gitlab}} user. {{ic|git}} is a system user that will be used for [[gitolite]]. {{ic|gitlab}} user will be used for Gitlab and is part of group git.
+
[[Install]] the {{pkg|gitlab}} package.
  
# usermod -d /home/git git
+
In order to receive mail notifications, a mail server must be installed and configured. See [[:Category:Mail server]] for details.
# mkdir -pv /home/git
 
# chown -R git:git /home/git
 
# useradd --user-group --shell /bin/bash --comment 'gitlab system' --create-home --groups git gitlab
 
  
Note that the user ''git'' must have its initial group set to ''git'' (not ''users''). If the initial group is not ''git'', then all files created by the ''git'' user will be owned by git:users which will prevent gitlab from showing you a newly created repo (it will get stucked at the page where it tells you how to push to the new repo). Running ''sudo usermod -g git git'' will set the ''git'' user's initial group.
+
== Configuration ==
  
==Gitolite==
+
=== Preliminary Notes ===
  
 +
GitLab is composed of multiple components, see the [https://docs.gitlab.com/ce/development/architecture.html architecture overview page].
  
Clone the gitolite repository from Gitlab's fork. Note that it's version 3.
+
The {{pkg|gitlab}} package installs GitLab's files in a manner that more closely follow standard Linux conventions:
# cd /home/git
 
# sudo -H -u git git clone -b gl-v304 https://github.com/gitlabhq/gitolite.git /home/git/gitolite
 
  
Generate Gitlab's ssh key to be used with gitolite:
+
{| class="wikitable"
 +
! Description
 +
! [https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/installation.md GitLab's Official]
 +
! {{pkg|gitlab}}
 +
|----------------------------------------------------------
 +
| Configuration File GitShell
 +
| {{ic|/home/git/gitlab-shell/config.yml}}
 +
| {{ic|/etc/webapps/gitlab-shell/config.yml}}
 +
|----------------------------------------------------------
 +
| Configuration File GitLab
 +
| {{ic|/home/git/gitlab/config/gitlab.yml}}
 +
| {{ic|/etc/webapps/gitlab/gitlab.yml}}
 +
|----------------------------------------------------------
 +
| User (Home Directory)
 +
| {{ic|git}} ({{ic|/home/git}})
 +
| {{ic|gitlab}} ({{ic|/var/lib/gitlab}})
 +
|}
  
{{ic|<nowiki> # sudo -H -u gitlab ssh-keygen -q -N '' -t rsa -f /home/gitlab/.ssh/id_rsa</nowiki>}}
+
{{tip|If you are familiar with the [[Arch Build System]] you can edit the PKGBUILD and relevant files to change gitlab's home directory to a place of your liking.}}
  
Add the following path to git's {{ic|.bash_profile}}:
+
===GitLab===
# sudo -u git sh -c 'echo "export PATH=/home/git/bin:$PATH" >> /home/git/.bash_profile'
+
Edit {{ic|/etc/webapps/gitlab/gitlab.yml}} and setup at least the following parameters:
# sudo -u git sh -c 'mkdir /home/git/bin'
 
# sudo -u git -H sh -c "export PATH=/home/git/bin:$PATH; /home/git/gitolite/install -ln"
 
 
Copy Gitlab's public key to gitolite's home and change permissions:
 
# cp /home/gitlab/.ssh/id_rsa.pub /home/git/gitlab.pub
 
# chmod 0444 /home/git/gitlab.pub
 
  
Install gitolite:
+
{{Note|The {{ic|hostname}} and {{ic|port}} are used for the {{ic|git clone http://hostname:port}} as example.}}
# sudo -u git -H sh -c "export PATH=/home/git/bin:$PATH; /home/git/gitolite/src/gitolite setup -pk /home/git/gitlab.pub"
 
  
{{hc|Example output|
+
'''Hostname:''' In the {{ic|gitlab:}} section set {{ic|host:}} - replacing {{ic|localhost}} to {{ic|yourdomain.com}} ('''note:''' no 'http://' or trailing slash) - into your fully qualified domain name.
creating gitolite-admin...
 
Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/
 
creating testing...
 
Initialized empty Git repository in /home/git/repositories/testing.git/
 
[master (root-commit) 012fdf5] start
 
2 files changed, 6 insertions(+)
 
create mode 100644 conf/gitolite.conf
 
create mode 100644 keydir/gitlab.pub
 
}}
 
  
Change permissions:
+
'''Port:''' {{ic|port:}} can be confusing. This is not the port that the gitlab server (unicorn) runs on; it's the port that users will initially access through in their browser. Basically, if you intend for users to visit 'yourdomain.com' in their browser, without appending a port number to the domain name, leave {{ic|port:}} as {{ic|80}}. If you intend your users to type something like 'yourdomain.com:3425' into their browsers, then you'd set {{ic|port:}} to {{ic|3425}}. You will also have to '''configure your webserver''' to listen on that port.
# chmod -R g+rwX /home/git/repositories/
 
# chmod g+x /home/git
 
# chown -R git:git /home/git/repositories/
 
  
{{Note| The next step is '''important''' to succeed. If not, do not try to proceed any further.}}
+
'''Timezone (optional):''' The {{ic|time_zone:}} parameter is optional, but may be useful to force the zone of GitLab applications.
{{Note| If you obtain an error like "Permission denied (publickey)" for the next command, one reason can be that "UsePAM" is not activated in ssh. Set "UsePAM yes" in /etc/ssh/sshd_config" and restart the ssh server. }}
 
  
Add Gitlab's ssh key to known hosts:
+
Finally set the correct [[permissions]] to the ''uploads'' directory:
# sudo -u gitlab -H git clone git@localhost:gitolite-admin.git /tmp/gitolite-admin
 
  
Answer yes. At this point you should be able to clone the gitolite-admin repository.
+
# chmod 700 /var/lib/gitlab/uploads
  
{{hc|Example output|
+
=== Custom port for Unicorn ===
Cloning into '/tmp/gitolite-admin'...
 
The authenticity of host 'localhost (::1)' can't be established.
 
ECDSA key fingerprint is 5a:50:69:47:1f:1c:61:79:08:a8:2c:fa:a1:fb:48:bf.
 
Are you sure you want to continue connecting (yes/no)? yes
 
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
 
remote: Counting objects: 6, done.
 
remote: Compressing objects: 100% (4/4), done.
 
Receiving objects: 100% (6/6), 712 bytes, done.
 
remote: Total 6 (delta 0), reused 0 (delta 0)
 
}}
 
  
If the repository is cloned successfully, it is safe to remove it:
+
GitLab Unicorn is the main component which processes most of the user requests. By default, it listens on the {{ic|127.0.0.1:8080}} address which can be changed in the {{ic|/etc/webapps/gitlab/unicorn.rb}} file:
# rm -rf /tmp/gitolite-admin
 
  
==Gitlab==
+
{{hc|/etc/webapps/gitlab/unicorn.rb|2=
 +
listen "/run/gitlab/gitlab.socket", :backlog => 1024
 +
listen "'''127.0.0.1:8080'''", :tcp_nopush => true
 +
}}
  
===Installation===
+
If the Unicorn address is changed, the configuration of other components which communicate with Unicorn have to be updated as well:
  
{{Tip| If you do not want to download any documentation, add {{ic|gem: --no-rdoc --no-ri}} to {{ic|/home/gitlab/.gemrc}}. Be sure to add it as the gitlab user in order to acquire the appropriate permissions.}}
+
* For GitLab Shell, update the {{ic|gitlab_url}} variable in {{ic|/etc/webapps/gitlab-shell/config.yml}}.
 +
: {{Tip|According to the comment in the config file, UNIX socket path can be specified with URL-escaped slashes (i.e. {{ic|http+unix://%2Frun%2Fgitlab%2Fgitlab.socket}} for the default {{ic|/run/gitlab/gitlab.socket}}). Additionally, un-escaped slashes can be used to specify the [https://docs.gitlab.com/ce/install/relative_url.html relative URL root] (e.g. {{ic|/gitlab}}).}}
 +
* For GitLab Workhorse, [[edit]] the {{ic|gitlab-workhorse.service}} and update the {{ic|-authBackend}} option.
  
Add [[ruby]] to Gitlab's {{ic|PATH}}:
+
=== Secret strings ===
# sudo -u gitlab -H sh -c 'echo "export PATH=$(ruby -rubygems -e "puts Gem.user_dir")/bin:$PATH" >> /home/gitlab/.bashrc'
 
  
Install bundler and charlock_holmes:
+
Make sure that the files {{ic|/etc/webapps/gitlab/secret}} and {{ic|/etc/webapps/gitlab-shell/secret}} files contain something. Their content should be kept secret because they are used for the generation of authentication tokens etc.
# sudo -u gitlab -H gem install charlock_holmes --version '0.6.9'
 
# sudo -u gitlab -H gem install bundler
 
  
{{Note|When installing charlock_holmes don't mind any errors that might occur, that's ''normal''.}}
+
For example, random strings can be generated with the following commands:
  
Because systemd requires full path to binaries to launch (the path is not enough), create a symbolic link in /home/gitlab/bin/ that points to the **bundle** executable. We'll also add the folder to gitlab's PATH:
+
  # hexdump -v -n 64 -e '1/1 "%02x"' /dev/urandom > /etc/webapps/gitlab/secret
# sudo -u gitlab -H mkdir /home/gitlab/bin
+
  # chown root:gitlab /etc/webapps/gitlab/secret
  # sudo -u gitlab -H sh -c "ln -s \$(ruby -rubygems -e 'puts Gem.user_dir')/bin/bundle /home/gitlab/bin/"
+
# chmod 640 /etc/webapps/gitlab/secret
  # sudo -u gitlab -H sh -c 'echo "export PATH=/home/gitlab/bin:$PATH" >> /home/gitlab/.bashrc'
 
  
 +
# hexdump -v -n 64 -e '1/1 "%02x"' /dev/urandom > /etc/webapps/gitlab-shell/secret
 +
# chown root:gitlab /etc/webapps/gitlab-shell/secret
 +
# chmod 640 /etc/webapps/gitlab-shell/secret
  
Clone Gitlab's stable repository:
+
===Redis===
# cd /home/gitlab
 
# sudo -H -u gitlab git clone -b stable git://github.com/gitlabhq/gitlabhq.git gitlab
 
# cd gitlab
 
# sudo -H -u gitlab git checkout v3.1.0
 
# sudo -u gitlab mkdir -pv tmp
 
  
===Basic configuration===
+
In order to provide sufficient performance you will need a cache database. [[Redis#Installation|Install]] and [[Redis#Configuration|configure]] a Redis instance, being careful to the section dedicated to listening via a socket.
  
First we need to rename the example file.
+
* Add the ''gitlab'' user to the ''redis'' [[group]].
  
# sudo -u gitlab cp config/gitlab.yml.example config/gitlab.yml
+
* Update the configuration files:
 +
{{hc|/etc/webapps/gitlab/resque.yml|2=
 +
development: unix:/run/redis/redis.sock
 +
test: unix:/run/redis/redis.sock
 +
production: unix:/run/redis/redis.sock
 +
}}
  
The options are pretty straightforward. You can skip this part as it is quite detailed. Open {{ic|/home/gitlab/gitlab/config/gitlab.yml}} with your favorite editor and check the settings below.
+
{{hc|/etc/webapps/gitlab-shell/config.yml|2=
 +
# Redis settings used for pushing commit notices to gitlab
 +
redis:
 +
  bin: /usr/bin/redis-cli
 +
  host: 127.0.0.1
 +
  port: 6379
 +
  # pass: redispass # Allows you to specify the password for Redis
 +
  database: 5 # Use different database, default up to 16
 +
  socket: /run/redis/redis.sock # '''uncomment''' this line
 +
  namespace: resque:gitlab
 +
}}
  
====Web application specific settings====
+
=== Database backend ===
  
{{hc|/home/gitlab/gitlab/config/gitlab.yml|<nowiki>
+
{{Accuracy|GitLab [https://docs.gitlab.com/ce/install/installation.html#6-database recommends] to use PostgreSQL.}}
host: myhost.example.com
 
port: 80
 
https: false
 
</nowiki>}}
 
  
*{{ic|host}}: Enter your [[Wikipedia:Fully_qualified_domain_name|Fully Qualified Domain Name]].
+
A Database backend will be required before Gitlab can be run. Currently GitLab supports [[MariaDB]] and [[PostgreSQL]]. By default, GitLab assumes you will use MySQL. Extra work is needed if you plan to use PostgreSQL.
  
====Email used for notification====
+
==== MariaDB ====
 +
To set up MySQL (MariaDB) you need to create a database called {{ic|gitlabhq_production}} along with a user (default: {{ic|gitlab}}) who has full privileges to the database:
  
{{hc|/home/gitlab/gitlab/config/gitlab.yml|<nowiki>
+
{{hc|$ mysql -u root -p|2=
from: notify@example.com
+
mysql> CREATE DATABASE `gitlabhq_production` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;
</nowiki>}}
+
mysql> CREATE USER 'gitlab'@'localhost' IDENTIFIED BY 'password';
 +
mysql> GRANT ALL ON `gitlabhq_production`.* TO 'gitlab'@'localhost';
 +
mysql> \q
 +
}}
  
This is how the mail address will be shown for mail notifications. Gitlab needs the sendmail command in order to send emails (for things like lost password recovery, new user addition etc). This command is provided by packages such as [[msmtp]], [[postfix]], [[sendmail]] etc, but you can only have one of them installed. First, check whether you already have the sendmail command:
+
Try connecting to the new database with the new user:
  
  # ls /usr/sbin/sendmail
+
  $ mysql -u '''gitlab''' -p -D gitlabhq_production
  
If you get a ‘cannot access /usr/bin/sendmail’ then install one of the above packages.
+
Copy the MySQL template file before configuring it:
  
====Application specific settings====
+
# cp /usr/share/doc/gitlab/database.yml.mysql /etc/webapps/gitlab/database.yml
  
{{hc|/home/gitlab/gitlab/config/gitlab.yml|<nowiki>
+
Next you will need to open {{ic|/etc/webapps/gitlab/database.yml}} and set {{ic|username:}} and {{ic|password:}} for the {{ic|gitlabhq_production}}:
default_projects_limit: 10
 
# backup_path: "/vol/backups"  # default: Rails.root + backups/
 
# backup_keep_time: 604800      # default: 0 (forever) (in seconds)
 
</nowiki>}}
 
  
*{{ic|default_projects_limit}}: As the name suggests, this integer defines the default number of projects new users have. The number can change from within Gitlab by an administrator.
+
{{hc|/etc/webapps/gitlab/database.yml|
*{{ic|backup_path}}: The path where backups are stored. Default location is {{ic|/home/gitlab/gitlab/backups}}. The {{ic|backups}} folder is created automatically after first backup.
+
#
*{{ic|backup_keep_time}}: Time to preserve backups. The default option is to never be deleted.
+
# PRODUCTION
 +
#
 +
production:
 +
  adapter: mysql2
 +
  encoding: utf8
 +
  collation: utf8_general_ci
 +
  reconnect: false
 +
  database: gitlabhq_production
 +
  pool: 10
 +
  username: '''username'''
 +
  password: '''"password"'''
 +
  # host: localhost
 +
  # socket: /run/mysqld/mysqld.sock # If running MariaDB as socket
 +
...
 +
}}
  
Also check [[#Backup_and_restore| Backup and restore]].
+
It should not be set as world readable, e.g. only processes running under the {{ic|gitlab}} user should have read/write access:
  
====Git Hosting configuration====
+
# chmod 600 /etc/webapps/gitlab/database.yml
 +
# chown gitlab:gitlab /etc/webapps/gitlab/database.yml
  
{{hc|/home/gitlab/gitlab/config/gitlab.yml|<nowiki>
+
For more info and other ways to create/manage MySQL databases, see the [https://mariadb.org/docs/ MariaDB documentation] and the [https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/installation.md GitLab official (generic) install guide].
admin_uri: git@localhost:gitolite-admin
 
base_path: /home/git/repositories/
 
hooks_path: /home/git/share/gitolite/hooks/
 
# host: localhost
 
git_user: git
 
upload_pack: true
 
receive_pack: true
 
# port: 22
 
</nowiki>}}
 
  
*{{ic|admin_uri}}: Do not change it. Leave as is.
+
==== PostgreSQL ====
*{{ic|base_path}}: The path where gitolite's repositories reside. If the repositories directory is different than the default one, change it here.
+
Login to PostgreSQL and create the {{ic|gitlabhq_production}} database with along with its user. Remember to change {{ic|your_username_here}} and {{ic|your_password_here}} to the real values:
*{{ic|hooks_path}}: change default setting to /home/git/share/gitolite/hooks/
 
*{{ic|host}}: Should point to your FQDN.
 
*{{ic|git_user}}: Name of the git user we created.
 
*{{ic|upload_pack}}:
 
*{{ic|receive_pack}}:  
 
  
*{{ic|port}}: ssh port which git should use. Default one is 22. If you want to change it for safety reasons, do not forget to also add the port number to {{ic|.ssh/config}}.
+
# psql -d template1
  
{{hc|/home/gitlab/gitlab/.ssh/config|<nowiki>
+
{{bc|1=
Host localhost
+
template1=# CREATE USER your_username_here WITH PASSWORD 'your_password_here';
Port 5000
+
template1=# ALTER USER your_username_here SUPERUSER;
</nowiki>}}
+
template1=# CREATE DATABASE gitlabhq_production OWNER your_username_here;
 
+
template1=# \q
====Git settings====
+
}}
  
{{hc|/home/gitlab/gitlab/config/gitlab.yml|<nowiki>
+
{{Note|The reason for creating the user as a superuser is that GitLab is trying to be "smart" and install extensions (not just create them in its own userspace). And this is only allowed by superusers in Postgresql.}}
path: /usr/bin/git
 
git_max_size: 5242880 # 5.megabytes
 
git_timeout: 10
 
</nowiki>}}
 
  
*{{ic|git_max_size}}: Max size of git objects like commits, in bytes,.This value can be increased if you have very large commits.
+
Try connecting to the new database with the new user to verify it works:
*{{ic|git_timeout}}: git timeout to read commit, in seconds.
 
  
===Database selection===
+
# psql -d gitlabhq_production
  
SQLite support in Gitlab is now deprecated. See [https://github.com/gitlabhq/gitlabhq/pull/2093 this bug report].
+
Copy the PostgreSQL template file before configuring it (overwriting the default MySQL configuration file):
  
====MySQL====
+
# cp /usr/share/doc/gitlab/database.yml.postgresql /etc/webapps/gitlab/database.yml
  
[[pacman|Install]] {{Pkg|mysql}} from the [[official repositories]] and start the [[daemon]]. Create the database and do not forget to replace {{ic|your_password_here}} with a real one.
+
Open the new {{ic|/etc/webapps/gitlab/database.yml}} and set the values for {{ic|username:}} and {{ic|password:}}. For example:
# mysql -u root -p
 
 
mysql> create database gitlabhq_production;
 
mysql> create user 'gitlab'@'localhost' identified by 'your_password_here';
 
mysql> grant all privileges on gitlabhq_production.* to 'gitlab'@'localhost' with grant option;
 
mysql> exit;
 
  
Copy the example configuration file and make sure to update username/password in {{ic|config/database.yml}} at production section:
+
{{hc|/etc/webapps/gitlab/database.yml|
# sudo -u gitlab cp config/database.yml.mysql config/database.yml
+
#
 
+
# PRODUCTION
===Install gems===
+
#
This could take a while as it installs all required libraries.
+
production:
 
+
  adapter: postgresql
# cd /home/gitlab/gitlab
+
  encoding: unicode
# export PATH=/home/gitlab/bin:$PATH
+
  database: gitlabhq_production
# sudo -u gitlab -H bundle install --deployment
+
  pool: 10
 
+
  username: your_username_here
{{Note|1= Using "--without development test" in bundle command line will ignore required packages for database backup and restore }}
+
  password: "your_password_here"
 
+
  # host: localhost
===Start redis server===
+
  # port: 5432
 
+
  # socket: /tmp/postgresql.sock
Start the [[daemon]]. If you are using {{Pkg| initscripts}} you might want to add {{ic|redis}} to your {{ic|DAEMONS}} array in {{ic|rc.conf}}.
+
...
 +
}}
  
{{Note|redis might already be running, causing a FAIL message to appear. Check if it is already running with {{ic|rc.d list redis}}.}}
+
For our purposes (unless you know what you are doing), you do not need to worry about configuring the other databases listed in {{ic|/etc/webapps/gitlab/database.yml}}. We only need to set up the production database to get GitLab working.
  
If you have switched to [[systemd]], there is a service file included in the official package. See [[daemon]] how to enable it.
+
=== Firewall ===
  
===Populate the database===
+
If you want to give direct access to your Gitlab installation through an [[iptables]] firewall, you may need to adjust the port and the network address:
  
  # sudo -u gitlab bundle exec rake gitlab:app:setup RAILS_ENV=production
+
  # iptables -A tcp_inbound -p TCP -s '''192.168.1.0/24''' --destination-port '''80''' -j ACCEPT
  
===Setup gitlab hooks===
+
To enable API-access:
  
  # cp ./lib/hooks/post-receive /home/git/.gitolite/hooks/common/post-receive
+
  # iptables -A tcp_inbound -p TCP -s '''192.168.1.0/24''' --destination-port '''8080''' -j ACCEPT
# chown git:git /home/git/.gitolite/hooks/common/post-receive
 
  
===Check status===
+
If you are behind a router, do not forget to forward this port to the running GitLab server host, if you want to allow WAN-access.
  
With the following commands we check if the steps we followed so far are configured properly. Before running the first command you must edit {{ic|/home/gitlab/gitlab/lib/tasks/gitlab/info.rake}}. The script cannot determine OS version; simply replace {{ic|os_name.squish!}} with {{ic|os_name &#61; "Arch Linux"}}.
+
=== Initialize Gitlab database ===
  
# sudo -u gitlab -H bundle exec rake gitlab:env:info RAILS_ENV=production
+
Start the [[Redis]] server before we create the database.
# sudo -u gitlab -H bundle exec rake gitlab:check RAILS_ENV=production
 
  
{{hc|Example output|
+
Initialize the database and activate advanced features:
System information
+
# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.3 exec rake gitlab:setup RAILS_ENV=production"
System:         Arch Linux
 
Current User:  gitlab
 
Using RVM:      no
 
Ruby Version:  1.9.3p362
 
Gem Version:    1.8.23
 
Bundler Version:1.2.3
 
Rake Version:   10.0.1
 
  
GitLab information
+
Finally run the following commands to check your installation:
Version:       4.0.0
 
Revision:      8ef7b9b
 
Directory:      /home/gitlab/gitlab
 
DB Adapter:    mysql2
 
URL:            <nowiki>http://example.com</nowiki>
 
HTTP Clone URL: <nowiki>http://example.com/some-project.git</nowiki>
 
SSH Clone URL:  git@example.com:some-project.git
 
Using LDAP:    no
 
Using Omniauth: no
 
  
Gitolite information
+
# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.3 exec rake gitlab:env:info RAILS_ENV=production"
Version:        v3.04-4-g4524f01
+
# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.3 exec rake gitlab:check RAILS_ENV=production"
Admin URI:      git@example.com:gitolite-admin
 
Admin Key:      gitlab
 
Repositories:  /home/git/repositories/
 
Hooks:          /home/git/.gitolite/hooks/
 
Git:            /usr/bin/git
 
  
 +
{{note|
 +
*The ''gitlab:env:info'' and ''gitlab:check'' commands will show a fatal error related to git. This is OK.
 +
*The ''gitlab:check'' will complain about missing initscripts. This is nothing to worry about, as [[systemd]] service files are used instead (which GitLab does not recognize).
 
}}
 
}}
  
===Server testing and resque process===
+
=== Adjust modifier bits ===
 +
(The gitlab check won't pass if the user and group ownership isn't configured properly)
  
[http://defunkt.io/resque/ Resque] is a Redis-backed library for creating background jobs, placing those jobs on multiple queues, and processing them later. For the backstory, philosophy, and history of Resque's beginnings, please see this [https://github.com/blog/542-introducing-resque blog post].
+
# chmod -R ug+rwX,o-rwx /var/lib/gitlab/repositories/
 +
# chmod -R ug-s /var/lib/gitlab/repositories
 +
# find /var/lib/gitlab/repositories/ -type d -print0 | xargs -0 chmod g+s
  
Run resque process for processing queue:
+
== Start and test GitLab ==
# sudo -u gitlab bundle exec rake environment resque:work QUEUE=* RAILS_ENV=production BACKGROUND=yes
 
  
or use Gitlab's start script:
+
Make sure [[MySQL]] or [[PostgreSQL]] and [[Redis]] are running and setup correctly.
# sudo -u gitlab ./resque.sh
 
  
{{Note|If you run this as root, {{ic|/home/gitlab/gitlab/tmp/pids/resque_worker.pid}} will be owned by root causing the resque worker not to start via init script on next boot/service restart}}
+
Then [[start]]/[[enable]] {{ic|gitlab.target}}.
  
Gitlab application can be started with the next command:
+
Now test your GitLab instance by visiting http://localhost:8080 or http://yourdomain.com, you should be prompted to create a password:
# sudo -u gitlab bundle exec rails s -e production
 
  
Open {{ic|localhost:3000}} with your favorite browser and you should see Gitlab's sign in page. In case you missed it, the default login/password are:
+
{{bc|
 +
username: root
 +
password: You'll be prompted to create one on your first visit.
 +
}}
  
login.........admin@local.host
+
See [[#Troubleshooting]] and log files inside the {{ic|/usr/share/webapps/gitlab/log/}} directory for troubleshooting.
password......5iveL!fe
 
  
Since this is a thin web server, it is only for test purposes. You may close it with {{Keypress|Ctrl+c}}. Follow instructions below to make Gitlab run with a real web server.
+
== Upgrade database on updates ==
 +
After updating the {{Pkg|gitlab}} package, it is required to upgrade the database:
 +
# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.3 exec rake db:migrate RAILS_ENV=production"
  
==Web server configuration==
+
Afterwards, restart gitlab-related services:
 +
# systemctl daemon-reload
 +
# systemctl restart gitlab-sidekiq gitlab-unicorn gitlab-workhorse gitlab-gitaly
  
 +
== Advanced Configuration ==
  
===Unicorn only===
+
=== Basic SSH ===
 +
After completing the basic installation, set up SSH access for users.  Configuration for [[Secure_Shell#OpenSSH|OpenSSH ]] is described below.  [[Secure_Shell#Other_SSH_clients_and_servers|Other SSH clients and servers ]] will require different modifications.
  
Edit {{ic|/home/gitlab/gitlab/config/unicorn.rb}} uncomment:
+
For tips on adding user SSH keys, the process is well-documented on the [https://docs.gitlab.com/ee/ssh/ GitLab] website.  You can check the administrator logs at {{ic|/var/lib/gitlab/log/gitlab-shell.log}} to confirm user SSH keys are being submitted properly.  Behind the scenes, GitLab adds these keys to its ''authorized_keys'' file in {{ic|/var/lib/gitlab/.ssh/authorized_keys}}.
  
  listen 8080 # listen to port 8080 on all TCP interfaces
+
The common method of testing keys (ex: {{ic|<nowiki>$ ssh -T git@</nowiki>''YOUR_SERVER''}}) requires a bit of extra configuration to work correctly. The user configured in {{ic|/etc/webapps/gitlab/gitlab.yml}} (default user: {{ic|gitlab}}) must be added to the server's sshd configuration file, in addition to a handful of other changes:
 +
{{hc|/etc/ssh/sshd_config|
 +
PubkeyAuthentication  yes
 +
AuthorizedKeysFile    %h/.ssh/authorized_keys
 +
}}
  
Create {{ic|/etc/rc.d/unicorn-gitlab}}.
+
After updating the configuration file, restart the ssh daemon:
<pre>
+
# systemctl restart sshd
#!/bin/bash
 
  
. /etc/rc.conf
+
Test user SSH keys (optionally add -v to see extra information):
. /etc/rc.d/functions
+
<nowiki>$ ssh -T </nowiki>'''gitlab'''@''YOUR_SERVER''
  
 +
=== Custom SSH Connection ===
 +
If you are running SSH on a non-standard port, you must change the GitLab user's SSH config:
 +
{{hc|/var/lib/gitlab/.ssh/config|2=
 +
host localhost      # Give your setup a name (here: override localhost)
 +
user gitlab        # Your remote git user
 +
port 2222          # Your port number
 +
hostname 127.0.0.1; # Your server name or IP
 +
}}
  
PID=`pidof -o %PPID /usr/bin/ruby`
+
You also need to change the corresponding options (e.g. ssh_user, ssh_host, admin_uri) in the {{ic|/etc/webapps/gitlab/gitlab.yml}} file.
case "$1" in
 
  start)
 
    stat_busy "Starting unicorn"
 
    [ -z "$PID" ] && sudo -u gitlab bash  -c  "source /home/gitlab/.bash_profile && cd /home/gitlab/gitlab/ && bundle exec unicorn_rails -c config/unicorn.rb -E production -D"
 
    if [ $? -gt 0 ]; then
 
      stat_fail
 
    else
 
      add_daemon unicorn
 
      stat_done
 
    fi
 
    ;;
 
  stop)
 
    stat_busy "Stopping unicorn"
 
    [ ! -z "$PID" ]  && kill $PID &> /dev/null
 
    if [ $? -gt 0 ]; then
 
      stat_fail
 
    else
 
      rm_daemon unicorn
 
      stat_done
 
    fi
 
    ;;
 
  restart)
 
    $0 stop
 
    sleep 1
 
    $0 start
 
    ;;
 
  *)
 
    echo "usage: $0 {start|stop|restart}"
 
esac
 
exit 0
 
</pre>
 
  
Start '''unicorn''':
+
=== HTTPS/SSL ===
  
# /etc/rc.d/unicorn-gitlab start
+
==== Change GitLab configs ====
 +
Modify {{ic|/etc/webapps/gitlab/shell.yml}} so the url to your GitLab site starts with {{ic|https://}}.
 +
Modify {{ic|/etc/webapps/gitlab/gitlab.yml}} so that {{ic|https:}} setting is set to {{ic|true}}.
  
Test it http://localhost:8080
+
See also [[Apache HTTP Server#TLS/SSL]] and [[Let’s Encrypt]].
  
Add it to DAEMONS array in /etc/rc.conf
+
==== Let's Encrypt ====
  
Redirect http port to unicorn server
+
To validate your URL, the Let's Encrypt process will try to access your gitlab server with something like {{ic|<nowiki>https://gitlab.</nowiki>''YOUR_SERVER_FQDN''/.well-known/acme-challenge/''A_LONG_ID''}}. But, due to gitlab configuration, every request to {{ic|gitlab.''YOUR_SERVER_FQDN''}} will be redirected to a proxy (gitlab-workhorse) that will not be able to deal with this URL.
  
# iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
+
To bypass this issue, you can use the Let's Encrypt webroot configuration, setting the webroot at {{ic|/srv/http/letsencrypt/}}.
  
And test again, now http://localhost
+
Additionally, force the Let's Encrypt request for gitlab to be redirected to this webroot by adding the following:
  
===Nginx and unicorn===
+
{{hc|/etc/http/conf/extra/gitlab.conf|
 +
Alias "/.well-known"  "/srv/http/letsencrypt/.well-known"
 +
RewriteCond  %{REQUEST_URI}  !/\.well-known/.*
 +
}}
  
[[pacman|Install]] {{Pkg|nginx}} from the [[official repositories]].
+
===Web server configuration===
 +
If you want to integrate Gitlab into a running web server instead of using its build-in http server Unicorn, then follow these instructions.
  
Run these commands to setup nginx:
+
===== Node.js =====
 +
You can easily set up an http proxy on port 443 to proxy traffic to the GitLab application on port 8080 using http-master for Node.js. After you have created your domain's OpenSSL keys and have gotten you CA certificate (or self signed it), then go to https://github.com/CodeCharmLtd/http-master to learn how easy it is to proxy requests to GitLab using HTTPS. http-master is built on top of [https://github.com/nodejitsu/node-http-proxy node-http-proxy].
  
# wget https://raw.github.com/gitlabhq/gitlab-recipes/master/nginx/gitlab -P /etc/nginx/sites-available/
+
==== Nginx ====
# ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab
 
  
Edit {{ic|/etc/nginx/sites-enabled/gitlab}} and change YOUR_SERVER_IP and YOUR_SERVER_FQDN to the IP address and fully-qualified domain name of the host serving Gitlab. As you can see nginx needs to access {{ic|/home/gitlab/gitlab/tmp/sockets/gitlab.socket}} socket file. You have to be able to run {{ic|sudo -u http ls /home/gitlab/gitlab/tmp/sockets/gitlab.socket}} successfully. Otherwise setup access to the directory:
+
See [[Nginx#Configuration]] for basic ''nginx'' configuration and [[Nginx#TLS/SSL]] for enabling HTTPS. The sample in this section also assumes that server blocks are managed with [[Nginx#Managing server entries]].
 
# chgrp http /home/gitlab
 
# chmod u=rwx,g=rx,o= /home/gitlab
 
  
Restart gitlab.service, resque.service and nginx.
+
Create and edit the configuration based on the following snippet. See the [https://gitlab.com/gitlab-org/gitlab-ce/tree/master/lib/support/nginx upstream GitLab repository] for more examples.
  
[http://unicorn.bogomips.org/ Unicorn] is an HTTP server for Rack applications designed to only serve fast clients on low-latency, high-bandwidth connections and take advantage of features in Unix/Unix-like kernels. First we rename the example file and then we start unicorn:
+
{{hc|/etc/nginx/servers-available/gitlab|<nowiki>
 +
upstream gitlab-workhorse {
 +
  server unix:/run/gitlab/gitlab-workhorse.socket fail_timeout=0;
 +
}
  
# cd /home/gitlab/gitlab
+
server {
# sudo -u gitlab cp config/unicorn.rb.orig config/unicorn.rb
+
  listen 80;
# sudo -u gitlab bundle exec unicorn_rails -c config/unicorn.rb -E production -D
+
  #listen 443 ssl; # uncomment to enable ssl
 +
  server_name example.com
  
===Apache and unicorn===
+
  #ssl_certificate ssl/example.com.crt;
 +
  #ssl_certificate_key ssl/example.com.key;
  
[[pacman|Install]] {{Pkg|apache}} from the [[official repositories]].
+
  location / {
 +
      # unlimited upload size in nginx (so the setting in GitLab applies)
 +
      client_max_body_size 0;
  
====Configure Unicorn====
+
      # proxy timeout should match the timeout value set in /etc/webapps/gitlab/unicorn.rb
 +
      proxy_read_timeout 60;
 +
      proxy_connect_timeout 60;
 +
      proxy_redirect off;
  
As the official installation guide instructs, copy the unicorn configuration file:
+
      proxy_set_header Host $http_host;
# sudo -u gitlab -H cp /home/gitlab/gitlab/config/unicorn.rb.example /home/gitlab/gitlab/config/unicorn.rb
+
      proxy_set_header X-Real-IP $remote_addr;
 +
      proxy_set_header X-Forwarded-Ssl on;
 +
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 +
      proxy_set_header X-Forwarded-Proto $scheme;
  
Now edit {{ic|config/unicorn.rb}} and add a listening port by uncommenting the following line:
+
      proxy_pass http://gitlab-workhorse;
listen "127.0.0.1:8080"
+
  }
  
{{Tip| You can set a custom port if you want. Just remember to also include it in Apache's virtual host. See below.}}
+
  error_page 404 /404.html;
 
+
  error_page 422 /422.html;
====Create a virtual host for Gitlab====
+
  error_page 500 /500.html;
 
+
  error_page 502 /502.html;
Create a configuration file for Gitlab’s virtual host and insert the lines below adjusted accordingly. For the ssl section see [[LAMP#SSL]]. If you do not need it, remove it. Notice that the SSL virtual host needs a specific IP instead of generic. Also if you set a custom port for Unicorn, do not forget to set it at the BalanceMember line.
+
   error_page 503 /503.html;
 
+
   location ~ ^/(404|422|500|502|503)\.html$ {
# mkdir -pv /etc/httpd/conf/vhosts/
+
    root /usr/share/webapps/gitlab/public;
 
+
    internal;
{{hc|/etc/httpd/conf/vhosts/gitlab|
+
   }
<VirtualHost *:80>
+
}
   ServerName gitlab.myserver.com
+
</nowiki>}}
   ServerAlias www.gitlab.myserver.com
 
  DocumentRoot /home/gitlab/gitlab/public
 
  ErrorLog /var/log/httpd/gitlab_error_log
 
   CustomLog /var/log/httpd/gitlab_access_log combined
 
 
 
  <Proxy balancer://unicornservers>
 
      BalancerMember http://127.0.0.1:8080
 
  </Proxy>
 
  
  <Directory /home/gitlab/gitlab/public>
+
==== Apache ====
    AllowOverride All
 
    Options -MultiViews
 
  </Directory>
 
  
  RewriteEngine on
+
Install and configure the [[Apache HTTP Server]]. You can use these [https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache upstream recipes] to get started with the configuration file for GitLab's virtual host.
  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
 
  RewriteRule ^/(.*)$ balancer://unicornservers%{REQUEST_URI} [P,QSA,L]
 
  
  ProxyPass /uploads !
+
For the SSL configuration see [[Apache HTTP Server#TLS/SSL]]. If you do not need it, remove it. Notice that the SSL virtual host needs a specific IP instead of generic. Also if you set a custom port for Unicorn, do not forget to set it at the {{ic|BalanceMember}} line.
  ProxyPass / balancer://unicornservers/
 
  ProxyPassReverse / balancer://unicornservers/
 
  ProxyPreserveHost on
 
  
  <Proxy *>
+
=== Gitlab-workhorse ===
      Order deny,allow
 
      Allow from all
 
  </Proxy>
 
</VirtualHost>
 
  
<VirtualHost MY_IP:443>
+
{{Remove|The {{Pkg|gitlab-workhorse}} component is nowadays required. The default configuration is sufficient for common cases so this section can be removed.}}
  ServerName gitlab.myserver.com
 
  ServerAlias www.gitlab.myserver.com
 
  DocumentRoot /home/gitlab/gitlab/public
 
  ErrorLog /var/log/httpd/gitlab_error_log
 
  CustomLog /var/log/httpd/gitlab_access_log combined
 
  
  <Proxy balancer://unicornservers>
+
{{Expansion|This section needs configuration instructions.}}
      BalancerMember http://127.0.0.1:8080
 
  </Proxy>
 
  
  <Directory /home/gitlab/gitlab/public>
+
Since 8.0 GitLab uses separate HTTP server {{Pkg|gitlab-workhorse}} for large HTTP requests like Git push/pull. If you want to use this instead of SSH, install the {{Pkg|gitlab-workhorse}} package, enable {{ic|gitlab-workhorse.service}} and configure web server for this. {{Pkg|gitlab-workhorse}} should now be preferred over {{ic|gitlab-unicorn}} according to the GitLab team: https://gitlab.com/gitlab-org/gitlab-ce/issues/22528#note_16036216
    AllowOverride All
 
    Options -MultiViews
 
  </Directory>
 
  
  RewriteEngine on
+
{{Note|Unicorn is still needed so don't disable or stop {{ic|gitlab-unicorn.service}}.}}
  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
 
  RewriteRule ^/(.*)$ balancer://unicornservers%{REQUEST_URI} [P,QSA,L]
 
  
  ProxyPass /uploads !
+
By default {{Pkg|gitlab-workhorse}} listens on {{ic|/run/gitlab/gitlab-workhorse.socket}}. You can [[edit]] {{ic|gitlab-workhorse.service}} and change the parameter {{ic|-listenAddr}} to make it listen on an address, for example {{ic|-listenAddr 127.0.0.1:8181}}. If listening on an address you also need to set the network type to {{ic|-listenNetwork tcp}}
  ProxyPass / balancer://unicornservers/
 
  ProxyPassReverse / balancer://unicornservers/
 
  ProxyPreserveHost on
 
  
  <Proxy *>
+
When using nginx remember to edit your nginx configuration file. To switch from gitlab-unicorn to gitlab-workhorse edit the two following settings accordingly
      Order deny,allow
+
{{hc|/etc/nginx/servers-available/gitlab|2=
      Allow from all
+
upstream gitlab {
   </Proxy>
+
   server unix:/run/gitlab/gitlab-workhorse.socket fail_timeout=0;
 +
}
  
  SSLEngine on
+
...
  SSLCertificateFile /home/gitlab/gitlab/ssl.cert
+
     
   SSLCertificateKeyFile /home/gitlab/gitlab/ssl.key
+
      proxy_pass http://unix:/run/gitlab/gitlab-workhorse.socket;
</VirtualHost>
+
  
 +
}
 
}}
 
}}
  
====Enable host and start unicorn====
+
==Useful Tips==
  
Enable your Gitlab virtual host and reload [[Apache]]:
+
===Hidden options===
{{hc|/etc/httpd/conf/httpd.conf|Include conf/vhosts/gitlab}}
+
Go to Gitlab's home directory:
 
+
# cd /usr/share/webapps/gitlab
Finally start unicorn:
 
 
 
# cd /home/gitlab/gitlab
 
# sudo -u gitlab bundle exec unicorn_rails -c config/unicorn.rb -E production -D
 
 
 
==SystemD support==
 
 
 
Note that you don't need the systemd units to launch shell scripts as suggested by the gitlab authors. Just make sure the ExecStart line points to the full path of the **bundle** executable.
 
 
 
Create:
 
{{hc|/etc/systemd/system/gitlab.service|<nowiki>
 
[Unit]
 
Description=Gitlab Unicorn Rails server
 
  
[Service]
+
and run:
Type=simple
+
{{hc|<nowiki># rake -T | grep gitlab</nowiki>|<nowiki>
SyslogIdentifier=gl-unicorn
+
rake gitlab:app:check                        # GITLAB | Check the configuration of the GitLab Rails app
User=gitlab
+
rake gitlab:backup:create                    # GITLAB | Create a backup of the GitLab system
PIDFile=/home/gitlab/gitlab/tmp/pids/unicorn.pid
+
rake gitlab:backup:restore                    # GITLAB | Restore a previously created backup
WorkingDirectory=/home/gitlab/gitlab
+
rake gitlab:check                            # GITLAB | Check the configuration of GitLab and its environment
TimeoutStartSec=600
+
rake gitlab:cleanup:block_removed_ldap_users  # GITLAB | Cleanup | Block users that have been removed in LDAP
 
+
rake gitlab:cleanup:dirs                      # GITLAB | Cleanup | Clean namespaces
ExecStart=/home/gitlab/bin/bundle exec unicorn_rails -c /home/gitlab/gitlab/config/unicorn.rb -E production -D
+
rake gitlab:cleanup:repos                    # GITLAB | Cleanup | Clean repositories
ExecReload=/bin/kill -HUP $MAINPID
+
rake gitlab:env:check                        # GITLAB | Check the configuration of the environment
ExecStop=/bin/kill -QUIT $MAINPID
+
rake gitlab:env:info                          # GITLAB | Show information about GitLab and its environment
 
+
rake gitlab:generate_docs                    # GITLAB | Generate sdocs for project
[Install]
+
rake gitlab:gitlab_shell:check                # GITLAB | Check the configuration of GitLab Shell
WantedBy=multi-user.target
+
rake gitlab:import:all_users_to_all_groups    # GITLAB | Add all users to all groups (admin users are added as owners)
 +
rake gitlab:import:all_users_to_all_projects  # GITLAB | Add all users to all projects (admin users are added as masters)
 +
rake gitlab:import:repos                      # GITLAB | Import bare repositories from gitlab_shell -> repos_path into GitLab project instance
 +
rake gitlab:import:user_to_groups[email]      # GITLAB | Add a specific user to all groups (as a developer)
 +
rake gitlab:import:user_to_projects[email]    # GITLAB | Add a specific user to all projects (as a developer)
 +
rake gitlab:satellites:create                # GITLAB | Create satellite repos
 +
rake gitlab:setup                            # GITLAB | Setup production application
 +
rake gitlab:shell:build_missing_projects      # GITLAB | Build missing projects
 +
rake gitlab:shell:install[tag,repo]          # GITLAB | Install or upgrade gitlab-shell
 +
rake gitlab:shell:setup                      # GITLAB | Setup gitlab-shell
 +
rake gitlab:sidekiq:check                    # GITLAB | Check the configuration of Sidekiq
 +
rake gitlab:test                              # GITLAB | Run all tests
 +
rake gitlab:web_hook:add                      # GITLAB | Adds a web hook to the projects
 +
rake gitlab:web_hook:list                    # GITLAB | List web hooks
 +
rake gitlab:web_hook:rm                      # GITLAB | Remove a web hook from the projects
 +
rake setup                                    # GITLAB | Setup gitlab db
 
</nowiki>}}
 
</nowiki>}}
  
{{hc|/etc/systemd/system/resque.service|<nowiki>
+
===Backup and restore===
  
[Unit]
+
Create a backup of the gitlab system:
Description=Gitlab Resque
+
# sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:create
  
[Service]
+
Restore the previously created backup file {{ic|/home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740_gitlab_backup.tar}}:
Type=simple
+
# sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:restore BACKUP=/home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740
SyslogIdentifier=gl-resque
 
User=gitlab
 
PIDFile=/home/gitlab/gitlab/tmp/pids/resque_worker.pid
 
WorkingDirectory=/home/gitlab/gitlab
 
TimeoutStartSec=600
 
  
ExecStart=/home/gitlab/bin/bundle exec rake environment resque:work QUEUE=post_receive,mailer,system_hook RAILS_ENV=production PIDFILE=tmp/pids/resque_worker.pid
+
{{Note| Backup folder is set in {{ic|config/gitlab.yml}}. GitLab backup and restore is documented [https://github.com/gitlabhq/gitlabhq/blob/master/doc/raketasks/backup_restore.md here].}}
ExecReload=/bin/kill -HUP $MAINPID
 
ExecStop=/bin/kill -QUIT $MAINPID
 
  
[Install]
+
===Sending mails from Gitlab via SMTP===
WantedBy=multi-user.target
 
</nowiki>
 
}}
 
  
Also see: https://github.com/gitlabhq/gitlab-recipes/issues/14
+
You might want to use a gmail (or other mail service) to send mails from your gitlab server. This avoids the need to install a mail daemon on the gitlab server.
  
==Useful Tips==
+
Adjust {{ic|smtp_settings.rb}} according to your mail server settings:
===Hook into /var===
 
  sudo mkdir -m700 /var/log/gitlab /var/tmp/gitlab
 
  sudo chown gitlab:gitlab /var/log/gitlab /var/tmp/gitlab
 
  sudo -u gitlab -i
 
  cd ~/gitlab
 
  d=log; mv $d/* /var/$d/gitlab; rm -f $d/.gitkeep; rm -r $d && ln -s /var/$d/gitlab $d
 
  d=tmp; mv $d/* /var/$d/gitlab; rm -f $d/.gitkeep; rm -r $d && ln -s /var/$d/gitlab $d
 
  
===Hidden options===
+
{{hc|/usr/share/webapps/gitlab/config/initializers/smtp_settings.rb|<nowiki>
Go to Gitlab's home directory
+
if Rails.env.production?
# cd /home/gitlab/gitlab
+
  Gitlab::Application.config.action_mailer.delivery_method = :smtp
  
and run
+
  ActionMailer::Base.delivery_method = :smtp
# rake -T | grep gitlab
+
  ActionMailer::Base.smtp_settings = {
 +
    address:              'smtp.gmail.com',
 +
    port:                587,
 +
    domain:              'gmail.com',
 +
    user_name:            'username@gmail.com',
 +
    password:            'application password',
 +
    authentication:      'plain',
 +
    enable_starttls_auto: true
 +
  }
 +
end</nowiki>}}
  
These are the options so far:
+
Gmail will reject mails received this way (and send you a mail that it did). You will need to disable secure authentication (follow the link in the rejection mail) to work around this. The more secure approach is to enable two-factor authentication for username@gmail.com and to set up an application password for this configuration file.
rake gitlab:app:backup_create      # GITLAB | Create a backup of the gitlab system
 
rake gitlab:app:backup_restore    # GITLAB | Restore a previously created backup
 
rake gitlab:app:enable_automerge  # GITLAB | Enable auto merge
 
rake gitlab:app:setup              # GITLAB | Setup production application
 
rake gitlab:app:status            # GITLAB | Check gitlab installation status
 
rake gitlab:gitolite:update_hooks  # GITLAB | Rewrite hooks for repos
 
rake gitlab:gitolite:update_keys  # GITLAB | Rebuild each key at gitolite config
 
rake gitlab:gitolite:update_repos  # GITLAB | Rebuild each project at gitolite config
 
rake gitlab:test                  # GITLAB | Run both cucumber & rspec
 
  
===Backup and restore===
+
==Troubleshooting==
  
Create a backup of the gitlab system:
+
=== HTTPS is not green (gravatar not using https) ===
# sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:create
+
Redis caches gravatar images, so if you have visited your GitLab with http, then enabled https, gravatar will load up the non-secure images. You can clear the cache by doing
  
Restore the previously created backup file {{ic|/home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740_gitlab_backup.tar}}:
+
cd /usr/share/webapps/gitlab
  # sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:restore BACKUP=/home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740
+
  RAILS_ENV=production bundle-2.3 exec rake cache:clear
  
{{Note| Backup folder is set in {{ic|conig.yml}}. Check [[#Application_specific_settings]].}}
+
as the gitlab user.
  
===Update Gitlab===
+
=== Errors after updating ===
 +
After updating the package from the AUR, the database migrations and asset updates will sometimes fail. These steps may resolve the issue, if a simple reboot does not.
  
When a new version is out follow the instructions at [https://github.com/gitlabhq/gitlabhq/wiki Github wiki]. A new release is out every 22nd of a month.
+
First, move to the gitlab installation directory.
 +
# cd /usr/share/webapps/gitlab
  
===Migrate from sqlite to mysql===
+
If every gitlab page gives a 500 error, then the database migrations and the assets are probably stale. If not, skip this step.
 +
# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.3 exec rake db:migrate RAILS_ENV=production"
  
Get latest code as described in [[#Update_Gitlab]].
+
If gitlab is constantly waiting for the deployment to finish, then the assets have probably not been recompiled.
Save data.
+
  # su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.3 exec rake gitlab:assets:clean gitlab:assets:compile cache:clear RAILS_ENV=production"
  # cd /home/gitlab/gitlab
 
# sudo -u gitlab bundle exec rake db:data:dump RAILS_ENV=production
 
  
Follow [[#Mysql]] instructions and then setup the database.
+
Finally, restart the gitlab services and test your site.
  # sudo -u gitlab bundle exec rake db:setup RAILS_ENV=production
+
  # systemctl restart gitlab-unicorn gitlab-sidekiq gitlab-workhorse
  
Finally restore old data.
+
=== Gitlab-Unicorn cannot access non-default repositories directory ===
# sudo -u gitlab bundle exec rake db:data:load RAILS_ENV=production
 
 
 
==Troubleshooting==
 
  
Sometimes things may not work as expected. Be sure to visit the [https://github.com/gitlabhq/gitlab-public-wiki/wiki/Trouble-Shooting-Guide Trouble Shooting Guide].
+
If a custom repository storage directory is set in {{ic|/home}}, disable the {{ic|1=ProtectHome=true}} parameter in the {{ic|gitlab-unicorn.service}} (see [[Systemd#Drop-in files]] and the [https://forum.gitlab.com/t/cannot-change-repositores-location/9634/2 relevant forum thread on gitlab.com]).
  
 
==See also==
 
==See also==
*[https://github.com/gitlabhq/gitlabhq/blob/stable/doc/install/installation.md Official Documentation]
+
*[https://docs.gitlab.com/ce/install/installation.html Official installation documentation]
*[https://github.com/gitlabhq/gitlab-recipes Gitlab recipes for setup on different platforms, update etc.]
+
*[https://gitlab.com/gitlab-org/gitlab-recipes GitLab recipes with further documentation on running it with several web servers]
*[http://www.andmarios.com/en/2012/06/gitlab-on-an-ubuntu-10-04-server-with-apache/ GitLab on an Ubuntu 10.04 server with Apache]
+
*[https://gitlab.com/gitlab-org/gitlab-ce GitLab source code]
*[http://blog.phusion.nl/2012/04/21/tutorial-setting-up-gitlab-on-debian-6/ Setting up gitlab on Debian 6]
 
*[http://howto.basjes.nl/linux/installing-gitlab-on-centos-6 Installing Gitlab on CentOS 6]
 
*[https://gist.github.com/2440768 Gist: Install Gitlab on Debian Squeeze]
 
*[https://gist.github.com/3305554 Gist: Install Gitlab on Archlinux]
 

Latest revision as of 08:59, 6 June 2018

From GitLab's homepage:

GitLab offers git repository management, code reviews, issue tracking, activity feeds and wikis. Enterprises install GitLab on-premise and connect it with LDAP and Active Directory servers for secure authentication and authorization. A single GitLab server can handle more than 25,000 users but it is also possible to create a high availability setup with multiple active servers.

An example live version can be found at GitLab.com.

Installation

Note: This article covers installing and configuring GitLab without HTTPS at first. If needed, see #Advanced Configuration to set up SSL.

GitLab requires Redis and a database backend. If you plan to run it on the same machine, first install either MySQL or PostgreSQL.

Install the gitlab package.

In order to receive mail notifications, a mail server must be installed and configured. See Category:Mail server for details.

Configuration

Preliminary Notes

GitLab is composed of multiple components, see the architecture overview page.

The gitlab package installs GitLab's files in a manner that more closely follow standard Linux conventions:

Description GitLab's Official gitlab
Configuration File GitShell /home/git/gitlab-shell/config.yml /etc/webapps/gitlab-shell/config.yml
Configuration File GitLab /home/git/gitlab/config/gitlab.yml /etc/webapps/gitlab/gitlab.yml
User (Home Directory) git (/home/git) gitlab (/var/lib/gitlab)
Tip: If you are familiar with the Arch Build System you can edit the PKGBUILD and relevant files to change gitlab's home directory to a place of your liking.

GitLab

Edit /etc/webapps/gitlab/gitlab.yml and setup at least the following parameters:

Note: The hostname and port are used for the git clone http://hostname:port as example.

Hostname: In the gitlab: section set host: - replacing localhost to yourdomain.com (note: no 'http://' or trailing slash) - into your fully qualified domain name.

Port: port: can be confusing. This is not the port that the gitlab server (unicorn) runs on; it's the port that users will initially access through in their browser. Basically, if you intend for users to visit 'yourdomain.com' in their browser, without appending a port number to the domain name, leave port: as 80. If you intend your users to type something like 'yourdomain.com:3425' into their browsers, then you'd set port: to 3425. You will also have to configure your webserver to listen on that port.

Timezone (optional): The time_zone: parameter is optional, but may be useful to force the zone of GitLab applications.

Finally set the correct permissions to the uploads directory:

# chmod 700 /var/lib/gitlab/uploads

Custom port for Unicorn

GitLab Unicorn is the main component which processes most of the user requests. By default, it listens on the 127.0.0.1:8080 address which can be changed in the /etc/webapps/gitlab/unicorn.rb file:

/etc/webapps/gitlab/unicorn.rb
listen "/run/gitlab/gitlab.socket", :backlog => 1024
listen "127.0.0.1:8080", :tcp_nopush => true

If the Unicorn address is changed, the configuration of other components which communicate with Unicorn have to be updated as well:

  • For GitLab Shell, update the gitlab_url variable in /etc/webapps/gitlab-shell/config.yml.
Tip: According to the comment in the config file, UNIX socket path can be specified with URL-escaped slashes (i.e. http+unix://%2Frun%2Fgitlab%2Fgitlab.socket for the default /run/gitlab/gitlab.socket). Additionally, un-escaped slashes can be used to specify the relative URL root (e.g. /gitlab).
  • For GitLab Workhorse, edit the gitlab-workhorse.service and update the -authBackend option.

Secret strings

Make sure that the files /etc/webapps/gitlab/secret and /etc/webapps/gitlab-shell/secret files contain something. Their content should be kept secret because they are used for the generation of authentication tokens etc.

For example, random strings can be generated with the following commands:

# hexdump -v -n 64 -e '1/1 "%02x"' /dev/urandom > /etc/webapps/gitlab/secret
# chown root:gitlab /etc/webapps/gitlab/secret
# chmod 640 /etc/webapps/gitlab/secret
# hexdump -v -n 64 -e '1/1 "%02x"' /dev/urandom > /etc/webapps/gitlab-shell/secret
# chown root:gitlab /etc/webapps/gitlab-shell/secret
# chmod 640 /etc/webapps/gitlab-shell/secret

Redis

In order to provide sufficient performance you will need a cache database. Install and configure a Redis instance, being careful to the section dedicated to listening via a socket.

  • Add the gitlab user to the redis group.
  • Update the configuration files:
/etc/webapps/gitlab/resque.yml
development: unix:/run/redis/redis.sock
test: unix:/run/redis/redis.sock
production: unix:/run/redis/redis.sock
/etc/webapps/gitlab-shell/config.yml
# Redis settings used for pushing commit notices to gitlab
redis:
  bin: /usr/bin/redis-cli
  host: 127.0.0.1
  port: 6379
  # pass: redispass # Allows you to specify the password for Redis
  database: 5 # Use different database, default up to 16
  socket: /run/redis/redis.sock # uncomment this line
  namespace: resque:gitlab

Database backend

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: GitLab recommends to use PostgreSQL. (Discuss in Talk:GitLab#)

A Database backend will be required before Gitlab can be run. Currently GitLab supports MariaDB and PostgreSQL. By default, GitLab assumes you will use MySQL. Extra work is needed if you plan to use PostgreSQL.

MariaDB

To set up MySQL (MariaDB) you need to create a database called gitlabhq_production along with a user (default: gitlab) who has full privileges to the database:

$ mysql -u root -p
mysql> CREATE DATABASE `gitlabhq_production` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;
mysql> CREATE USER 'gitlab'@'localhost' IDENTIFIED BY 'password';
mysql> GRANT ALL ON `gitlabhq_production`.* TO 'gitlab'@'localhost';
mysql> \q

Try connecting to the new database with the new user:

$ mysql -u gitlab -p -D gitlabhq_production

Copy the MySQL template file before configuring it:

# cp /usr/share/doc/gitlab/database.yml.mysql /etc/webapps/gitlab/database.yml

Next you will need to open /etc/webapps/gitlab/database.yml and set username: and password: for the gitlabhq_production:

/etc/webapps/gitlab/database.yml
#
# PRODUCTION
#
production:
  adapter: mysql2
  encoding: utf8
  collation: utf8_general_ci
  reconnect: false
  database: gitlabhq_production
  pool: 10
  username: username
  password: "password"
  # host: localhost
  # socket: /run/mysqld/mysqld.sock # If running MariaDB as socket
...

It should not be set as world readable, e.g. only processes running under the gitlab user should have read/write access:

# chmod 600 /etc/webapps/gitlab/database.yml
# chown gitlab:gitlab /etc/webapps/gitlab/database.yml

For more info and other ways to create/manage MySQL databases, see the MariaDB documentation and the GitLab official (generic) install guide.

PostgreSQL

Login to PostgreSQL and create the gitlabhq_production database with along with its user. Remember to change your_username_here and your_password_here to the real values:

# psql -d template1
template1=# CREATE USER your_username_here WITH PASSWORD 'your_password_here';
template1=# ALTER USER your_username_here SUPERUSER;
template1=# CREATE DATABASE gitlabhq_production OWNER your_username_here;
template1=# \q
Note: The reason for creating the user as a superuser is that GitLab is trying to be "smart" and install extensions (not just create them in its own userspace). And this is only allowed by superusers in Postgresql.

Try connecting to the new database with the new user to verify it works:

# psql -d gitlabhq_production

Copy the PostgreSQL template file before configuring it (overwriting the default MySQL configuration file):

# cp /usr/share/doc/gitlab/database.yml.postgresql /etc/webapps/gitlab/database.yml

Open the new /etc/webapps/gitlab/database.yml and set the values for username: and password:. For example:

/etc/webapps/gitlab/database.yml
#
# PRODUCTION
#
production:
  adapter: postgresql
  encoding: unicode
  database: gitlabhq_production
  pool: 10
  username: your_username_here
  password: "your_password_here"
  # host: localhost
  # port: 5432
  # socket: /tmp/postgresql.sock
...

For our purposes (unless you know what you are doing), you do not need to worry about configuring the other databases listed in /etc/webapps/gitlab/database.yml. We only need to set up the production database to get GitLab working.

Firewall

If you want to give direct access to your Gitlab installation through an iptables firewall, you may need to adjust the port and the network address:

# iptables -A tcp_inbound -p TCP -s 192.168.1.0/24 --destination-port 80 -j ACCEPT

To enable API-access:

# iptables -A tcp_inbound -p TCP -s 192.168.1.0/24 --destination-port 8080 -j ACCEPT

If you are behind a router, do not forget to forward this port to the running GitLab server host, if you want to allow WAN-access.

Initialize Gitlab database

Start the Redis server before we create the database.

Initialize the database and activate advanced features:

# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.3 exec rake gitlab:setup RAILS_ENV=production"

Finally run the following commands to check your installation:

# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.3 exec rake gitlab:env:info RAILS_ENV=production"
# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.3 exec rake gitlab:check RAILS_ENV=production"
Note:
  • The gitlab:env:info and gitlab:check commands will show a fatal error related to git. This is OK.
  • The gitlab:check will complain about missing initscripts. This is nothing to worry about, as systemd service files are used instead (which GitLab does not recognize).

Adjust modifier bits

(The gitlab check won't pass if the user and group ownership isn't configured properly)

# chmod -R ug+rwX,o-rwx /var/lib/gitlab/repositories/
# chmod -R ug-s /var/lib/gitlab/repositories
# find /var/lib/gitlab/repositories/ -type d -print0 | xargs -0 chmod g+s

Start and test GitLab

Make sure MySQL or PostgreSQL and Redis are running and setup correctly.

Then start/enable gitlab.target.

Now test your GitLab instance by visiting http://localhost:8080 or http://yourdomain.com, you should be prompted to create a password:

username: root
password: You'll be prompted to create one on your first visit.

See #Troubleshooting and log files inside the /usr/share/webapps/gitlab/log/ directory for troubleshooting.

Upgrade database on updates

After updating the gitlab package, it is required to upgrade the database:

# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.3 exec rake db:migrate RAILS_ENV=production"

Afterwards, restart gitlab-related services:

# systemctl daemon-reload
# systemctl restart gitlab-sidekiq gitlab-unicorn gitlab-workhorse gitlab-gitaly

Advanced Configuration

Basic SSH

After completing the basic installation, set up SSH access for users. Configuration for OpenSSH is described below. Other SSH clients and servers will require different modifications.

For tips on adding user SSH keys, the process is well-documented on the GitLab website. You can check the administrator logs at /var/lib/gitlab/log/gitlab-shell.log to confirm user SSH keys are being submitted properly. Behind the scenes, GitLab adds these keys to its authorized_keys file in /var/lib/gitlab/.ssh/authorized_keys.

The common method of testing keys (ex: $ ssh -T git@YOUR_SERVER) requires a bit of extra configuration to work correctly. The user configured in /etc/webapps/gitlab/gitlab.yml (default user: gitlab) must be added to the server's sshd configuration file, in addition to a handful of other changes:

/etc/ssh/sshd_config
PubkeyAuthentication   yes
AuthorizedKeysFile     %h/.ssh/authorized_keys

After updating the configuration file, restart the ssh daemon:

# systemctl restart sshd

Test user SSH keys (optionally add -v to see extra information):

$ ssh -T gitlab@YOUR_SERVER

Custom SSH Connection

If you are running SSH on a non-standard port, you must change the GitLab user's SSH config:

/var/lib/gitlab/.ssh/config
host localhost      # Give your setup a name (here: override localhost)
user gitlab         # Your remote git user
port 2222           # Your port number
hostname 127.0.0.1; # Your server name or IP

You also need to change the corresponding options (e.g. ssh_user, ssh_host, admin_uri) in the /etc/webapps/gitlab/gitlab.yml file.

HTTPS/SSL

Change GitLab configs

Modify /etc/webapps/gitlab/shell.yml so the url to your GitLab site starts with https://. Modify /etc/webapps/gitlab/gitlab.yml so that https: setting is set to true.

See also Apache HTTP Server#TLS/SSL and Let’s Encrypt.

Let's Encrypt

To validate your URL, the Let's Encrypt process will try to access your gitlab server with something like https://gitlab.YOUR_SERVER_FQDN/.well-known/acme-challenge/A_LONG_ID. But, due to gitlab configuration, every request to gitlab.YOUR_SERVER_FQDN will be redirected to a proxy (gitlab-workhorse) that will not be able to deal with this URL.

To bypass this issue, you can use the Let's Encrypt webroot configuration, setting the webroot at /srv/http/letsencrypt/.

Additionally, force the Let's Encrypt request for gitlab to be redirected to this webroot by adding the following:

/etc/http/conf/extra/gitlab.conf
Alias "/.well-known"  "/srv/http/letsencrypt/.well-known"
RewriteCond   %{REQUEST_URI}  !/\.well-known/.*

Web server configuration

If you want to integrate Gitlab into a running web server instead of using its build-in http server Unicorn, then follow these instructions.

Node.js

You can easily set up an http proxy on port 443 to proxy traffic to the GitLab application on port 8080 using http-master for Node.js. After you have created your domain's OpenSSL keys and have gotten you CA certificate (or self signed it), then go to https://github.com/CodeCharmLtd/http-master to learn how easy it is to proxy requests to GitLab using HTTPS. http-master is built on top of node-http-proxy.

Nginx

See Nginx#Configuration for basic nginx configuration and Nginx#TLS/SSL for enabling HTTPS. The sample in this section also assumes that server blocks are managed with Nginx#Managing server entries.

Create and edit the configuration based on the following snippet. See the upstream GitLab repository for more examples.

/etc/nginx/servers-available/gitlab
upstream gitlab-workhorse {
  server unix:/run/gitlab/gitlab-workhorse.socket fail_timeout=0;
}

server {
  listen 80;
  #listen 443 ssl; # uncomment to enable ssl
  server_name example.com

  #ssl_certificate ssl/example.com.crt;
  #ssl_certificate_key ssl/example.com.key;

  location / {
      # unlimited upload size in nginx (so the setting in GitLab applies)
      client_max_body_size 0;

      # proxy timeout should match the timeout value set in /etc/webapps/gitlab/unicorn.rb
      proxy_read_timeout 60;
      proxy_connect_timeout 60;
      proxy_redirect off;

      proxy_set_header Host $http_host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-Ssl on;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;

      proxy_pass http://gitlab-workhorse;
  }

  error_page 404 /404.html;
  error_page 422 /422.html;
  error_page 500 /500.html;
  error_page 502 /502.html;
  error_page 503 /503.html;
  location ~ ^/(404|422|500|502|503)\.html$ {
    root /usr/share/webapps/gitlab/public;
    internal;
  }
}

Apache

Install and configure the Apache HTTP Server. You can use these upstream recipes to get started with the configuration file for GitLab's virtual host.

For the SSL configuration see Apache HTTP Server#TLS/SSL. If you do not need it, remove it. Notice that the SSL virtual host needs a specific IP instead of generic. Also if you set a custom port for Unicorn, do not forget to set it at the BalanceMember line.

Gitlab-workhorse

Tango-edit-cut.pngThis section is being considered for removal.Tango-edit-cut.png

Reason: The gitlab-workhorse component is nowadays required. The default configuration is sufficient for common cases so this section can be removed. (Discuss in Talk:GitLab#)

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: This section needs configuration instructions. (Discuss in Talk:GitLab#)

Since 8.0 GitLab uses separate HTTP server gitlab-workhorse for large HTTP requests like Git push/pull. If you want to use this instead of SSH, install the gitlab-workhorse package, enable gitlab-workhorse.service and configure web server for this. gitlab-workhorse should now be preferred over gitlab-unicorn according to the GitLab team: https://gitlab.com/gitlab-org/gitlab-ce/issues/22528#note_16036216

Note: Unicorn is still needed so don't disable or stop gitlab-unicorn.service.

By default gitlab-workhorse listens on /run/gitlab/gitlab-workhorse.socket. You can edit gitlab-workhorse.service and change the parameter -listenAddr to make it listen on an address, for example -listenAddr 127.0.0.1:8181. If listening on an address you also need to set the network type to -listenNetwork tcp

When using nginx remember to edit your nginx configuration file. To switch from gitlab-unicorn to gitlab-workhorse edit the two following settings accordingly

/etc/nginx/servers-available/gitlab
upstream gitlab {
   server unix:/run/gitlab/gitlab-workhorse.socket fail_timeout=0;
}

...
      
      proxy_pass http://unix:/run/gitlab/gitlab-workhorse.socket;
  }  
}

Useful Tips

Hidden options

Go to Gitlab's home directory:

# cd /usr/share/webapps/gitlab

and run:

# rake -T | grep gitlab
rake gitlab:app:check                         # GITLAB | Check the configuration of the GitLab Rails app
rake gitlab:backup:create                     # GITLAB | Create a backup of the GitLab system
rake gitlab:backup:restore                    # GITLAB | Restore a previously created backup
rake gitlab:check                             # GITLAB | Check the configuration of GitLab and its environment
rake gitlab:cleanup:block_removed_ldap_users  # GITLAB | Cleanup | Block users that have been removed in LDAP
rake gitlab:cleanup:dirs                      # GITLAB | Cleanup | Clean namespaces
rake gitlab:cleanup:repos                     # GITLAB | Cleanup | Clean repositories
rake gitlab:env:check                         # GITLAB | Check the configuration of the environment
rake gitlab:env:info                          # GITLAB | Show information about GitLab and its environment
rake gitlab:generate_docs                     # GITLAB | Generate sdocs for project
rake gitlab:gitlab_shell:check                # GITLAB | Check the configuration of GitLab Shell
rake gitlab:import:all_users_to_all_groups    # GITLAB | Add all users to all groups (admin users are added as owners)
rake gitlab:import:all_users_to_all_projects  # GITLAB | Add all users to all projects (admin users are added as masters)
rake gitlab:import:repos                      # GITLAB | Import bare repositories from gitlab_shell -> repos_path into GitLab project instance
rake gitlab:import:user_to_groups[email]      # GITLAB | Add a specific user to all groups (as a developer)
rake gitlab:import:user_to_projects[email]    # GITLAB | Add a specific user to all projects (as a developer)
rake gitlab:satellites:create                 # GITLAB | Create satellite repos
rake gitlab:setup                             # GITLAB | Setup production application
rake gitlab:shell:build_missing_projects      # GITLAB | Build missing projects
rake gitlab:shell:install[tag,repo]           # GITLAB | Install or upgrade gitlab-shell
rake gitlab:shell:setup                       # GITLAB | Setup gitlab-shell
rake gitlab:sidekiq:check                     # GITLAB | Check the configuration of Sidekiq
rake gitlab:test                              # GITLAB | Run all tests
rake gitlab:web_hook:add                      # GITLAB | Adds a web hook to the projects
rake gitlab:web_hook:list                     # GITLAB | List web hooks
rake gitlab:web_hook:rm                       # GITLAB | Remove a web hook from the projects
rake setup                                    # GITLAB | Setup gitlab db

Backup and restore

Create a backup of the gitlab system:

# sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:create

Restore the previously created backup file /home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740_gitlab_backup.tar:

# sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:restore BACKUP=/home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740
Note: Backup folder is set in config/gitlab.yml. GitLab backup and restore is documented here.

Sending mails from Gitlab via SMTP

You might want to use a gmail (or other mail service) to send mails from your gitlab server. This avoids the need to install a mail daemon on the gitlab server.

Adjust smtp_settings.rb according to your mail server settings:

/usr/share/webapps/gitlab/config/initializers/smtp_settings.rb
if Rails.env.production?
  Gitlab::Application.config.action_mailer.delivery_method = :smtp

  ActionMailer::Base.delivery_method = :smtp
  ActionMailer::Base.smtp_settings = {
    address:              'smtp.gmail.com',
    port:                 587,
    domain:               'gmail.com',
    user_name:            'username@gmail.com',
    password:             'application password',
    authentication:       'plain',
    enable_starttls_auto: true
  }
end

Gmail will reject mails received this way (and send you a mail that it did). You will need to disable secure authentication (follow the link in the rejection mail) to work around this. The more secure approach is to enable two-factor authentication for username@gmail.com and to set up an application password for this configuration file.

Troubleshooting

HTTPS is not green (gravatar not using https)

Redis caches gravatar images, so if you have visited your GitLab with http, then enabled https, gravatar will load up the non-secure images. You can clear the cache by doing

cd /usr/share/webapps/gitlab
RAILS_ENV=production bundle-2.3 exec rake cache:clear

as the gitlab user.

Errors after updating

After updating the package from the AUR, the database migrations and asset updates will sometimes fail. These steps may resolve the issue, if a simple reboot does not.

First, move to the gitlab installation directory.

# cd /usr/share/webapps/gitlab

If every gitlab page gives a 500 error, then the database migrations and the assets are probably stale. If not, skip this step.

# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.3 exec rake db:migrate RAILS_ENV=production"

If gitlab is constantly waiting for the deployment to finish, then the assets have probably not been recompiled.

# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.3 exec rake gitlab:assets:clean gitlab:assets:compile cache:clear RAILS_ENV=production"

Finally, restart the gitlab services and test your site.

# systemctl restart gitlab-unicorn gitlab-sidekiq gitlab-workhorse

Gitlab-Unicorn cannot access non-default repositories directory

If a custom repository storage directory is set in /home, disable the ProtectHome=true parameter in the gitlab-unicorn.service (see Systemd#Drop-in files and the relevant forum thread on gitlab.com).

See also