битрикс жжет

Я херею. битрик, посаженный в свежий битрикс окружение (с php ветки 5.3), при запуске сканера безопасности сообщает:

Используется опасная версия php       Важно!
Текущая версия php, предположительно содержит ряд критичных уязвимостей
Необходимо обновить php до последней стабильной версии или как минимум до версии не ниже 5.4.0

При этом в битрикс окружении стоит 5.3.3, пруф с офсайта:

Автоматически устанавливаемое и настраиваемое ПО:

• mysql-server 5.*
• web-server (Apache 2.2.*)
• php 5.3.*
• nginx 1.4.*
• memcached
• stunnel
• catdoc
• xpdf
• munin
• nagios
• sphinx

Просто ппц. При этом на их форуме куча негатива на счет попыток накатить 5.4 - куча модулей дохнет. Это первое.
Второе - собсно секюрность.. Рекомендация сменить текущий пых, со всеми секурити патчами на данный момент, на 5.4.0, в котором были реальные дыры - это из разряда вредных советов.

И все это наводит на мысль - весь этот скан безопасности заключается в тупом сравнении веток ПО. Не заморачиваясь с оценкой собственно уязвимостей.

Чиним сломанный сайт

Клиенту сайт поломали. Открывается ппц долго. Решили перед тем, как бекап отдать, сами посмотреть.
Итак - начинаем с предположения, что при запуске пых процесса он коннектится куда-то.

1. Запускаю курлом хит по сайту, на серваке делаю ps aux с грепом по юзеру и netstat -lntp | grep php. Да, куда-то ломится - на 192.151.154.180 По адресу видимо искать смысла нет, в коде наверняка хостнейм. Для очистки совести греп по жумле - нету такого.

2. Ок, давайте найдём хостнейм. Запускаем tcpdump -nnt -A port 53 > dnslog и опять жмакаем по сайту. Отлично, в полученном логе по адресу находим хостнейм.
 IP 188.xx.xx.133.53 > 188.xx.xx.21.46260:  951 2/2/4 A 192.151.154.180, (206) api.ipinfodb.com

3. Грепаем по хостнейму файло - находим занятный файлик /home/cpxxxxxx/public_html/libraries/joomla/plugin/qdh1ym.php. В нём, среди прочих няшек, упоминается ещё один: /home/cpxxxxxx/public_html/includes/thx7r.txt

4. Муваем файлики, жмакаем по сайту - открылся сразу, но с ошибкой require. Комментим этот require - сайт работает )

А дальше надо искать дыру, через которую инклюд сделали и посмотреть на предмет ходовых зараз.

onapp: поиск lvm виртуалки

Надо найти лвмку в onapp, чтобы поправить на диске кой-чего, владелец виртуалки себе что-то прострелил.

Нашли машинку, в ней диск, в описании диска - номер и сторадж
Дальше лезем в БД:

mysql> use onapp
mysql> select * from disks where id = '1913'\G  
*************************** 1. row ***************************
                id: 1913
virtual_machine_id: 1002
     data_store_id: 12
         disk_size: 21
        identifier: gskrjjn1ydypz7
        created_at: 2013-03-03 05:54:14
        updated_at: 2013-03-10 05:42:55
           is_swap: 0
             built: 1
            locked: 0
           primary: 1
    disk_vm_number: 1
       mount_point: NULL
add_to_linux_fstab: NULL
1 row in set (0.00 sec)

identifier - название, собственно, нужного лвма. Лезем на сторадж, кот. нам уже известен и можно ковырять лвмку.

Хватает же наглости

Сегодня один клиент с хостинга пожаловался. Что у него спам до яху не доходит. Совсем обнаглели. Сами на лок напрошиваются )

Про бюрократию и эффективность в отдельной конторе

Ну вот и у нас развели бюрократию. Собираемся, ругаемся, получаем люлей, объясняем, почему не выполнена пятилетка за три года и т.д. По сути - просто тратим время. На всех собраниях просто сидишь, слушаешь отчёты начальству своих коллег, из которых интересно послушать только девов и ТП, остальное - продажи, непродажи, маркетинги и акции к моей работе вообще мало относятся. Потом доходит дело до меня, говорю "сделал, не сделал, не сделал, ...,ну потому,..., не я не ненавижу всех и не хочу убить всех людей"
Ещё была задумка в в том, что на этих сборищах разные отделы могли поинтересоваться друг у другу: "Ну что у нас там с subj?!". И если ничего - то типа попросить всё-таки сделать.
На практике оказалось, что всё это бесполезно. Мои просьбы к двум коллегам не были услышаны в течении 2х недель и как-то всё это замялось ими.
Самое клёвое - раньше была доска с задачами, которые по мере возможности выполняли. Теперь же есть недельный и квартальный планы, которые по идее составляем мы сами. В итоге вышло, что сверху в эти планы вставляются дополнительные вещи, а те задачи, которые ставим перед собой мы сами - надо развёрнуто обосновывать. Причём новые задачи накидываются по ходу недели и реакции на них требуют чуть ли не моментальной
В результате я теперь каждый день по полдня трачу на то, чтобы что-то где-то заполнить, отчитаться, объяснить и т.д. Остальное время съедает повседневная работа, которой довольно много и которую никто не отменял.
Приходится что-то делать, оставаясь сидеть в офисе на час-полтора и дома по выходным. Есть в этом что-то неправильное.

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

Надзоры и запреты

Пришла неделю назад абуза от росконадзора. Запретить забанить уничтожить растрелировать клиентский сайт. Сайт и правду нехороший, про какие-то курительные смеси. Ну, написали клиенту, на время реакции засуспендили.
Одно только но.. Абуза пришла на мыло человека, почти 2 года у нас не работающего. Просто по привычке форвард на меня стоит, вот и попала абуза ко мне.
Перерыл все ресурсы конторы - в райпе везде контактом указан я. Думаю, ну неужели у них своя база, с блекждеком и устаревшими данными? И тут коллега натыкается на просторах инета на какой-то хуиз сайт, который юзает свою копию, года видимо 2010.
Написал чиновникам, что клиента уведомили, сайт заблокировали, но шлёте абузы вы не туда и как бы в будущем избежать такого.
Ответа так и не получил. Попробовал звонить - трубку не берут.
Вот такой надзор.

ISP: account disabled by server administrator

Человек жалуется - просрочил оплату, был залочен. Оплатил, но "сайт досихпор неработает".

Смотрю, действительно залочен. Нашёл в основном конфиге апача секцию с его хомяком:

<Directory /var/www/username/data>
        AllowOverride none
        Deny from all
        ErrorDocument 403 /disabled/index.html
</Directory>

Дёрнул суспенд/унсуспенд - 0.
Руками потёр начинку секции. Вот теперь интересно - заменится ли ручная правка? )) Посмотрим..

Самый прикол, что лочился и разлочивался акк через испэшный http api. На их форуме нашёл пост про аналогичную ситуацию, но там акки оставались лоченными из-за порчи конфига апача лишними закрывающими тегами секций. Официальная позиция на этот счёт - да, баг имеет место и не только с конфигом апача. Но баг редкий и трудновоспроизводимый, поэтому пока не отловили.
Если тут есть связь - становится немножко грустно.

Cpanel wildcard domains and nginx

На днях появилась такая проблемка:
1. Клиент в сипанели цепляет вайдкардный домен вида *.domain.com.
2. Панель добавляет алиас www.*.domain.com.
3. При генерации конфига nginx в директиву server_name попадает значение  "*.domain.com www.*.domain.com"/
4. Nginx проверяет новый конфиг и говорит, что он invalid, т.к. "*" допускается только в начале или конце сервернейма.

Сипанель нельзя заставить генерить имена с "*" в середине, поэтому пришлось выгребать такие имена из нагенерённого конфига.

Сделал такую штуку:

#!/usr/bin/perl
my $filename=$ARGV[0];
open(IN, "<", $filename) or die "open error\n";

while (<IN>) {
        my($line) = $_;
        chomp($line);
        if (m/server_name/) {
                $line =~ s/\S+\*\S+//g;
        }
        print  "$line\n";
}

Дергаю её после генерации конфига, в патч для скрипта-генератора:

--- build-conf.sh       2010-03-04 14:26:39.000000000 +0300
+++ build-conf.sh_new   2012-08-22 11:58:27.000000000 +0400
@@ -16,13 +16,16 @@

 cd $ROOT

-if [ ! -f $NGINX/vhosts.conf.new ]; then
-       touch $NGINX/vhosts.conf.new
-       chmod 600 $NGINX/vhosts.conf.new
+if [ ! -f $NGINX/vhosts.conf.raw ]; then
+        touch $NGINX/vhosts.conf.raw
+        chmod 600 $NGINX/vhosts.conf.raw
 fi

 # build nginx conf using default template in $TMPL
-$ROOT/ngx_conf_gen.pl -c /usr/local/apache/conf/httpd.conf > $NGINX/vhosts.conf.new || exit 4
+$ROOT/ngx_conf_gen.pl -c /usr/local/apache/conf/httpd.conf > $NGINX/vhosts.conf.raw || exit 4
+
+# remove invalid wildcarded server_name (example: www.*.server.com)
+$ROOT/rm_badwildcard.pl $NGINX/vhosts.conf.raw > $NGINX/vhosts.conf.new

 new=`$MD5 $NGINX/vhosts.conf.new | cut -f1 -d' '`
 cur=`$MD5 $NGINX/vhosts.conf | cut -f1 -d' '`

Зловещий нагиос ))

Билайны продолжают жечь

Проблема - билайн у себя зачем-то зафильтровал FTP трафик своему клиенту до нас. То ли они опять с чем-то борются, то ли ещё просто нашествие мозговых слизней. Суть в том, что клиент поинтересовался у них насчёт фильтрации. Ответ билайна:

Отвечая на Ваш вопрос, хотим сообщить, что наши файрволлы снабжают сессии портами выше 1024, а указанный Вами хостинг не пускает на свой FTP сервис TCP сессии с source портом выше 1024.

Я вот даже не знаю, что и сказать. Видимо, то существо, что писало этот бред, хотело выразить что-то типа: "Мы д'артаньяны, ничего не фильтруем, а фильтуют нед'артаньяны хостеры, да ещё верхний диапазон исходящих портов".

Ппц, вот что там за люди работают?

Ещё прикол с аллиедом

Клиент жалуется - на двух железках входящая скорость нормальная, под 50 Мбит/сек, исходящая скорость низкая, около 3х Мбит/сек. На третьей всё ок. Все железки разные, оси - на 2х фряха, на одной винда. Проблемы у виндового и фряшного серваков. Свич - AT8000GS-48 с прошивкой 2.0.0.26.
Смотрю - либо на серверах косяк, либо свич неисправен, ибо шейперов нет.
В конце концов нашли засаду - выключенный negotiation на портах свича. Вырубал в своё время с целью переключения портов принудительно в режим 100f. Врубил негоциэйшн - и пошла скорость )
Скорость до сотни пришлось зарезать rate-limit.

Итого: по-дефолту лучше negotiation оставлять.
Хотя был случай, когда клиент наоборот просил вырубить его.

билайн и блокировка айпишников

эти болваны из билайна по писульке или звонку неизвестного представителя силовых структур заблокировали адрес сервака, на котором сидит около тысячи акков и 3 тысячи доменов.
При этом никаких абуз нам не писали, просто взяли и заблокировали.
Когда нам хлынул потом обращений от клиентов, стали разбираться - как так?
Что характерно, клиенты сначала звонили провайдеру с жалобой - через вас сайт не работает, через другого прова работает. А билайн им и говорит - "мы никогда не блокировали и не блокируем адреса, звоните хостеру". И это при том, что интернеты завалены постами "билайн блокирует ip адрес".
На второй день телефонных разговоров с этими недоумками выяснилось наконец, что проблема не в аварии, про которую они нам весь прошлый день твердили, а да, по предписанию от ментов заблокирован адрес, потому что на нем домен, который этому менту не понравился.
Убирать блокировку, равно как и сообщать домен, из-за которого адрес заблокирован, они не хотят. Что за предписание - тоже не говорят.
При этом клиентам они продолжают говорить, что проблема у хостера, т.к. билайн белый и пушистый никогда блять ничего не блокирует.
Придётся менять для всех клиентов айпишник и вдобавок каждому доказывать, что билайн им наврал.

Что характерно - это единственный такой больной на голову пров. Больше таких выкрутасов ну у кого не видел.

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

вот, кстати, пара статей на тему:
http://tsapel-man.livejournal.com/15146.html
http://vorugamnet.livejournal.com/635.html

Новая площадка

Осваиваем новый ЦОД:

Амазон и трансляции

Сегодня, вернее уже вчера вечером некая контора разыгрывала в одном московском клубе скидки на квартиры. Так получилось, что мне пришлось срочно поднимать резервную площадку для трансляции розыгрыша церемонии вручения купонов.
Делать решили на амазоне, используя адобовские образы с флешем (тут рассказывал про это). Настроил один ориджин, на который ребята, занимающиеся трансляцией, пустили поток из клуба, перед ним 3 эджа. Все 4 инстанса - x.large. Балансером тут выступал по сути офсайт, плеер раздавался клиентам с ссылкой на один из эджей. Коллега, который плеер на сайт прикручивал, сделал ротацию и убоал мою карусель в резерв.
В какой-то момент пришлось ресчехлять.
Итого нагрузка в пике составила в сумме 5,5 тыс. одновременных трансляций, за ~3 часа отдали полтора терабайта. Из-за небольшой ошибки, часть клиентов на ориджин попали, но так, как он мог вынести нагрузку на уровне с эджами - оставили, просто убрали его из ротации.
Причём занятно - поначалу трансляция с амазона была довольно тормозная, пока коннекты единичные были, но после их резкого роста все тормоза прекратились )

Вот график отдачи:

Странноват, конечно..
В общем, aws - вполне годится для трансляций в прямом эфире, где допустим лаг в 5-8 секунд.
И, да, всё удовольствие вышло примерно в 300$.

centos vs adaptec 6xxx

Дело-то, вообще говоря, дрянь.. Вот возможное решение, но надо тыкать флешки - нам не подходит:
http://www.webhostingtalk.com/showthread.php?t=1068797

NFS и квоты

Понадобилось заквотировать товарища, который NFS юзает.
Не стал с мудрить с нфс квотами, сделал так:
1. завёл юзера и группу для него.
2. выставил ему квоты.
3. заменил в /etc/exports опции на  /backup/colo/userfoo   xxx.xxx.xxx.xxx(rw,all_squash,anonuid=528,anongid=504)
Где 528 и 504 - это созданные юзер и группа.
4. выставил овнером хозяйства товарища нового юзера/группу
5. ну и нфс рестартанул
Таким образом, кем бы товарищ не писал в эту нфс, всё туда будет падать с правами локальным овнером 528:504 и будет квотироваться.

EX4200 traffic shaping

Возникла жёсткая необходимость зарезать входящий трафик на один сервак. Стал мудрить с bandwidth-limit, по аналогии с резкой исходящего (относительно оконечного оборудования). Не прокатило - резал на 3 inet уровне, на аплинке. В общем, кучу варианов перебрал, решение окалось весьма простым:

{master:0}[edit]
xxx@yyy# show class-of-service
interfaces {
    ge-0/0/26 {
        shaping-rate 150m;
    }
}

При этом исходящий с сервера режется через bandwidth-limit в policier'ах.

Native vlan на ex4200

Столкнулся с забавной штукой на джуниперах EX4200:
Отдаю клиенту трафик в одном влане, на обоих концах access порты.
Возникла необходимость отдать в 2 влана, причём в один отдавать без тега.
Перенастроил порт на транк, добавил новый влан, старый сделал нативным. Не работает )
Опытным путём удалось установить, что нужно удалить нативный влан из vlan membership.
Вот так.

Манагеры

Сегодня в очередной раз столкнулся с идиотизмом организаций, сажающих людей не на своё место.
После делегирования зоны на новые серверы, в зоне ru. остались склеивающие записи. Но бывшие авторитетные НСы перехали на новое место и поменяли адреса. В результате сложилась картина: есть пары записей - старая склеивающая в зоне ru. и новая обычная запись в зоне домен.ru. Старая запись отдаётся в дополнительной секции при определённых запросах и оседает в кэшах.
Т.е. надо убирать записи в зоне ru., за которую рипн отвечает. Но решил сначала с регистратором пообщаться.
Зная уровень первой линии подобных контор сразу спросил - с кем можно технические аспекты обсудить?
Парень на телефоне вызвался помочь. Обрисовал ситуацию. Товарищ начал мне загибать про а записи в моей зоне и т.д., пришлось объяснить про склеивающие записи. Тут он передал звонок "техническому специалисту".
Девушка-сцециалист сказала, что понимает суть проблемы и стала меня учить изменять А записи в личном кабинете, пришлось ещё одну итерацию про записи в зоне ру провести. Передали звонок дальше.
Следующая девушка посоветовала обратится к конторе-владельцу домену, т.е. ко мне же по сути ))
Потом сказала, что манагеры такими вопросами не занимаются и сказали написать заявку на мыло, а там, дескать, разработчики посмотрят.
Ну вот нахера, спрашивается, передавать манагерам и сейлзам задачи, в которых они не шарят, а требуют чисто технической квалификации? В общем, незачёт регистратору r01.ru.

ДЦ и свет.

В понедельник были опять те же грабли, что и в мае, только домой я в этот раз не в 4, а в 6 приехал ) И сидел ещё до 7.
Грюстно..
Вот сёни пришлось делать прикидку клиенту на отказоустойчивую карусель из 2х нод. Первое, что на ум пришло - хартбит. А потом думаю - а вдруг опять электричество кончицо? И тогда ни 2 ноды, ни 2 канала, ничего не спасёт.
Ладно, будем надеяться, что косяки нашими партнёрами на ближайший год были досрочно сделаны )