Pull to refresh

Мини-детектив НЕ системного администратора

Reading time5 min
Views14K
Всем привет!

Меня зовут Илья. Я скорее программист и вечный-в-попытках-предприниматель чем системный администратор. Но, как известно, в стартапах ты и косец, и жнец, и на дуде игрец. Поэтому сегодня пришлось поиграть во все роли. Статья сможет помочь таким же как я начинающим администраторам, которые по воле судьбы/службы приходится заниматься сервером.

Пишу с пылу, с жару, часть команд писал по памяти. Буду рад любым корректировкам.

Итак, сегодня утром в 11:35 по минскому времени один из менеджеров написал, что сайты перестали работать. А конкретнее, сыпать ошибками MySQL

Т.к. первоначальной настройкой сервера занимались специалисты хостинговой компании, я сразу же написал запрос им. Но получил от ворот поворот:



Что же, возможно это и не клиентоориентированно, но правильно. Не каждому же клиенту помогать с MySQL. Платной услугой пользоваться не хотелось. Будем сами.

Действительно, при заходе на сайт появлялось неприятное:

SQLSTATE[HY000]: General error: 1 Can't create/write to file '/tmp/#sql_b80_0.MYI' (Errcode: 28 - No space left on device),


На первый взгляд все казалось очень простым — не хватает места на диске, где находится MySQL. Но с другой стороны и удивительным — только вчера на том диске было 40 Гб свободного места.

Подключаемся по SSH, смотрим:

bakharevich@server:/# df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs           60G   17G   40G  30% /
/dev/xvda1       60G   17G   40G  30% /
/dev/xvda3       79G   57G   19G  76% /home/site2.by
/dev/xvda5       69G   36G   30G  55% /home/site3.by

Странно. На диске с БД действительно свободно 40Гб, но MySQL уверенно не хочет запускаться — нет места.

Быстрый поиск в Интернете дал результат — кроме места на диске есть ещё и айноды, которых у нас как раз-таки 0.
bakharevich@server:/# df -i
Filesystem       Inodes   IUsed    IFree IUse% Mounted on
rootfs          3932160 3932160        0  100% /
/dev/xvda1      3932160 3932160        0  100% /
/dev/xvda3      5242880 1122900  4119980   22% /home/site2.by
/dev/xvda5      4587520  801087  3786433   18% /home/site3.by


Т.е. каждый файл, директория и даже симлинк занимают айноду. Где-то в подсознании я безусловно понимал, что такое имеет место быть. Но отсутствие опыта в делах админских/железячных не дало мне сразу же подумать об этом. Хорошо, будем знать! :-) А пока нужно освободить часть айнод, чтобы как можно скорее запустить сайты.

Первое, что я решил удалить, это сессии от PHP. Да, у людей повылетают авторизации, но это не так страшно, т.к. сайты не работают. У нас сессии хранятся на диске. Поэтому:

rm -rf /var/lib/php5/*


А также перенастроить их сохранение на другой диск в php.ini:

session.save_path = "/path/to/new/dir/"


Смотрим, сколько освободили айнод:

bakharevich@server:/home# df -i
Filesystem       Inodes   IUsed    IFree IUse% Mounted on
rootfs          3932160 32928660    3500  100% /
/dev/xvda1      3932160 3932160        0  100% /
/dev/xvda3      5242880 1122900  4119980   22% /home/site2.by
/dev/xvda5      4587520  801087  3786433   18% /home/site3.by


Всего 3500 :-( Но этого может хватить, чтобы запустить MySQL, а значит и временно восстановить работу сайтов.

Пробуем перезапустить MySQL:

bakharevich@server:~$ sudo service mysql start
[ ok ] Starting MySQL (Percona Server) database server: mysqld . . ..


Отлично, сайты заработали! Но количество айнод продолжает уменьшаться. Примерно через 10 минут их снова станет 0.

Продолжаем удалять файлы. Инстиктивно я начал с /var/log/ і /var/cache/:

du --max-depth=1 /var/log/ | sort -n -r
du --max-depth=1 /var/cache/ | sort -n -r


Удалил лишнее. Стало примерно еще 3.000 айнод, но этого естественно все равно очень мало. И вообще, кто мог создать такое количество файлов, чтобы использовать около 1.5 млн айнод?



При дальнейшем поиске увидел папку /var/spool/exim4/input. Exim4 — почтовый сервер, который, как я понимаю, идет вместе с Debian. Попробовал подсчитать кол-во файлов в директории, но результат долго не показывался. Значит файлов там действительно очень и очень много:

ls -l /var/spool/exim4/input | wc -l


Быстрый поиск в Интернете показал, что эта директория для писем в очереди. Гм… Это интересно, потому что ни один из наших сайтов не пользуется локальным почтовым сервером. Все переведено на «Яндекс.Почта для домена» и Google. Ладно, к этому вернемся позже. Пока нужно освободить айноды!

Просто удалять файлы в директории не хочется. Ищем правильное удаление и находим нечто подобное:

exim -bp | exiqgrep -i -f $user | xargs exim -Mrm


Запускаю. Жду некоторое время и понимаю, что айноды не освобождаются. Быстро размышляю, что это скорее всего из-за первой команды exim -bp, которая сначала выводит список писем в очереди. Раз там более 1 млн писем, то и выводить будет долго.

Более того, к этому времени свободные айноды уже закончились. Сайты вновь остановились. Начинают писать менеджеры, приходят одна за одной SMS о неработоспособности сайтов, звонит телефон… Обстановка накаляется. Ладно! Придется действовать жестко. Удаляем напрямую:

rm -rf /var/spook/exim4/input/*


Но не тут-то было. Айноды не высвобождаются. Удаляются ли файлы тоже не могу посмотреть — объем более миллиона не позволяет их быстро подсчитать. Скорее всего, rm * тоже сначала читает всю директорию, а потом уже начинает удаление.

Ладно, пробуем более жесткий вариант:

rm -r /var/spool/exim4/input/


… и наконец-то айноды освобождаются тысячами. Чувствую, что победил в небольшой битве, но враг ушел в лес для перегруппировки и еще одной атаки примерно через месяц :-) Надо наступать дальше.

Уже более спокойный и рассудительный, начал смотреть логи exim. Сначала ничего интересного… как вдруг нечто подобное:

2015-07-31 13:58:41 1ZIwuU-0007a9-Rm ** joan_galloway@site.by R=dnslookup T=remote_smtp: retry time not reached for any host after a long failure period
2015-07-31 13:58:41 1ZIwuU-0007a9-Rm joan_galloway@site.by: error ignored
2015-07-31 13:58:41 1ZIwuU-0007a9-Rm Completed


Интересно! Как я уже писал, мы не пользуемся локальным почтовым сервером. Более того, site.by — не наш. Мы просто его временно размещаем на нашем сервере. Чем он занимается никому не известно.

Смотрю структуру сайта:



Что-то знакомое. Посмотрим index.php:



Ага, Joomla! Причем от 2013 года. Наверное воспользовались уязвимостью старых версий.

С большой надеждой, что сайт не очень популярный, открываю логи-вебсервера, чтобы найти что-то подозрительное. Сразу делаю поиск по email «joan_galloway», который был найден в логах exim. Но ничего нет… Ищем дальше. Запросы картинок, файлов стилей… И вдруг:

50.62.177.108 - - [31/Jul/2015:14:37:41 +0300] "POST /components/com_weblinks/views/categories/system.php HTTP/1.1" 404 2056 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.6)"


Очень интересно! Некий файл system.php. Был POST запрос, поэтому параметров запроса не видно в адресе. Название очень подозрительное. Когда-то в детстве у меня тоже была такая директория на домашнем компьютере :-)

Смотрим сам файл:



Понятно! Враг найден. Изменяем название файла и в логах exim наступает снова тишина. Наконец можно притронуться к еде, которую будущая жена поставила около меня минут 10 назад :-)

Далее будет допрос заключенного:

— каким образом попал на сервер?
— есть ли сообщники на других сайтах/директориях?

А также нужно разобраться на нашей территории:

— проверить права к папкам
— кроме автоматической проверки свободного места настроить проверку свободных айнод
— настроить exim (например, заблокировать SMTP).

Наверное, необходимо что-то еще. Буду рад комментариям/исправлениям/историям из вашей практики.

Надеюсь, кому-то статья покажется полезной.

Спасибо за внимание!
Tags:
Hubs:
Total votes 28: ↑15 and ↓13+2
Comments29

Articles