Данный дневник является порождением терзающей меня на протяжении, наверное, года мысли "надо таки начать где-нибудь записывать перлы с работы". Ну а к окончательной реализации подбил пример одного ведущего дневник товарища. За что ему было высказано отдельное спасибо
Я не заинтересован в срывании покровов, разговорах о футболе, политике, "наболевшем" и так далее - посему никаких личных переживаний, мнений, жалоб и тд и тп здесь не будет. Только моя работа и, надеюсь, только юмор.
Теперь, собственно, о сабже. Несколько лет работаю в техподдержке одного хостинг-провайдера (известного, обожаемого, проклинаемого, говнохостера - это как посмотреть, хватает, прямо скажем, всего) и до сих пор, несмотря на печали разного "административного" толка (за что отдельное спасибо руководству), мне доставляет эта работа Этим чувством я и постараюсь поделиться.
Все логины, имена, фамилии смело считайте вымышленными, совпадения случайными а то еще придут злые дяди из СБ и выразят своё "фи"...
An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Дневник снова открыт... летом!
Хотя у него немного сменилась ориентация - меньше "саппорта", больше администрирования. Скорее всего, в будущем переберусь на другое название или другую площадку вообще.
Пока как черновики:
Я·17:27
[root@ovz]# du -sch /vz/restore/BACKUPS/local/9731 4.0K /vz/restore/BACKUPS/local/9731
чего только 4кб?
Дмитрий·17:27
отому что тяни из архива за 20е
там же нет ничего, папка пустая
Я·17:28
дык последние должны лежать на сервере?)
Дмитрий·17:28
теоретически. Согласись, между "должны" и "есть" пролегает большая разница
Я·17:29
нублжад)
нуок
как я быстро из гнева к смирению пришел, минуя отрицание, торг и депрессию ))
An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Дневник закрыт... летом.
Через пять лет работы в техподдержке (последние пара лет далась особо тяжело благодаря воцарившимуся идиотизму) я ушел из этой области. Несмотря ни на что - я не жалею ни об этом времени, ни тем более об уходе
Заводить новый дневник для новой сферы моей деятельности я не буду Во-первых - она слишком спецефична и понятна определенным специалистам определенной области (ФТТ), во-вторых - этот опыт показал, что я все-таки не люблю писать дневники. Мне интереснее писать какие-то статьи/заметки, делиться опытом на какую-то случайно пришедшую в голову тему - чем описывать "течение окружающей жизни".
Ну а в качестве тем для очерков я в итоге выбрал авиацию, а не IT
An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
/>>> 05.03.2015, 12:00, "Support Team": />>> Здравствуйте! />>> />>> Действительно, нагрузка на сервер не снизилась. В таком случае требуется проверка скриптов Вашего сайта с помощью его разработчика. />>> />>> В частности, вчера произведено порядка 1200 запросов к скрипту sсript_naduv.php: />>> />>> [username@shared ~/logs]$ cat custom_log.previous | cut -d'"' -f2 | cut -d' ' -f2 | cut -d'?' -f1 | sort | uniq -c | sort -n | tail />>> 185 /favicon.ico />>> 216 /highslide/graphics/zoomout.cur />>> 261 /sсript_igra.php />>> 268 /sсript_mech.php />>> 274 /sсript_all.php />>> 335 /sсript_sport.php />>> 343 /sсript_child.php />>> 421 / />>> 427 /news.php />>> 1201 /sсript_naduv.php />>> />>> При этом генерация страницы скриптом потребляет порядка 10 секунд процессорного времени. />>> />>> username 62906 57.6 0.5 27420 16760 ?? RN 8:36AM 0:09.44 sсript_naduv.php (php-cgi) />>> />>> Другие скрипты сайта тоже потребляют достаточно много процессорного времени. />>> />>> username 72192 45.4 0.5 27420 16396 ?? RN 8:36AM 0:06.60 sсript_sport.php (php-cgi) />>> username 86791 39.8 0.3 10164 8224 ?? RN 8:36AM 0:05.55 sсript_old.php (php-cgi) />>> username 90153 47.4 0.2 8960 7228 ?? RN 8:37AM 0:07.63 sсript_child.php (php-cgi) />>> username 96708 51.0 0.4 17620 12408 ?? RN 8:37AM 0:07.69 news.php (php-cgi) />>> username 3183 36.9 0.3 14372 10140 ?? RN 8:37AM 0:04.78 sсript_tir.php (php-cgi) />>> username 7133 30.3 0.4 19312 13744 ?? RN 8:37AM 0:03.52 sсript_disco.php (php-cgi) />>> />>> Нормальное потребление процессорного времени скриптами сайта - порядка 0.1-0.3 секунды, а не нескольких секунд. />>> />>> Системные вызовы процесса генерации скрипта sсript_naduv.php показывают на громадное количество операций смены прав доступа к файлам (зачем такая операция вообще />>> производится?) в начале обработки скрипта и на громадное количество операций чтения, которое, по всей видимости, возникают при чтении комментариев из базы данных: />>> ... />>> 4.966374098 write(4,"i\0\0\0\^Cselect `id`, `comments"...,109) = 109 (0x6d) />>> 4.966488919 read(4,"\^A\0\0\^A",4) = 4 (0x4) />>> 4.966552895 read(4,"\^F",1) = 1 (0x1) />>> 4.966611004 read(4,"N\0\0\^B",4) = 4 (0x4) />>> 4.966670790 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,78) = 78 (0x4e) />>> 4.966738956 read(4,"Z\0\0\^C",4) = 4 (0x4) />>> 4.966794830 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,90) = 90 (0x5a) />>> 4.966856012 read(4,"b\0\0\^D",4) = 4 (0x4) />>> 4.966917474 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,98) = 98 (0x62) />>> 4.966980891 read(4,"Z\0\0\^E",4) = 4 (0x4) />>> 4.967041514 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,90) = 90 (0x5a) />>> 4.967105490 read(4,"\\\0\0\^F",4) = 4 (0x4) />>> 4.967166114 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,92) = 92 (0x5c) />>> 4.967229810 read(4,"V\0\0\a",4) = 4 (0x4) />>> 4.967290992 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,86) = 86 (0x56) />>> 4.967355247 read(4,"\^A\0\0\b",4) = 4 (0x4) />>> 4.967415312 read(4,"\M-~",1) = 1 (0x1) />>> 4.967485155 read(4,"\^S\0\0\t",4) = 4 (0x4) />>> 4.967548293 read(4,"\^A2\0\0\0\fhtml_with_br\0",19) = 19 (0x13) />>> 4.967608916 read(4,"\^S\0\0\n",4) = 4 (0x4) />>> 4.967668422 read(4,"\^A3\0\0\0\fhtml_with_br\0",19) = 19 (0x13) />>> 4.967732398 read(4,"\^S\0\0\v",4) = 4 (0x4) />>> 4.967792183 read(4,"\^A4\0\0\0\fhtml_with_br\0",19) = 19 (0x13) />>> 4.967848057 read(4,"\^S\0\0\f",4) = 4 (0x4) />>> 4.967905608 read(4,"\^A5\0\0\0\fhtml_with_br\0",19) = 19 (0x13) />>> 4.967963717 read(4,"\^S\0\0\r",4) = 4 (0x4) />>> 4.968021267 read(4,"\^A6\0\0\0\fhtml_with_br\0",19) = 19 (0x13) />>> 4.968078538 read(4,"\^S\0\0\^N",4) = 4 (0x4) />>> 4.968135809 read(4,"\^A7\0\0\0\fhtml_with_br\0",19) = 19 (0x13) />>> 4.968194756 read(4,"\^S\0\0\^O",4) = 4 (0x4) />>> 4.968250630 read(4,"\^A8\0\0\0\fhtml_with_br\0",19) = 19 (0x13) />>> 4.968309019 read(4,"\^S\0\0\^P",4) = 4 (0x4) />>> 4.968366569 read(4,"\^A9\0\0\0\fhtml_with_br\0",19) = 19 (0x13) />>> 4.968426354 read(4,"\^T\0\0\^Q",4) = 4 (0x4) />>> 4.968481949 read(4,"\^B10\0\0\0\fhtml_with_br\0",20) = 20 (0x14) />>> 4.968539779 read(4,"\^T\0\0\^R",4) = 4 (0x4) />>> 4.968597608 read(4,"\^B11\0\0\0\fhtml_with_br\0",20) = 20 (0x14) />>> ... />>> />>> Системные вызовы процесса были сняты таким образом и сохранены в файл: />>> />>> [username@shared ~/www/htdocs]$ while true; do ps aux | grep php-cgi | grep sсript_naduv | awk {'print $2'} | xargs truss -o sсript_naduv.php.txt -d -p ; done />>> [username@shared ~/www/htdocs]$ ls -alh sсript_naduv.php.txt />>> -rw-r--r-- 1 username username 58M Mar 5 08:45 sсript_naduv.php.txt />>> />>> Вам необходимо проанализировать этот файл с разработчиками сайта и устранить указанные проблемы. />>> />> 05.03.2015 14:36 - Username написал(а): />> Здравствуйте! />> Скачиваем файл. Анализировать с разработчиками не представляется возможным, так />> как их давно нет, и связи с ними тоже. Другое дело, что эти же скрипты и работали />> все это время и не нагружали настолько сервер, всегда хватало ресурсов. А после />> того, как мы оплатили хостинг на год, понеслась проблема с нагрузкой. Данный сайт />> плохо оптимизирован. CMS, на которой он устроен, не обновлялась уже много лет. На />> данный момент мы делаем другой новый сайт, после него собираемся полностью переделать />> проблемный сайт, чтобы он был современным и в плане технической сборки тоже. />> Мы постараемся проанализировать данные, которые вы прислали. Будем стараться />> исправить проблему, потому что сайт нас кормит, в конце концов... />> Но не могли бы вы проанализировать работу сервера до и после начала каждодневной />> нагрузки. Мы не меняли ничего на сайте (серьезного) с 2014 года, а нагрузка не />> могла начаться просто так, так же исполняя скрипты, как и прежде, это как минимум />> странно. />> /> 05.03.2015, 15:10, "Support Team": /> Здравствуйте! /> /> Сервер работает в штатном режиме и его конфигурация и настройки не обновлялись. Также никакие обновления сервера не могли привести к такому эффекту. /> /> Нагрузка могла расти постепенно: учитывая, что изменяются права доступа к множеству файлов, их количество будет влиять на итоговый результат, то есть на результат влияет /> банально наполнение сайта; /> /> Нагрузка могла вырасти скачком: учитывая, что производится считывание огромного количества информации из базы данных, причем в этом процессе фигурирует слово /> "Комментарии", речь может идти об атаке на сайт и создании большого числа спам-комментариев на сайте в различных формах (гостевая книга, комментарии, отзывы и так /> далее), что привело к дальнейшему затруднению в работе сайта. /> /> Также речь может идти о взломе сайта и об изменении его кода, но на наш взгляд были бы иные последствия в виде лишних страниц на сайте, рассылке спама, работе посторонних /> скриптов - такого сейчас не наблюдается. /> /> В любом случае сейчас скрипт в ходе генерации одной страницы совершает порядка 900 тысяч действий, это связано только с кодом и это никак не может быть /> связано с сервером: в вывод системных вызовов не успела попасть инициализация обработчика PHP, поскольку в штатном режиме она занимает крайне мало времени. Все действия, что /> производятся при генерации страницы и тратят ресурсы процессора - производятся обработчиком согласно найденному в скриптах коду и никак не связаны с серверным настройками. /> Здравствуйте! После разговоров с вами и проделанных манипуляций, решили нанять фрилансера для оптимизации кода сайта, чтобы наконец решить проблему нагрузки.
Спасибо за проявленное терпение. Работоспособность сайта для нас первоочередная задача.
$ php -c /etc/php.ini index.php Notice: Undefined index: SERVER_NAME in include/kernel.class.php on line 1030 Warning: readfile(/index.html): failed to open stream: operation failed in include/kernel.class.php on line 1030
Вуаля: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND user 5569 0.0 0.0 19564 12800 ?? I 10:51AM 0:00.48 httpd -f /etc/apache/httpd.conf user 6825 0.0 0.0 19564 12800 ?? I 10:54AM 0:00.32 httpd -f /etc/apache/httpd.conf user 6916 0.0 0.0 19564 12804 ?? I 10:54AM 0:00.50 httpd -f /etc/apache/httpd.conf user 18376 0.0 0.0 19528 12764 ?? I 11:09AM 0:00.14 httpd -f /etc/apache/httpd.conf user 53119 0.0 0.0 17060 10524 ?? Ss Wed03PM 12:56.55 httpd -f /etc/apache/httpd.conf user 94218 0.0 0.0 19564 12800 ?? I 10:59AM 0:00.65 httpd -f /etc/apache/httpd.conf ...
An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Заявка на тему "Не сохраняются отправленные на сервере", к заявке приложен скриншот с ошибкой: "Tunderbird не удалось подключиться к IMAP-серверу. Возможно, Вы превысили ограничение на максимальное число соединений к этому серверу. Если это так, откройте диалоговое "Дополнительные параметры IMAP-сервера и уменьшите число кэшируемых соединений."
Зрим в логи: Feb 19 09:36:56 courier-imapd: Maximum connection limit reached for $IP Feb 19 09:36:57 courier-imapd: Maximum connection limit reached for $IP Feb 19 09:36:57 courier-imapd: Maximum connection limit reached for $IP Feb 19 09:36:57 courier-imapd: Maximum connection limit reached for $IP Feb 19 09:36:57 courier-imapd: Maximum connection limit reached for $IP
Какой умный почтовый клиент, однако Надо было его послушаться.
An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Заявка на тему: "Почему я не могу войти по ftp".
В ходе обсуждения теории входа на сервер мы пришли к выводу: 1) Вампиры не могут войти на сервер по протоколу SSH/SFTP; 2) Вампиры не могут войти на сервер по протоколу FTP в активном режиме обмена данными; 3) Вампиры должны использовать пассивный режим обмена данными для успешного входа на сервер.
А все потому, что вампиры не могут войти без приглашения
An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Достаточно часто на автомате выполняются "стандартные действия", которые выолняются практически всегда без раздумий, но которые по факту не нужны.
Например: у нас есть один сайт, который позавчера начали ддосить и в ответ мы запретили доступ к сайту из зарубежных сетей (а кроме этого работает скрипт, который особо наглых добавляет в iptable). Сегодня пользователь интересовался, можно ли снять фильтр, не кончилась ли атака. Ответ - нет, не кончилась. Далее в качестве пруфов кидается кусочек лога последнего наглого забаненного. Я обычно кидаю кусочек за секунду-две, чтобы пользователь сам оценил масштаб. В логе сервера оно выглядит так:
Я человек добрый, готовый для комфорта пользователей чего-нить сделать дополнительного и не люблю, когда в логе есть лишняя информация, не нужная пользователю - такую информацию вырезаю регулярками. Здесь тоже самое, таймстампы пользователь вряд ли оценит, заменяю "ru;*[0-9.]*;" "ru;", получаю такой результат и отправляю его клиенту:
58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1 58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1 58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1 58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1 58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1 58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1 58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1 58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1 58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1 58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1 58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1 58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1 58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1 58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1 58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1 58.11.94.108;www.domain.ru;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1 После чего смотрю на отправленный ответ и в голове проскакивает мысль - "блин, надо было просто скопировать одну строчку и вставить 15 раз"
Вот тут то все и стало понятно Для домена IPv6-адрес в зоне указан, а в конфигурации apache его нет - вот он и отдает свою страницу) Еще забавно, что похоже для яндекса приоритетом является именно IPv6 - несмотря на то, что сайт успешно открывался по IPv4-адресу, яндекс решил взять за основу результаты открытия страниц по IPv6-адресу и заявлял, что сайт не работает.
An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
... когда пользователь заказывает выделенный IP - и система выделяет ему айпишник нашего phpmyadmin. К слову, phpmyadmin без боя не сдался - так что это теперь у пользователя по его домену открывается именно он, а не наоборот!
An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Жалоба - "не работает plesk (500 internal server error), спасите-помогите!"
Ну, на момент, когда руки дошли - посмотреть, что там случилось с плеском, не получилось. Контейнер не отвечал в принципе и не пинговался. Захожу внутрь - не запущен сетевой интефрейс. Пожал плечами, запустил. Вроде там что-то про "ребут поможет?" в заявке было, ну да ладно. Так, а вот и ошибка плеска. А вот лог службы, которая отвечает за его работу:
[root@3346 /]# tail /var/log/sw-cp-server/error_log /usr/share/sw-cp-server/applications-conf.sh: line 4: /etc/sw-cp-server/applications.d/*.conf: Permission denied Cannot find config item ["global/SERVERsocket==:8443", ".php", 0] 2014-08-06 10:16:57: (mod_fastcgi.c.1068) the fastcgi-backend /usr/bin/sw-engine-cgi -c /usr/local/psa/admin/conf/php.ini -d auto_prepend_file=auth.php3 -u psaadm failed to start: 2014-08-06 10:16:57: (mod_fastcgi.c.1072) child exited with status 1 /usr/bin/sw-engine-cgi -c /usr/local/psa/admin/conf/php.ini -d auto_prepend_file=auth.php3 -u psaadm 2014-08-06 10:16:57: (mod_fastcgi.c.1075) If you're trying to run your app as a FastCGI backend, make sure you're using the FastCGI-enabled version. If this is PHP on Gentoo, add 'fastcgi' to the USE flags. 2014-08-06 10:16:57: (mod_fastcgi.c.1171) [ERROR]: spawning fcgi failed.
Хм, понятного мало, но хоть понятно, как воспроизвести [root@3346 /]# /usr/bin/sw-engine-cgi -c /usr/local/psa/admin/conf/php.ini -d auto_prepend_file=auth.php3 -u psaadm Could not open Repository at "/etc/sw/keys": Cannot open file PHP Warning: file(/etc/psa/psa.conf) [function.file]: failed to open stream: Permission denied in /usr/local/psa/admin/plib/class.Conf.php3 on line 27 Content-type: text/html Unable to read Control Panel configuration file: date_default_timezone_get() [function.date-default-timezone-get]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Volgograd' for 'VOLST/4.0/DST' instead
Эээ... эээ? Не, с правами к конфигу psa.conf все в порядке, а вот права на /etc/psa/ - 0664. Странно. Ладно, поправим. Так, а что это за ругать на /etc/sw/keys/? С keys опять все в порядке, а вот /etc/sw/ - права 0664. Хм, странно, но поправим. А еще на что-то ругань была... А, "/etc/sw-cp-server/applications.d/*.conf". Хм, и опять с конфигами все в порядке. А /etc/sw-cp-server/ - 0664. Окей, попра...
"Штирлиц долго смотрел в одну точку... Потом в другую... - Двоеточие! - наконец-то догадался Штирлиц."
Ну да, в /etc/ все обладает правами 0664. Не удивительно, что ничего не работает Ну что ж, поправим, подглядев у соседнего сервера.
An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Жалоба на работу с почтвым ящиком. Смотрю логи авторизации - хм, вот пользователь вошел два раза по протоколу POP3 и три раза по протоколу IMAP. Так, а что он там делал? Посмотрим лог сервера dovecot. Хм, только imap?..
"Лог dovecot'а - странный предмет, вот юзер входит - а вот его нет!"
PS Позже посмотрел внимательнее. Просто два входа на сервер по протоколу POP3 - это 4 строки в логе. А три его входа по IMAP вылились в over100 строк лога, ибо с письмами активно работал.
PPS На работе не хватает времени, приходится дописывать потом
An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Утро понедельника началось с сюрприза - на рабочую почту пришло уведомление от антивируса: wp-content/empt.php => PHP.#28463.evb64.0.UNOFFICIAL
Хм, но это же тестовый хостинг без домена второго уровня, на который установлен голый вордпресс? Тот самый вопрдресс, разработчики которого в случае взломов уверяют "у вас пароль украли, а сервер вообще дырявый!"... Да, версия старая (3.8.2) и установка производилась только ради теста обработчика PHP на сервере, но каких-либо дополнительных плагинов, например, не устанавливал. Значит, косяк точно в вордпрессе, будем искать...
Обыкновенный вебшелл, md5-хэш в базе есть (пароль root). Кроме веб-шелла еще производился доступ к каталогу uploads, других вредоносов нет. Ну что ж, теперь нам нужны логи. читать дальше
Хм, ну что ж, прикольно. Судя по всему, через скрипт install.php (который в ходе установки не удаляется и в том числе нет рекомендаций удалять его вручную) поменяли пароль доступа к CMS, далее через саму CMS загрузили вебшелл, потом уже с помощью самого вебшелла переместили его в другой каталог.
wordpress.stackexchange.com/questions/96620/sho... - Is keeping wp-admin/install.php and wp-admin/install-helper.php a security leak on the newer versions of wordpress? - No, there is no security risk. Both files do sanity checks before anything happens.
Хм, и как решать эту проблему? Ну, в моем случае очень быстро и эффективно: $ rm -rf ~/public_html/*
А так - советуют блокировать доступ к install.php через .htaccess (интересно, и почему нельзя просто удалять этот файл?)