Genius

По-моему ситуация обстоит несколько по другому. Шейпера нет, но прикрутить простой шейпер на cbq, htb - без проблем. Для 23 компов этот вариант подойдет без проблем даже с перспективой роста до 100ни. Есть модуль оплаты по карточкам от разработчиков, правда не знаю насчет его работы с новыми версиями. http://stg.dp.ua/modules.php

На мой взгляд функция очень нужная. так как часто добавляешь абонентов с предоплаченным траффиком в середине месяца, и считать им ручками метры - несколько странно. Я бы еще добавил функцию чтобы оно и абонентскую плату пропорционально прошедшему периоду снимало, в 2.0 версиях такого не было.

СТГ при стандартной сборке все равно будет захватывать все пакеты, а запись NULL будет означать лишь потом отбрасывать их при подсчете. Для лечение данной проблемы собирать STG через libipq linux Или считать через divert в freebsd

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

Думается мне что сервер не может работать одновременно с AlwaysOnline и нескольких ИПов у одного пользователя. Для такого случая думаю надо сделать несколько логинов и прописать им всем AlwaysOnline.

Я у себя такие случае видел и сделал почти 100% вывод что это иет при перегрузке процессора. Решения: апгрейд машины или lib_ipq уменьшение количества считаемого траффика если там считались какие нить локалки.

Решил скомпилить, попробовать, не компилится: OS 2.6.15-gentoo-r1 x86_64 AMD Athlon 64 X2 Dual Core Processor 3800+ # ./build ############################################################################# Building STG 2.4 for Linux ############################################################################# Makeing stg_logger.lib ../Makefile.in:74: deps: No such file or directory g++ -g -Wall -I ../../include/ -I ./ -DLINUX -DSTG_TIME -c stg_logger.cpp ar rc libstg_logger.a stg_logger.o ranlib libstg_logger.a cp stg_logger.h ../../include/ cp libstg_logger.a ../../lib/ M

cat /var/log/stargazer.log | grep Admin - выведет все действия админские cat /var/log/stargazer.log | grep cash - все поплнения счета cat /var/log/stargazer.log | grep login_kassira - все дейсвтия данного кассира. И т.п. можно сделать все что угодно. Чтобы делать разбивку по месяцам копай в сторону ротации логов например logrotate

Абсолютно нормально, никаких доп. настроек, я его по сути из-за этой возможности и начал использовать.

Щас будет мат часть по специальности из калькулятора: 24994167 - байты 24994167/1024 = 24408,3662109375 килобайты 24408,3662109375/1024 = 23,83629512786865234375 мегабайты, если округлить будет 23,84. Теперь внимание вопрос, что ты еще хочешь от биллинга? И в чем собственно проблема?

Нет, кило это 2 в 10ой), вспоминая анекдот про обычного человека и программера... Если необходимо считать по 1000 править в сырцах, но багов боюсь не оберешь при передаче данных от сервера в авторизатор, лучше цены поменять если нужная такая точность.

У мя тоже такое было 2 раза на моей памяти, в одном и том же интервале времени (в 10 минут), в детальной статистике сначала трафф считается как локал (как написано в rules) а потом тут же считает как интернет и снимаются деньги, писал на форуме, но никто не ответил, баг вообщем на лицо.

libipq не выпустит пакет из очереди пока он не пройдет через обработчик. И главное что ты можешь не гонять в очередь все пакеты (собственно из-за чего такая загрузка на проц) а пропускать только необходимые подсчету, таким образом снижается загрузка. Почему скидывает - хз, но я видел такое пару раз в такой ситуации тормозит консоль - а это последнее дело, то есть загрузка проца максимальна.

Только при совпадении всех версий динамически слинкованных библиотек, вообщем лучше так делать не стоит.

libipq можно собрать только из сырцов, система от этого не засорится я думаю), хотя во всех rpm based системах это конечно неприятно.

Когда загрузка 100% на проц держится порядка минуты, может 2, он либо отрубает всех пользователей и через минуту подключает обратно, или просто вываливается без отключения пользователей (при стандартном методе сбора пакетов)

Ээээ, на мой взгялд глюки несколько другие: 1. Глюк обнуления статов (не сталкивался с ним тьфу тьфу тьфу уже год как) 2. Падения сервера без отключения пользователей (тьфу тьфу тьфу кроме отклюения питания без УПСы не встречал) 3. Глюк NOT DELETED FROM INDEX встречается после удаления пользователя конфигуратором, в таком случае не отключает остальных пользователей, лечится перезапуском после любого удаления пользователя, не сильно мешает, так как удаление пользователя процедура редкая. 4. Отваливается СТГ при превышении нагрузки, можно пересобрать с libipq думаю не бубедт такого бага.

Смотри по загрузке пользователей, у меня ситуация машинка Gentoo 450Celeron, считает траффик примерно 50 пользователей уходящий в интернет (до 1Мбита), и в две другие подсети (100Мбит каждая), скажу сразу при пиковых нагрузках работает на пределе. Так что считай сам. На серваке моем других сервисов вообще нет крмое системных. Смотри сам по загрузке на проц, в принципе я думаю впишешься, но очень неправильно ставить Файловый и Биллинг серв на одной машине.

Ну например если у тебя направление Интернет 0, то да. Соответственно допустим цена у тебя 0.5ед за Мб, и в тарифе стоит 20 Мб халявных то пользователям достанется и будет писатся по 40Мб. Примерно логика такая.

Ты осознаешь что 2 это номер направления на деньги которого перерасчитываются FreeMB?

Большинство людей я думаю использует последний build 2.016.7.6 , принципиальных глюков не много, есть случае неправильного отключения клиентов "NOT DELETED FORM INDEX" (вылезает только при удалении акков), в остальном ничего фатального.

Это простая проблема, когда пользователь делает logoff сеанса все процессы закрываются принудительно и соответственно inetaccess не отсылает команду на закрытие подключения, в такой ситуации подключения разорвется только через timeout секунд установленное в конфах. По-моему 15 секунд не есть фатальная проблема для чего-бы то ни было. Можно уменьшить время таймаута проверки клиента.

ПРиоритет максимальный нужен чтобы биллинг ни при каких условиях (другие пиковые нагрузки) не пропустил пакеты мимо себя. Это принципиально только на слабых машинках на которых работают активно другие демоны.

Можешь отредактировать скрипты onConnect onDIsconnect и проверять баланс клиента, если там денег меньше чем абонентская плата но еще остались бесплатные МБ то включать только соответствующие направления (или не включать).

У этих пользователей этой галочки точно не было, так что проблема где то еще. Ну если выполняется то значит проблем не так много, она по крайней мере скорее всего в ошибке в скрипте, может права пользователя от которого запущен СТГ?