Переезд с Ubuntu на Astra Linux: что реально ломается в первый день

MAATRIX https://maatrix.io/blog/pereezd-s-ubuntu-na-astra-linux-chto-lomaetsya/

Если вы десять лет ставили apt install на Ubuntu и Debian на автопилоте, первая же Astra Linux на новом сервере встретит вас парой сюрпризов: не тот пакет в репозитории, не та версия в выводе apt policy, сервис, который стартует не в том порядке, что вы привыкли видеть. Ничего катастрофического, но час-два на «а почему это не работает как обычно» вы потратите — если не готовы заранее. Ниже — список того, что реально ломается в первый день миграции, без домыслов и без пугания.

Зачем вообще Astra Linux, если это тот же Debian

Astra Linux — российский дистрибутив, построенный на пакетной базе Debian, с собственной системой сборки, репозиториями и набором доработок в области разграничения доступа и сертификации. Для системного администратора это означает две вещи одновременно: с одной стороны, большая часть привычных знаний о Debian-подобных системах переносится без потерь — тот же dpkg, тот же apt, та же файловая иерархия, тот же systemd в качестве системы инициализации. С другой — это не Ubuntu с перекрашенным логотипом, а отдельно сопровождаемый дистрибутив со своим циклом обновлений и своими решениями там, где апстрим Debian оставляет выбор открытым.

Причина, по которой Astra Linux вообще оказывается в списке задач в 2026 году, обычно одна и та же: требования к использованию отечественного ПО в госсекторе, у подрядчиков госзаказчиков и в ряде регулируемых отраслей. Если вам нужно держать персональные данные на сервере в юрисдикции с соответствующими требованиями, стоит заодно свериться со статьёй о том, где законно держать сервер с персональными данными по 152-ФЗ — выбор дистрибутива и выбор локации сервера часто оказываются частью одного и того же решения.

Если у вас пока нет формального требования и вопрос звучит как «а зачем мне это вообще» — сначала прочитайте общее сравнение в статье Ubuntu или Debian: что выбрать для сервера: логика выбора между «привычным» и «специализированным» дистрибутивом там разобрана подробно, и часть аргументов применима и к выбору в пользу Astra.

Репозитории: другой источник пакетов и своя специфика доступа

Первое, что бросается в глаза сразу после установки — /etc/apt/sources.list указывает не на deb.debian.org и не на archive.ubuntu.com, а на репозитории Astra Linux. Это логично и ожидаемо, но приносит с собой несколько практических следствий:

• Не все привычные PPA и сторонние репозитории Ubuntu подключаются «в лоб». Некоторые внешние deb-репозитории рассчитаны на конкретные кодовые имена релизов Ubuntu/Debian (например, проверяют lsb_release -c перед выдачей пакетов) и могут не узнать кодовое имя Astra — придётся либо искать репозиторий, который отдаёт пакеты по факту совместимости, либо собирать нужный софт из исходников, либо использовать статические сборки (那 же Docker-образы, standalone-бинарники).
• Смешивание репозиториев Astra с ванильными Debian-репозиториями — плохая идея. Технически apt не запретит вам добавить deb.debian.org в sources.list, но дальше велика вероятность конфликтов версий базовых пакетов и поломки зависимостей, которые Astra тщательно собирает и тестирует как единый комплект. Если пакета нет в штатных репозиториях — ищите альтернативный источник (официальный сайт проекта, Docker, Snap/Flatpak, если они предусмотрены), а не «Debian же тот же самый».
• Проверьте, каким пользователем и с какими правами настроен доступ к репозиторию. В зависимости от редакции и конфигурации могут быть нюансы с сертификатами и HTTPS-доступом к внутренним или защищённым зеркалам — это стоит выяснить до того, как вы окажетесь на сервере без интернета в 2 часа ночи.

Практический вывод: перед тем как переносить список пакетов с продакшен-Ubuntu на Astra, выпишите его и проверьте каждый пункт на доступность в штатных репозиториях, а не полагайтесь на то, что «раз это Debian-based, значит всё встанет».

Версии пакетов: не удивляйтесь несовпадению с тем, к чему привыкли

Второй источник «что за ерунда» в первый день — версии пакетов в выводе apt policy <пакет> или dpkg -l отличаются от того, что вы видели на Ubuntu 24.04 или Debian 12 в тот же момент времени. Это нормально и заслуживает отдельного объяснения, а не паники:

• У Astra Linux собственный цикл сборки и тестирования пакетов, не синхронизированный один в один с релизными циклами Ubuntu или ванильного Debian. Пакет может быть новее, старше или патчен иначе — в зависимости от того, что нужно самой Astra для стабильности и совместимости в её экосистеме.
• Не полагайтесь на память о конкретных номерах версий из других дистрибутивов при написании скриптов, Ansible-плейбуков или Dockerfile — код, который проверяет версию пакета строкой (grep "1.2.3" в выводе dpkg -l), скорее всего сломается при переносе на Astra. Пишите проверки версий через сравнение диапазонов (dpkg --compare-versions), а не через точное совпадение строки.
• Если ваше приложение или библиотека жёстко требует конкретную минимальную версию системного пакета (характерный пример — версии OpenSSL, Python, ядра для специфичных модулей), проверяйте фактически установленную версию на целевом сервере до деплоя, а не полагайтесь на документацию проекта, которая тестировалась на Ubuntu.
• Обновления безопасности приходят через отдельный канал Astra, со своим расписанием — не ждите, что патч выйдет в тот же день, что и апстрим Debian security advisory. Держите это в голове при планировании окон обслуживания.

Практика, которая экономит нервы: на этапе подготовки соберите тестовый стенд на Astra Linux и прогоните на нём весь деплой-пайплайн приложения ещё до переноса продакшена. Дешевле поймать несовпадение версий на тестовом сервере, чем в момент боевого релиза.

systemd: тот же движок, но проверьте юниты и порядок загрузки

Astra Linux использует systemd как систему инициализации — в этом смысле весь ваш опыт работы с systemctl, journalctl, юнит-файлами .service/.timer/.socket переносится напрямую. Но пара мест, где стоит удвоить внимание в первый день:

• Набор предустановленных и включённых по умолчанию юнитов отличается от Ubuntu. Часть сервисов, которые вы привыкли видеть выключенными на «чистой» Ubuntu, могут быть включены на Astra (и наоборот) — это связано с тем, что дистрибутив собирается под конкретные сценарии использования и требования безопасности, а не универсально «под всё». Первым делом после установки выполните systemctl list-unit-files --state=enabled и сверьте список с тем, что вы ожидаете видеть — выключите лишнее, включите нужное явно, не полагайтесь на дефолты.
• Проверьте зависимости и порядок старта для собственных юнитов, которые вы переносите с Ubuntu-сервера. Если ваш сервис писался с расчётом на конкретный порядок загрузки сети, дисков или других сервисов (директивы After=, Requires=, Wants= в юнит-файле), явно перепроверьте эти зависимости на новом сервере — не факт, что цепочка загрузки идентична, особенно если в Astra иначе настроены сетевые юниты (см. следующий раздел).
• journalctl и логирование работают так же, как вы привыкли, но если в вашей инфраструктуре есть специфичные политики разграничения доступа к логам (актуально именно для Astra в контексте её ориентации на защищённые конфигурации), проверьте, что процесс, который должен читать журнал, действительно имеет к нему доступ — иначе полчаса потратите на отладку «сервис работает, а логов не видно», хотя дело в правах.

Если в целом хотите освежить в памяти, как именно systemd принимает решения при загрузке и что происходит с зависимостями юнитов, у нас есть отдельный разбор — как работает systemd при загрузке. Механика там общая для любого Debian-based дистрибутива с systemd, включая Astra.

Сеть: не полагайтесь на файлы и утилиты «по памяти»

Сетевая настройка — третье место, где привычные Ubuntu-рефлексы могут подвести. На современной Ubuntu вы, скорее всего, привыкли к Netplan поверх systemd-networkd или NetworkManager, с YAML-конфигами в /etc/netplan/. На Astra Linux сетевой стек может быть настроен иначе — конкретный инструмент (NetworkManager, systemd-networkd, классический /etc/network/interfaces через ifupdown, либо собственные утилиты дистрибутива) зависит от редакции и варианта установки, и это первое, что стоит выяснить, а не предполагать по аналогии.

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

• Выполните ip a и ip route — зафиксируйте текущее состояние до того, как начнёте что-то менять.
• Проверьте, какой именно механизм управляет интерфейсами: systemctl status NetworkManager, systemctl status systemd-networkd, наличие и содержимое /etc/network/interfaces — не угадывайте, а посмотрите, что реально запущено и что реально применяет конфигурацию.
• Если переносите конфиг с Ubuntu (Netplan YAML) — не копируйте файл один в один в надежде, что он «просто заработает». Проверьте, какой инструмент управления сетью используется на Astra, и переносите настройки (IP, маску, шлюз, DNS) через штатный для этой системы механизм.
• Отдельно проверьте настройки DNS-резолвинга (/etc/resolv.conf и то, кто им управляет — systemd-resolved или что-то другое) — рассинхрон между тем, что вы прописали, и тем, что реально применяется, частая причина «сеть вроде настроена, а резолвинг не работает».
• Если сервер стоит за файрволом или в защищённом контуре — уточните, не блокирует ли локальная политика безопасности (в том числе штатные механизмы разграничения доступа Astra) исходящие соединения, которые вы считаете само собой разумеющимися, ещё до того как начнёте разбираться, «почему не открывается порт».

Если у вас уже есть привычка настраивать firewall по шаблону из мира Ubuntu/Debian, посмотрите, применимы ли те же принципы — общая логика описана в статье про настройку файрвола на Debian 12 с нуля: конкретные утилиты на Astra могут отличаться, но модель мышления «что должно быть открыто и почему» та же самая.

Разграничение доступа: не отключайте то, чего не понимаете

Отдельно стоит сказать про то, чего в Ubuntu вы, скорее всего, вообще не касались: механизмы мандатного и ролевого разграничения доступа, которые в защищённых конфигурациях Astra Linux могут быть включены и активны из коробки или доступны к включению. Если вы сталкиваетесь с ошибками доступа, которые не объясняются обычными правами Unix (владелец/группа/права на файл), — не спешите гуглить «как отключить» первую попавшуюся подсистему безопасности. Это тот случай, когда быстрое решение «выключить и не думать» создаёт больше проблем, чем решает: вы теряете именно то свойство системы, ради которого её и разворачивали.

Разумный порядок действий:

1. Зафиксируйте точный текст ошибки и контекст (какой процесс, какой файл, какое действие).
2. Проверьте документацию к конкретной установленной редакции и версии — общие рекомендации «для Linux вообще» здесь не подходят, специфика у каждой сборки своя.
3. Если решение действительно требует смягчения политики — делайте это точечно, для конкретного случая, а не глобальным отключением подсистемы.

Это тот же принцип, что и с SELinux в мире RHEL/AlmaLinux: выключить — не значит починить, это значит спрятать проблему и потерять контроль над тем, что реально происходит в системе.

Практический чеклист первого дня на новом сервере Astra Linux

Соберём всё в порядок действий, который стоит пройти при разворачивании нового сервера, прежде чем на него едет продакшен:

1. Зафиксировать версию и редакцию дистрибутива:
   cat /etc/os-release

2. Проверить состояние sources.list и доступность репозиториев:
   cat /etc/apt/sources.list
   apt update
   apt policy <ключевые-пакеты-приложения>

3. Обновить систему и зафиксировать список установленных пакетов:
   apt upgrade
   dpkg -l > /root/packages-baseline.txt

4. Проверить, что реально запущено и включено в systemd:
   systemctl list-unit-files --state=enabled
   systemctl list-units --failed

5. Разобраться с сетевым стеком до внесения изменений:
   ip a
   ip route
   systemctl status NetworkManager systemd-networkd 2>/dev/null
   cat /etc/resolv.conf

6. Проверить SSH-доступ и перейти на ключи вместо пароля:
   (см. отдельный чеклист по SSH-ключам ниже)

7. Прогнать деплой-пайплайн приложения на тестовом экземпляре
   прежде чем переносить продакшен-трафик.

8. Задокументировать все отклонения от привычного Ubuntu/Debian-
   поведения, которые вы нашли — следующему администратору
   это сэкономит тот же час, что потратили вы.

Если этот сервер — первый в компании и вы вообще заново проходите базовую настройку с нуля (не только применительно к Astra), общая логика первичной защиты сервера, включая переход на SSH-ключи, разобрана в статье Debian 12: первичная настройка и безопасность с нуля — большая часть шагов переносится на Astra напрямую, конкретные утилиты местами будут отличаться, но порядок действий тот же.

Частые вопросы