Alexey Osipov

В репозитории появился быстрый NetFlow-измеритель: http://local.com.ua/forum/topic/26157-ipt-netflow-%D0%B1%D1%8B%D1%81%D1%82%D1%80%D1%8B%D0%B9-netflow-%D0%B8%D0%B7%D0%BC%D0%B5%D1%80%D0%B8%D1%82%D0%B5%D0%BB%D1%8C/

К Stargazer'у напрямую не относится, но я краем глаза где-то тут слышал, что народ для подсчёта трафика пользуется программными генераторами NetFlow-потоков: softflowd, fprobe, fprobe-ulog. Я попробовал все три по очереди и работают они медленно: на скорости 3-5 МБайт/сек откушивают от 5% до 8% ресурсов процессора (класса Core 2 Duo). Стал искать альтернативный вариант и нашел ipt-netflow - модуль для iptables, предоставляющий цель "-j NETFLOW". Все пакеты, попадающие в эту цель, обрабатываются модулем и отправляются сборщику трафика по протоколу NetFlow. Всё это дело происходит в пространстве ядра и поэтому работает очень быстро: при тех же исходных данных видимой загрузки процессора нет вообще. Автор ipt-netflow (как и уважаемые авторы Stargazer'а ) решил не заморачиваться с Autotools или CMake, а изобрёл свой велосипед написал собственный configure скрипт. Скрипт этот почему-то требует наличия полных исходников iptables и исходников ядра. Хотя на самом деле ему было бы достаточно заголовочных файлов и того и другого. Вообщем, изрядно намучившись и напатчившись, я таки запаковал ipt-netflow в DEB-пакет. Результат своих мучений и выкладываю на ваш суд: https://launchpad.net/~lion-simba/+archive/stargazer/ Это тот же репозиторий, где лежит упакованная мной версия Stargazer. Пакет использует технологию DKMS - то есть при обновлении ядра модуль будет пересобран автоматически.

simba@dahari:/data/src/stg/pure/purestg2$ ls ./stginc actions.h base_store.h ia_packets.h raw_ip_packet.h stg_error.h user_conf.h actions.inl.h blowfish.h ibpp.h resetable.h stg_int.h user.h admin_conf.h common.h lp2_blocks.h rs_packets.h stg_locker.h user_ips.h admin_conf.inc.h common_settings.h mempool.h script_executer.h stg_logger.h user_property.h admin.h conffiles.h mimetype.h servconf.h stg_message.h users.h admins.h corp_conf.h netunit.h service_conf.h stg_timer.h user_stat.h ag_md5.h debug.h noncopyable.h settings.h tariff_conf.h user_traff.h base_auth.h dotconfpp.h notifer.h stdstring.h tariff.h utime.h base_db.h eventloop.h os_int.h stg_common.h tariffs.h version.h base_plugin.h hostallow.h pinger.h stg_comp_stat.h test.h vpn_stg_packets.h base_settings.h ia_auth_c.h rad_packets.h stg_const.h traffcounter.h ./configure --with-stg-headers=`pwd`/stginc проходит на ура. Рекомендуется указывать полный путь к папке с заголовками. И... покажи побольше лога конфигурации.

А мы не будем ждать madf и rc3. Выпустил purestg2 2.1. Качать на гуглекоде: http://code.google.com/p/purestg2/ Список новшеств можно прочитать в файле NEWS. По-русски это будет: Ну или всё то, что я уже описывал в этой теме.

Приказ старгейзеру авторизовать юзверя уходит ДО запуска ip-up и даже ДО запуска auth-up (если он используется). Запрос уходит синхронно, то есть плагин ждёт его завершения. НО. Скрипт OnConnect в старгейзере вызывается асинхроно к авторизации пользователя. То есть, между моментом авторизации пользователя в старгейзере и его подключением (вызовом скрипта OnConnect) проходит некоторое время. Исходя из сказанного, имеющимися средствами нельзя гарантировать определенную очередность выполнения ip-up и OnConnect. Так значит... в pppd есть ещё штатный скрипт ip-pre-up, он выполняется синхронно, но уже после auth-up и соответственно после авторизации в старгейзере. Есть вариант перевесить отправку запроса авторизации старгейзеру на момент сразу после ip-pre-up, но перед ip-up. Тогда в ip-pre-up можно будет помещать команды, которые должны быть выполнены гарантированно до авторизации в старгейзере. Нюанс: в момент вызова ip-pre-up ppp-интерфейс уже существует, но находится в состоянии "down" и ещё не имеет IP адреса. Это как-то может помешать? Если да, то я могу сделать в своем плагине ещё одну опцию наподобие predownscript - preupscript, который будет вызываться до авторизации в старгейзере и до запуска ip-up, но уже после того, как интерфейс окончательно поднят и настроен.

Поторопился с этой опцией. Тесты показали, что оба этих скрипта запускаются асинхронно по отношению к pppd, то есть нельзя гарантировать, что они будут закончены или начаты к моменту отключения пользователя в старгейзере. Поэтому эту опцию выкинул. Вместо неё появилась другая опция - predownscript <путь>. Собственно, выполняет указанный аргументом скрипт синхронно непосредственно ДО отключения пользователя в старгейзере.

Новые плюшки в git: Новая опция в плагине для старгейзера - pppunitsave. Позволяет сохранить номер ppp-интерфейса, выданного юзверю, в поле userdata<pppunitsave>. Новая опция в плагине для pppd - latedisconnect. Управляет тем, когда плагин pppd пошлёт запрос старгейзеру на отключение юзверя. Если опция НЕ задана, то запрос на отключение будет послан ДО запуска скриптов auth-down и ip-down; иначе - после их выполнения. Релиз purestg2 2.1 будет выпущен вскоре после выпуска stargazer-2.407-rc3.

Через конфигуратор ставим пароль админа меньше 8 символов. В MySQL базе в поле password получаем мусор и в следующий раз залогиниться не можем. Полагаю, что это связано со спицификой шифрования пароля блоуфишем, который шифрует блок из 8 байт за раз. Не зануляется буфер перед копированием в него пароля, полученного из конфигуратора?

Скоро будет релиз 2.1. Я сейчас жду ответа madf на некоторые вопросы, и в зависимости от них, релиз 2.1 будет раньше или позже. Но я хотел бы, чтобы до этого его немного потестили. Получить последние исходники из git можно так: git clone git://github.com/lion-simba/purestg2.git Всё остальное как обычно: ./configure --prefix=/usr && make && sudo make install Исправлено. Теперь, при корректной остановке stargazer'а, все pppd соединения должны корректно закрыться. корректно это как? Корректно - это значит, что pppd не просто умирать будет, а перед смертью отправит клиенту пакет, что дескать соединение надо закрыть. Раньше клиенту приходилось об этом самому догадываться и отключаться по таймауту. эмм, лучше бы конечно через пробел, в мускуле проще общаться будет А чем проще?

Изменения в git: Исправлено. Теперь, при корректной остановке stargazer'а, все pppd соединения должны корректно закрыться. Новые плюшки: Опция kickprevious в плагине старгейзера. Определяет, что делать, если пользователь пытается подключиться повторно с тем же логином при наличии уже активного подключения. Если опция отсутствует в конфиге, то плагин не позволит установить второе соединение. Если опция присутствует в конфиге, то первое соединение будет разорвано, а второе, если пароль верный, будет установлено. yKpon, ау?

В репозитории появились пакеты для Ubuntu 10.10 Maverick Meerkat. Пакеты те же, самые, что и для Ubuntu 10.04 Lucid Lynx.

Возможно, madf обратит на это внимание. Давно пора, IMHO, открыть сайт проекта на каком-нибудь бесплатном проект-хостинге - code.google.com, sourceforge.net, ... Отличная доступность и платить не надо.

Последние изменения в git: ... Хотя да, надо бы configure подправить, чтобы выдавал ошибку, если не хватает каких-то заголовочных файлов. Сделано. Сделано. В конфиге появилось три новых необязательных опции: ipparamsave = X ipparamauth = Y # X не равно Y allowemptyipparam # требует наличия опции ipparamauth Если задан ipparamsave, то при подключении пользователя его ipparam (то, что передалось в pppd) будет записан в userdataX. При отключении пользователя userdataX НЕ изменяется. Если задан ipparamauth, то на этапе аутентификации пользователя, если его ipparam отсутствует в userdataY (список через запятую), то аутентификация считается неудачной. Если поле userdataY пустое, то аутентификация всегда считается удачной. Если ipparam не был задан в pppd, то аутентификация всегда считается неудачной. Если задана allowemptyipparam, то аутентификация пользователя с пустым ipparam (не заданным в pppd) всегда считается удачной. Ни одна из этих опций не отменяет проверку пароля пользователя, а используется лишь как дополнительное средство. Сделано. Товарищ yKpon осилит сборку модуля из git или сделать релиз в tar.gz?

Можно, но это ничем не будет отличаться от тех же ПИНГ пакетов со стороны pppd в сторону старгейзера каждые N секунд (см. пункт 5 первого сообщения темы). Мда, действительно. Надо, наверное, подписку на connected вынести наружу. На выходных посмотрю что можно сделать. Вот этот вариант мне гораздо больше нравится. Пока оставляю как есть, а когда будет на что подписываться - переделаю.

Можно подписаться на currIP. Пот отключении он обнуляется, а при подключении туда попадает IP абона. А вот и нельзя. currIP меняется в USER::Authorize() и USER::Unauthorize(). Если же отключение юзверя происходит со стороны старгейзера (disabled, passive, кончились деньги), то старгейзер делает USER::Disconnect(), а USER::Unauthorize() не происходит. Ещё идеи? ---добавлено--- Вижу USER_PROPERTY<bool> USER::connected; но оно приватное.

А откуда этот IP берётся? Я вот знаю только, что PopTop (pptpd) передаёт IP подключающегося через ipparam в pppd. Но, допустим, pppoe-server этого не делает (хотя мог бы передавать MAC).

Угу. По идее, повисшие сессии должны были оборваться сами по прошествии keepalivetimeout * 2 секунд. Любопытно, что удаление сокета помогло. У меня не получилось удалением сокета сбросить повисших юзверей. А по-хорошему, нужно делать нормальный двунаправленный обмен событиями между старгейзером и pppd, чтобы инициировать события мог не только pppd, но и старгейзер. А для этого, было бы неплохо в плагине старгейзера подписываться на изменение статуса пользователя IsInetable() как, скажем, на изменение настроек. Вообщем, я ещё подумаю в эту сторону.

Если xl2tpd в итоге запускает pppd, то да - подходит. Просто я с ним не сталкивался. Точно работает с PopTop (pptpd) и pppoe-server (из пакета pppoe). Бегло поглядел. Похоже, что такой возможности для плагинов pppd не предоставляет. Отлично, чем больше отзывов, тем лучше.

потому что: Если поставить пакет stargazer-dev из моего репозитория, то должно собраться. Либо можно руками все .h файлы из дистрибутива старгейзера скинуть в одну папку и при сборке purestg2 указать: ./configure --with-stg-headers=/путь/к/папке Хотя да, надо бы configure подправить, чтобы выдавал ошибку, если не хватает каких-то заголовочных файлов.

Угу. Я думал про new/delete, но у меня там ещё realloc, а в "man realloc" написано, что Поэтому я испугался и заюзал malloc и free. Впрочем, можно переехать на std::vector. А, я вспомнил, почему не выбрал std::vector. Массив struct pollfd* connections потом уходит в функцию poll, которая ждет на вход обычный СИ массив и с std::vector работать не умеет. Впрочем, в других местах можно и std::vector использовать. А чем лучше? Ага. И эти заголовочные файлы должны по команде make install тоже устанавливаться куда-нибудь в ${prefix}/usr/include/stargazer/ по идее. Сейчас система сборки purestg2 рассчитывает на то, что все заголовочные файлы старгейзера лежат в одной куче в /usr/include/stargazer/, либо можно указать другую папку, но они должны быть в куче.

Плагин авторизации для Stargazer, который работает напрямую с pppd Общая информация Страница проекта (NEW!): http://lion-simba.github.io/purestg2 Последняя версия (NEW!): 2.4 (04.04.2015) Исходный код: https://github.com/lion-simba/purestg2 Лицензия: GPL Предложения и пожелания принимаются. Возможности - простота конфигурации. - возможность задавать минимальный номер ppp-интерфейса. Это удобно, когда на сервере висит несколько upstream-подключений к провайдеру на ppp0-pppX, и чтобы отличать подключения юзверей от upstream-подключений, им удобно выдавать интерфейсы начиная с pppY, где Y > X. - возможность присваивать IP-адрес клиента прямо из Старгейзера. - возможность сохранения номера ppp-интерфейса в любое поле userdata при подключении. - возможность сохранения параметров ipparam и callingnumber из pppd в любое поле userdata. - возможность проводить дополнительную аутентификацию пользователя по наличию ipparam и callingnumber из pppd в списке в указанном поле userdata. - возможность автоматически отключать предыдущую сессию пользователя при открытии новой. Удобно, если у клиента есть несколько разных компьютеров, с которых он может подключаться, и он забыл закрыть сессию на одном из них. - корректное закрытие ppp-сессии в случае отключения пользователя Старгейзером. Требования Stargazer не ниже 2.408. Версия purestg2 2.2 работает со Stargazer 2.407. Версии purestg2 до 2.2 работают со Stargazer 2.407-rc2. pppd - 2.4.4-2.4.5 и возможно другие. Обзор Плагин состоит из двух частей - собственно модуля для Stargazer (mod_auth_purestg2.so) и плагина для pppd (purestg2.so). При старте старгейзера создается UNIX domain socket с адресом, указанном в конфиг-файле (например - /var/run/purestg.sock), который ожидает подключений от плагина для pppd. Когда pppd с активированным плагином стартует, он подключается к этому сокету (адрес опять же настраивается в опциях pppd) и делает буквально следующее: 1. Запрашивает у Старгейзера номер ppp-интерфейса, который нужно присвоить клиенту (ppp5, ppp12 и т.п.). Номер выбирается из числа ещё не выданных номеров, начиная с некоторого номера minppp, который задаётся в настройках модуля. 2. Когда pppd становится известен логин подключающегося пользователя, он отправляет его Старгейзеру с вопросом: а может ли этот пользователь получить доступ? Если может, то Старгейзер в ответ отправляет пароль пользователя. 3. pppd, используя присланный старгейзером пароль, выполняет аунтентификацию пользователя. Поддерживаются как PAP, так и CHAP методы (включая MS-CHAP-v2). 4. Если аутентификация удалась, то pppd запрашивает у Старгейзера IP-адрес, который нужно присвоить пользователю, согласовывает его, а затем шлёт Старгейзеру команду "подключить пользователя". С этого момент пользователь в старгейзере считается online. 5. Каждые N секунд (N задаётся в опциях pppd) pppd шлёт Старгейзеру ПИНГ с вопросом "пользователь всё ещё имеет доступ?". Если старгейзер отвечает "Нет" или не отвечает в течение ещё N секунд, то PPP-соединение разрывается. Это нужно, например, если отключение пользователя происходит со стороны Старгейзера (скажем, из-за нехватки средств на счете). Когда пользователь сам разрывает PPP-соединение, pppd шлёт команду старгейзеру "отключить" пользователя и аккуратно закрывается. Получился этакий себе мини-RADIUS.

Итак, обновления в репозитории. Будут доступны как только launchpad их соберёт. Теперь общее число собираемых бинарных пакетов из одного исходного - 24. Думаю - не стОит. Хотя нужно еще подумать дважды, чтобы дать правильный ответ Так вот, я тут подумал. Дважды. 1) Если старгейзер не останавливать при обновлении, а просто заменить все файлы новыми версиями, то это может нарушить целостность данных. Скажем, если произошло изменение в схеме БД, то старая работающая версия старгейзера рано или поздно об это споткнется и упадёт. Нехорошо. 2) Если старгейзер принудительно останавливать при обновлении, то это значит, что при любом неосторожном apt-get upgrade можно случайно выключить биллинг. 8) Незапланированный отказ в обслуживании - тоже плохо. Поэтому решил сделать так. Установщик будет проверять, запущен ли в данный момент биллинг. Если запущен, то обновление не происходит совсем, а администратору выдается сообщение. Если биллинг не запущен, то обновление происходит штатным образом. После обновления (или установки) биллинг нужно запустить вручную (на тот случай, если захочется проверить конфиги, что-то подправить и т.п.). При удалении пакета биллинг останавливается автоматически. На хранение пароля админа в виде хэша можно переехать и без нарушения обратной совместимости с авторизатором/конфигуратором, ибо, насколько я понял, этот пароль никуда за пределы сервера не выходит. Но опять же, я ничего плохого не вижу в том, чтобы поменять протоколы авторизатора/конфигуратора с некоторой версии Х. А с OpenSSL вообще красиво было бы. Нужно стараться по-максимому использовать чужой код. Я про обратную совместимость с БД. Если, например, PostgreSQL и Firebird хранят внутри себя версию схемы БД то у файловой базы и MySQL такого нет. Хотя, конечно, можно попробовать сделать. Надо подумать над этим. Можно просто поставлять вместе с очередным выпуском старгейзера скрипты для соответствующей модификации существующей БД (а для файловой БД можно извратиться с Perl'ом, например). Я у себя в пакетах могу их автоматически запускать при обновлении. Хотя конечно было бы приятственно, если бы модули хранения сами заботились о версии и конвертировали данные при записи. С другой стороны, этот способ будет означать, что код для чтения старых версий придется всю жизнь таскать с собой (libcrypto, ага). По поводу dev-пакета согласен. Проверил. Действительно, заголовочных файлов вполне достаточно. Но. Они все разбросаны по разным частям исходников. Так, например, можно было бы подумать, что все общие заголовочные файлы содержаться в папке include, однако, допустим в файле base_plugin.h мы видим следующую конструкцию: class ADMINS; class USERS; class TARIFFS; class TRAFFCOUNTER; class SETTINGS; class BASE_STORE; //----------------------------------------------------------------------------- class BASE_PLUGIN : private NONCOPYABLE { public: virtual ~BASE_PLUGIN(){}; virtual void SetUsers(USERS * u) = 0; virtual void SetTariffs(TARIFFS * t) = 0; virtual void SetAdmins(ADMINS * a) = 0; virtual void SetTraffcounter(TRAFFCOUNTER * tc) = 0; virtual void SetStore(BASE_STORE * st) = 0; virtual void SetStgSettings(const SETTINGS * s) = 0; При этом определений классов ADMINS, USERS, TARIFFS, ... в заголовочных файлах папки include нет. Они определены в заголовочных файлах проекта stargazer. А многие заголовочные файлы проекта stargazer, в свою очередь, используют заголовочные файлы библиотек старгейзера (например, admins.h включает в себя stg_locker.h, который лежит в stglibs/stg_locker.lib). Получается, я вынужден собирать заголовочники из разных мест. Появляется вопрос, в -dev пакете их валить все в кучу или как-то разбивать по подпапкам? Моё предложение: навести порядок в заголовочных файлах проекта и всё, что необходимо для разработки сторонних модулей, вынести в папку include. А всё лишнее (если оно там есть) оттуда убрать. На данный момент в -dev пакет кладутся следующие заголовочные файлы: include/*.h /usr/include/stargazer/ stglibs/common.lib/*.h /usr/include/stargazer/ stglibs/stg_logger.lib/*.h /usr/include/stargazer/ stglibs/stg_locker.lib/*.h /usr/include/stargazer/ stglibs/crypto.lib/*.h /usr/include/stargazer/ projects/stargazer/admin*.h /usr/include/stargazer/ projects/stargazer/user*.h /usr/include/stargazer/ projects/stargazer/eventloop.h /usr/include/stargazer/ projects/stargazer/traffcounter.h /usr/include/stargazer/ projects/stargazer/settings.h /usr/include/stargazer/ projects/stargazer/tariff*.h /usr/include/stargazer/ projects/stargazer/stg_timer.h /usr/include/stargazer/ projects/stargazer/actions*.h /usr/include/stargazer/ Ну понятно. В принципе-то... не должно быть сильно сложно сейчас взять и убрать везде -shared, оставив только статическую линковку. На английский? Это позитивно. Надо бы ещё ChangeLog перевести, да и в commit'ах git'а использование английского языка могло бы снизить барьер вхождения для не-украинских разработчиков.

Как раз вопрос именно в этом - я модифицировал файл перезапуска сервера, если буду пользоваться этой версией - возможно буду модифицировать именно Upstart-скрипт. Поэтому отсюда вопрос - стоит ли идти по такому пути - ведь в случае обновления он будет перезаписан новым. Нет, не будет. Он помечен в пакете как "файл конфигурации". Это значит, что если в нём будут локальные изменения, установщик при обновлении спросит, что с ним делать - оставить старый или поставить новый. Может даже diff показать между ними. Вопросов не было потому, что вы не установили другие модули хранения. Вы сделали apt-get install stargazer который по умолчанию утянул за собой модуль хранения в файлах - stargazer-storage-files. Попробуйте сейчас сделать: apt-get install stargazer-storage-mysql и увидите вопрос.

Да. Как только я соберу свежую версию. Я думаю, вы второй человек (после меня), кто пробует этот репозиторий. Даже я его ещё на продакшн-сервере не применял (но собираюсь). Вообщем, до поры до времени, я бы относился к нему как к Beta-версии. Тем не менее, обещаю быть как можно более аккуратным при обновлении версии. Мне нужно больше отзывов. Сейчас в скриптах прописана перезагрузка только в случае переконфигурации (dpkg-reconfigure). При обновлении - будет продолжать работать старая версия до момента её ручной перезагрузки. Можно сделать и автоматически, но стоит ли? /etc/init.d/stargazer в пакете не используется (файл такой есть, но это просто заглушка), я использую Upstart - /etc/init/stargazer.conf.

Спасибо. ) Поглядел. В репозиториях убунты судя по всему нет этой библиотеки, так что буду использовать внутреннюю. Да, точно. Плагины тоже можно раскидать по пакетам. Вот о чем и речь. Чехарда с кодировками. Значит нужно править везде одновременно - и в сервере, и в конфигураторе и в авторизаторе. Кстати, если авторизатор/конфигуратор при соединении с сервером сообщают ему свою версию, можно даже обратную совместимость сохранить. Хотя в принципе я не вижу ничего плохого в том, чтобы потребовать юзверей скачать новую версию авторизатора. На хранение пароля админа в виде хэша можно переехать и без нарушения обратной совместимости с авторизатором/конфигуратором, ибо, насколько я понял, этот пароль никуда за пределы сервера не выходит. Но опять же, я ничего плохого не вижу в том, чтобы поменять протоколы авторизатора/конфигуратора с некоторой версии Х. А с OpenSSL вообще красиво было бы. Нужно стараться по-максимому использовать чужой код. Оказывается, в репозиториях убунту есть dotconf, а не dotconfpp (С++'ный вариант). Так что эту тоже буду использовать внутреннюю, тем более что она доработанная. Вообщем, я тут ещё провёл анализ использования библиотек старгейзера различными его компонентами и плагинами и пришел к следующим выводам: 1) Сторонние плагины для старгейзера совершенно не обязательно линковать с библиотеками старгейзера. Достаточно, чтобы при сборке плагина были доступны все необходимые заголовочные файлы (часть из папки include, а часть из папок с библиотеками stglibs/*.lib/). 2) Причиной вынесения части кода старгейзера в библиотеки (so-файлы) явилось то, что этот код используется в нескольких проектах (сам сервер, авторизатор, конфигураторы, rscriptd, ...). Поэтому... так как библиотеки старгейзера фактически являются частями самого старгейзера и никаких целостных законченных функциональных возможностей не предоставляют, выносить их на общесистемный уровень (/usr/lib/), а также в отдельный пакет, смысла не имеет. За исключением, пожалуй, ibpp и dotconfpp. Однако, я довольно далёк от Firebird, чтобы поддерживать его библиотеку. А что касается dotconfpp, то, раз это модифицированный вариант, опять же выносить в отдельный пакет смысла нет. Вот тут я бы тоже посмотрел, что нынче является стандартом де-факто для парсинга конфигов. Наверняка ведь есть что-то удобное. Итого получается, что для разработчиков сторонних плагинов требуется создать -dev пакет, который содержит все необходимые заголовочные файлы и только и всего. Позже эту гипотезу проверю. PS. Ещё один мелкий патч (useless-conffiles-binding.patch): MySQL store plugin doesn't use any external conffiles. --- a/projects/stargazer/plugins/store/mysql/Makefile +++ b/projects/stargazer/plugins/store/mysql/Makefile @@ -8,7 +8,7 @@ SRCS = ./mysql_store.cpp -STGLIBS = -lconffiles -lstg_common -lstg_crypto +STGLIBS = -lstg_common -lstg_crypto MYSQL_CFLAGS = $(shell mysql_config --cflags) MYSQL_LDFLAGS = $(shell mysql_config --libs_r)