SystemD глазами мейнтейнера musl-дистрибутива [перевод]

Вместо предисловия

Этот пост я решил написать после выхода статьи о systemd, нашпигованной конспирологией, в стиле Кима ДотКома.

Я работал с systemd (именно написание юнитов) только пару-тройку раз и не писал юниты под другие системы (хотя иногда работал с openrc в Alpine, но это была лишь пост-установка определенных компонентов), что не позволяет мне называть себя профессионалом. Но, так как я горячо поддерживаю любые альтернативные мейнстримные разработки, такие как musl, busybox/toybox, то приведу мнение разработчика Adelie Linux (musl-based) относительно systemd.

Далее следует мой перевод статьи из персонального блога. Большинство идиом я заменил введением в контекст, постарался описать о какой технологии идёт речь и т.д.

---

systemd, как менеджер сервисов, на самом деле не является плохим программным обеспечением сам по себе. То, что он может выступать и как менеджер сервисов, и как замена inetd, — это действительно здорово. Формат файлов юнитов очень приятный и выразительный. Определение механизма и оставление политики на усмотрение администратора - это хороший дизайн.

Но мы говорим не только о том, как он помогает сисадминам в автоматизации работы. Мне не нравится поощрение привязки демонов к libsystemd для лучшей интеграции - все полезные интеграции могут быть сделаны с помощью более переносимых мер. И мне очень не нравится, что они считают glibc "Linux API", когда существуют [другие Си-стандартные библиотеки для Linux, такие как) musl, bionic и другие

Я хотел бы подробно рассказать о хороших и плохих сторонах systemd, как я вижу их глазами конечного пользователя, администратора и разработчика.

Управление службами: Хорошо

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

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

Самое приятное в ней то, что эта конфигурация точно описывает, как должна выглядеть и существовать система во время ее работы. Это похоже на то, как работают стандарты сетевых устройств - см. NETCONF и его детище RESTCONF. Вы определяете, как должно выглядеть устройство во время работы, применяете конфигурацию, и в итоге устройство становится соответствующим этой конфигурации.

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

Кроме того, использование cgroups для каждого управляемого блока означает, что отслеживание процессов всегда доступно, без необходимости создавать беспорядочные pid-файлы или требовать, чтобы демоны никогда не ветвились. Это еще одна очень полезная функция, которая не только помогает контролировать систему в целом, но и способствует отладке и даже аудиту безопасности. Когда cgroups используется таким образом, вы всегда знаете, какое подразделение породило тот или иной процесс в полностью управляемой системе.

Отсутствие конкуренции: Не очень

Нет никаких причин, по которым не мог бы существовать другой менеджер служб со всеми этими возможностями. На самом деле, я надеюсь, что у systemd появится конкуренция, которую сообщество будет воспринимать всерьез. Наличие одного пакета, в котором есть все для всех случаев использования, приводит к значительным проблемам. Изменения в systemd обязательно затронут каждого отдельного пользователя - это может показаться очевидным, но это означает, что системе сложнее развиваться. Эволюция системы может привести, а в некоторых случаях уже привела, к поломке большого числа сценариев использования и машин.

Кроме того, в отсутствие конкуренции нет внешнего давления, подталкивающего ее к идеям и концепциям, в которых, возможно, не уверены сопровождающие. GCC и Clang учатся на успехах и неудачах друг друга и используют эти знания, чтобы сделать друг друга лучше. Сейчас ни один пакет не делает этого с systemd. Инновации подавляются там, где отсутствует выбор.

Неправильное название glibc как "Linux API": Плохо

Я также недоволен отсутствием в SystemD поддержки musl libc. Возможно, для меня это спасение, потому что это отличное оправдание не пытаться поставлять ее в Adélie. В то время как я только что потратил пять абзацев на то, как отлично systemd справляется с управлением сервисами, она действительно плоха во многих других вещах. Именно здесь большинство статей уходят в глубокий отрыв, но я хочу дать конструктивную критику по некоторым проблемам, с которыми я лично столкнулся и которые ощутил при использовании машин на базе systemd.

Логгер: Очень плохо

journald - моя наименее любимая функция systemd. Хотя я понимаю причины, по которым он был разработан таким образом, мне не нравится, что он является единственным способом входа в систему systemd. Конечно, можно сделать вернуться к syslog, установить журнал только в памяти с небольшим размером и притвориться, что journald не существует. Однако это не только избыточное использование процессорной мощности и памяти с отрицательной выгодой, но и дополнительная поверхность для атак. Было бы здорово, если бы существовала "заглушка" journald, которая была бы только форвардером и не содержала никакого другого кода.

Я также недоволен тем, как журнал пытается "съесть" файлы ядра. В то время как стандартная настройка Linux "поместить файл с именем 'core' в $CWD" абсолютно непригодна для разработки и производства, несуразный гибрид файловой системы и бинарного журнала делает вещи неоправданно сложными. В документации даже явно указывается, что файлы ядра могут существовать без соответствующих записей в журнале, а записи в журнале могут указывать на файлы ядра, которые больше не существуют. Тем не менее, они используют xattrs, чтобы поместить "некоторые метаданные" в файлы ядра. Почему бы просто не иметь дополнительный файл (возможно, [имя файла ядра].info или .json или .whatever), который содержит всю информацию из журнала, и иметь единственную запись в журнале, которая указывает на этот файл, если администратор заинтересован в дополнительной информации о сбое?

Systemd-resolved: Решение, ищущее проблему

Сама по себе resolved [модуль systemd, отвечающий за разрешение имён, по умолчанию настроен на сервера google, при существовании более быстрого cloudflare, что вызвало ожесточенную полемику среди англоязычных пользователей, любящих поколупаться в конфигурационных файлах] может быть неплохой идеей, но уже есть другие пакеты, которые могут обеспечить локальный кэширующий резолвер без множества проблем, присущих resolved. Более того, сама идея того, что DNS-резольвер является частью "системного слоя", кажется мне неразумной.

Поддержка DNSSEC [модуль безопасности доменного имени] является экспериментальной и не совсем корректной, и они с готовностью это признают. Хорошо знать свои ограничения, но DNSSEC - это то, что невероятно ценно иметь на конечных точках. Я не думаю, что без него resolved можно воспринимать всерьез. Я не понимаю, как никто не внес эту функцию в такой широко используемый пакет.

Есть странные проблемы с поиском в локальном домене. Это усложняется в домашних сетях, где многое из того, что он делает, излишне. В корпоративных сетях он, скорее всего, все равно не подойдет, что заставляет меня задаться вопросом, почему он поддерживает все, что делает.

И наконец, на мой взгляд, resolved пытается впихнуть слишком много странных функций и протоколов, не сделав сначала основ. О mDNS лучше позаботиться с помощью специализированного пакета, например Avahi. Поддержка LLMNR [устаревший протокол разрешения имён] была отменена ее создателем Microsoft в пользу mDNS уже более года назад. Поскольку LLMNR всегда представлял собой угрозу безопасности [https://www.blackhillsinfosec.com/how-to-disable-llmnr-why-you-want-to/], я не понимаю, зачем его поддержка вообще была добавлена.

nspawn: Нишевый инструмент для нишевых целей

Любое обсуждение, включающее resolved, было бы упущением без упоминания главной причины его существования, а именно nspawn. Это интересный подход к тому, чтобы быть "между" chroot и полноценным контейнером, таким как Docker. У него есть нишевое применение, и у меня нет никаких реальных претензий к нему, но я никогда не находил его полезным в своей работе, поэтому у меня нет большого опыта работы с ним. Обычно, когда я берусь за chroot, мне нужно общее состояние между хостом и контейнером, так что nspawn здесь не имеет смысла. А когда я берусь за Podman, мне нужна полная изоляция, которую мне удобнее передать пакету, имеющему больше инструментов.

Вспомогательные инструменты: Почему именно на системном уровне?

networkd незрел, не имеет большой поддержки для продвинутых случаев использования и не имеет графического интерфейса для конечных пользователей. Я не знаю, почему они хотят запихнуть сетевые технологии в "системный слой", когда существует NetworkManager, который держит всю сетевую муть вне системного слоя.

timedated кажется милым способом позволить пользователям менять часовые пояса через действие PolicyKit, но в остальном кажется, что лучше бы об этом позаботился "настоящий" NTP-клиент, например Chrony или NTP. И опять же, я не знаю, почему это должно жить в системном слое.

systemd-boot поддерживает только EFI, что делает его непортативнным и негибким. Вы не найдете EFI на Power или Z, и у меня есть много плат ARM, которые не поддерживают основной U-Boot. Это не проблема systemd-boot, так как совершенно понятно желание иметь дело только с идиосинкразией одной платформы. Что беспокоит, так это тот факт, что такие дистрибутивы, как Fedora, отказываются от GRUB в пользу этой системы, а это значит, что они теряют еще больше переносимости.

В заключение:

В этой статье я хочу прояснить следующее:

• Я не питаю ненависти к systemd на основе предпочтений [Unix-way — не Unix-way], и на самом деле я восхищаюсь многими ее качествами как реального менеджера сервисов. Что мне не нравится, так это ее попытка взять на себя то, что они называют «системным слоем», когда альтернатив не существует.
• Проблемы, которые я испытываю с systemd, ощутимы, а не просто разводят руками: «Unix — хорошо, sysd — плохо».
• Если бы была предпринята попытка отделить systemd от всех остальных щупалец, которыми она обросла, я бы искренне настаивал на том, чтобы она была доступна в качестве менеджера сервисов в Adélie. Я чувствую, что в качестве менеджера сервисов — и только в качестве менеджера сервисов — он обеспечит фантастический пользовательский опыт, с которым не смогут сравниться другие существующие решения.