LINUX.ORG.RU

Выпуск Systemd 243 с устранением уязвимостей

 


1

2

Выпущено крупное обновление широко используемой системы инициализации Linux.

Примечания к выпуску

  • новый инструмент systemd-network-generator
  • дополнения resolctl
  • поддержка определения NUMAPolicy для служб systemd
  • теперь PID1 прослушивает события о нехватки памяти ядра
  • диспетчер служб теперь предоставляет ресурсы ввода-вывода, используемые модулями systemd
  • поддержка MACsec в сети
  • пользовательские программы BPF в cgroups
  • новый сервис Pstore
  • устранена уязвимость systemd-resolved ― No access controls for systemd-resolved DBUS API

Systemd 243 - это большой релиз, внесенный в большинство дистрибутивов для осенних обновлений.

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

★★

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

Я тут немного не заметил.

systemd-journald will now stop logging to /var/log/journal during shutdown when /var/ is on a separate mount,

этот прогер к 243(!) релизу додумкал до того, что очевидно для любого простого админа

А назови-ка мне хотя бы одну службу ведения логов в GNU/Linux (кроме systemd-journald 243), которая автоматически меняет своё поведение в зависимости от примонтированных ФС?

А то сдаётся мне, что ты снова занимаешься поиском соринок в глазу проекта.

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

А назови-ка мне хотя бы одну службу ведения логов в GNU/Linux (кроме systemd-journald 243), которая автоматически меняет своё поведение в зависимости от примонтированных ФС?

А зачем демону (демону, едрёна кочерыжка, «службы» это в венде) который пишет логи вообще заниматься мониторингом ФС? Это не его собачье дело.

При halt/reboot syslog просто прибивался перед тем, как отмонтировались файловые системы (или рут перемонтировался в ro). Если очень нужно зачем-то иметь возможность заниматься логгированием и после отмонтирования ФС, то никто не мешал при halt/reboot не убивать, а перезапускать syslog c конфигом типа *.* @somehost или там *.* /dev/console. Правда не очень понятен юзкейс для этого, ведь все процессы к этому времени уже прибиты и логи писать просто некому. Но всё равно можно.

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

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

А назови-ка мне хотя бы одну

Чтоб ничего не разваливалось, я все в моей конструкции скрепил синей изолентой.

А назови-ка мне хотя бы одну конструкцию закрепленную синей изолентой?

то-то!

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

демону, едрёна кочерыжка, «службы» это в венде

dæmon — это конкретная техническая идея долгоживущего процесса, который работает в фоне. А служба — это общая концепция. И здесь, в данном случае, плевать, как эта служба будет реализована (в виде демона, да хоть в виде скрипта, запускающегося на каждую новую строчку из кольцевого буфера сообщений ядра).

А зачем демону <…> который пишет логи вообще заниматься мониторингом ФС? Это не его собачье дело.

Ну я тоже так считаю. А @crypt говорит, что-де systemd только к версии 243 дошёл до того, что все остальные якобы всегда умели и делали.

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

А назови-ка мне хотя бы одну конструкцию закрепленную синей изолентой?

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

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

тачка падает

прямо как линукс с системд...

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

А @crypt говорит, что-де systemd только к версии 243 дошёл до того, что все остальные якобы всегда умели и делали.

конкретно в том посте я критикую не systemd, я прямо пишу, что сомневаюсь в компетенции создателей-программистов. я не пишу, что какие-то сервисы работали как-то иначе (ну нет этого в моем сообщении). просто сообщение в чейджлоге выглядит как очевидная ошибка проектирования. ну ты вот мне отвечаешь, что мол оно как-то по-другому работало. ну мне нечего возразить, так как я хз. я с systemd завязал сразу после того, как оно не смогло прочекать фс и загрузиться. ну ок, я признаю, что ошибки в программах исправляются. если люди это назвали 243 релизом, то я бы назвал 0.243 бета релизом. ну разгребайте, изучайте... я уже обозначил, что мне проще freebsd изучить и использовать старые парадигмы админства, чем переделывать все на новый декларативный подход, потому что microsoft и редхат теперь руководствуются новыми данными статистики. я готов постебаться над чейжлогом, но не готов следить за всем этим бредом в продакшене. в какой-то момент systemd допишут, появится новый systemd/Linux (недавно слышал, что даже grub можно уже выкинуть и грузиться сразу через efi+systemd) и дефолтное поведение перестанет меняться.

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

А служба — это общая концепция.

Эта «общая концепция» прямиком из венды.

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

Теперь модно делать велосипеды в виде «скрипта, запускающегося на каждую новую строчку из кольцевого буфера сообщений ядра» ? А что будет с системой при шторме из битых UDP пакетов, например? Так-то нормальный человек напишет что-то типа kern.* |/some_fifo и повесит демона слушать этот fifo, чтобы не запускать процесс на каждый чих.

Ну я тоже так считаю. А @crypt говорит, что-де systemd только к версии 243 дошёл до того, что все остальные якобы всегда умели и делали.

Ты не понял. Раньше такой проблемы вообще не существовало. А вот системдэ её создал и героически решал аж до версии 243.

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