A Mad Tea-Party http://blog.viliar.net.ru Curiouser and curiouser! Thu, 24 Jun 2010 00:41:43 +0000 http://wordpress.org/?v=2.0.11 en convert vmdk to raw. http://blog.viliar.net.ru/2010/06/23/convert-vmdk-to-raw/ http://blog.viliar.net.ru/2010/06/23/convert-vmdk-to-raw/#comments Wed, 23 Jun 2010 11:51:34 +0000 viliar opensource http://blog.viliar.net.ru/2010/06/23/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/

]]>
http://blog.viliar.net.ru/2010/06/23/convert-vmdk-to-raw/feed/
perl-FCGI, RT3 http://blog.viliar.net.ru/2010/06/23/perl-fcgi-rt3/ http://blog.viliar.net.ru/2010/06/23/perl-fcgi-rt3/#comments Tue, 22 Jun 2010 21:13:11 +0000 viliar opensource http://blog.viliar.net.ru/2010/06/23/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.

]]>
http://blog.viliar.net.ru/2010/06/23/perl-fcgi-rt3/feed/
post systems, antispam. http://blog.viliar.net.ru/2010/06/21/post-systems-antispam/ http://blog.viliar.net.ru/2010/06/21/post-systems-antispam/#comments Mon, 21 Jun 2010 10:15:36 +0000 viliar mail http://blog.viliar.net.ru/2010/06/21/post-systems-antispam/ Кстати, уже пару лет как посещяет мысль написать пару статей, на предмет построения почтовой системы postfix+dovecot+sqlite и отдельного стоящего почтового прокси (mx) на основе postfix для фильтрации спама. Благо в обоих случаях есть опыт внедрения и в принципе, довольно результативного в плане работы антиспама. Таки судя по всему напишу.

Stay tuned! (c) :-)

]]>
http://blog.viliar.net.ru/2010/06/21/post-systems-antispam/feed/
postfix 2.8, sqlite http://blog.viliar.net.ru/2010/06/21/postfix-28-sqlite/ http://blog.viliar.net.ru/2010/06/21/postfix-28-sqlite/#comments Mon, 21 Jun 2010 10:09:25 +0000 viliar mail http://blog.viliar.net.ru/2010/06/21/postfix-28-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’ы.

]]>
http://blog.viliar.net.ru/2010/06/21/postfix-28-sqlite/feed/
postfix debug http://blog.viliar.net.ru/2010/03/27/postfix-debug/ http://blog.viliar.net.ru/2010/03/27/postfix-debug/#comments Sat, 27 Mar 2010 11:56:36 +0000 viliar mail http://blog.viliar.net.ru/2010/03/27/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.

]]>
http://blog.viliar.net.ru/2010/03/27/postfix-debug/feed/
asterisk transfer hook http://blog.viliar.net.ru/2010/03/19/asterisk-transfer-hook/ http://blog.viliar.net.ru/2010/03/19/asterisk-transfer-hook/#comments Fri, 19 Mar 2010 11:16:50 +0000 viliar pbx http://blog.viliar.net.ru/2010/03/19/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

]]>
http://blog.viliar.net.ru/2010/03/19/asterisk-transfer-hook/feed/
ubunutu gdm login freeze. http://blog.viliar.net.ru/2010/03/18/ubunutu-gdm-login-freeze/ http://blog.viliar.net.ru/2010/03/18/ubunutu-gdm-login-freeze/#comments Thu, 18 Mar 2010 09:51:51 +0000 viliar linux http://blog.viliar.net.ru/2010/03/18/ubunutu-gdm-login-freeze/ Иногда случается, что при попытке разблокировать экран процесс логина зависает. Можно, конечно, перезагрузиться, но бывает, что слишком много окон открыто и жалко терять сессию. Мне в этом случае помогала отправка сигнала SIGHUP gdm’у.  А точнее kill -1 `pidof gdm-binary`после логина рутом на первой консоли (Ctrl-Alt-F1)

]]>
http://blog.viliar.net.ru/2010/03/18/ubunutu-gdm-login-freeze/feed/
OOF (out-of-fuel). http://blog.viliar.net.ru/2010/02/25/oof-out-of-fuel/ http://blog.viliar.net.ru/2010/02/25/oof-out-of-fuel/#comments Thu, 25 Feb 2010 10:49:45 +0000 viliar fun linux http://blog.viliar.net.ru/2010/02/25/oof-out-of-fuel/ "An aircraft company discovered that it was cheaper to fly its planes with less fuel on board. The planes would be lighter and use less fuel and money was saved. On rare occasions however the amount of fuel was insufficient, and the plane would crash. This problem was solved by the engineers of the company by the development of a special OOF (out-of-fuel) mechanism. In emergency cases a passenger was selected and thrown out of the plane. (When necessary, the procedure was repeated.) A large body of theory was developed and many publications were devoted to the problem of properly selecting the victim to be ejected. Should the victim be chosen at random? Or should one choose the heaviest person? Or the oldest? Should passengers pay in order not to be ejected, so that the victim would be the poorest on board? And if for example the heaviest person was chosen, should there be a special exception in case that was the pilot? Should first class passengers be exempted? Now that the OOF mechanism existed, it would be activated every now and then, and eject passengers even when there was no fuel shortage. The engineers are still studying precisely how this malfunction is caused."
 http://lwn.net/Articles/104185/
Твердая пять :-D 
]]> http://blog.viliar.net.ru/2010/02/25/oof-out-of-fuel/feed/ rpm packaging. http://blog.viliar.net.ru/2010/02/18/rpm-packaging/ http://blog.viliar.net.ru/2010/02/18/rpm-packaging/#comments Thu, 18 Feb 2010 19:21:50 +0000 viliar linux http://blog.viliar.net.ru/2010/02/18/rpm-packaging/ Если не следовать умным документам, типа
RPM advanced docs

и правильно не именовать rpm пакеты c rc/pre версиями, можно вляпаться в следующее:
# rpm -Uhv –force /usr/src/redhat/RPMS/noarch/postfixadmin-2.3rc7-1.noarch.rpm
Preparing…                ########################################### [100%]
1:postfixadmin           ########################################### [100%]
# rpm -Uhv /usr/src/redhat/RPMS/noarch/postfixadmin-2.3-3.noarch.rpm
Preparing…                ########################################### [100%]
package postfixadmin-2.3rc7-1.noarch (which is newer than postfixadmin-2.3-3.noarch) is already installed

Беда. Пакет то уже в репозитарии и установлен в ряд систем. Тем не менее. Даже с такими кривыми руками можно жить, хотя, конечно, менее комфортно.
Добавляем в spec файл после Version и Release следующую строчку:
Epoch:          1

Пересобираем пакет. И вуаля:
# rpm -Uhv /usr/src/redhat/RPMS/noarch/postfixadmin-2.3-3.noarch.rpm
Preparing…                ########################################### [100%]
1:postfixadmin           ########################################### [100%]
Do not forget run upgrade.php!

Happy rpm packaging!

Update:

Пожалуй, на всякий случай приведу кусок текста, мало ли со временем та wiki помрет:

“Sometimes, program naming schemes are good, but rpm is lost. For example, with Proftpd, Pre-releases are named with the version followed by the suffix pre and then the pre version number, like so: 1.2.0pre5. Because of string comparisons, rpm thinks that 1.2.0pre5 is newer than 1.2.0 (we know that this is not true).

To permit upgrades to newer packages, we must help rpm to know which packages are newer than others. We could use the Epoch: tag (superseding the Serial: tag) but this is dirty. You have to use another naming convention, putting the “pre” stuff in the release tag; in our example you will call the package “1.2.0-0.pre5.1mdv”. Then, when 1.2.0 comes out, you’ll release “1.2.0-1mdv”, and this package will be able to upgrade the pre5.”

]]>
http://blog.viliar.net.ru/2010/02/18/rpm-packaging/feed/
xentop long names. http://blog.viliar.net.ru/2010/02/15/xentop-long-names/ http://blog.viliar.net.ru/2010/02/15/xentop-long-names/#comments Mon, 15 Feb 2010 16:33:39 +0000 viliar opensource http://blog.viliar.net.ru/2010/02/15/xentop-long-names/ В xentop слишком длинные имена отображаются не полностью, и в некоторых ситуациях не понятно, who is who.  Это справедливо для xen 3.3.2. Выше пока не смотрел, может что-то поправили. По мотивам http://www.wombattechnology.com.au/pages/articles/xentop-column-too-wide.php. У меня их решение не работает, то есть имя через /local/domain/$id/name меняется, но изменения не видны через xm top, xentop, xm list. Но имя можно записывать как через /local/domain/$id/name, так и через /vm/$uuid/name. Это работает. Подредактированный скрипт, если имя domU, как у нас, равно ip:

#!/bin/bash

TempFile="/root/xenlist"

#
# Get a list of domains.
#
xm list > $TempFile

let LineCount=1
exec < "$TempFile"
while read Line
do
DomainName=`echo "$Line" | awk '{ print $1 }' | sed -r 's/.*.([0-9]+.[0-9]+)/1/'`
if [ "$DomainName" != "Name" ]
then
if [ "$DomainName" != "Domain-0" ]
then
DomainId=`echo "$Line" | awk '{ print $2 }'`
DomainUuid=`xenstore-read /local/domain/$DomainId/vm`
#echo "DomainName $DomainName DomainId $DomainId DomainUuid $DomainUuid"
#echo "xenstore-write $DomainUuid/name $DomainName"
xenstore-write $DomainUuid/name $DomainName
let LineCount=$LineCount+1
fi
fi
done

rm -f $TempFile

Update: Аккуратнее, wordpress портит кавычки, а так же, как выяснилось, бэкслеши. Код для sed, там в замене бэкслеш перед единицей. Экранирование не помогает, а плагинов вставки кода в страницу для этой версии wordpress нет. Обновлять не хочется по ряду причин, времени переезжать на другой блоговый движок, к сожалению пока нет.

]]>
http://blog.viliar.net.ru/2010/02/15/xentop-long-names/feed/