Исправление 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 плохой? А какая разница, что именно не так настроил тот, кто образ делал, если явная проблема возникла из-за его действий?