LINUX.ORG.RU

Релиз systemd 230

 


4

8

Представлен выпуск системного менеджера systemd 230. Из новшеств можно отметить включение по умолчанию DNSSEС и режима чистки процессов пользователя после завершения сеанса, поддержку унифицированной иерархии cgroup, возможность настройки прокси ARP для сетевого интерфейса, новые типы юнитов generated и transient, новую команду systemctl revert и возможность создания виртуальных прямых сетевых ссылок между контейнерами.

Основные изменения:

  • В DNS-резолвере systemd-resolved по умолчанию включен DNSSEC. DNSSEC доступен в режиме allow-downgrade (автоматический откат на режим без DNSSEC) и может быть отключен через настройку DNSSEC в resolved.conf или на этапе сборки при указании опции configure --with-default-dnssec=no. Дистрибутивам пока не рекомендуется включать DNSSEC по умолчанию, пока не будут выявлены все возможные несовместимости режима DNSSEC с DNS-серверами.
  • В systemd-resolve добавлена возможность резолвинга DNS-записей DANE (DNS-based Authentication of Named Entities) при указании опции --tlsa и OPENPGPKEY при указании опции --openpgp, а также создания дампа raw-данных записей DNS при указании опции --raw=дамп.
  • В systemd-logind по умолчанию обеспечено принудительное завершение процессов, запущенных в составе пользовательского сеанса, после выхода пользователя из системы. Управлять принудительным завершением можно через опцию KillUserProcesses в logind.conf, которая теперь выставлена в значение yes по умолчанию, что требует отдельных настроек, если необходимо сохранить работу длительно выполняемых пользовательских процессов (для работы screen и tmux требуется специальная настройка сервисов, например, включение т.н. lingering через loginctl). Для восстановления старого поведения на этапе сборки можно указать опцию --without-kill-user-processes.
  • В systemd-logind добавлены новые настройки SessionsMax и InhibitorsMax, которые по умолчанию установлены в значение 8192.
  • В systemd-logind добавлена поддержка обновления конфигурации по сигналу SIGHUP.
  • Добавлена поддержка унифицированной иерархии cgroup (в ядре с 4.5), для задействования которой в systemd при загрузке требуется указать опцию командной строки ядра systemd.unified_cgroup_hierarchy=1. Для унифицированной иерархии также добавлен контроллер cgroup io, который дополнил контроллеры memory и pids.
  • Поддержка протокола LLDP (Link Layer Discovery Protocol) расширена возможностями использования пассивного (только приём) и активного (отправка) режимов. Пассивный режим включен по умолчанию в systemd-networkd, а активный режим включен по умолчанию в изолированных контейнерах с адресацией внутренней сети. Для просмотра статистики можно использовать команду networkctl lldp.
  • Добавлена возможность настройки уникальных идентификаторов IAID и DUID, отправляемых в запросах DHCP. Идентификаторы могут быть определены как для всей системы, так и для отдельных файлов .network при помощи опций DUIDType, DUIDRawData и IAID.
  • В systemd-networkd добавлена возможность настройки прокси ARP для отдельных сетевых интерфейсов, используя опцию ProxyArp в файлах .network. Кроме того, в файлы .netdev добавлены опции MulticastQuerier и MulticastSnooping, позволяющие включить режим отправки запросов и прослушивания IGMP-трафика.
  • В файлах .network представлена новая опция PreferredLifetime, позволяющая определить время жизни IP-адреса.
  • В DHCP-сервере, встроенном в systemd-networkd, активирована по умолчанию опция EmitRouter, включающая поле DHCP Option 3 (Router).
  • Тестовая утилита systemd-activate переименована в systemd-socket-activate и перемещена в /usr/bin.
  • В systemd-journald задействован отдельный поток для сброса прокэшированных данных на диск при закрытии файлов с журналом, что решило проблемы с задержками записи в лог на медленных дисках.
  • В journalctl добавлен новый метод вывода -o short-unix, при котором к записями в логе добавляется префикс с эпохальным (UNIX) временем (число секунд с 1970 года). Также добавлена опция --no-hostname для исключения столбца с именем хоста.
  • Устройства фреймбуфера, сканеры и 3D-принтеры теперь подключаются в режиме uaccess и доступны для вошедших в систему пользователей.
  • В опции DeviceAllow теперь можно указывать спецификаторы (начинаются с символа %).
  • В systemctl show добавлена опция --value, позволяющая вывести только содержимое заданного свойства юнита без указания его имени.
  • Для автоматически сгенерированных и созданных в процессе работы через обращения к API файлов добавлены новые типы юнитов generated и transient.
  • Добавлена новая команда systemctl revert для отката к предоставляемой поставщиком версии файла юнита в случае внесения в файл юнита локальных изменений.
  • В machinectl clean добавлена возможность автоматического удаления всех или только скрытых образов контейнеров.
  • В systemd-tmpfiles добавлен новый тип записи «e», позволяющий организовать очистку директорий, если они уже существуют.
  • В systemd-nspawn добавлена поддержка автоматического исправления UID/GID и ACL для всех файлов и директорий в контейнере для их соответствия диапазону UID/GID, выбранному при запуске контейнера.
  • В systemd-nspawn добавлена новая опция --network-zone для создания виртуальных прямых линков между контейнерами.
  • Для socket-юнитов добавлены опции TriggerLimitIntervalSec и TriggerLimitBurst для настройки лимитов на возможное число активаций в заданный промежуток времени.
  • Компонент systemd-bootchart вынесен в отдельный репозиторий.
  • Из состава удалён systemd-bus-proxyd, так как kdbus вряд ли будет принят в ядро в своём текущем виде.
  • Удалены библиотеки libsystemd-daemon.so, libsystemd-journal.so, libsystemd-id128.so и libsystemd-login.so, которые ранее были объявлены устаревшими.
  • Удалена опция Capabilities, вместо которой следует использовать AmbientCapabilities и CapabilityBoundingSet.

>>> Подробности

★★★★

Проверено: Falcon-peregrinus ()
Последнее исправление: Klymedy (всего исправлений: 5)
Ответ на: комментарий от Olegarch

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

Shadow ★★★★★
()
Ответ на: комментарий от Shadow

Активизация же запускает демона, удерживает соединение до запуска демона и передает его

Совет - посмотри, как работает xinetd. И найди только одно отличие от того, что ты написал. 8)

Olegarch
()
Ответ на: комментарий от Shadow

Активизация же запускает демона, удерживает соединение
до запуска демона и передает его.

Хм. А зачем ? Почему демон не должен быть запущен сразу, если в системе предусмотрена его работа ?

AS ★★★★★
()
Ответ на: комментарий от Olegarch

Совет - посмотри, как работает xinetd. И найди только
одно отличие от того, что ты написал. 8)

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

AS ★★★★★
()
Ответ на: комментарий от Shadow

новые логины - необходимость, старые были костылем

Брррр... /bin/login для любой шелл-консоли + unix-way-authentication для авторизации - это единственный возможный логин для юникс-системы. 8) Все остальное - костыли. Даже включение кофеварки при входе админа в комнату.

Olegarch
()
Ответ на: комментарий от AS

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

На это я могу тебе ответить, рискуя перебить твой троллинг (сорри, если что) - потому что некоторые демоны нужны «раз в пятилетку», когда кому-то приспичит в svn/git тыкнуться, на ftp что-нибудь выложить, rsync в DMZ локалке сделать - единичные задачи, для которых можно использовать и подход «триггерного запуска». Для всех остальных задач - да, демон приклеивается к порту перманентно, и больше никуда не девается. И бОльшая часть демонов написанных «до-systemd» умеет работать «и так и эдак». Как там у systemd с этим - не знаю, и знать не желаю.

Olegarch
()
Ответ на: комментарий от Olegarch

На это я могу тебе ответить, рискуя перебить твой троллинг

:-)

потому что некоторые демоны нужны «раз в пятилетку»

Ну так тогда зачем они висящие ? Потом надо положить тогда. А это уже inetd получается. :-)

AS ★★★★★
()
Ответ на: комментарий от AS

Потом надо положить тогда. А это уже inetd получается. :-)

Ну а я о чем тут распинался? :) Конечно надо потом погасить. А что, этот самый ыныеуьв не укладывает их потом баиньки?! Если нет - трындец...

Olegarch
()
Ответ на: комментарий от Olegarch

Как там у systemd с этим - не знаю, и знать не желаю.

не знаю, и знать не желаю.

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

zink ★★
()
Ответ на: комментарий от zink

Вот ты наконец-то и признался, что просто воинствующий мракобес

Он просто понимает, что в большом комбайне больше проблем, а тут монстр во главе системы. И не надо говорить, что сам systemd маленький (хотя и это не так). Проблема в том, что из тарбола собирается куча всего, и обновление одной части тащит за собой обновление всего остального разом, со всеми перезапусками, возможностями нарваться на новые ошибки и т.п.

AS ★★★★★
()
Ответ на: комментарий от AS

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

Так основной посыл ненависти к systemd это якобы повышение вероятности «нарваться на новые ошибки»? Как-то знаете ли неубедительно звучит. Переход на systemd состоялся и никаких серьёзных проблем не было.

Обобщая все прочитанное в комментариях к многим новостям о релизах systemd заметна тенденция к искусственному очернению и надумаванию предлогов почему systemd якобы плох.

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

anonymous
()
Ответ на: комментарий от anonymous

Так основной посыл ненависти к systemd это якобы повышение
вероятности «нарваться на новые ошибки»?

Дошло, что ли ? Только слово «якобы» тут лишнее.

Переход на systemd состоялся и никаких серьёзных проблем не было.

Были. На одну серьёзную я уже в начале этой темы указывал, со ссылкой на проблему на моём буке в январе. А были и ещё.

То же ядро можно новое поставить рядом со старым, сказать lilo -R new_label, после чего вернуться банальным reset (в Grub тоже что-то такое родили), а что сделать с комбайном, который уложит систему при обновлении ?

AS ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.