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

А настройка в тарифах параметра "Минимальный трафик" не решает вашу проблему?

У меня немного другой принцип. Месяц не пользовался - снимается другая сумма - за сохранение порта в свиче за клиентом. Как это организовать? Сумма за содержание + уменьшенный на эту сумму тариф - как бы не интересно. Можно и забыть установить или клиенты могут зайти в свою клиентскую статистику, а иные еще умеют читать. А если сделать отдельным модулем - не пользовался инетом - не сняло за инет а сняло другую сумму. Или же сделать в услугах. Трафик не поднялся выше указанного размера то снимается сумма за содержание порта?

А, кстати, да. Такой вариант для тебя проще всего. Там при месячном обсчёте проверяется трафик и если он меньше указанного - снятие не начисляется.
Можно прямо в условие проверки добавить снятие нужной тебе суммы, которую, для удобства, прописать в конфиги.
Хотя, конечно, надо подумать, не нужно-ли при таком снятии ещё какие-нибудь дополнительные условия проверять?

А... Вон оно что! Народ хочет, чтобы вообще минусов не было. Даже за один месяц.

Объясните, что имеется в виду под "клиенты уходят в минуса"? А то я смотрю, у всех глобальные проблемы, а я понять не могу, в чём дело. Может, мне уже пора начинать беспокоиться?

Начался новый период, у клиента сняло за один месяц - и всё. Если денег на счету недостаточно - сидит с минусом за один месяц, интернета не получает, пока не оплатит. Хоть год будет не платить - меньше, чем минус один период у него не будет. Оплатил - стало на счету ноль и он работает месяц с момента оплаты.

Или это неправильный алгоритм и должно работать как-то по-другому?

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

За что наказывать? У вас в договоре с клиентом написано - не парсить выдачу гугла?

Хотя, конечно, человека нужно найти и объяснить ему, что так он делает себе-же хуже - парсить выдачу гугла нужно используя прокси-серверы, не сохраняя куки, изменяя значение User Agent, и лучше всего - в несколько потоков, так оно быстрее будет

Я думал речь идет о всем железном парке. А то что Вы описали решается намного более гуманным и не костыльным методом. Смотрите HAproxy, например :
httр://mysql.wingtiplabs.com/documentation/hap225xe/fail-over-mysql-with-haproxy

Всё железо в облако не утянешь - что-то и на бренной земле должно остаться, чтобы было куда подключать абонентские кабели.

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

Необязательно-же делать именно кластер? Для целей биллинга достаточно синхронизировать базу данных основного и резервного биллинговых серваков.

А дальше схема примерно такая:
Сателлиты обращаются к биллингу не по адресу, а по доменному имени, которое завязано на динамик ДНС.
Резервный сервак пингует это-же имя, и если не получит ответа - запускает у себя клиентский скрипт динамик ДНСа, чтобы "перетянуть на себя" запросы сателлитов.

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

Люди неужели не кто не пользуется Dr.Web Enterprise Security Suite
мне нужен модуль, готов купить. РАЗРАБОТЧИКИ HELP

Так разработчики или телепаты? Вы-бы хоть объяснили, что этот модуль делать должен.

Вообще, странное сочетание - Энтерпрайз секьюрити и биллинг. Оно, по-идее, применяется в разных местах.

Клиенты жалуются, что "при входе в интернет" их браузеры иногда "зацикливает". Похоже, что циклит модуль заглушки. Выглядит это как дописывание этого-же адреса в конец адресной строки:
 
httр://billing.mynetwork.com/cgi-bin/cap.pl?url=httр://billing.mynetwork.com/cgi-bin/cap.pl?url=httр://billing.mynetwork.com/cgi-bin/cap.pl?url=httр://billing.mynetwork.com/cgi-bin/cap.pl?url=httр://billing.mynetwork.com/cgi-bin/cap.pl?url=httр://billing.mynetwork.com/cgi-bin/cap.pl...

И так оно дописывается и моргает, пока испуганный клиент не нажимает в браузере "Стоп".

Пытался моделировать на своих компах - воспроизвести глюк не получилось, заглушка отрабатывает как положено. Но факт имеет место быть - регулярно звонят недовольные клиенты, да и монтажники наблюдали это чудо самолично, правда, не смогли диагностировать, почему это происходит. Что за чертовщина? Как её победить?

Мне неважно, как оно там хранится, мне нужно, чтобы на графике показывало скорость. Потому как тарифы у нас в Мегабитах в секунду, а не в Мегабайтах за 5 минут. И клиент должен иметь возможность, зайдя в статистику, убедиться, что он получает свою скорость. Без необходимости заниматься вычислениями.

Подскажите, в каких крокодилах отображается трафик на графике в клиентской статистике?

Попробуй в файле web/user/traf_graph.pl заменить
SELECT time, SUM(`in`) AS traf_in, SUM(`out`) AS traf_out FROM (
на
SELECT time, SUM(`in`)/8 AS traf_in, SUM(`out`)/8 AS traf_out FROM (

chown: freeradius: illegal group name

Неверное имя группы. Наверное её нет.

Вот ещё что в UPDATING пишут:

20110602:
  AFFECTS: users of net/freeradius
  AUTHOR: Sevan Janiyan <venture37@geeklan.co.uk>

  Freeradius no longer runs as nobody. It now runs as the freeradius
  user. Please ensure that the following paths are owned by freeradius:

  /var/run/radiusd
  /var/log/radacct
  /var/log/radius.log

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

Это похвально, что ты сделал патч. Но несколько замечаний, по теме и нет.

Спасибо за замечания, учту.

Старайся в коде не делать строки, которые не помещаются по ширине экрана, реально неудобно работать. Например,

Код:

Db->sql(
 "SELECT ... ".
 "FROM ..."
);

Ок. Хотя у меня помещается.
И мне так удобней работать - однострочный вариант проще копировать в консоль MySQL для отладки.

Надо юзать плейсхолдеры:

Кроме исключения инъекций (а тут им, ИМХО, взяться негде), у плейсхолдеров есть какие-то значимые преимущества?

Код:

"UPDATE users_services SET tm_start=UNIX_TIMESTAMP(), tm_end=tm_end+UNIX_TIMESTAMP()-tm_start ..."

Тоже хотел так сделать. Но у месяцев разное количество дней, поэтому такая схема "гуляет" на 1-3 дня.

А почему я не заюзал такую схему? Вот:
1) Клиент берут кредит на 3 дня
2) Подключается услуга на 1 месяц, через 3 дня отключается
3) Клиент пополняет счет и пользуется месяц. Итого месяц + 3 дня

И это не единственная ситуация. По-корректному делать так как я ранее написал. Будет время - сделаю

Согласен, этот момент я не учёл. Подправлю. Или у тебя "будет время" в ближайшую неделю?

А можно такое организовать. Человек месяц не пользовался инетом, ему не сняло деньги. Но вместо этого ему начислять другую услугу. Типа как отпуск. А пользовал - начислять установленную.

Можно попробовать исхитриться.
Например, добавить всем основную услугу "Резервирование линии" ("Эксплуатационные расходы","Арендная плата", назвать по вкусу) скажем, 20 гривен.
А из помесячных тарифов вычесть эти 20 грн.
Тогда, если трафика за месяц не было - снимется 20 грн., если был - 20 грн. и уменьшенный тариф (в сумме - ваш нынешний тариф).
Как-то так...

если клиент в минусе, то при пополнении счёта начало услуги переносится на дату оплаты. То есть, если у клиента закончились деньги и он пару недель не пополнялся (оно ему было не надо), эти две недели не учитываются, и отсчёт нового месяца пойдёт с даты оплаты.

не подскажеш  как именно организовал?

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