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)
Ответ на: комментарий от Stanson

Способ разобраться в причинах падения - это логи и дебаггер

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

Объяснять кому? Самому себе?

Вы работаете один и на себя?

А это повод для жёстких мер по отношению к тому дебилу, который жестко завязал всю работу конторы на какого-то криво написанного проприетарного демона не оставив никакого failover'а.

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

Демон написан моими коллегами. Как и в любом ПО, в нём бывают ошибки. Резерв невозможен в силу специфики его работы (пришлось бы городить синхронизацию состояния).

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

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

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

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

Демон написан моими коллегами.

раз

Как и в любом ПО, в нём бывают ошибки.

два

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

три

Вы как будто в своём выдуманном мирке живёте

четыре

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

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

пришлось бы городить синхронизацию состояния

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

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

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

Во-первых, код выхода, вообще-то нужен в первую очередь для использования программы в скриптах в качестве кирпичика. А во-вторых, он не должен сообщать об ошибках _внутри_ программы, он для _штатной_ отработки совершенно _штатных_ вариантов развития событий при работе программы, когда она по тем или иным, _не_зависящим_от_неё_причинам_ не может продолжать работу. Например нужный файл не найден, хост недоступен, получены невалидные данные и т.д. Использовать код выхода для _отладки_ самой программы - это полный идиотизм. Для этого есть логи, ассерты, дебаггеры и пр.

Вы работаете один и на себя?

Я совладелец конторы. Так что работаю не один и не только на себя.

Демон написан моими коллегами. Как и в любом ПО, в нём бывают ошибки. Резерв невозможен в силу специфики его работы (пришлось бы городить синхронизацию состояния).

Архитектора - на рею.

Вы как будто в своём выдуманном мирке живёте

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

но и с малоизвестными

С малоизвестными всё ещё проще чем с известными, их можно просто перепилить под себя и не испытывать при этом, например, проблем с обновлениями и всем таким.

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

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

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

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

времена меняются, а этот мелкий недопровайдер по-прежнему не может понять, что Restart=on-failure - опциональная не дефолтная настройка. Ему она не нужна, а например мейнтейнерам docker в дебиане - нужна. Бывает же.

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

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

/facepalm

Код выхода - это один из способов передать информацию. Всё остальное - лишь ваши домыслы.

Я совладелец конторы.

Ну вот и выходит, что предъявить вам некому.

С малоизвестными всё ещё проще чем с известными, их можно просто перепилить под себя и не испытывать при этом, например, проблем с обновлениями и всем таким.

Во-первых, возможность перепилить под себя зависит от размера и сложности проекта, а не его известности. Да, есть корреляция, но далеко не единица.

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

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

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

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

Значит, наряду с PostgreSQL надо поднять и продублировать всё в MySQL, ejabberd дополнить каким-нибудь openfire, локальный gitlab подпереть... чем, кстати?

Надеюсь, в вашей правильной конторе всё именно так и устроено.

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

И при этом процентов так 90 посетителей этого сайта узнали в этом описании свою контору. :)

Внезапно, преимущества такого ПО как система инициализации и проявляются тогда, когда всё работает неидеально.

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

сейчас уже столько средств и хранилищ на любой вкус для совместной работы с данными

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

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

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

преимущества такого ПО как система инициализации и проявляются тогда, когда всё работает неидеально.

ага... комп не загрузился из-за сабжа - вот тебе и все преимущество...

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

Код выхода - это один из способов передать информацию. Всё остальное - лишь ваши домыслы.

Можно и гланды через жопу удалять, и дебаг через exit code делать.

Ну вот и выходит, что предъявить вам некому.

Предъявить что?

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

Да, на костыли обоснование не требуется. Правда вот человекочасов, как правило, в итоге требуется на порядки больше, а это даже финансово просто невыгодно.

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

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

Значит, наряду с PostgreSQL надо поднять и продублировать всё в MySQL, ejabberd дополнить каким-нибудь openfire, локальный gitlab подпереть... чем, кстати?

Т.е. подумать чуть дальше своего огорода ты даже и не пытаешься. :) Понятненько. Вот поэтому ты и работаешь на дядю, а не на себя.

Надеюсь, в вашей правильной конторе всё именно так и устроено.

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

Внезапно, преимущества такого ПО как система инициализации и проявляются тогда, когда всё работает неидеально.

И это неизбежно приводит к резкому падению качества софта и культуры производства, что собственно и наблюдаем. Зачем искать баги, что-то там чинить, думать о правильной архитектуре и организации работы, если можно просто перезапускать падающее говно? Системдэ очень вреден в дальней перспективе.

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

Можно и гланды через жопу удалять, и дебаг через exit code делать.

В какой-то книжке прочитали, что код выхода исключительно «для _штатной_ отработки совершенно _штатных_ вариантов развития событий при работе программы» - и изливаете теперь здесь свой синдром утёнка? Какие принципиальные проблемы с использованием кода выхода для передачи причины ошибки, внутренней или внешней?

Предъявить что?

За необоснованный простой.

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

Зачем останавливаться на полпути? - надо организовать работу так, чтобы её можно было делать и при неработающих компьютерах! Теоретики, блин...

Т.е. подумать чуть дальше своего огорода ты даже и не пытаешься. :) Понятненько.

Т.е. ответить вам нечего, вот вы и отбрехиваетесь общими фразами. И правда, всё с вами понятно.

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

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

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

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

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

За необоснованный простой.

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

Зачем останавливаться на полпути? - надо организовать работу так, чтобы её можно было делать и при неработающих компьютерах!

Ты не поверишь. Это не только возможно, но и прекрасно работает уже 20 лет.

Теоретики, блин...

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

Т.е. ответить вам нечего, вот вы и отбрехиваетесь общими фразами.

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

И правда, всё с вами понятно.

Да, я вижу, понимание прям брызжет :)

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

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

Вы придуриваетесь или правда не понимаете? Делаю последнюю попытку объяснить.

К примеру, есть локальный gitlab. Работа происходит приблизительно так:

  1. Программисты отправляют коммиты в репозиторий gitlab, где они проверяются автоматическими тестами CI.
  2. Нередко изменения сперва проходят review через MR там же.
  3. Когда подходит время выпуска, создаётся тег, по которому CI gitlab собирает тестовые образы и отправляет тестерам.
  4. Тестеры сообщают о найденных проблемах в issues проекта в gitlab.
  5. Когда основные баги исправлены, CI по тегу собирает финальные образы, подписывает их и отправляет на сервер обновлений, откуда их потом утягивают клиенты.

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

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

Эта инфраструктура сделана не просто так, а потому что она позволяет автоматизировать и свести воедино многие процессы, увеличивая эффективность.

Видимо ты действительно вообще не видишь дальше собственного носа. :)

Если суть бизнеса сводится к тому, чтобы софт обновлялся (ради обновлений ?) ежесекундно, а задержка обновления на час и тем более сутки означает недопустимые финансовые потери, то проблема вовсе не в наборе софта, который обеспечивает это ежесекундное обновление, а в самой бизнес-модели.

Не пробовал подумать, а зачем вообще клиентам нужно всё это ваше непреывное CI? Может им вовсе не CI нужно, а качественный продукт, на самом деле...

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

Видимо ты действительно вообще не видишь дальше собственного носа. :)

Если суть бизнеса сводится к тому, чтобы софт обновлялся (ради обновлений ?) ежесекундно, а задержка обновления на час и тем более сутки означает недопустимые финансовые потери, то проблема вовсе не в наборе софта, который обеспечивает это ежесекундное обновление, а в самой бизнес-модели.

Нет, это вы не видите дальше собственного носа. Бизнес-модель интернет-провайдера «немножко» отличается от бизнес-модели, например, игровой индустрии, и слепо переносить свои повадки на других вам не следует. У вас может быть очень много клиентов, но всем им нужен приблизительно один и тот же набор сервисов. У нас же под три сотни версий конфигурации под разные страны и даже штаты, и любые проблемы с нашим ПО (которое чертовски сложное внутри) - это потери миллионов в день, и вовсе не рублей. Так что если у вас нет конкретных и чётких аргументов, то держите своё дилетантское мнение при себе.

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

Только осталось объяснить, зачем нужны эти непрерывные обновления. :) Иначе вся картина о страшной необходимости рестартовать падающий жидлаб как-то рушится. :)

И, традиционно, мы никогда не узнаем конкретного названия чудесного предприятия игровой индустрии где всё надо непрерывно обновлять и перезапускать. :)

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

Бизнес, он вообще-то про получение прибыли, а не чтобы какая-то программка постоянно работала.

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

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

И до сих пор не его задача, если архитектура правильная.

Раз функционал приделали, то, увы, уже его. А это лишний ненужный для init код, где тоже может быть баг.

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