LINUX.ORG.RU

История изменений

Исправление mogwai, (текущая версия) :

Нет, проблема у тех,…

у кого после установки пакета демон себя ведёт так, как в документации проекта описано?

Есть много вариантов его выключения. Просто ошибка в конфигурировании, например.…

Так pourquoi ты долбоящеров к серверам подпускаешь?) И какая ещё причина может быть?

Это сломает сервис только тем, кто вовсе не лазил в настройки memcached при этом, использует его не на локалхосте.

Так и с какого перепугу ты им сервис ломать будешь, если их баг не задевает?

То есть, людей с первым и вторым твоими случаями это не затронет, так как %config(noreplace) же наверняка, да?

Как это не затронет? Им из-за твоего самодурства придётся автоматизацию развёртывания серверов перенастраивать, а им на баг udp плевать, ибо они udp не используют, а вот tcp используют.

Почему в ALT это сделали 7 (!) лет назад, а в RH/CentOS додумались совсем недавно.

До чего додумались-то? Не путай дефолтный конфиг и патч на бинарник. Ты продемонстрируй как ты подключишься к udp/11211, если он iptables закрыт. Или ты так, покукарекать «наш дифолт лучше»? Не лучше. Нормальный админ, когда разворачивать систему будет, в конфиг заглянет и внесёт нужные изменения, или убедится, что они уже есть.
А дефолт такой потому что RHEL либо решили заранее не идти в разрез с документацией memcached, где написано «по дефолту на всех интерфейсах», либо в приоритете ЦА которой к memcached доступ по сети нужен; а базальт либо срать хотел на документацию, либо в приоритете маленькие сервера с локальным php-memcached. Вопрос лишь того, кому вызвать sed, ибо уровень безопасности оно не снижает.

Это верно, но спорит тут с тобой не пользователь CentOS

И наружу торчит udp/11211 не у пользователя centos, а у пользователя кривой сборки на основе centos. И, как ты выше уже сказал, раз вызвался ему помочь, то пошёл бы и настрочил репорт автору этого образа в openvz. Если бы memcached в этом образе из коробки был (а может и есть, кстати…) и был настроен на прослушивание udp/1121@eth0 автором этого образа, ты бы тоже тут кукарекал, что CentOS плохой? А какая разница, что именно не так настроил тот, кто образ делал, если явная проблема возникла из-за его действий?

Исходная версия mogwai, :

Нет, проблема у тех,…

у кого после установки пакета демон себя ведёт так, как в документации проекта описано?

Есть много вариантов его выключения. Просто ошибка в конфигурировании, например.…

Так pourquoi ты долбоящеров к серверам подпускаешь?) И какая ещё причина может быть?

Это сломает сервис только тем, кто вовсе не лазил в настройки memcached при этом, использует его не на локалхосте.

Так и с какого перепугу ты им сервис ломать будешь, если их баг не задевает?

То есть, людей с первым и вторым твоими случаями это не затронет, так как %config(noreplace) же наверняка, да?

Как это не затронет? Им из-за твоего самодурства придётся автоматизацию развёртывания серверов перенастраивать, а им на баг udp плевать, ибо они udp не используют, а вот tcp используют.

Почему в ALT это сделали 7 (!) лет назад, а в RH/CentOS додумались совсем недавно.

До чего додумались-то? Ты продемонстрируй как ты подключишься к udp/11211, если он iptables закрыт. Или ты так, покукарекать «наш дифолт лучше»? Не лучше. Нормальный админ, когда разворачивать систему будет, в конфиг заглянет и внесёт нужные изменения, или убедится, что они уже есть.
А дефолт такой потому что RHEL либо решили заранее не идти в разрез с документацией memcached, где написано «по дефолту на всех интерфейсах», либо в приоритете ЦА которой к memcached доступ по сети нужен; а базальт либо срать хотел на документацию, либо в приоритете маленькие сервера с локальным php-memcached. Вопрос лишь того, кому вызвать sed, ибо уровень безопасности оно не снижает.

Это верно, но спорит тут с тобой не пользователь CentOS

И наружу торчит udp/11211 не у пользователя centos, а у пользователя кривой сборки на основе centos. И, как ты выше уже сказал, раз вызвался ему помочь, то пошёл бы и настрочил репорт автору этого образа в openvz. Если бы memcached в этом образе из коробки был (а может и есть, кстати…) и был настроен на прослушивание udp/1121@eth0 автором этого образа, ты бы тоже тут кукарекал, что CentOS плохой? А какая разница, что именно не так настроил тот, кто образ делал, если явная проблема возникла из-за его действий?