asterisk.ru

Ок, вы безусловно правы, простите. Нет смысла продолжать.

Ок, вы безусловно правы, простите. Нет смысла продолжать.

Не надо было начинать

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

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

Традиции вообщем-то не причем.
1) банально, при выполнение apt upgrade, каждый раз будет всплывать под сотню *-dev пакетов под обновление, которые по сути не нужны, нужны были исключительно для сборки.
2) допустим, у вас прод сервер с уже собраным астериском, на нём решаете обновлять астер, путем пересборки, пересборка - ресурсоемкая задача, тратящая cpu, хорошо если не заметите.
3) drift окружения, у вас по какой-то причине упал сервер/сгорел/затопило и т.д. нужно развернуть идентичную версию asterisk, но уже могли уехать dev версии зависимых пакетов и да, скорее всего соберется рабочий астер той же версии, но добавляет "непредсказуемости". или решили 2ую ноду развернуть и сталкиваетесь с таким нюансом.
4) как уже выше Павел написал, вопрос безопасности, наличие gcc, make может быть потенциально служить дополнительным вектором атаки.
5) откат проще, вот вы собрали новый астер, установили и оказывается, что новая версия не подходит по каким-либо причинам (новые функции, изменение поведения). ваши действия? снова пересобирать старую версию? а ведь можно было старый deb пакет установить.

Традиции вообщем-то не причем.
1) банально, при выполнение apt upgrade, каждый раз будет всплывать под сотню *-dev пакетов под обновление, которые по сути не нужны, нужны были исключительно для сборки.
2) допустим, у вас прод сервер с уже собраным астериском, на нём решаете обновлять астер, путем пересборки, пересборка - ресурсоемкая задача, тратящая cpu, хорошо если не заметите.
3) drift окружения, у вас по какой-то причине упал сервер/сгорел/затопило и т.д. нужно развернуть идентичную версию asterisk, но уже могли уехать dev версии зависимых пакетов и да, скорее всего соберется рабочий астер той же версии, но добавляет "непредсказуемости". или решили 2ую ноду развернуть и сталкиваетесь с таким нюансом.
4) как уже выше Павел написал, вопрос безопасности, наличие gcc, make может быть потенциально служить дополнительным вектором атаки.
5) откат проще, вот вы собрали новый астер, установили и оказывается, что новая версия не подходит по каким-либо причинам (новые функции, изменение поведения). ваши действия? снова пересобирать старую версию? а ведь можно было старый deb пакет установить.

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

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

https://github.com/pqlx/CVE-2022-1015
как видите Cшный код.
получают не рутовый доступ по ssh, а у вас build essential c gcc,make - собирают, получают рутовый шел. "всё чунга-чанга"(с)

https://github.com/pqlx/CVE-2022-1015
как видите Cшный код.
получают не рутовый доступ по ssh, а у вас build essential c gcc,make - собирают, получают рутовый шел. "всё чунга-чанга"(с)

Благодарю.

https://github.com/pqlx/CVE-2022-1015
как видите Cшный код.
получают не рутовый доступ по ssh, а у вас build essential c gcc,make - собирают, получают рутовый шел. "всё чунга-чанга"(с)

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

#ЕстьМнение

Денежная масса M2 в России растет быстрее, чем в относительно спокойные 2016–2019 годы, но медленнее, чем в турбулентный период 2022–2024 годов — и эта «золотая середина» указывает на инфляцию около 5,8–6% по итогам 2026 года и курс доллара в районе 82–86 рублей к декабрю.

Если немонетарные факторы — вроде уже происходящего скачка цен на бензин — способны в одиночку сломать весь этот аккуратный прогноз, то какой именно порог их влияния превращает умеренный инфляционный сценарий в неуправляемый?

Никита Лысенок, ведущий преподаватель магистерских программ «Финансовый инжиниринг» и «Инвестиции на финансовых рынках» НИУ ВШЭ, сооснователь инвестиционного клуба SDF Solutions:

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

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

Первый и главный предохранитель — инфляционные ожидания. Июль показал механику наглядно: на топливных новостях ожидания населения подскочили с 12,4% до 14,7%, это сильнейший рывок за несколько лет. В августе они откатились к 13,7%, и во многом потому, что в коммуникации властей и Банка России был последовательный акцент на временном характере шока, и люди в это поверили. Пока в разовость верят, шок остается эпизодом статистики, и регулятор может смотреть сквозь него. Вторая волна ажиотажа проверяет эту веру прямо сейчас. Тихий, но важный сигнал: ожидания на пять лет вперед подросли до 12,4%, то есть сомнения появляются уже не про этот год, а про способность инфляции вернуться к цели в принципе.

Второй предохранитель — дизель. Бензин это в основном личные автомобили, а дизель это вся логистика и, через неё, продовольственная корзина. Пока дизель удержан, вторичный перенос шока в широкий круг цен ограничен. Если ускорится дизель, вслед за ним поедет всё остальное.

Третий — сам механизм ценового регулирования: он работает, пока выдерживает нагрузку. Чем дольше длится шок, тем эта нагрузка выше.

Поэтому вместо порога я бы дал наблюдаемые маркеры перехода. Первый: ожидания населения после всплеска не возвращаются вниз два-три месяца подряд. Второй: рост цен из точечного становится широким, что видно по устойчивым компонентам инфляции. Третий: ускоряются дизель и продовольствие. Когда эти маркеры загораются вместе, включаются индексации, перенос издержек и покупки впрок, и у сценария меняется вся арифметика. Операционное определение простое: умеренный сценарий перестаёт быть базовым в тот момент, когда Банку России приходится прерывать цикл смягчения политики. Ближайшая контрольная точка — заседание 11 сентября.

Так что порог влияния немонетарных факторов измеряется не в рублях за литр. Он измеряется в месяцах, которые инфляционные ожидания отказываются снижаться. @nebrexnya

Если кто пропустил:
https://www.asterisk.org/manager-event-queueing-improvement/

? Мощное обновление в Asterisk: оптимизация очередей AMI

Разработчики выкатили важное архитектурное изменение «под капотом», которое сильно ускорит работу Asterisk Manager Interface (AMI) под высокой нагрузкой.

? Как было раньше:
Все подключенные интеграции (CRM, панели телефонии и т.д.) сидели в одной гигантской общей очереди событий. Из-за этого:
• Каждая сессия тратила ресурсы на проверку чужих событий.
• Потоки блокировали друг друга.
• Память от старых событий очищалась с задержкой.
• Итог: тормоза и те самые бесячие предупреждения taskprocessor в логах.

? Что изменили:
• Индивидуальные очереди: У каждой сессии AMI теперь своя независимая очередь.
• Умная фильтрация: События фильтруются на входе. Сессия получает только то, что ей нужно, и не «просыпается» вхолостую.
• Мгновенная очистка: Перешли на объекты ao2 с подсчетом ссылок — память освобождается моментально (отдельный поток-уборщик больше не нужен).
• Меньше блокировок: Улучшен механизм чтения событий — теперь процессы добавления и чтения не тормозят друг друга.

? Результат:
AMI потребляет значительно меньше ресурсов CPU, а потолок производительности сильно вырос. Перегрузки (taskprocessor warnings) теперь будут возникать гораздо реже. Сервер станет стабильнее, особенно если у вас много звонков и активных интеграций.

? Уже доступно в релизах:
Asterisk 20.21.0, 22.11.0 и 23.5.0.