Импортозамещение на практике: пилот Astra Linux SE у госзаказчика

Минкомсвязи не первый раз расширяет список обязательного программного обеспечения из реестра отечественного ПО - это уже ставшая ритмичной практика. Но каждый такой шаг означает, что у госорганов становится меньше степеней свободы в выборе и больше давления на ИТ-команды: надо мигрировать, причём реально, а не на бумаге. На этом фоне один из наших госзаказчиков попросил помочь с пилотом - посмотреть, как Astra Linux Special Edition ведёт себя на реальных рабочих местах, с реальным прикладным ПО и реальной инфраструктурой.

Спойлер: с 1С и GroupWise всё оказалось терпимо. С Active Directory - нет.

Зачем пилот

Заказчик работает в структуре, которую требования реестра касаются напрямую. Офисные машины на Windows 7/10, на большинстве из них - толстый клиент 1С, корпоративная почта через Novell GroupWise, всё это в домене Active Directory. Типичная история для государственной организации, которая строила инфраструктуру в нулевых и с тех пор в ней живёт.

Задача пилота была простая: взять два десятка рабочих мест, поставить Astra Linux SE, подключить к домену, поднять 1С и GroupWise - и посмотреть, что получится. Не имитация, а рабочая обстановка: сотрудники должны были реально работать на этих машинах в течение двух недель.

1С и GroupWise: совместимость приемлемая

Начнём с хорошего. 1С: Предприятие 8.3 на Linux работает. Компания «1С» официально поддерживает Linux-клиент, и в нашем случае тонкий клиент через веб-браузер поднялся без особых трудностей - сервер 1С остался на Windows, что и планировалось. Пользователи, которые работают в типовых конфигурациях (бухгалтерия, зарплата), на практически не заметили разницы. Более экзотические доработки, которые используют COM-объекты и прямые вызовы Windows API, - это отдельная история, которую мы выносим за скобки пилота.

GroupWise тоже поднялся. Novell/Micro Focus поставляет Linux-клиент, который в нашем случае установился штатно и подключился к почтовому серверу. Базовый набор функций - почта, календарь, задачи - работал нормально. Некоторые плагины и интеграции с офисным ПО, привязанные к Windows, отвалились, но для большинства пользователей это некритично.

Офисный пакет - LibreOffice в составе дистрибутива. Здесь ожидаемая история: с doc/docx/xlsx-файлами, которые не используют специфические макросы, всё нормально. Там, где много автоматизации на VBA, придётся либо переписывать, либо оставлять отдельные машины под Windows.

Active Directory: неделя нервов

Вот тут началось. Astra Linux SE включает собственный стек аутентификации - ALD (Astra Linux Directory), который по умолчанию предлагается вместо AD. Но у заказчика уже есть продуктивный домен Windows Server, выносить его никто не планирует, и задача была именно присоединить Astra-машины к существующему AD.

Технически это реализуется через Winbind (часть пакета Samba) или через SSSD с backend-ом на AD. Оба пути рабочие, но дьявол в деталях:

• Kerberos и DNS. Astra Linux требует аккуратной настройки /etc/krb5.conf и корректного разрешения SRV-записей. Если DNS в домене не идеальный - а в унаследованных инфраструктурах он никогда не идеальный - начинаются странные сбои аутентификации, которые воспроизводятся не всегда.
• Уровень функциональности домена. Домен заказчика жил с Windows Server 2008 R2 в режиме совместимости с более старыми клиентами. Некоторые сочетания настроек SSSD с таким доменом давали нестабильное поведение при обновлении тикетов Kerberos.
• Права и групповые политики. Групповые политики Windows на Linux-машины не распространяются - это ожидаемо. Но заказчик привык управлять настройками рабочих мест именно через GPO, и перенос этой логики на ansible-роли и ald-pro потребовал отдельного проектирования.
• Смена пароля и синхронизация. Пользователи меняют пароль через стандартный интерфейс AD - это работало. Но была ловушка: после смены пароля kerberos-тикет обновлялся не сразу, и несколько пользователей словили временную блокировку. Лечится настройкой параметров SSSD, но нужно знать куда смотреть.

Итого неделя ушла на стабилизацию связки AD + SSSD в условиях конкретного домена заказчика. Не катастрофа, но и не «поставил и работает».

Что не попало в пилот

Две вещи мы сознательно оставили за рамками. Первое - VPN-клиенты с сертифицированными СКЗИ (КриптоПро и аналоги): у заказчика их используют не все рабочие места, и это отдельный пласт работ. Второе - специализированное отраслевое ПО, часть которого существует только в виде Windows-приложения. По этим позициям вопрос открытый.

Где мы сейчас

Пилот завершён, результаты переданы заказчику. Вывод, который мы сформулировали: для рабочих мест с типовым набором задач - почта, офисные документы, веб-интерфейсы, 1С - переход реален без экзотических костылей. Всерьёз болезненных мест два: нестандартная AD-инфраструктура и Windows-специфичные приложения.

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

Технические подробности по интеграции Astra Linux в существующую инфраструктуру - готовы обсуждать.