Установка GitLab CE за прокси Nginx | Блог NetPoint

Introduction

GitLab, specifically GitLab CE (Community Edition), is an open source application primarily used to host Git repositories, with additional development-related features like issue tracking. The GitLab project makes it relatively straight forward to set up a GitLab instance on your own hardware with an easy installation mechanism.

Add a custom domain to Pages

Navigate to your project’s Setting > Pages and click New domain
to add your custom domain to GitLab Pages. You can choose whether to:

Click Create New Domain.

Get the verification code

After you add a new domain to Pages, the verification code prompts you. Copy the values from GitLab
and paste them in your domain’s control panel as a TXT record on the next step.

Set up DNS records for Pages

Read this document for an overview of DNS records for Pages.
If you’re familiar with the subject, follow the instructions below
according to the type of domain you want to use with your Pages site:

Verify the domain’s ownership

Once you have added all the DNS records:

1. Go back at your project’s Settings > Pages.
2. Locate your domain name and click Details.
3. Click the Retry verification button to activate your new domain.

As soon as your domain becomes active, your website is available through your domain name.

WARNING:
Considering GitLab instances with domain verification enabled,
if the domain can’t be verified for 7 days, it’s removed
from the GitLab project.

Notes:

Adding an ssl/tls certificate to pages

Read this document for an overview on SSL/TLS certification.

To secure your custom domain with GitLab Pages you can opt by:

Adding more domain aliases

You can add more than one alias (custom domains and subdomains) to the same project.
An alias can be understood as having many doors leading to the same room.

All the aliases you’ve set to your site are listed on Setting > Pages.
From that page, you can view, add, and remove them.

Additional troubleshooting

For additional troubleshooting steps, see Troubleshooting SSL.

Automatic let’s encrypt renewal

Introduced in GitLab 10.7.

Available ssl configuration tasks

Omnibus-GitLab supports several common use cases for SSL configuration.

Common ssl errors

1. SSL certificate problem: unable to get local issuer certificate

   This error indicates the client cannot get the root CA. To fix this, you can either trust the root CA of the server you are trying to connect to on the client or modify the certificate to present the full chained certificate on the server you are trying to connect to.

   NOTE:
   It is recommended to use the full certificate chain in order to prevent SSL errors when clients connect. The full certificate chain order should consist of the server certificate first, followed by all intermediate certificates, with the root CA last.

2. unable to verify the first certificate

   This error indicates that an incomplete certificate chain is being presented by the server. To fix this error, you will need to replace server’s certificate with the full chained certificate. The full certificate chain order should consist of the server certificate first, followed by all intermediate certificates, with the root CA last.

3. certificate signed by unknown authority

   This error indicates that the client does not trust the certificate or CA. To fix this error, the client connecting to server will need to trust the certificate or CA.

4. SSL certificate problem: self signed certificate in certificate chain

   This error indicates that the client does not trust the certificate or CA. To fix this error, the client connecting to server will need to trust the certificate or CA.

Custom certificates missing or skipped

GitLab versions 8.9.0, 8.9.1, and 8.9.2 all mistakenly used the
/etc/gitlab/ssl/trusted-certs/ directory. This directory is safe to remove if it
is empty. If it still contains custom certificates then move them to /etc/gitlab/trusted-certs/
and run gitlab-ctl reconfigure.

If no symlinks are created in /opt/gitlab/embedded/ssl/certs/ and you see
the message “Skipping cert.pem” after running gitlab-ctl reconfigure, that
means there may be one of four issues:

1. The file in /etc/gitlab/trusted-certs/ is a symlink
2. The file is not a valid PEM or DER-encoded certificate
3. Perl is not installed on the operating system which is needed for c_rehash to properly symlink certificates.
4. The certificate contains the string TRUSTED

Test the certificate’s validity using the commands below:

/opt/gitlab/embedded/bin/openssl x509 -in /etc/gitlab/trusted-certs/example.pem -text -noout
/opt/gitlab/embedded/bin/openssl x509 -inform DER -in /etc/gitlab/trusted-certs/example.der -text -noout

Invalid certificate files produce the following output:

unable to load certificate
140663131141784:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:701:Expecting: TRUSTED CERTIFICATE

To test if c_rehash is not symlinking the certificate due to a missing perl interpreter:

$ /opt/gitlab/embedded/bin/c_rehash /etc/gitlab/trusted-certs

bash: /opt/gitlab/embedded/bin/c_rehash: /usr/bin/perl: bad interpreter: No such file or directory

If you see this message, you will need to install perl with your distribution’s package manager.

If you inspect the certificate itself, then look for the string TRUSTED:

-----BEGIN TRUSTED CERTIFICATE-----
...
-----END TRUSTED CERTIFICATE-----

If it does, like the example above, then try removing the string TRUSTED and running gitlab-ctl reconfigure again.

Custom certificates not detected

If after running gitlab-ctl reconfigure:

1. no symlinks are created in /opt/gitlab/embedded/ssl/certs/;
2. you have placed custom certificates in /etc/gitlab/trusted-certs/; and
3. you do not see any skipped or symlinked custom certificate messages

You may be encountering an issue where Omnibus GitLab thinks that the custom
certificates have already been added.

To resolve, delete the trusted certificates directory hash:

rm /var/opt/gitlab/trusted-certs-directory-hash

Then run gitlab-ctl reconfigure again. The reconfigure should now detect and symlink
your custom certificates.

Details on how gitlab and ssl work

GitLab-Omnibus includes its own library of OpenSSL and links all compiled
programs (e.g. Ruby, PostgreSQL, etc.) against this library. This library is
compiled to look for certificates in /opt/gitlab/embedded/ssl/certs.

GitLab-Omnibus manages custom certificates by symlinking any certificate that
gets added to /etc/gitlab/trusted-certs/ to /opt/gitlab/embedded/ssl/certs
using the c_rehash
tool. For example, let’s suppose we add customcacert.pem to
/etc/gitlab/trusted-certs/:

Here we see the fingerprint of the certificate is 7f279c95, which links to
the custom certificate.

Edit the gitlab configuration

Start by opening up the GitLab configuration file again:

Gitlab components

Introduced in GitLab 11.0.

Follow the steps to enable basic Let’s Encrypt integration and
modify /etc/gitlab/gitlab.rb with any of the following that apply:

Git-lfs and other embedded services written in golang report custom certificate signed by unknown authority

NOTE:
In GitLab 11.5, the following workaround is no longer necessary, embedded golang apps now use the standard GitLab certificate directory automatically.

The gitlab-workhorse and other services written in golang use the crypto/tls library from golang
instead of OpenSSL.

Add the following entry in /etc/gitlab/gitlab.rb to work around the
issue as reported:

NOTE:
If you have installed GitLab to a path other than /opt/gitlab/ then modify the entry above
with the correct path in your operating environment.

Install custom public certificates

NOTE:
A perl interpreter is required for c_rehash dependency to properly symlink the certificates.
Perl is currently not bundled in Omnibus GitLab.

Let’s encrypt certificate signed by unknown authority

The initial implementation of Let’s Encrypt integration only used the certificate, not the full certificate chain.

Starting in 10.5.4, the full certificate chain will be used. For installs which are already using a certificate, the switchover will not happen until the renewal logic indicates the certificate is near expiration. To force it sooner, run the following

Where HOSTNAME is the hostname of the certificate.

Let’s encrypt fails on reconfigure

When you reconfigure, there are common scenarios under which Let’s Encrypt may fail:

Manual addition of ssl/tls certificates

You can use any certificate satisfying the following requirements:

For example, Cloudflare certificates
meet these requirements.

Manual let’s encrypt renewal

Renew Let’s Encrypt certificates manually using one of the following commands:

sudo gitlab-ctl reconfigure

sudo gitlab-ctl renew-le-certs

WARNING:
GitLab 12.1 or later will attempt to renew any Let’s Encrypt certificate.
If you plan to use your own Let’s Encrypt certificate you must set letsencrypt[‘enable’] = false
in /etc/gitlab/gitlab.rb to disable integration. Otherwise the certificate
could be overwritten due to the renewal.

NOTE:
The above commands require root privileges and only generate a renewal if the certificate is close to expiration.
Consider the upstream rate limits if encountering an error during renewal.

Other certificate authorities

Omnibus GitLab supports connections to external services with
self-signed certificates.

NOTE:
Custom certificates were introduced in GitLab 8.9.

Reconfigure fails due to certificates

ERROR: Not a certificate: /opt/gitlab/embedded/ssl/certs/FILE. Move it from /opt/gitlab/embedded/ssl/certs to a different location and reconfigure again.

Check /opt/gitlab/embedded/ssl/certs and remove any files other than README.md that aren’t valid X.509 certificates.

NOTE:
Running gitlab-ctl reconfigure constructs symlinks named from the subject hashes
of your custom public certificates and places them in /opt/gitlab/embedded/ssl/certs/.
Broken symlinks in /opt/gitlab/embedded/ssl/certs/ will be automatically removed.

Reconfigure gitlab to enable ssl

Now, reconfigure GitLab again to implement your changes:

Set up pages with a custom domain

To set up Pages with a custom domain name, read the requirements
and steps below.

Ssl_connect wrong version number

A misconfiguration may result in:

Status: deprecated

This article covers an older method of configuring GitLab with Let’s Encrypt manually. As of GitLab version 10.5, Let’s Encrypt support is available natively within Gitlab.

Our guide on How To Install and Configure GitLab on Ubuntu 16.04 has been updated to include the relevant configuration settings within GitLab. We recommend referring to that guide moving forward.

Troubleshooting pages domain verification

To manually verify that you have properly configured the domain verification
TXT DNS entry, you can run the following command in your terminal:

dig _gitlab-pages-verification-code.<YOUR-PAGES-DOMAIN> TXT

Expect the output:

;; ANSWER SECTION:_gitlab-pages-verification-code.<YOUR-PAGES-DOMAIN>. 300 IN TXT "gitlab-pages-verification-code=<YOUR-VERIFICATION-CODE>"

In some cases it can help to add the verification code with the same domain name as you are trying to register.

For a root domain:

For a subdomain:

Useful openssl debugging commands

Sometimes it’s helpful to get a better picture of the SSL certificate chain by viewing it directly
at the source. These commands are part of the standard OpenSSL library of tools for diagnostics and
debugging.

NOTE:
GitLab includes its own custom-compiled version of OpenSSL
that all GitLab libraries are linked against. It’s important to run the following commands using
this OpenSSL version.

Using gitlab runner with a gitlab instance configured with internal ca certificate or self-signed certificate

Besides getting the errors mentioned in
Using an internal CA certificate with GitLab,
your CI pipelines may get stuck in Pending status. In the runner logs you may
see the following error message:

Добавление ssh ключа

Для работы с Git и GitLab можно указать публичный SSH ключ, чтобы не приходилось каждый раз вводить пароль вашей учетной записи.

Введите команду (если у вас уже существует ключ):

cat ~/.ssh/id_rsa.pub

Команда вернет следующий результат:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC5onOVtATUjVkqk91lq v0g5TzOZTMBp4avWLEZO/97jQa1PL7y4zx4iOmUDOdlux/gC QSW0knti/yJrtzPJibDOedRJ9KkPPGpyD1JPqRGiy3eEY2gs755McfopX6U99aYjUVBgtcfX5AXp1 5Dd9jJEFhhEDDD/WEVfYERP1ZjybaRWy6vykkPa5W2YloXRIJq/kJk9ubtd5iGnRJfDZrkza2Q97ruNGWbeEty4rgDVNwb/Znz84qt9DzzI9rvlZTfB/9EApmB0Y7eu6vR3AG5T3gBZIAYGdurdqbIj/dI8nUduE9AImzlGxeACKs0iOi/037u5gvB gitlab@netpoint-dc.ml

Это пример ключа. У вас будут свои данные

Скопируйте публичный ключ полностью, перейдите в настройки профиля и нажмите на ссылку «SSH Keys» слева. Вставьте ключ в большое поле и напишите его название в поле Title. Для сохранения (добавления) ключа нажмите на кнопку «Add key».

Если публичного ключа у вас нет, вы получите примерно следующий ответ от команды:

 cat: /home/gitlab/.ssh/id_rsa.pub:  No such file or directory 

Для генерации связки приватного и публичного ключа введите команду:

ssh-keygen -t rsa

У вас должно получиться примерно следующее:

На все вопросы в процессе генерации можно нажимать клавишу «Enter» или ввести подходящую вам директорию.

Снова введите команду для просмотра содержимого публичного ключа

cat ~/.ssh/id_rsa.pub

Скопируйте ключ и введите его в свойствах профиля.

Лимиты по созданию проектов (ограничение)

По умолчанию в GitLab любой пользователь может создать 100000 проектов. Откройте раздел «Account and limit» и измените значение в строке «Default projects limit» на 0 , нажмите на кнопку «Save changes». Значение «0» необходимо, когда нужно запретить пользователям создание проектов.

Настройка nginx

Откройте ваш конфигурационный файл

CentOSnano /etc/nginx/conf.d/${WEBSITE_NAME}.conf

Debian/Ubuntunano /etc/nginx/sites-available/$WEBSITE_NAME

Настройка профиля

После авторизации нажмите на профиль левой кнопкой мыши в правом верхнем углу и нажмите на пункт «Profile».

Нажмите на кнопку «Edit profile» справа вверху.

Введите ваши данные (email, контакты, имя пользователя, аватар) и нажмите на кнопку «Update profile settings» , чтобы сохранить данные.

Ограничение или блокировка открытой регистрации

На данный момент любой человек может зарегистрироваться в вашем проекте и участвовать в разработке. Вы можете ограничить доступ к проекту или отключить регистрацию совсем.

Нажмите на значок гаечного ключа сверху.

В разделе администратора нажмите на ссылку «Settings» слева

Вас могут заинтересовать следующие категории

В разделе «Sign-up restrictions» уберите отметку с пункта «Sign-up enabled» и сохраните изменения, чтобы убрать возможность регистрации.

Ограничение регистрации по домену

GitLab поддерживает ограничение по домену почты. Установите отметку в пункте » Send confirmation email on sign-up», введите доверенный домен в поле «Whitelisted domains for sign-ups» и нажмите на кнопку «Save changes», чтобы сохранить изменения.

Подготовка к установке gitlab

Обновите индекс пакетов командой:

Debian/Ubuntu

apt-get update

CentOS

yum update

Выполните установку дополнительных компонентов:

Debian/Ubuntu

apt-get install ca-certificates curl postfix 

CentOS

yum install curl policycoreutils postfix

Во время установки будет открыто диалоговое окно для настройки MTA Postfix (почтового сервера). Выберите пункт «Интернет-сайт».

В следующем окне введите реально существующее доменное имя. Доменное имя будет использоваться для отправки с него писем.

Вы можете ввести IP адрес сервера вместо доменного имени, но в таком случае доставка писем на внешние почтовые серверы не гарантируется.

Системные требования

Рекомендуется использовать не менее 8 ГБ оперативной памяти и процессор не менее 2-ух ядер. Более подробно о системных требованиях можно прочитать в документации GitLab.

GitLab может быть установлен в следующих дистрибутивах Linux:

• Ubuntu;
• Debian;
• CentOS;
• openSUSE;
• Red Hat Enterprise Linux (CentOS);
• Scientific Linux (CentOS);
• Oracle Linux (CentOS).

После установки операционной системы подключитесь к ней по SSH для выполнения действий на сервере, где будет работать GitLab CE.

Установка gitlab ce

Процесс установки занимает не так много времени. Воспользуйтесь скриптом для подготовки рабочей среды под GitLab. Будут установлены дополнительные программы и настроено подключение к репозиторию GitLab CE.

Выполните следующую команду для скачивания и выполнения скрипта:

Debian/Ubuntu

Установка и настройка gitlab на ubuntu 18.04 | записки системного администратора

Установка сервера nginx с сертификатом let’s encrypt

Мы будем использовать установку GitLab CE, которая работает за сервером Nginx, который будет выполнять обратное проксирование и осуществлять обработку SSL-трафика. Для настройки базового сервера воспользуйтесь руководством из списка ниже, подходящим для вашей операционной системы.

На данный момент у вас должен быть развернут сервер с Nginx и сертификатом Let’s Encrypt. Теперь установим GitLab CE.