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

Виртуализация — неотъемлемая часть IT-инфраструктуры. Она лежит в основе всех облачных систем,  обеспечивает изоляцию ресурсов и гибкость управления. Такие возможности, конечно, появились не сразу. Технология прошла долгий путь: начавшись с одного системного вызова в 1980‑х, она переросла в большие инженерные решения. 

В этой статье я расскажу про развитие гипервизоров: от появления системного вызова chroot(2) до возникновения идеи о виртуализации в браузере…

Привет, Хабр! Импортозамещение инфраструктурного стека Microsoft — задача, с которой периодически сталкиваются большие российские компании и субъекты критической инфраструктуры (КИИ). Служба каталога, менеджер конфигураций, корпоративный центр сертификации — всё это годами держалось на решениях одного вендора. Но все знают, что за последние 5 лет всё кардинально поменялось, и нужны решения, способные реально заменить существующий 30 лет стек.

На Хабре уже выходили материалы про аналоги Active Directory. Настал черед поговорить про коробочные решения, уже заменяющие стек Windows + AD + SCCM + CA. Речь идёт об Astra Server Core, совместной платформе «Группы Астра» и компании «Аладдин». Решение представляет собой Astra Linux Server с корпоративным центром сертификации Aladdin Enterprise CA (eCA), службой каталога ALD Pro и менеджером конфигураций ACM.

Я поговорил об этом стеке с директором серверного ПО «Группы Астра» Алексеем Фоменко и генеральным директором компании «Аладдин» Сергеем Груздевым. Мы обсудили, из чего состоит платформа, как организована миграция с Windows-инфраструктуры без остановки сервисов, какие специалисты нужны для внедрения и как обстоит дело с совместимостью с другими российскими ОС.

Приятного чтения!

Привет, Хабр! С вами эксперты ИнфоТеКС. В современной ИТ-индустрии контейнеризация стала неотъемлемой частью разработки и эксплуатации систем. Docker, как один из ключевых инструментов, прочно вошёл в повседневную практику. Однако с ростом сложности проектов, особенно в микросервисной архитектуре, возникает проблема, которая может существенно замедлить процесс разработки — скорость сборки Docker-образов.

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

В какой‑то момент у меня накопилось несколько VPS у разных провайдеров. Не десятки, но уже достаточно, чтобы каждый месяц ловить себя на одной и той же мысли: «А этот сервер когда оплачивать?»

Ссылка на биллинг — где‑то в закладках. Дата продления — в Telegram. Пароль от кабинета — в другом месте. Таблицы, заметки, все разбросано. Пока серверов немного, это ещё работает. Когда их перевалило за 15, начинаешь постоянно все терять. Кто хостер, а что там крутится, вкладки, вкладки, вкладки!

Так появилась идея: сделать личный кабинет для своих серверов.

Недавно на вебинаре Хайстекс разбирались реальные сценарии DR на практике. В чате трансляции зрители задали ряд технических вопросов, наиболее интересные из них легли в основу этого разбора.

Привет, Хабр. Я Михаил Фучко, технический продакт-менеджер SDN и Terraform в команде zVirt. Я продолжаю серию статей о пути, который мы проделали в процессе разработки собственного провайдера инфраструктуры для Terraform. В предыдущей части мы честно попробовали воспользоваться опенсорс-провайдером Terraform для oVirt и получили неоднозначные результаты (на самом деле вполне однозначные).  

Эта статья посвящена анализу провала проекта terraform-provider-ovirt. Посмотрим на принятые решения, поищем первопричину, оценим, как надо и как не надо делать, и выработаем основные концептуальные решения перед реализацией своего провайдера. 

Эта статья может быть полезна всем, кому предстоит написание своего Terraform-провайдера. Работа с унаследованным API, попытки натянуть одну модель управления ресурсами на абсолютно другую и необходимость предусматривать гораздо больше, чем изначально вложено в систему — все это погубило terraform-provider-ovirt и всего этого следует опасаться любому разработчику подобного решения. 

Практически все современные системы управления инфраструктурой опираются на один и тот же фундаментальный механизм — сохранённое состояние (persistent state).

Terraform хранит состояние в .tfstate, Crossplane использует Kubernetes API как систему записи, GitOps-решения строят дополнительные слои поверх Kubernetes. Архитектурные различия между этими инструментами огромны, но их объединяет одна идея: между конфигурацией и реальной инфраструктурой существует некоторое долговременное представление мира, которое считается авторитетным.

Исторически это было вполне разумно. Когда Terraform появился, облачные API были значительно медленнее, инфраструктура хуже наблюдалась, а полный обход ресурсов занимал ощутимое время. Поддерживать локальный снимок состояния было выгоднее, чем каждый раз заново опрашивать провайдера.

Проблема в том, что со временем этот снимок превратился из оптимизации в архитектурный фундамент. Вокруг него со временем выросла целая экосистема: удалённые хранилища состояния, механизмы блокировки, импорт ресурсов, синхронизация состояния с инфраструктурой, обнаружение дрейфа конфигурации, миграции состояния и другие инструменты, необходимые для поддержания согласованности между сохранённым представлением системы и её фактическим состоянием.

В какой-то момент возникает вопрос: а обязателен ли вообще persistent state как архитектурный элемент? Можно ли построить систему, которая будет работать напрямую с реальной инфраструктурой, не поддерживая отдельный долговременный слой состояния?

Штатная ситуация оказалась задачей со звёздочкой: кластер кинул алерт о том, что заканчивается сеть подов, но ни одно решение «из методички» не подходило, а вытаскивать кластер из прода было нельзя.

В статье расскажу, как мы не просто расширили подсеть подов, но сделали это на работающем кластере и не потеряли при этом данные. Что важно — трюк сработает на любом дистрибутиве Kubernetes и CNI.

Взяли один агент, один навык и одну выгрузку правил Ideco NGFW – и прогнали её через GigaChat Max и Claude Opus 4.8. Рассказываем, что из этого получилось, почему «настоящего» агентского теста не вышло и сколько всё это стоило в токенах и рублях.

Зачем мы это затеяли

В прошлой статье – «Пещера Аладдина для безопасника» – мы показывали, как автономный агент Hermes с открытой библиотекой Agent Skills разбирает IPS-логи и проводит аудит правил межсетевого экрана Ideco NGFW. Тогда мы сравнивали бесплатную фронтир-модель и платную Claude Opus и сделали осторожный вывод: для первичного triage хватает дешёвой модели, а для глубокого расследования лучше брать сильную.

Тот эксперимент оставил открытым один очевидный вопрос. Все «сильные» модели в нём были западными. А что покажет российская LLM на той же задаче?

Вопрос не праздный. Если вы – банк, госкомпания или объект КИИ, отправлять выгрузку правил вашего боевого файрвола в облако Anthropic – это в лучшем случае разговор с юристами, в худшем – прямое нарушение. GigaChat от Сбера работает в российском контуре, и если он справляется с аудитом конфигураций на приемлемом уровне, это меняет картину для целого класса заказчиков.

Поэтому мы взяли один и тот же агент (Hermes), один и тот же навык аудита и одинаковые входные данные – и подставили под него две модели: GigaChat Max и Claude Opus 4.8 (задумку с тестированием Claude Fable 5 для этой же задачи реализовать не удалось, со всеми нашими ИБ-скиллами он работать отказался, даже когда был доступен).

Привет! Я — Саша Басун, инженер направления пользовательских ИТ-сервисов в «Петрович-Тех». Сегодня я пришёл к вам с историей о том, как вывод значения ключа из реестра Windows может упростить обработку заявок в отделе технической поддержки.

Если коротко: помощь со стороны нашей техподдержки нередко начиналась с мема «Давайте поможем Даше найти Internet-ID на рабочем столе». Тут нет-нет, да все стадии от гнева до принятия пройти придётся. В итоге после заявки, которая пришла уже мне, родилось маленькое, но изящное решение на C#. 

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

На первый-третий расчитайсь! Сервер – рас. Администратор – два. URL – три!

Открыли HTTPS 443 – значит, можно запускаться.

На практике с решениями, которые работают с Linux-каталогом, такой подход всё одно, что бить палкой крапиву. Веб-интерфейс – это только точка управления. Само решение не живёт в вакууме: ему нужно обращаться к контроллерам домена, LDAP-каталогу, Kerberos/KDC, DNS, NTP. И это не пожелания, а обязательная сетевая связность, без которой сервис просто не работает – даже если страница в браузере открывается.

Именно поэтому при согласовании с ИБ важно приносить не просьбу «дайте доступ к серверу, сколько не жалко», а схему сетевых взаимодействий.

История реальная

Проект – Linux-каталог на 600 пользователей. Крайний срок – конец квартала. Мы сделали всё: Linux-каталог развёрнут, тестирование прошло, дата запуска согласована, рубашки заправлены.

За день до старта звонит ИБ: «А где схема сетевых взаимодействий?». Схемы нет. Я думал: ну HTTPS же открыли – чего ещё надо?

Как оказалось – надо всё остальное. И вот почему.

Формально доступ к веб-морде есть. Админ может зайти, логин-пароль ввести. Но само решение не может выполнить ни одной задачи. В каталог ему не пролезть. LDAPS не согласован. Kerberos – только в наших мечтах. DNS – «ну он же работает», но в заявке нет...

Я сижу и тупо смотрю на экран. Консоль открыта. Пользователей добавить нельзя.

Если у вас в начале июня внезапно завис git clone, а pip install начал валиться на каждом втором пакете — выдохните, дело не в вас и не в карме. С мая 2026 доступ к ключевым инструментам разработчика из России потихоньку деградирует. 8 июня Роскомнадзор предложил отрасли решение, и отрасль встретила его, мягко говоря, без оваций. Давайте по порядку: что сломалось, почему достаётся именно репозиториям, что это за «ГосVPN» такой, почему инженеры от него отмахиваются и что можно сделать прямо сейчас — без шаманства, обычной инженерной гигиеной.

Сразу одна важная вещь. Дальше я честно помечаю, где у меня твёрдый пруф, а где — реконструкция по одному источнику или просто разумное предположение. РКН официально отрицает блокировки PyPI и GitHub, часть атрибуций («это ТСПУ») технически правдоподобна по характеру сбоев, но ведомством не подтверждена. Так что местами я буду оговариваться — это не занудство, это честность.

Полгода назад я написал здесь разбор «почему VLESS работает» — он собрал 169 тысяч просмотров и под тысячу закладок. Я тогда уверенно заявил: REALITY не отличить от обычного HTTPS, поэтому он держится там, где всё остальное давно отвалилось. Прошло полгода — и оказалось, что я был прав ровно наполовину.

В феврале ТСПУ перешёл на поведенческий анализ, а в июне — на то, что в чатах называют «заморозкой по fingerprint». И тут разом перестали подключаться мои собственные конфиги — и конфиги тысяч других людей. Приложение бодро рапортует «connected», а трафика нет. А привычный совет «обнови клиент» вдруг превратился в пустой звук.

Вот я и вернулся — посмотреть, что осталось от моих же выводов. Это разбор со стороны клиентского устройства — угла, который обычно недозанят. Что на самом деле творится в телефоне, когда «всё зелёное, а интернета нет». Как устроена новая детекция. И как измерить её самому, чтобы не потерять доступ к легальным сервисам, которые попали под ложные срабатывания.

Пара слов о том, чему верить. Тема скользкая, источников мало, и я не хочу делать вид, что у меня на руках спецификация системы. Поэтому дальше честно помечаю, где у меня твёрдый пруф, а где — реконструкция по одному источнику. Самое важное сразу: ядро всей новой схемы (разделы 2–4) собрано по одному структурированному первоисточнику — посту в Obsidian/Zapret, где автор разбирает поведение через инструмент dpi-ch. Это не выписка из документа РКН и не консенсус исследователей ТСПУ. Академические работы (ensafi/IMC 2022, gfw.report) такой схемы вообще не описывают — как и кодового имени, под которым она ходит в обсуждениях. Так что всё про конкретные пороги — «>3 хендшейка», «350–400 мс», «120/600 с» — это инженерная реконструкция чёрного ящика по одному наблюдению, а не доказанное устройство системы. Числа читайте как рабочие гипотезы.

Если у вас российский номер, my.telegram.org с VPN выдаёт ERROR при создании приложения, а без VPN вообще не открывается. Антифрод сверяет страну номера и страну IP - и они не сходятся. Разбираю, почему обход через VPN - тупик, при чём тут DNS, и как получить api_id и api_hash одной строкой в файле hosts за 5 минут, без покупки номеров телефона других стран.

Я около десяти лет занимаюсь русской локализацией Mozilla и сейчас являюсь лидером русской локализации. За это время я много раз видел Firefox с пользовательской стороны, со стороны сообщества, со стороны перевода интерфейса и документации. Но в корпоративной среде браузер выглядит иначе. Там это не просто приложение для просмотра сайтов, а часть рабочего места, через которую проходят почта, внутренние системы, облачные службы, порталы, административные панели и множество других критичных процессов.

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

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

Так появился Browser Policy Manager — свободный продукт под лицензией MPL-2.0 для управления корпоративными политиками Firefox.

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

Это особенно проявилось на фоне «бума» российского VDI в 2022 году. VDI отлично справляется с офисными приложениями, неплохо живёт с web‑сценариями и требует особого подхода к CAD‑ и мультимедийным нагрузкам. Но самый парадоксальный эффект проявляется в организации видеоконференцсвязи (ВКС).

Разберёмся, почему видеосвязь требует особых подходов к оптимизации, без которых цифровое рабочее место остаётся только наполовину виртуальным, какие есть российские ВКС и что делать их поставщикам, чтобы не ломался UX.

С момента выхода PiKVM в 2017 году рынок IP KVM стал активно развиваться. Я протестировал почти все из этих устройств и готов дать объективную оценку каждому.

Для удалённого управления компьютером из любой точки LAN вы можете использовать инструменты вроде Remote Desktop, Screen Sharing или VNC. И если у вас нет собственной VPN, то полноценный удалённый доступ вам помогут обеспечить RealVNC или Raspberry Pi Connect, либо можете сами настроить сеть через Tailscale или Pangolin. Всё это прекрасные решения, как и SSH, если вам не требуется графический интерфейс.

Но бывают ситуации, когда вы не хотите запускать на ПК программу для удалённого управления. К примеру, когда я удалённо выполняю бенчмарки, мне не нужно, чтобы функция совместного использования экрана отнимала ресурсы системы. Или представьте, что у вас есть компьютер, к которому вам необходимо иметь возможность удалённо подключиться в любой ситуации. В таком сценарии, если этот ПК вдруг зависнет или по какой-то причине отключится, SSH и Screen Sharing уже не помогут.

И здесь на сцену выходит технология IP KVM. В передовые серверные решения она встраивается по умолчанию (к примеру, в HP iLO, Dell iDRAC или IPMI), но не у всех есть доступ к серверным материнским платам. И даже если он есть, BMC (Baseboard Management Controller) может оказаться сильно устаревшим, или же вы можете решить подключиться с использованием установленного GPU, а не встроенной VGA-графики.

Несколько лет назад я перестал доверять чужим VPN. Не из паранойи, а по скучной причине: бесплатный сервис живёт на твоих данных, платный - на твоём доверии, и оба разом отваливаются, когда их блокируют. А блокируют сейчас волнами, под выходные особенно.

Свой сервер звучит как “ну, надо быть админом”. Не надо. У меня на одном таком сидят жена и пара друзей, подняли за вечер пару лет назад, и с тех пор я к нему почти не прикасаюсь. Ниже - как поднять свой VPN на дешёвом VPS, и про грабли, которые обычно обходят молчанием.

В рамках проекта etcd-operator сообщество развивает оператор для развёртывания и сопровождения кластеров etcd в Kubernetes. На днях он был передан проекту Cozystack (CNCF Sandbox). Перед этим команда опубликовала написанную с нуля реализацию оператора с новой версией API — etcd-operator.cozystack.io/v1alpha2. Эта версия пришла на смену etcd.aenix.io/v1alpha1. Вместо управления узлами через StatefulSet новый оператор напрямую задействует штатный Membership API etcd (операции MemberAdd, MemberPromote и MemberRemove), что позволяет ему полностью контролировать состав кластера. Автор новой реализации — Тимофей Ларкин, один из мейнтейнеров прежнего оператора (старый код остался в ветке v1alpha1). Проект написан на Go и распространяется под лицензией Apache 2.0.

WireGuard довольно быстро стал популярным VPN-протоколом: простой, быстрый, с аккуратной архитектурой и без тяжёлого наследия, он выгодно выделялся на фоне монстров вроде IPsec и OpenVPN. Но, как это часто бывает, сильная сторона со временем стала и слабым местом. Протокол оказался не только удобным и предсказуемым, но и легко узнаваемым, а значит и сравнительно простым для блокировки.

Как только WireGuard начали пытаться блокировать, появились и первые попытки его спрятать. Сначала это были довольно простые приёмы, например, добавить перед хендшейком несколько мусорных UDP-пакетов, чтобы сбить DPI в начале сессии. Потом появилась AmneziaWG, которая пошла дальше и стала менять уже сам внешний вид WireGuard-пакетов: заголовки, размеры, дополнительные junk-данные внутри хендшейка. В AmneziaWG 2.0 пространства для манёвра стало ещё больше: к уже существовавшим S1–S2 добавились S3–S4, и управляемые вставки стало возможно применять не только к хендшейку, но и к другим типам сообщений, включая основной поток данных. Параллельно развивалась и идея имитационных пакетов: перед хендшейком можно было отправлять не просто случайный мусор, а пакеты, похожие на трафик другого протокола, чтобы сбить первичную классификацию.

В этой статье речь пойдёт о следующем шаге в развитии этой идеи. Если раньше имитационные пакеты работали в основном как короткая дымовая завеса перед хендшейком, то теперь имитация переносится в сам поток: транспортные пакеты AmneziaWG на проводе начинают выглядеть как QUIC, DNS, STUN или SIP.