Prikalel 3 дек 2022 в 21:01

GitLab self-instance on RedOs

14 мин

8.8K

Туториал

Abstract

Представим ситуацию - вы - прошаренный разработчик-сисадмин, просыпаетесь утром, пьёте кофе, на улице поют птички, ничего не предвещает беды. Как вдруг, откуда ни возьмись, появляется босс и требует, чтобы вы срочно подняли 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, то верность отпечатка можно проверить, выполнив команду на сервере:

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

Если вы часто выключаете и включаете сервер:

Каждый раз при ребуте у меня отваливается postfix сервис. На просторах интернета, вроде бы, написано, что этого можно избежать, отключив selinux, но это мало помогает. Проблема связана с тем, что сервис сохраняет pid процесса в каком-то файле и при выходе забывает (или не успевает) его очистить. В результате из-за нарушения безопасности, postfix при очередном запуске пытается прочитать файл и у него не получается. Если у кого-то есть такая же проблема и вы её решили, пожалуйста, поделитесь в комментариях.

Если при ребуте у вас отвалился сервис почты, его всегда можно поднять руками:

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% смог их прочитать.

Пример файла конфигурации gitlab.rb:

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

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

Ошибка permission denied (publickey,keyboard-interactive).

Если вы первый раз клонируете (или пушите) репозиторий, после того как правильно настроили ssh ключ, добавив его в свой аккаунт, может выкинуть эту ошибку по нескольким причинам. Одна из них - каким-то боком сервер не может открыть файл с ключами. Смотрим лог cat /var/log/audit/audit.log:

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

А первая же ссылка в гугле говорит, что имеет место идея отключить selinux. И да, этот обходной путь работает.

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 см. выше).

Ошибка Address already in use.

Ещё раз: сначала запускаете GitLab, сказав ему, чтобы он свой nginx не использовал, потом перезапускаете nginx. Иначе можно получить bind() to 0.0.0.0:80 failed (98: Address already in use). Эта ошибка означает, что GitLab слушает на стандартном порту и не ожидает, что будет использоваться внешний (системный) nginx, а вы запустили nginx, чтобы он слушал на этом же порту и запросы перенаправлял GitLab-у.

Немного подредактируем конфиг nginx.

Советую убрать первый блок в начале conf.d/gitlab.conf:

@@ -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;

Если после всего этого счастья вы получаете 502 bad gateway:

Скорее всего 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 кое-какую команду запускать.
Проверьте, что есть в логах:
1. cat /var/log/audit/audit.log | grep nginx | grep denied.
2. Логи nginx: cat /var/log/nginx/gitlab_error.log.

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

Теги:

Хабы: