GitLab

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:

Edit and setup at least the following parameters:

Hostname: In the section set - replacing to (no or trailing slash) - into your fully qualified domain name.

Port: port: can be confusing. This is not the port that the GitLab server (Puma) runs on; it is the port that users will initially access through in their browser. Basically, if you intend for users to visit 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 into their browsers, then you would set port: to . You will also have to configure your webserver to listen on that port.

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

Based on the table in #Preliminary notes above, the following paths have to be configured in :

• section:
• section (if enabled): log_path: "/var/log/gitlab/mail_room_json.log"
• section (if enabled):
• section (if enabled): storage_path: "/var/lib/gitlab/shared/external-diffs"
• section (if enabled):
• section (if enabled):
• section (if enabled):
• terraform_state section (if enabled):
• section (if enabled):
• section (if enabled):

GitLab Puma is the main component which processes most of the user requests. By default, it listens on the UNIX socket which can be changed in the /etc/webapps/gitlab/puma.rb file.

To configure Puma to listen on a TCP port as well as UNIX socket:

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

• For GitLab Shell, update the variable in and url in the section in .

• For GitLab Workhorse, edit the and update the option. See for details.

Make sure that the files and 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
# chmod 640 /etc/webapps/gitlab/secret

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

Also fill in (new) secret strings for secrets.yml:

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 user group and update this configuration file:

A PostgreSQL database will be required before Gitlab can be run.

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

# psql -d template1

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

# psql -d gitlabhq_production

Open the new and set the values for and password:. For example:

/etc/webapps/gitlab/database.yml (gitlab before 15.0.1-1)

#
# PRODUCTION
#
production:
  adapter: postgresql
  encoding: unicode
  database: gitlabhq_production
  pool: 10
  username: your_username_here
  password: "your_password_here"
  # host: localhost
  # port: 5432
  socket: /run/postgresql/.s.PGSQL.5432
...

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

Start the Redis server and the before initializing the database.

Initialize the database and activate advanced features:

$ cd /usr/share/webapps/gitlab
$ sudo -u gitlab $(cat environment | xargs) bundle-2.7 exec rake gitlab:setup

Finally run the following commands to check your installation:

$ sudo -u gitlab $(cat environment | xargs) bundle-2.7 exec rake gitlab:env:info
$ sudo -u gitlab $(cat environment | xargs) bundle-2.7 exec rake gitlab:check

(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

To access GitLab from an outside network, the upstream documentation recommends to use an established web server as a proxy. All queries from the web server to GitLab are processed by GitLab Workhorse, which decides how they should be processed. See for details.

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.

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

Notice that the SSL virtual host needs a specific IP instead of generic. Also if you set a custom port for Puma, do not forget to set it at the line.

A working example with certbot flavor assuming that contains on the line:

You can easily set up an HTTPS proxy on port 443 to proxy traffic to the GitLab Workhorse using http-master for Node.js. http-master is built on top of node-http-proxy.

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

To validate your URL, the Let's Encrypt process will try to access your GitLab server via a URL such as . Hence, you need to make sure that requests to the subdirectory are not proxied to GitLab Workhorse. This can be done easily with the Certbot's "webroot" method, see Certbot#Webroot for details.

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

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.

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

$ cd /usr/share/webapps/gitlab
$ sudo -u gitlab $(cat environment | xargs) bundle-2.7 exec rake db:migrate

Afterwards, reload and restart , , and .

You can create pacman hooks to automate database upgrades on gitlab package updates. Create the three following files, do not forget to set the executable flag on the shell script:

/etc/pacman.d/hooks/gitlab-pre.hook

[Trigger]
Operation = Upgrade
Type = Package
Target = gitlab

[Action]
Description = Stopping gitlab services
When = PreTransaction
Exec = /usr/bin/systemctl stop gitlab-gitaly.service gitlab-mailroom.service gitlab-puma.service gitlab-sidekiq.service gitlab-workhorse.service

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 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 (e.g. ) requires a bit of extra configuration to work correctly. The user configured in (by default gitlab) must be added to the server's sshd configuration file, in addition to a handful of other changes:

If your contains the option, then the gitlab user should be added to the list:

After updating the configuration file, restart the .

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

$ ssh -T gitlab@your_server

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

You also need to change the corresponding options (e.g. ssh_user, ssh_host, admin_uri) in the file.

GitLab can send emails either using a local mail transfer agent (via sendmail) or using SMTP.

To use sendmail, edit /etc/webapps/gitlab/smtp_settings.rb and comment out all lines. Then mail delivery should work without any further configuration in GitLab, assuming that the local mail transfer agent is configured properly.

To use SMTP, configure the options in according to your mail server. For example, to send via Gmail:

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:

$ sudo -u gitlab $(cat environment | xargs) bundle-2.7 exec 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

Create a backup of the gitlab system:

$ cd /usr/share/webapps/gitlab
$ sudo -u gitlab $(cat environment | xargs) bundle-2.7 exec rake gitlab:backup:create

Restore the previously created backup file :

$ cd /usr/share/webapps/gitlab
$ sudo -u gitlab $(cat environment | xargs) bundle-2.7 exec rake gitlab:backup:restore BACKUP=1556571328_2019_04_29_11.10.2

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 .

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

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

Finally restart the .

Rails console can be used to interface directly with GitLab. See for details.

To access Rails console:

$ cd /usr/share/webapps/gitlab
$ sudo -u gitlab $(cat environment | xargs) bundle-2.7 exec rails console

From here you can troubleshoot problems or do administration tasks like resetting user passwords.

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
$ sudo -u gitlab $(cat environment | xargs) bundle-2.7 exec rake cache:clear

as the gitlab user.

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.

$ sudo -u gitlab $(cat environment | xargs) bundle-2.7 exec rake db:migrate

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

$ sudo -u gitlab $(cat environment | xargs) bundle-2.7 exec rake gitlab:assets:clean gitlab:assets:compile cache:clear

Finally, restart , and .

If a custom repository storage directory is set in , disable the parameter in the (see systemd#Drop-in files and the relevant forum thread on gitlab.com).

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

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

If you have any issues with styles and CSS not working, you may try to edit 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

If you get an error like fatal: the receiving end does not support push options you might need to enable it for the GitLab Git user (gitlab) on the server. This can be done in the gitconfig:

Alternatively one can set this with:

$ sudo -u gitlab -H git config --global receive.advertisePushOptions true