Биллинг они своровали в webnames, панель хостинга у них ISPmanager/cPanel (честно купленные).
bugsmoran добавил 23.06.2010 в 21:50
Igoron, Вы мне написали, что я тролль в личку, но если я тролль, а на самом деле Вы белые и пушистые, тогда пожалуйста ответьте лично на этот пост, а я посмотрю, как тут можно выкрутиться:
ТЫЦ
И, честно говоря, не уверен, что он еще стабильно работает. Он еще не успел войти в моду.
ULThost, это ни в коем случае не травля, а просто предложение все-таки поменять mod_php на mod_fcgid или, если рисковый характер, mpm_prefork/mpm_worker на mpm_itk.
Dimanych прав на все сто. mod-php - смерть от форк-бомбы как минимум. А еще можно выдолбить ошибку у соседа по сайту, и увидеть путь к его сайту на диске, а там естественно либо хозяин апач, либо права 777 (по другому не работает mod-php). Все, файлы соседа уничтожены.
Короче mod-php, это когда уничтожение хостинга становится лишь вопросов фантазии, а если на CentOS, так еще и ограниченное количество утилит по мониторингу, так как система ретроградная.
а я бы не приходил даже изначально :-D
А как переносил то? Разве такое всплывет, если в tar закатать, а потом на новом сервере разархивировать?
LeaderHost
Logol
Хм... а кто тогда ведомый, если этот уровень - ведущий? И почему при самых быстрых базах такой уход? Клиентов силой ротационной инерции выкидывает? )))
Ну потому что остались еще cgi-дети, которые обрабатывают остатки php. Не надо после поднятия первого резко ломиться класть второй. Можно покурить и уже потом класть. Тогда все ок. А так то можно что угодно положить. Можно например с МиГ-29 уложить ракету в сервер - тоже гарантированно ляжет, но зачем?
bugsmoran добавил 23.06.2010 в 02:38
Впрочем это оффтоп, а сегодня у меня был положительный опыт общения с саппортом ИСП.
Причем я заметил, что меня сегодня отправляли только в BillManager guru (раньшене замечал такой отдел). Вообще никаких проблем. Быстро и четко сработали.
Вывод: хотите получить нормальный саппорт в ИСП - обходите гемба всеми правдами и неправдами. Там глубже зарыты нормальные сотрудники.
Я не только тестировал, у меня вообще такой хостинг))
Если Вы поднимаете первый апач, а второй кладете потом, то 502 откуда? Второй - бэкэнд. Более 90 секунд не может отработать ни один его форк (ну если так настроено в php.ini), а новые все идут на основной. Так через 91-у секунду можно смело его класть - никто не заметит.
Кроме того, зачем ребутать вообще апач? Есть reload - вполне достаточно, чтобы перечитать конфиг.
Так точно. Учитывая, что перегрузить Апач просто невозможно, потом что он не обрабатывает PHP, а передает работу в FastCGI-процесс. А FastCGI невозможно физически перегрузить, потому что срабатывает ограничение на CPU и RAM (не буду говорить какие и как реализовано из соображений корпоративных секретов). Сервер в принципе не возможно ну никак перегрузить. Можно только сломать конфиг Апача, а единственный, кто его трогает...
Я очень рекомендую переписать ISP-шникам работу с инит-скрптами и вставить конфигтесты и выкаты с бэкапа если что не так пойдет. Это пять строчек кода, не так уж и сложно.
А зачем планово перегружать Апач, если он не кушает память? А форки сами рестартятся по истечении количества MaxRequestPerChild запросов. А вот в reg.ru например вообще висит два Апача, а у Nginx в конфиге:
http { upstream backend { server aaa.bbb.ccc.ddd:8080; server aaa.bbb.ccc.ddd:8090 backup; }}
и все. Проблема 502 не существует)))
У меня нету двух апачей. но у меня и нету в инит-скрипте restart, а есть только reload, stop и start. Поэтому рестартовать Apache силами ISPmanager после добавления виртхоста не получится.
Тогда надо использовать все в своих целях)))) men in the middle - наше все. Такого "найти" директору, что бы он сам уволился пока его не посадили.
