Опыт установки 5.3 на боевом сервере

[TiRider]

А что можете сказать по моей просьбе касательно фильтра в сессиях RADIUS?

Присоединяюсь. Еще бы поиск по логину, было бы шикарно, чтобы не шуршать...

[w0Lf]

Обновился с 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 Исправлена ошибка, в ряде случаев приводившая к некорректным списаниям абонентской платы

Увы, но судя по всему проблема со списаниями так и не была решена.

[banec]

Полистайте тему - Магнум где-то писал про эти проблемы.
У себя проверил списало только за текущий день. up18

[yegorov.v]

Насколько допустимо убивать радиус через kill -9 если на /etc/init.d/utm5_radius stop он не шибко реагирует?

[MEDVED]

Насколько допустимо убивать радиус через kill -9 если на /etc/init.d/utm5_radius stop он не шибко реагирует?

Уже давно так делаем. На вопрос почему так в хотлайне не ответили.

[yegorov.v]

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

[MEDVED]

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

[yegorov.v]

И как починили? Очень интересует ваш опыт. Сейчас подымаю новую версию биллинга на резерве, потом сделаю архивацию и перекину туда бд.

[maxxsoft]

У нас при генерации счетов в .pdf формате в строках где сумма, НДС, итого в документе нули.

Если счет генерируется в формате .odt то всё нормально.

Centos 6 32 битная. Такая ситуация с 5-3.003 RC1 и до upd 4.

Вроде и тикет есть 2621... но как-то глухо.
Кто-нибудь сталкивался с такой проблемой?

я столкнулся с данной проблемой, пошуршал конфиг и не увидел там секции 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

## max_upload_size
## Description: Maximum size of ODT template/contract file
## Possible values: an integer
## Default value: 1000000
#max_upload_size=1000000

[MEDVED]

И как починили? Очень интересует ваш опыт. Сейчас подымаю новую версию биллинга на резерве, потом сделаю архивацию и перекину туда бд.

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

[Groggy]

я столкнулся с данной проблемой, пошуршал конфиг и не увидел там секции 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

Есть у меня это в конфигурации. Но это не помогает в .pdf формате в нескольких полях получаются нули. На двух серверах рабочем и тестовом одинаково.

Какая у вас ОС ? В счете все поля с цифрами (таблица), итого верные ?

[maxxsoft]

Есть у меня это в конфигурации. Но это не помогает в .pdf формате в нескольких полях получаются нули. На двух серверах рабочем и тестовом одинаково.

Какая у вас ОС ? В счете все поля с цифрами (таблица), итого верные ?

Version:5.3-003-update4-debian_wheezy_x64 Rev #14998

счета, акты и СФ формируются сейчас корректно

Libreoffice у вас установлен корректно?, может стоит его переустановить.. а также проверьте соответствие конфига на положение бинарника либреофиса, ну и последуйте моему примеру: перезапустите ядро.

UPD
ещё одно:
Клиентом я сижу на убунте, может конечно это и не важно, но всё же..

[banec]

При включении параметра

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

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&#58;05&#58;58 ?Debug &#58; 255c9740 DBConnection_mysql&#58; <0x240f200> SQL query&#58; CREATE UNIQUE INDEX uniq_dbf2840cfffe4be64dbff06b1b8dfa00 ON dtagg_iptraffic&#40;is_closed,slink_id,tclass,base_cost&#41;;
Sep 22 15&#58;05&#58;58  ERROR &#58; 255c9740 DBConnection_mysql&#58; <0x240f200> MySQL query failed&#58;<Duplicate entry '1-12-40-0' for key 'uniq_dbf2840cfffe4be64dbff06b1b8dfa00'> Trying to reconnect&#58; 0
Sep 22 15&#58;06&#58;58  ERROR &#58; 255c9740 DBConnection_mysql&#58; <0x240f200> MySQL query failed&#58;<Duplicate entry '1-12-40-0' for key 'uniq_dbf2840cfffe4be64dbff06b1b8dfa00'> Trying to reconnect&#58; 1
Sep 22 15&#58;07&#58;58  ERROR &#58; 255c9740 DBConnection_mysql&#58; <0x240f200> MySQL query failed&#58;<Duplicate entry '1-12-40-0' for key 'uniq_dbf2840cfffe4be64dbff06b1b8dfa00'> Trying to reconnect&#58; 2
Sep 22 15&#58;08&#58;58  ERROR &#58; 255c9740 DBConnection_mysql&#58; <0x240f200> MySQL query failed&#58;<Duplicate entry '1-12-40-0' for key 'uniq_dbf2840cfffe4be64dbff06b1b8dfa00'> Trying to reconnect&#58; 3
Sep 22 15&#58;09&#58;58  ERROR &#58; 255c9740 DBConnection_mysql&#58; <0x240f200> MySQL query failed&#58;<Duplicate entry '1-12-40-0' for key 'uniq_dbf2840cfffe4be64dbff06b1b8dfa00'> Trying to reconnect&#58; 4
Sep 22 15&#58;10&#58;58  ERROR &#58; 255c9740 DBConnection_mysql&#58; <0x240f200> MySQL query failed&#58; 
Sep 22 15&#58;10&#58;58  ERROR &#58; 255c9740 DBASQLError&#58; MySQL query failed&#58; 

ну, коли гора не идет к магомету....
проблема заключается в наличии дублирующихся записей в таблице
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;

потом создаем индекс

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

CREATE UNIQUE INDEX uniq_dbf2840cfffe4be64dbff06b1b8dfa00 ON dtagg_iptraffic(is_closed,slink_id,tclass,base_cost);

и вуаля... ругани нет, ядро запускается за 4 секунды вместо 320
удалилось порядка 20 тысяч записей из 140 тысяч, как повлияло на работоспособность- неизвестно, делалось на тестовой базе

И все же, можно так делать или нет?

Еще глюк: если открыть памятку абонента в MS Office 2013, то он ругается на битый файл. И если его восстановить, то отображается шаблон без замен. А вот в LibreOffice все вроде ок. Это что ж, теперь всем операторам LibreOffice ставить? Или можно это исправить?

Техподдержка сказала, что в моём случае надо искать дубликаты и удалять их, на вопрос "а может стоит включить в данный индекс еще какое-либо поле таблицы?" они ответили "К сожалению, из Вашего письма не совсем понятно, что Вы спрашиваете.
Напишите пожалуйста более подробно."(Ticket#: 2015092310000064) как подробнее написать, я что-то не догоняю....

имею на руках up6(выслали для теста доработанного динашейпера для нас) . Проверка базы стоит по умолчанию включено.
Первый запуск ядра 1 минута - судя по логам ядро само ещё обновляла структуру базы.
Но стартовало без ошибок. Так что починили.(на up5 тоже ругалось)

[yegorov.v]

Пожалуйста, прокртитикуйте настройки. Сейчас на NAS-ах, дубликатов ip нет, но в логах

Oct 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

http://pastebin.com/0rHT8RKS

Такое уже было 10 страниц назад в конце, и как-то прошло само собой, понимания что мы сделали и что починило временно нет. Адресов хватает.

[Groggy]

Version:5.3-003-update4-debian_wheezy_x64 Rev #14998

счета, акты и СФ формируются сейчас корректно

Libreoffice у вас установлен корректно?, может стоит его переустановить.. а также проверьте соответствие конфига на положение бинарника либреофиса, ну и последуйте моему примеру: перезапустите ядро.

UPD
ещё одно:
Клиентом я сижу на убунте, может конечно это и не важно, но всё же..

На тестовом сервере стоит пакет libreoffice4.4, на рабочем libreoffice-headless 4.0.4.2-14.

Ядро разумеется перезапускалось. Я пробовал разные версиии utm5. Это у нас тянется с апрельского RC1

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

На тестовом обновил Libreoffice до 5.0.2 - не помогло.