Портирование под Astra Linux: чек-лист для разработчика

Чтобы продукт заработал на Astra Linux, недостаточно запустить его на каком-нибудь Linux. Нужно пройти десять стадий: описать зависимости, собрать на целевой ОС, упаковать в пакет, запустить службой от непривилегированного пользователя, проверить права и защитные механизмы редакции, привести в порядок пути, локали и время, проверить графику и сеть, добавить автотесты с конвейером и написать документацию. Сводная таблица — в конце статьи.

Чек-лист написан для Astra Linux и применим к РЕД ОС с поправками на формат пакета и защитные механизмы. Он не заменяет документацию вашей редакции ОС: там, где поведение зависит от редакции, версии и настроек политики, так и написано. Сертификация и подача в реестр в чек-лист не входят.

Стадия 1. Инвентаризация: языки, зависимости, нативные библиотеки, лицензии

До первой сборки нужен список всего, из чего состоит продукт и что он вызывает во время работы. Без него портирование превращается в запуск наугад.

• языки и версии рантаймов, системные библиотеки и версии компиляторов;
• прямые и транзитивные зависимости с версиями: dotnet list package --include-transitive, mvn dependency:tree, pip freeze, npm ls;
• нативные библиотеки: что было .dll, что станет .so, есть ли исходники или версия под Linux; зависимости бинарников смотрят через readelf -d, а ldd запускают только в изолированной среде;
• внешние программы, которые продукт запускает: офисные пакеты, COM-объекты, утилиты командной строки;
• обращения к Windows: реестр, службы, WMI, Win32, пути вида C:\;
• лицензии зависимостей: допускают ли их условия поставку в составе вашего продукта.

Признак готовности: у каждой зависимости записаны версия, источник (репозиторий ОС, сторонний репозиторий, собственная сборка) и лицензия.

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

Собрать продукт на целевой ОС нужно до того, как что-то переписывать: часть проблем окажется мнимой, часть неожиданной. Для сборки подойдёт виртуальная машина с чистой системой нужной версии.

• Старая версия как база. Бинарник, собранный на новой версии системных библиотек, на старой может не запуститься: ему не хватит нужных версий символов glibc. Собирайте на самой старой из целевых версий, а требуемые версии смотрите через objdump -T по бинарнику.
• Версии инструментов закреплены. Компилятор, SDK, сборщик, версии пакетов: в файле блокировки или в образе сборочной среды.
• Сборка из внутреннего зеркала. В закрытом контуре внешние репозитории недоступны: все зависимости сборки должны браться из вашего зеркала, а не с внешних серверов.
• Зависимости сборки и запуска разделены. То, что нужно только на сборке, не должно попасть в требования пакета.
• Архитектура. Если нужна не только x86-64 (например, ARM), это отдельная сборка и отдельный набор тестов.

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

Стадия 3. Пакеты .deb для Astra Linux и .rpm для РЕД ОС: что должно быть внутри

Форматы пакетов разные, но требования к содержимому общие: файлы лежат в предсказуемых каталогах, зависимости объявлены, настройки не затираются при обновлении, службу можно включить и выключить.

• продукт ставится в /opt или /usr, настройки в /etc, данные в /var/lib, журналы в /var/log; ничего не пишется в каталог установки;
• системный пользователь создаётся в скрипте установки, а не требует ручной подготовки;
• пакет подписывается по правилам вашей редакции и репозитория;
• обновление поверх предыдущей версии и удаление проверены отдельно.

Признак готовности: пакет ставится на чистую машину, обновляется поверх предыдущего, удаляется без остатков вне каталогов данных; lintian и rpmlint не дают ошибок, а предупреждения разобраны.

Стадия 4. Установка и запуск от непривилегированного пользователя: systemd, каталоги, журналы

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

1. Создать системного пользователя без оболочки и без домашнего каталога.
2. Оформить юнит systemd: User=, ExecStart=, Restart=on-failure. Каталоги состояния и журнала можно поручить systemd через StateDirectory= и LogsDirectory=.
3. Для порта ниже 1024 выбрать порт выше либо выдать службе только нужную возможность (AmbientCapabilities=CAP_NET_BIND_SERVICE), а не root.
4. Журнал писать в стандартный вывод, чтобы он попадал в журнал systemd, или в файл с ротацией.
5. Не рассчитывать на домашний каталог службы и на запись в каталог установки; временные файлы — в выделенный каталог, а не куда придётся.
6. Проверить юнит командой systemd-analyze verify, затем перезагрузкой и принудительным завершением процесса.

Отдельная оговорка: на защищённых установках каталог /tmp может быть смонтирован с запретом исполнения. Продукт, который распаковывает во временный каталог исполняемые файлы и запускает их, там не заработает.

Признак готовности: после перезагрузки служба поднимается сама, после завершения процесса — перезапускается, процессов с правами root без необходимости нет.

Стадия 5. Права, мандатный доступ и замкнутая программная среда

В защищённой редакции (Astra Linux Special Edition) поверх обычных прав Unix могут действовать мандатное разграничение доступа с метками, контроль целостности и замкнутая программная среда, при которой запускаются только подписанные программы. Что именно включено, зависит от редакции, версии и настроек политики, поэтому формулировки ниже осторожные: сверяйте с документацией вашей редакции. На обычной сборке этих механизмов может не быть, а значит, проверка на ней ничего не доказывает.

• Паспорт продукта. Составьте перечень: что процесс читает, пишет и запускает, какие каталоги, сокеты и порты использует, какие дочерние процессы и скрипты вызывает.
• Подпись сборок. Все исполняемые файлы и библиотеки вашей сборки подлежат подписи по правилам редакции. Сюда входит и то, что продукт распаковывает или скачивает во время работы: такие файлы замкнутая среда может не пустить.
• Скрипты и подключаемые модули. Неподписанные скрипты и плагины могут не запускаться; проверьте, нет ли у продукта таких сценариев.
• Разные пользователи. Метки доступа влияют на то, какие файлы и каталоги видит процесс. Проверьте продукт под двумя пользователями с разными уровнями, а не только под тем, под которым вы разрабатывали.
• Диагностика. Отказы похожи на обычные ошибки доступа, причина — в журналах аудита и системных журналах. Включите их на стенде заранее.

Признак готовности: сценарии проходят на стенде нужной редакции с включёнными механизмами; паспорт продукта и порядок подписи записаны в документации. Подробнее о том, что ломается при переходе на Astra Linux, — в статье «Переход на Astra Linux: что ломается».

Стадия 6. Конфигурация, пути, кодировки, локали и время

Это самая «мелкая» стадия, и на ней же ломается больше всего неочевидного.

• Регистр и разделители. Файловая система учитывает регистр: Config.json и config.json — разные файлы. Пути собираются средствами языка, а не склейкой строк с обратной косой чертой.
• Где что лежит. Настройки в /etc/продукт, данные в /var/lib/продукт, кэш в /var/cache. Рабочий каталог службы не равен каталогу установки, относительные пути нужно проверить.
• Кодировки. В файлах от Windows встречаются cp1251, BOM и переводы строк CRLF. Определить кодировку помогает file -i, перекодировать — iconv. Скрипты с CRLF не запустятся из-за неверного интерпретатора, поэтому для них задают окончания LF в настройках репозитория.
• Локаль. Служба не наследует окружение пользователя. Задайте локаль в юните (Environment=LANG=ru_RU.UTF-8) и проверьте, что она есть на целевой ОС (locale -a). Форматы в файлах обмена задавайте явно, а не через локаль.
• Время. Храните и передавайте время в UTC, часовой пояс применяйте на границе. Версия базы часовых поясов на целевой ОС может отличаться, проверьте нужные регионы.

Признак готовности: продукт отрабатывает на пустом окружении службы и на нескольких локалях, файлы обмена читаются в UTF-8, внутреннее время в UTC.

Стадия 7. Графика, шрифты и печать

Если у продукта есть интерфейс или печатные формы, на каждой целевой ОС они выглядят чуть иначе, поэтому проверяются на каждой.

• Шрифты. Привычных Arial, Times New Roman и Calibri в системе нет, подставляется другой шрифт, и вёрстка форм может сдвинуться. Что подставляется, показывает fc-match Arial. Метрически совместимые шрифты есть (Liberation для Arial и Times New Roman, Carlito для Calibri), но шрифты Windows в пакет не кладите, не проверив лицензию. В PDF шрифты лучше встраивать.
• Библиотеки интерфейса. Версии Qt и GTK в репозиториях разных ОС отличаются. Проверьте масштабирование экрана, диалоги выбора файла, значок в трее, горячие клавиши.
• Печать. Принтеры работают через CUPS. Для сложных форм надёжнее формировать PDF и отдавать его на печать.
• Оборудование. Последовательные порты, сканеры, считыватели: проверяйте на целевой ОС по факту, права на устройства выдаются группами, а не как на Windows. Заявление «поддержка Linux» у производителя работу именно на вашей сборке не гарантирует.

Признак готовности: снимки экрана и печатные формы на целевых ОС сверены с эталоном в согласованных допусках, лицензии на шрифты в пакете понятны.

Стадия 8. Сеть и криптография

В закрытых контурах сеть и сертификаты ломают продукт чаще, чем код.

• Порты и интерфейсы. Посмотрите, что слушает продукт (ss -tlnp), на каком интерфейсе, и что происходит с именем localhost, которое может разрешаться в адрес IPv6. Таблицу портов включите в документацию.
• Межсетевой экран. Проверьте работу продукта при включённых правилах, а не на открытой машине.
• Прокси. Службы не наследуют переменные окружения пользователя, прокси нужно задать явно.
• Сертификаты. Внутренний удостоверяющий центр добавляется в системное хранилище разными командами (update-ca-certificates в Debian-подобных системах, update-ca-trust в системах на rpm). Java, Python и Node.js могут пользоваться собственным хранилищем, его проверяют отдельно.
• Криптография. Если продукт шифрует, подписывает или работает по TLS, ориентируйтесь на средства ОС и сертифицированные средства криптографической защиты. Требования зависят от вашего контура и определяются его владельцем. Собственных реализаций не пишите; привязку к криптопровайдеру Windows нужно заменить на то, что поддерживается на целевой ОС.

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

Стадия 9. Автотесты и CI на целевой ОС: несколько версий и редакций

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

1. Модульные тесты запускаются на целевой ОС, а не только на машине разработчика.
2. Интеграционный сценарий: установка пакета на чистую машину, запуск службы, проверка работоспособности, ключевая операция, обновление с предыдущей версии, удаление.
3. Негативные проверки: нет прав, нет места на диске, нет сети, служба упала.
4. Конвейер собирает пакеты, проверяет их lintian и rpmlint, ставит на чистую виртуальную машину и публикует во внутренний репозиторий.
5. Матрица поддержки записана: версии ОС, редакции, архитектуры, и каждая её строка проверяется конвейером.

Для нескольких версий ОС есть два пути. Первый: отдельная сборка под каждую версию, как правило на базе самой старой. Второй: поставка нужных библиотек вместе с продуктом, что проще в сборке, но обновления безопасности этих библиотек тогда на вашей стороне. Выбор зависит от требований контура.

Признак готовности: конвейер зелёный на каждой заявленной ОС, а повторение сценария установки не требует ручных шагов.

Стадия 10. Документация и сценарий установки

Документ, по которому продукт ставит человек, не участвовавший в разработке, — часть продукта. Минимальный состав:

• требования: версии ОС и редакции, ресурсы, нужные пакеты, порты;
• установка с нуля, настройка, проверка после установки;
• обновление и удаление, что сохраняется и что нужно сохранить вручную;
• резервное копирование и восстановление: какие каталоги и данные входят;
• каталоги, пользователи, группы, параметры конфигурации, место журналов;
• известные ограничения и перечень сторонних компонентов с лицензиями.

Признак готовности: человек, не писавший продукт, ставит его на чистую машину по документу с первого раза, а все команды из документа проверены копированием.

Сводный чек-лист по стадиям и что в него не входит

Что в чек-лист не входит

Сертификация и подача заявки в реестр отечественного ПО, заключение о совместимости от производителя ОС, аттестация и лицензируемые работы по защите информации. Портирование закрывает техническую часть, остальное — отдельные процедуры правообладателя, подробнее в статье о реестре отечественного ПО. Если вместе с продуктом уходит и серверная часть, смотрите переход с Windows Server на Linux, а если продукт работает с MS SQL, к нему добавится миграция базы на PostgreSQL. Интерфейс на WinForms и WPF придётся переписывать, это обычная разработка.

Что делаем мы и с чего начать

Мы проводим портирование по этим же стадиям на ваших стендах и в вашем репозитории, а сборочный конвейер остаётся у вас. Начинаем с обследования одного продукта: 200 000 ₽, 2–3 недели, вычитается из следующего этапа. На выходе — список зависимостей, пробная сборка на целевой ОС, отчёт о том, что переносится сразу и что придётся переписывать, и вилка бюджета. Состав работ и цены — на странице портирования под Astra Linux и РЕД ОС.