Всем привет!
Меня зовут Илья. Я скорее программист и вечный-в-попытках-предприниматель чем системный администратор. Но, как известно, в стартапах ты и косец, и жнец, и на дуде игрец. Поэтому сегодня пришлось поиграть во все роли. Статья сможет помочь таким же как я начинающим администраторам, которые по воле судьбы/службы приходится заниматься сервером.
Пишу с пылу, с жару, часть команд писал по памяти. Буду рад любым корректировкам.
Итак, сегодня утром в 11:35 по минскому времени один из менеджеров написал, что сайты перестали работать. А конкретнее, сыпать ошибками MySQL
Т.к. первоначальной настройкой сервера занимались специалисты хостинговой компании, я сразу же написал запрос им. Но получил от ворот поворот:
Что же, возможно это и не клиентоориентированно, но правильно. Не каждому же клиенту помогать с MySQL. Платной услугой пользоваться не хотелось. Будем сами.
Действительно, при заходе на сайт появлялось неприятное:
На первый взгляд все казалось очень простым — не хватает места на диске, где находится MySQL. Но с другой стороны и удивительным — только вчера на том диске было 40 Гб свободного места.
Подключаемся по SSH, смотрим:
Странно. На диске с БД действительно свободно 40Гб, но MySQL уверенно не хочет запускаться — нет места.
Быстрый поиск в Интернете дал результат — кроме места на диске есть ещё и айноды, которых у нас как раз-таки 0.
Т.е. каждый файл, директория и даже симлинк занимают айноду. Где-то в подсознании я безусловно понимал, что такое имеет место быть. Но отсутствие опыта в делах админских/железячных не дало мне сразу же подумать об этом. Хорошо, будем знать! :-) А пока нужно освободить часть айнод, чтобы как можно скорее запустить сайты.
Первое, что я решил удалить, это сессии от PHP. Да, у людей повылетают авторизации, но это не так страшно, т.к. сайты не работают. У нас сессии хранятся на диске. Поэтому:
А также перенастроить их сохранение на другой диск в php.ini:
Смотрим, сколько освободили айнод:
Всего 3500 :-( Но этого может хватить, чтобы запустить MySQL, а значит и временно восстановить работу сайтов.
Пробуем перезапустить MySQL:
Отлично, сайты заработали! Но количество айнод продолжает уменьшаться. Примерно через 10 минут их снова станет 0.
Продолжаем удалять файлы. Инстиктивно я начал с /var/log/ і /var/cache/:
Удалил лишнее. Стало примерно еще 3.000 айнод, но этого естественно все равно очень мало. И вообще, кто мог создать такое количество файлов, чтобы использовать около 1.5 млн айнод?
При дальнейшем поиске увидел папку /var/spool/exim4/input. Exim4 — почтовый сервер, который, как я понимаю, идет вместе с Debian. Попробовал подсчитать кол-во файлов в директории, но результат долго не показывался. Значит файлов там действительно очень и очень много:
Быстрый поиск в Интернете показал, что эта директория для писем в очереди. Гм… Это интересно, потому что ни один из наших сайтов не пользуется локальным почтовым сервером. Все переведено на «Яндекс.Почта для домена» и Google. Ладно, к этому вернемся позже. Пока нужно освободить айноды!
Просто удалять файлы в директории не хочется. Ищем правильное удаление и находим нечто подобное:
Запускаю. Жду некоторое время и понимаю, что айноды не освобождаются. Быстро размышляю, что это скорее всего из-за первой команды exim -bp, которая сначала выводит список писем в очереди. Раз там более 1 млн писем, то и выводить будет долго.
Более того, к этому времени свободные айноды уже закончились. Сайты вновь остановились. Начинают писать менеджеры, приходят одна за одной SMS о неработоспособности сайтов, звонит телефон… Обстановка накаляется. Ладно! Придется действовать жестко. Удаляем напрямую:
Но не тут-то было. Айноды не высвобождаются. Удаляются ли файлы тоже не могу посмотреть — объем более миллиона не позволяет их быстро подсчитать. Скорее всего, rm * тоже сначала читает всю директорию, а потом уже начинает удаление.
Ладно, пробуем более жесткий вариант:
… и наконец-то айноды освобождаются тысячами. Чувствую, что победил в небольшой битве, но враг ушел в лес для перегруппировки и еще одной атаки примерно через месяц :-) Надо наступать дальше.
Уже более спокойный и рассудительный, начал смотреть логи exim. Сначала ничего интересного… как вдруг нечто подобное:
Интересно! Как я уже писал, мы не пользуемся локальным почтовым сервером. Более того, site.by — не наш. Мы просто его временно размещаем на нашем сервере. Чем он занимается никому не известно.
Смотрю структуру сайта:
Что-то знакомое. Посмотрим index.php:
Ага, Joomla! Причем от 2013 года. Наверное воспользовались уязвимостью старых версий.
С большой надеждой, что сайт не очень популярный, открываю логи-вебсервера, чтобы найти что-то подозрительное. Сразу делаю поиск по email «joan_galloway», который был найден в логах exim. Но ничего нет… Ищем дальше. Запросы картинок, файлов стилей… И вдруг:
Очень интересно! Некий файл system.php. Был POST запрос, поэтому параметров запроса не видно в адресе. Название очень подозрительное. Когда-то в детстве у меня тоже была такая директория на домашнем компьютере :-)
Смотрим сам файл:
Понятно! Враг найден. Изменяем название файла и в логах exim наступает снова тишина. Наконец можно притронуться к еде, которую будущая жена поставила около меня минут 10 назад :-)
Далее будет допрос заключенного:
— каким образом попал на сервер?
— есть ли сообщники на других сайтах/директориях?
А также нужно разобраться на нашей территории:
— проверить права к папкам
— кроме автоматической проверки свободного места настроить проверку свободных айнод
— настроить exim (например, заблокировать SMTP).
Наверное, необходимо что-то еще. Буду рад комментариям/исправлениям/историям из вашей практики.
Надеюсь, кому-то статья покажется полезной.
Спасибо за внимание!
Меня зовут Илья. Я скорее программист и вечный-в-попытках-предприниматель чем системный администратор. Но, как известно, в стартапах ты и косец, и жнец, и на дуде игрец. Поэтому сегодня пришлось поиграть во все роли. Статья сможет помочь таким же как я начинающим администраторам, которые по воле судьбы/службы приходится заниматься сервером.
Пишу с пылу, с жару, часть команд писал по памяти. Буду рад любым корректировкам.
Итак, сегодня утром в 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).
Наверное, необходимо что-то еще. Буду рад комментариям/исправлениям/историям из вашей практики.
Надеюсь, кому-то статья покажется полезной.
Спасибо за внимание!
