Антипаттерн: на сервере тот же дистрибутив, что на десктопе

MAATRIX

Арендовали сервер, открыли установщик — и по привычке выбрали тот же образ, что стоит на рабочем ноутбуке: знакомый интерфейс, знакомые команды, ничего искать не надо. Через пару месяцев на сервере обнаруживается графическая оболочка, которую никто не открывал, десяток фоновых служб, о существовании которых никто не подозревал, и процесс, слушающий порт непонятно зачем. Разберём, почему «тот же дистрибутив, что и дома» — это не нейтральный выбор, а решение, которое тихо создаёт проблемы, и как выбрать образ, который на сервере действительно нужен.

Откуда берётся привычка

Сценарий почти всегда одинаковый. У разработчика на ноутбуке стоит десктопная сборка Linux — с ней он работает годами, знает, где что лежит, какие команды набирать не глядя. Когда доходит до аренды VPS или выделенного сервера, установщик предлагает список образов, и рука тянется к тому же пункту, что и на личной машине: «ну это же тот дистрибутив, я его знаю». Иногда выбор даже не осознанный — панель провайдера по умолчанию предлагает первый в списке образ, а это может быть полновесная десктопная сборка, а не серверная.

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

Отдельно стоит случай, когда десктопный образ выбирают из соображений «мне так привычнее администрировать» — то есть сознательно ставят GUI поверх сервера, чтобы работать с ним локально в X-сессии. Это не совсем тот антипаттерн, о котором статья: если графическая среда — осознанное рабочее решение под конкретную задачу (например, сервер для рендеринга или для удалённого рабочего стола), то это отдельный выбор, который стоит делать с открытыми глазами и специально настраивать, а не тянуть по инерции.

Что реально устанавливается вместе с "тем же дистрибутивом"

Десктопный образ — это не просто ядро и набор утилит. Вместе с ним на сервер обычно приезжает:

• X-сервер или Wayland-композитор и полноценное окружение рабочего стола (менеджер окон, панель, файловый менеджер);
• менеджер входа в сессию (display manager), который держит открытым порт для локального логина;
• звуковой стек (pulseaudio/pipewire) — на сервере без звуковой карты он просто занимает память и автозапускается при каждой загрузке;
• служба печати (cups) — слушает локальный порт, даже если принтера в природе не существует;
• Bluetooth-демон, служба автомонтирования сменных носителей, индексация файлов для поиска (tracker, baloo и аналоги) — постоянно сканирует диск в фоне;
• mDNS/Avahi для обнаружения устройств в локальной сети — на сервере анонсирует его существование всем, кто слушает multicast;
• сетевой менеджер с графическим апплетом, магазины пакетов (snap/flatpak с GUI-фронтендами), набор офисных и медиаприложений «на всякий случай».

Проверить, что реально стоит, легко:

# сколько пакетов установлено вообще
dpkg -l | wc -l

# явные признаки десктопного окружения
dpkg -l | grep -iE 'xserver|gnome|kde|plasma|xfce|lxde|pulseaudio|cups|bluez'

# сколько служб включено автозапуском
systemctl list-unit-files --state=enabled | wc -l

# что реально слушает порты прямо сейчас
ss -tulpn

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

Каждая лишняя служба — это не абстрактная «грязь», а конкретный риск и конкретный расход: у неё есть свой код, свои уязвимости, свой цикл обновлений, который тоже нужно отслеживать. Демон печати или Bluetooth-стек, который никогда не используется, всё равно требует патчей безопасности — просто потому что он запущен и что-то слушает. Это прямое увеличение поверхности атаки без какой-либо пользы для задачи сервера.

Разная философия серверных и десктопных сборок

Десктопная сборка и серверный образ решают принципиально разные задачи, даже если формально называются одним именем дистрибутива.

Десктоп проектируется для человека, который сидит перед экраном прямо сейчас: автоматическое определение случайно воткнутого оборудования, мастера настройки принтера и сканера, спящий режим при простое, блокировка экрана, геолокация для автонастройки часового пояса, магазин приложений на первом экране. Всё это правильные решения — для ноутбука. На headless-сервере, который управляется только по SSH, часть этих функций просто бесполезна, а часть — откровенно мешает: спящий режим на выделенном железе может усыпить машину, которую потом придётся будить руками у стойки; сервис геолокации — это лишний сетевой запрос наружу, который непонятно зачем происходит с боевого сервера.

Серверные редакции того же дистрибутива, наоборот, собираются исходя из другой предпосылки: за консолью никого нет, работа идёт через сеть, а главные приоритеты — предсказуемость и стабильность. Отсюда более консервативный набор пакетов «из коробки», без экспериментальных десктопных фич, и часто более длинный цикл поддержки конкретной ветки — обновления безопасности приходят регулярно, но версии основных компонентов не скачут вслед за десктопными релизами с новым UI. Это осознанный компромисс: сервер должен работать одинаково предсказуемо и через год, и через три, а не получать сюрпризы вместе с очередным «косметическим» обновлением рабочего стола.

Отдельно эта тема — про железо, а не про образ ОС — разобрана в статье про миф "серверный процессор всегда лучше десктопного": там показано, что ярлык «серверный» сам по себе ничего не гарантирует и важно смотреть, под какую задачу конкретно оптимизирована сборка — будь то процессор или дистрибутив.

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

Даже если удалить явно десктопные пакеты, часть проблем остаётся на уровне настроек по умолчанию, унаследованных от десктопного профиля установки:

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

Отдельно про автообновления безопасности и типичные ошибки при их настройке на сервере есть разбор в статье про автообновления безопасности на сервере — там же видно, чем headless-подход отличается от десктопного «нажми ОК, когда попросит».

Как выбрать правильный образ для сервера

Правильный выбор — не «дистрибутив другой марки», а другой профиль установки внутри того же семейства. На практике это выглядит так:

1. При установке с ISO — выбирайте минимальный/серверный профиль установщика, а не «рабочая станция» или «desktop». В интерактивном установщике это отдельный пункт выбора задач — снимите галочку с desktop environment, оставьте только базовую систему и нужные роли (веб-сервер, база данных, контейнеры — что реально требуется).
2. При использовании готового образа провайдера — берите образ, помеченный именно как серверный/cloud/minimal, а не общий ISO для настольных машин. Такие образы обычно уже подготовлены для headless-загрузки и работы с cloud-init, без графической подсистемы вообще.
3. При сборке через debootstrap/аналогичные инструменты начальной загрузки — вы контролируете набор пакетов с нуля и десктопные метапакеты туда просто не попадают, если их не добавлять явно.

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

# графических пакетов быть не должно
dpkg -l | grep -iE 'xserver|gnome|kde|plasma' || echo "чисто"

# цель загрузки должна быть многопользовательской, не графической
systemctl get-default
# ожидаем: multi-user.target

# список реально запущенных служб — должен быть коротким и понятным
systemctl list-units --type=service --state=running

Если systemctl get-default показывает graphical.target на сервере, который никто не открывает локально — это тот самый признак, что образ выбирали по привычке, а не по задаче. Общий чек-лист базовой настройки нового сервера — с фаерволом, SSH и правами доступа — собран отдельно в статье чек-лист безопасности нового сервера, она хорошо дополняет выбор правильного образа как следующий шаг после установки.

Если десктопный образ уже стоит на проде

Если сервер уже работает и на нём обнаружился десктопный набор пакетов, разбирать это стоит аккуратно и не в спешке.

Сначала — инвентаризация, без резких движений:

dpkg -l | grep -iE 'gnome|kde|xfce|lxde|plasma|cups|bluez|pulseaudio' > /tmp/desktop-packages.txt
systemctl list-unit-files --state=enabled

Дальше — отключение, а не сразу удаление: systemctl disable --now cups avahi-daemon bluetooth и аналогичные для того, что реально не нужно. После отключения понаблюдайте какое-то время, что рабочая нагрузка не пострадала — часть служб может неожиданно оказаться зависимостью для чего-то важного.

Только после этого — удаление метапакетов desktop environment и последующий apt autoremove --purge (или аналог для вашего пакетного менеджера), чтобы подчистить хвосты зависимостей. Обязательно проверьте df -h / до и после — освобождённое место обычно измеряется гигабайтами.

Важная оговорка: полная ручная чистка десктопного окружения на живом сервере редко проходит идеально. Графы зависимостей у метапакетов рабочего стола запутанные, и что-нибудь да останется — осиротевший конфиг, забытый systemd-таймер, часть библиотек, которые формально ничем не используются, но и не были помечены как «можно удалить». Если сервер критичный и данные можно перенести без простоя, честнее и быстрее в перспективе — поднять новый сервер с нормального минимального образа и мигрировать сервис туда, чем бесконечно вычищать наследие десктопной установки. Перед любыми массовыми удалениями на проде сделайте снапшот или бэкап — если что-то пойдёт не так, откат должен занимать минуты, а не часы разбора зависимостей.

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