A Mad Tea-Party

nagios startup segafaults.

Столкнулся с тем, что nagios в нескольких разных конфигурациях и даже на разных платформах(centos, freebsd) сегфолтится на старте. Однозначно проблему решила только перекомпиляция с –disable-embedded-perl.

centos/rhel5, xen 4.0.1.

В качестве эксперимента поднял эту конфигурацию со штатным ядром. Xen запустился, ядро загрузилось, но на моем чипсете 82801IR/IO/IH (ICH9R/DO/DH) все застопорилось на определении sata контроллера. Ошибка следующая:

ata1.00: qc timeout (cmd 0xec)

ata1.00: failed to IDENTIFY (I/O error, err_mask=0×4)

Решило проблему подсмотренное где-то на гентушных форумах pci=nomsi, добавленное в параметры к ядру в grub.conf

sendmail & postscreen

Первый раз вижу, чтобы нормальные почтовые сервера Pregreet’ами баловались. Обычно это треш-по от спаммеров, а тут вот вполне приличный sendmail. У, вероятно, вполне приличной фирмы “Ренесанс-страхование” (renins.com). Ан нет. Кажется у кого-таки обьекты /dev/ass и /dev/hands совмещены.

[root@mx2 ~]# grep -ih renins.com /var/log/maillog* | grep postscreen
Sep 24 15:01:01 mx2 postfix/postscreen[29116]: PREGREET 21 after 0.07 from 194.190.22.69: HELO mx2.renins.com??
Sep 23 20:21:57 mx2 postfix/postscreen[16099]: PREGREET 21 after 0.07 from 194.190.22.69: HELO mx2.renins.com??
Sep 23 18:42:09 mx2 postfix/postscreen[16099]: PREGREET 17 after 0.1 from 92.83.120.92: HELO renins.com??
Sep 23 18:45:18 mx2 postfix/postscreen[16099]: PREGREET 17 after 0.1 from 92.83.120.92: HELO renins.com??
Sep 23 18:51:10 mx2 postfix/postscreen[16099]: PREGREET 17 after 0.1 from 92.83.120.92: HELO renins.com??
Sep 23 18:51:18 mx2 postfix/postscreen[16099]: PREGREET 17 after 0.1 from 92.83.120.92: HELO renins.com??
Sep 23 18:51:53 mx2 postfix/postscreen[16099]: PREGREET 17 after 0.1 from 92.83.120.92: HELO renins.com??
Sep 23 18:52:39 mx2 postfix/postscreen[16099]: PREGREET 17 after 0.14 from 92.83.120.92: HELO renins.com??
Sep 24 08:13:17 mx2 postfix/postscreen[86914]: PREGREET 21 after 0.09 from 62.168.227.180: HELO mx7.renins.com??
Что любопытно, баннер сервера отдают одинаковый, но часть серверов ведет себя нормально, а часть активно нарушает RFC.
[root@mx2 ~]# telnet mx1.renins.com 25
Trying 194.190.22.23…
Connected to mx1.renins.com.
Escape character is ‘^]’.
220 mx1.renins.com ESMTP Sendmail 8.13.7/8.14.2; Fri, 24 Sep 2010 15:14:51 +0400
^]
telnet>
telnet> quit
Connection closed.
[root@mx2 ~]# telnet mx2.renins.com 25
Trying 194.190.22.69…
Connected to mx2.renins.com.
Escape character is ‘^]’.
220 mx2.renins.com ESMTP Sendmail 8.13.7/8.14.2; Fri, 24 Sep 2010 15:15:12 +0400
^]
telnet> quit
Connection closed.

Материалы по теме:
http://www.postfix.org/POSTSCREEN_README.html

http://www.rfc-editor.org/rfc/rfc5321.txt

“The communication between the sender and receiver is an
alternating dialogue, controlled by the sender. As such, the
sender issues a command and the receiver responds with a reply.
Unless other arrangements are negotiated through service
extensions, the sender MUST wait for this response before sending
further commands. One important reply is the connection greeting.
Normally, a receiver will send a 220 “Service ready” reply when
the connection is completed. The sender SHOULD wait for this
greeting message before sending any commands.”

convert vmdk to raw.

# qemu-img convert -f vmdk BitrixVirtualAppliance-s001.vmdk BitrixVirtualAppliance-s002.vmdk BitrixVirtualAppliance-s003.vmdk -O raw bitrix.raw

# kpartx -av bitrix.raw
add map loop0p1 : 0 256977 linear /dev/loop0 63
add map loop0p5 : 0 8131505 linear /dev/loop0 257103
# mount /dev/mapper/loop0p5 /mnt/root1/
# mount /dev/mapper/loop0p1 /mnt/root1/boot/

perl-FCGI, RT3

При обновлении Fedora12 отвалился Request Tracker (RT3) со следующей ошибкой:

Wide character in FCGI::Stream::PRINT Mason/CGIHandler.pm line 105.

Выяснилось, что в fedora очень удачно внесли обновления судя по- всему в perl-FCGI или в какой-то сопутствующий пакет, так что получилось как здесь:

http://www.opennet.ru/openforum/vsluhforumID8/6763.html

Переводить все на просто CGI не захотелось, рекомендуемый downgrade не проходит, поэтому по мотивам поста с опеннет был сделан грязный хак в файле

/usr/lib/perl5/vendor_perl/5.10.0/HTML/Mason/CGIHandler.pm

#print STDOUT grep {defined} @_;
my @xout = ( grep {defined} @_ );
utf8::encode(@xout);
print STDOUT @xout;

Тикеты заработали. Спасибо себе хорошему, что не сделал снапшот (как делаю обычно перед обновлениями) и господам-мэйнтейнерам.

Update:

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

/usr/lib/perl5/vendor_perl/5.10.0/RT/Interface/Web.pm

--- ./lib/RT/Interface/Web.pm.orig	2009-12-11 17:27:20.000000000 +0000
+++ ./lib/RT/Interface/Web.pm
@@@@ -88,6 +88,7 @@@@ sub EscapeUTF8 {
$$ref =~ s/)/)/g;
$$ref =~ s/"/"/g;
$$ref =~ s/'/'/g;
+    $$ref = Encode::encode_utf8($$ref);
}

# }}}
@

Взято отсюда

Update2

История имеет продолжение. Как выяснилось, после правильного фикса проблема пропала при использовании одного браузера, но проявляется точно так же, как и в начале в другом. Пока не понятно, толи там как-то все завязано на User-Agent, то ли, м.б., виноват какой-нибудь кеш масона. Вечером буду копаться дальше.

Update3

Чуда не произошло. Будучи сильно стесненным во времени, я не стал разбираться, почему под FreeBSD со старым firefox оно не работает, не работает под Ubuntu с последней Оперой, но работает под Ubuntu c последним Firefox и под виндой тоже вполне себе. Хотя я уверен, что это был бы очень увлекательный разбор полетов. Поэтому для меня решили проблему следующие строчки по переводу всего хозяйства под mod_perl:
#FCGIWrapper “/usr/sbin/mason_handler.fcgi” .fcgifcgi-perl
#SetHandler fcgid-script
#ScriptAlias / /usr/sbin/mason_handler.fcgi/

SetHandler perl-script
PerlResponseHandler RT::Mason
PerlRequire /usr/sbin/webmux.pl
Ну и активация mod_perl.

post systems, antispam.

Кстати, уже пару лет как посещяет мысль написать пару статей, на предмет построения почтовой системы postfix+dovecot+sqlite и отдельного стоящего почтового прокси (mx) на основе postfix для фильтрации спама. Благо в обоих случаях есть опыт внедрения и в принципе, довольно результативного в плане работы антиспама. Таки судя по всему напишу.

Stay tuned! (c)

postfix 2.8, sqlite

В последнем снапшоте 20100618 добавили поддержку sqlite. Но добавили так, что на CentOS не собирается со следующей ошибкой:
“dict_sqlite.c:71:2: error: #error “Your SQLite version is too old”
dict_sqlite.c: In function ‘dict_sqlite_lookup’:
dict_sqlite.c:203: warning: implicit declaration of function ’sqlite3_prepare_v2′
make: *** [dict_sqlite.o] Error 1
make: *** [update] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.38770 (%build)

RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.38770 (%build)
”
Старые грабли, пару лет назад я на них уже наступал

Отправил письмо на postfix-devel, посмотрил, что разработчики скажут. Но скорее всего правильно будет на этапе компиляции проверять версию sqlite и использовать всякие ifdef’ы.

postfix debug

Иногда требуется что-то в почтовой системе отдебажить прямо на рабочем сервере. Логи у postfix при дебаге откровенно говоря адские по размеру. Если включить дебаг обычным способом (master.cf smtpd -v), то при выской нагрузке почтовый сервер либо сразу уйдет в торпор, либо система будет медленно задыхаться под тяжестью логов.

Кроме использования debug_peer_list (который включает дебаг только для smtpd) можно еще запустить отдельного демона smtpd на нестандартном порту или другом ip и только для него включить дебаг. ~~Помимо клевого баннера~~ для него можно использовать по-моему вобще всю отдельную цепочку сервисов через указание в опциях *_service_name. Я проверял только для cleanup.
/etc/postfix/master.cf:

0.0.0.0:2025 inet n - n - 10 smtpd -v
-o smtpd_banner=$debug_banner
-o cleanup_service_name=debug_cleanup

debug_cleanup unix n - n - 0 cleanup -v

/etc/postfix/main.cf:

debug_banner = $myhostname ESMTP ready. Welcome to Debug Hell.

asterisk transfer hook

Задача специфическая. У меня на работе при поступлении внешнего звонка нужно диффиренцировать, откуда он поступил и давать соответствующее сообщение тому, на кого попадает звонок. В этом приближении задача решается довольно просто, при помощи разных входящих контекстов или через анализ ${SIP_HEADER(Record-Route)}. Но вот понадобилось диффиренцировать те звонки, которые идут через трансфер, не важно, blind или attended. Если опустить все сложности с поиском, то мне как и в прошлый раз помогла переменная TRANSFER_CONTEXТ, при помощи которой, в частности, сотрудники с мобильных телефонов могут безопасно переводить звонки на тех, кто в офисе. Вместо использования общего контекста для привилегированных пользователей создается отдельный контекст именно для трансфера с catch-all экстеншеном и вуаля:
[authxfer]
; Special hook on transfer
; include => authusers
exten => _.,1,NoOp(transfer)
exten => _.,n,Set(WARN=”ON”)
exten => _.,n,Set(WARNMSG=”msg/msg_transfer”)
exten => _.,n,Goto(authusers,${EXTEN},1)

Дальше звонок перебрасывается по назначению. Так что для трансфера можно не только свое сообщение забить, но и при необходимости выполнить еще какие-то действия. Судя по всему решений > 1, но меня вполне устраивает это.

P.S. Ну и да, это болванка, неплохо бы фильтровать символы и все такое, согласно README-SERIOUSLY.bestpractices.txt

ubunutu gdm login freeze.

Иногда случается, что при попытке разблокировать экран процесс логина зависает. Можно, конечно, перезагрузиться, но бывает, что слишком много окон открыто и жалко терять сессию. Мне в этом случае помогала отправка сигнала SIGHUP gdm’у. А точнее kill -1 `pidof gdm-binary`после логина рутом на первой консоли (Ctrl-Alt-F1)