[exim-conf] сборка exim, libspf2 и sqlite3 на NetBSD

Victor Ustugov victor на corvax.kiev.ua
Пт Июн 18 21:49:33 EEST 2010


приветствую

реализована сборка exim с моими патчами под NetBSD:
http://mta.org.ua/exim-4.69-conf/pkgsrc-netbsd/exim-4.72/

механизм сборки похож на сборку под OpenBSD и FreeBSD.

нужно два раза выполнить gmake sync. после первого раза обновиться
Makefile, в ходе второго будет выполнен gmake sync_pkgsrc_netbsd

нужно обновить дерево портов.

подразумевалось, что если бы была нужна проверка соответствия адреса 
хоста отправителя SPF записи домена отправителя, нужно было бы перейти в 
каталог pkgsrc-netbsd/libspf2-1.2.9 и выполнить gmake install

при этом libspf2 соберется с моими патчами и будет установлена.

но, как оказалось, exim, собранный на NetBSD с поддержкой libspf2, 
неработоспособен (об этом ниже).

сам механизм сборки порта libspf2 со своими двумя патчами я пока оставил.

перед сборкой эксима нужно в каталоге pkgsrc-netbsd/exim-4.72 разово
выполнить команду gmake patch_port. при этом в дереве портов будет
модифицировать файл options.mk (добавлен синтаксис для сборки exim с
поддержкой dlfunc, spf, embedded perl) и в файл distinfo будут добавлены
контрольные суммы новых патчей.

далее нужно скопировать файл Makefile.local.sample в Makefile.local, при
необходимости отредактировать его.

при необходимости собрать exim с поддержкой libspf2 нужно в переменной
PKG_OPTIONS указать значение exim-spf. повторюсь, что это сделано "на 
будущее", т. к. на данный момент времени exim с поддержкой libspf2 
неработоспособен.

при этом надо обратить внимание, что в этой же переменной нужно оставить
значение exim-expand-dlfunc, т. к. dlfunc сейчас широко применяется в
конфигураторе и собирать exim без поддержки dlfunc я не рекомендую.

т. к. по умолчанию в переменной confMAILERTABLE_LMTP включено
использование lmtp транспорта в mailertable, то в значении переменной
PKG_OPTIONS нужно указать и exim-transport-lmtp. если необходимости в
роутинге почты по LTMP нет, то можно в conf/site указать NO в качестве
значения confMAILERTABLE_LMTP и не указывать exim-transport-lmtp в
значении PKG_OPTIONS в Makefile.local.

в следующей версии конфигуратора значение по умолчанию для
confMAILERTABLE_LMTP будет изменено с `YES' на `NO'.

далее нужно выполнить gmake build, далее gmake install

что касается сборки exim с поддержкой embedded perl, то с этим пока
возникли проблемы.

учитывая, что на данный момент времени в конфигурации паровоза, близкой 
к дефолтовой, embedded perl используется только для определения основной 
MX записи домена при указании в mailertable конструкции /bestMX, было
решено решение этой проблемы отложить.

на NetBSD временно можно просто не использовать confPERL. тогда
конструакция /bestMX в mailertable будет обрабатываться как /MX.

а в следующей версии конфигуратора будет применено определение основной
MX записи домена с помощью ${reduce (спасибо за идею Андрею
Октябрьскому), а не с помощью функции bestmx на embedded perl.
реализация уже готова и протестирована:

http://mta.org.ua/exim-4.70-conf/deliveries/mailertable.m4

в данном случае имеется ввиду следущий фрагмент роутеров:
	route_data		= ${sg{${sg\
				{$address_data}\
				{\N(?i)([^:\s]+?)\/bestMX\N}\
				{\N\
				    ${extract{2}{ }{\
					${reduce{<\n ${lookup dnsdb{mx=$1}}}{999999 localhost}{${if
<{${extract{1}{ }{$item}}}{${extract{1}{ }{$value}}}{$item}{$value}}}}\
				    }}\N\
				}\
				}}{\N\s\N}{}}

в следующий версии конфигуратора этот же алгоритм определения основной
MX записи домена будет использован при рилеинге почты на основе MX
записей (см. confRELAY_BASED_ON_MX). т. к. в данном случае вычисление
bestmx домена производится не в роутерах, а в acl, то удалось избежать
использования embedded perl, использовав рекурсивный вызов acl. вот этот 
рекурсивный вызов acl и будет заменен на аналог вышеприведенной 
конструкции, основанной на ${reduce.


теперь о проблемах сборки exim с libspf2.

libspf2 собирается в любом случае с -lpthread:

# ldd /usr/pkg/lib/libspf2.so.2.1.0
/usr/pkg/lib/libspf2.so.2.1.0:
         -lc.12 => /usr/lib/libc.so.12
         -lpthread.0 => /usr/lib/libpthread.so.0
         -lintl.0 => /usr/lib/libintl.so.0

судя по сообщению внутри libspf2-1.2.9/configure.ac пока собрать libspf2 
без -lpthread невозможно:

pthread.h is required to build this program.


при этом в libspf2-1.2.9/TODO написано:

Test compile without pthreads and without res_ninit() - NetBSD 2


все дело в том, что эксим не является многопоточным приложением. поэтому 
разработчики при работе с резолвером напрямую могут обращаться к 
глобальной переменной _res. а libspf2 собрана с -lpthread. 
соответственно если собрать exim с libspf2, то обращаться напрямую к 
переменной _res нельзя. тут же появляется сообщение об ошибке:

_res is not supported for multi-threaded programs.

выходом является либо переписывание исходников exim для перехода на 
работу с функциями res_n*() (res_ninit, res_nsend, ...), либо сборка 
библиотек, с которыми собирается exim, без -lpthread.

собственно все это можно узнать из следующего следующео треда:
http://mail-index.netbsd.org/pkgsrc-users/2009/11/16/msg011135.html


собрать libspf2 без -lpthread не получится (по крайней мере пока), 
поэтому пока для проверки соответствия адреса рилея отправителя SPF 
записи домена отправителя можно использовать альтернативный SPF backend, 
а именно spfd из состава порта p5-Mail-SPF-Query.

простой пример запуска spfd:
/usr/pkg/lib/perl5/vendor_perl/bin/spfd --socket /tmp/spfd --socket-user 
mail --socket-group mail

при этом в site/conf необходимо в явном виде указать испльзуемый SPF 
backend:

define(`confSPF2', `YES')dnl
define(`confSPF2_BACKEND', `SPFD')dnl
define(`confSPF2_SPFD_SOCKET', `/tmp/spfd')dnl


если же нужна поддеркжа sqlite3 в exim, то придется пересобрать sqlite3 
без --enable-threadsafe.

я не силен в pkgsrc, поэтому не знаю, как указать --enable-threadsafe=no 
в CONFIGURE_ARGS из командной строки. поэтому пришлось сделать крошечный 
патч к порту libspf3:

http://mta.org.ua/netbsd/sqlite3-3.6.23.1/patches-port/Makefile.patch

можно или самостоятельно наложить этот патч, либо возпользоваться 
механизмом сборки портов, подобным тем, с помощью которых можно собирать 
exim и другие порты с моими патчами:

http://mta.org.ua/netbsd/sqlite3-3.6.23.1/

файлы из данного каталога можно получить по rsync:

rsync -a rsync://rsync.mta.org.ua/netbsd/ netbsd/

после этого необходимо перейти в каталог netbsd/sqlite3-3.6.23.1 и выполнить

gmake clean patch_port build


после установки собранного таким образом порта sqlite3 можно собирать 
exim с exim-lookup-sqlite в PKG_OPTIONS в файле Makefile.local

-- 
Best wishes Victor Ustugov   mailto:victor на corvax.kiev.ua
public GnuPG/PGP key:        http://victor.corvax.kiev.ua/corvax.asc
ICQ UIN: 77186900, 371808614 nic-handle: CRV-UANIC




Подробная информация о списке рассылки exim-conf