Лучше объяснить саму задачу, потому что я Вам гарантирую, что Вы чешете правой рукой левое ухо. Придумали неграмотное решение. Возможно нам бы удалось придумать грамотное, но поясните изначальную цель такого скрипта.
Кстати у nginx есть таймауты. Он не будет вечно ждать Apache. Как выглядит преждевременный обрыв работы скрипта? Не 504 случаем?
firstman: Глупости. Вы же не одежду выбирайте, чтобы это было дело вкуса.
Незнай незнай... эргономику врядли можно очками посчитать.
firstman:
А в хостинге разве юзабилити главное?
Для клиента да. Эргономика + функциональность = юзабилити.
Хотя Raistlin что-то переборщил с деферамбами Плеску :)
firstman:
Мы пересели на ISP - первый день очень грустно было именно от простоты интерфейса.
Но зато так легко стало:
1) Нет проблем с доступом к папкам (без этого нет нормального хостинга) 2) Нет проблем установкой на FreeBSD 3) Нет проблем с резервным копированием (без этого нет нормального хостинга)
Есть. Катастрофические. Примерно 10% пользователей не получают нормальные бэкапы.
firstman:
4) Нет проблем с php.ini
Во-первых есть, во-вторых панели они не касаются. Она не виновата. Как и все другие. PHP.INI и панель не коррелируют.
firstman: 5) SSH доступ как у людей 6) Распаковка архивов без проблем (без этого нет нормального хостинга)
Попробуйте разархивировать крупный архив - не получится. Попробуйте понять почему не разархивируется битый архив - будет сто лет думать и ничего не скажет, а просто втихаря покажет все как и было.
coolvds: даже если в топике столько страниц недовольства и батталий, всё равно все кто юзал продукты ispsystem будут их юзать дальше. Единицы начнут писать своё аналогичное ПО, но основная масса будет возмущаться, давиться и пользоваться продуктами ispsystem просто из-за того, что очень удобные условия маркетинга. Понимая это ispsystem не сильно суетиться решать проблемы.
Грандиозно. Каждый на основе ничего уже точно знает, что произошло, а самое главное, кто виноват.
ClockWorkOrange:
Собственно, вопрос. Как выяснить Ddos это или нет?
По многим параметрам. Каждый тип DDoS оставляет свои след.
Например HTTPGet резко увеличивает access-логи nginx/apache2. Попробуйте посмотреть как быстро они увеличиваются.
Slow Loris держит много коннектов максимально долгое время. А значит в netstat будет огромное количество процессов в состоянии Established.
SYN Flood будет в том же netstat оставлять жуткое количество SYN_*.
А возможно у Вас MySQL наружу выставлен, тогда mysql -p -e "show process_list;" покажет кучу одинаковых процессов с долгим временем.
Но факт один: к выводу, что на машину идет DDoS приходят не по цепочке "а вдруг дос?"->"дай проверю!"->"точно дос!", а по такой: "нихрена не работает"->"дай найду, что именно..."->"большая нагрузка на Nginx, логи читать не возможно - летят как сумасшедшие"->"очевидно, что это DDoS типа HTTP Flood".
Romka_Kharkov: Да хоть 1954-й, он что от этого плохо работает? Меня например дико смущает выход обновлений к софту раз в неделю.... это говорит том, что софт блин патчить и патчить.... т.е он сырой и сырой, а я вот пользуюсь qmail, да 98 года релиза... и что ? Софт то нормальный, уязвимостей нет известных что бы так вот взять и наломать мне qmail ? в чем проблема? В том что исходник датирован 98м годом и все? Так этого кроме нас с вами и Химико вообще мало кто знает ;) Но это разве мешает успешно применять qmail ? В общем не аргумент!
Как так не аргумент? Сегодня Qmail - набор патчей, скопившихся за 12 лет. Патчи тем отличаюся от единого релиза, что не протестированы между собой. Закрывая один баг, уже вылазиет другой от конфликта с другим патчем. А если вспомнить, что про Qmail патчи пишут все, кто ни попадя, то картинка становится совсем угрюмой.
Кроме того, Qmail исповедует архитектуру "все через очередь". В результате она забивается бонсами и все становится еще хуже. Нету такой проблемы у Postfix.
Himiko: Мне вот, как админу хостинга, приходится и искать ошибки в скриптах клиентов, смотреть и подсказывать по MySQL-запросам, исправлять глюки в модулях кеширования движков.
Это, конечно, совсем не задачи хостера.
В случае с Himiko это, скорее всего, действительно его задачи. У него VIP-хостинг. Соответственно широкий набор всяких подобных плюшек. VIP-услужливость за VIP-деньги. Но это, конечно, частный случай, к происходящему отношения не имеющий. И уж совсем не показательный.
Потому что если админ вынужден помогать разработчику, то это такая же вина разработчика, как в случае с hosts вина админа перед разработчиком. Получается, что все делают за всех. Бардель какой-то. Натуральное хозяйство.
А все же расскжите суть задачи. Чтобы по грамотному ее решить.
Лучше объяснить саму задачу, потому что я Вам гарантирую, что Вы чешете правой рукой левое ухо. Придумали неграмотное решение. Возможно нам бы удалось придумать грамотное, но поясните изначальную цель такого скрипта.
Кстати у nginx есть таймауты. Он не будет вечно ждать Apache. Как выглядит преждевременный обрыв работы скрипта? Не 504 случаем?
Глупости. Вы же не одежду выбирайте, чтобы это было дело вкуса.
Незнай незнай... эргономику врядли можно очками посчитать.
А в хостинге разве юзабилити главное?
Для клиента да. Эргономика + функциональность = юзабилити.
Хотя Raistlin что-то переборщил с деферамбами Плеску :)
Мы пересели на ISP - первый день очень грустно было именно от простоты интерфейса.
Но зато так легко стало:
1) Нет проблем с доступом к папкам (без этого нет нормального хостинга)
2) Нет проблем установкой на FreeBSD
3) Нет проблем с резервным копированием (без этого нет нормального хостинга)
Есть. Катастрофические. Примерно 10% пользователей не получают нормальные бэкапы.
4) Нет проблем с php.ini
Во-первых есть, во-вторых панели они не касаются. Она не виновата. Как и все другие. PHP.INI и панель не коррелируют.
5) SSH доступ как у людей
6) Распаковка архивов без проблем (без этого нет нормального хостинга)
Попробуйте разархивировать крупный архив - не получится. Попробуйте понять почему не разархивируется битый архив - будет сто лет думать и ничего не скажет, а просто втихаря покажет все как и было.
даже если в топике столько страниц недовольства и батталий, всё равно все кто юзал продукты ispsystem будут их юзать дальше.
Единицы начнут писать своё аналогичное ПО, но основная масса будет возмущаться, давиться и пользоваться продуктами ispsystem просто из-за того, что очень удобные условия маркетинга.
Понимая это ispsystem не сильно суетиться решать проблемы.
+100000000000000000000
QFT
Грандиозно. Каждый на основе ничего уже точно знает, что произошло, а самое главное, кто виноват.
Собственно, вопрос. Как выяснить Ddos это или нет?
По многим параметрам. Каждый тип DDoS оставляет свои след.
Например HTTPGet резко увеличивает access-логи nginx/apache2. Попробуйте посмотреть как быстро они увеличиваются.
Slow Loris держит много коннектов максимально долгое время. А значит в netstat будет огромное количество процессов в состоянии Established.
SYN Flood будет в том же netstat оставлять жуткое количество SYN_*.
А возможно у Вас MySQL наружу выставлен, тогда mysql -p -e "show process_list;" покажет кучу одинаковых процессов с долгим временем.
Но факт один: к выводу, что на машину идет DDoS приходят не по цепочке "а вдруг дос?"->"дай проверю!"->"точно дос!", а по такой: "нихрена не работает"->"дай найду, что именно..."->"большая нагрузка на Nginx, логи читать не возможно - летят как сумасшедшие"->"очевидно, что это DDoS типа HTTP Flood".
То есть Вы пошли не с того конца.
Пробую, конечно. Просто 503-ю не всегда удаётся вызвать. Если только досс заказать)
Чат на аяксе сделайте - моментально получите. Форк бомбу через PHP, запускаемую с браузера - тоже вариант.
535gtr,
Сообщения: 1
Репутация: 10
Еще один... зарегался, чтобы сразу броситьс в защиту хостера. Настоящий мужик!
Да хоть 1954-й, он что от этого плохо работает? Меня например дико смущает выход обновлений к софту раз в неделю.... это говорит том, что софт блин патчить и патчить.... т.е он сырой и сырой, а я вот пользуюсь qmail, да 98 года релиза... и что ? Софт то нормальный, уязвимостей нет известных что бы так вот взять и наломать мне qmail ? в чем проблема? В том что исходник датирован 98м годом и все? Так этого кроме нас с вами и Химико вообще мало кто знает ;) Но это разве мешает успешно применять qmail ? В общем не аргумент!
Как так не аргумент? Сегодня Qmail - набор патчей, скопившихся за 12 лет. Патчи тем отличаюся от единого релиза, что не протестированы между собой. Закрывая один баг, уже вылазиет другой от конфликта с другим патчем. А если вспомнить, что про Qmail патчи пишут все, кто ни попадя, то картинка становится совсем угрюмой.
Кроме того, Qmail исповедует архитектуру "все через очередь". В результате она забивается бонсами и все становится еще хуже. Нету такой проблемы у Postfix.
Тут согласен, постфикс тоже не плох, но что вам не нравиться в qmail ?:)
Stable release 1.03 / June 15, 1998; 12 years ago
Вспоминается фраза из фильма Snatch:
"Все нормально, Тони, все тип-топ. Я только не совсем уверен с выбором цвета"
Маленький оффтоп:
Мне вот, как админу хостинга, приходится и искать ошибки в скриптах клиентов, смотреть и подсказывать по MySQL-запросам, исправлять глюки в модулях кеширования движков.
Это, конечно, совсем не задачи хостера.
В случае с Himiko это, скорее всего, действительно его задачи. У него VIP-хостинг. Соответственно широкий набор всяких подобных плюшек. VIP-услужливость за VIP-деньги. Но это, конечно, частный случай, к происходящему отношения не имеющий. И уж совсем не показательный.
Потому что если админ вынужден помогать разработчику, то это такая же вина разработчика, как в случае с hosts вина админа перед разработчиком. Получается, что все делают за всех. Бардель какой-то. Натуральное хозяйство.