Monday, April 13, 2009

Rspamd

Бета версия rspamd доступна для тестирования. Для сборки требуется cmake и gmime2.2. Сейчас rspamd работает примерно на порядок быстрее, чем spamassassin, но для окончательного релиза необходимо еще много тестирования. Буду признателен за любую информацию об использовании rspamd, а также о багах, в нем найденных. Rspamd доступен тут: http://cebka.pp.ru/trac

17 comments:

  1. Хотел попробывать, в результате видим сег фаулты :-) И как я понял примеры конфигурации отстают от реалии, так как на это тоже ругается :)
    Да и как часто синхранизируются сырцы с SF ?

    ReplyDelete
  2. 0.2.6 должен быть уже достаточно стабилен. Сейчас я работаю над lua api и документацией всего. А сегфолты - это хорошо, шлите трейсы, по дефолту он собирается с дебаг символами.

    ReplyDelete
  3. корок нет :-) только в логе валит:
    #12492: Sep 02 23:33:17 rspamd main: worker process 16775 terminated abnormally by signal: 11

    ReplyDelete
  4. А вот и корка :-)
    #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
    по ходу где-то память портим :-(

    ReplyDelete
  5. ну вобщем проблема в ip_internal.inc, сделал там запись верную ip/mask, в секции конфига view ip указан верный путь, оно там правда ругалось на /^[A-Z]{2}_SURBL_MULTI$/i, я ее законментил.

    ReplyDelete
  6. А какие настройки мапов (http:// или file:// в конфиге)?

    ReplyDelete
  7. ip = "file:///usr/local/etc/rspamd/ip_internal.inc";
    может как-то не в коментах это перемывать?

    ReplyDelete
  8. круто, вобщем после ip/mask не было \n ну ладно воткнул, так дальше получаем кору, теперь в ней data->cur_data = radix_tree_create () пихает null, ну и как резульатат, tree выходит null и проверок далее нет, я так понял в radix не получилось сделать аллокацию памяти в пуле :-)
    и проверки ни какой не стоит :-)

    ReplyDelete
  9. При создании пула используется glib g_malloc, который кидает abort при невозможности аллоцировать память. Насчет \n пофикшу завтра. Вообще насчет проверок валидности указателей там надо сделать весьма серьезный рефакторинг.

    ReplyDelete
  10. Угу полазил, так и есть, вообще в работе с пулом почти ничего не проверяется, типа под девизом у нас есть память всегда :-)

    ReplyDelete
  11. Эта проблема возникла ровно тогда, когда я перевел memory pool с g_malloc, который в случае невозможности выделения памяти делает abort() на g_slice, который abort не делает. Сейчас я обложил все вызовы g_slice_alloc и mmap assert'ами.

    ReplyDelete
  12. Да, но дело, конечно, вовсе не в этом, а в том, что radix_tree_create вызывался без аргументов, а ему в качестве аргумента должен передаваться пул. Это бага views.

    ReplyDelete
  13. Assert тоже не выход, один фиг он аборт дергает! Так как прога должна просто плюнуть в лог ошибка аллокирования и продолжить работу, в надежде на то, что память все же будет или придет админ и что-то поправит :-) А демон в итоге должен пропустить письмо как чистое :-)
    Понятно, что это усложит проверками почти все этапы, зато демон будет торчать как вкопанный.
    Да и откуда такая любовь в glib ? :-)
    У меня ХТ много чего тоже написано и практика показала, что лучше все писать самому :-)
    Как пример я как-то давно еще для своих почтовых штучек использовал gmime, так вот автор этого чуда, чхать хотел на мои рекомендации :-( Тебе вроде как Стас говорил про это :-) Там есть косяк, с декодированием допустим сабжекта которые бейз64 или квотет, при малейшем отклонении от rfc он ничего не будет декодировать :-) А у нас тьма почтовых программ которые только и спят и видят, чего бы такое нарушить из rfc :-)

    ReplyDelete
  14. Вобщем готов принять посильное участие :-) Так как мне интересно хорошее решение на С, надоело мне платить кучу денег Спамооброне :-)
    Кстати, а чего ты выбрал radix32? Мне как-то больше патриция понравилась :-)

    ReplyDelete
  15. Пофиксил эту и некоторые другие проблемы в этом коде. Просто так как мы пока не используем эту фичу, то она и тестировалась очень мало. Репозиторий на sf засинкал.

    ReplyDelete
  16. Насчет аллокации памяти у меня несколько другой подход. Допустим, 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.

    ReplyDelete
  17. [...]Бета версия rspamd доступна для тестирования. Для сборки требуется cmake и gmime2.2. Сейчас rspamd работает примерно на порядок быстрее, чем spamassassin, но для окончательного релиза необходимо[...]

    ReplyDelete