А у меня один вариант - Вам еще рано предлагать варианты... Трепитесь меньше - учитесь больше.
Исправление:
chmod a-x /etc/grub.d/README
PS: Ubuntu не самый лучший вариант для сервера. Если у Вас осталась возможность выбора - я рекоммендую Вам Debian.
Ограничить использование памяти кем? Бекапом - так почти наверняка память забивают какие-нить апачи, которые ждут отработки SQL-запросов к базе, которые лочит бекап. Так что бекап ограничивать глупо. Нужно думать - как в Вашем случае организовать его так, чтобы он отрабатывал быстро. Может структуру базы сменить, тип таблиц, метод бекапа (например два mysql сервера и бекапить со slave) и т.п.
Королев. фон Браун. По чертежу взлетали ракеты только уже у бойцов рангом поменьше (и то - не всегда)... Когда технологический процесс был отлажен до мелочей.
Чем, например? Она для решений типовых задач. Как Вы думаете - какие типовые задачи будут в Вашем случае?
Нет, и не предвидится. Все подобные решения ориентированы на защиту от школьников. Т.е. есть вполне конкретные (и несложные) векторы атаки, от которых так не защититься в принципе.
Второй момент - сложность таких решений. DDoS - это просто много запросов с разных IP. Если атакующий немного постарается - эти запросы могут быть практически неотличимы от обычных обращений клиентов. Сравнительно просто защититься от конкретной атаки - но крайне сложно защититься от любой.
Соответственно, Вам нужно либо досконально разбираться во всем (уметь написать свое антидос решение и модифицировать его по обстоятельствам) - либо забыть про технические детали о обратиться к специалистам.
Картина маслом - Битва титанов. (Швыряются какашками с утра)
Да уж на что угодно - как раз таки можно не думать.
Ну, потому что непонятна.
Что мне "подтверждать" - Вы не в состоянии найти список CVE по уязвимостям PHP?
Ну, чуть раньше и про mod_security ;) Safe mode - еще более-менее разумно.
Откуда Вы узнали, что не через FTP? Очень похоже.
Ну так и пишите. А то "Отключить шелл в PHP" - и поди пойми что этот дзен значит. (Конечно, все эти меры не приведут к неработоспособности шелла - да и определенная вероятность "выйти" за пределы конкретного виртуалхоста имеется. Openbasedir еще тот фиговый листочек...)
Порождая с десяток новых (если Вы про mod_security).
Да нет, конечно. Если Вы не овладели простейшим опытом "научись читать штатную документацию" - грош этому "опыту" цена.
Помойка, иными словами. В минутах лучше измеряйте время обновления этой "конфигурации" при смене версий.
Пакетами можно сделать куда больше.
Ну так Вы объясните на сайте - какое конкретно у Вас установлено ПО и почему.
Вы предусмотрели такой вариант решения как временная аренда сервера в своем ДЦ?
Оценили сколько это займет по времени (с технической стороны - порядка получаса, плюс бюрократические проволочки у хостера)?
Что еще за "зона A"? Если Вы про IN A записи в ДНС - так поставьте TTL поменьше просто. Многие крупные хостеры ставят по 15 минут и менее.
Так что, если хорошо сперва подумать (больше даже над организационными моментами) - даунтайм в случае полного отказа сервера сводится к времени порядка получаса (вынимаем диски из Вашего сервера и вставлем в другой). Насколько это неприемлемо?
Что касается ISP Cluster - тут, имхо, если и делать - что что-то куда более простое и ориентированное на конкретно Ваш продукт. Минимум, на порядок дешевле будет. ISP для одного магазина - вообще лишний.
Если не ограничиваться одним ДЦ - не перебор.
Приведенная Вами ошибка вряд-ли как-то связана с reload'ом. Просто бакенд медленно отвечает - нужно смотреть и разбираться почему.
