Abstract

Представим ситуацию - вы - прошаренный разработчик-сисадмин, просыпаетесь утром, пьёте кофе, на улице поют птички, ничего не предвещает беды. Как вдруг, откуда ни возьмись, появляется босс и требует, чтобы вы срочно подняли GitLab на корпоративном сервере. А на сервере стоит RedOs. Первое что приходит в голову: "А давайте переустановим на что-нибудь другое?" Но за такое вас уволят. Что ж...

В этом непродолжительном туторе настроим свой GitLab на отечественной операционной системе RedOs. Иногда будем ссылаться на уже имеющийся туториал. Если вы не знаете, что такое свой GitLab или какие преимущества он даёт, - обращайтесь к нему. Также есть другая статья (очень хорошая, недавно вышла, для ubuntu-юзеров) на хабре, к которой тоже можно обращаться.

Способы установки

Вы можете поставить GitLab множеством различных способов. Но разберём основные 3:

Пойдём по второму пути.

Что надо?

1. Сервер с проброшенными портами и белым ip, на котором можно поставить (или он уже стоит) RedOs (чисто технически, если там CentOs или Redhat, то тоже норм). Желательно, чтобы на нём было минимум 2 ядра CPU и 2 Гб оперативы.

2. Домен.

3. Уметь пользоваться терминалом.

4. Возможность настраивать dns-записи у своего провайдера домена. gitlab.mydomain.com должен указывать на внешний ip вашего сервера.

5. Умение управлять корпоративной почтой в панели своего провайдера.

Подготовительный этап

Если у вас ещё нету ОС, то самое время передумать поставить её. На комп, который будет использоваться как сервер, поставьте ОС. Во время установки выбирайте сервер-минимальный. Дополнительно сразу отметим некоторые пакеты для установки:

• Средства контроля производительности,

• Python,

• Библиотеки совместимости,

• Контрольные средства интернета,

• Средства разработки,

• Средства администрирования.

Созданного юзера добавляем в группу wheel, чтобы он мог пользоваться sudo -i. Сразу после установки можно поставить самую свежую версию ядра: dnf upgrade.

Чтобы уметь прокручивать историю терминала, а также копи-пастить команды, быстренько настраиваем ssh-подключение по ключу с другого устройства, у которого есть браузер и графическая оболочка. Если вам говорят, что подключение к серверу происходит впервые и что неплохо бы добавить ключ сервера в .ssh/known_host, то верность отпечатка можно проверить, выполнив команду на сервере:

ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub

Как только настроили, удаляем возможность подключения по паролю:

vim /etc/ssh/sshd_config  # Или любой другой терминальный редактор.
PasswordAuthentication no  # Найти эту сторку и установить в `no`.

Если не сказано иного, все остальные команды выполняются на сервере от имени суперпользователя.

Почта

Настроим postfix. Поставим сразу дополнительно парочку важных пакетов и, например, докер.

yum install postfix docker-ce curl policycoreutils-python "libcrypt.so.1()(64bit)"

Если бы мы ставили на Debian или Ubuntu, нам бы высветилось окошко с возможностью первоначальной конфигурацией smtp-менеджера. В нашем случае - настройка через relay- (smart-) host. Открываем и редактируем файл конфигурации /etc/postfix/main.cf.

Конфигурация, если ваш smart-host - это mail.ru для бизнеса.

Mail.ru для бизнеса - возможность управлять почтовыми ящиками своих пользователей, создавать и устанавливать им пароли, а также рассылать сообщения. В бесплатном тарифе там доступно до 300 пользователей.

Если у вас ещё нет своей почты, но есть домен и доступ к его dns-панели, можете создать корпоративную почту в своём домене. Чтобы убедиться в том, что домен действительно принадлежит вам, mail.ru потребует либо html-ответ, либо dns-запись, а также предложит парочку других вариантов. Если ваш сервер ещё не может отвечать на запросы, dns-запись - предпочтительный вариант. Если вы выгрузили dns-зону, то изменения распространятся не сразу. Чуть дальше будет рассказано, как убедиться, что dns-записи готовы к проверке.

Конфигурация postfix:

queue_directory = /var/spool/postfix
command_directory = /usr/sbin
data_directory = /var/lib/postfix
mail_owner = postfix
myhostname = root.mydomain.com
mydomain = mydomain.com
inet_interfaces = 127.0.0.1, 192.168.31.84  # Вторым идёт ваш локальный ip!
inet_protocols = ipv4
mydestination = $myhostname, localhost.$mydomain, localhost
mynetworks = 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
unknown_local_recipient_reject_code = 550

relayhost = [smtp.mail.ru]:587  # Relay-host mail.ru для бизнеса.

debug_peer_level = 2
debugger_command =
	 PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
	 ddd $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail.postfix
newaliases_path = /usr/bin/newaliases.postfix
mailq_path = /usr/bin/mailq.postfix
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix/samples
readme_directory = /usr/share/doc/postfix/README_FILES
smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem
smtpd_tls_key_file = /etc/pki/tls/private/postfix.key
smtp_tls_security_level = encrypt
smtp_tls_CApath = /etc/pki/tls/certs
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
meta_directory = /etc/postfix
shlib_directory = /usr/lib64/postfix
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_type = cyrus
smtp_sasl_path = private/auth
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_mechanism_filter = plain
smtp_generic_maps = hash:/etc/postfix/generic

Создаём файл паролей:

# cat /etc/postfix/sasl_passwd
[smtp.mail.ru]:587 admin@mydomain.com:cjELGQu5pDHENwq8jbuE

Чтобы получить пароль (который идёт после двоеточия), надо в mail.ru зайти в свой почтовый ящик. Далее -> настройки -> безопасность -> пароли для внешних приложений -> добавить.

Создаём файл адресов отправителей:

# cat /etc/postfix/generic
root@root.mydomain.com  admin@mydomain.com

Хэшируем файлы:

postmap /etc/postfix/generic /etc/postfix/sasl_passwd
chmod go-r /etc/postfix/sasl_passwd /etc/postfix/generic
ls -la  # Должны появиться файлы sasl_passwd.db generic.db

Перезапускаем сервис:

service postfix restart
service postfix status  # Перезапустился?
journalctl -xe  # Посмотреть ошибки.

Теперь можете проверить работу почты:

echo "Subject: hello" | sendmail.postfix other-sendbox@mail.ru
# На other-sendbox@mail.ru почта приходит мгновенно.
# Если не пришла, значит вы что-то неправильно сделали. Посмотреть лог:
cat /var/log/maillog

service postfix restart

Установка certbot

Все мы любим https за то, что в браузерах рядом с нашим сайтом есть зелёный щит или значок замка́. Чтобы воспользоваться такой возможностью, надо поставить certbot, который в будущем поможет нам получить сертификаты от letsencrypt. По официальной документации его можно поставить через snapd.

dnf install snapd -y
systemctl enable --now snapd.socket
sleep 20  # Подождать пару сек, потому что может кинуть "error: too early for operation, device not yet seeded or device model not acknowledged"
snap install core
ln -s /var/lib/snapd/snap /snap
snap install --classic certbot
# certbot 1.32.0 from Certbot Project (certbot-eff✓) installed

БД

Для GitLab требуется redis и postgresql. Лучше поставить 12 версию.

yum install redis postgresql-server
postgresql-setup initdb  # Обязательно, без этого БД с ходу не будет работать.
systemctl enable postgresql 
systemctl start postgresql 
systemctl status postgresql
# Проверим, что можно подключиться... Откроем терминал postgres:
sudo -u postgres psql 
\l
## Покажет таблицу
exit ## Выйти обратно в терминал

GitLab

Теперь всё готово. Выполняем скрипт:

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo os=centos dist=7 bash

Чтобы обмануть систему говорим ему, что пользуемся не отечественной ОС, а иностранной.

Потом ставим сам пакет, указав домен. Через переменную окружения можно передать начальный пароль администратора.

EXTERNAL_URL="http://gitlab.mydomain.com" GITLAB_ROOT_PASSWORD="gitlab_root_password" yum install gitlab-ce

Если вы имели бэкап (версии той же, что и установили), можете его применить.

А после установки надо подправить файл /etc/gitlab/gitlab.rb (почитайте какие настройки там есть и подредачьте их), потом выполните gitlab-ctl reconfigure.Минимум один раз перед загрузкой бэкапа реконфигурацию надо сделать.

HTTPS

Можете попробовать автоматическое получение сертификатов через letsencrypt['enable'] = true, но у меня он не сработал.

Ok, если надо получить сертификаты, есть два сценария - во-первых, на один ваш домен, во-вторых, на wildcard-домены типа таких, какие нужны для GitLab Pages. В процессе от вас в любом случае потребуют добавить dns-запись, которая после выгрузки зоны распространится не сразу. Проверить, появились ли dns-записи на вашем сайте, можно при помощи онлайн-утилит, например, таких. Команда получения сертификата для одного домена примерно такая:

certbot certonly --standalone --agree-tos --preferred-challenges http -d gitlab.mydomain.com

Для pages.mydomain.com ситуация немного другая. Для каждого пользователя, который будет создавать свой GitLab Page, будет выделен поддомен, а статические файлы будут хоститься на username.pages.mydomain.com/project-name. Есть прекрасная статья, где говорится, как получать wildcard-сертификаты:

certbot --manual --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns certonly --server https://acme-v02.api.letsencrypt.org/directory -d *.pages.mydomain.com -d pages.mydomain.com

Все сертификаты сохраняются в /etc/letsencrypt/live/subdomain.mydomain.com/*.pem. Нас интересуют файлы fullchain.pem и privkey.pem. Их надо переместить в нужную папку, чтобы GitLab их увидел. Ключ -L добавляем, потому что в указанных папках лежат символьные ссылки на ../../archive.

cp -L /etc/letsencrypt/live/gitlab.mydomain.com/fullchain.pem /etc/gitlab/ssl/gitlab.mydomain.com.crt
cp -L /etc/letsencrypt/live/gitlab.mydomain.com/privkey.pem /etc/gitlab/ssl/gitlab.mydomain.com.key
cp -L /etc/letsencrypt/live/pages.mydomain.com/fullchain.pem /etc/gitlab/ssl/pages.mydomain.com.crt
cp -L /etc/letsencrypt/live/pages.mydomain.com/privkey.pem /etc/gitlab/ssl/pages.mydomain.com.key
chmod -R go+r /etc/gitlab/ssl/  # Чтобы он 100% смог их прочитать.

external_url 'https://gitlab.mydomain.com'
gitlab_rails['time_zone'] = 'Europe/Moscow'
gitlab_rails['gitlab_email_enabled'] = true
gitlab_rails['gitlab_email_from'] = 'admin@mydomain.com'
gitlab_rails['gitlab_email_display_name'] = 'GitLab'
gitlab_rails['gitlab_default_theme'] = 2
gitlab_rails['gitlab_default_projects_features_issues'] = true
gitlab_rails['gitlab_default_projects_features_merge_requests'] = true
gitlab_rails['gitlab_default_projects_features_wiki'] = false
gitlab_rails['gitlab_default_projects_features_snippets'] = false
gitlab_rails['gitlab_default_projects_features_builds'] = true
gitlab_rails['gitlab_default_projects_features_container_registry'] = true
gitlab_rails['artifacts_enabled'] = true
gitlab_rails['lfs_enabled'] = true
gitlab_rails['manage_backup_path'] = true
gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"
gitlab_rails['backup_gitaly_backup_path'] = "/opt/gitlab/embedded/bin/gitaly-backup"
gitlab_rails['backup_keep_time'] = 2419200
gitlab_rails['registry_enabled'] = false
gitlab_shell['gitlab_url'] = "https://gitlab.mydomain.com"
nginx['enable'] = true
nginx['redirect_http_to_https'] = true
pages_external_url "https://pages.mydomain.com"
gitlab_pages['enable'] = true
gitlab_pages['access_control'] = false
pages_nginx['enable'] = true
pages_nginx['redirect_http_to_https'] = true
pages_nginx['ssl_certificate'] = "/etc/gitlab/ssl/pages.mydomain.com.crt"
pages_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/pages.mydomain.com.key"
letsencrypt['enable'] = false

Кофигурируем, перезапускаем, проверяем:

gitlab-ctl reconfigure && gitlab-ctl restart && sleep 120 && gitlab-rake gitlab:check

Задержка нужна, потому что сразу gitlab-shell не поднимется и ему нужно раскачаться. Если запустить проверку сразу после перезапуска, у вас не всё будет так гладко, как если бы вы проверили то же самое, но через некоторое время.

Если у вас в локальной сети есть ещё компьютеры, и вы хотите с них зайти на свой сайт, то существуют два пути решения проблемы: поднять свой dns-сервер или на каждой локальной машине, подключённой к тому же роутеру, что и сервер, редактировать файл /etc/hosts:

127.0.0.1	    localhost
192.168.31.84   gitlab.mydomain.com  # Локальный ip вашего сервера.

Теперь можете заходить на gitlab.mydomain.com с логином root и паролем, который указали при установке.

Проверка GitLab

Чтобы проверить, что всё идеально работает, осталось совсем немного.

type=AVC msg=audit(1669722871.540:475): avc:  denied  { read } for  pid=2319 comm="sshd" name="authorized_keys" dev="sda3" ino=7625832 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_t:s0 tclass=file permissive=0

setenforce 0  # Отключить временно в текущем сеансе
sed -i "s/SELINUX=enforcing/SELINUX=disabled/" /etc/selinux/config  # Отключить навсегда (требуется перезагрузка)

yum install firewalld
systemctl start firewalld.service
firewall-cmd --permanent --allow-service=http
firewall-cmd --permanent --allow-service=https
firewall-cmd --permanent --allow-service=ssh
firewall-cmd --reload
# Посмотреть:
firewall-cmd --list-all

cat /var/log/audit/audit.log | grep 185.145.201.29 | wc
## 1950 ... ... <-- Если это значение с каждой минутой будет возрастать, значит кто-то пытается залезть в систему.

# Заблокируем этот адрес и обновим файервол:
firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='185.145.201.29' reject"
firewall-cmd --reload

# Опустошим логи и проверим ещё раз:
echo '' > /var/log/audit/audit.log  # Не удаляйте файл!
cat /var/log/audit/audit.log | grep 185.145.201.29 | wc
## 0 0 0 <-- сколько раз вы бы не вызывали предыдущую команду, заблокированный адрес уже никогда не появится в логах!

Сейчас любой в интернете может зарегистрироваться как новый пользователь. Чтобы избежать проблем заходим в админ-панель, Settings -> General -> Sign-up restrictions -> Allowed domains for sign-ups. Установите ограничение только на почту в вашем домене, пролистайте чуть ниже и сохраните изменения.

По умолчанию должен был быть создан репозиторий Monitoring, попробуйте его склонировать на другом компьютере, предварительно добавив ssh-ключи в аккаунт. Добавьте парочку файлов, сделайте коммит и пуш. Проверьте, что ваши изменения есть на сайте.

Этой конфигурации может быть достаточно для большинства нужд. Можете настроить gitlab-runners и проверить GitLab Ci/Cd, гайдов по этому в интернете полным-полно.

Ну а мы пойдём немного дальше, добавим конфигурацию nginx.

NGINX

yum install nginx

В конфигурации GitLab не забудьте отключить nginx: nginx['enable'] = false. По умолчанию создаётся юзер nginx для подключения к файлам самим сервисом. В конфиге GitLab надо добавить этого юзера: web_server['external_users'] = ['nginx', 'gitlab-www', 'git'].

Для настройки nginx конфига его надо скачать (вот это поворот, да?). Есть разница в том, что в RedOs нету папок sites-available и sites-enabled, тут только /etc/nginx/conf.d/, куда надо класть файлы с расширением .conf. Также имеет смысл зайти в основной файл (vim /etc/nginx/nginx.conf), который будет эти конфиги подтягивать, и удалить там дефолтный server-блок (если, конечно, вы не собираетесь хостить на этом сервере ещё что-нибудь). Кладём конфиг nginx в нужное место:

wget https://gitlab.com/gitlab-org/gitlab-recipes/-/raw/master/web-server/nginx/gitlab-omnibus-ssl-nginx.conf?inline=false
mv gitlab-omnibus-ssl-nginx.conf\?inline\=false  /etc/nginx/conf.d/gitlab.conf
vim /etc/nginx/conf.d/gitlab.conf  # Или любой другой редактор.

Заменяем YOUR_SERVER_FQDN на свой домен, где будет крутиться GitLab, например gitlab.mydomain.com. Кста, ещё можно и путь к сертификатам указать! Аргументы ipv6only=on можете сразу удалять, сейчас они не поддерживаются. Ещё там есть строка ssl on, поскольку этот конфиг создавался 2 года назад, сейчас уже всё по-другому, эту строку тоже можно удалить (иначе nginx выкинет предупреждение).

listen 0.0.0.0:80;
listen [::]:80;
server_name gitlab.mydomain.com;
...
ssl_certificate /etc/gitlab/ssl/gitlab.mydomain.com.crt;
ssl_certificate_key /etc/gitlab/ssl/gitlab.mydomain.com.key;

Проверьте, что ваш конфиг нормальный nginx -t и перезапустите сервис: nginx -s reload. Но перед этим убедитесь, что конфиг вашего GitLab соответствует действительности и перезапустите его тоже, если что-то там меняли (команду для перезапуска GitLab см. выше).

@@ -1,32 +1,3 @@
-## GitLab
-##
-## Modified from nginx http version
-## Modified from http://blog.phusion.nl/2012/04/21/tutorial-setting-up-gitlab-on-debian-6/
-## Modified from https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html
-##
-## Lines starting with two hashes (##) are comments with information.
-## Lines starting with one hash (#) are configuration parameters that can be uncommented.
-##
-##################################
-##        CONTRIBUTING          ##
-##################################
-##
-## If you change this file in a Merge Request, please also create
-## a Merge Request on https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests
-##
-###################################
-##         configuration         ##
-###################################
-##
-## See installation.md#using-https for additional HTTPS configuration details.
-
-upstream gitlab-workhorse {
-  # On GitLab versions before 13.5, the location is
-  # `/var/opt/gitlab/gitlab-workhorse/socket`. Change the following line
-  # accordingly.
-  server unix:/var/opt/gitlab/gitlab-workhorse/sockets/socket fail_timeout=0;
-}
-

@@ -107,6 +77,6 @@
     proxy_set_header    X-Forwarded-Ssl     on;
     proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
     proxy_set_header    X-Forwarded-Proto   $scheme;
-    proxy_pass http://gitlab-workhorse;
+    proxy_pass http://unix:/var/opt/gitlab/gitlab-workhorse/sockets/socket;

Спасибо большое, что пролистали прочитали до конца! Желаю вам приятных снов, хорошего настроения и крепких нервов. Встретимся в следующем туторе (или статье)!