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)

Ответ на: комментарий от kir2yar

бы мне не приходилось костылить свою реализацию мультисита на баш-лапше.

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

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

Зачем тогда это в рамках одного цельного дерева исходников всё распространяется, а не раздельно ?

Эм, так делает ядро, астериск, апач и xorg, да фактически все суют основные плагины в основное дерево.

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

а для людей это инструмент управления системой и связи модулей.

Вот пусть люди и сами варятся в этом супе.
Мне за 10 лет как-то поднадоел уже баш.

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

войд
очень грамотный

Небось, как и его адепты...

с весьма уважаемым создателем

Для меня не существует авторитетов. Посмотрел на педивикии - какой-то хрен с горы, ранее мэйнтейнивший нетбсд.

то что у него пока мало мэйнтенеров не делает его ноунэйм.

Не делает, естественно. Делает его таковым малое количество юзеров.

border-radius
()
Ответ на: комментарий от kir2yar

Смех, смехом, но и весь системд около одного направления - нормальная системная прослойка.

Она слишком жирная.

loginctl list-sessions

Но зачем это должно быть вместе с init ?

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

Мне за 10 лет как-то поднадоел уже баш.

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

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

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

Эм, так делает ядро, астериск, апач и xorg, да фактически
все суют основные плагины в основное дерево.

Я уже пояснил основную мысль. Повторюсь. От того, что грохнется астериск, я не потеряю сервер, и смогу его откатить. От того, что грохнется ядро, я не потеряю сервер, так как его ребутнёт ватчдог загрузчика или материнки (или палец с ногами, в конце концов), после чего сервер поднимется со старым. А вот если прилетит падучий init, то кто мне его откатит ?

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

Появился systemd - появилась проблема.

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

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

Она слишком жирная.

Полтора метра - жирная? Тот-же баш, который дергается при каждом запуске неоднократно весит метр. Плюс к нему еще нужен init.
$ du -h /bin/bash /lib/systemd/systemd
1016K /bin/bash
1,6M /lib/systemd/systemd


Но зачем это должно быть вместе с init ?

Сессии начинаются с инита по факту. Кроме того, loginctl не единственная фича проекта. Тот-же systemctl достаточно удобен и нагляден.

Возможно у системд есть косяки (да где их нет?) но я еще не встречал, а функционала они сильно добавили.

kir2yar
()
Ответ на: комментарий от border-radius

Не делает, естественно. Делает его таковым малое количество юзеров.

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

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

От того, что грохнется астериск, я не потеряю сервер, и смогу его откатить.

Без резервного хоста, от того, что грохнется астер ты потеряешь премию, как минимум.

А вот если прилетит падучий init, то кто мне его откатит?

Те, падучий инит физически уничтожит сервер? И даже IPMI тебе убьет?
Хз, что надо делать с инитом (что системд, что sysv) что бы на тестах он выжил, а при внедрении на прод - фатально сдох.

kir2yar
()
Ответ на: комментарий от border-radius

Minix тоже разработан академически корректно и «весьма уважаемым специалистом», и кому он сейчас нужен?

что-ты хочешь сказать? minix - ноунэйм? в minix нечему научиться? миникс не используется для отжима пота? или что?

dinama
()
Последнее исправление: dinama (всего исправлений: 1)
Ответ на: комментарий от AS

А вот если прилетит падучий init, то кто мне его откатит ?

Ты %)

С матюками, холодным потом и проклятиями в адрес того, кто это сделал. 8)

Уверяю тебя - у тебя получится. Ничто так не мотивирует, как неустойка за время простоя.

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

ээ 1000 мух не могут ошибаться? или что ты хотел сказать?

Как правило больше юзерей в опенсорс-проекте = быстрее развитие и качественней софт. (Правило действует только на опенсорс)

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

А вот если прилетит падучий init, то кто мне его откатит ?

yum history undo? хотя, казалось бы, обновления надо тестировать перед продом

EvgGad_303 ★★★★★
()
Последнее исправление: EvgGad_303 (всего исправлений: 1)
Ответ на: комментарий от kir2yar

Хз, что надо делать с инитом (что системд, что sysv) что бы на тестах он выжил, а при внедрении на прод - фатально сдох.

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

В случае с sysvinit (не сталкивался чтобы он беспричинно сдох, - какие-то его проходные скрипты - могут, но) - ты сразу увидишь отчет об этом, через kvm, через uart, через перенаправленную системную консоль, в postmortem логах загрузки, но увидишь. Даже если грохнется что-то критичное при загрузке - выключишь глюку в интерактивном режиме через emergency shell, загрузишь систему и разберешься - что случилось.

А вот как с сабжем быть - я хз. Нарисовал он тебе, что ядро загрузилось, populating udev - и висяк. Куда копать? Что делать? Где логи? Где грохнулось? Где у него хотя бы вербозность повысить - может он на загрузке какого-то ядерного модуля лёг, может при ините какого девайса - я откуда это узнаю?

Печаль...

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

Если только другое сетевое окружение - а корень и изоляцию юзеров не надо, можно через ip netns в другое namespace приложение отправить

да, мне нужно запустить пару/тройку экземпляров одного приложения с кучей слушающих сокетов; разделить директории (конфиги, логи) отдельных инстансов я могу и без контейнеров, наверно; а вот сеть каждого нужно изолировать, причем выдавая каждому определенный IP вручную, ну еще нужно задавать ограничения в cgroups по нодам, где разрешено выделять память, и cpuset отдельно для каждого экземпляра

как-то можно все вот это запилить без контейнеров вообще, и через один юнит на каждый экземпляр, чтобы все системные настройки по изоляции инстансов лежали в одном месте?

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

Без резервного хоста, от того, что грохнется астер ты потеряешь премию, как минимум.

Это понятно, но речь не об этом, а о том, что надо будет тащить куда-то свою задницу даже в том случае, если есть резерв: поднимать-то надо всё равно, пусть и не срочно.

И даже IPMI тебе убьет ?

А толку от него, если в системный шел попасть нельзя ? Кроме того, его может и не быть. Да, оборудование, которое работает 24/7, может работать и не на серверном железе, на самом-то деле. Я могу тебе показать семилетний сервер, который напоминает сервер только 2U корпусом. Причём, на самом деле, наверное побольше, так как это у hdd Power_On_Hours - 66421.

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

ну не знаю как юнитом, но скриптами это делается достаточно тривиально

Базовые принципы неплохо описаны тут

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

а чья это проблема, если остальные ещё более отсталые?

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

тебе уже намекнули про централизованное обновление мажорной версии без тестового развёртывания

А я намекнул на то, что намекнувшие нихрена не знают о реальной работе. Сколько обычно тестовых машин для развертывания теста? Ответ, я думаю - ты знаешь сам.

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

Повторяю сентенцию - что делать, если один из этих репликантов встал раком после апдейта, и причины выяснить не представляется возможным?

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

А вот как с сабжем быть - я хз. Нарисовал он тебе, что ядро загрузилось, populating udev - и висяк. Куда копать? Что делать? Где логи? Где грохнулось? Где у него хотя бы вербозность повысить - может он на загрузке какого-то ядерного модуля лёг, может при ините какого девайса - я откуда это узнаю?

А вот тут на помощь как раз приходит штуковина, над которой много кто почему-то ржал. Заходишь браузером по айпишнику железяки на порт 19531 и смотришь все события. Ну а если всё настолько плохо, что и сети нет, то journalctl в той же emergency shell, поднятой всё тем же описанным тобой методом, никто не отменял.

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

Как, если оно не грузится, и я туда должен ногами попасть?

Цитирую себя же: «через kvm, через uart, через перенаправленную системную консоль»... У админа много путей... И разных способов...

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

У крутого одмина нет сетевой загрузки с кикстартом или подобным?

Мне это делать ради systemd ? А зачем ? Я скоро 20 лет, как без этого спокойно живу. :-) Кроме того, как ты заставишь поменять источник загрузки без IPMI (см Релиз systemd 230 (комментарий)) ? Или надо всё срочно апгдейдить, да ещё в кризис, так как systemd - это круто ?

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

Цитирую себя же: «через kvm, через uart, через перенаправленную
системную консоль»...

А сам-то как откатывал зависший udev ? Речь-то про незагрузившуюся систему. Это в каждом компе теперь флешку держать с resque-образом, что ли ? :-)

AS ★★★★★
()

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

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

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

Та же самая история с ядром линукса

Опять грубое передёргивание. Не та же самая. Ядро не подменяет собой существующие и хорошо работающие службы.

frost_ii ★★★★★
()
Ответ на: комментарий от border-radius

journalctl в той же emergency shell, поднятой всё тем же описанным тобой методом

...*ять...

Да висит оно! Наглухо! Нет ничего, ни отклика на сеть, ни отклика на локальную клаву, ни на события uart'а, - мертвое, зависшее. Какой нах* journalctl (где плейнтекстовый лог в консоли?!), какой шелл? Система мертвая. Сразу после загрузки ядра - рисует указанную картинку и виснет.

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

Только, вот, боюсь, - не повторится. Нет у меня больше systemd нигде. И не будет. 8)

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

Особенно после того как РедХат стал избыточной прокладкой к Azure. Угу. Уже попкорном запасся

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

А сам-то как откатывал зависший udev

Рассказываю. В эмбеддеде есть довольно продвинутые бут-лоадеры. Зачастую это u-boot. При наличие сети ему нужно просто сказать - какой интерфейс поднять, откуда взять ядро, настройки загрузки и рутфс.

Угадай, что я делал дальше. 8)

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

то в современных реалиях он абсолютно бесполезен.

бесполезен для чего? для отжима пота из админов или что?

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

Мне это делать ради systemd ?

Опытные инженеры это не только ради системд делают.

Я скоро 20 лет, как без этого спокойно живу. :-)

Да я заметил.

Кроме того, как ты заставишь поменять источник загрузки без IPMI

Остаётся тебе только посочувствовать. Я со всяким говном без удалённого доступа не работаю.
да, и как ты собрался чинить тот другой инит без ipmi?

EvgGad_303 ★★★★★
()
Последнее исправление: EvgGad_303 (всего исправлений: 1)
Ответ на: комментарий от LinuxDebian

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

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

/usr/lib/sftp-server

и это отдельный сервер который можно использовать например с dropbear у которого нет своего сервера sftp, а компоненты systemd возможно так использовать ?

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

Опытные инженеры это не только ради системд делают.

Есть задачи разной важности, под них выбираются разные железки. А вот обновлять приходится все рано или поздно.

и как ты собрался чинить тот другой инит без ipmi?

В нём на порядки реже находятся ошибки. Точнее, даже не так: он давным давно стабилен и делает то, что требуется.

Вот, например: http://savannah.nongnu.org/projects/sysvinit
Последняя версия от 14 Apr 2010. 103K, кстати, забзипленный тарбол.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от Olegarch

В случае с sysvinit (не сталкивался чтобы он беспричинно сдох, - какие-то его проходные скрипты - могут, но) - ты сразу увидишь отчет об этом, через kvm, через uart, через перенаправленную системную консоль, в postmortem логах загрузки, но увидишь. Даже если грохнется что-то критичное при загрузке - выключишь глюку в интерактивном режиме через emergency shell, загрузишь систему и разберешься - что случилось.

Эм, системд упадет в rescue-mode и от туда тоже можно починиться.
А если он совсем крешнется - то тот-же uart/ kvm в помощь. Тут нет никаких отличий.

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

такое ощущение, что никто не читает что было написано. проблема и была в том, что systemd просто повис на populating udev. и не откликался и никуда ничего не писал. если бы оно свалилось в rescue и/или писало бы больше в консоль/uart и т.д., вопросов бы не было у человека.

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

Ответ, я думаю - ты знаешь сам.

Я-то знаю, а вот у тебя, похоже, ни одного.

Повторяю сентенцию - что делать, если один из этих репликантов встал раком после апдейта

Всё то же самое, что и в случае с инитом.

причины выяснить не представляется возможным?

манцов читнуть не пробовал? говорят помогает.

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

и не на серверном железе

Прод. Mission-critical... Во всей красе.
В таких случаях ставят в полтора раза больше серверов, чем реально нужно. И простой одной железки до недели - ни на что не влияет.

Ну ежель у вас важный сервис крутится на одной железке, не серверного класса и без резервирования... Тут даже нет смысла об инитах рассуждать.

у hdd Power_On_Hours - 66421

Стальные шарики, блин. Хоть на бэды проверяете?

Я все свои сервера планово перезапускаю раз в месяц (обновления да и вообще тест состояния железа). Разок так удалось обнаружить гибель блока питания, пару раз - память...
Вообще безумный аптайм самого сервера больше нужен для писькомерства. Гораздо важнее аптайм сервиса.

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

Это в каждом компе теперь флешку держать с resque-образом, что ли ? :-)

Серверная инфраструктура без спасительной загрузки через сеть??

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