Представим ситуацию - вы - прошаренный разработчик-сисадмин, просыпаетесь утром, пьёте кофе, на улице поют птички, ничего не предвещает беды. Как вдруг, откуда ни возьмись, появляется босс и требует, чтобы вы срочно подняли GitLab на корпоративном сервере. А на сервере стоит RedOs. Первое что приходит в голову: "А давайте переустановим на что-нибудь другое?" Но за такое вас уволят. Что ж... В этом непродолжительном туторе настроим свой GitLab на отечественной операционной системе RedOs. Иногда будем ссылаться на уже имеющийся туториал. Если вы не знаете, что такое свой GitLab или какие преимущества он даёт, - обращайтесь к нему. Также есть другая статья (очень хорошая, недавно вышла, для ubuntu-юзеров) на хабре, к которой тоже можно обращаться. Здесь мы устанавливаем GitLab на RedOs, а не на Ubuntu/Debian. Дополнительно (см. спойлеры) настроим почту на своём домене. Мы пытаемся поднять его публично, чтобы дать возможность ребятам не в нашей локальной сети пушить и пуллить проекты.  Вы можете поставить GitLab множеством различных способов. Но разберём основные 3: Метод Плюсы Минусы Из исходников [Вроде бы] бó‎льшая скорость и более быстрый отклик сервера. Возможность залезть в код и посмотреть, как там всё устроено, отдебажить. Очень долгий процесс установки, состоящий из многих пунктов. В любой момент всё может пойти не по плану. Одна ошибка вызывает другую, та вызывает третью - и так далее. Пакет от Omnibus Мгновенная установка одной командой. Удобный способ настройки и конфигурации, а также управление сервисом. Обширная база решений проблем в случае, если что-то пойдет не так. Чуть меньшая скорость отклика. В основном минусов нет. Docker image Настройка портов, включение в облаке, автоматическое поднятие, если он упал и т.п. Я не особо пользовался, так что тут мало что могу сказать. Неочевидная настройка своих https сертификатов, а главный минус: отсутствие smtp менеджера. Если вы хотите postfix, вам придётся или пользоваться docker-compose или собирать образ из своего Dockerfile. Пойдём по второму пути. Многие пакеты в RedOs называются иначе, чем в официальной документации по установке GitLab из сурсов (хотя бы потому что она для Debian-based дистрибутивов). Во время установки gitaly может выкинуть ошибку компиляции связанную с grpc ( bin/ld can not find -lstdc++ ). А в issue сказано, что установка, которая происходит на том этапе, просто не поддерживается. Эта ошибка может возникнуть, а потом пропасть. Из-за настройки https может выкинуть 500 Internal API unreachable error. Это решается настройкой gitlab-shell (в gitlab-shell/config.yml), чтобы он подключался должным образом. Про эту проблему написано, например, здесь.  Сервер с проброшенными портами и белым ip, на котором можно поставить (или он уже стоит) RedOs (чисто технически, если там CentOs или Redhat, то тоже норм). Желательно, чтобы на нём было минимум 2 ядра CPU и 2 Гб оперативы. Домен. Уметь пользоваться терминалом. Возможность настраивать dns-записи у своего провайдера домена. gitlab.mydomain.com должен указывать на внешний ip вашего сервера. Умение управлять корпоративной почтой в панели своего провайдера. Если у вас ещё нету ОС, то самое время передумать поставить её. На комп, который будет использоваться как сервер, поставьте ОС. Во время установки выбирайте сервер-минимальный. Дополнительно сразу отметим некоторые пакеты для установки: Средства контроля производительности, Python, Библиотеки совместимости, Контрольные средства интернета, Средства разработки, Средства администрирования. Созданного юзера добавляем в группу wheel, чтобы он мог пользоваться sudo -i. Сразу после установки можно поставить самую свежую версию ядра: dnf upgrade. Чтобы уметь прокручивать историю терминала, а также копи-пастить команды, быстренько настраиваем ssh-подключение по ключу с другого устройства, у которого есть браузер и графическая оболочка. Если вам говорят, что подключение к серверу происходит впервые и что неплохо бы добавить ключ сервера в .ssh/known_host, то верность отпечатка можно проверить, выполнив команду на сервере: Как только настроили, удаляем возможность подключения по паролю: Если не сказано иного, все остальные команды выполняются на сервере от имени суперпользователя. Настроим postfix. Поставим сразу дополнительно парочку важных пакетов и, например, докер. Если бы мы ставили на Debian или Ubuntu, нам бы высветилось окошко с возможностью первоначальной конфигурацией smtp-менеджера. В нашем случае - настройка через relay- (smart-) host. Открываем и редактируем файл конфигурации /etc/postfix/main.cf. Mail.ru для бизнеса - возможность управлять почтовыми ящиками своих пользователей, создавать и устанавливать им пароли, а также рассылать сообщения. В бесплатном тарифе там доступно до 300 пользователей. Если у вас ещё нет своей почты, но есть домен и доступ к его dns-панели, можете создать корпоративную почту в своём домене. Чтобы убедиться в том, что домен действительно принадлежит вам, mail.ru потребует либо html-ответ, либо dns-запись, а также предложит парочку других вариантов. Если ваш сервер ещё не может отвечать на запросы, dns-запись - предпочтительный вариант. Если вы выгрузили dns-зону, то изменения распространятся не сразу. Чуть дальше будет рассказано, как убедиться, что dns-записи готовы к проверке. Конфигурация postfix: Создаём файл паролей: Чтобы получить пароль (который идёт после двоеточия), надо в mail.ru зайти в свой почтовый ящик. Далее -> настройки -> безопасность -> пароли для внешних приложений -> добавить. Создаём файл адресов отправителей: Хэшируем файлы: Перезапускаем сервис:  Теперь можете проверить работу почты: Каждый раз при ребуте у меня отваливается postfix сервис. На просторах интернета, вроде бы, написано, что этого можно избежать, отключив selinux, но это мало помогает. Проблема связана с тем, что сервис сохраняет pid процесса в каком-то файле и при выходе забывает (или не успевает) его очистить. В результате из-за нарушения безопасности, postfix при очередном запуске пытается прочитать файл и у него не получается. Если у кого-то есть такая же проблема и вы её решили, пожалуйста, поделитесь в комментариях. Если при ребуте у вас отвалился сервис почты, его всегда можно поднять руками:  Все мы любим https за то, что в браузерах рядом с нашим сайтом есть зелёный щит или значок замка́. Чтобы воспользоваться такой возможностью, надо поставить certbot, который в будущем поможет нам получить сертификаты от letsencrypt. По официальной документации его можно поставить через snapd. Для GitLab требуется redis и postgresql. Лучше поставить 12 версию. Теперь всё готово. Выполняем скрипт: Чтобы обмануть систему говорим ему, что пользуемся не отечественной ОС, а иностранной. Потом ставим сам пакет, указав домен. Через переменную окружения можно передать начальный пароль администратора. Если вы имели бэкап (версии той же, что и установили), можете его применить.  А после установки надо подправить файл /etc/gitlab/gitlab.rb (почитайте какие настройки там есть и подредачьте их), потом выполните gitlab-ctl reconfigure.Минимум один раз перед загрузкой бэкапа реконфигурацию надо сделать. Можете попробовать автоматическое получение сертификатов через letsencrypt['enable'] = true, но у меня он не сработал.  Ok, если надо получить сертификаты, есть два сценария - во-первых, на один ваш домен, во-вторых, на wildcard-домены типа таких, какие нужны для GitLab Pages. В процессе от вас в любом случае потребуют добавить dns-запись, которая после выгрузки зоны распространится не сразу. Проверить, появились ли dns-записи на вашем сайте, можно при помощи онлайн-утилит, например, таких. Команда получения сертификата для одного домена примерно такая: Для pages.mydomain.com ситуация немного другая. Для каждого пользователя, который будет создавать свой GitLab Page, будет выделен поддомен, а статические файлы будут хоститься на username.pages.mydomain.com/project-name. Есть прекрасная статья, где говорится, как получать wildcard-сертификаты: Все сертификаты сохраняются в /etc/letsencrypt/live/subdomain.mydomain.com/*.pem. Нас интересуют файлы fullchain.pem и privkey.pem. Их надо переместить в нужную папку, чтобы GitLab их увидел. Ключ -L добавляем, потому что в указанных папках лежат символьные ссылки на ../../archive.  Кофигурируем, перезапускаем, проверяем: Задержка нужна, потому что сразу gitlab-shell не поднимется и ему нужно раскачаться. Если запустить проверку сразу после перезапуска, у вас не всё будет так гладко, как если бы вы проверили то же самое, но через некоторое время. Если у вас в локальной сети есть ещё компьютеры, и вы хотите с них зайти на свой сайт, то существуют два пути решения проблемы: поднять свой dns-сервер или на каждой локальной машине, подключённой к тому же роутеру, что и сервер, редактировать файл /etc/hosts: Теперь можете заходить на gitlab.mydomain.com с логином root и паролем, который указали при установке. Чтобы проверить, что всё идеально работает, осталось совсем немного. Если вы первый раз клонируете (или пушите) репозиторий, после того как правильно настроили ssh ключ, добавив его в свой аккаунт, может выкинуть эту ошибку по нескольким причинам. Одна из них - каким-то боком сервер не может открыть файл с ключами. Смотрим лог cat /var/log/audit/audit.log: А первая же ссылка в гугле говорит, что имеет место идея отключить selinux. И да, этот обходной путь работает.  См. доки: Если у вас в логах часто появляется один и тот же левый адрес, файервол прекрасно с ним справится:  Сейчас любой в интернете может зарегистрироваться как новый пользователь. Чтобы избежать проблем заходим в админ-панель, Settings -> General -> Sign-up restrictions -> Allowed domains for sign-ups. Установите ограничение только на почту в вашем домене, пролистайте чуть ниже и сохраните изменения. По умолчанию должен был быть создан репозиторий Monitoring, попробуйте его склонировать на другом компьютере, предварительно добавив ssh-ключи в аккаунт. Добавьте парочку файлов, сделайте коммит и пуш. Проверьте, что ваши изменения есть на сайте. Этой конфигурации может быть достаточно для большинства нужд. Можете настроить gitlab-runners и проверить GitLab Ci/Cd, гайдов по этому в интернете полным-полно. Ну а мы пойдём немного дальше, добавим конфигурацию 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 в нужное место: Заменяем YOUR_SERVER_FQDN на свой домен, где будет крутиться GitLab, например gitlab.mydomain.com. Кста, ещё можно и путь к сертификатам указать! Аргументы ipv6only=on можете сразу удалять, сейчас они не поддерживаются. Ещё там есть строка ssl on, поскольку этот конфиг создавался 2 года назад, сейчас уже всё по-другому, эту строку тоже можно удалить (иначе nginx выкинет предупреждение). Проверьте, что ваш конфиг нормальный nginx -t и перезапустите сервис: nginx -s reload. Но перед этим убедитесь, что конфиг вашего GitLab соответствует действительности и перезапустите его тоже, если что-то там меняли (команду для перезапуска GitLab см. выше). Ещё раз: сначала запускаете GitLab, сказав ему, чтобы он свой nginx не использовал, потом перезапускаете nginx. Иначе можно получить bind() to 0.0.0.0:80 failed (98: Address already in use). Эта ошибка означает, что GitLab слушает на стандартном порту и не ожидает, что будет использоваться внешний (системный) nginx, а вы запустили nginx, чтобы он слушал на этом же порту и запросы перенаправлял GitLab-у.  Советую убрать первый блок в начале conf.d/gitlab.conf: А в конце заменить всё это дело обычным указанием пути до сокета:  Скорее всего nginx не может прочитать файл сокета: sudo -u nginx ls -la /var/opt/gitlab/gitlab-workhorse/sockets/socket, либо из-за проблем с правами, либо из-за отсутствия файла, хотя он должен быть. Выключите selinux (см. инструкции выше). Есть инструкции на официальном сайте. Вот после них у меня всё заработало. На ответе в stackoverflow, в обсуждениях в issue в репозитории GitLab-а и ещё тут советуют добавить пользователей в группы: usermod -aG git,gitlab-www nginx. Если не хотите выключать selinux, можно попробовать сделать исключение. Человек говорит, там надо каждый раз после реконфигурации GitLab кое-какую команду запускать. Проверьте, что есть в логах: cat /var/log/audit/audit.log | grep nginx | grep denied.  Логи nginx: cat /var/log/nginx/gitlab_error.log.  Спасибо большое, что пролистали прочитали до конца! Желаю вам приятных снов, хорошего настроения и крепких нервов. Встретимся в следующем туторе (или статье)!  Самый крутой прогер на деревне.