Никто из уважающих себя хостеров - _ee_ себе не поставит. Массовый
виртуальный хостинг - совершенно другая ниша, там свое пишут.
Про то как управлять ftp доступом - написано на их сайте. ftpaccess для proftpd никто не отменял.
Там, блин, все написано. Вам можно использовать аналогичное задание, только
путь нужно поменять на Ваш каталог /some/where/in/var/www/.../mod-tmp
Vincent_, логика интересная: взять и запустить на системе под root скрипт,
содержащий ключевые слова. _Не читая его_.
Ибо если бы прочли - сразу было бы понятно, на чем он затыкается. Дергает
какие-то старые нерабочие URL на предмет нужных ему файлов.
В чем проблема поправить порт под себя? Если Вам под 5.2 нужно (судя
по скрипту :D): http://www.php-fpm.org.ua/freebsd-port-php5-fpm
А вообще - инструкции по сборке есть на сайте ;)
При "лазании" на сайт разработчика зайти не пробовали?
Раз так уверены, что проблема в размере заголовков - помогут
директивы client_header_buffer_size и large_client_header_buffers.
Если Вас досят - это скорее всего одино из проявлений ddos. И не обязательно,
что именно из-за прерывания запроса файерволом. Отключите блокировку - посмотрите
в лог через некоторое время, ну зачем тут сниффер :).
А если ничего больше о DDoS не свидетельствует - нужно дальше копать. Почему такое
может быть с нормальным клиентом - я привел пример выше.
Весьма разумная мысль :D. Видимо, не все еще потеряно...
Скорее всего, бот очень быстро закрывает соединение, не дождавшись ответа
от сервера. Например, http://sysoev.ru/nginx/docs/faq.html#econnaborted - т.е. нормальные
клиенты вполне такое могут вызвать.
Выставите подходящий уровень логгирования в nginx - узнаете подробнее.
Скорее всего, в вашем случае будет что-то
типа "client closed prematurely connection while reading client request line".
в /etc/cron.d/php5 - пример подобного крон-задания (только каталог там /var/lib/php5/)
Куда летит?
Рискну предположить, что с каталогом хранения сессий вы
наблюдаете какие-то проблемы. Может очищать старые сессии
по крону нужно? Я сталкивался с тем, что на Debian по меньшей
мере - "чудо" под названием ISPManager этого не делает.
Из-за кучи старых сессий могут возникнуть ощутимые
"тормоза" движков сайтов.
tcpsnfbuf растет в failcnt - это плохо, но не фатально для
приложений, отказа соединений не будет. т.е. причина ошибки
с ftpd - определенно не в этом.
Кстати, да. Ходить из _локально_ по HTTP за статикой или
подключаемыми файлами - не лучшая идея. И вполне вероятно
внесло большую лепту в проблему.
ТС не пробовал по нетстату сравнить пропорцию созданных с сервера локальных
соедиений (с IP сервера на IP сервера) со всем остальным?
просто умрут по SIGSEGV.
на сами воркеры это лимит не подействует - там нужно
либо средствами расширений апача ограничения
ставить (memory_limit для mod_php) - либо ulimit в init скриптах.
