DOS запрос одной страницы. Как вычеслить.

Если запрашивают одну страницу с сайта, но очень много раз, то довольно легко по логам посмотреть с какого ip это делают и прибить, если конечно делают с одного адреса.

Смотрим по логам кто у нас много запрашивает
tail -n 5000 /var/log/httpd/access.log | awk '{print $1}' | sort | uniq -c | sort -rn

Получим на выходе список адресов с которых заходили с количеством обращений.
Конечно нужно уточнять расположение логов.

Тоже самое делаем когда используется прокся - парсим, выделяем адрес ( в логах сквида выделяем awk '{print $3}'), сортируем, баним.


updated:
И вот еще положу на всякий, чтобы было под рукой.
netstat -ntu | awk '{print $5}' | sed -e '1d' -e '2d'|sort | uniq -c | sort -nr |head -n20
netstat -n -p | grep SYN_REC| awk '{print $5}'|awk -F: '{print $1}' | sort -n | uniq -c | sort -nr | head -n1

Очистка кэша.

find /var/www/site_on_cms_with_cache/dir/cache/ -type f -ctime +7 -path .svn -prune -print0 | xargs -r0 rm -fr

Перенос систесы с винта на винт.

Недавно переносил систему с одного жесткого диска на другой. Все сводится к обычному копированию, подправке fstab и установке загрузчика (в моем случае это был grub2).
Сначала делалось экспериментальным способом с гуглом под рукой, с результате чего была найдена статейка, которую я и перенес к себе в вики.
В статейке написано откуда она.
Вот Перенос системы на другой диск

Clearing orphaned inode

При проверке дисков с помощью fsck вылазили сообщения типа:
Clearing orphaned inode 144 (uid=118, gid=127, mode=0100600, size=0)

Почитал здесь : https://bugzilla.redhat.com/show_bug.cgi?id=147748
Там говорится, что это не ошибка, ничего страшного нету, это просто куски файлов, которые использовались в время работы с файлами, но по каким-то причинам небыли удалены после закрытия этих файлов, или не смогли удалиться после сбоя по питанию или перезагрузки компьютера.

Посмотреть список пользователей mysql

SELECT USER from mysql.user;

Включить mysql low log

Включить логирование медленных запросов MySQL
Работоспособность сервера баз данных сильно зависит от типа и количества запросов, которые пытаются выполнить клиентские приложения. Чтобы "отловить" те запросы, которые приводят к большой загрузке, в MySQL встроен механизм журналирования таких запросов. По анализу лога длительных запросов можно определить, какие из них замедляют работу сервера в целом. Но следует учесть, что на этот вид логов большое влияние оказывает загруженность сервера в целом. Если сервер будет перегружен, в этот журнал попадут даже запросы, которые в обычное время считались бы нормальными в плане производительности.

По умолчанию механизм фиксирования длительных запросов не включен. Для того чтобы его включить, следует в строке инициализации демона MySQL указать параметр --log-slow-queries или log-slow-queries = [путь до лог файла], либо же в конфигурационном файле my.ini (my.cnf) указать в разделе [mysqld] параметр log-slow-queries.

Запостил и сюда

Неправильные квоты cpanel

Если не верно работают квоты на cpanel, тоесть неверно просчитаны, то это лечится так:

./scripts/upcp --force

Можно попробывать и без этого.

Сразу запустить

./scripts/fixquotas


признаки такой проблемы: квота на всех акаунтах:unlimited, а Disk Used 0M.

update: как обнаружилось, это не пофиксало до конца квоты.

Пофиксались они гараздо позже выполнением

quotacheck -vguma

А еще нашел такую сборку приятностей, чтобы фиксить данныую траблу там

http://nazeems.wordpress.com/2009/08/03/how-to-fix-cpanelwhm-quota/

1) quotacheck -c /home

2) repquota -a

3) /scripts/fixquotas

4)/var/cpanel/cpanel.config for disablequotacache=0 в /var/cpanel/cpanel.config и потом /scripts/fixquotas