Обсчет данных ip accounting по заданному ip

Возникла задача разбирать логи ip accounting'а с целью определить, какой пользователь куда тратит свой трафик. Для этой цели написал простой перловый скрипт, который разбирает строчки данных ip accounting'а, ищет строчки, относящиеся к заданному ip и выводит 2 списка: общий список адресов исходящего и входящего трафика, и список 5-ти самых активных адресов. Возможно, кому-то пригодится. Лежит тут: http://cebka.pp.ru/stuff/ipacct_counter.pl. Пример использования:

# cat /data/log/ipacct/2010-05-25/2010-05-25-00 | perl ipacct_by_dest.pl <ip>

Bitbucket.org

В связи с многочисленными проблемами работы с sourceforge, связанных, например, с невозможностью управления trac'ом, я решил, что лучше будет перенести публичный репозиторий на http://bitbucket.org. Это платформа для публикации кода, где все элементы помещаются в mercurial репозитории (например, wiki). Это делает очень удобным резервное копирование информации. Так что http://rspamd.sourceforge.net сейчас редиректит на bitbucket. Также я практически дописал основную документацию к rspamd, и теперь она доступна в том числе в wiki butbucket'а. Для конвертации из texinfo, который я использую для написания документации, в wiki формат (creole - http://www.wikicreole.org/) я написал небольшой скрипт на перле, который конвертирует основные элементы документации (лежит тут: http://cebka.pp.ru/stuff/info2wiki.pl). Разумеется, он конвертирует неполный набор тегов docbook и зачастую работает не совсем верно, но, насколько я знаю, это единственный способ конвертации, т.к. варианты texinfo->docbook->wiki также не реализованы нормально. Кроме этого, я, наконец, затегал 0.3.0. В планах к 0.3.1 написание smtp прокси для обработки спама на ранних стадиях, а также допиливание документации к lua API rspamd.

Ng_multicar или шейпинг трафика для большого числа ip адресов

Обычный ng_car довольно удобно использовать для шейпинга небольшого количества отдельных полос, в случае же увеличения количества полос поиск хука, в который будет отправлено правило будет занимать довольно много времени, т.к. для этого используется линейный список (ng_ipfw.c):

/* Look up hook by name */
hook_p
ng_ipfw_findhook(node_p node, const char *name)
{
        u_int16_t n;    /* numeric representation of hook */
        char *endptr;

        n = (u_int16_t)strtol(name, &endptr, 10);
        if (*endptr != '\0')
                return NULL;
        return ng_ipfw_findhook1(node, n);
}

/* Look up hook by rule number */
static hook_p
ng_ipfw_findhook1(node_p node, u_int16_t rulenum)
{
        hook_p  hook;
        hpriv_p hpriv;

        LIST_FOREACH(hook, &node->nd_hooks, hk_hooks) {
                hpriv = NG_HOOK_PRIVATE(hook);
                if (NG_HOOK_IS_VALID(hook) && (hpriv->rulenum == rulenum))
                        return (hook);
        }

        return (NULL);
}

Кроме этого, такое использование ng_car подходит только для ipfw с его ng_ipfw. В моем случае для pf'а необходимо направлять весь трафик в netgraph ноду (например, с ng_ether), поэтому задача разделения полос и ip адресов возлагается целиком на netgraph модуль. Возникли следующие идеи по реализации такого шейпера:

• Использовать для хранения информации о полосе для ip judy массив для ускорения поиска


• Для загрузки и выгрузки информации о полосах и соответствующих им ip использовать либо отдельные команды, либо парсить некоторый загрузочный файл



• Поддерживать создание динамических полос для сетей, например, если аргумент - сеть в CIDR формате, то создавать полосу для ip по получению пакета от данного ip из данной сети (нечто вроде динамических пайпов dummynet'а)

При такой схеме при увеличении числа пользователей нагрузка на роутер не должна значительно возрастать.

OpenID и wordpress

Плагин для работы openid аутентификации в wordpress работает достаточно странно: он требует для парсинга XRDS xml парсер, но то, как он пытается его загрузить, довольно ужасно:

        if (!extension_loaded($name)) {
            foreach ($params['libname'] as $libname) {
                if (@dl($libname)) {
                    $classname = $params['classname'];
                }   
            }   
        } else {

То есть, при отсутствии заданного расширения, он пытается его dlopen'уть, но при этом игнорируя любые ошибки. В итоге ошибка dl становится фатальной, но нигде не отображается. Опытным путем выяснилось, что для работы плагина необходимо расширение dom.so (textproc/php5-dom). Сейчас openid авторизация тут должна работать.

Rspamd и xml

Замучавшись бороться с lex+yacc решил перевести конфигурацию rspamd в xml формат. Минусы старой системы довольно прозаичны: lex при переключении внутренних состояний парсера (lex states) не умеет при yyrestart'е переключаться в INITIAL state, что приводит к невозможности перечитывания конфига "на лету". Кроме этого, сами по себе lex+yacc предоставляют слишком много возможностей для генерации грамматик, что само по себе неплохо, но я ловлю себя на мысле, что bind like конфиг-файл зачастую не очень очевиден для пользователя, яркий пример, когда переменные rspamd на самом деле являются не переменными в полном понимании этого слова, а подстановками текста. Также такой конфиг крайне сложно парсить чем-то, отличным от оригинальной lex/yacc грамматики. Моя же идея была в расширении интерфейса управления кластера rspamd, давая возможность конфигурации машин в кластере более-менее атоматически. Выбор лежал между ini-like форматом и xml (yaml и json тоже рассматривались, но никаких существенных преимуществ, кроме уменьшения размера конфига, я не нашел), но у ini нет понятия уровней вложенности, а это мне было нужно для описания файлов статистики внутри classifier'а. Конечным решением системы, которая бы предоставляла компромисс между удобством ручного написания сложных правил и возможностью настройки параметров автоматически (через web интерфейс или же shell script), я выбрал lua + xml. То есть, логика правил описывается в lua, используя все возможности этого языка, включая, например, переменные, являющиеся функциями, а включаются эти правила, а также назначаются веса, описываются рабочие процессы в xml. Такое решение, на мой взгляд, позволяет отделить код правил от собственно процесса настройки системы. Поддержку старого формата я оставил, и теперь rspamd умеет конвертировать старый формат в xml (конвертировать правила в lua он, к сожалению, не умеет, но умеет представлять их в виде xml). Сразу же видимый профит - возможность "мягкого" рестарта с перечитыванием конфига. В будущем планируется введение динамических правил, которые можно было бы загружать в кластер через контроллер, не выполняя рестарта. Также анализ правил, заимствованных из spamassassin'а показал, что все это лучше делать через отдельные статистические файлы, которые после обучения поставлять вместе с rspamd. Ну и напоследок, если у кого-то вдруг появилось желание заменить SA или другую систему спам фильтрации на rspamd, но в rspamd не хватает какой-то функциональности, то я был бы рад выслушать подобные замечания, равно как и другие идеи по развитию проекта.

Небольшой обзор возможностей rspamd

Так как до сих пор у меня не появилось идей, как рассказать легко и понятно о том, зачем и как использовать rspamd, я написал краткий обзор rspamd: фичи, установка, настройка и обучение. Надеюсь, он будет полезен тем, кто хочет использовать rspamd или тем, кто даже не знает о его существовании. Обзор тут:  http://cebka.pp.ru/why-rspamd.html.