aus, Homepage von Ralf und Judith Krüdewagen (Kruedewagen)
Zur Navigation springen Zur Suche springen
GitLab Architecture, Source: GitLab

This page describes operational tasks for maintaining a GitLab platform.


The installation under openSUSE must be done almost manually, since there are no installation packages available for openSUSE. However, on the one hand you learn the best when installing manually, on the other hand the manual installation is quite the same than under the official generic description for Debian. Linux is Linux - and it should not matter which distribution you use unless it's actual enough.


The following link has been used as installation procedure:

Special notes about openSUSE (could party help for handling specific topics like gitlab-shell installation):

This page is useful for understanding the architecture:

Additional repositories

In order to install actual ruby 2 packages (incl. rubygem-bundler), the following repository has been used:

Note: Ruby >= 2.1.6 needed for GitLab 7.14 [1]

Special Notes

Here are some special notes about the installation procedure.

MySQL and Apache

Instead of using the recommended PostgreSQL (as database) and Nginx (as reverse proxy) we use MySQL and Apache, because they are already in use and our standard packages. Using Apache and MySQL is quite well supported and documented (partly by community).


Instead of /home/git the directory /srv/git has been used as home directory of GitLab.


gitlab-shell has been installed by manually cloning the Git repo, described in the links about openSUSE.


  • charlock_holmes needs to be installed (not the latest)
  • When a libmagic.a error occurs during bundle install compilation, you need to unset the CONFIG_SITE variable.

Boot integration

The following init scripts have been manually installed and activated:


In addition, the following init script has been activated:




  • MySQL database: gitlabdb
  • MySQL user: gitlab

Configuration files

The following configuration files are important:

  • ~git/gitlab/config/database.yml
  • ~git/gitlab/config/gitlab.yml
  • ~git/gitlab/config/unicorn.rb
  • ~git/gitlab-shell/config.yml
  • ~git/gitlab/config/application.rb
  • ~git/gitlab/config/environments/production.rb
  • ~git/gitlab/config/initializers/rack_attack.rb
  • /etc/redis/default.conf

Web path

It's not recommended (and not fully supported) to run GitLab within a relative URL path like If you need to run it like that, have a look to the parameter relative_url_root in config file ~git/gitlab/config/gitlab.yml. See also:


The gitlab-shell URL in variable gitlab_url is addressed only internally:

gitlab_url: ""

Therefore, whn not using localhost you need to add to /etc/hosts:       localhost


The standard Unicorn configuration is that the reverse proxy - running on the same host - handles the static web content, which includes CSS files, the uploaded files, user images etc.

If the reverse proxy (like in our setup) is located on another host, it normally can't handle those static files. Therefore, Unicorn needs to be configured to handle this static content [1]. The setting is made in ~git/gitlab/config/environments/production.rb:

config.serve_static_assets = false

In order to access the web service from the "external" reverse proxy, you also need to change the listen parameter in ~git/gitlab/config/unicorn.rb [2]:

listen "8090", :tcp_nopush => true

Network parameters

  • The Unicorn web server listens on port 8090 - on all interfaces (for reverse proxy integration when the reverse proxy does not run on same host)
  • Redis listens on standard port 6379.
  • The gitlab-shell is using the standard SSH port 22.

SSH keys

The SSH keys added via the user profile interface are added to


Reverse Proxy integration

In order to access the GitLab GUI and Git repositories via HTTP on a standard port like 80, a proper integration to Nginx or Apache needs to be performed. This is outlined in the GitLab documentation GitLab recipes - Apache.

See also Notes about static web content provided by Unicorn, see also notes about the Unicorn configuration.


Useful commands

See also


Check proper gitlab-shell configuration and integration:



Check GitLab API access: OK
Check directories and files: 
        /srv/git/projects: OK
        /srv/git/.ssh/authorized_keys: OK
Test redis-cli executable: redis-cli 2.6.14
Send ping to redis server: PONG

Note: The gitlab-shell URL in variable gitlab_url is addressed only internally.

GitLab application


Checking the environment:

cd ~git/gitlab/
bundle exec rake gitlab:env:info RAILS_ENV=production

Output like:

System information
System:         openSUSE project 13.1
Current User:   git
Using RVM:      no
Ruby Version:   2.0.0p247
Gem Version:    2.0.3
Bundler Version:1.6.2
Rake Version:   10.1.1
Sidekiq Version:2.17.0

GitLab information
Version:        6.8.2
Revision:       bfdcbc5
Directory:      /srv/git/gitlab
DB Adapter:     mysql2
SSH Clone URL:
Using LDAP:     no
Using Omniauth: no

GitLab Shell
Version:        1.9.4
Repositories:   /srv/git/projects/
Hooks:          /srv/git/gitlab-shell/hooks/
Git:            /usr/bin/git

Extended check

Checking even more:

cd ~git/gitlab/
bundle exec rake gitlab:check RAILS_ENV=production


In order to re-create the GitLab assets (web components), e.g. after you made some configuration changes, you need to perform:

cd ~git/gitlab/
bundle exec rake assets:clean assets:precompile cache:clear RAILS_ENV=production


  • You can also just use e.g. cache:clear to only run one command.
  • After a cache:clear all user GUI sessions are cleared too.
  • The cache:clear command can be used to re-calculate the repository sizes outlined in the GUI.


GitLab (includes Unicorn and Sidekiq logs):







  • /etc/logrotate.d/gitlab:
# GitLab logrotate settings
# based on:

/srv/git/gitlab/log/*.log {
    rotate 90

/srv/git/gitlab-shell/gitlab-shell.log {
    rotate 90
  • /etc/logrotate.d/redis (from distribution)


Monitoring proper GitLab system and service availability can be done via Icinga.

Following checks should been integrated:

  • checking HTTP Port 80 availability on reverse proxies
  • checking HTTP Port 8090 availability on direct interfaces
  • checking MySQL database
  • checking processes are running: Unicorn, Redis, Sidekiq


Postfix Integration

Try this setting /instead of default "login" value) if you can't authenticate towards a regular user in Postfix:

gitlab_rails['smtp_authentication'] = "plain"


You need to backup

  • The git user home dir (containing software, config and repos)
  • Other configurations (Redis, MySQL, Apache, etc.)
  • Redis dump file(s) in dir
  • MySQL database