Обычно наоборот : взрослый программист скорее активно использует чужую работу, чем потратит время на скучную реализацию вебшелла. Но сейчас сканеры по сигнатурам типа lmd и ai-bolit мешают это делать. Только ради этого самописные шеллы будут использоваться. А выводов о взломщике по-прежнему никаких сделать нельзя.
Тоже ни о чем не говорит.
Я думаю, это потому что ваши сайты взламывали не целенаправленно, а находили в гугле уязвимость и заливали свой шелл. Несколько взломщиков каждый со своим почерком и шеллом.
ШАНС-ON, реально непонятно какой ответ вы хотели получить.
Ну да, если в коде забит пароль и подобные функции, то это скорее webshell, чем модуль для удобного администрирования и устранения проблем.
Дальше-то что ? В чем будет ваш вывод ? Байты не пахнут. Шелл - это шелл. Ничего из этого не следует.
Сильно переоцениваете доброту Яндекса. Я полагаю, этим все и закончится.
Вот можете посмотреть комментарии на Хабре и стиль ответов : кому не нравится - берите и делайте сами, исходники открыты.
Тут нет прямой выгоды Яндексу, а значит нет бизнеса, нет вложенных ресурсов, нет поддержки и качественного кода на выходе. Просто типичный популизм от Яндекса : вот, посмотрите же, мы заботимся о вашей безопасности. Даже скооперировались и взяли у автора ai-bolit несколько идей, поручили штатным программистам-питонщикам родить абы-какой аналог.
Все неправильно поняли. Просто сделайте как на картинках по моей ссылке .
Точка монтирования для /boot должна быть одна и на устройстве с raid.
Но еще нужно по одному разделу на каждом из дисков с типом раздела ef02 - BIOS boot partition. Так нужно для загрузки с UEFI и GPT. Именно на это ругается grub.
В такой ситуации для GPT на диске sdb нужен еще BIOS boot partition. Причем, инсталлятор настоял на создании такового на sda, на sdb вы забыли. И зря.
Зачем вы вообще создали /boot, /boot2 и вообще два диска с разным разбиением ?
Если делаете резервирование - то надо и резервировать каждый раздел.
Все же, случаи могут быть разные. Вы не привели полную информацию. Так что посоветую просто с самого начала переустановить и вручную разбить каждый диск на одинаковое число разделов одинакового размера. При этом на каждом должен быть по bios boot partition по 1 мб.
Потом собрать несколько массивов raid1. Выбрать /boot поверх raid1 и корневой тоже поверх raid1.
Вот тут вроде неплохо картинки выглядят http://stackful-dev.com/raid-install-ubuntu-server-on-a-large-hard-drive.html.
По-моему, в ubuntu инсталлятор просто спрашивает на какие из дисков загрузчик записать, а debian это вручную делать надо.
Кстати, в современных debian не обязательно делать /boot отдельным разделом. Grub2 научился грузиться откуда попало. С одним разделом попроще будет.
zexis, это типа юмор такой. Вы пишете "автоматически отключать", а потом ниже выясняется, что на самом деле это означает "две недели подбирать пороговые значения без сна и отдыха" . И еще по мере роста сайта периодически возвращаться к этой проблеме.
Так что некоторым такая автоматика не нужна.
coolmans, и все же лучше найти админа. Он посмотрит, конечно же ничего не сделает, возьмет денег, но вы все равно будете довольны. Потому что проблем то никаких у вас нет.
Mister_Black, нууу так может быть настало время завести мониторинг, чтобы видеть когда бекап слегка вмешивается, а когда запросы действительно мешают нормальным пользователями ? Для начала рекомендую munin.
Так же почитайте как и почему пользоваться pt-query-digest . Это позволит сосредоточиться на действительно важных запросах.
Конечно, запрос с характеристикой Rows_examined : 338874 наверняка проблемный и им стоит заняться. Но вы же хотели чтобы вам объяснили парадокс : запрос вроде исправляется, но становится только хуже. Вот я объяснил.
Недостаточно внимательные измерения.
Совпадения и сделанные из них неверные выводы.
Суждение только лишь по одному логу медленных запросов не принимая к сведению другие параметры и такие возможные варианты, как запуск бекапа ночью.
Расстрэлят.
Бизнас держится на доверии. Т.е. читай как на суеверии.
А между тем, отметим, что форум searchengines, использующий cloudflare (вот уже год?) пока пользователей не растерял.
Не собираюсь оспаривать высказывания от людей предлагающих услуги антиддос. Просто предоставляю читающему тему дополнительные факты.
