Открытый проект SecretScanner помогает парсить пароли, API‑ключи, токены и другие ценные данные из приложений. Сервис проверяет Docker образы и файловую систему, чтобы отыскать секреты. Внутри у каждой программы есть целая база важной инфы — можно почерпнуть множество полезностей.
Добрый день, уважаемые коллеги!
Прошу прощения за задержку тары сообщения, но новость о прекращении разработки и сопровождения pgbackrest более неактуальна: https://github.com/pgbackrest/pgbackrest#maintenance-update
Спасибо @Harliff: https://habr.com/ru/articles/820349/#comment_29976278
Нужна ли кувалда, чтоб вынуть один кривой гвоздь?
Иногда служба каталога не падает. Не горит. Не уходит в отказ. Всё формально работает.
Просто у 10 000 пользователей внезапно изменился не тот атрибут. Или пропало членство в группе. Или после массового скрипта часть прав доступа поехала в сторону, куда никто не планировал.
И вот тут резервная копия превращается из «спасительного круга» в довольно грубый инструмент.
Полный откат – не всегда ответ
С резервными копиями всё понятно: они нужны. Без них инфраструктура живёт на честном слове и удаче администратора.
Но у каталога есть неприятная особенность. Ошибка часто бывает не катастрофической, а логической.
Не «всё умерло», а:
– удалили одну важную группу;
– изменили атрибут у тысяч пользователей;
– сломали членства;
– неверно применили политику;
– после миграции обнаружили хвосты в объектах;
– интеграция записала в каталог не то, что должна была.
Сервис при этом может продолжать отвечать. Пользователи могут даже какое-то время работать. Мониторинг не обязательно сразу закричит.
А потом выясняется, что доступы уже разъехались, часть приложений видит некорректные данные, а исправлять это руками – отдельный вид админской археологии.
Почему полное восстановление неудобно
Классический сценарий восстановления из резервной копии часто мыслится как «поднять состояние на момент снимка».
Для аварии это нормально.
Для точечной ошибки – не всегда.
Если откатить каталог целиком, можно вернуть не только испорченные данные, но и потерять корректные изменения, которые появились после бэкапа. Новые пользователи, изменения групп, обновлённые атрибуты, свежие правки политик – всё это тоже часть реальной жизни каталога.
Получается выбор без хорошего варианта:
1️⃣ откатить больше, чем нужно;
2️⃣ написать скрипт и надеяться, что он не добавит новых сюрпризов;
3️⃣ вручную разбирать, что именно поменялось.
Третий вариант обычно рассматривается годным только до тех пор, пока объектов не сотни и не тысячи.
Что хочется иметь на практике
В идеальном мире администратор должен видеть не просто «у нас есть резервная копия».
А что именно изменилось между текущим состоянием каталога и снимком:
– какие объекты удалены;
– какие изменены;
– какие перемещены;
– какие атрибуты отличаются;
– какие членства нужно вернуть;
– что будет затронуто перед восстановлением.
И уже после этого восстанавливать не всю базу целиком, а только нужную часть: объект, группу, членство, атрибут, параметр политики.
Это не отменяет резервное копирование. Это добавляет к нему более тонкий инструмент.
Кувалда нужна, когда стена рухнула. Но если надо достать один криво забитый гвоздь, кувалда внезапно становится странным выбором.
Где здесь РЕД АДМ 2.1 и Granulex Recovery
В РЕД АДМ 2.1 появилась интеграция с Granulex Recovery – подсистемой для резервного копирования, сравнения состояния каталога и точечного восстановления LDAP-объектов и их атрибутов.
Смысл не в том, чтобы «ещё раз сделать бэкап». Смысл в другом: дать администратору возможность сначала увидеть разницу, а потом вернуть только нужные данные без полного отката каталога и без остановки службы.
Для крупных инфраструктур это особенно важно. Чем больше пользователей, групп, политик, интеграций и зависимых сервисов, тем опаснее становится подход «ну сейчас быстро откатим всё назад».
Потому что «всё назад» – это не всегда восстановление. Иногда это вторая авария, просто более организованная.
Финальный вывод простой: резервная копия спасает от тяжёлого сбоя. Но логические ошибки в каталоге часто нужно не откатывать целиком, а аккуратно вынимать пинцетом.
Так получилось, что мне приходится работать с достаточно древними серверами (причины оставаться на старом железе и софте разные, но достаточно веские). Я и так стараюсь держаться на два шага позади переднего края (чаще всего это Debian oldoldstable), но иногда приходится делать резкий шаг вперёд (обновляться до oldstable, который скоро oldoldstable станет).
Вот и сейчас обновил кое-что с Bullseye на Bookworm. И получил при попытке зайти со старого OpenSSH 5.3 на новый 9.2 “no hostkey alg”. В новой версии OpenSSH по умолчанию отключены алгоритмы ssh-rsa и ssh-dss (первый из-за небезопасного хеша SHA1, второй из-за общей проблемности DSA); а старые версии ещё не умеют rsa-sha2-256, rsa-sha2-512 (не говоря уж об эллиптических кривых).
К счастью, эти алгоритмы ещё не удалены напрочь! Поэтому для обеспепчения возможности подключения старого клиента OpenSSH 5 к новому серверу OpenSSH 9 достаточно записать такие строки в файл /etc/ssh/sshd_config.d/local.conf (и перезапустить sshd):
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
В обратную сторону тоже работает, чтобы иметь возможность заходить новым клиентом OpenSSH 8 (и выше) на старый сервер OpenSSH 5 (и ниже) достаточно прописать такие три строки в файл ~/.ssh/config:
Host old-server
Hostname 1.2.3.4
. . .
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa
KexAlgorithms +diffie-hellman-group14-sha1
Напрямую или через бот-платформу: как лучше интегрировать чат-боты
От выбора зависит не только сложность внедрения, но и дальнейшая поддержка. Разбираем плюсы и минусы подходов на примере интеграции с сервис деск системой.
1. Прямая интеграция с каналом
➕ Полный контроль над функциональностью — например, в случае VK можно обрабатывать не только запросы в личных сообщениях, но и комментарии под постами, на стене, под фото.
➖ Разные API, авторизации, ограничения и нюансы. Требуется закладывать время на поддержку каждого канала.
2. Интеграция через Botmother
➕ Визуальный конструктор — менять сценарии могут не-разработчики. Один сценарий обработки обращений достаточно просто раскатать на разные каналы.
➖ Меньше гибкости в тонкой настройке маршрутизации и аналитики по сравнению с другими платформами.
3. Интеграция через Fasttrack
➕ Расширенные шаблоны ответов, точная маршрутизация по командам, продвинутая аналитика.
➖ Сложнее в настройке сценариев в отличие от того же Botmother.
Что же в итоге? Можно остановиться на способе 2-в-1. Для отдельных сценариев — прямая интеграция, в других случаях — через бот-платформу. Так сделано у одного крупного клиента ITSM 365.
Подробнее про кейс, нюансы в поддержке интеграций и практические шаги по внедрению — в полной версии статьи на Хабре.
K2 Cloud курирует трек “Облака” на ДевФест 21-22 мая
21-22 мая в Омске пройдёт ДевФест 2026, партнером которого стал K2 Cloud. Мы будем на площадке оба дня: со стендом, спикерами и целым тематическим треком “Облака”, который курируем в программе конференции.
В треке поговорим про архитектуру, безопасность, CI/CD, бесшовные релизы, dogfooding, облако в облаке, BI-конструкторы и федеративное обучение. За доклады отвечают эксперты из K2 Cloud, Авроры/ОМП и Битрикс24.
И приятный бонус для тех, кто уже открыл вкладку с билетами: промокод BESTCLOUDEVER даст 10% скидки.
Сам ДевФест пройдет 21 и 22 мая с 10:00 до 18:00, а наш облачный трек – в оба дня с 11:00 до 14:00. Программу конференции можно посмотреть на сайте, а расписание трека дополнительно вынесем сюда:
21 мая
11:00 – JWT в геораспределённой архитектуре: аутентификация пользователей веб-консоли мультирегионального облака (Никита Трунов, K2 Cloud)
Никита разрабатывает инфраструктурные сервисы K2 Cloud на Python и работает с логированием, мониторингом, безопасностью и управлением пользователями. В докладе он разберёт, как устроить аутентификацию в мультирегиональном облаке: где JWT помогает, какие сложности появляются при синхронизации и в каких случаях стоит смотреть в сторону альтернативных или комбинированных подходов.
12:00 – Бесшовные релизы глазами разработчика: обновляем код Облака без отключения API (Игорь Анохин, K2 Cloud)
Игорь как руководитель платформенной разработкой в нашем облаке расскажет про особенности обновления высоконагруженной системы без остановки API. В фокусе будут эволюция релизных подходов от Big Bang до Rolling-Out, требования к коду, миграциям и контрактам, а ещё компромиссы, без которых бесшовность не работает.
13:00 – CI/CD Flutter-приложений для ОС Аврора (Ирина Житницкая, Аврора/ОМП)
Ирина занимается тестированием и CI/CD-процессами публичных проектов ОС Аврора. Она покажет, как перевести сборку Flutter-приложений под ОС Аврора из ручного процесса в прозрачный pipeline, какие архитектурные решения помогают сделать его воспроизводимым и где чаще всего возникают проблемы.
22 мая
11:00 – Архитектура BI-конструктора Битрикс24 (Александр Сербул, Битрикс24)
Александр занимается архитектурой и разработкой высоконагруженных отказоустойчивых проектов в Битрикс24. На примере BI-конструктора он разберёт путь от проектирования до запуска облачного сервиса: архитектурные решения, масштабирование, развитие команд и практическое применение Python и Kubernetes.
12:00 – Ешь, молись, люби своё облако: Dogfooding как драйвер развития (Александр Чернев, K2 Cloud)
Александр участвовал в запуске KaaS и PaaS-платформ K2 Cloud, работал над релизными процессами, тестированием и стабилизацией платформы. В докладе он расскажет, как мы используем собственное облако для разработки и тестирования: зачем нужен dogfooding, как работает “облако в облаке” и как внутреннее использование продукта помогает быстрее находить слабые места.
13:00 – Сломанные веса: как разное железо мешает федеративному обучению и что мы можем с этим сделать (Максим Мухамедов, K2 Cloud)
Максим – Python-разработчик в K2 Cloud, который до разработки успел поработать с инфраструктурой датацентра на физическом уровне модели OSI. Он разберёт, как особенности железа, сенсоров и версий ОС искажают данные в федеративном обучении ИИ, почему возникает system-induced bias и какие подходы помогают отличить проблему данных от проблемы устройства.
Если будете в это время Омске, обязательно заглядывайте к нам: будем ждать вас на стенде и докладах!
VDI в Termit на базе zVirt: как оптимизировать рутинные операции по работе с ВРМ
19 мая Orion soft проведет технический вебинар с демонстрацией функциональности VDI в платформе виртуализации рабочих столов и приложений Termit. Системный инженер Дмитрий Руссу покажет, как выполнять рутинные операции в Termit максимально быстро и эффективно.
На вебинаре подробно рассмотрим:
- Как развернуть виртуальное рабочее место Windows и Linux
- Как подготовить золотой образ и экономить время на создании ВРМ
- Как объединять ВРМ в ресурсные группы и управлять ими
- Как создать каталог и работать с ним
Только для участников вебинара — проведем опрос о пожеланиях по функциональности следующих релизов Termit. Лучшие предложения реализуем, а их авторам подарим эксклюзивные паки мерча Orion soft.
Также ответим на все интересующие вас вопросы. Присоединяйтесь, чтобы научиться новым лайфхакам в работе с Termit и оптимизировать свою рутину.
Кому будет интересно:
- Системные администраторы
- Инженеры (по виртуализации, VDI, ИТ-инфраструктуре, ИБ, технической поддержке и др.)
- Архитекторы (виртуальной инфраструктуры, рабочих мест и др.)
Сервер для PyTorch: как выбрать конфигурацию под обучение и инференс
PyTorch запустится почти на любом сервере, но между «запустится» и «работает стабильно под нагрузкой» — большая разница. Частая ошибка — выбирать VRAM по размеру модели, но видеопамять занимают контекст, KV-cache, размер батча и служебные расходы фреймворка.
В новой статье разобрали, когда хватает CPU и в каких сценариях нужен GPU. Показали, как заранее проверить совместимость драйвера NVIDIA и версии CUDA, как эмпирически измерить фактическое потребление VRAM и сколько RAM закладывать под DataLoader с несколькими воркерами. И собрали ориентиры по конфигурациям — от прототипирования и небольшого инференса до обучения на 2–4 GPU и больших моделей.
Все подробности — в блоге Рег.облака.
Опубликовали программу infra.conf'26 — большой конференции про инфраструктуру и высоконагруженные сервисы
Команда Yandex Infrastructure открыла полную программу infra.conf 2026, которая состоится 4 июня в Москве и онлайн. Фокус конференции этого года — построение и особенности эксплуатации инфраструктуры в эпоху ML.
В трёх треках программы обсудим не только ML‑инфраструктуру, но и базы данных, стораджи, инструменты разработки, observability‑решения, SRE и эксплуатацию и управление трафиком.
Среди докладов от инженеров и разработчиков Яндекса, Сбера, X5 Tech, Wildberries & Russ и других компаний нас ждут темы:
«Как появилась Алиса AI: путь одной LLM» (Аркадий Альшан, Яндекс)
«ML‑платформы для больших компаний» (Антон Алексеев, AvitoTech)
«Как мы построили два больших GPU‑кластера на Kubernetes» (Иван Юмашев, Ozon)
«Два подхода к надёжности распределённых систем» (Евгений Дюков, Yandex Cloud)
«ИИ‑агенты для MLOps‑инфраструктуры» (Марк Кузнецов, Альфа‑банк)
«Особенности observability LLM‑приложений и агентов» (Даниэль Халиулин, Yandex Infrastructure)
Также участникам будут доступны мастер‑классы и выставочная зона инженерных команд.
Infra.conf'26 пройдёт 4 июня в Москве в пространстве TAU. Для участия нужно зарегистрироваться и дождаться приглашения. Также посмотреть доклады в прямом эфире можно будет на сайте конференции.
dpi-checkers — open-source инструмент от hyperion-cs — показывает, каким именно методом ваш провайдер режет трафик: RST после 16-го пакета, SNI-дроп или CIDR-вайтлист. Прогнал на трёх подключениях — картина неожиданная.
Пользователи рунета давно заметили: «интернет дома» и «интернет у бабушки в области» — это два разных интернета. YouTube грузится на одном провайдере и не грузится на другом. Discord висит на мобильном, но работает на проводе того же оператора. Это не случайность и не деградация сети — за каждым таким симптомом стоит конкретный технический механизм на L4/L7.
Набор тестов dpi-checkers (часть на Go как CLI-утилита, часть в браузере на JS) позволяет идентифицировать метод фильтрации, который применяет конкретный ISP. Я прогнал проверки на трёх подключениях: домашнем у федерального провайдера, мобильном у одного из «большой четвёрки» и через знакомого в другом регионе.
Пять методов которые реально встречаются в РФ. DPI — не одна технология, а класс решений. Современный Deep Packet Inspection анализирует не только заголовки L3/L4, но и содержимое L7: по особенностям TLS handshake система определяет сервис назначения даже без знания IP и применяет политику — пропустить, сбросить, замедлить. Когда в новостях пишут «провайдер замедляет YouTube» — это упрощение. Технически применяется один из нескольких методов, и симптомы у пользователя разные в зависимости от метода.
CIDR-вайтлисты — блокировка по IP-подсетям. Трафик к адресам вне «доверенного» списка не пропускается. Жёсткий метод, чаще встречается на мобильных тарифах 4G+/5G.
TCP 16-20 (rps-разрыв) — DPI ждёт первые 16–20 пакетов TLS-сессии, детектирует SNI нежелательного хоста и отправляет RST обеим сторонам. Клиент видит «сайт упал», хотя сервер жив. Основной механизм замедления YouTube в 2024–2025.
Подмена DNS-ответов — перехват запроса на уровне провайдера, возврат заглушки или 0.0.0.0. Старый метод, обходится DoH/DoT, но используется как первая ступень.
SNI-блокировка — поле Server Name Indication в TLS handshake передаётся открытым текстом до установки шифрованного канала. DPI читает его и сбрасывает соединение по домену.
QUIC-блокировки — UDP/443 режется целиком или деградирует, чтобы клиент откатился на TCP, где уже работает SNI-фильтрация.
Что показал dpi-checkers на трёх подключениях. Домашний федеральный провайдер — TCP 16-20 в чистом виде: соединение с рядом зарубежных сервисов рвётся ровно после 16–18 пакетов в TLS-сессии, RST приходит от «провайдерского» адреса, не от сервера назначения. Мобильный оператор — комбинация SNI-дропа и QUIC-блокировки: UDP/443 не проходит вообще, TCP-соединение с теми же хостами рвётся по SNI до завершения handshake. Региональный провайдер через знакомого — DNS-подмена как первая ступень плюс CIDR-ограничения на часть подсетей Cloudflare.
Исследования Citizen Lab и проект net4people фиксируют схожие паттерны по всему рунету — методы стандартизированы, оборудование у операторов в основном одно и то же (ТСПУ от Эшелона и аналоги). Различия между провайдерами — в настройке порогов и в том, какие именно списки им спустили.
Для меня как человека, который строит корпоративные сети, это не абстрактный research. Когда у сотрудника «не работает» корпоративный сервис — первый вопрос теперь не «а VPN включён?», а «какой метод фильтрации у его провайдера?». TCP RST лечится иначе, чем DNS-подмена, и иначе, чем QUIC-блок. dpi-checkers даёт ответ за пять минут вместо часа диагностики вслепую.
Здесь многих морщит, когда они видят откровенно ИИ-шный текст, недостаточно хорошо отражающий суть того о чем он как бы написан. НО!
Вот появилась тут буквально вчера статья на тему "старый ноутбук, мало памяти, zram, swapspaces".
Явно - писана с помощью ИИ, и как справедливо было замечено - из серии "как нарисовать сову": долго готовим рабочее место и инструменты, потом рисуем один глаз, второй, ну а потом остальную сову.
Провисела она тут весьма недолго, пока писал комментарий - ее закидали помидорами и убрали. Тем не менее, по сути статья полезная: я взял и попробовал.
И оно, оказывается, работает, и даже неплохо. Просто автор не дописал, как "дорисовать остальную сову".
Автор, если ты это видишь - сделай людям доброе дело, распиши подробнее.
Я б сам написал - но получится, типа украл чужую статью, а это не очень красиво.
Но тема-то интересная...
Дайджест Рег.облака за апрель
В апреле запустили Free Tier, провели Демо день, добавили пользовательские образы и ИИ-инференс на vLLM, расширили географию защиты от DDoS. Ниже — главное.
Демо день Рег.облака
16 апреля собрались в Центре событий РБК. Показывали развитие облачной платформы, GPU-инфраструктуру, инструменты для ИИ-нагрузок и сценарии масштабирования IT-инфраструктуры. В программе — продуктовые анонсы, технические доклады и практические сессии про эксплуатацию облака, отказоустойчивость, хранение данных и оптимизацию ресурсов. После выступлений участники тестировали сервисы вживую и обсуждали задачи с нашими разработчиками.
Делимся записями обоих треков:
Бизнес-трек — оптимизация стоимости IT-инфраструктуры, соответствие 152-ФЗ, гибридные конфигурации и экономика ИИ-проектов.
Практикум — Terraform для бизнеса, пользовательские ОС-образы, защита от DDoS в один клик и внутренняя кухня S3-хранилища.
Запустили Free Tier — бесплатный уровень доступа к облаку
Free Tier дает бесплатный доступ к облачному серверу. Минимальная конфигурация — 1 vCPU, 1 ГБ RAM и 10 ГБ на NVMe-диске на срок до шести месяцев, расширить ресурсы можно по запросу. Сервер работает в отказоустойчивом публичном облаке и подходит для небольших сайтов, тестовых сред, учебных стендов и пет-проектов, а в расширенной конфигурации — для небольших CMS и CI/CD. Когда проект вырастет, можно перейти на коммерческий тариф без переноса данных и смены архитектуры. Подробности на странице программы.
Линейка тарифов с выделенным CPU в аттестованном облаке 152-ФЗ
Запустили тарифы с выделенным CPU в облаке, аттестованном до первого уровня защищенности по требованиям 152-ФЗ и ФСТЭК. Физические ядра процессора не делятся с другими виртуальными машинами — без переподписки и влияния соседних нагрузок. В основе — процессоры Intel Xeon Gold 2,8 ГГц и NVMe-накопители с низкими задержками.
Линейка рассчитана на базы данных с персональными данными (PostgreSQL, MySQL, 1С, Oracle) и высоконагруженные системы в регулируемых отраслях. Подробнее о тарифах — на нашем сайте.
Создание серверов из пользовательских образов
Добавили загрузку собственных образов виртуальных машин. Пользователь импортирует заранее подготовленный образ из своего S3-хранилища в облаке и разворачивает на его основе ВМ в нужном регионе.
Сценарии: миграция инфраструктуры из других облаков и локальных площадок, собственные сборки ОС и специализированные окружения, контроль над конфигурацией и версиями образов. Подробности — на странице продукта.
AI-платформа и ИИ-инференс на vLLM
Для тарифной линейки с GPU добавили ИИ-инференс — готовую виртуальную машину с vLLM для запуска LLM-моделей на выделенной видеокарте. Пользователь сразу получает рабочую среду без настройки драйверов и фреймворков, а к модели обращается через OpenAI-совместимый API (endpoint + ключ).
ИИ-инференс — часть бета-версии AI-платформы. В нее также входят сценарии разворачивания LLM-моделей, автоматизация процессов через n8n, ИИ-ассистент и JupyterHub.
Расширенная защита от DDoS L3–L7 в трех новых регионах
Услугу подключили в Москве-2 (30 марта), Санкт-Петербурге (8 апреля) и регионе ФЗ-152 (15 апреля). Подробности — на странице продукта.
Желаем продуктивного месяца и спасибо, что следите за обновлениями Рег.облака!
Российский рынок софта — куда мы идем
Привет, друзья!
После предыдущего поста мне захотелось немного порефлексировать относительно того, как сейчас обстоит ситуация с платформами виртуализации. Сегодня я не буду задавать никаких вопросов, пишу эту заметку скорее для фиксации своих мыслей и ваших мнений.
Довольно давно я (как наверняка и многие из вас) размышляю о том, как обстоят дела с софтом и куда все это идет. Естественно, думаю об этом я со своей колокольни виртуализации, но буду рад, если вы выскажитесь под постом и про другие классы и категории.
Итак, как я это вижу.
Раньше на рынке все было довольно мейнстримно - был один лидер (VMware) и множество догоняющих. Все было понятно и предсказуемо. Но в силу произошедших и происходящих до сих пор событий рынок как будто раздробился.
Часть компаний осталась на том же софте, но в ряде случаев - с туманными перспективами. Часть ушла на российские платформы. Кто-то перешел на опенсорс.
Но какого-то единого вектора, как это было раньше, теперь нет. Каждая компания решает задачу по-своему, исходя из бюджета, наличия рук и уровня паранойи требований. И это, пожалуй, главная особенность сегодняшней ситуации.
Отсюда же вытекает проблема с кадрами. Пласт специалистов под VMware был просто огромный, сегодня же, когда внезапно на рынке появилась куча новых платформ, порой приходится искать подходящего человека или же его обучать. Словом, происходит какое-то броуновское движение.
И в связи с этим я все чаще задаю себе вопрос - к чему мы в итоге придем лет через 5-7? Устаканится ли российский софтверный рынок? Найдем ли мы равновесие между привычным зарубежным софтом и подросшим (смею на это надеяться) российским?
Лично у меня ответа пока нет, но есть чувство, что мы находимся в середине большого переходного периода, и конца ему пока не видно.
Как определить свой внешний IP когда действуют белые списки Минцифры
Когда Министерство цифровой деградации России начинает ограничивать Интернет по своим белым спискам, внезапно обнаруживается, что из привычных инструментов не работает ничего. Невозможно зайти ни на один сайт: 2ip.ru myip.ru ifconfig.me ipify.org whatismyipaddress.com www.whatismyip.com ipinfo.io потому что никто из них не занесён в белые списки. Timeweb есть в белых списках, timeweb.com/check-ip страница открывается, но во время работы белых списков все поля пустые. Из поисковых серверов в этот момент доступен только Яндекс, но он тоже ничем не может помочь в данной ситуации, потому что не готов к такому, и предлагает те же самые сайты которые недоступны.
Вспоминаем жизнь до появления поисковых серверов - создаём свои коллекции нужных ссылок вручную.
В момент действия белых списков мне через моего сотового провайдера «Мегафон» (физически я нахожусь в СПб или Ленобласти) доступен очень ограниченный перечень сайтов. Возможно, что в том месте где Вы находитесь белый список будет другим. Просмотрев вручную всё что мне доступно по состоянию на 7 мая 2026 нашёл всего две ссылки которые показывают мой IP адрес: Яндекс Интернетометр yandex.ru/internet и Reg.ru reg.ru/web-tools/myip В Интернетометре Яндекса можно ещё и скорость померить. Из сервисов whois рабочий нашёл только один nic.ru/whois Разумеется, не надо заходить на эти ресурсы через свою выходную ноду VPN. Также, в момент когда действуют белые списки, возможно ещё и замедление скорости доступа даже к тому что разрешено. Привычный дизайн сайтов может быть нарушен, из-за того, что внешние ресурсы подгружаемые сайтом недоступны во время работы белых списков.
IP адрес который выдал Вашему устройству сотовый провайдер можно посмотреть на самом устройстве. На Android это вот тут: Settings / About phone / Status / IP Address
Возможны другие варианты. На BlackView BV9800: Settings / System / Advanced / About Phone / IP Address
Во время работы белых списков на смартфоне 100.82.28.67 а внешний IP на сайте Яндекс Интернетометр в это же время показывает 178.178.244.80
100.64.0.0 — 100.127.255.255 (маска подсети 255.192.0.0 или /10). Данная подсеть рекомендована согласно RFC 6598 для использования в качестве адресов для CGN (Carrier-Grade NAT); Вики
Список подсетей возможно доступных по белым спискам можно посмотреть тут Это — всё что вам надо знать о белых списках: как устроены и 6 способов обхода
PS: Запасайте наличные рубли, во время работы белых списков либо оплата наличными, либо предоплата на сайте. Оплата банковской картой в это время не работает. Видимо эквайринг Сбербанка в белые списки не попал.
SELECTOS OpenFix Day 2.0 стартует через час
В 19:00 (мск) мы начинаем митап для инженеров и системных администраторов. Ждем всех, кто не только разворачивает Linux в продакшене, но и читает исходники, гоняет ядро в дебаггере, отслеживает регрессии и закрывает CVE до того, как они становятся инцидентом.
Программа митапа
Итоги программы OpenFix и планы на будущее.
Пластмассовый мир: что не так с ИИ-хайпом и как с этим жить.
Как ИИ может помочь в управлении ОС.
Как я ронял прод: конкурс инженерных факапов.
Подключайтесь
✔️ на YouTube
✔️ в VK
Отменили разработчиков и пришли за DevOps'ами. Инженеры — всё!
Раньше увольняли кодеров, теперь у микрофона сисадмины
Coder - больше не профессия. Не верите? Cursor, Claude Code, OpenCode уже закрывают вакансии middle-разработчиков быстрее, чем HR успевают постить новые. Кто не верил - уже сидит с гитбуком в одной руке и резюме в другой.
Но была одна святая группа. Люди, которые смотрели на эту вакханалию и говорили: "Ну, нас-то ИИ не заменит. Сервера сами себя не настраивают, прод сами себя не поднимает. У кого рука на пульсе - у того работа есть".
Знакомо? Я тоже так думал.
До вчерашнего дня.
Встречайте: ваш новый коллега - ничего
Пять дней назад Alibaba Cloud выкатил v1.1.0 своего open-source проекта HiClaw. Если кратко - это оператор для AI-агентов на Kubernetes. Агентская команда, которая живёт в Matrix-чате. Ты видишь их переписку, @ упоминаешь, даёшь задачи.
И в этой команде появился новый участник.
Hermes Worker.
Не человек. Не "помощник". Полноценный DevOps-инженер с terminal-песочницей, который: - Лезит в кластер - Смотрит логи - Чинит конфиги - Пишет постмортемы
Сам. Без approvals. В YOLO-mode.
Раньше ты говорил: "У меня мониторинг в 3 ночи - поднимаюсь, лезу в прод, чиню, я незаменим, ваша говношаражка без меня умерла бы давно". Теперь мониторинг пошлёт алерт Hermes Worker-у, тот лезет в кластер, смотрит логи, чинит, пишет постмортем и уходит в спящий режим. Ты узнаёшь об инциденте из утреннего дайджеста в Matrix.
"Ну, это просто автоматизация рутинных операций", - скажете вы. Ага. Cursor тоже начинали с автодополнения скобочек.
Что конкретно произошло
HiClaw работает так: есть Controller (на Go), который через CRD управляет Worker/Team/Manager/Human ресурсами. Вся команда сидит в Matrix-чате. Manager декомпозирует задачу, воркеры исполняют. Ты @упоминаешь, корректируешь, аппрувишь стратегию.
В v1.1.0 добавили Hermes Worker Runtime - first-class сорт воркера наравне с Node.js и QwenPaw.
Чем он отличается: - Node.js Worker - болтает и дёргает тулы - QwenPaw (Python) - инструменты и скрипты - Hermes Worker - автономный программирующий оператор. Сам планирует, исполняет, итерирует
То есть если Manager говорит "нужна диагностика пода в namespce prod, причина OOMKill", Hermes Worker сам: заходит в кластер → смотрит grafana → чекает лимиты → пересчитывает requests/limits → перекатывает деплой → пишет что сделал.
В 3 часа ночи. Без тебя.
Это ещё не всё
Helm Chart с Leader Election, RBAC, PVC - enterprise-ready
Provider-интерфейсы для storage - MinIO, S3, OSS - не надо переписывать контроллер
Multi-container architecture - Manager больше не тащит Higress+Tuwunel+MinIO+Element в одном образе на 1.7 GB. Инфраструктура вынесена в Controller.
Worker lifecycle - сам засыпает при простое, просыпается по запросу
Авто-миграция - старые конфиги сами переезжают в CRD
Всё это open-source (Apache 2.0). Ставится одной строкой:
curl -sSL https://higress.ai/hiclaw/install.shА что с российскими реалиями?
С одной стороны - open-source. Форкнул, поставил через Selectel/k3s, LLM заменил на GigaChat/YandexGPT через Higress Gateway. Данные никуда не уходят.
С другой стороны - вы серьёзно думаете, что ваш enterprise с 15 согласованиями на любой чих готов отдать прод AI-агенту? Даже если он пишет постмортемы?
Хотя... если Manager будет сидеть в Matrix-комнате, где ИБ видит каждый чих - почему нет? Прозрачность операций - единственный аргумент, который может продать эту архитектуру в enterprise.
И чо теперь?
Варианта два.
Первый: сделать вид, что это очередной хайп, который не дойдёт до продакшна. Написать коммент "В наше то время все руками делали, где скрепы? Риск: 4.4k звезд на GitHub, 519 форков, 9 контрибьюторов в релизе, код на Go (не очередной Python-прототип). Не похоже на pet project.
Второй: принять, что DevOps как ниша "я один знаю как чинить этот кластер" - умирает. Hermes Worker не заменит инженера, который придумывает архитектуру. Но он заменит инженера, который в 3 ночи заходит по SSH и чинит конфиг.
Вопрос не в том, заменят ли тебя. Вопрос в том, когда.
Если вы считаете, что вы обманули белые списки Роскомнадзора с помощью VLESS и прочих квн-чудес, то просто представьте, как всё это держится на Yandex Cloud и VK Cloud за счет того, что они арендуют сервера с диапазонами айпи в белых списках...
На днях решил посмотреть свой IP через VPN и заметил хостинг YANDEX CLOUD или VK LLC. И вот непопулярное мнение с ноткой теории заговора, но я задумался о том, почему ВК и Яндекс вообще допускают диапазоны IP своих VDS (про сервисы не говорим, так как исключения легко можно настроить) и особо не спешат блокировать свои IP, и хочу высказать догадку.
Не видел такой точки зрения, но мне кажется, что ВК и Яндексу выгодно и очень прибыльно хостить сервера, айпи которых в белом списке, так как это тот самый важный элемент для КВН, обходящих белые списки и без точки входа во внешний Интернет, оно бы не заработало.
Что можете сказать по этому поводу?
Образ сервера для деплоя: golden image, immutable infrastructure и многослойная сборка
Образ сервера — это основа предсказуемого деплоя. Одна и та же конфигурация на всех инстансах, развертывание за минуты вместо часов, никаких расхождений между средами. На этой идее держатся immutable infrastructure, сборка образа как финальный шаг CI/CD и подход cattle, not pets.
В новой статье разобрали, чем образ отличается от snapshot и бэкапа. Показали, где в CI/CD место Packer, Docker и cloud-init. Рассказали про многослойную сборку и отдельно — про работу с секретами через переменные окружения и регулярную пересборку базового слоя.
Все подробности — в блоге Рег.облака.
Да не может быть!
Вы в интернете чегонть понимаете?
Задам простой вопрос:
Смотри… Есть компьютер, и сервер с сайтом. Они подключены к одному свичу.
Как запретить клиенту подключение к сайту?
Не трогая настройки свича, клиента, и сервера ?
Очевидный ответ…
Я не верю что это так просто, и так легко!
Но вот прямо щас сижу и сморю tcpdump и офигеваю...
Смотри: клиент заходит на сайт (https).
Сайт отвечает ему: у меня такой сертификат.
Клиент идет в интернет проверить сертификат.
РКН режет эту проверку.
Клиент не верит серверу и не заходит на него.
Легко!
Да не может такого быть!
Ubuntu 26.04 LTS (Resolute Raccoon) Взгляд системного администратора
23 апреля 2026 года Canonical выпустила Ubuntu 26.04 LTS Resolute Raccoon. Для меня это старт большого проекта. Работа Linux-администратора в крупной компании подразумевает создание «золотого образа», который потом годами будет крутиться на сотнях машин.
В мои задачи входит поддержка систем управления конфигурациями. И большая часть хостов для пользователей крутится на подготовленной Ubuntu с нужным набором программ, политиками, настройками рабочего окружения, сертификатами, репозиториями, ограничениями, автозапуском, удалённым доступом и прочей инфраструктурной обвязкой. Срок поддержки заявлен до 2031 года. Для корпоративной среды это главный аргумент: если сейчас нормально подготовить дистрибутив, на нём можно спокойно жить ещё 5 лет.
Первое знакомство.
Canonical в документации указывает для Ubuntu Desktop 26.04 минимум 6 ГБ RAM, 2 GHz dual-core CPU и 25 ГБ. В чистом виде, без swap-файла, система заняла у меня около 6.6 ГБ на диске. Потребление оперативки на старте чуть меньше 2 ГБ. На фоне этого официальная рекомендация в 6 ГБ RAM выглядит как оценка для комфортной работы. Думаю после загрузки всех требуемых пакетов, браузеров с десятками вкладок, мессенджерами, антивирусами, агентами и прочими пожирателями ресурсов будет в самый раз. После тестовой установки нескольких тяжеловесных приложений, система ощущается плавной и отзывчивой. Дальше предстоит выяснить что поменялось в системе, где могут сломаться сценарии Puppet, не поедут ли настройки dconf/gsettings и ещё тысячи других мелочей.
Что нового в «Решительном еноте»?
Если сравнивать с 22.04 (которая до сих пор остается основной рабочей лошадкой во многих конторах), то это довольно крупный технологический скачок.
Ядро Linux 7.0. Ubuntu 26.04 базируется на новой мажорной версии ядра. Это поддержка самого свежего железа, оптимизации в работе планировщика, а также свежие фичи в сетевом стеке.
GNOME 50 принёс улучшения в адаптации интерфейса под небольшие экраны, аппаратное ускорение записи экрана, прокачанный remote desktop и более плавную работу. GNOME-сессия теперь работает только на Wayland. Старый добрый X11 не бросили (он работает через XWayland), но стандартная сессия как X.org больше не запускается. Здесь есть риск что все настройки связанные с графикой и удалённым доступом могут сломаться.
Также Canonical удалила PreLogin и PostSession скрипты. Это может задеть корпоративные сценарии, например синхронизацию домашней директории при входе/выходе или очистку временных данных.
Расширилось использования Rust в системе. Это помогает бороться с целым классом ошибок памяти, что всё равно не делает утилиты полностью безопасными.
APT 3.1. Наконец то история операций и команды для отката: apt history-info, apt history-undo, apt history-redo, apt history-rollback. Вещь полезная, особенно когда случайно удалил лишнее.
Так же появилось несколько изменений, которые важны для администратора.
Dracut — новый механизм сборки initramfs по умолчанию. Он отвечает за ранний этап загрузки системы: подготовку драйверов, модулей, шифрования дисков и всего, что нужно до старта основной ОС.
TPM-backed full-disk encryption — полнодисковое шифрование с привязкой ключей к TPM-чипу. Система может разблокироваться автоматически, если проверка целостности прошла успешно. Это удобно, но требует аккуратности при обновлениях BIOS или замене платы.
CUDA и ROCm в репозиториях Ubuntu — упрощённая установка инструментов для вычислений на GPU, что полезно для ML.
Итог
Первое впечатление у меня положительное. Система установилась без сюрпризов, занимает умеренно места, по памяти выглядит адекватно, интерфейс работает плавно. В системе заявлено довольно много новых технологий, что обещает начало долгого марафона по настройке и тестированию. Будем смотреть, как Енот покажет себя в «боевых» условиях.