2. Add the GitLab package server and install the package

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash

sudo yum install gitlab-ce

If you are not comfortable installing the repository through a piped script, you can find the entire script here.

Alternatively you can select and download the package manually and install using

curl -LJO https://packages.gitlab.com/gitlab/gitlab-ce/packages/el/6/gitlab-ce-XXX.rpm/download

rpm -i gitlab-ce-XXX.rpm

3. Configure and start GitLab

sudo gitlab-ctl reconfigure

4. Browse to the hostname and login

Username: root 
Password: 5iveL!fe

For configuration and troubleshooting options please see the Omnibus GitLab documentation

Maintenance commands

After installation

Get service status

Run sudo gitlab-ctl status; the output should look like this:

run: nginx: (pid 972) 7s; run: log: (pid 971) 7s

run: postgresql: (pid 962) 7s; run: log: (pid 959) 7s

run: redis: (pid 964) 7s; run: log: (pid 963) 7s

run: sidekiq: (pid 967) 7s; run: log: (pid 966) 7s

run: unicorn: (pid 961) 7s; run: log: (pid 960) 7s

Tail process logs

See doc/settings/logs.md.

Starting and stopping

After omnibus-gitlab is installed and configured, your server will have a Runit service directory (runsvdir) process running that gets started at boot via /etc/inittab or the /etc/init/gitlab-runsvdir.conf Upstart resource. You should not have to deal with the runsvdir process directly; you can use the gitlab-ctl front-end instead.

You can start, stop or restart GitLab and all of its components with the following commands.

# Start all GitLab components

sudo gitlab-ctl start

# Stop all GitLab components

sudo gitlab-ctl stop

# Restart all GitLab components

sudo gitlab-ctl restart

Note that on a single-core server it may take up to a minute to restart Unicorn and Sidekiq. Your GitLab instance will give a 502 error until Unicorn is up again.

It is also possible to start, stop or restart individual components.

sudo gitlab-ctl restart sidekiq

Unicorn supports zero-downtime reloads. These can be triggered as follows:

sudo gitlab-ctl hup unicorn

Note that you cannot use a Unicorn reload to update the Ruby runtime.

Invoking Rake tasks

To invoke a GitLab Rake task, use gitlab-rake. For example:

sudo gitlab-rake gitlab:check

Leave out 'sudo' if you are the 'git' user.

Contrary to with a traditional GitLab installation, there is no need to change the user or the RAILS_ENV environment variable; this is taken care of by the gitlab-rake wrapper script.

Starting a Rails console session

If you need access to a Rails production console for your GitLab installation you can start one with the command below. Please be warned that it is very easy to inadvertently modify, corrupt or destroy data from the console.

# start a Rails console for GitLab

sudo gitlab-rails console

Configuring a relative URL for Gitlab

Note: Relative URL support in Omnibus GitLab is experimental and was introduced in version 8.5. For source installations there is aseparate document.

While it is recommended to install GitLab in its own (sub)domain, sometimes this is not possible due to a variety of reasons. In that case, GitLab can also be installed under a relative URL, for example https://example.com/gitlab.

Note that by changing the URL, all remote URLS will change, so you'll have to manually edit them in any local repository that points to your GitLab instance.

Relative URL requirements

The Omnibus GitLab package is shipped with pre-compiled assets (CSS, JavaScript, fonts, etc.). If you configure Omnibus with a relative URL, the assets will need to be recompiled, which is a task which consumes a lot of CPU and memory resources. To avoid out-of-memory errors, you should have at least 2GB of RAM available on your system, while we recommend 4GB RAM, and 4 or 8 CPU cores.

Enable relative URL in GitLab

Follow the steps below to enable relative URL in GitLab:

1. (Optional) If you run short on resources, you can temporarily free up some memory by shutting down Unicorn and Sidekiq with the following command:

   sudo gitlab-ctl stop unicorn
   
   sudo gitlab-ctl stop sidekiq

2. Set the external_url in /etc/gitlab/gitlab.rb:

   external_url "https://example.com/gitlab"

   In this example, the relative URL under which GitLab will be served will be /gitlab. Change it to your liking.

3. Reconfigure GitLab for the changes to take effect:

   sudo gitlab-ctl reconfigure

4. Restart GitLab in case you shut down Unicorn and Sidekiq in the first step:

   sudo gitlab-ctl restart

If you stumble upon any issues, see the [troubleshooting section] (#relative-url-troubleshooting).

Disable relative URL in GitLab

To disable the relative URL, follow the same steps as above and set up the external_url to a one that doesn't contain a relative path. You may need to explicitly restart Unicorn after the reconfigure task is done:

sudo gitlab-ctl restart unicorn

If you stumble upon any issues, see the [troubleshooting section] (#relative-url-troubleshooting).

Relative URL troubleshooting

If for some reason the asset compilation fails (i.e. the server runs out of memory), you can execute the task manually after you addressed the issue (e.g. add swap):

sudo NO_PRIVILEGE_DROP=true USE_DB=false gitlab-rake assets:clean assets:precompile

sudo chown -R git:git /var/opt/gitlab/gitlab-rails/tmp/cache

User and path might be different if you changed the defaults of user['username'], user['group'] and gitlab_rails['dir']in gitlab.rb. In that case, make sure that the chown command above is run with the right username and group.

Loading external configuration file from non-root user

Omnibus-gitlab package loads all configuration from /etc/gitlab/gitlab.rb file. This file has strict file permissions and is owned by the root user. The reason for strict permissions and ownership is that /etc/gitlab/gitlab.rb is being executed as Ruby code by the root user during gitlab-ctl reconfigure. This means that users who have write access to/etc/gitlab/gitlab.rb can add configuration that will be executed as code by root.

In certain organizations it is allowed to have access to the configuration files but not as the root user. You can include an external configuration file inside /etc/gitlab/gitlab.rb by specifying the path to the file:

from_file "/home/admin/external_gitlab.rb"

Please note that code you include into /etc/gitlab/gitlab.rb using from_file will run with root privileges when you runsudo gitlab-ctl reconfigure. Any configuration that is set in /etc/gitlab/gitlab.rb after from_file is included will take precedence over the configuration from the included file.

Storing Git data in an alternative directory

By default, omnibus-gitlab stores the Git repository data under /var/opt/gitlab/git-data. The repositories are stored in a subfolder repositories. You can change the location of the git-data parent directory by adding the following line to/etc/gitlab/gitlab.rb.

git_data_dir "/mnt/nas/git-data"

Note that the target directory and any of its subpaths must not be a symlink.

Run sudo gitlab-ctl reconfigure for the change to take effect.

If you already have existing Git repositories in /var/opt/gitlab/git-data you can move them to the new location as follows:

# Prevent users from writing to the repositories while you move them.

sudo gitlab-ctl stop

# Note there is _no_ slash behind 'repositories', but there _is_ a

# slash behind 'git-data'.

sudo rsync -av /var/opt/gitlab/git-data/repositories /mnt/nas/git-data/

# Fix permissions if necessary

sudo gitlab-ctl reconfigure

# Double-check directory layout in /mnt/nas/git-data. Expected output:

# gitlab-satellites  repositories

sudo ls /mnt/nas/git-data/

# Done! Start GitLab and verify that you can browse through the repositories in

# the web interface.

sudo gitlab-ctl start

Changing the name of the Git user / group

By default, omnibus-gitLab uses the user name git for Git gitlab-shell login, ownership of the Git data itself, and SSH URL generation on the web interface. Similarly, git group is used for group ownership of the Git data.

We do not recommend changing the user/group of an existing installation because it can cause unpredictable side-effects. If you still want to do change the user and group, you can do so by adding the following lines to /etc/gitlab/gitlab.rb.

user['username'] = "gitlab"

user['group'] = "gitlab"

Run sudo gitlab-ctl reconfigure for the change to take effect.

Note that if you are changing the username of an existing installation, the reconfigure run won't change the ownership of the nested directories so you will have to do that manually. Make sure that the new user can access repositories as well as theuploads directory.

Specify numeric user and group identifiers

omnibus-gitlab creates users for GitLab, PostgreSQL, Redis and NGINX. You can specify the numeric identifiers for these users in /etc/gitlab/gitlab.rb as follows.

user['uid'] = 1234

user['gid'] = 1234

postgresql['uid'] = 1235

postgresql['gid'] = 1235

redis['uid'] = 1236

redis['gid'] = 1236

web_server['uid'] = 1237

web_server['gid'] = 1237

Run sudo gitlab-ctl reconfigure for the changes to take effect.

Disable user and group account management

By default, omnibus-gitlab takes care of user and group accounts creation as well as keeping the accounts information updated. This behaviour makes sense for most users but in certain environments user and group accounts are managed by other software, eg. LDAP.

In order to disable user and group accounts management, in /etc/gitlab/gitlab.rb set:

manage_accounts['enable'] = false

Warning Omnibus-gitlab still expects users and groups to exist on the system where omnibus-gitlab package is installed.

By default, omnibus-gitlab package expects that following users exist:

# GitLab user (required)

git

# Web server user (required)

gitlab-www

# Redis user for GitLab (only when using packaged Redis)

gitlab-redis

# Postgresql user (only when using packaged Postgresql)

gitlab-psql

# GitLab Mattermost user (only when using GitLab Mattermost)

mattermost

By default, omnibus-gitlab package expects that following groups exist:

# GitLab group (required)

git

# Web server group (required)

gitlab-www

# Redis group for GitLab (only when using packaged Redis)

gitlab-redis

# Postgresql group (only when using packaged Postgresql)

gitlab-psql

# GitLab Mattermost group (only when using GitLab Mattermost)

mattermost

You can also use different user/group names but then you must specify user/group details in /etc/gitlab/gitlab.rb, eg.

# Do not manage user/group accounts

manage_accounts['enable'] = false

# GitLab

user['username'] = "custom-gitlab"

user['group'] = "custom-gitlab"

user['shell'] = "/bin/sh"

user['home'] = "/var/opt/custom-gitlab"

# Web server

web_server['username'] = 'webserver-gitlab'

web_server['group'] = 'webserver-gitlab'

web_server['shell'] = '/bin/false'

web_server['home'] = '/var/opt/gitlab/webserver'

# Postgresql (not needed when using external Postgresql)

postgresql['username'] = "postgres-gitlab"

postgresql['shell'] = "/bin/sh"

postgresql['home'] = "/var/opt/postgres-gitlab"

# Redis (not needed when using external Redis)

redis['username'] = "redis-gitlab"

redis['shell'] = "/bin/false"

redis['home'] = "/var/opt/redis-gitlab"

# And so on for users/groups for GitLab CI GitLab Mattermost

Only start Omnibus-GitLab services after a given filesystem is mounted

If you want to prevent omnibus-gitlab services (NGINX, Redis, Unicorn etc.) from starting before a given filesystem is mounted, add the following to /etc/gitlab/gitlab.rb:

# wait for /var/opt/gitlab to be mounted

high_availability['mountpoint'] = '/var/opt/gitlab'

Run sudo gitlab-ctl reconfigure for the change to take effect.

Setting up LDAP sign-in

See doc/settings/ldap.md.

Enable HTTPS

See doc/settings/nginx.md.

Redirect HTTP requests to HTTPS.

See doc/settings/nginx.md.

Change the default port and the ssl certificate locations.

See doc/settings/nginx.md.

Use non-packaged web-server

For using an existing Nginx, Passenger, or Apache webserver see doc/settings/nginx.md.

Using a non-packaged PostgreSQL database management server

To connect to an external PostgreSQL or MySQL DBMS see doc/settings/database.md (MySQL support in the Omnibus Packages is Enterprise Only).

Using a non-packaged Redis instance

See doc/settings/redis.md.

Adding ENV Vars to the GitLab Runtime Environment

See doc/settings/environment-variables.md.

Changing GitLab.yml settings

See doc/settings/gitlab.yml.md.

Sending application email via SMTP

See doc/settings/smtp.md.

Omniauth (Google, Twitter, GitHub login)

Omniauth configuration is documented in doc.gitlab.com.

Adjusting Unicorn settings

See doc/settings/unicorn.md.

Setting the NGINX listen address or addresses

See doc/settings/nginx.md.

Inserting custom NGINX settings into the GitLab server block

See doc/settings/nginx.md.

Inserting custom settings into the NGINX config