Присоединяюсь. Еще бы поиск по логину, было бы шикарно, чтобы не шуршать...MEDVED писал(а): А что можете сказать по моей просьбе касательно фильтра в сессиях RADIUS?
Опыт установки 5.3 на боевом сервере
Обновился с 5.3-002-upd8 до 5.3-002-upd18.
После обновления появились проблемы со списаниями услуг.
Суть проблемы:
Есть тестовый абон, баланс 10000 р.
Лицевой счёт имеет админскую блокировку, инет выкл.
В таком состоянии подключаем периодическую услугу стоимостью 1000 р/мес.
Редактируем лицсчёт, блокировка - нет, интернет - вкл.
Как только лицсчёт разблокируется происходит списание суммой 372 руб.
Абон, лицсчёт и блокировка лицсчёта созданы 20 окт.
20 окт разблокирован лицсчёт и происходит списание.
Ежесуточное списание за услугу 1000/31=32.26 , по логике должно было списать 32 или меньше.
однако биллинг зачем-то списывает от даты подключения услуги и до конца расчётного периода.
В политике списаний для услуги стоят галки:
- Перерасчёт при создании связки: абон.плата
- перерасчет при блокировке(админская): не списывать абонплату, пересчитывать абонплату
- перерасчет при блокировке(пользовательская): не списывать абонплату, пересчитывать абонплату
- перерасчет при блокировке(системная): ничего не выбрано
- настройки системной блокировки: устанавливать при недостатке средств.
Расчётный период: ежемесячный, кол-во списаний в неделю - 7.
Когда сервисная связка создаётся, в таблице periodic_service_links в поле unabon_period указан не 0, если остановить биллинг, руками выставить 0, запустить биллинг и снять блокировку с л/с, списание происходит с верной суммой, от текущего времени и до конца суток.
Нужно чтобы при снятии блокировки с периодических сервисных связок происходило списание суммой от текущего времени и до конца суток (32 или меньше руб) а не за оставшиеся дни расчётного периода.
Как это сделать?
UPD:
в changelog версии UTM-5.3-002-update16 указано что проблема решена, но это не так.
2536,2547 Исправлена установка периода начала пересчета абонентской платы при добавлении сервисной связки для заблокированного лицевого счета
тоже заявлено и в UTM-5.3-002-update17
2581 Исправлена ошибка, в ряде случаев приводившая к некорректным списаниям абонентской платы
Увы, но судя по всему проблема со списаниями так и не была решена.
После обновления появились проблемы со списаниями услуг.
Суть проблемы:
Есть тестовый абон, баланс 10000 р.
Лицевой счёт имеет админскую блокировку, инет выкл.
В таком состоянии подключаем периодическую услугу стоимостью 1000 р/мес.
Редактируем лицсчёт, блокировка - нет, интернет - вкл.
Как только лицсчёт разблокируется происходит списание суммой 372 руб.
Абон, лицсчёт и блокировка лицсчёта созданы 20 окт.
20 окт разблокирован лицсчёт и происходит списание.
Ежесуточное списание за услугу 1000/31=32.26 , по логике должно было списать 32 или меньше.
однако биллинг зачем-то списывает от даты подключения услуги и до конца расчётного периода.
В политике списаний для услуги стоят галки:
- Перерасчёт при создании связки: абон.плата
- перерасчет при блокировке(админская): не списывать абонплату, пересчитывать абонплату
- перерасчет при блокировке(пользовательская): не списывать абонплату, пересчитывать абонплату
- перерасчет при блокировке(системная): ничего не выбрано
- настройки системной блокировки: устанавливать при недостатке средств.
Расчётный период: ежемесячный, кол-во списаний в неделю - 7.
Когда сервисная связка создаётся, в таблице periodic_service_links в поле unabon_period указан не 0, если остановить биллинг, руками выставить 0, запустить биллинг и снять блокировку с л/с, списание происходит с верной суммой, от текущего времени и до конца суток.
Нужно чтобы при снятии блокировки с периодических сервисных связок происходило списание суммой от текущего времени и до конца суток (32 или меньше руб) а не за оставшиеся дни расчётного периода.
Как это сделать?
UPD:
в changelog версии UTM-5.3-002-update16 указано что проблема решена, но это не так.
2536,2547 Исправлена установка периода начала пересчета абонентской платы при добавлении сервисной связки для заблокированного лицевого счета
тоже заявлено и в UTM-5.3-002-update17
2581 Исправлена ошибка, в ряде случаев приводившая к некорректным списаниям абонентской платы
Увы, но судя по всему проблема со списаниями так и не была решена.
я столкнулся с данной проблемой, пошуршал конфиг и не увидел там секции DOCUMENTS прописал её, перезапустил, всё взлетело, уж не знаю из за секции в конфиге это было или из за перезапуска.....Groggy писал(а):У нас при генерации счетов в .pdf формате в строках где сумма, НДС, итого в документе нули.
Если счет генерируется в формате .odt то всё нормально.
Centos 6 32 битная. Такая ситуация с 5-3.003 RC1 и до upd 4.
Вроде и тикет есть 2621... но как-то глухо.
Кто-нибудь сталкивался с такой проблемой?
Код: Выделить всё
## =============================================================================
## DOCUMENTS
## =============================================================================
## doc_path
## Description: base directory of the ODT document storage
## Possible values: directory path
## Default value: /netup/utm5/doc
doc_path=/netup/utm5/doc
## tmp_path
## Description: temporary files directory
## Possible values: directory path
## Default value: /tmp
#tmp_path=/tmp
## libreoffice_path
## Description: path to the LibreOffice executable
## Possible values: libreoffice executable path
## Default value: /usr/bin/libreoffice
libreoffice_path=/usr/bin/libreoffice
## max_upload_size
## Description: Maximum size of ODT template/contract file
## Possible values: an integer
## Default value: 1000000
#max_upload_size=1000000
-
- Сообщения: 37
- Зарегистрирован: Вт июл 15, 2014 15:19
- Откуда: Украина, Черновцы
- Контактная информация:
Никак. После перезапуска радиус начинает выдавать адреса, которые ранее были выданы. В хотлайне о проблеме сообщили, в ответ нам подсказали что проблема эта связана с пропаданием связи между радиусом и ядром, в нашем случае ядро периодически зависало и рестартовало из-за того, что детальная статистика не писалась в файл, хотя у нас нетфлоу не используется. Подключили запись деталки в файл и с тех пор пока радиус и ядро вручную не рестартовали, прошло примерно три недели и пока все ок, но непонятно или счастье таки наступило, все будет ясно как-всегда 1-го числа, когда начнется новый расчетный период.yegorov.v писал(а):И как починили? Очень интересует ваш опыт. Сейчас подымаю новую версию биллинга на резерве, потом сделаю архивацию и перекину туда бд.
Есть у меня это в конфигурации. Но это не помогает в .pdf формате в нескольких полях получаются нули. На двух серверах рабочем и тестовом одинаково.maxxsoft писал(а): я столкнулся с данной проблемой, пошуршал конфиг и не увидел там секции DOCUMENTS прописал её, перезапустил, всё взлетело, уж не знаю из за секции в конфиге это было или из за перезапуска.....Код: Выделить всё
## ============================================================================= ## DOCUMENTS ## ============================================================================= ## doc_path ## Description: base directory of the ODT document storage ## Possible values: directory path ## Default value: /netup/utm5/doc doc_path=/netup/utm5/doc ## tmp_path ## Description: temporary files directory ## Possible values: directory path ## Default value: /tmp #tmp_path=/tmp ## libreoffice_path ## Description: path to the LibreOffice executable ## Possible values: libreoffice executable path ## Default value: /usr/bin/libreoffice libreoffice_path=/usr/bin/libreoffice
Какая у вас ОС ? В счете все поля с цифрами (таблица), итого верные ?
Version:5.3-003-update4-debian_wheezy_x64 Rev #14998Groggy писал(а):
Есть у меня это в конфигурации. Но это не помогает в .pdf формате в нескольких полях получаются нули. На двух серверах рабочем и тестовом одинаково.
Какая у вас ОС ? В счете все поля с цифрами (таблица), итого верные ?
счета, акты и СФ формируются сейчас корректно
Libreoffice у вас установлен корректно?, может стоит его переустановить.. а также проверьте соответствие конфига на положение бинарника либреофиса, ну и последуйте моему примеру: перезапустите ядро.
UPD
ещё одно:
Клиентом я сижу на убунте, может конечно это и не важно, но всё же..
имею на руках up6(выслали для теста доработанного динашейпера для нас) . Проверка базы стоит по умолчанию включено.Point писал(а):Техподдержка сказала, что в моём случае надо искать дубликаты и удалять их, на вопрос "а может стоит включить в данный индекс еще какое-либо поле таблицы?" они ответили "К сожалению, из Вашего письма не совсем понятно, что Вы спрашиваете.Vans писал(а):И все же, можно так делать или нет?Point писал(а):ну, коли гора не идет к магомету....Point писал(а):аналогичный вопрос, как правильно вылечитьZeM писал(а):При включении параметра
Вот такие ошибкиКод: Выделить всё
verify_database_index=enable
Как грамотно вылечить ? Есть мысль грохнуть его или не вариант?
- Sep 22 10:24:51 ?Debug : b6ce86f0 DBConnection_mysql: <0xb5e84078> SQL query: CREATE UNIQUE INDEX uniq_a6ba8c930a7fd5d9544531e489aa4ec1 ON dtagg_hotspot(is_$
Sep 22 10:24:51 ERROR : b6ce86f0 DBConnection_mysql: <0xb5e84078> MySQL query failed:<Duplicate entry '1-2458-1' for key 'uniq_a6ba8c930a7fd5d9544531e489aa$Код: Выделить всё
Sep 22 15:05:58 ?Debug : 255c9740 DBConnection_mysql: <0x240f200> SQL query: CREATE UNIQUE INDEX uniq_dbf2840cfffe4be64dbff06b1b8dfa00 ON dtagg_iptraffic(is_closed,slink_id,tclass,base_cost); Sep 22 15:05:58 ERROR : 255c9740 DBConnection_mysql: <0x240f200> MySQL query failed:<Duplicate entry '1-12-40-0' for key 'uniq_dbf2840cfffe4be64dbff06b1b8dfa00'> Trying to reconnect: 0 Sep 22 15:06:58 ERROR : 255c9740 DBConnection_mysql: <0x240f200> MySQL query failed:<Duplicate entry '1-12-40-0' for key 'uniq_dbf2840cfffe4be64dbff06b1b8dfa00'> Trying to reconnect: 1 Sep 22 15:07:58 ERROR : 255c9740 DBConnection_mysql: <0x240f200> MySQL query failed:<Duplicate entry '1-12-40-0' for key 'uniq_dbf2840cfffe4be64dbff06b1b8dfa00'> Trying to reconnect: 2 Sep 22 15:08:58 ERROR : 255c9740 DBConnection_mysql: <0x240f200> MySQL query failed:<Duplicate entry '1-12-40-0' for key 'uniq_dbf2840cfffe4be64dbff06b1b8dfa00'> Trying to reconnect: 3 Sep 22 15:09:58 ERROR : 255c9740 DBConnection_mysql: <0x240f200> MySQL query failed:<Duplicate entry '1-12-40-0' for key 'uniq_dbf2840cfffe4be64dbff06b1b8dfa00'> Trying to reconnect: 4 Sep 22 15:10:58 ERROR : 255c9740 DBConnection_mysql: <0x240f200> MySQL query failed: Sep 22 15:10:58 ERROR : 255c9740 DBASQLError: MySQL query failed:
проблема заключается в наличии дублирующихся записей в таблице
dtagg_iptraffic (поля (is_closed,slink_id,tclass,base_cost))
лечим такпотом создаем индексКод: Выделить всё
DELETE s1 FROM dtagg_iptraffic s1 JOIN (SELECT MIN(id) id, slink_id, is_closed, base_cost, tclass FROM dtagg_iptraffic GROUP BY slink_id, is_closed, base_cost, tclass) s2 ON s1.id <> s2.id AND s1.slink_id = s2.slink_id AND s1.is_closed = s2.is_closed AND s1.base_cost = s2.base_cost AND s1.tclass = s2.tclass;
и вуаля... ругани нет, ядро запускается за 4 секунды вместо 320Код: Выделить всё
CREATE UNIQUE INDEX uniq_dbf2840cfffe4be64dbff06b1b8dfa00 ON dtagg_iptraffic(is_closed,slink_id,tclass,base_cost);
удалилось порядка 20 тысяч записей из 140 тысяч, как повлияло на работоспособность- неизвестно, делалось на тестовой базе
Еще глюк: если открыть памятку абонента в MS Office 2013, то он ругается на битый файл. И если его восстановить, то отображается шаблон без замен. А вот в LibreOffice все вроде ок. Это что ж, теперь всем операторам LibreOffice ставить? Или можно это исправить?
Напишите пожалуйста более подробно."(Ticket#: 2015092310000064) как подробнее написать, я что-то не догоняю....
Первый запуск ядра 1 минута - судя по логам ядро само ещё обновляла структуру базы.
Но стартовало без ошибок. Так что починили.(на up5 тоже ругалось)
Пожалуйста, прокртитикуйте настройки. Сейчас на NAS-ах, дубликатов ip нет, но в логах
Такое уже было 10 страниц назад в конце, и как-то прошло само собой, понимания что мы сделали и что починило временно нет. Адресов хватает.
http://pastebin.com/0rHT8RKSOct 23 10:10:02 ?Debug : 27fbc940 AcctQueue: new session ID 496743 for SID 81001bc8
Oct 23 10:10:02 ?Debug : 27fbc940 AcctQueue: sid_insert: session ID 496743 for SID 81001bc8
Oct 23 10:10:02 ?Debug : 27fbc940 LoginStorage: Acquire: login 'zaki46-31' used 1 times
Oct 23 10:10:02 ?Debug : 27fbc940 AcctQueue: slink_id 49652 service_type 5 for login 'zaki46-31'
Oct 23 10:10:02 Info : 27fbc940 AcctQueue: IPv4 address 176.118.112.92 leased
Oct 23 10:10:02 ERROR : 27fbc940 IPPoolManager: IP 176.118.112.92 is busy
Oct 23 10:10:02 ERROR : 27fbc940 LogicError: IP address is busy
Oct 23 10:10:02 ?Trace : 27fbc940 trace: Obtained 11 stack frames.
Oct 23 10:10:02 ?Trace : 27fbc940 trace: /netup/utm5/bin/utm5_radius(_ZN3UTM15print_backtraceEv+0x48) [0x4bb968]
Oct 23 10:10:02 ?Trace : 27fbc940 trace: /netup/utm5/bin/utm5_radius(_ZN3UTM8DBAErrorC2ERKSsS2_b+0xea) [0x43c4ca]
Oct 23 10:10:02 ?Trace : 27fbc940 trace: /netup/utm5/bin/utm5_radius(_ZN6RADIUS13IPPoolManager10__lease_ipERKN3UTM10IP_addressE+0x46b) [0x43e36b]
Oct 23 10:10:02 ?Trace : 27fbc940 trace: /netup/utm5/bin/utm5_radius(_ZN6RADIUS13IPPoolManager8lease_ipERKNS_6IPPairE+0x52) [0x43e732]
Oct 23 10:10:02 ?Trace : 27fbc940 trace: /netup/utm5/bin/utm5_radius(_ZN6RADIUS9AcctQueue15process_ip_infoERKNS_9RADPacketEPNS_7SessionE+0x1d0) [0x425c90]
Oct 23 10:10:02 ?Trace : 27fbc940 trace: /netup/utm5/bin/utm5_radius(_ZN6RADIUS9AcctQueue15process_requestERKN3UTM8NAS_InfoERKNS_9RADPacketERS5_+0xa7b) [0x4285cb]
Oct 23 10:10:02 ?Trace : 27fbc940 trace: /netup/utm5/bin/utm5_radius(_ZN6RADIUS9AcctQueue15packet_receivedEPKcmRKN3UTM6Socket8EndpointE+0x60c) [0x42948c]
Oct 23 10:10:02 ?Trace : 27fbc940 trace: /netup/utm5/bin/utm5_radius(_ZN6RADIUS9UDPServer3runEv+0xf8) [0x472d28]
Oct 23 10:10:02 ?Trace : 27fbc940 trace: /netup/utm5/bin/utm5_radius(_ZN3UTM6Thread6threadEPv+0x59) [0x4bc259]
Oct 23 10:10:02 ?Trace : 27fbc940 trace: /lib64/libpthread.so.0 [0x3386e0683d]
Oct 23 10:10:02 ?Trace : 27fbc940 trace: /lib64/libc.so.6(clone+0x6d) [0x33866d4f8d]
Oct 23 10:10:02 ?Debug : 27fbc940 AcctQueue: lookup: session ID 496743 closed
Oct 23 10:10:02 ?Debug : 27fbc940 Transport: sending traffic/dialup session ID 496743
Oct 23 10:10:02 ?Debug : 27fbc940 Transport: session ID 496743 witout IPInfo
Oct 23 10:10:02 ?Debug : 27fbc940 StreamConnection: Sending message ID 0x1107
Oct 23 10:10:02 ?Debug : 27fbc940 SessionManager: put: sessiond ID 496743 from NAS 81 is closed
Oct 23 10:10:02 ?Debug : 27fbc940 LoginStorage: Release: login 'zaki46-31' used 0 times
Oct 23 10:10:02 ERROR : 27fbc940 AcctQueue: LogicError: IP address is busy
Oct 23 10:10:02 ?Debug : 27fbc940 AcctQueue: Request from 192.168.1.102:48473
Такое уже было 10 страниц назад в конце, и как-то прошло само собой, понимания что мы сделали и что починило временно нет. Адресов хватает.
На тестовом сервере стоит пакет libreoffice4.4, на рабочем libreoffice-headless 4.0.4.2-14.maxxsoft писал(а):
Version:5.3-003-update4-debian_wheezy_x64 Rev #14998
счета, акты и СФ формируются сейчас корректно
Libreoffice у вас установлен корректно?, может стоит его переустановить.. а также проверьте соответствие конфига на положение бинарника либреофиса, ну и последуйте моему примеру: перезапустите ядро.
UPD
ещё одно:
Клиентом я сижу на убунте, может конечно это и не важно, но всё же..
Ядро разумеется перезапускалось. Я пробовал разные версиии utm5. Это у нас тянется с апрельского RC1

Пробовал скармливать .odt файл счета libreoffice в ручном режиме - всё нормально.
На тестовом обновил Libreoffice до 5.0.2 - не помогло.