Monday, April 13, 2009
Rspamd
Бета версия rspamd доступна для тестирования. Для сборки требуется cmake и gmime2.2. Сейчас rspamd работает примерно на порядок быстрее, чем spamassassin, но для окончательного релиза необходимо еще много тестирования. Буду признателен за любую информацию об использовании rspamd, а также о багах, в нем найденных. Rspamd доступен тут: http://cebka.pp.ru/trac
Subscribe to:
Post Comments (Atom)
Хотел попробывать, в результате видим сег фаулты :-) И как я понял примеры конфигурации отстают от реалии, так как на это тоже ругается :)
ReplyDeleteДа и как часто синхранизируются сырцы с SF ?
0.2.6 должен быть уже достаточно стабилен. Сейчас я работаю над lua api и документацией всего. А сегфолты - это хорошо, шлите трейсы, по дефолту он собирается с дебаг символами.
ReplyDeleteкорок нет :-) только в логе валит:
ReplyDelete#12492: Sep 02 23:33:17 rspamd main: worker process 16775 terminated abnormally by signal: 11
А вот и корка :-)
ReplyDelete#0 0x00000000004226c7 in radix_tree_free (tree=0x801a226c0) at /home/anton/rspamd/src/radix.c:237
237 if (!node->left && !node->right && !node->parent) {
[New Thread 0x801a020b0 (LWP 101862)]
[New LWP 100747]
(gdb) bt
#0 0x00000000004226c7 in radix_tree_free (tree=0x801a226c0) at /home/anton/rspamd/src/radix.c:237
#1 0x00000000004240ed in fin_radix_list (pool=0x801a0d320, data=0x7fffffffe920)
at /home/anton/rspamd/src/map.c:547
#2 0x0000000000423743 in read_map_file (map=0x801a74000, data=0x801a740c0)
at /home/anton/rspamd/src/map.c:294
#3 0x000000000042479c in start_map_watch () at /home/anton/rspamd/src/map.c:700
#4 0x0000000000407ddf in start_worker (worker=0x801a32500) at /home/anton/rspamd/src/worker.c:361
#5 0x00000000004180f6 in fork_worker (rspamd=0x801a08060, cf=0x801a2001b)
at /home/anton/rspamd/src/main.c:321
#6 0x00000000004183c8 in fork_delayed (rspamd=0x801a08060) at /home/anton/rspamd/src/main.c:412
#7 0x000000000041932d in main (argc=2, argv=0x7fffffffebe8, env=0x7fffffffec00)
at /home/anton/rspamd/src/main.c:779
(gdb) print node
$1 = (radix_node_t *) 0xb
(gdb) print *node
Cannot access memory at address 0xb
по ходу где-то память портим :-(
ну вобщем проблема в ip_internal.inc, сделал там запись верную ip/mask, в секции конфига view ip указан верный путь, оно там правда ругалось на /^[A-Z]{2}_SURBL_MULTI$/i, я ее законментил.
ReplyDeleteА какие настройки мапов (http:// или file:// в конфиге)?
ReplyDeleteip = "file:///usr/local/etc/rspamd/ip_internal.inc";
ReplyDeleteможет как-то не в коментах это перемывать?
круто, вобщем после ip/mask не было \n ну ладно воткнул, так дальше получаем кору, теперь в ней data->cur_data = radix_tree_create () пихает null, ну и как резульатат, tree выходит null и проверок далее нет, я так понял в radix не получилось сделать аллокацию памяти в пуле :-)
ReplyDeleteи проверки ни какой не стоит :-)
При создании пула используется glib g_malloc, который кидает abort при невозможности аллоцировать память. Насчет \n пофикшу завтра. Вообще насчет проверок валидности указателей там надо сделать весьма серьезный рефакторинг.
ReplyDeleteУгу полазил, так и есть, вообще в работе с пулом почти ничего не проверяется, типа под девизом у нас есть память всегда :-)
ReplyDeleteЭта проблема возникла ровно тогда, когда я перевел memory pool с g_malloc, который в случае невозможности выделения памяти делает abort() на g_slice, который abort не делает. Сейчас я обложил все вызовы g_slice_alloc и mmap assert'ами.
ReplyDeleteДа, но дело, конечно, вовсе не в этом, а в том, что radix_tree_create вызывался без аргументов, а ему в качестве аргумента должен передаваться пул. Это бага views.
ReplyDeleteAssert тоже не выход, один фиг он аборт дергает! Так как прога должна просто плюнуть в лог ошибка аллокирования и продолжить работу, в надежде на то, что память все же будет или придет админ и что-то поправит :-) А демон в итоге должен пропустить письмо как чистое :-)
ReplyDeleteПонятно, что это усложит проверками почти все этапы, зато демон будет торчать как вкопанный.
Да и откуда такая любовь в glib ? :-)
У меня ХТ много чего тоже написано и практика показала, что лучше все писать самому :-)
Как пример я как-то давно еще для своих почтовых штучек использовал gmime, так вот автор этого чуда, чхать хотел на мои рекомендации :-( Тебе вроде как Стас говорил про это :-) Там есть косяк, с декодированием допустим сабжекта которые бейз64 или квотет, при малейшем отклонении от rfc он ничего не будет декодировать :-) А у нас тьма почтовых программ которые только и спят и видят, чего бы такое нарушить из rfc :-)
Вобщем готов принять посильное участие :-) Так как мне интересно хорошее решение на С, надоело мне платить кучу денег Спамооброне :-)
ReplyDeleteКстати, а чего ты выбрал radix32? Мне как-то больше патриция понравилась :-)
Пофиксил эту и некоторые другие проблемы в этом коде. Просто так как мы пока не используем эту фичу, то она и тестировалась очень мало. Репозиторий на sf засинкал.
ReplyDeleteНасчет аллокации памяти у меня несколько другой подход. Допустим, malloc возвращает нам NULL, что в этой ситуации можно сделать? На самом деле по логике вещей лучше подохнуть, оставив решение проблемы диспатчеру, который либо отфоркает нового воркера (если будет память), либо как-то иначе решит проблему. Задача воркера - фильтрация почты, а не memory и process management. В том же nginx другой вариант: он просто начинает активнее освобождать ресурсы или же не принимать новые коннекты. В данном случае освобождать по сути нечего, лучше просто переложить эту задачу на плечи диспатчера.
ReplyDeleteНасчет glib'а: я лично считаю, что glib относится к C примерно как boost к C++. То есть, жить без glib'а можно, но херово. Особенно это касается портабельности. Свой предыдущий проект - rmilter, я писал под фрю, и когда потребовалось запустить его под линуксом, то пришлось весьма конкретно поплясать с бубном. Glib эти проблемы частично решает. Что же касается алгоритмов, то они в нем реализованы очень хорошо.
Насчет gmime: да, у него есть куча тараканов, и багу с декодированием я уже "обнаружил". Я думаю, лучшим вариантом будет форк gmime у себя и динамическая линковка с ним (дабы не нарушать lgpl). Но пока в ближайших планах окончательное допиливание lua и подключение нейросетевого классификатора.
Да, если неудобно общаться в комментах тут, то можно использовать jabber:
cebka@highsecure.ru
или почту:
vsevolod@highsecure.ru.
[...]Бета версия rspamd доступна для тестирования. Для сборки требуется cmake и gmime2.2. Сейчас rspamd работает примерно на порядок быстрее, чем spamassassin, но для окончательного релиза необходимо[...]
ReplyDelete