Лишние списания со счетов.

[Vjacheslav-A]

После перехода с версии 004 на 008, наблюдались списания (я так понимаю периодической составляющей стоимости услуги деленной на 2) не два раза в день а иногда три раза. Из отчетов: Обратите внимание на дату списания.

Код: Выделить всё

129;vd3-36;Передача IP трафика;Thu Jul 08 09:00:01 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Wed Jul 07 22:07:02 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Wed Jul 07 10:02:03 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Wed Jul 07 07:22:01 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Tue Jul 06 11:24:53 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Tue Jul 06 07:30:38 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Mon Jul 05 13:00:04 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Mon Jul 05 07:42:04 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Sun Jul 04 14:52:00 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Sun Jul 04 08:21:47 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Sat Jul 03 16:32:01 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Sat Jul 03 08:05:25 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Fri Jul 02 17:35:01 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Fri Jul 02 07:10:16 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Fri Jul 02 00:00:00 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Thu Jul 01 15:19:55 MSD 2010;31687;26.661;
Суммарно;;;;Передача IP трафика;;;261.036;
Итого;;;;;;;261.036;

Аварийный останов ядра был 07.07 , 02.07 был просто перезапуск.
Такое происходит у части пользователей (которых проверил) причем у некоторых 05.07 , когда биллинг вообще спокойно работал, у некоторых списывалось нормально (по два раза), и у всех странное списание за 01.07 .
P.S. Тариф(название) и имя пользователя вырезаны
Так же до перехода , отчетов по списаниям по этим и аналогичным услугам (тарифам нет) . Хотелось бы уточнить алгоритм списания и расчета периодической составляющей. Тариф "безлимитный" , списывать деньги должен в течении всего расчетного периода. У этого пользователя текущий рассчетный период с 12.06.2010 по 12.07.2010.

[Magnum72]

После перехода с версии 004 на 008, наблюдались списания (я так понимаю периодической составляющей стоимости услуги деленной на 2) не два раза в день а иногда три раза. Из отчетов: Обратите внимание на дату списания.

Код: Выделить всё

129;vd3-36;Передача IP трафика;Thu Jul 08 09:00:01 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Wed Jul 07 22:07:02 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Wed Jul 07 10:02:03 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Wed Jul 07 07:22:01 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Tue Jul 06 11:24:53 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Tue Jul 06 07:30:38 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Mon Jul 05 13:00:04 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Mon Jul 05 07:42:04 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Sun Jul 04 14:52:00 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Sun Jul 04 08:21:47 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Sat Jul 03 16:32:01 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Sat Jul 03 08:05:25 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Fri Jul 02 17:35:01 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Fri Jul 02 07:10:16 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Fri Jul 02 00:00:00 MSD 2010;31687;15.625;
129;vd3-36;Передача IP трафика;Thu Jul 01 15:19:55 MSD 2010;31687;26.661;
Суммарно;;;;Передача IP трафика;;;261.036;
Итого;;;;;;;261.036;

Аварийный останов ядра был 07.07 , 02.07 был просто перезапуск.
Такое происходит у части пользователей (которых проверил) причем у некоторых 05.07 , когда биллинг вообще спокойно работал, у некоторых списывалось нормально (по два раза), и у всех странное списание за 01.07 .
P.S. Тариф(название) и имя пользователя вырезаны
Так же до перехода , отчетов по списаниям по этим и аналогичным услугам (тарифам нет) . Хотелось бы уточнить алгоритм списания и расчета периодической составляющей. Тариф "безлимитный" , списывать деньги должен в течении всего расчетного периода. У этого пользователя текущий рассчетный период с 12.06.2010 по 12.07.2010.

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

[Vjacheslav-A]

Да , расчетные периоды создаются автоматически (количество списаний биллинг не ставит). Еще бы понять как он будет продолжать списывать деньги.

[gil]

Верификатор?

[Vjacheslav-A]

Ворнингов куча , но раньше они жить не мешали , их много , и если их сгруппировать по slink затрагивают не так много позицый , в основном это : check slink exists and delete dtagg_iptraffic entry for deleted slink
# cat /netup/utm5/log/verificator.log | grep "check slink exists" | wc -l
9238

Код: Выделить всё

-- ERROR strange row in services_data with id 66 (no row in periodic_services_data, iptraffic_services_data, dialup_services_data, hotspot_services_data, telephony_services_data or once_services_data)
-- SQL DESC delete row (NOT RECOMMENDED)
-- UPDATE services_data SET is_deleted=1 WHERE id='66';

-- ERROR tel_directions table has rows with id < 1000000
-- SQL DESC delete all directions and re-create it
INSERT INTO tel_directions &#40;id, prefix, name, is_deleted&#41; VALUES &#40;'1001000', '', '', '1'&#41;;

-- 2 errors
-- 9238 warnings
-- affected tables&#58; dtagg_iptraffic dtagg_periodic dtagg_telephony services_data tel_directions

Телефонией он не занимается , что то осталось от попыток старых админов сделать в этом направлении видимо.

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

[Vjacheslav-A]

Пересчитал всё сам , разницу в несколько руб-коп , считаю не критичной , видимо мы с биллингом малость по разному считаем ). Если никому больше не интересны подробности перехода на новую версию (008) с 5.2.1-004 , то просьба тему удалить дней через пять (мало ли еще чего нибудь вылезет с расчетами ).

[TiRider]

Распиши как делал. Все по подробнее. Некоторым может пригодиться.

[Vjacheslav-A]

Исходные данные: Сеть небольшая , юрики+физики , 90% безлимитка , VPN практически нет. Мускуль : Server version: 5.0.32-Debian_7etch1
Система уже понятно какая. Железо : Intel(R) Pentium(R) 4 CPU 3.00GHz , Гиг памяти . Загрузка маленькая , кроме биллинга ничего не крутиться.

1.) Останавливаем биллинг, останавливаем MySQL ,копируем папку /var/lib/mysql/UTM5 , ну напрмер в UTM5NEW. Запускаем всё взад.

2.) Необходимо очистить базу от "лишнего" трафика , у кого есть юр.лица , я бы оставил трафик за последний год и всё, иначе обновлять базу будете дня три - четыре (если конечно не захотите воспользоваться механизмом архивации , я пока не захотел). Алгоритм очистки тут, на форуме, где то был , стираем всё из таблиц , discount_transactions_all discount_transactions_iptraffic_all до определенного числа , не забываем потом оптимизировать таблицы. У кого много клиентов и огромная база (у меня была где то 25 Гиг.) рекомендую всё таки архивирование этих таблиц.
3.) Если обновляетесь с версии 004 , читаем всё что касается обновления до 005 (только обновления базы MySQL), подготавливаем файлы и обновляем базу. И так последовательно для каждого релиза (006, 007), ну и 008-rc1. Рекомендую сохранять промежуточные состояния апдейтов (почистили 004 - сохранили , проще остановить биллинг и мускуль , скопировать папку с базой, чем делать всё это mysqldump-ом).
4.) Не забываем накатить апдейты шаблонов (по моему лежат в 008-бета), запустить конвертацию правил файерволов (в папке bin utm-а), залить новый ключик в базу.
5.) Сохраните старые бинарники куда то ! , мало ли , понадобиться быстро откатиться. Обновляем бинарники , на Debian по мануалу вполне получилось , единственное, игноры в команде dpkg кое какие пришлось указать (--force-overwrite). Обновлял etch версию. На тестовом делал как и dpkg , так и просто переписывал поверх старых , новые файлы (пришлось подсобрать кое какие зависимости). Конфиги лучше новые отредактировать , а не ковырять свои старые , в связи с новыми реалиями так сказать.
6.) Запускаем , проверяем логи, проверяем работу rfw ( на удаленных шлюзах rfw не обновлял , и так заработало). Проверяем подсчет трафика , отчеты.
Можете перекодировать базу в UTF8 , у меня в Latin1, периодичеки в логах появляются ошибки "cann't convert multi-byte character to wide", честно говоря пока не понял на что они влияют , у пользователей с буковкой "Ы" в фамилии всё норм, ядро теперь от таких вещей никуда не вываливается.
P.S. ну и потренируйтесь на тестовом для начала (если сделаете аналогичный рабочему (по версиям П.О, вообще идеально) и бекапы и еще раз бекапы базы!!!.