Системное администрирование *

Уязвимость в протоколе REALITY XTLS/Xray-core: быстрый фикс уязвимости Aparecium

На прошлой неделе была обнаружена уязвимость в известном ПО для создания прокси соединений XTLS/Xray-core, а именно в протоколе REALITY, позволяющая выявлять работу этого протокола.

Для тех, кто не в курсе: REALITY — это уникальный протокол прокси, который позволяет маскировать прокси-трафик под легитимное посещение реальных сайтов (например, google.com или любого другого), при этом не требуя покупки домена и настройки TLS-сертификата на своем сервере.

Обнаружение уязвимости

В начале июня 2025 года исследователь под ником ban6cat6 опубликовал утилиту под названием Aparecium. Ее цель — находить серверы, использующие протоколы вроде REALITY.

В чем была суть уязвимости?
Утилита обнаружила, что серверы на базе OpenSSL после завершения основного TLS-рукопожатия (handshake) обычно отправляют клиенту один или два служебных сообщения NewSessionTicket. Это стандартное поведение, позволяющее возобновлять сессии. Протокол REALITY в своей реализации это поведение не имитировал.

Это тонкое различие позволяло Aparecium с высокой точностью отличать настоящий веб-сервер от сервера с REALITY, просто проанализировав последовательность TLS-сообщений.

Быстрый фикс

Информация об уязвимости была опубликована в виде issue #4778 в репозитории Xray-core. Разработчики, в частности RPRX, отреагировали практически молниеносно.

Вместо того чтобы добавить отправку фейковых NewSessionTicket, они пошли по более правильному пути. Уже через несколько дней в версии Xray-core v25.6.8 появилось «предварительное» решение:

Теперь при первом запуске сервер REALITY, используя отпечаток клиента Chrome, сам подключается к целевому сайту (dest), «подсматривает», какие именно post-handshake сообщения и какой длины тот отправляет, кэширует эту информацию и в дальнейшем идеально имитирует именно это поведение.

На это «зондирование» уходит около 30 секунд при первом старте сервера, но оно по большей части решает основную проблему. Вместе с этим был исправлен и неприятный баг с производительностью из-за неработающего аппаратного ускорения AES-NI.

Глубокий анализ

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

1. Загадка «лишнего пакета» от bilibili.com
   Один из разработчиков заметил, что при подключении к некоторым сайтам (например, bilibili.com) с отпечатком Chrome, сервер возвращает не только NewSessionTicket, но и еще один небольшой пакет. После анализа выяснилось, что это не TLS-сообщение, а кадр настроек HTTP/2 (settings frame). Это значит, что для идеальной маскировки нужно имитировать не только TLS-уровень, но и поведение прикладного протокола (HTTP/2), который был согласован в ходе рукопожатия.

2. Проблема разных отпечатков (fingerprints)
   Выяснилось, что один и тот же сайт может по-разному отвечать на ClientHello от разных клиентов. Например, на запрос с отпечатком Chrome он может отправить два NewSessionTicket и settings фрейм, а на запрос от Go-клиента — только один NewSessionTicket. Похоже, что статического зондирования недостаточно.

3. Идея «живого обучения»
   В ходе мозгового штурма родилась идея для долгосрочного решения, которое было оформлено в issue #4788. Суть в том, чтобы сервер REALITY, получив ClientHello от нового клиента, не просто использовал стандартный отпечаток для зондирования, а копировал отпечаток реального клиента и именно с ним обращался к целевому сайту. Это позволит динамически адаптироваться под любого клиента и достичь практически идеальной мимикрии.

Разработчики рекомендуют всем обновить сервера и клиенты, использующие Xray-core, до версии 25.6.8.

ping: permission denied (are you root?)

Знакомы ли с этим сообщением об ошибке? И знаете ли, как ее исправить?

Этот запрет на отправку ICMP-пакетов внутри контейнера можно получить при выполнении, например, такой задачи.

Задача: Организовать k8s-кластеры в ручном режиме с помощью kubeadm и kubectl на базе cri-o (1.28+) и использовать Calico как CNI-плагин.

Кластер доступен для взаимодействия через kubectl, команда возвращает корректную информацию о кластере. Есть возможность сделать ping 8.8.8.8 с образом busybox.

Если вы опытный DevOps и знаете, как решается эта «детская проблема» при работе с оркестратором, регистрируйтесь на спринт-оффер для девопсов. Сможете буквально играючи получить новую работу за 3 дня.

Если вы только начали изучать Kubernetes, читайте статью с подробным разбором этой ошибки → 

Как обнаружить anycast-адреса сервисов при помощи неравенства треугольника

Технически, по одному и тому же IP-адресу может отвечать всякий интернет-узел, который находится на (двунаправленном) техническом пути следования пакетов. Чтобы такое работало без запинки для многих IP-источников - требуется согласовать пути следования пакетов на уровне IP-сети, то есть, средствами BGP. Штатный способ использования этой особенности называется Anycast. Настроить и поддерживать сложно, но, при грамотном подходе, метод отлично работает и достаточно широко используется в глобальной Сети. При Anycast один и тот же IP-адрес, наблюдаемый из разных точек Интернета, адресует разные физические узлы. Эти физические узлы могут быть географически распределены - ближе к пользователям. Обычно, так и делается, потому что это одно из основных практических преимуществ Anycast, но далеко не единственное преимущество - anycast-адреса могут быть разведены средствами BGP и коммутации сетевых сегментов из соображений устойчивости к DDoS-атакам, распределения прочей нагрузки, повышения надёжности и т.д. Примеры: 1.1.1.1, 8.8.8.8, многие корневые DNS-серверы.

Как подручными средствами проверить, что какой-то интернет-сервис стоит за anycast-адресами? Для этого нужно использовать неравенство треугольника. Тестируемый узел должен отвечать в рамках того или иного протокола, который позволяет измерить сетевое время доставки пакетов.

Методика. Пусть мы обнаружили IP-адрес сервиса (обычно, из DNS) и хотим его проверить. Пусть узел под этим адресом отвечает по ICMP - ping. Возьмём два опорных узла-источника, расположенных в совсем разных местах Интернета: например, узел в Амстердаме (обозначим его А) и узел во Владивостоке (соответственно - В). Тестируемый узел назовём Т. Принцип: если среднее время доставки ping между А, В (А <--> В) существенно превышает сумму ping для А --> Т и В --> Т, то сервис, работающий на узле T, скорее всего, использует Anycast. Поэтому измеряем время силами ping. Это и есть нарушение неравенства треугольника: если сумма расстояний (в смысле ICMP) от каждой из точек тестирования к тестируемому узлу меньше, чем расстояние между этими точками, то тестируемый узел - это, скорее всего, как минимум два узла, использующих один и тот же IP-адрес, то есть, это anycast-адрес.

Конечно, тут всегда есть место для погрешности, однако в подавляющем большинстве случаев Anycast так виден - иначе в нём не было бы смысла. Можно взять несколько опорных точек, а не две, тогда точность возрастёт.

Чек-лист: как настроить мониторинг, который предупредит сбой до его возникновения

Шаг 1. Составьте карту сервисов и зависимостей

• Что включить: микросервисы, БД, очереди (Kafka, RabbitMQ), сторонние API (платежки, SMS).

• Зачем: чтобы понять, как падение одного компонента влияет на систему.

«Падение Redis "уронит" кэширование и увеличит нагрузку на БД».

Шаг 2. Разделите симптомы проблем: срочные vs важные

Срочные (реагировать немедленно!)

• БД: connections > 90%, replica lag > 10 сек.

• Платежный шлюз: 5xx errors > 1% за 5 мин, latency p99 > 3 сек.

• Kubernetes: pod restarts > 5/час, node CPU > 95%.

Инструменты: Grafana OnCall, PagerDuty.

Важные (требуют анализа)

• Рост ошибок 4xx > 5% за сутки.

• Увеличение времени ответа API на > 20% за неделю.

• Падение успешных сессий (Google Analytics).

Решение: алерты в Slack/Email.

Шаг 3. Автоматизируйте рутину

Сбор логов: стек EFK (Elastic + Fluentd + Kibana).

Kubernetes:

• Liveness-пробы → авто-перезапуск пода при сбое.

• Readiness-пробы → остановка трафика на проблемный под.

Redis: настройка политик очистки кэша.

Совет для ленивых:

«Используйте Coroot — он автоматически строит карту зависимостей и предлагает алерты»

Шаг 4. Тестируйте устойчивость

Chaos Engineering раз в месяц:

• Отключайте случайные ноды в кластере.

• Эмулируйте нагрузку в 10 раз выше обычной (Locust).

«Мониторинг должен не только сообщать о проблемах, но и подсказывать, что делать».

Подключайтесь к вебинару про производительность 1С 🔍

Ровно через час, в 12:00 мск, встретимся, чтобы обсудить тест Гилева и другие методики тестирования 1С. Ответим на главные вопросы:

✔️ как выбрать подходящий метод,

✔️ как настроить тестовое окружение,

✔️ как проанализировать результаты и провести оптимизацию на основе полученных данных.

Вебинар будет полезен администраторам 1С и системным администраторам, руководителям IT-отделов, разработчикам, а также специалистам по производительности. 

Подключайтесь к трансляции:
➡️ в VK
➡️ на YouTube

На GitHub опубликовали новый инструмент для обнаружения протоколов маскировки TLS Он получил название Aparecium и способен выявлять ShadowTLS v3 и REALITY, которые маскируют зашифрованный трафик под легитимный TLS 1.3.

Aparecium использует особенности реализации TLS, чтобы обнаружить аномалии в поведении протоколов маскировки. ShadowTLS и REALITY, например, часто не обрабатывают отправляемые сервером сообщения NewSessionTicket должным образом, что позволяет выявить их использование.

Серверы на базе OpenSSL отправляют два сообщения NewSessionTicket одинаковой длины в одном TCP‑пакете, что также является характерной особенностью, отсутствующей в протоколах маскировки.

IMPulse - менеджмент инцидентов. Интеграция с Google Calendar, вложенные цепочки эскалации.

Предыдущие публикации:
https://habr.com/ru/articles/865208/
https://habr.com/ru/posts/889768/

Мы продолжаем развивать нашу систему менеджмента инцидентов. И рады представить интеграцию с Google Calendar, благодаря которой вы сможете гибко настраивать график дежурств и цепочки эскалации для этих дежурств.

Помимо интеграции с Google Calendar, мы реализовали вложенные цепочки эскалации. Теперь в chain можно добавить другой chain (nested), благодаря чему размер конфигурационного файла уменьшится.

Мы хотим создать достаточно гибкую, но не перегруженную систему цепочек эскалации, чтобы на проектах разной величины вы могли использовать IMPulse так как вам удобно. Для этого в комментариях расскажите, какой самый сложный кейс уведомлений / эскалации вам необходимо было реализовать. Например: во вторник нужно дёргать Антона, через 5 минут Олега, а по средам - только дёргать Геннадия, в остальное время, если severity == 'critical', звонить Грише.
Будем рады почитать самые сложные варианты и предложить наше универсальное решение для них.

Остаёмся на связи в нашем Telegram канале - там можно общаться / задавать вопросы.

Как защитить данные без полных бэкапов: разбираем косвенную адресацию в СХД

Мгновенный снимок (снапшот) — это компактная с точки зрения дискового пространства копия данных, созданная в определенный момент времени. Снапшот способен моментально зафиксировать состояние тома, в отличие от резервной копии, создание которой при большом объеме данных может занять длительное время и требовать остановки записи для сохранения консистентности. Снапшот же не создает независимую копию данных, а лишь обеспечивает возможность обратиться к данным тома на момент создания снапшота.

В TATLIN.UNIFIED снапшоты создаются путем копирования карты блоков данных оригинального тома. Сами данные не копируются, поэтому снапшоты создаются очень быстро и не занимают дополнительного места в области данных.

Со временем в родительском томе заполняются новые блоки данных. Некоторые данные у родительского тома и снапшота начинают различаться, но данные, на которые уже ссылается снапшот, не перезаписываются и не освобождаются. Оригинальный физический блок данных считается занятым до тех пор, пока снапшот, который на него ссылается, не будет удален. После удаления снапшота блоки данных, которые он не разделял с другими ресурсами, освобождаются и могут быть использованы для последующих операций записи. Такой вариант реализации снапшотов называют Redirect-On-Write (RoW).

В своей статье Алексей Шушарин, главный эксперт по разработке ПО в департаменте СХД YADRO, подробно рассказал о снапшотах, клонах и всех процессах, связанных с косвенной адресацией. А также о том, как грамотно вписать эту функциональность в стек хранилища.

Порадуем вас обновами в Kubernetes

А новостей собралось действительно много:

➖ Добавили в маркетплейс дополнений ArgoCD и cert-manager Webhook, который дружит с нашим API. С ними можно автоматизировать деплой приложений и упростить выпуск и обновление TLS-сертификатов в Kubernetes
➖ Открываем новые локации — теперь можно создавать кластеры и во Франкфурте
➖ Обновили публичную документацию API и добавили доки для части аддонов Kubernetes + описание всех новых параметров API
➖ Плюсик к карме и к безопасности — read-only режим для API-токенов, которые выпускаются автоматически при создании кластеров. Никаких случайных изменений или удалений

Забрать все обновы в Kubernetes себе →

Три дня, чтобы начать поддерживать инфраструктуру для базовых станций GSM/LTE

Это baseband-модуль (BBU) базовой станции, которую разработала команда Телеком в YADRO, и мы ищем DevOps-инженеров, которые к ней присоединятся. Таким специалистам нужно будет поддерживать процессы разработки (на С/С++, Go, Node.JS), развивать CI/CD и улучшать качество внутренних сервисов.

Узнать, как стать DevOps-инженером в YADRO → 

DevOps-специалистов разного уровня — от junior до senior — мы ждем по двум направлениям.

Infrastructure

Задача DevOps-инженера здесь — поддерживать бесперебойную работу инфраструктуры для разработки в телекоме. А это более 600 виртуальных машин, 20 информационных систем и десятков внутренних сервисов. Эта работа не просто про администрирование серверов, но и про автоматизацию работы и масштабирование инфраструктуры.

CI/CD

Специалисты по этому направлению организуют разработку и выпуск программно-аппаратных решений в сфере телекоммуникаций — с использованием Gitlab CI. Ежедневно они востребованы у более тысячи разработчиков и тестировщиков телекома. Цель DevOps-команды — сделать удобным процесс доставки изменений от разработчиков до продукта, а также постоянно улучшать и оптимизировать существующие решения, внедрять Observability для текущих продуктов, создавать новые инструменты.

Условия быстрого оффера

Подайте заявку на лендинге до 8 июня. Далее с вами свяжется рекрутер, чтобы обсудить общие вопросы и назначить интервью. После вы пройдете техническое интервью и интервью с менеджером, а в случае успеха получите оффер в компанию. Весь процесс займет 3 дня.

Больше про спринт-оффер и описания требований к специалистам — по ссылке.

Настройка бекапа вашей Linux системы с помощью rsync: просто и со вкусом

Шаг 1: Подготовка сервера для бэкапов

Лайфхак: В Hostkey VPS с 4ТБ обойдется примерно в 2600₽/месяц

Настройка SSH-ключа для безопасного доступа:

# Создаем SSH-ключ
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_backup

# Копируем на сервер
ssh-copy-id -i ~/.ssh/id_rsa_backup.pub user@backup-server

# Создаем директории на сервере
mkdir -p /root/backup-{1,2,3}

Шаг 2: Настройка автоматических бэкапов

Добавляем три задания в crontab для ротации бэкапов по дням недели:

crontab -e

Вставляем три задания (замените SSH_USER, SSH_HOST и SSH_KEY_PATH):

# Бэкап в директорию backup-1 (воскресенье, среда, суббота)
0 */2 * * 0,3,6 touch /tmp/os-backup.lock && /usr/bin/timeout 7200 /usr/bin/flock --close -n /tmp/os-backup.lock /bin/bash -c "rsync -aAXHv --delete -P --rsync-path=\"sudo rsync\" -e \"ssh -o StrictHostKeyChecking=no -i SSH_KEY_PATH\" --exclude='/dev/*' --exclude='/proc/*' --exclude='/sys/*' --exclude='/tmp/*' --exclude='/run/*' --exclude='/mnt/*' --exclude='/media/*' --exclude='/lost+found/' /* SSH_USER@SSH_HOST:/root/backup-1 &> /var/log/os-backup || sudo -u $(id -nu 1000) DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus notify-send \"OS BACKUP FAILED\""

# Бэкап в директорию backup-2 (понедельник, четверг)
0 */2 * * 1,4 touch /tmp/os-backup.lock && /usr/bin/timeout 7200 /usr/bin/flock --close -n /tmp/os-backup.lock /bin/bash -c "rsync -aAXHv --delete -P --rsync-path=\"sudo rsync\" -e \"ssh -o StrictHostKeyChecking=no -i SSH_KEY_PATH\" --exclude='/dev/*' --exclude='/proc/*' --exclude='/sys/*' --exclude='/tmp/*' --exclude='/run/*' --exclude='/mnt/*' --exclude='/media/*' --exclude='/lost+found/' /* SSH_USER@SSH_HOST:/root/backup-2 &> /var/log/os-backup || sudo -u $(id -nu 1000) DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus notify-send \"OS BACKUP FAILED\""

# Бэкап в директорию backup-3 (вторник, пятница)
0 */2 * * 2,5 touch /tmp/os-backup.lock && /usr/bin/timeout 7200 /usr/bin/flock --close -n /tmp/os-backup.lock /bin/bash -c "rsync -aAXHv --delete -P --rsync-path=\"sudo rsync\" -e \"ssh -o StrictHostKeyChecking=no -i SSH_KEY_PATH\" --exclude='/dev/*' --exclude='/proc/*' --exclude='/sys/*' --exclude='/tmp/*' --exclude='/run/*' --exclude='/mnt/*' --exclude='/media/*' --exclude='/lost+found/' /* SSH_USER@SSH_HOST:/root/backup-3 &> /var/log/os-backup || sudo -u $(id -nu 1000) DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus notify-send \"OS BACKUP FAILED\""

Что делает наш скрипт?

• Умное расписание: Каждый день недели система копирует данные в одну из трех директорий

• Защита от блокировок: Предотвращает запуск нескольких копий скрипта одновременно

• Безопасность: Использует SSH-ключи вместо паролей

• Исключения: Пропускает системные директории, которые не нужно бэкапить

• Мониторинг: Отправляет уведомление в шторку уведомлений, если что-то пошло не так

ОБЯЗАТЕЛЬНО сохраните SSH-ключ в надежном месте! Без него восстановление данных будет невозможно.

Рекомендации:

• Копия на USB-флешке (хранить отдельно от компьютера)

• Распечатка на бумаге в сейфе (для параноиков)Зашифрованная копия в менеджере паролей

Проверка работоспособности

Регулярно проверяйте состояние ваших бэкапов:

ssh -i SSH_KEY_PATH SSH_USER@SSH_HOST "ls -la /root/backup-1"

Теперь у вас есть надежная система бэкапов, которая защитит вас от большинства катастроф. В случае сбоя вы сможете быстро восстановить всю систему целиком, минимизируя простои и стресс.

Скрипт очистки логов всех баз MSSQL

Изначально статья была выложена на своём сервере https://ast-1c.kz/almasoft/?p=1443

Ничего сверхъестественного, но может кому пригодится:)

В процессе работы с сервером 1С, который в качестве сервера баз данных использует MSSQL сервер, очень часто приходится решать задачу по очистке логов базы. Сама по себе задача достаточно тривиальная и решается исполнением скрипта (при полной модели восстановления):

USE база_данных;  
GO  
-- Изменяем модель восстановления базы данных на SIMPLE.  
ALTER DATABASE база_данных
SET RECOVERY SIMPLE;  
GO  
-- Обрезаем LOG файл до 1 мегабайта.  
DBCC SHRINKFILE (база_данных_log, 1);  
GO  
-- Возвращаем модель восстановления базы данных на FULL.  
ALTER DATABASE база_данных
SET RECOVERY FULL;  
GO

либо же для базы использующей простой тип модели восстановления:

USE база_данных;  
GO  
-- Обрезаем LOG файл до 1 мегабайта.  
DBCC SHRINKFILE (база_данных_log, 1);  
GO  

Всё, просто и хорошо, но вот если на сервере скажем 100 баз, писать такой скрипт для каждой в отдельности — это не очень приятное задание, да и времени уйдет предостаточно. А ещё есть одно неудобство — если в последствии будет добавлена очередная база, то Вы не должны забыть и для неё прописать отдельный скрипт. Очень часто базы добавляют программисты 1С, а вот слежение за состоянием сервера ложится на плечи системного администратора. Ну и тут главное не просмотреть этот момент. В общем не очень удобная штука.

Было принято решение написать универсальный скрипт, который бы сам определял все базы и в зависимости от модели их восстановления выполнял бы необходимые процедуры для обрезки файла лога. А вот и полученный скрипт:

Declare @name varchar(100)
declare @qu as varchar(1200)
declare icur cursor fast_forward for

SELECT name
FROM sys.databases
WHERE name NOT IN ('master', 'model', 'msdb', 'tempdb')
--and recovery_model_desc = 'FULL'

open icur
 fetch next from icur into @name
 While @@Fetch_Status = 0 

Begin
  Set @qu='use [' + @name + '] Declare @logname varchar(64), @size int'
  Set @qu=@qu + ' Set @logname = (SELECT [name] FROM [sys].[database_files]  where type_desc=''LOG'')'
  Set @qu=@qu + ' Set @size = (SELECT max_size FROM [sys].[database_files]  where type_desc=''LOG'') * 0.7/128'
  Set @qu=@qu +  ' ALTER DATABASE [' + @name + ']  SET RECOVERY SIMPLE DBCC SHRINKFILE (@logname, 7)'
  Set @qu=@qu + ' ALTER DATABASE [' + @name + ']  SET RECOVERY FULL'
  Exec (@qu) 
  Set @qu = '' 
  fetch next from icur into @name
END
close icur

SELECT name
FROM sys.databases
WHERE name NOT IN ('master', 'model', 'msdb', 'tempdb')
--and recovery_model_desc = 'SIMPLE'

open icur
 fetch next from icur into @name
 While @@Fetch_Status = 0 

Begin
  Set @qu='use [' + @name + '] Declare @logname varchar(64), @size int'
  Set @qu=@qu + ' Set @logname = (SELECT [name] FROM [sys].[database_files]  where type_desc=''LOG'')'
  Set @qu=@qu + ' Set @size = (SELECT max_size FROM [sys].[database_files]  where type_desc=''LOG'') * 0.7/128'
  Set @qu=@qu +  ' ALTER DATABASE [' + @name + ']  SET RECOVERY SIMPLE DBCC SHRINKFILE (@logname, 7)'
  Exec (@qu) 
  Set @qu = '' 
  fetch next from icur into @name
END
close icur
deallocate icur

DBCC SHRINKDATABASE (TEMPDB);

Скачать готовый на GitHub Gist

Приглашаем на вебинар, посвященный последним обновлениям IVA MCU — ведущей платформы видеоконференцсвязи на российском рынке*

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

Спикеры

• Дмитрий Журавлев, директор по продукту IVA MCU

• Дмитрий Чугунов, руководитель управления поддержки продаж

Что вас ждет

• Обзор ключевых функций новой версии IVA MCU

• Экскурс: как мы обеспечиваем безопасность платформы

• Примеры успешного внедрения

• Дорожная карта развития на 2025 год

• Ответы на вопросы

Зарегистрироваться прямо сейчас.

 _{*По данным CNews Analytics: Крупнейшие поставщики решений для видеоконференцсвязи 2023.}

Миграция сервера GitLab: инструкция от практика

Нужно перенести GitLab на новый сервер, но боитесь потерять данные? Я покажу проверенный способ миграции, сохраняющий все проекты, настройки и историю.

Подготовка

Убедитесь, что:

• у вас есть root-доступ к обоим серверам;

• на старом сервере ≥50% свободного места;

• Вы знаете точную версию GitLab (критически важно!)

Шаг 1: Подготовка нового сервера

Установите идентичную версию GitLab на новую машину:

sudo apt-get update && sudo apt-get install -y curl openssh-server ca-certificates perl 
# Установка конкретной версии (пример для 17.5.5) 
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash sudo apt-get install gitlab-ee=17.5.5-ee.0

Шаг 2: Создание бэкапа на старом сервере

# Проверка свободного места 
df -h  
# Создаем резервную копию
sudo gitlab-backup create

Процесс создания бэкапа может занять от минут до часов.

Шаг 3: Копирование файлов на новый сервер

Важно! Используем nohup для обеспечения непрерывности процесса и SSH-ключ для безопасного соединения:

# Копирование файла секретов 
nohup /bin/bash -c 'rsync -avh --delete --rsync-path="sudo rsync" -e "ssh -o StrictHostKeyChecking=no -i k" /etc/gitlab/gitlab-secrets.json root@new-server:/etc/gitlab/gitlab-secrets.json'
# Копирование бэкапа 
nohup /bin/bash -c 'rsync -avh --delete --rsync-path="sudo rsync" -e "ssh -o StrictHostKeyChecking=no -i k" /var/opt/gitlab/backups/1742165326_2025_03_16_17.5.5_gitlab_backup.tar root@new-server:/var/backups/gitlab/1742165326_2025_03_16_17.5.5_gitlab_backup.tar'

Примечание: В примере k — это файл приватного ключа. Файл конфигурации (gitlab.rb) намеренно не копируем, но при необходимости полной копии скопируйте и его.

Шаг 4: Восстановление на новом сервере

Сначала остановите необходимые сервисы:

sudo gitlab-ctl stop puma 
sudo gitlab-ctl stop sidekiq

Затем запустите восстановление (с nohup для надежности):

nohup /bin/bash -c "gitlab-backup restore BACKUP=1742165326_2025_03_16_17.5.5 force=yes"

Важно: Идентификатор бэкапа — это часть имени файла до gitlabbackup.tar. Параметр force=yes избавляет от подтверждений.

Шаг 5: Перезапуск и проверка

sudo gitlab-ctl restart 
sudo gitlab-ctl reconfigure  
# Проверки целостности данных 
sudo gitlab-rake gitlab:check SANITIZE=true 
sudo gitlab-rake gitlab:doctor:secrets 
sudo gitlab-rake gitlab:artifacts:check 
sudo gitlab-rake gitlab:lfs:check 
sudo gitlab-rake gitlab:uploads:check

Финальная проверка

Убедитесь, что:

• вход работает;

• репозитории открываются;

• CI/CD пайплайны запускаются;

• все проекты на месте.

Типичные проблемы и их решение

Ошибка 502 при доступе к некоторым репозиториям:

sudo gitlab-ctl restart 
sudo gitlab-ctl reconfigure

Рекомендации от практика

1. Тестовая миграция: Сначала попробуйте на тестовом сервере.

2. Окно обслуживания: Предупредите команду заранее.

3. Резервный план: Не выключайте старый сервер до полной проверки нового.

4. Мониторинг: Следите за логами первые дни после миграции.

5. DNS: Обновите DNS-записи после успешной миграции.

Заключение

Ключ к успешной миграции — точное соблюдение версионности, использование nohup для длительных операций и тщательная проверка после восстановления.

Подробнее: docs.gitlab.com/ee/administration/backup_restore/restore_gitlab.html

Бонус: инструмент для построения последовательности обновления гитлаба

Опубликовали программу infra.conf'25 — конференции про работу с высоконагруженными системами и инфраструктурой

Итоговая программа ежегодной infra.conf'25 объединит доклады про платформенную разработку, применение больших языковых моделей, решения с открытым исходным кодом, обеспечение безопасности, инфраструктуру для машинного обучения и мобильной разработки.

Спикерами infra.conf'25 станут ведущие инженеры и разработчики Яндекса, Купера, MTS Web Services, Positive Technologies, AvitoTech, Sber AI и других компаний. Организаторы мероприятия — команда Yandex Infrastructure, которая создаёт и предоставляет внутреннюю инфраструктуру Яндекса.

Конференцию откроет главный доклад от Андрея Година, руководителя Yandex Infrastructure, и Александра Чубинского, руководителя Yandex Platform Engineering.
Также среди спикеров infra.conf'25:

• Александр Николаичев и Николай Гриценко из Yandex Infrastructure — «Все дороги ведут в Internal Development Platform (IDP)».

• Роза Морозенкова из Купера — «ML‑платформа: зачем она нужна вам, нам и ML‑инженерам».

• Кирилл Сюзев из команды платформы для разработчиков SourceCraft — «Облачный CI/CD — 5-звёздочный отель для особо опасных любимых пользователей».

• Валерий Евдокимов из ecom.tech (ex. Samokat.tech) — «Превозмогая opensource: опыт внедрения OpenTelemetry, Qryn и Coroot для выстраивания системы наблюдаемости».

• Виталий Шишкин из Positive Technologies — «Tetragon: лучшие практики и нюансы разработки Tracing Policy».

• Эдуард Оболенский из Yandex Infrastructure — «Опыт построения инфраструктуры вокруг мобильной разработки».

Также гости мероприятия смогут посетить воркшоп по Surface Mount Device‑пайке — это процесс пайки электронных компонентов поверхностного монтажа к печатным платам.

infra.conf'25 пройдёт 5 июня в Москве в Loft Hall #8. Также доклады можно посмотреть онлайн на сайте конференции. Для участия нужно зарегистрироваться на сайте и получить приглашение.

VPS со скидкой 49% от PQ.Hosting в Юго-Восточной Азии — Малайзия открыта для предзаказов

Мы открываем предзаказ на виртуальные серверы в Малайзии, в дата-центре в Куала-Лумпуре. Это уже 49-я локация в нашей сети.

Почему эта площадка может быть интересна для ваших проектов:

• близость к основным рынкам Юго-Восточной Азии (Сингапур, Индонезия, Таиланд, Китай);

• стабильная правовая среда для работы IT-бизнеса;

• порты до 10 Gbps без ограничений по трафику уже в базовой конфигурации.

Активация серверов запланирована через 96 часов. До этого момента можно оформить заказ со скидкой 49% по промокоду PRESALE49. Срок действия промокода — до 13.05.25 23:59 UTC+3.

Больше информации о запуске — в наших следующих обновлениях.

Вебинар | Что нам стоит «лес» построить? Принципы работы с многодоменными инфраструктурами

13 мая, 15:00
МТС Линк

Продлеваем майские вебинаром о лесах! Недавно для РЕД АДМ вышло глобальное обновление: появилась возможность мигрировать сложные многодоменные ИТ-инфраструктуры на всех уровнях леса. Это уникальное решение для рынка отечественных систем управления. Слушателей вебинара ждет подробный обзор возможностей решения, а также демонстрация процесса миграции сложной ИТ-инфраструктуры.

План вебинара: максимум практики!

— Сайты VS поддомены: в чём разница? Рассмотрим особенности каждого подхода к построению инфраструктуры

— Демонстрация: ввод контролеров РЕД АДМ в корневой домен и поддомен на базе Microsoft Active Directory

— Подробнее о поддоменах: настройка отдельного поддомена на базе Службы каталогов РЕД АДМ

— Рассмотрим работу транзитивных доверительных отношений между поддоменами

— Оцениваем результаты трудов! Отключаем Microsoft Active Directory и наблюдаем за работой ИТ-инфраструктуры на базе РЕД АДМ

Спикер: Кристина Орлова, эксперт центра компетенций РЕД СОФТ

Регистрация >>

Состоялся релиз РЕД ОС 8 для архитектуры процессоров ARM

Релиз для архитектуры процессоров ARM открывает новые возможности по созданию отечественных программно-аппаратных комплексов, а также расширяет совместимость РЕД ОС 8 с российскими аппаратными платформами.

Установочные образы под различные ARM-платформы уже доступны на сайте.

Поддержка процессоров на архитектуре ARM в РЕД ОС 8 позволит российским компаниям снизить зависимость от зарубежного программного обеспечения. Работоспособность РЕД ОС 8 уже подтверждена для российских процессоров Байкал-М и Байкал-S, сертификаты совместимости размещены на сайте РЕД ОС.

Помимо устройств от российских компаний, РЕД ОС 8 демонстрирует стабильную и корректную работу на процессорах серии Ampere Altra и Huawei Kunpeng.

Скачать образы
Читать подробности в пресс-релизе

«Первая Форма» представила новую админпанель для быстрой low-code настройки

В новой версии low-code BPM-системы «Первая Форма» представлена обновленная административная панель для настройки процессов. Её главное преимущество — редактор, который даёт администраторам системы возможность создавать автоматизации без глубоких технических знаний и привлечения IT-специалистов. Решение помогает быстрее настраивать и оптимизировать процессы.

В редакторе автоматизаций появилось три новых инструмента для работы с запросами:

• Визуализация плана запроса. Эта функция отображает процесс сбора данных из баз и позволяет определить этапы SQL-запроса, которые влияют на производительность. Инструмент помогает администратору понять, как работает его запрос, найти причину долгого выполнения и оптимизировать его.

• Встроенное версионирование скриптов с функцией отката. Если изменения привели к ошибке, администратор может вернуть предыдущую сохранённую версию без потери данных.

• Интеллектуальная система подсказок (IntelliSense). Эта функция помогает быстрее написать запрос к базе данных без указания названий таблиц или полей. Администратор может написать название процесса или параметра, а система сама заполнит нужные значения.

«Обновлённый редактор “Первой Формы” решает ключевые технические задачи при настройке BPM-системы. IntelliSense для создания автоматизаций, инструменты анализа производительности SQL-запросов и система версионирования формируют комплексное решение, которое сокращает технический барьер между бизнес-требованиями и их реализацией».

Евгения Бушуева, руководитель проекта по тестированию нового интерфейса администрирования «Первой Формы»

Другие функции новой версии можно изучить в материале на сайте.

В связи с интенсивным сокращением максимального срока действия TLS-сертификатов (пока что обещают 47 дней, но для всех и к 2030 году), коллеги саркастически поинтересовались, можно ли сделать так, чтобы сертификат выписывался на каждый TLS-запрос. Шутки - шутками, но сделать-то можно. И даже не требуется переделывать протокол TLS - есть готовое решение.

Если внимательно посмотреть на алгоритм TLS-хендшейка, то окажется, что секретный ключ, соответствующий открытому ключу из серверного сертификата, требуется там только один раз - для формирования подписи в сообщении CertificateVerify. Соответственно, секретного ключа от сертификата вообще может не быть на сервере, а сервер будет обращаться к некоторому подписывающему узлу, у которого этот ключ есть и который подтвердит TLS-сессию, подписав значение для CertificateVerify. Это вовсе не теоретическое рассуждение, именно так делается на практике, когда входящие соединения принимает прокси-провайдер (CDN, обычно), но передавать этому провайдеру секретные ключи от сертификатов для своих доменов клиент не желает. Первыми в промышленных масштабах такую услугу сделали в Cloudflare, более десяти лет назад. Называется Keyless SSL.

Так что, вместо возни с автоматическим перевыпуском суперкоротких сертификатов, центральный сервис может выдавать квитанции доступа на каждую TLS-сессию. Естественно, TLS-сертифкат сервера должен быть предъявлен раньше, чем отправлено сообщение с подписью CertificateVerify. Однако эти сообщения в TLS передаются сервером одной серией, поэтому, в процессе создания TLS-сессии, сервер сможет сразу же получить от центрального узла и сгенерированный только что сертификат, и соответствующую подпись, собрать это всё вместе и отправить клиенту.

Сертификат, таким образом, окончательно превратится в безотзывный тикет доступа, мгновенного действия, а сервер будет привязан к центральному провайдеру (можно совместить с крупными CDN, у которых и так есть собственные хорошо известные УЦ). Проверку совпадения подписей, серверной и на сертификате, будет всё так же проводить браузер (речь, напомню, про веб). В браузере ничего не нужно переделывать совсем: если сервер не смог предъявить корректную подпись в CertificateVerify - TLS-сессия браузером установлена не будет.

Это, если что, была минутка технологического юмора. Но вот то, что развитие инфраструктуры TLS-сертификатов в вебе движется в сторону тикетов доступа (или, скорее, квитанций) - отрицать всё сложнее.

Заполните опрос State of DevOps Russia 2025: помогите отследить тренды и развитие DevOps-практик

«Экспресс 42» запустил ежегодное исследование состояния DevOps в России. Ключевой темой исследования в 2025 году будет developer experience. На основании ваших ответов хотим изучить, что помогает компаниям формировать позитивный опыт для разработчиков и как на него влияют внутренние платформы, ML/AI-инструменты, облачные технологии и практики ИБ. 

В остальном, как и всегда, посмотрим, какие инструменты используют в индустрии, отследим технологические тренды и изучим факторы, влияющие на профиль эффективности компаний. Результатами поделимся осенью. Если у вас есть опыт в сфере DevOps — пройдите опрос. Это займёт около 20 минут. Чем больше респондентов, тем точнее результаты. 

Для кого опрос

Мы приглашаем заполнить анкету исследования всех специалистов, связанных с DevOps: инженеров и администраторов, разработчиков и тестировщиков, техлидов и тимлидов, CIO и CTO. В 2024 году в опросе приняли участие больше 4100 респондентов, и мы надеемся, что в этом году вас будет ещё больше. 

Если вы заполните анкету, то сможете поучаствовать в лотерее с розыгрышем классных призов от «Экспресс 42» и генеральных партнёров исследования. Более 80 победителей получат мерч, подписки на полезные и развлекательные сервисы, промокоды на незаменимые в работе продукты и билеты на такие профильные конференции, как Highload и DevOpsConf. 

Присоединяйтесь!

P. S.

Полные отчёты с 2020 по 2024 год можно скачать на лендинге State of DevOps Russia.

Что нужно знать и уметь начинающему системному администратору?

Умение работать с Bash и применять grep, awk, sed, tar, ssh, scp — это здорово, но еще далеко не все. Даже для новичка. Хорошо бы погрузиться в тонкости работы с железом, сетями, автоматизацией, виртуализацией, оркестраторами, базами данных и вот этим всем. Ну и софт-скиллы подтянуть, куда же без них.

Чтобы ничего не упустить, мы собрали небольшой скилл-сет со ссылками на полезные обучающие материалы: статьи, видео, книги, курсы, тренажеры и т. д. Изучайте и прокачивайте компетенции.

А еще просто напоминаем, что у нас есть бесплатный курс (с теорией, практикой и тестами) для системных администраторов.

Вы научитесь:

• администрировать Linux на SelectOD,

• работать с командной строкой и основными утилитами,

• управлять пользователями, файлами и правами доступа,

• настраивать сети, SSH-соединения и мониторинг системы,

• анализировать логи и устранять инциденты,

• управлять пакетами и обновлениями программного обеспечения.

«Первая Форма» представила SRM-решение с ИИ-агентами для автоматизации закупочных процессов

SRM-решение на базе low-code BPM-платформы объединяет компанию-заказчика и поставщиков в едином информационном пространстве, автоматизируя полный цикл закупочных процессов — от формирования потребности до исполнения контракта.

SRM-система обеспечивает единую базу данных поставщиков, номенклатур, договоров и рекламаций, позволяя отслеживать весь жизненный цикл закупок. Она также минимизирует риски при взаимодействии с поставщиками благодаря искусственному интеллекту — ИИ-агенты могут проверить благонадёжность контрагентов по данным из Контур.Фокуса и информации об арбитражных делах. 

«Долгое время компании полагались на зарубежное ПО для управления закупками, но после ухода иностранных вендоров выросла потребность в отечественных аналогах. Мы разработали SRM-решение, которое заменяет функции SAP SRM и даёт компаниям инструменты для управления поставщиками, автоматизации закупок, проведения конкурсных процедур и работы с договорами. Всё это на единой low-code платформе с возможностью установки на сервер заказчика», — комментирует генеральный директор «Первой Формы» Денис Селезнёв.

Часть процесса можно делегировать ИИ-агентам — виртуальным сотрудникам, которые обучаются на корпоративных инструкциях.

Фонд «Сколково» и аналитический центр TAdviser провели исследование российского рынка SRM. По результатам демо-показа «Первая Форма» получила высший балл в группе low-code решений и 2 место среди всех платформ, включая  специализированные решения.

В честь "Всемирного дня бэкапа" решил частично проверить восстановление той части резервного копирования, что описана у меня сколько-нибудь подробно здесь (на Дзене, в той же статье короткие воспоминания о бэкапах в 80-е годы). Скрипты копирования такие:

@start "split into BD-RE slices" %comspec% /k py .\bd_split.py %~nx1

#! python3.13

import sys


BUF_SIZE = 1024 * 1024
FS_SIZE = 2048 * 512 # кратно BUF_SIZE, значит можно использовать сравнение count == BD_DISK_SIZE
BD_DISK_SIZE = 25025314816 - FS_SIZE

file_name = sys.argv[1]
source = r"K:\backup\2311\{0}".format(file_name)
dest_head = r"D:\kvk\YandexDisk\Acronis\{0}".format(file_name)

with open(source, "rb") as input:
    part = 1
    while True:
        count = 0
        with open(dest_head + ".{0:02d}".format(part), "wb") as output:
            bytestring = input.read(BUF_SIZE)
            while bytestring:
                count += output.write(bytestring)
                if count == BD_DISK_SIZE:
                    part += 1
                    break
                elif count > BD_DISK_SIZE:
                    raise Exception("Превышен максимальный размер диска для части {0}...".format(part))
                bytestring = input.read(BUF_SIZE)
            else:
                break

Поскольку облако не специализированное, подписываю GnuPG подписью получившиеся кусочки для последующего возможного контроля целостности.

Сегодня в процессе проверки подключил внешний жёсткий диск с бэкапами, для самой маленькой резервной копии из недавних посчитал SHA256, восстановил её же из облака вместе с подписями, проверил их, собрал эту инкрементную резервную копию из кусочков, проверил SHA256. Совпали. Последний раз проверял по такой схеме наверно более 10 лет назад, ну и сегодня "на всякий случай" :)

А вообще у меня бэкапы проверяются периодически (какие автоматически после каждого резервного копирования, какие вручную еженедельно), а восстановление из копии при изменениях в "железе" и обновлении софта обычно.

Вебинар: «Импортозамещение в госсекторе — от операционной системы до оперативного управления компанией»

Кто проводит: эксперты компаний РЭД ОС и «Первая Форма»

Кому полезно: техническим специалистам, бизнес-аналитикам, директорам по ИТ и инновациям в госкомпаниях и ведомствах

Почему это важно:

С 1 января на объектах КИИ запрещено зарубежное ПО. Также Минцифры рекомендует госкомпаниям и ведомствам использовать только российские операционные системы и офисные программы. 

Но на практике большая часть настольных компьютеров в госучреждениях по-прежнему работает на продуктах Microsoft. 

На вебинаре мы рассмотрим пример внедрения ПО для полного импортозамещения – low-code BPM-системы на отечественной операционной системе РЕД ОС.

Что узнают участники:

• какие технологические и правовые аспекты нужно учитывать при импортозамещении в госсекторе.

• какие процессы можно автоматизировать в едином решении — от управления госпрограммами до планирования отпусков.

• как свои процессы оцифровали в Аналитическом центре при Правительстве РФ, Академии Ростеха и других компаниях. 

Как попасть:

Участие бесплатное, по предварительной регистрации. Вебинар состоится 16 апреля в 12:30.

Расширили почтовые тарифы в SpaceWeb

Вам письмо: делимся апдейтами почтовых тарифов в SpaceWeb. Напомним, что мы можем помочь с созданием электронной почты на собственном домене. Что нового: теперь с 10 Гб мы добавили место под почту до 50 и 100 Гб.

И ещё некоторые фичи почты для домена от SpaceWeb:

• неограниченное количество доменов и почтовых ящиков;

• защита от спама и вирусов: доступен комплекс от Лаборатории Касперского для контроля почтового трафика от вредоносного ПО и спама;

• сбор писем работает по протоколам IMAP, POP3, SMTP;

• есть поддержка кириллических доменов.

Узнать подробнее о возможностях и тарифах можно на нашем сайте. Приятный бонус: при оплате за год действует скидка.

Привет, Хабр! Меня зовут Станислав Егоркин, я инженер юнита IaaS департамента разработки Infrastructure в AvitoTech.

Недавно я рассказывал о новых подходах, которые мы использовали при создании дашбордов для диагностики. С тех пор дашборды такого типа обрели еще большую популярность, и мы решили выложить пример их реализации в галерею дашбордов Grafana.

За основу я взял наш дашборд Node Status, который показывал в предыдущей статье. Напомню, он служит для того, чтобы быстро понять, все ли в порядке с нодой в Kubernetes-кластере. В своей основе она содержит множество небольших панелек, которые единообразно подсвечиваются при возникновении аномалий: оранжевый значит «обрати внимание», красный - явно что-то не так. При необходимости по клику можно получить расширенную информацию по каждой метрике.

Я очистил наш внутренний вариант от специфики. Это позволяет использовать дашборд в любых окружениях, в которых развернуты нужные экспортеры:

• node-exporter (лейбл «node» должен содержать имя Kubernetes-ноды);

• kube-state-metrics;

• node-problem-detector (опционально).

Несмотря на то, что все панельки должны в этом случае работать «из коробки», сам дашборд все же следует воспринимать как конструктор. У каждой инфраструктуры есть специфика, и вы можете легко отразить ее, опираясь на то, как реализованы уже имеющиеся панели.

Я полагаю, что ценность Node Status для комьюнити состоит не в том, какие именно метрики на ней собраны, а в том, на каких принципах она основана. Эти принципы зарекомендовали себя у нас, и вероятно будут также полезны и вам.

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

Вспомнились давние обсуждения в выборе размера кластера в файловой системе. Где всё плохо, маленький размер больше фрагментация, большой слишком много места пропадёт. Так вот стало интересно сколько же места будет пропадать в зависимости от размера кластера, компьютере среднестатичтического(ну на моём допустим) пользователя.

Сейчас у меня диск 2TB на котором в общей сложности живут 1998738 файлов от исходников линукса и его компонентов, до фото/видео архива, игр, софта и всяких там ISO(хотя под них в основном NAS используется). Сейчас всё это добро занимает порядка 1.6TB

Я проиндексировал весь диск. и решил посчитать сколько будет оверхед по месту для размера кластера от 512 до 64К.

512 - 529MB
1K - 1076MB
2K - 2232MB
4K - 4769MB
8K - 10162MB
16K - 22102MB
32K - 47990MB
64K - 103391MB

Вот такая математика.

PS. Я не учитывал что файлы могут хранится в MFT. так как какой максимальный размер файла там может хранится для меня вопрос окутанный тайной.

Orion soft обновляет виртуализацию zVirt: Storage DRS, репликация на уровне СХД YADRO и Huawei, ядро ИСП РАН и другие новые функции

31 марта мы выпустим крупное обновление нашей защищенной платформы виртуализации zVirt.

Версия 4.3 включает инструмент для объединения нескольких доменов хранения в логический кластер (Storage DRS), управление репликацией на уровне СХД YADRO и Huawei, управление сертификатами через интерфейс, отечественное ядро ИСП РАН, Terraform-провайдер и еще 30 улучшений.

Приглашаем 1 апреля в 11:00 по Мск на вебинар о новом релизе, на котором расскажем подробнее о главных нововведениях и поделимся планами на развитие продукта.

Регистрация открыта по ссылке.

Вышла новая версия XRay-core v25.3.6, одно из самых интересных нововведений которой - возможность обхода блокировок с помощью domain fronting и локального MitM без использования прокси-сервера. Идея domain fronting основана на том, что некоторые сервисы и CDN (например, Google/Youtube, Meta/Facebook/Instagram, а также Fastly, которую используют Reddit и Twitter) позволяют обращаться к своим сайтам и сервисам, передавая разные домены в поле SNI (при установке зашифрованного соединения - это поле видно оборудование анализу трафика и на основании его содержимого принимается решение о блокировке или замедлении) и в поле "Host" HTTP-запроса. Таким образом можно, например, обратиться к серверу "youtube.com" указав в SNI адрес "google.com", в результате чего клиент получит доступ к Youtube, но для стороннего наблюдателя это будет выглядеть как обращение к поисковику.

XRay в новой версии позволяет автоматически производить такие подмены для заданного списка доменов, и таким образом получать доступ к сервисам, страдающим от устаревания оборудования (по мнению РКН) напрямую без замедления и без использования прокси-серверов.

Поскольку при использовании domain fronting сервер будет отвечать сертификатом "подменного" домена, а не того домена, который запросил браузер, XRay так же на лету подменяет сертификаты из ответа сервера на свои самоподписанные с нужным доменом - для этого нужно добавить в список доверенных сертификатов в браузере свой самоподписанный корневой сертификат.

Краткое описание настройки можно найти здесь, а подробный пример конфигурации клиента - здесь.

Хабр, привет!

Приглашаем на митап о карьере в Linux🐧.

19 марта эксперты компании и приглашенный гость — блогер Константин Дипеж (DeusOps) — обсудят профессиональный путь Linux-специалиста.

— как безболезненно «вкатиться» в Linux

— с чем откликаться на вакансию

— какие вопросы задают на техническом интервью

— как расти профессионально после оффера

— как развиваться в DevOps и не только

Приглашаем Linux-специалистов, которые видят зоны роста и хотят выйти на новый уровень профессиональной экспертизы

Во время дискуссии можно будет задать вопросы спикерам. За лучшие – обещаем мерч;)

Встреча пройдет онлайн, 19 марта в 18:00 (мск). Подробности и регистрация на сайте.

IMPulse - менеджмент инцидентов. Интеграция с Telegram.

После первой публикации об IMPulse, стало понятно, что основная интеграция, которую от нас ждут, это Telegram. И мы рады её представить!

Для работы с Telegram мы использовали группы с топиками - они лучше всего ложатся на наш функционал. В процессе разработки мы столкнулись с багом при упоминании (mention) пользователей в Telegram, о чём составили соответствующий issue. Если вы тоже заинтересованы в закрытии этого бага, пожалуйста поставьте "👍".

Помимо интеграции с Telegram стоит упомянуть реализованный шедулер для работы команд реагирования по расписанию. Синтаксис конфигурации составлен таким образом, чтобы в будущем была возможность интегрироваться с внешними календарями типа Google.

Также мы запустили нашу группу в Telegram для вопросов и обсуждений.

Скоро мы снова придём с очередными хорошими новостями! Подписывайтесь здесь, в Telegram'е или на GitHub'е, чтобы быть в курсе.

Представим, что у нас некоторая система, состоящая из микросервисов, которые работают на разных машинах, но внутри общей IP-сети на немаршрутизируемых IP-адресах (10.0.0.0/8, 192.168.0.0/16 и т.д.). Микросервисы разговаривают друг с другом по TCP, подключаясь по IP-адресам, указанным в соответствующих конфигурационных файлах каждого. Но можно указать и не IP-адрес, а некий хостнейм, прописав его же в /etc/hosts. Почему-то часто считают, что "хостнейм эквивалентен IP-адресу". Оно, конечно, удобно так считать, с точки зрения "человекопонятности", но не всегда хорошо с точки зрения безопасной настройки.

Дело в том, что опечатка (или намеренная замена символа) в имени хоста может привести к тому, что адрес окажется в чужой DNS-зоне. Простейший случай: users-db.example.com -> users-db.example.co. Да, должно быть закрыто, да, есть .local, а хостнеймы можно записывать одним "лейблом", но это не решает проблему: использование символьного хостнейма гарантирует дополнительные запросы для разрешения имён, будь то локальные запросы на той же машине или запросы внешние, возникшие из-за опечатки. А всякий, даже локальный, библиотечный/системный вызов, выполняющий трансляцию имён и адресов, готов принести с собой неожиданные эффекты (см. ниже пример уже про IP-адреса). Не обязательно это эффекты от подмены библиотеки или подмены конкретного вызова. А если кто-то умеет записывать в /etc/hosts, то он и конфиг любой поправит. Что, впрочем, не всегда так, поскольку раскладывание hosts по машинам могут автоматизировать - тогда перехватить нужно только точку управления скриптом, формирующим файл. А ведь ещё обычно используется два протокола: v6 и v4, адреса и "резолвинг" там разные.

Если в конфигах микросервисов прописывать непосредственно IP-адреса (пусть и автоматом), то ситуация несколько лучше. Есть неплохие шансы, что трансляция имён/адресов не будет использована. Минимальная опечатка в записи немаршрутизируемого адреса реже приводит к тому, что трафик убегает наружу. Это так потому, что, во-первых, на то они и немаршрутизируемые; во-вторых, в таких системах обычно настраивают различные ACL, а они настраиваются для IP, в других местах, не на конкретной машине с микросервисом, да и пальцы у настраивающих ACL дрожат по-иному.

Тут, впрочем, необходимо отметить некоторые тонкости: ping 010.010.010.010 -- на многих и многих системах отправит пакеты в сторону серверов Google (проверьте). Я раньше рекомендовал использовать этот довольно хитрый "оборот" в рамках собеседований на должность сетевого инженера/разработчика (теперь уже смысла, понятно, нет), поскольку понимание того, почему здесь пакеты уходят в сторону сети Google, раскрывает основную часть опасений, связанных с использованием имён хостов в конфигах. Но всё же, в 010.010.010.010 - более одной "опечатки".

Образы FreeDOS, HDAT2, MHDD, memtest86+, UEFI memtest86, UEFI Shell для загрузки в Ventoy (требуется версия 1.0.80 или новее)

Скачать: tools-ventoy (GoogleDrive)

Файлы .7z необходимо распаковать. Файлы .img уже сжаты gzip поэтому не запакованы в архивы.

Legacy/CSM: FreeDOS_vtmemdisk.img, HDAT2v7.5_vtmemdisk.img, MHDDv4.6_vtmemdisk.img

memtest86+v7.20_vtgrub2.iso - комбинированный ia32 + x64, Legacy/CSM + UEFI

UEFI: UEFI_memtest86v11.2_vtgrub2.iso, UEFI_shellx64.efi

Let's Encrypt больше не будет отправлять уведомления по электронной почте об истечении срока действия сертификатов

Ну что ж, вот и кончилась эпоха... С момента своего создания Let’s Encrypt отправлял уведомления об истечении срока действия сертификатов по электронной почте подписчикам, которые предоставили им свой адрес. Однако, начиная с 4 июня 2025 года, данная рассылка будет прекращена.

Let’s Encrypt приводит следующие аргументы в поддержку этого решения:

1. За последние 10 лет подавляющее большинство подписчиков внедрили автоматизированные системы обновления сертификатов, которые являются более надёжными, чем получение уведомлений по электронной почте.

2. Для рассылки уведомлений Let’s Encrypt вынужден хранить миллионы адресов электронной почты, что негативно сказывается на конфиденциальности. Сокращение объёма хранимых данных рассматривается как приоритетная задача.

3. Отправка уведомлений обходится в десятки тысяч долларов в год — средства, которые можно использовать гораздо эффективнее для улучшения других компонентов инфраструктуры.

4. Поддержка системы рассылки увеличивает общую сложность инфраструктуры, требуя дополнительных ресурсов и повышая вероятность ошибок. С учётом планов по внедрению новых функций становится необходимым сокращение избыточной сложности инфраструктуры.

Для тех, кто хочет продолжать получать уведомления об истечении срока действия сертификатов есть возможность воспользоваться сторонним сервисом Red Sift Certificates Lite (https://redsift.com/pulse-platform/certificates-lite). Мониторинговый сервис Red Sift предоставляет уведомления бесплатно для 250 сертификатов.

Несмотря на заявленное стремление сокращать количество хранимых адресов для рассылки уведомлений об истечении срока действия сертификатов, рассылки о новостях Let’s Encrypt и ее материнской компании ISRG (https://www.abetterinternet.org/) не прекратятся... А те кто не успел на них подписаться даже могут это сделать. Правда, как это сочетается с желанием сократить общую сложность инфраструктуры, я уже не могу и предположить.

Для тех, кто еще не добавил автоматическое обновление сертификатов на свой сервер – вот подходящая команда для cron (пытается обновить сертификаты через каждые трое суток):

0 2 */3 * * /usr/bin/certbot renew --quiet >/dev/null 2>&1

Добавить ее можно путем вызова команды crontab -e

Обратите внимание что после ввода строки надо обязательно нажать Enter!

Из Let's Encrypt сообщают, что выпустили первый TLS-сертификат сроком действия шесть дней. Сделать такие TLS-сертификаты доступными для всех планируют к концу 2025 года. Короткоживущие сертификаты не будут содержать ни ссылки на OCSP-респондер, ни ссылки на точку раздачи CRL. То есть, никаких механизмов проверки статуса (отзыва) в сертификате не предусмотрено. Такой вариант допускается для короткоживущих сертификатов требованиям CA/B-форума (организация, через которую определяются требования к УЦ, корневые ключи которых включаются в дистрибутивы браузеров).

Для подключения шестидневных сертификатов нужна поддержка соответствующих профилей в ACME-клиенте. Очевидно, заказ короткоживущих сертификатов для легитимных, - долгоживущих, - сайтов имеет смысл выполнять только полностью автоматически. Зато такие сертификаты обещают и для IP-адресов, что удобно в ряде сценариев использования. DNS для подтверждения управления IP-адресами не подходит. Поэтому проверяется только факт управления узлом под заданным IP-адресом, а не доменной зоной. И такая проверка будет происходить не только по HTTP, но и довольно экзотическим методом TLS-ALPN, который целиком работает на уровне TLS и вообще не виден для веб-сервера, работающего выше TLS.

Что касается перехода к короткоживущим сертификатам. В современном вебе отзыв сертификатов, фактически, не работает. Это хорошо известно. Считается, что коротоживущие сертификаты, в основном, решают эту проблему, так как, в случае компрометации ключа, всё равно быстро заканчивают действовать. Тут, впрочем, нужно учитывать, что это касается только отзыва, а атаки с подменой сертификата вполне могут быть достаточно "быстрыми", чтобы короткоживущий сертификат не оказался самой большой помехой. Но, конечно, подменный сертификат, действующий год, лучше подменного сертификата, валидного только до пятницы - тут не поспорить.

Поскольку проблема отзыва сертификатов и компрометации ключей - одна из центральных в этой области, можно предположить, что скоро короткоживущие сертификаты получат приоритет и в браузерах. Последует постепенный, - но достаточно быстрый, - отказ от доверия "долгим" сертификатам только на основании периода валидности, даже без проверки подписей и доверия к УЦ. Технически, ограничение срока действия может применяться и к оконечным сертификатам от УЦ, корневые ключи которых были добавлены в браузер вручную.

Эта строгая тенденция к снижению срока действия сертификатов, которым браузеры соглашаются верить, достаточно давняя - ей около десяти лет. А хорошим подтверждением курса на "сверхкороткие" сертификаты является то, что в рекомендациях CA/B-форума для таких сертификатов уже закреплено отсутствие требования ссылки на CRL (OCSP сейчас не является обязательным для любых оконечных сертификатов).

Я разверну этот мониторинг «с трех нот»: система для инсталляций с десятками СХД

Инженеры YADRO включили в состав продукта TATLIN.SATELLITES интегрированное решение для мониторинга — система получила название Monitoring Appliance. Она включает в себя компоненты для сбора и хранения метрик со множества массивов, а также их визуализацию и алертинг.

Возможности Monitoring Appliance

Система мониторинга, разворачиваемая из Docker Compose, может: 

• Собрать метрики производительности компонентов СХД по протоколу SNMP.

• Принять и обработать SNMP traps от СХД.

• Принять и обработать Syslog-сообщения от СХД.

• Мониторить состояние сервера, на котором установлен Monitoring Appliance.

• Отображать данные мониторинга в виде дашбордов.

• Оповещать о внештатных ситуациях и пороговых состояниях.

Главная страница визуализации мониторинг. На ней отображаются основные метрики «здоровья» систем хранения данных, на которых хочет сфокусироваться пользователь. Можно выбрать нужную СХД и получить данные конкретно по ней. Также этот дашборд легко пересобрать, исходя из своих целей. 

Из чего состоит мониторинг и как его повторить, читайте по ссылке →

Это задачка для DevOps-инженера: почему ArgoCD не расшифровывал секреты из Vault

Нашему DevOps-специалисту Антону нужно было развернуть helm-чарт для Airflow с использованием ArgoCD. Как известно, ArgoCD реализует концепцию GitOps и подразумевает хранение манифестов в репозитории. Но часть данных в values чувствительна, например пароль от базы данных PostgreSQL. Поэтому неплохо было бы вынести эти данные в хранилище секретов (в этом случае — HashiCorp Vault), чтобы скрыть информацию от лишних глаз.

Есть несколько способов подтянуть секреты из Vault в поды. Наиболее предпочтительный по ряду причин — vault-injector. В обычной ситуации Антон бы воспользовался им, но в случае с helm-чартом Airflow задача показалась непростой. Поэтому он решил воспользоваться менее предпочтительным, но точно рабочим (как думал Антон) вариантом с ArgoCD Vault Plugin.

Какая вылезла проблема

Когда секреты были добавлены в хранилище, а ArgoCD Application написан, Антон попытался развернуть его для теста. Вот примерный Application, с которым это делалось (весомая часть пропущена для компактности):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: airflow
 labels:
   app.kubernetes.io/name: airflow
   app.kubernetes.io/component: airflow
 namespace: argocd
 finalizers:
   - resources-finalizer.argocd.argoproj.io
spec:
 project: default
 destination:
   namespace: some-namespace
   name: cluster
 source:
   repoURL: "airflow_repo_url"
   targetRevision: "revision"
   chart: airflow
   plugin:
     name: argocd-vault-plugin-helm
     env:
       - name: HELM_VALUES
         value: |
             ...
             metadataConnection:
               user: user
               pass: <path:path/to/airflow/secrets#postgres_password>
               protocol: postgresql
               host: postgres.db.url
               port: 5432
               db: airflow_db
               sslmode: prefer
             ...
   
 syncPolicy:
   automated:
     prune: true
     selfHeal: true
   syncOptions:
     - Validate=true
     - CreateNamespace=true

Ничего необычного, за исключением прокидывания values прямо из Application и того самого секрета. А еще — компонент webserver отказался запускаться, ссылаясь на невозможность подключиться к базе данных. Хотя данные были абсолютно точно правильными.

В чем итоге была проблем и как Антон с ней справился, читайте в статье →

Практический курс «Системный администратор Linux с нуля»

Привет, Хабр! Selectel запускает курс по работе с серверной операционной системой. Он будет полезен начинающим администраторам, а также разработчикам и DevOps-инженерам, которые хотят погрузиться в Linux и сетевую инфраструктуру.

На курсе вы научитесь:

▫️ работать с командной строкой и основными утилитами;

▫️ управлять пользователями, файлами и правами доступа;

▫️ настраивать сети, SSH-соединения и мониторинг системы;

▫️ управлять инфраструктурой на базе Linux;

▫️ управлять пакетами и обновлениями программного обеспечения;

▫️ анализировать логи и устранять инциденты.

Занятия построены на базе SelectOS. Дополнительных знаний не требуется — достаточно базового владения компьютером и интереса к Linux.

Смотреть программу →