一键安装GitLab7
1. Install and configure the necessary dependencies
If you install Postfix to send email please select 'Internet Site' during setup. Instead of using Postfix you can also use Sendmail or configure a custom SMTP server. If you wish to use Exim, please configure it as an SMTP server.
On Centos 6 and 7, the commands below will also open HTTP and SSH access in the system firewall.
sudo yum install curl openssh-server openssh-clients postfix cronie sudo service postfix start sudo chkconfig postfix on sudo lokkit -s http -s ssh
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-ceIf 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) 7sTail process logs
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 restartNote 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 sidekiqUnicorn supports zero-downtime reloads. These can be triggered as follows:
sudo gitlab-ctl hup unicornNote 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:checkLeave 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:
-
(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 -
Set the
external_urlin/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. -
Reconfigure GitLab for the changes to take effect:
sudo gitlab-ctl reconfigure -
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 unicornIf 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/cacheUser 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 startChanging 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'] = 1237Run 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'] = falseWarning 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)
mattermostBy 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)
mattermostYou 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 MattermostOnly 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
Redirect HTTP requests to HTTPS.
Change the default port and the ssl certificate locations.
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
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.
