В дебиане оно падает с ассертом в libc - так что можуть как хитрее и возможно эксплуатировать. Но сумлеваюсь я.
Как бы то ни было - апдейт вышел, don't panic!
Можно пруфлинк какой? А то просто security обновление пока не выпустили, вот и все.
Чет не взлетает на debian. У кого-нить получилось?
Я уж и создал /tmp на том же разделе, что и суидные бинарники (как в примере эксплойта).
Ну не делайте как подобные буратины - вот и все.
дырка в glibc, а не в "linux"
Объяснили уже, почему не глупость. Чего Вам еще непонятно?
А с тем, что апач в качестве прозрачного прокси вполне способен заменить nginx - я вполне с Вами согласен.
Эт Вы загнули. Он не использует кипалайв только при общении с бакендом (апачевский прокси, кстати, умеет такое делать).
На память акселератору может и не хватить - а nginx явно будет полезен. Т.к. в 99% случаев нагрузки - именно он возьмет на себя обработку медленных клиентов (если это перестало быть узким местом - тормозит бакенд, пора оптимизировать скрипты и т.п.), потому апачи память жрать не будут только ради этого.
Еще раз повторюсь - дело не в nginx, как в программе - дело в организации хостинга (фронтенд/бакенд vs один бакенд). Роль nginx'а как программулины с успехом сыграет апач с mpm event.
1) "Каким образом" - написали пару раз уже выше. Прокси (фронтенд) - возьмет на себя обработку медленных клиентов. Экономя тем самым память. Золотым прокси точно не станет, только от того, что будет работать на nginx, а не на апаче или лайти.
2) Которых "байт"? Что с чем Вы сравниваете? Какой MPM у апача?
Вы удивитесь - но апач уже давным давно не только prefork. Для динамики (в т.ч. бакенда) - не всегда удобно использовать что-то отличное от него, а вот на фронтенде - как раз наоборот.
Может их и нет особо?
А вот Вы сумеете сформулировать эти пресловутые "приемущест"?
Я бы не советовал игнорировать mismatch_cnt и в пределе десятка - на raid5.
Сейчас есть документация, в т.ч. упомянута по ссылкам в баге. Там сказано, когда mismatch_cnt доверять не стоит (это относится только к raid1!). Совсем, однако, "забить" - не стоит. Сделайте скрипт, проверающий массивы по крону (в debian есть искаропки), с меньшей периодичностью - можно запускать repair.
Тогда дебиан просто не для вас.
По init-скриптам vz* - убедитесь, что там действительно не локальные изменения.
Апач запросто можно использовать в качестве прокси, как и nginx. В т.ч. и кеширующего прокси.
В использовании nginx есть плюшки (выливающиеся в экономии памяти, в среднем) - не из-за nginx'а самого по себе (роль nginx-а перед апачем с блеском выполнит другой апач ;)) - а из-за другой структуры хостинга.
В принципе, своп - только один вариант, приводящий к mismatch_cnt != 0 в "нормальной" ситуации.
Отключите swap или /proc/sys/vm/swappiness поменьше сделайте. repair & check - и посмотрите что будет.
Покажите. Любопытно понаблюдать, что Вам подскажут местные "специалисты".
Давайте последний раз определимся.
Это у Вас сразу после repair & check? Или только по прошествии сравнительно продолжительного времени после? Если последнее - то волноваться особо точно нет причины, это именно ситуация, описаная в баге.
