13Апр/0917
Rspamd
Бета версия rspamd доступна для тестирования. Для сборки требуется cmake и gmime2.2. Сейчас rspamd работает примерно на порядок быстрее, чем spamassassin, но для окончательного релиза необходимо еще много тестирования. Буду признателен за любую информацию об использовании rspamd, а также о багах, в нем найденных. Rspamd доступен тут: http://cebka.pp.ru/trac
Комментарии (17)
Пинги (0)
(подписаться на новые комментарии в этой ветке)
Нет обратных ссылок на эту запись.
Сентябрь 2nd, 2009 - 23:17
Хотел попробывать, в результате видим сег фаулты
И как я понял примеры конфигурации отстают от реалии, так как на это тоже ругается 
Да и как часто синхранизируются сырцы с SF ?
[Ответить]
Сентябрь 2nd, 2009 - 23:24
0.2.6 должен быть уже достаточно стабилен. Сейчас я работаю над lua api и документацией всего. А сегфолты – это хорошо, шлите трейсы, по дефолту он собирается с дебаг символами.
[Ответить]
Сентябрь 2nd, 2009 - 23:34
корок нет
только в логе валит:
#12492: Sep 02 23:33:17 rspamd main: worker process 16775 terminated abnormally by signal: 11
[Ответить]
Сентябрь 2nd, 2009 - 23:51
А вот и корка
#0 0×00000000004226c7 in radix_tree_free (tree=0×801a226c0) 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 0×00000000004226c7 in radix_tree_free (tree=0×801a226c0) at /home/anton/rspamd/src/radix.c:237
#1 0×00000000004240ed in fin_radix_list (pool=0×801a0d320, data=0×7fffffffe920)
at /home/anton/rspamd/src/map.c:547
#2 0×0000000000423743 in read_map_file (map=0×801a74000, data=0×801a740c0)
at /home/anton/rspamd/src/map.c:294
#3 0×000000000042479c in start_map_watch () at /home/anton/rspamd/src/map.c:700
#4 0×0000000000407ddf in start_worker (worker=0×801a32500) at /home/anton/rspamd/src/worker.c:361
#5 0×00000000004180f6 in fork_worker (rspamd=0×801a08060, cf=0×801a2001b)
at /home/anton/rspamd/src/main.c:321
#6 0×00000000004183c8 in fork_delayed (rspamd=0×801a08060) at /home/anton/rspamd/src/main.c:412
#7 0×000000000041932d in main (argc=2, argv=0×7fffffffebe8, env=0×7fffffffec00)
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
по ходу где-то память портим
[Ответить]
Сентябрь 3rd, 2009 - 00:02
ну вобщем проблема в ip_internal.inc, сделал там запись верную ip/mask, в секции конфига view ip указан верный путь, оно там правда ругалось на /^[A-Z]{2}_SURBL_MULTI$/i, я ее законментил.
[Ответить]
Сентябрь 3rd, 2009 - 00:06
А какие настройки мапов (http:// или file:// в конфиге)?
[Ответить]
Сентябрь 3rd, 2009 - 00:12
ip = «file:///usr/local/etc/rspamd/ip_internal.inc»;
может как-то не в коментах это перемывать?
[Ответить]
Сентябрь 3rd, 2009 - 00:23
круто, вобщем после ip/mask не было \n ну ладно воткнул, так дальше получаем кору, теперь в ней data->cur_data = radix_tree_create () пихает null, ну и как резульатат, tree выходит null и проверок далее нет, я так понял в radix не получилось сделать аллокацию памяти в пуле
и проверки ни какой не стоит
[Ответить]
Сентябрь 3rd, 2009 - 03:00
При создании пула используется glib g_malloc, который кидает abort при невозможности аллоцировать память. Насчет \n пофикшу завтра. Вообще насчет проверок валидности указателей там надо сделать весьма серьезный рефакторинг.
[Ответить]
Сентябрь 3rd, 2009 - 12:56
Угу полазил, так и есть, вообще в работе с пулом почти ничего не проверяется, типа под девизом у нас есть память всегда
[Ответить]
Сентябрь 3rd, 2009 - 13:21
Эта проблема возникла ровно тогда, когда я перевел memory pool с g_malloc, который в случае невозможности выделения памяти делает abort() на g_slice, который abort не делает. Сейчас я обложил все вызовы g_slice_alloc и mmap assert’ами.
[Ответить]
Сентябрь 3rd, 2009 - 13:28
Да, но дело, конечно, вовсе не в этом, а в том, что radix_tree_create вызывался без аргументов, а ему в качестве аргумента должен передаваться пул. Это бага views.
[Ответить]
Сентябрь 3rd, 2009 - 13:56
Assert тоже не выход, один фиг он аборт дергает! Так как прога должна просто плюнуть в лог ошибка аллокирования и продолжить работу, в надежде на то, что память все же будет или придет админ и что-то поправит
А демон в итоге должен пропустить письмо как чистое 
Тебе вроде как Стас говорил про это 
Там есть косяк, с декодированием допустим сабжекта которые бейз64 или квотет, при малейшем отклонении от rfc он ничего не будет декодировать 
А у нас тьма почтовых программ которые только и спят и видят, чего бы такое нарушить из rfc 
Понятно, что это усложит проверками почти все этапы, зато демон будет торчать как вкопанный.
Да и откуда такая любовь в glib ?
У меня ХТ много чего тоже написано и практика показала, что лучше все писать самому
Как пример я как-то давно еще для своих почтовых штучек использовал gmime, так вот автор этого чуда, чхать хотел на мои рекомендации
[Ответить]
Сентябрь 3rd, 2009 - 14:00
Вобщем готов принять посильное участие
Так как мне интересно хорошее решение на С, надоело мне платить кучу денег Спамооброне 
Кстати, а чего ты выбрал radix32? Мне как-то больше патриция понравилась
[Ответить]
Сентябрь 3rd, 2009 - 14:02
Пофиксил эту и некоторые другие проблемы в этом коде. Просто так как мы пока не используем эту фичу, то она и тестировалась очень мало. Репозиторий на sf засинкал.
[Ответить]
Сентябрь 3rd, 2009 - 14:11
Насчет аллокации памяти у меня несколько другой подход. Допустим, malloc возвращает нам NULL, что в этой ситуации можно сделать? На самом деле по логике вещей лучше подохнуть, оставив решение проблемы диспатчеру, который либо отфоркает нового воркера (если будет память), либо как-то иначе решит проблему. Задача воркера – фильтрация почты, а не memory и process management. В том же nginx другой вариант: он просто начинает активнее освобождать ресурсы или же не принимать новые коннекты. В данном случае освобождать по сути нечего, лучше просто переложить эту задачу на плечи диспатчера.
Насчет glib’а: я лично считаю, что glib относится к C примерно как boost к C++. То есть, жить без glib’а можно, но херово. Особенно это касается портабельности. Свой предыдущий проект – rmilter, я писал под фрю, и когда потребовалось запустить его под линуксом, то пришлось весьма конкретно поплясать с бубном. Glib эти проблемы частично решает. Что же касается алгоритмов, то они в нем реализованы очень хорошо.
Насчет gmime: да, у него есть куча тараканов, и багу с декодированием я уже «обнаружил». Я думаю, лучшим вариантом будет форк gmime у себя и динамическая линковка с ним (дабы не нарушать lgpl). Но пока в ближайших планах окончательное допиливание lua и подключение нейросетевого классификатора.
Да, если неудобно общаться в комментах тут, то можно использовать jabber:
cebka@highsecure.ru
или почту:
vsevolod@highsecure.ru.
[Ответить]
Август 20th, 2010 - 19:46
[...]Бета версия rspamd доступна для тестирования. Для сборки требуется cmake и gmime2.2. Сейчас rspamd работает примерно на порядок быстрее, чем spamassassin, но для окончательного релиза необходимо[...]
[Ответить]