300 рабочих станций на RedOS 7.3: Ansible + kickstart под дедлайн импортозамещения

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

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

Почему RedOS, а не Astra

Клиент рассматривал оба варианта. В итоге остановились на RedOS 7.3 для основной массы рабочих станций по двум причинам: внутренняя ИТ-команда лучше знакома с Red Hat-подобными системами, и уже была написана часть Ansible-ролей под RedHat-family ещё для серверов. Astra Linux SE зарезервировали под подразделения с повышенными требованиями по безопасности - там нужен мандатный контроль доступа, и это оправданный выбор именно Астры.

Автоматизация: kickstart + Ansible

300 машин руками не ставишь. Схема стандартная, но с нюансами под конкретную инфраструктуру клиента.

Kickstart взяли за основу сетевой установки. RedOS 7.3 поддерживает anaconda-kickstart, синтаксис близкий к RHEL/CentOS - это плюс, потому что у клиента были заготовки ещё со времён CentOS 7. Адаптировать проще, чем писать с нуля.

Основные блоки в kickstart-файле:

• разметка диска (LVM, отдельный /home)
• список базовых пакетов
• пост-скрипт, который ставит SSH-ключ и прописывает машину в inventory Ansible
• настройка первичного пользователя и доменной авторизации

После первого старта машина сама попадает в очередь Ansible AWX и получает конфигурацию в соответствии со своей группой: бухгалтерия, кадры, IT и т.д. Роли написали под ansible_os_family == "RedHat" - RedOS 7.3 в это семейство попадает корректно с ansible-core 2.14, о чём мы писали в марте.

Что сломалось - по приоритету боли

Список проблем оказался предсказуемым, но объём работы по каждому пункту - нет.

Принтеры. Это отдельная категория страданий. У клиента парк из нескольких моделей - часть с поддержкой CUPS через PPD, часть через проприетарные драйверы, которые выпускались только под Windows и RHEL 7. Для двух моделей официальных драйверов под RedOS 7.3 просто не существует. Решение нашли через универсальные PostScript-драйверы и настройку через IPP Everywhere там, где принтер поддерживает этот протокол. Две модели пришлось заменить - это было болезненное решение, но альтернатива - ставить wine или строить виртуальную машину ради принтера - хуже.

Браузеры. Chromium из репозитория RedOS работает, но версия на момент развёртывания заметно отставала от актуальной. Yandex Browser - корпоративная версия - ставился без проблем и был нужен клиенту для доступа к нескольким внешним порталам, которые ещё не перешли на нейтральный стек. Проблема оказалась не в браузере, а в корпоративных веб-приложениях клиента, написанных в своё время под IE с ActiveX. Для них оказалось нужно настраивать Chromium в режиме IE-эмуляции через User-Agent и специфичные флаги. Несколько внутренних систем так и остались доступны только через RDP на терминальный сервер Windows - это зафиксировали как технический долг.

1С. Клиент работает на 1С:Предприятие 8.3, и это заняло больше всего времени. Тонкий клиент под Linux существует, но путь от «скачал» до «работает с нашей конфигурацией» оказался нетривиальным. Проблемы: зависимость от конкретных версий библиотек (libicu, libssl), которые в RedOS 7.3 не совпадают по версии с тем, что ожидает инсталлятор 1С, и поведение печати из 1С через CUPS - формирование PDF-задания работало не на всех принтерах одинаково.

Решение для 1С выглядело так:

# Зависимости для 1С тонкого клиента на RedOS 7.3
dnf install -y libicu libssl1.1 libc++ unixODBC \
  fonts-ttf-liberation fonts-ttf-dejavu
# libssl1.1 нет в основном репозитории - брали из compat-пакетов

Плюс настройка шрифтов: 1С ожидает Microsoft Core Fonts или их замену, иначе интерфейс рендерится криво. Поставили пакет с метриками шрифтов (msttcore-fonts или аналог из репозитория) - стало нормально.

Ansible роли: что переиспользовалось, что пришлось писать

Серверные роли под RedHat-family подошли частично. Всё, что касается системных параметров, sysctl, сетевых настроек - переиспользовали без изменений. Для десктопа пришлось добавить:

• роль установки и настройки принтеров (CUPS + PPD-файлы через template)
• роль настройки 1С тонкого клиента с зависимостями
• роль настройки GNOME (dconf через ansible) - корпоративные обои, отключение ряда апплетов, блокировка экрана
• роль подключения к домену (FreeIPA у клиента)

Итого около 8 новых ролей, которые легли в корпоративный репозиторий клиента.

Где стоим

Из 300 машин на момент написания переведено около 230. Остаток - подразделения с наиболее специфичным ПО: есть несколько рабочих мест с промышленным CAD, где ситуация с Linux-версиями ещё хуже чем с принтерами. По ним переговоры с вендорами продолжаются, пока стоят на Windows с обещанием перейти «до конца года».

Главный вывод, который пока можно сделать: автоматизация через kickstart + Ansible работает и позволяет держать темп. Без неё 300 машин за такой срок были бы нереальны. Но автоматизация не решает проблему экосистемы - принтерные драйверы, корпоративные веб-приложения и промышленный CAD это ручная работа, переговоры с вендорами и местами замена железа.