Идея к размышлению. Если порт забивают полностью так, что не достучаться, можно попросить хетцнер дать квм и занулить все ай-пи. Из квма наружу доступ вроде будет при этом, поэтому можно будет запустить бекап на удаленный сервер. Не очень удобно, но за неимением лучшего варианта, можно попробовать хоть так. К тому же и доступ на сервер появится и там хоть можно будет глянуть какой ай-пи досят собственно говоря.
Косяк №2 - не косяк. Следует понимать, что на виртуальном хостинге как правило используется операционные системы Linux/FreeBSD и подобные. Ваш аккаунт для этой системы - один. Независимо от того, сколько у вас сайтов натыкано в один аккаунт. В этом и есть проблема обычных мультидоменных тарифных планов - ломают один сайт, а заблокируют если что все сразу. По простой причине. Раз сломали один сайт, значит злоумышленник получил доступ ко ВСЕМУ вашему аккаунту (для системы вы один единственный юзер с полным доступом к вашей домашней директории). Следовательно, заблокировать доступ к одному сайту недостаточно и необходимо заблокировать весь аккаунт пока клиент не очухается и не начнет работать над устранением ошибок. Иначе, рассылка спама, ддос боты и прочие гадости. И все это будет делаться со скомпрометированного вашего аккаунта который использует ай-пи общий с еще тучей других сайтов других клиентов. Через довольно короткое время, ай-пи, в случае непринятия немедленных мер, попадает в тучу блок листов, некоторые из которых вообще не публичны и/или не имеют формы делистинга. Такое происходит каждый божий день и ваш случай далеко не уникален, так же как не уникальны подобные посты.
Что касается писем. Ну неужели вы думаете, что даже школохост будет имитировать отправку писем вам? Я уж не говорю о профессиональных хостерах. Вот спят они и видят как вам письмо не отправить и заблокировать ваш аккаунт. Господа клиенты, почта работает отвратно к сожалению и это мало зависит от хостера. Разного рода контент фильтры срабатывают хрен знает на что и добиться того, чтобы гугль скажем не клал письма в спам папку - это поседеть можно. А ведь этим занимается не только гугль и не только в какой-то конкретный день. Вполне может случится, что вам пошлют сообщение от спамкоп о том, что с вашего сайта слали спам, хостер пересылает вам уведомление, а контент фильтр вашего мейл сервиса его рубит. И что прикажете делать хостеру, тем более что обычно письма обратно не возвращаются и только по логам можно понять почему письмо было отвергнуто да и то не всегда. Так что не надо гнать на хостера по пустому.
По пункту 1 единственно, что могу сказать: не так давно пришлось перейти на апач 2.4 и в связи с изменениями которые были внесены разработчиками приходилось вносить некоторые изменения в .htaccess файлы. И после этого обнаружились проблемы у пары клиентов у которых запрет к файлам был реализован неправильно. Поэтому автоматические скрипты перехода на новую версию не смогли их правильно сконвертировать. Как только клиенты обратились, директивы были исправлены и сайты заработали штатно. В посте ТС я услышал (простите, если мне показалось), отголоски мифа о том, что файлы клиента - это святое и хостер не имеет права их читать, редактировать и т.п. Но это только миф. В случае, если у хостера возникают обоснованная необходимость исправить или заблокировать доступ к какому-то файлу у пользователя - он это сделает. Самый типичный пример - антиспам решения. Другой пример - поиск троянов и вирусов на аккаунте клиента. При этом если будет обнаружен вредоносный файл, он будет перемещен в карантин. Само собой клиент будет об этом извещен, но это будет уже после перемещения. Альтернатива таким действиям - полная блокировка аккаунта. Виртуальный хостинг весь состоит из компромиссов и это надо понимать.
вероятно надо теперь по юзерам раскидать бинарник пхп. тоже, видимо, испманагер сбойнул. в папках /var/www/username/php-bin вроде должен лежать он. владелец и группа должны быть юзера. бинарник должен называться просто php и иметь права 755.
В свойствах юзера разрешение есть использовать пхп как цгий?
php как cgi работает медленнее модуля. php-fpm или даже такой зверь как itk практически с такой же скоростью работает как и модуль.
ScriptAlias /local-bin /usr/bin а зачем?
Для юзера пхп то включен? И у него еще должен быть разрешен пхп как цгий.
А в возможностях отображается 5.4 пхп? Можно еще с командной строки проверить - на месте ли пхп 5.4 в цгий версии и если да, не дает ли он каких нибудь ошибок при запуске. К примеру, так примитивно можно проверить: путькпхп/php-cgi -v Если ругнется, то лечить. Потом проверить, а какой файл живет у пользователя в папке php-bin. Может там не тот пхп. Если везде все лежит и работает 5.3, то смотреть хандлеры остается. ISPmanager иногда конфиги просто не убивает до конца или, наоборот, не создает. Можно еще попробовать включить/выключить пхп - может поможет.
ну тогда вероятно это происходит из-за того, что вы через дочку апача запускаете процесс пхп и дочка эта убивается по таймауту апача. теорию не подведу под это (почему в пхп как модуль апача этого не происходит), но для парсера яндекс маркета нам приходилось увеличивать именно таймаут апача в режиме использования пхп как цгий. так что это не нечто уникальное и не связано именно с вашими настройками.
Случайно это не грабер чего-то типа яндекс маркета?
VPS от leaseweb:
1 Гб памяти, 40 Гбт диск (SAN Storage, RAID 10), 1 Гбит порт, 500 Гбт премиум трафик.
https://euro.rustelekom.net/manager/billmgr?func=register&welcomfunc=vds.order&welcomparam=price=2609&project=3
7 евро.
Бекап в другую страну: NAS 100 Gb ftp/rsync/ssh/nfs Unmetered traffic 150 рублей.
надо у юзера видимо. сделайте страничку с phpinfo и проверьте действительно ли таймаут поменялся для скриптов которые от юзера запускаются. max_execution_time=86400 по идее должно хватить. Еще можно прибавить столько же для max_input_time. Еще может быть default_socket_timeout прибавить и или mysql.connect_timeout если парсер пытается загрузить много данных в базу.
