Difference between revisions of "GitLab"

From ArchWiki
Jump to navigation Jump to search
m (Changed apache.conf.example path)
(Undo revision 584498 by TheSmiley1 (talk) - gitlab's docker images are not based on Arch Linux, so this page does not apply to that setup at all (and of course there are more installation methods))
Tag: Undo
 
(161 intermediate revisions by 40 users not shown)
Line 1: Line 1:
[[Category:Version Control System]]
+
[[Category:Git web interfaces]]
 
[[ja:Gitlab]]
 
[[ja:Gitlab]]
 +
[[zh-hans:Gitlab]]
 
{{Related articles start}}
 
{{Related articles start}}
 
{{Related|Gitolite}}
 
{{Related|Gitolite}}
Line 6: Line 7:
 
{{Related articles end}}
 
{{Related articles end}}
  
{{Accuracy|Commands are incomplete/incorrect, reported upgrade issues}}
+
From [https://about.gitlab.com/ GitLab's homepage]:
 
 
From [https://about.gitlab.com/ 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.
 
: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.
Line 15: Line 14:
  
 
== Installation ==
 
== Installation ==
{{Note|If you want to use RVM refer to the article [[#Running GitLab with rvm]] before starting with the installation}}
 
  
{{Note|This article covers installing and configuring GitLab without HTTPS at first. If needed, see [[#Advanced Configuration]] to set up SSL}}
+
{{Note|This article covers installing and configuring GitLab without HTTPS at first. If needed, see [[#Advanced configuration]] to set up SSL.}}
  
GitLab requires a database backend. If you plan to run it on the same machine, first install either [[MySQL]] or [[PostgreSQL]].
+
GitLab requires [[Redis]] and a database backend. If you plan to run it on the same machine, first install [[PostgreSQL]].
  
 
[[Install]] the {{pkg|gitlab}} package.
 
[[Install]] the {{pkg|gitlab}} package.
  
In order to receive mail notifications, a mail server must be installed and configured. See the following for more information: [[:Category:Mail server]]
+
In order to receive mail notifications, a mail server must be installed and configured. See [[:Category:Mail server]] for details.
  
 
== Configuration ==
 
== Configuration ==
  
=== Notes Before Configuring ===
+
=== Preliminary Notes ===
The {{pkg|gitlab}} package installs GitLab's files in a manner that more closely follows standard Linux conventions:
+
 
 +
GitLab is composed of multiple components, see the [https://docs.gitlab.com/ce/development/architecture.html architecture overview page].
 +
 
 +
The {{pkg|gitlab}} package installs GitLab's files in a manner that more closely follow standard Linux conventions:
  
 
{| class="wikitable"
 
{| class="wikitable"
 
! Description  
 
! Description  
! [https://github.com/gitlabhq/gitlabhq/blob/6-5-stable/doc/install/installation.md GitLab's Official]  
+
! [https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/installation.md GitLab's Official]  
 
! {{pkg|gitlab}}  
 
! {{pkg|gitlab}}  
 
|----------------------------------------------------------
 
|----------------------------------------------------------
Line 50: Line 51:
 
{{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.}}
 
{{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.}}
  
===Basic configuration===
+
===GitLab===
====GitLab Shell====
+
Edit {{ic|/etc/webapps/gitlab/gitlab.yml}} and setup at least the following parameters:
{{Note|You can leave the {{ic|gitlab_url}} with default value if you intend to host GitLab on the same host.}}
 
  
Edit {{ic|/etc/webapps/gitlab-shell/config.yml}} and set {{ic|gitlab_url:}} to the prefer url and port:
+
{{Note|The {{ic|hostname}} and {{ic|port}} are used for the {{ic|git clone http://hostname:port}} as example.}}
{{hc|/etc/webapps/gitlab-shell/config.yml|2=
 
# GitLab user. git by default
 
user: gitlab
 
  
# Url to gitlab instance. Used for api calls. Should end with a slash.
+
'''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.
# Default: http://localhost:8080/
 
# You only have to change the default if you have configured Unicorn
 
# to listen on a custom port, or if you have configured Unicorn to
 
# only listen on a Unix domain socket.
 
gitlab_url: "http://localhost:8080/" # <<-- right here
 
  
http_settings:
+
'''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 would set {{ic|port:}} to {{ic|3425}}. You will also have to '''configure your webserver''' to listen on that port.
#  user: someone
 
#  password: somepass
 
...
 
}}
 
  
Update the {{ic|/etc/webapps/gitlab/unicorn.rb}} configuration if the port and/or hostname is different from the default:
+
'''Timezone (optional):''' The {{ic|time_zone:}} parameter is optional, but may be useful to force the zone of GitLab applications.
{{hc|/etc/webapps/gitlab/unicorn.rb|2=
 
listen "127.0.0.1:8080", :tcp_nopush => true # <<-- right here
 
}}
 
  
====GitLab====
+
Finally set the correct [[permissions]] to the ''uploads'' directory:
Edit {{ic|/etc/webapps/gitlab/gitlab.yml}} and setup at least the following parameters:
 
  
{{Tip|The hostname and port are used for the {{ic|git clone http://hostname:port}} as example.}}
+
# chmod 700 /var/lib/gitlab/uploads
  
'''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.
+
=== Custom port for Unicorn ===
  
'''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.
+
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:
  
'''Timezone (optional):''' The {{ic|time_zone:}} parameter is optional, but may be useful to force the zone of GitLab applications.
+
{{hc|/etc/webapps/gitlab/unicorn.rb|2=
 +
listen "/run/gitlab/gitlab.socket", :backlog => 1024
 +
listen "'''127.0.0.1:8080'''", :tcp_nopush => true
 +
}}
  
Those are the minimal changes needed for a working GitLab install. The adventurous may read on in the comment and customize as needed.
+
If the Unicorn address is changed, the configuration of other components which communicate with Unicorn have to be updated as well:
  
=== Further configuration ===
+
* 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.
  
==== Database backend ====
+
=== Secret strings ===
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 ====
+
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.
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|$ mysql -u root -p|2=
+
For example, random strings can be generated with the following commands:
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:
+
# 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
  
  $ mysql -u '''gitlab''' -p -D gitlabhq_production
+
  # 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
  
Copy the MySQL template file before configuring it:
+
===Redis===
  
# cp /usr/share/doc/gitlab/database.yml.mysql /etc/webapps/gitlab/database.yml
+
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.
  
Next you will need to open {{ic|/etc/webapps/gitlab/database.yml}} and set {{ic|username:}} and {{ic|password:}} for the {{ic|gitlabhq_production}}:
+
* Add the {{ic|gitlab}} user to the {{ic|redis}} [[user group]].
  
{{hc|/etc/webapps/gitlab/database.yml|
+
* Update this configuration file:
#
+
{{hc|/etc/webapps/gitlab/resque.yml|2=
# PRODUCTION
+
development:
#
+
  url: unix:/run/redis/redis.sock
 +
test:
 +
  url: unix:/run/redis/redis.sock
 
production:
 
production:
   adapter: mysql2
+
   url: unix:/run/redis/redis.sock
  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 {{ic|gitlab}} user should have read/write access:
+
* Append to this configuration file:
 +
{{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
 +
}}
  
# chmod 600 /etc/webapps/gitlab/database.yml
+
=== Database backend ===
# chown gitlab:gitlab /etc/webapps/gitlab/database.yml
 
  
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/6-5-stable/doc/install/installation.md GitLab official (generic) install guide].
+
A database backend will be required before Gitlab can be run. GitLab [https://docs.gitlab.com/ce/install/installation.html#6-database recommends] to use [[PostgreSQL]].
  
 
==== PostgreSQL ====
 
==== PostgreSQL ====
Login to PostgreSQL and create the {{ic|gitlabhq_production}} database with along with it's user. Remember to change {{ic|your_username_here}} and {{ic|your_password_here}} to the real values:
+
 
 +
Login to PostgreSQL and create the {{ic|gitlabhq_production}} database along with its user. Remember to change {{ic|your_username_here}} and {{ic|your_password_here}} to the real values:
  
 
  # psql -d template1
 
  # psql -d template1
Line 152: Line 141:
 
}}
 
}}
  
{{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 it's own userspace). And this is only allowed by superusers in Postgresql.}}
+
{{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:
 
Try connecting to the new database with the new user to verify it works:
Line 183: Line 172:
 
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.
 
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.
  
Finally, open {{ic|/usr/lib/systemd/system/gitlab.target}} and {{ic|/usr/lib/systemd/system/gitlab-unicorn.service}} change all instances of {{ic|mysql.service}} to {{ic|postgresql.service}}.
+
==== MariaDB ====
 +
{{Remove|MySQL support is removed in [https://about.gitlab.com/2019/06/27/removing-mysql-support/ GitLab version 12.1].}}
  
==== Firewall ====
+
{{Warning|Using GitLab with MariaDB is [https://docs.gitlab.com/ce/install/database_mysql.html not recommended]. You may run into issues like {{ic|Specified key was too long; max key length is 767 bytes}} when trying to use [[MariaDB]].}}
  
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:
+
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:
  
# iptables -A tcp_inbound -p TCP -s '''192.168.1.0/24''' --destination-port '''80''' -j ACCEPT
+
{{hc|$ mysql -u root -p|2=
 +
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
 +
}}
  
To enable API-access:
+
Try connecting to the new database with the new user:
  
  # iptables -A tcp_inbound -p TCP -s '''192.168.1.0/24''' --destination-port '''8080''' -j ACCEPT
+
  $ mysql -u '''gitlab''' -p -D gitlabhq_production
  
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.
+
Copy the MySQL template file before configuring it:
  
==== Satellites access ====
+
# cp /usr/share/doc/gitlab/database.yml.mysql /etc/webapps/gitlab/database.yml
  
The folder {{ic|satellites}} should have the following permissions set:
+
Next you will need to open {{ic|/etc/webapps/gitlab/database.yml}} and set {{ic|username:}} and {{ic|password:}} for the {{ic|gitlabhq_production}}:
  
# chmod 750 /var/lib/gitlab/satellites
+
{{hc|/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
 +
...
 +
}}
  
==== Initialize Gitlab database ====
+
It should not be set as world readable, e.g. only processes running under the {{ic|gitlab}} user should have read/write access:
  
Start the Redis server before we create the database [[start/enable]] the {{ic|redis}} systemd unit.
+
# chmod 600 /etc/webapps/gitlab/database.yml
 +
# chown gitlab:gitlab /etc/webapps/gitlab/database.yml
  
Now you have to install bundler and the required gems with:
+
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].
  
# export PATH=$PATH:/var/lib/gitlab/.gem/ruby/2.3.0/bin
+
=== Firewall ===
# sudo -u gitlab -H gem install bundler --no-document
 
# cd /usr/share/webapps/gitlab
 
# sudo -u gitlab -H bundle install
 
  
{{Warning|GitLab requires {{ic|bundle}} command, not {{ic|bundle-2.1}}, don't forget to install it.}}
+
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:
  
{{Note|If you're getting errors later on saying bundle is missing for the user 'gitlab', then this is most likely because ruby is installed in a non-readable folder such as /usr/lib or something similar and this solves that issue:
+
# iptables -A tcp_inbound -p TCP -s '''192.168.1.0/24''' --destination-port '''80''' -j ACCEPT
  
{{bc|<nowiki>
+
To enable API-access:
su - gitlab -s /bin/sh -c "export PATH=$PATH:/var/lib/gitlab/.gem/ruby/2.3.0/bin; gem install bundler --no-document"
 
su - gitlab -s /bin/sh -c "export PATH=$PATH:/var/lib/gitlab/.gem/ruby/2.3.0/bin; cd /usr/share/webapps/gitlab; bundle install"
 
su - gitlab -s /bin/sh -c "export PATH=$PATH:/var/lib/gitlab/.gem/ruby/2.3.0/bin; cd /usr/share/webapps/gitlab; bundle exec rake gitlab:setup RAILS_ENV=production"
 
su - gitlab -s /bin/sh -c "export PATH=$PATH:/var/lib/gitlab/.gem/ruby/2.3.0/bin; cd /usr/share/webapps/gitlab; bundle exec rake assets:precompile RAILS_ENV=production"
 
</nowiki>}}
 
}}
 
  
Initialize the database and activate advanced features:
+
  # iptables -A tcp_inbound -p TCP -s '''192.168.1.0/24''' --destination-port '''8080''' -j ACCEPT
  # cd /usr/share/webapps/gitlab
 
# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle exec rake gitlab:setup RAILS_ENV=production"
 
  
{{bc|<nowiki>
+
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.
Missing `db_key_base` for 'production' environment. The secrets will be generated and stored in `config/secrets.yml`
 
This will create the necessary database tables and seed the database.
 
You will lose any previous data stored in the database.
 
Do you want to continue (yes/no)? yes
 
  
gitlabhq_production already exists
+
=== Initialize Gitlab database ===
-- enable_extension("plpgsql")
 
  -> 0.0009s
 
-- create_table("abuse_reports", {:force=>true})
 
  -> 0.0300s
 
-- create_table("application_settings", {:force=>true})
 
  -> 0.0116s
 
  
...
+
Start the [[Redis]] server and the {{ic|gitlab-gitaly.service}} before initializing the database.
  
Administrator account created:
+
Initialize the database and activate advanced features:
 +
# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.5 exec rake gitlab:setup RAILS_ENV=production"
  
login.........root
+
Finally run the following commands to check your installation:
password......5iveL!fe
 
</nowiki>}}
 
  
Now compile the assets:
+
# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.5 exec rake gitlab:env:info RAILS_ENV=production"
 +
# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.5 exec rake gitlab:check RAILS_ENV=production"
  
# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle exec rake assets:precompile RAILS_ENV=production"
+
{{note|
 
+
*The ''gitlab:env:info'' and ''gitlab:check'' commands will show a fatal error related to git. This is OK.
Finally, check that {{ic|/etc/webapps/gitlab/secret}} contains a random hex string.
+
*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).
 
+
}}
==== Configure Git User  ====
 
{{Note|This must match the {{ic|user}} and {{ic|email_from}} defined in {{ic|/usr/share/webapps/gitlab/config/gitlab.yml}}.}}
 
 
 
# cd /usr/share/webapps/gitlab
 
# sudo -u gitlab -H git config --global user.name  "GitLab"
 
# sudo -u gitlab -H git config --global user.email "example@example.com"
 
# sudo -u gitlab -H git config --global core.autocrlf "input"
 
  
==== Adjust modifier bits ====
+
=== Adjust modifier bits ===
(The gitlab check won't pass if the user and group ownership isn't configured properly)
+
(The gitlab check will not pass if the user and group ownership is not configured properly)
  
 
  # chmod -R ug+rwX,o-rwx /var/lib/gitlab/repositories/
 
  # chmod -R ug+rwX,o-rwx /var/lib/gitlab/repositories/
Line 274: Line 258:
  
 
== Start and test GitLab ==
 
== Start and test GitLab ==
{{note|See [[#Troubleshooting]] and log files inside the {{ic|/usr/share/webapps/gitlab/log}} directory for troubleshooting.}}
 
Make systemd see your new daemon unit files:
 
  
# systemctl daemon-reload
+
Make sure [[PostgreSQL]] and [[Redis]] are running and setup correctly.
  
Make sure [[MySQL]] or [[PostgreSQL]] and Redis are running and setup correctly.
+
Then [[start]]/[[enable]] {{ic|gitlab.target}}.
  
If needed see [[#Redis Over Unix Socket]] example if GitLab cannot load {{ic|redis}} correctly.
+
Now test your GitLab instance by visiting http://localhost:8080 or http://yourdomain.com, you should be prompted to create a password:
  
After starting the database backends, we can start GitLab with its webserver (Unicorn) by [[start]]ing both the {{ic|gitlab-sidekiq}} and {{ic|gitlab-unicorn}} systemd units.
+
{{bc|
 +
username: root
 +
password: You will be prompted to create one on your first visit.
 +
}}
  
With the following commands we check if the steps we followed so far are configured properly:
+
See [[#Troubleshooting]] and log files inside the {{ic|/usr/share/webapps/gitlab/log/}} directory for troubleshooting.
  
  # cd /usr/share/webapps/gitlab
+
== Upgrade database on updates ==
# sudo -u gitlab bundle exec rake gitlab:env:info RAILS_ENV=production
+
After updating the {{Pkg|gitlab}} package, it is required to upgrade the database:
# sudo -u gitlab bundle exec rake gitlab:check RAILS_ENV=production
+
  # su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.5 exec rake db:migrate RAILS_ENV=production"
  
{{note|These gitlab:env:info and gitlab:check commands will show a fatal error related to git. This is OK.}}
+
Afterwards, restart gitlab-related services:
 
+
# systemctl daemon-reload
{{hc|<nowiki>$ sudo -u gitlab bundle exec rake gitlab:env:info RAILS_ENV=production</nowiki>|<nowiki>
+
# systemctl restart gitlab-sidekiq gitlab-unicorn gitlab-workhorse gitlab-gitaly
fatal: Not a git repository (or any of the parent directories): .git
 
 
 
System information
 
System: Arch rolling
 
Current User: gitlab
 
Using RVM: no
 
Ruby Version: 2.2.3p173
 
Gem Version: 2.4.5.1
 
Bundler Version:1.10.6
 
Rake Version: 10.4.2
 
Sidekiq Version:3.3.0
 
  
GitLab information
+
== Advanced configuration ==
Version: 7.14.0
 
Revision: fatal: Not a git repository (or any of the parent directories): .git
 
Directory: /usr/share/webapps/gitlab
 
DB Adapter: mysql2
 
URL: http://gitlab.arch
 
HTTP Clone URL: http://gitlab.arch/some-project.git
 
SSH Clone URL: git@gitlab.arch:some-project.git
 
Using LDAP: no
 
Using Omniauth: no
 
  
GitLab Shell
+
=== Basic SSH ===
Version: 2.6.4
+
After completing the basic installation, set up SSH access for users. Configuration for [[OpenSSH]] is described below.  [[SSH#Implementations|Other SSH clients and servers]] will require different modifications.
Repositories: /var/lib/gitlab/repositories/
 
Hooks: /usr/share/webapps/gitlab-shell/hooks/
 
Git: /usr/bin/git
 
</nowiki>}}
 
  
{{Note| {{ic|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).}}
+
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}}.
  
{{hc|<nowiki>$ sudo -u gitlab bundle exec rake gitlab:check RAILS_ENV=production</nowiki>|<nowiki>
+
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:
fatal: Not a git repository (or any of the parent directories): .git
+
{{hc|/etc/ssh/sshd_config|
Checking Environment ...
+
PubkeyAuthentication  yes
 
+
AuthorizedKeysFile    %h/.ssh/authorized_keys
Git configured for gitlab user? ... yes
 
Has python2? ... yes
 
python2 is supported version? ... yes
 
 
 
Checking Environment ... Finished
 
 
 
Checking GitLab Shell ...
 
 
 
GitLab Shell version >= 1.7.9 ? ... OK (1.8.0)
 
Repo base directory exists? ... yes
 
Repo base directory is a symlink? ... no
 
Repo base owned by gitlab:gitlab? ... yes
 
Repo base access is drwxrws---? ... yes
 
update hook up-to-date? ... yes
 
update hooks in repos are links: ... can't check, you have no projects
 
Running /srv/gitlab/gitlab-shell/bin/check
 
Check GitLab API access: OK
 
Check directories and files:
 
        /srv/gitlab/repositories: OK
 
        /srv/gitlab/.ssh/authorized_keys: OK
 
Test redis-cli executable: redis-cli 2.8.4
 
Send ping to redis server: PONG
 
gitlab-shell self-check successful
 
 
 
Checking GitLab Shell ... Finished
 
 
 
Checking Sidekiq ...
 
 
 
Running? ... yes
 
Number of Sidekiq processes ... 1
 
 
 
Checking Sidekiq ... Finished
 
 
 
Checking LDAP ...
 
 
 
LDAP is disabled in config/gitlab.yml
 
 
 
Checking LDAP ... Finished
 
 
 
Checking GitLab ...
 
 
 
Database config exists? ... yes
 
Database is SQLite ... no
 
All migrations up? ... fatal: Not a git repository (or any of the parent directories): .git
 
yes
 
GitLab config exists? ... yes
 
GitLab config outdated? ... no
 
Log directory writable? ... yes
 
Tmp directory writable? ... yes
 
Init script exists? ... no
 
  Try fixing it:
 
  Install 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.
 
Init script up-to-date? ... can't check because of previous errors
 
projects have namespace: ... can't check, you have no projects
 
Projects have satellites? ... can't check, you have no projects
 
Redis version >= 2.0.0? ... yes
 
Your git bin path is "/usr/bin/git"
 
Git version >= 1.7.10 ? ... yes (1.8.5)
 
 
 
Checking GitLab ... Finished
 
</nowiki>}}
 
 
 
To automatically launch GitLab at startup, enable the {{ic|gitlab.target}}, {{ic|gitlab-sidekiq}} and {{ic|gitlab-unicorn}} services.
 
 
 
Now test your GitLab instance by visiting http://localhost:8080 or http://yourdomain.com and login with the default credentials:
 
 
 
{{bc|
 
username: root
 
password: 5iveL!fe
 
 
}}
 
}}
  
{{note|1=If your browser runs not on the machine where gitlab is running, modify your unicorn.rb in order to be able to test your setup without the use of a proxy. The corresponding line looks like this:
+
After updating the configuration file, restart the ssh daemon:
<pre>listen "127.0.0.1:8080, :tcp_nopush => true</pre>
+
# systemctl restart sshd
you should replace that with:
 
<pre>listen "example.yourhost.com:8080, :tcp_nopush => true</pre>
 
}}
 
  
== Advanced Configuration ==
+
Test user SSH keys (optionally add -v to see extra information):
 +
<nowiki>$ ssh -T </nowiki>'''gitlab'''@''YOUR_SERVER''
  
=== Custom SSH Connection ===
+
=== Custom SSH connection ===
 
If you are running SSH on a non-standard port, you must change the GitLab user's SSH config:
 
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=
 
{{hc|/var/lib/gitlab/.ssh/config|2=
Line 429: Line 316:
 
Modify {{ic|/etc/webapps/gitlab/gitlab.yml}} so that {{ic|https:}} setting is set to {{ic|true}}.
 
Modify {{ic|/etc/webapps/gitlab/gitlab.yml}} so that {{ic|https:}} setting is set to {{ic|true}}.
  
See also [[Apache HTTP Server#TLS/SSL]] and [[Let’s Encrypt]].
+
See also [[Apache HTTP Server#TLS]] and [[Let’s Encrypt]].
  
 
==== 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 {{ic|<nowiki>https://gitlab.</nowiki>''YOUR_SERVER_FQDN''/.well-known/''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.
+
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.
  
 
To bypass this issue, you can use the Let's Encrypt webroot configuration, setting the webroot at {{ic|/srv/http/letsencrypt/}}.
 
To bypass this issue, you can use the Let's Encrypt webroot configuration, setting the webroot at {{ic|/srv/http/letsencrypt/}}.
Line 447: Line 334:
 
If you want to integrate Gitlab into a running web server instead of using its build-in http server Unicorn, then follow these instructions.
 
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 =====
+
==== 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 creates 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].
+
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].
  
====Nginx and unicorn====
+
==== Nginx ====
  
=====AUR Installation=====
+
See [[Nginx#Configuration]] for basic ''nginx'' configuration and [[Nginx#TLS]] for enabling HTTPS. The sample in this section also assumes that server blocks are managed with [[Nginx#Managing server entries]].
Setup [[Nginx]], and create the following directories (if not exist already):
 
  
# mkdir /etc/nginx/servers-available
+
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.
# mkdir /etc/nginx/servers-enabled
 
  
{{Note|You may need to change {{ic|localhost:8080}} with the correct gitlab address and {{ic|example.com}} to your desired server name.}}
+
{{hc|/etc/nginx/servers-available/gitlab|<nowiki>
{{Tip|See [[Nginx#TLS.2FSSL|Nginx#TLS/SSL]] before enabling SSL.}}
+
upstream gitlab-workhorse {
Create a file {{ic|/etc/nginx/servers-available/gitlab}} with the following content:
+
   server unix:/run/gitlab/gitlab-workhorse.socket fail_timeout=0;
 
 
{{hc|/etc/nginx/servers-available/gitlab|2=
 
# Created by: Sameer Naik
 
# Contributor: francoism90
 
# Source: https://gist.github.com/sameersbn/becd1c976c3dc4866ef8
 
upstream gitlab {
 
   server localhost:8080 fail_timeout=0;
 
 
}
 
}
  
 
server {
 
server {
   listen 80;
+
   listen 80;                 # IPv4 HTTP
   #listen 443 ssl; # uncomment to enable ssl
+
   #listen 443 ssl http2;     # uncomment to enable IPv4 HTTPS + HTTP/2
   keepalive_timeout 70;
+
  #listen [::]:80;            # uncomment to enable IPv6 HTTP
   server_name example.com
+
   #listen [::]:443 ssl http2; # uncomment to enable IPv6 HTTPS + HTTP/2
  server_tokens off;
+
   server_name example.com;
 +
 
 
   #ssl_certificate ssl/example.com.crt;
 
   #ssl_certificate ssl/example.com.crt;
 
   #ssl_certificate_key ssl/example.com.key;
 
   #ssl_certificate_key ssl/example.com.key;
  charset utf-8;
+
 
  root /dev/null;
 
 
 
  # Increase this if you want to upload larger attachments
 
  client_max_body_size 20m;
 
 
 
 
   location / {
 
   location / {
       proxy_read_timeout 300;
+
      # unlimited upload size in nginx (so the setting in GitLab applies)
       proxy_connect_timeout 300;
+
      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_redirect off;
     
+
 
      proxy_set_header X-Forwarded-Proto $scheme;
 
 
       proxy_set_header Host $http_host;
 
       proxy_set_header Host $http_host;
 
       proxy_set_header X-Real-IP $remote_addr;
 
       proxy_set_header X-Real-IP $remote_addr;
Line 495: Line 372:
 
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 
       proxy_set_header X-Forwarded-Proto $scheme;
 
       proxy_set_header X-Forwarded-Proto $scheme;
      proxy_set_header X-Frame-Options SAMEORIGIN;
 
     
 
      proxy_pass http://localhost:8080;
 
  } 
 
}
 
}}
 
  
Make sure the following line exists at the end of the {{ic|http}} block in {{ic|/etc/nginx/nginx.conf}}:
+
      proxy_pass http://gitlab-workhorse;
 +
  }
  
include servers-enabled/*;
+
  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;
 +
  }
 +
}
 +
</nowiki>}}
  
Enable the {{ic|github}} configuration:
+
==== Apache ====
  
# ln -s /etc/nginx/servers-available/gitlab /etc/nginx/servers-enabled/gitlab
+
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.
  
Verify the new configuration:
+
For the SSL configuration see [[Apache HTTP Server#TLS]]. 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.
  
# nginx -t
+
=== Gitlab-workhorse ===
  
Finally, (re)start the {{ic|gitlab.target}}, {{ic|resque.target}} and {{ic|nginx.service}}.
+
{{Remove|The {{Pkg|gitlab-workhorse}} component is nowadays required. The default configuration is sufficient for common cases so this section can be removed.}}
  
=====Manual Installation=====
+
{{Expansion|This section needs configuration instructions.}}
If you did not use AUR, you need to copy {{ic|/usr/lib/support/nginx/gitlab}} to {{ic|/etc/nginx/sites-available/}}.
 
  
Run these commands to setup nginx:
+
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
  
# ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab
+
{{Note|Unicorn is still needed so do not disable or stop {{ic|gitlab-unicorn.service}}.}}
  
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.
+
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}}
  
Make sure the following line exists at the end of the {{ic|http}} block in {{ic|/etc/nginx/nginx.conf}}:
+
When using nginx remember to edit your nginx configuration file. To switch from gitlab-unicorn to gitlab-workhorse edit the two following settings accordingly
 +
{{hc|/etc/nginx/servers-available/gitlab|2=
 +
upstream gitlab {
 +
  server unix:/run/gitlab/gitlab-workhorse.socket fail_timeout=0;
 +
}
  
include sites-enabled/*;
 
 
Enable the {{ic|github}} configuration:
 
 
# ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab
 
 
Verify the new configuration:
 
 
# nginx -t
 
 
Finally, (re)start the {{ic|gitlab.target}}, {{ic|resque.target}} and {{ic|nginx.service}}.
 
 
====Apache and unicorn====
 
 
[[Install]] {{Pkg|apache}} from the [[official repositories]].
 
 
=====Configure Unicorn=====
 
 
As the official installation guide instructs, copy the unicorn configuration file:
 
# sudo -u git -H cp /usr/share/webapps/gitlab/config/unicorn.rb.example /usr/share/webapps/gitlab/config/unicorn.rb
 
 
Now edit {{ic|config/unicorn.rb}} and add a listening port by uncommenting the following line:
 
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.}}
 
 
=====Create a virtual host for Gitlab=====
 
 
Create a configuration file for Gitlab’s virtual host and insert the lines below adjusted accordingly. For the ssl section see [[LAMP#SSL]]{{Broken section link}}. 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.
 
 
You can use these [https://gitlab.com/gitlab-org/gitlab-recipes/blob/079f70dd2c091434a8dd04ed5b1a0d0e937cd361/web-server/apache/gitlab-ssl-apache2.4.conf examples] to get you started.
 
 
=====Enable host and start unicorn=====
 
 
Enable your Gitlab virtual host and reload [[Apache]]:
 
{{hc|/etc/httpd/conf/httpd.conf| Include /etc/httpd/conf/extra/gitlab.conf}}
 
 
Copy the Apache  gitlab.conf file
 
 
# cp /usr/share/doc/gitlab/apache.conf.example /etc/httpd/conf/extra/gitlab.conf
 
 
Finally [[start]] {{ic|gitlab-unicorn.service}}.
 
 
=== Redis ===
 
Using a Redis setup different from default (e.g. different address, port, unix socket) requires the environment variable ''REDIS_URL'' to be set accordingly for unicorn. This can be achieved by extending the systemd service file. Create a file ''/etc/systemd/system/gitlab-unicorn.service.d/redis.conf'' that injects the ''REDIS_URL'' environment variable:
 
[Service]
 
Environment=REDIS_URL=unix:///run/gitlab/redis.sock
 
 
==== Redis Over Unix Socket ====
 
 
If Redis is set to listen on socket, you may want to adjust the default configuration:
 
 
{{hc|/etc/redis.conf|2=
 
 
...
 
...
# Accept connections on the specified port, default is 6379.
+
     
# If port 0 is specified Redis will not listen on a TCP socket.
+
      proxy_pass http://unix:/run/gitlab/gitlab-workhorse.socket;
port 0
+
  } 
...
+
}
# By default Redis listens for connections from all the network interfaces
 
# available on the server. It is possible to listen to just one or multiple
 
# interfaces using the "bind" configuration directive, followed by one or
 
# more IP addresses.
 
#
 
# Examples:
 
#
 
# bind 192.168.1.100 10.0.0.1
 
bind 127.0.0.1
 
 
 
# Specify the path for the Unix socket that will be used to listen for
 
# incoming connections. There is no default, so Redis will not listen
 
# on a unix socket when not specified.
 
#
 
unixsocket /var/run/redis/redis.sock
 
unixsocketperm 770
 
 
}}
 
}}
  
Create the directory {{ic|/var/run/redis}} and set the correct permissions:
+
==Useful tips==
# mkdir /var/run/redis
 
# chown redis:redis /var/run/redis
 
# chmod 755 /var/run/redis
 
 
 
Add the user {{ic|git}} and {{ic|gitlab}} to the {{ic|redis}} group:
 
 
 
# usermod -a -G redis git
 
# usermod -a -G redis gitlab
 
  
Update {{ic|/etc/webapps/gitlab-shell/config.yml}} and {{ic|/etc/webapps/gitlab/resque.yml}} files:
+
===Rake tasks===
 
+
A number of setup/maintenance/etc tasks are available through rake. To list them, go to Gitlab's home directory:
{{hc|/etc/webapps/gitlab/resque.yml|2=
 
development: unix:/var/run/redis/redis.sock
 
test: unix:/run/redis/redis.sock
 
production: unix:/run/redis/redis.sock
 
}}
 
 
 
{{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: /var/run/redis/redis.sock # uncomment this line
 
  namespace: resque:gitlab
 
...
 
}}
 
 
 
Finally restart the {{ic|redis}}, {{ic|gitlab-sidekiq}} and {{ic|gitlab-unicorn}} services.
 
 
 
For more information, please see issue [https://github.com/gitlabhq/gitlabhq/issues/6100 #6100].
 
 
 
=== Gitlab-workhorse ===
 
 
 
{{Expansion|This section needs configuration instructions.}}
 
 
 
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.
 
 
 
Please note that {{Pkg|gitlab-workhorse}} should now be preferred over {{Pkg|gitlab-unicorn}}{{Broken package link|package not found}} according to the GitLab team: https://gitlab.com/gitlab-org/gitlab-ce/issues/22528#note_16036216
 
 
 
GitLab v8.12 somehow broke {{Pkg|gitlab-unicorn}}{{Broken package link|package not found}} web server. Using {{Pkg|gitlab-workhorse}} instead fixes issues about unreachable assets and consequently broken display/broken CSS.
 
 
 
By default {{Pkg|gitlab-workhorse}} listens on {{ic|127.0.0.1:8181}}. You should consider [[edit]]ing {{ic|gitlab-workhorse.service}} and change the parameter {{ic|-listenAddr}} according to your LAN IP address, for example {{ic|-listenAddr 192.168.0.1:8181}}.
 
 
 
=== GitLab CI ===
 
 
 
{{Expansion|This section needs configuration instructions (for example, valid builds directory path).}}
 
 
 
==Useful Tips==
 
 
 
===Fix Rake Warning===
 
When running rake tasks for the gitlab project, this error will occur: {{ic|fatal: Not a git repository (or any of the parent directories): .git}}. This is a bug in bundler, and it can be safely ignored. However, if you want to git rid of the error, the following method can be used:
 
 
 
{{bc|1=
 
# cd /usr/share/webapps/gitlab
 
# sudo -u gitlab git init
 
# sudo -u gitlab git commit -m "initial commit" --allow-empty
 
}}
 
 
 
===Hook into /var===
 
{{bc|1=
 
# mkdir -m700 /var/log/gitlab /var/tmp/gitlab
 
# 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===
 
Go to Gitlab's home directory:
 
 
  # cd /usr/share/webapps/gitlab
 
  # cd /usr/share/webapps/gitlab
  
Line 714: Line 459:
  
 
Create a backup of the gitlab system:
 
Create a backup of the gitlab system:
  # sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:create
+
  # su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.5 exec rake RAILS_ENV=production gitlab:backup:create"
  
Restore the previously created backup file {{ic|/home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740_gitlab_backup.tar}}:
+
Restore the previously created backup file {{ic|/var/lib/gitlab/backups/1556571328_2019_04_29_11.10.2_gitlab_backup.tar}}:
  # sudo -u gitlab -H rake RAILS_ENV=production gitlab:backup:restore BACKUP=/home/gitlab/gitlab/tmp/backups/20130125_11h35_1359131740
+
  # su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.5 exec rake RAILS_ENV=production gitlab:backup:restore BACKUP=1556571328_2019_04_29_11.10.2"
  
 
{{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].}}
 
{{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].}}
  
===Migrate from sqlite to mysql===
+
=== Enable fast SSH key lookup ===
  
Get latest code as described in [[#Update Gitlab]]{{Broken section link}}.
+
Enable Fast SSH Key Lookup as explained in this page: https://docs.gitlab.com/ee/administration/operations/fast_ssh_key_lookup.html
Save data.
 
# cd /home/gitlab/gitlab
 
# sudo -u gitlab bundle exec rake db:data:dump RAILS_ENV=production
 
  
Follow [[#Mysql]]{{Broken section link}} instructions and then setup the database.
+
In short, edit {{ic|/etc/ssh/sshd_config}}.
# sudo -u gitlab bundle exec rake db:setup RAILS_ENV=production
 
  
Finally restore old data.
+
Revert all changes done following this wiki (or revert {{ic|sshd_config}} from the {{Pkg|openssh}} package) and only add:
# sudo -u gitlab bundle exec rake db:data:load RAILS_ENV=production
 
  
===Running GitLab with rvm===
+
AuthorizedKeysCommand /var/lib/gitlab/gitlab-shell/bin/gitlab-shell-authorized-keys-check gitlab %u %k
 +
AuthorizedKeysCommandUser gitlab
  
To run gitlab with rvm first you have to set up an rvm:
+
Finally [[restart]] the {{ic|sshd.service}}.
 
 
  curl -L https://get.rvm.io | bash -s stable --ruby=1.9.3
 
 
 
{{Note|Version 1.9.3 is currently recommended to avoid some compatibility issues.}}
 
 
 
For the complete installation you will want to be the final user (e.g. {{ic|git}}) so make sure to switch to this user and activate your rvm:
 
 
 
  su - git
 
  source "$HOME/.rvm/scripts/rvm"
 
 
 
Then continue with the installation instructions from above. However, the systemd scripts will not work this way, because the environment for the rvm is not activated. The recommendation here is to create to separate shell scripts for {{ic|unicorn}} and {{ic|sidekiq}} to activate the environment and then start the service:
 
 
 
{{hc|gitlab.sh|<nowiki>
 
#!/bin/sh
 
source `/home/git/.rvm/bin/rvm 1.9.3 do rvm env --path`
 
bundle exec "unicorn_rails -c /usr/share/webapps/gitlab/config/unicorn.rb -E production"</nowiki>
 
}}
 
 
 
{{hc|sidekiq.sh|<nowiki>
 
#!/bin/sh
 
source `/home/git/.rvm/bin/rvm 1.9.3 do rvm env --path`
 
case $1 in
 
    start)
 
        bundle exec rake sidekiq:start RAILS_ENV=production
 
        ;;
 
    stop)
 
        bundle exec rake sidekiq:stop RAILS_ENV=production
 
        ;;
 
    *)
 
        echo "Usage $0 {start|stop}"
 
esac
 
</nowiki>}}
 
 
 
Then modify the above systemd files so they use these scripts. Modify the given lines:
 
 
 
{{hc|gitlab.service|<nowiki>
 
ExecStart=/home/git/bin/gitlab.sh
 
</nowiki>}}
 
{{hc|sidekiq.service|<nowiki>
 
ExecStart=/home/git/bin/sidekiq.sh start
 
ExecStop=/home/git/bin/sidekiq.sh stop
 
</nowiki>}}
 
  
 
===Sending mails from Gitlab via SMTP===
 
===Sending mails from Gitlab via SMTP===
Line 790: Line 489:
 
   Gitlab::Application.config.action_mailer.delivery_method = :smtp
 
   Gitlab::Application.config.action_mailer.delivery_method = :smtp
  
   Gitlab::Application.config.action_mailer.smtp_settings = {
+
   ActionMailer::Base.delivery_method = :smtp
 +
  ActionMailer::Base.smtp_settings = {
 
     address:              'smtp.gmail.com',
 
     address:              'smtp.gmail.com',
 
     port:                587,
 
     port:                587,
Line 804: Line 504:
  
 
==Troubleshooting==
 
==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].
 
  
 
=== HTTPS is not green (gravatar not using https) ===
 
=== HTTPS is not green (gravatar not using https) ===
Line 811: Line 509:
  
 
  cd /usr/share/webapps/gitlab
 
  cd /usr/share/webapps/gitlab
  RAILS_ENV=production bundle exec rake cache:clear
+
  RAILS_ENV=production bundle-2.5 exec rake cache:clear
  
 
as the gitlab user.
 
as the gitlab user.
 
=== Error at push bad line length character: API ===
 
If you get the following error while trying to push
 
fatal: protocol error: bad line length character: API
 
 
Check that your {{ic|/etc/webapps/gitlab-shell/secret}} matches {{ic|/usr/share/webapps/gitlab/.gitlab_shell_secret}}
 
 
If it is not the same, recreate the file with the following command
 
ln -s /etc/webapps/gitlab-shell/secret /usr/share/webapps/gitlab/.gitlab_shell_secret
 
  
 
=== Errors after updating ===
 
=== Errors after updating ===
Line 831: Line 520:
  
 
If every gitlab page gives a 500 error, then the database migrations and the assets are probably stale. If not, skip this step.
 
If every gitlab page gives a 500 error, then the database migrations and the assets are probably stale. If not, skip this step.
  # sudo -u gitlab -H bundle exec rake db:migrate RAILS_ENV=production
+
  # su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.5 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.
 
If gitlab is constantly waiting for the deployment to finish, then the assets have probably not been recompiled.
  # sudo -u gitlab -H bundle exec rake assets:clean assets:precompile cache:clear RAILS_ENV=production
+
  # su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.5 exec rake gitlab:assets:clean gitlab:assets:compile cache:clear RAILS_ENV=production"
  
 
Finally, restart the gitlab services and test your site.
 
Finally, restart the gitlab services and test your site.
 
  # systemctl restart gitlab-unicorn gitlab-sidekiq gitlab-workhorse
 
  # systemctl restart gitlab-unicorn gitlab-sidekiq gitlab-workhorse
  
=== /etc/webapps/gitlab/secret is empty ===
+
=== Gitlab-Unicorn cannot access non-default repositories directory ===
This file is usually generated while installing the {{pkg|gitlab-shell}} and the {{pkg|gitlab}} packages, but in some cases it may need to be generated manually.
+
 
  # hexdump -v -n 64 -e '1/1 "%02x"' /dev/urandom > /etc/webapps/gitlab-shell/secret
+
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]).
# chown root:gitlab /etc/webapps/gitlab-shell/secret
+
 
# chmod 640 /etc/webapps/gitlab-shell/secret
+
=== Failed to connect to Gitaly ===
 +
 
 +
Sometimes, the Gitaly service will not get started, leaving GitLab unable to connect to Gitaly. The solution is simple:
 +
  # systemctl start gitlab-gitaly
 +
 
 +
=== Failed to connect via SSH ===
 +
If git operations (-T, pull, clone, etc.) fails using ssh try changing the shell:
 +
 
 +
# usermod -s /usr/share/webapps/gitlab-shell/bin/gitlab-shell-ruby gitlab
 +
 
 +
=== CSS or styles issue ===
 +
 
 +
If you have any issues with styles and CSS not working, you may try to edit {{ic|/usr/share/webapps/gitlab/config/environments/production.rb}} and change:
 +
 
 +
  # Disable Rails's static asset server (Apache or nginx will already do this)
 +
  config.public_file_server.enabled = false
 +
 
 +
to:
  
# hexdump -v -n 64 -e '1/1 "%02x"' /dev/urandom > /etc/webapps/gitlab/secret
+
  # Disable Rails's static asset server (Apache or nginx will already do this)
# chown root:gitlab /etc/webapps/gitlab/secret
+
  config.public_file_server.enabled = true
# chmod 640 /etc/webapps/gitlab/secret
 
  
 
==See also==
 
==See also==
*[https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md Official Documentation]
+
*[https://docs.gitlab.com/ce/install/installation.html Official installation documentation]
*[https://gitlab.com/gitlab-org/gitlab-recipes Gitlab recipes with further documentation on running it with several webservers]
+
*[https://gitlab.com/gitlab-org/gitlab-recipes GitLab recipes with further documentation on running it with several web servers]
*[https://github.com/gitlabhq/gitlabhq GitLab source code]
+
*[https://gitlab.com/gitlab-org/gitlab-ce GitLab source code]

Latest revision as of 17:59, 6 October 2019

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 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 would 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.

  • Update this configuration file:
/etc/webapps/gitlab/resque.yml
development:
  url: unix:/run/redis/redis.sock
test:
  url: unix:/run/redis/redis.sock
production:
  url: unix:/run/redis/redis.sock
  • Append to this configuration file:
/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

A database backend will be required before Gitlab can be run. GitLab recommends to use PostgreSQL.

PostgreSQL

Login to PostgreSQL and create the gitlabhq_production database 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.

MariaDB

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

Reason: MySQL support is removed in GitLab version 12.1. (Discuss in Talk:GitLab#)
Warning: Using GitLab with MariaDB is not recommended. You may run into issues like Specified key was too long; max key length is 767 bytes when trying to use 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.

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 and the gitlab-gitaly.service before initializing the database.

Initialize the database and activate advanced features:

# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.5 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.5 exec rake gitlab:env:info RAILS_ENV=production"
# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.5 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 will not pass if the user and group ownership is not 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 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 will 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.5 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 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 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;                  # IPv4 HTTP
  #listen 443 ssl http2;      # uncomment to enable IPv4 HTTPS + HTTP/2
  #listen [::]:80;            # uncomment to enable IPv6 HTTP
  #listen [::]:443 ssl http2; # uncomment to enable IPv6 HTTPS + HTTP/2
  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. 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 do not 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

Rake tasks

A number of setup/maintenance/etc tasks are available through rake. To list them, 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:

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

Restore the previously created backup file /var/lib/gitlab/backups/1556571328_2019_04_29_11.10.2_gitlab_backup.tar:

# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle-2.5 exec rake RAILS_ENV=production gitlab:backup:restore BACKUP=1556571328_2019_04_29_11.10.2"
Note: Backup folder is set in config/gitlab.yml. GitLab backup and restore is documented here.

Enable fast SSH key lookup

Enable Fast SSH Key Lookup as explained in this page: https://docs.gitlab.com/ee/administration/operations/fast_ssh_key_lookup.html

In short, edit /etc/ssh/sshd_config.

Revert all changes done following this wiki (or revert sshd_config from the openssh package) and only add:

AuthorizedKeysCommand /var/lib/gitlab/gitlab-shell/bin/gitlab-shell-authorized-keys-check gitlab %u %k
AuthorizedKeysCommandUser gitlab

Finally restart the sshd.service.

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.5 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.5 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.5 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).

Failed to connect to Gitaly

Sometimes, the Gitaly service will not get started, leaving GitLab unable to connect to Gitaly. The solution is simple:

# systemctl start gitlab-gitaly

Failed to connect via SSH

If git operations (-T, pull, clone, etc.) fails using ssh try changing the shell:

# usermod -s /usr/share/webapps/gitlab-shell/bin/gitlab-shell-ruby gitlab

CSS or styles issue

If you have any issues with styles and CSS not working, you may try to edit /usr/share/webapps/gitlab/config/environments/production.rb and change:

 # Disable Rails's static asset server (Apache or nginx will already do this)
 config.public_file_server.enabled = false

to:

 # Disable Rails's static asset server (Apache or nginx will already do this)
 config.public_file_server.enabled = true

See also