- В systemd 259 добавлена частичная поддержка musl, улучшена модульность libsystemd, а также внедрена модель привилегий, обеспечиваемая параметром run0 --empower.
- Требования к системе повышаются: ядро Linux 5.10, glibc 2.34, OpenSSL 3.0.0 и другие современные библиотеки становятся обязательным минимальным набором.
- Процесс вывода из эксплуатации устаревших систем ускоряется: прощай, скрипты SysV, прекращение поддержки TPM 1.2, отказ от iptables и полное внедрение nftables.
- Они улучшают наблюдаемость и безопасность благодаря постоянному ведению журнала по умолчанию, новым метрикам OOMKills и многочисленным настройкам в сети, контейнерах и homed.
Выпуск стабильной версии systemd 259 представляет собой очередной поворот в одном из самых спорных и важных компонентов экосистемы Linux. Речь идёт о фреймворке для инициализации и управления службами, который уже доминирует в большинстве дистрибутивов, и этот релиз ещё больше ужесточает требования к техническим характеристикам, безопасности и отказу от устаревших технологий.
Это обновление стало результатом нескольких месяцев интенсивной работы и сосредоточено на трех основных областях: совместимость с новыми библиотеками C, улучшенная безопасность и очистка устаревшего кода (скрипты SysV, TPM 1.2, iptables и т. д.). Оно также вносит существенные изменения в управление привилегиями с помощью run0, обработку памяти с помощью systemd-oomd, хранение логов и внутреннюю модель зависимостей libsystemd.
systemd 259 и экспериментальная поддержка musl
Одна из наиболее обсуждаемых особенностей этой версии заключается в том, что systemd 259 впервые включает частичную поддержку стандартной библиотеки C musl . Эта библиотека широко используется в легковесных системах, минималистичных контейнерах и встроенных средах, где желательны простота и снижение потребления ресурсов по сравнению с glibc.
Поддержка musl включается путем установки параметра "libc" системы сборки Meson в значение "musl" . Однако эта интеграция далека от завершения: musl не реализует механизм переключения служб имен (NSS), что приводит к отключению некоторых частей systemd при компиляции с использованием этой библиотеки.
В частности, сборка systemd 259 с использованием musl исключает ключевые компоненты, такие как nss-systemd, nss-resolve, systemd-homed, systemd-userdbd и systemd-nsresourced . Также недоступны опция DynamicUser и возможность запуска systemd-nspawn без привилегий, что особенно актуально в контейнерных средах, которые в значительной степени полагаются на эти возможности.
Сами разработчики признают, что не могут гарантировать долгосрочную поддержку . Её продолжение будет зависеть от реального интереса сообщества, зрелости дополнительных слоев, предоставляющих функции, которых не хватает musl, и сообщений об ошибках, специфичных для этой библиотеки. Если спрос будет низким или поддержка окажется слишком сложной, не удивительно, если её пересмотрят в будущих версиях.
Однако это открытие доступа к musl важно на символическом уровне: systemd годами подвергался критике за почти исключительную зависимость от glibc , что делало его недружелюбным к альтернативным дистрибутивам и очень минималистичным сценариям. Этот шаг не решает всех проблем, но он разрушает представление о системе, полностью закрытой для других библиотек C.
run0 и новая модель привилегий: альтернатива sudo
Еще одной важной особенностью systemd 259 является утилита run0, предложенный в качестве современной и более безопасной замены sudo.Этот инструмент уже был встроен в systemd-run, но теперь он получает ключевую возможность: опцию --empower.
Новый аргумент `--empower` позволяет начать сессию с повышенными привилегиями без изменения вашего UID на root . Вместо традиционного переключения пользователя, `run0` использует возможности ядра (такие как `CAP_SYS_ADMIN`) для предоставления именно тех разрешений, которые необходимы для выполнения привилегированных действий, снижая риск получения прав root.
Кроме того, процессы, запущенные с помощью этого подхода, группируются в логическую группу «расширения прав и возможностей» с доступом к широкому набору действий, управляемых Polkit . Идея заключается в том, что увеличение привилегий является детализированным и контролируемым, поддерживая более строгую разграниченность, чем та, которая обычно обеспечивается традиционным sudo, где доступ часто открывается слишком широко.
Этот подход соответствует тенденции избегать прямого использования пользователя root , что является высоко ценимым принципом безопасности. Однако истинную эффективность run0 еще предстоит продемонстрировать в производственной среде: нам придется посмотреть, как он интегрируется с политиками каждого дистрибутива, как его возможности настраиваются на практике и насколько хорошо системное администрирование адаптируется к новому рабочему процессу.
Прекращение поддержки SysV init и очистки устаревших файлов.
В systemd 259 также начинается окончательный конец для сервисных скриптов в стиле System V. Совместимость с этими классическими механизмами уже много лет считалась "уходящей в прошлое", и теперь установлен четкий график их удаления.
В этой версии сообщается, что, в преддверии следующего крупного релиза, Исторические компоненты, такие как systemd-sysv-generator, systemd-rc-local-generator и systemd-sysv-install, будут удалены.То есть, сценарии в /etc/init.d/ Они больше не будут учитываться systemd, что завершает переходный период, длившийся почти десять лет.
Для администраторов, которые по-прежнему используют пользовательские службы на основе скриптов SysV , это означает необходимость приступить к работе: все эти скрипты нужно инвентаризировать и перенести в собственные модули systemd (.service, .socket и т. д.). Крупные дистрибутивы уже практически полностью завершили этот переход, но в пользовательских средах или старых установках некоторые «реликвии» могут все еще работать в фоновом режиме.
Процесс очистки устаревших компонентов не ограничивается SysV. В последних версиях systemd уже удаляется поддержка классических методов, таких как `/forcefsck` и `/fastboot` , заменяя их параметрами ядра и более современными механизмами учетных данных. В версии 259 направление такое же: меньше обратной совместимости в обмен на более поддерживаемый и согласованный код.
Минимальные требования к systemd: 259: ядро, библиотеки и окружение.
Одно из изменений, которое может оказать наибольшее влияние на старые системы, — это повышение минимальных требований к программному обеспечению для запуска systemd 259. Эта версия больше не учитывает очень старое оборудование или стеки и явно ориентирована на современные платформы.
В число ключевых требований, закрепленных в systemd 259, входят: приверженность современным платформам.
- Минимальная версия ядра Linux: 5.10. (с рекомендацией дойти как минимум до 5.14).
- glibc 2.34 в виде минимальной версии стандартной библиотеки GNU.
- Откройте SSL 3.0.0 в качестве обязательного условия для поддержки функций шифрования.
- util-linux 2.37 в качестве требования для обеспечения работы основных функций системы.
- libxcrypt 4.4.0 для управления криптографическими функциями, связанными с паролями.
- cryptsetup 2.4.0 и libseccomp 2.4.0 для шифрования томов и фильтрации системных вызовов.
- Python 3.9.0 в качестве минимальной зависимости для вспомогательных инструментов.
- В некоторых примечаниях также упоминается эльфутилс 0.177 в рамках обновленного набора зависимостей.
Это ужесточение означает, что очень старые системы или дистрибутивы, использующие ветки ядра до версии 5.10, автоматически исключаются из поддержки этой версии, если они не обновят свои базовые технологии. Взамен достигается более однородная экосистема с меньшим количеством особых случаев и компромиссных решений.
Для большинства универсальных дистрибутивов для настольных компьютеров и серверов эти требования не должны представлять проблемы: современные ветки ядра LTS уже значительно превосходят версию 5.10 , а упомянутые библиотеки широко доступны. Наибольшие проблемы могут возникнуть во встроенных системах, устройствах или очень консервативных установках, которые не часто обновляются.
Повышенная безопасность: TPM 2.0, шифрование и ограничения для устройств.
В области безопасности systemd 259 ускоряет свой прогресс благодаря ряду важных решений. Наиболее заметным является то, что systemd-boot и systemd-stub окончательно отказываются от поддержки TPM 1.2 , так что отныне эталонным стандартом считается только TPM 2.0.
Это изменение означает, что системам, которые использовали TPM 1.2 для управления политиками безопасной загрузки или ключами шифрования, потребуется обновить оборудование (например, заменить материнскую плату), если они хотят продолжать использовать эти функции с более новыми версиями systemd-boot. Многие пользователи Linux на настольных компьютерах отключили TPM и безопасную загрузку, поэтому они могут даже не заметить это изменение, но оно может иметь значение в корпоративных или высокозащищенных средах.
В предыдущих версиях, таких как systemd 258, в этой области уже были внесены существенные изменения: OpenSSL стала единственной библиотекой шифрования, поддерживаемой systemd-resolved и systemd-importd , исключив альтернативы, такие как GnuTLS и libgcrypt. Все это указывает на консолидацию вокруг меньшего, более контролируемого набора криптографических инструментов.
Также в ветке 258 были введены более строгие ограничения доступа по умолчанию для tty/pts : узлы создаются с правами доступа 0600 вместо 0620, что предотвращает запись другими пользователями в наши терминалы. Это еще один пример того, как systemd уже некоторое время совершенствует низкоуровневые детали, которые в совокупности повышают общую безопасность системы.
libsystemd обладает большей модульностью и загружается динамически.
В стремлении к повышению эффективности и снижению нагрузки на зависимости, в версии systemd 259 внесены существенные изменения в то, как libsystemd взаимодействует с другими системными библиотеками . Цель состоит в том, чтобы предотвратить перенос всего содержимого с самого начала, загружая его только тогда, когда это необходимо.
В частности, libsystemd теперь использует dlopen() для динамической загрузки таких библиотек, как libacl, libblkid, libseccomp, libselinux и libmount . Это означает, что эти зависимости не связаны жестко во время компиляции и не всегда загружаются в память: они активируются только тогда, когда этого требует конкретная функция.
Тот же механизм, что и в случае с `dlopen()`, применяется также для интеграции с подсистемой аудита Linux и PAM . Таким образом, запуск systemd и его обычная работа могут быть более оптимизированы в средах, которые не требуют одновременного использования всех этих компонентов.
С другой стороны, функциональность, ранее предоставляемая библиотекой libcap, была напрямую интегрирована в libsystemd . Это устраняет еще одну внешнюю зависимость, упрощая цепочку сборки и уменьшая потенциальные точки отказа или несовместимости.
В целом, такой подход обеспечивает лучшую модульность и меньший объем памяти и дискового пространства , особенно в системах, где требуется быстрая загрузка и компактный набор служб.
Изменения в сети и контейнерах: прощай, iptables, здравствуй, nftables.
В области сетевых технологий и виртуализации также происходят значительные изменения. Начиная с systemd 259, systemd-networkd и systemd-nspawn больше не поддерживают создание правил NAT с использованием iptables/libiptc . Единственным поддерживаемым бэкэндом межсетевого экрана становится nftables.
Это напрямую затрагивает контейнеры, управляемые с помощью systemd-nspawn, которые использовали NAT через iptables , а также сети, определенные в systemd-networkd, которые использовали правила трансляции адресов с классическим бэкендом. В тестах с релиз-кандидатами наблюдались скрытые сбои в работе NAT до тех пор, пока вся конфигурация не была перенесена на nftables.
Помимо перевода адресов, systemd-resolved получает возможность использовать локальные хуки. en /run/systemd/resolve.hook/Эти команды выполняются каждый раз при выполнении запроса на разрешение локальных имен. Это открывает возможности для расширенной настройки DNS и реализации специфической логики администратором.
В области импорта и управления изображениями, systemd-importd включает в себя собственную логику для работы с TAR-файлами., используя библиотеку libarchive из утилиты GNU tar. Кроме того, systemd-importd и systemd-machined теперь могут запускаться в пользовательском режиме, управляя образами системы, размещенными в ~/.local/state/machines/.
Для управления этими режимами утилита importctl добавляет параметры "--user" и "--system" , позволяющие легко выбрать, работать ли в контексте пользователя или на системном уровне. Такой подход полезен для сред разработки и тестирования, где не требуется изменять глобальную конфигурацию машины.
Постоянное ведение журнала по умолчанию и управление дисковым пространством.
Еще одно изменение, имеющее практическое значение, — это модификация режим хранения журнала по умолчанию, подсистема логирования systemd. До сих пор «автоматическое» поведение зависело от наличия или отсутствия каталога. /var/log/journal.
В systemd версии 259 режим по умолчанию становится "постоянным ", независимо от того, существовала ли папка ранее. Это означает, что журнал будет по умолчанию постоянно сохраняться на диск, а не храниться в энергозависимой оперативной памяти.
У этого решения есть свои плюсы и минусы. С одной стороны, оно значительно упрощает поиск и устранение неисправностей , поскольку журналы сохраняются после перезагрузки без необходимости каких-либо специальных действий со стороны администратора. С другой стороны, во встроенных системах, легковесных контейнерах или средах с очень ограниченным объемом памяти это может привести к значительному увеличению использования дискового пространства.
В таких сценариях корректировка правил ротации и размера журнала , или даже принудительный выбор другого режима хранения данных , станет важнее, чем когда-либо, если вы хотите избежать чрезмерного износа (например, во флэш-памяти с ограниченным количеством циклов записи).
systemd-oomd, отслеживание ошибок нехватки памяти и управление ресурсами.
Значительные улучшения коснулись также управления памятью и сценариев «недостаточно памяти». Компонент systemd-oomd, отвечающий за реагирование на ситуации нехватки памяти , включает в себя новые свойства для обеспечения большей наглядности.
В частности, для служб теперь доступны свойства OOMKills и ManagedOOMKills , которые регистрируют количество процессов, завершенных ядром или самой системой systemd-oomd из-за недостатка памяти. К этой информации можно получить прямой доступ с помощью инструментов systemd, что упрощает последующий анализ инцидентов.
Когда процесс выходит из-под контроля и начинает «пожирать» оперативную память до такой степени, что это ставит под угрозу систему , эти метрики позволяют с первого взгляда увидеть, какие блоки затронуты, сколько раз срабатывал механизм ошибки нехватки памяти (OOM) и какие компоненты создают наибольшую нагрузку на память.
Для администраторов сред с высокой нагрузкой или систем с очень ограниченными ресурсами эта расширенная возможность отслеживания ошибок нехватки памяти особенно полезна, поскольку помогает выявлять службы с неоптимальным размером или утечки памяти, которые ранее могли остаться незамеченными.
Другие заметные улучшения в systemd 259
В дополнение к упомянутым выше основным изменениям, systemd 259 содержит множество улучшений и мелких доработок, разбросанных по всей экосистеме . Многие из них довольно технические, но стоит их рассмотреть, поскольку в совокупности они приводят к существенным изменениям.
Среди новых функций API, Интерфейс на основе протокола Varlink расширяется. для предоставления доступа к конфигурации сервиса и выполнения вызовов межпроцессного взаимодействия, таких как Reload() y Reexecute()Также добавлены специальные вызовы для обработки функций systemd-repart, systemd-resolved и systemd-networkd.
В области конфигурации и модулей была введена опция ExecReloadPost , которая позволяет запускать команды сразу после перезагрузки конфигурации службы. Кроме того, файлы конфигурации, заканчивающиеся на ".ignore", теперь автоматически удаляются — это простой способ отключить файлы без необходимости их удаления или радикального переименования.
Временные подразделения получают право собственности. RootDirectoryFileDescriptor, который определяет дескриптор файла, соответствующий корневому каталогу, и добавлена новая опция. Путь к пространству имен пользователя, что позволяет связать диск с пространством имен пользователя, указав путь в /procВ systemd-nspawn эта директива появляется. NamespacePath в разделе из файлов .nspawn для указания используемого сетевого пространства имен.
Другие компоненты, такие как systemd-sysext и systemd-confext содержат специальные конфигурационные файлы. en /etc/systemd/systemd-sysext.conf y /etc/systemd/systemd-confext.confпеременные окружающей среды SYSTEMD_SYSEXT_OVERLAYFS_MOUNT_OPTIONS y SYSTEMD_CONFEXT_OVERLAYFS_MOUNT_OPTIONS Они позволяют регулировать варианты крепления накладок.
В мире udev эта опция добавлена. OPTIONS=»dump-json» to systemd-udevd Для отображения текущего состояния события в формате JSON используется функция. net_id Она генерирует предсказуемые имена для беспроводных интерфейсов в системах с DeviceTree и создает символические ссылки. /dev/gpio/by-id/... для устройств GPIO.
Раздел, посвященный пользователям и учетным записям, также укрепляется: База данных пользователей содержит поле UUID.Утилита userdbctl поддерживает опцию "-uuid" для поиска по этому идентификатору, homectl update Теперь поддерживается параметр "--recovery-key" для добавления ключей восстановления к существующим учетным записям.
В systemd-homed параметры "--prompt-shell" и "--prompt-groups" включаются при первой загрузке с помощью systemd-homed-firstboot.service, а в systemd-firstboot параметр "--prompt-keymap-auto", по-видимому, запрашивает раскладку клавиатуры при использовании локальной консоли при первой загрузке.
El Менеджер загрузки systemd-boot добавляет возможность определять уровень детализации журнала. с параметром log-level en loader.conf или с помощью поля SMBIOS io.systemd.boot.loglevelКроме того, ужесточаются требования к таким разделам, как XBOOTLDR, которые теперь должны быть в файловой системе VFAT, в соответствии с требованиями, уже предъявляемыми к ESP в современных системах UEFI.
На уровне продвинутых сетевых функций systemd-networkd добавляет параметры EmitDomain и Domain для DHCP-сервера и реализует контроллер, определяющий имена хостов, выдаваемые через DHCP, с использованием разрешения DNS. В то же время systemd-modules-load загружает модули ядра параллельно , сокращая время загрузки на системах с большим количеством драйверов.
Наконец, в разделе обеспечения целостности systemd-integrity-setup добавляет поддержку алгоритмов HMAC-SHA256, PHMAC-SHA256 и PHMAC-SHA512 , расширяя спектр криптографических возможностей, доступных для защиты целостности системы.
Благодаря всем этим изменениям systemd 259 укрепляет свои позиции как высокотехнологичная, требовательная и явно ориентированная на будущее версия . Она подталкивает пользователей к отказу от устаревших технологий, таких как SysV init, iptables и TPM 1.2, усиливает безопасность и контроль ресурсов, улучшает внутреннюю модульность и открывает двери для новых конфигураций с помощью musl, хотя и частично и условно. Для конечных пользователей дистрибутивов с точечными релизами многие из этих новых функций останутся практически незамеченными; для администраторов и проектов, постоянно использующих последнюю версию, настало время тщательно проверить скрипты, модули и требования к оборудованию, прежде чем переходить на новую версию.
