madf

С RedHat/CentOS никогда не работал, по этому по зависимостям не подскажу. Чистить дет. статистику можно как угодно, она в самом Strargazer'е не используется.

А вот это практически убийство - возможность использовать абстрактные лееры к БД возможно только до поры до времени. На первом же чуть более сложном джойне вся мультибазность становиться фикцией и требует массивного дублирования кода что превращает его по сути в месиво и делает сверхнапряжным дебаг. Собственно я начинал писать свою мордашку з заточем под мускуль/файбирд когда еще постгря была в анонсах. Закончилось просто более менее уверенной работой с мускулем о чем не тоскую Со всем остальным вами высказанном полностью согласен. Я в свое время ковырял AdoDB для PHP - мне понрав

Альтернативный конфигуратор уже готов. И даже частично протестирован. И даже на него написана подробная документация. И даже есть в 2.407-rc1. Просто не анонсирован и запрятан среди плагинов Называется XML RPC. Умеет все что умеет виндовый конфигуратор (в т.ч. управление тарифами и админами) и еще пару специфических фишек. Я его успешно использую из PHP и из Haskell. Привязки есть почти ко всем языкам.

sleep некошерно. А остальное зависит от дистрибутива. Но идея такая: сделать базу зависимостью для Stragazer. Т.е. стартовать его только после полного старта базы. К стати, что за СУБД и на сколько "выросла очень"? У нас за 6 месяцев на серваке с 300/800 примерно 140 Гб занимает. При чем сами данные около 100 Гб, остальное - индексы. И стартует все довольно шустро на не самом быстром железе и не самых быстрых винтах.

))) ну зачем мне врать? пишу все как есть PS вот libsrvconf.so либа с которой были проблемы Мне этот бинарник все равно ничего не скажет. Но с undefined symbol оно запуститься не может. Не может и все тут. Ну никак.

Это на 2.407-rc1? Если да то прошу собрать в отладочном режиме и сделать следующее (когда этот баг снова проявится): $ gdb /path/to/stargazer (gdb) attach <stargazer's_pid> (gdb) thread apply all bt Выхлоп последней команды заслать мне на faust@stg.dp.ua. Если используется более ранняя версия - прошу подтвердить этот баг на 2.407-rc1. в этой версии пофиксено это? http://local.com.ua/forum/topic/21317-novii-mesjac-i-ne-snjalas-abonplata-nekotorih-juz/page__view__findpost__p__160807 2.407-rc1 от 19 апреля, а эти патчи были позже. В принципе они подойдут для 2.407-rc1.

чесно - не знаю, первый выдает это, 2й раз - виснет и вешает сервер. Если тоже самое сделать на другой порт (2го модуля) - сервер "отъедает" уже и второе ядро. Нет, ну реально - оно не может запуститься. Может это откуда-то старая версия вылазит?

пусть даже после некоторого времени когда у него кончится место в памяти пусть героически падает, но не сразу же после падения связи с мускулом Не, героически падать не нужно. Можно просто начать терять старые данные. Но этого пока не реализовано. Сейчас он будет героически работать пока не съест всю память и ядро не прибъет его OOM Killer'ом.

а каким местом stg по вашему вообще связан с "пропуском трафика"? Если перехват с IPQ - то непосредственно. да, через IPQ Это на 2.407-rc1? Если да то прошу собрать в отладочном режиме и сделать следующее (когда этот баг снова проявится): $ gdb /path/to/stargazer (gdb) attach <stargazer's_pid> (gdb) thread apply all bt Выхлоп последней команды заслать мне на faust@stg.dp.ua. Если используется более ранняя версия - прошу подтвердить этот баг на 2.407-rc1.

тоже самое надо сделать в srvconf.lib LIBS = -lexpat -lstg_crypto иначе консольный конфигуратор ругается: "/usr/local/bin/sgconf: symbol lookup error: //usr/lib64/stg/libsrvconf.so: undefined symbol: _Z13Blowfish_InitP12BLOWFISH_CTXPhi" а при 2м запуске "вешает" сервер и тот "кушает" 100% cpu , но при этом работает Спасибо. Хотя проявляется, видимо, только на биарче. К стати, а как оно может запуститься? Там же undefined symbol!

1. Еще бы divert вспомнили. Я правда не могу придумать ни единой причины по которой их можно и нужно использовать на скоростях более 10 мбит. 2. Попахивает извращением - в отсутствии 100% надежности БД в которой собственно деньги и хранятся если уж на то пошло. Сложно представить себе адекватное поведение старгейзера которому некуда написать деньги/стату в таком случае. Вот что он должен с ними делать? Сохранять несохраненные данные в лог для последующего ручного анализа и акуратно самокиллалиться? Выглядит точно так же как и рассмотрения "адекватного поведения старгейзера" в случае пр

а каким местом stg по вашему вообще связан с "пропуском трафика"? Если перехват с IPQ - то непосредственно. Да, но достаточно сложно. Если кто-то возьмется - рекомендую посмотреть как это сделано в mod_store_postgresql. А почему мускул должен вообще отваливаться? Например если он на удаленном хосте.

Вполне может быть. При нажатии "Отключиться" отсылается DISCONN_SYN, и если он теряется - отключения не происходит.

А чем перехватывается трафик?

перезапуск ничего особо не давал. помогло в стг в конфиге выключил модуль бфп_кап(казись так) - рестарт стара -поднялся роботает-стоп стара - включил модуль-старт стара - поднялся - все гуд Шаманизьм чистой воды. Такого не может быть потому что не может быть никогда. А как трафик собирается: через BPF или NetFlow? Если первое - то зачем тогда cap_nf? Если второе - то проблема была вызвана NetFlow-сенсором. Это то что я всегда имею в виду когда не советую использовать mod_store_mysql. Что-то было испорчено в таблице users, из-за чего плагин молча падал и тащил за собой весь Sta

Да, но достаточно сложно. Если кто-то возьмется - рекомендую посмотреть как это сделано в mod_store_postgresql.

Ни разу не собирал в отладочном режиме. Подскажи команду, пожалуйста. $ build debug $ make Можно запускать прямо из сборочного каталога, но тогда в конфиге нужно прописать путь к плагинам в сборочном каталоге и перед запуском устанавливать LD_LIBRARY_PATH=../../lib А можно сделать sudo make install-bin и запускать ка обычно. Но нужно иметь в виду что при этом stargazer не становится дэмоном и начинает сыпать в консоль лог, о котором я и говорил. Так что в скрипты запуска имеет смысл добавить перенаправление вывода в файл и оператор & в конце.

Попробуй собрать в отладочном режиме и посмотреть что он будет в консоль писать. Количество юзеров тут не при чем. Вынесение Stargazer'а из общего трафика мысль правильная, но тут она вряд-ли поможет, т.к. потерь пакетов и лагов по ним я не вижу.

да, DBA нужен, а индексы в отличии от фс всегда висят в памяти а не ищуться хз где. Благо CMS на текстовках уже понаписывался - быстродействие равное/выше только на очень незначительных количествах данных с вложеной папочной структурой. Когда приходиться вызвать рекурсивный и не самый быстрый по своей сути scandir() плюс сделать несколько тысяч fopen()/fclose() как бы нормальная бд с нормальными индексами получается значительно в выигрыше Это если поиск по содержимому файлов. А тут у нас структура каталогов дает сразу индекс по логину и дате. И никакого scandir и поиска по содержимому -

Ну кроме считалки и классификатора, еще снималка денег и авторизалка =) Кажись как бескрайнее поле для писательства внешнего обвеса, причем заточенного под конкретную специфику. Все универсальные решения обречены на монструозность и негибкость. Ну зачем же сразу монструозность. Просто сделать нормальное управление пользователями, сервисами, систему событий и т.д. И все будет классно

Относительно этого мое предложение следующее: Реализованный на данный момент счетчик трафика очень хорошо зарекомендовал себя в работе, аналогично и авторизатор. Но они работают с одной записью логин-пароль-ip. Если создать отдельную таблицу, в которой будет храниться основной логин и пароль и прочее описание учетной записи. Так мы получаем виртуальную клиентскую запись. К этой записи привязываем денежный счет, который клиент и будет пополнять, не задумываясь на какие услуги пойдут деньги в дальнейшем. К этой виртуальной учетке привязываем столько логинов и паролей (то есть конкретных П

Не знал о таком баге. А как по мне, так правильнее было бы при нажатии кнопки выход пользователем, сначала отсылать закрытие соединения а потом делать закрытие приложения. Или сделать это опционально в конфиге. Угу, надо на закрытие поставить дисконнект. Добавил в TODO.

Не помогло увеличение cash-а (на примере абонента 172.16.17.3): Еще увеличил вдвое в stargazer.conf в <Module auth_ia>: UserDelay=30 UserTimeout=120 Вот лог абонента: 2010-05-31 16:40:56 -- Connect, 172.16.17.3 2010-05-31 16:42:56 -- Disconnect, session upload: '184,530298,0,0,0,0,0,0,0,0' session download: '1070,13345460,0,0,0,0,0,0,0,0' month upload: '4023068,16946293708,0,0,0,0,0,0,0,0' month download: '12577342,46539311332,0,0,0,0,0,0,0,0' cash: '1' 2010-05-31 16:44:58 -- Connect, 172.16.17.3 2010-05-31 16:59:28 -- Disconnect, session upload: '2484,66227124,0,0,0,0

А по моему мотивация вполне очевидна. Stargazer был хорош в том виде в котором он есть сейчас лет 5-10 назад. Сегодня его функционала не хватает. Обвязки внешними скриптами решают только простейшие проблемы. Если делать что-то более серьезное - приходится отказываться от внутренних механизмов Stargazer'а и прибегать к написанию внешних эквивалентов. Таким образом Stargazer из биллинговой системы вырождается в обычную считалку трафика (ну еще плюс классификатор). У меня тоже зреют наполеоновские планы, но силами одного разработчика их реализовать невозможно. Я периодически делаю призывы вкл

какие гарантии? это опынсорц детка (С) Обоснуйте (С) Возможно просто нужно уметь нормально писать? поверьте чувствуется на любых непионерных размерах сети Проверьте сколько у вас будет парситься из текстовок детальная стата по 2-3к пользователей вместо SELECT * с индексами по нужным полям. Wrong! Файловая система со структурой каталого - это уже прообраз таких индексов. Быстродействие примерно равное, но для БД еще нужны индексы. Без них БД работает медленнее. Даже нет, не так. Для БД еще нужен DBA