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

[banec]

У кого были проблемы с контролем сессий на Cisco
то вылечили так
aaa accounting delay-start
aaa accounting update periodic 1 - (это минута - без этого раньше работало, а у же с 5.3 - плодились сессии)
aaa accounting network default start-stop group radius

[lknsfos]

Странная проблема.
У абонента уже сутки висит сессия, в админке в Radius сессиях показывает, что она обновляется каждую минуту, но по факту сессии нет уже эти сутки, пакетов радиуса с этим абонентом не летает, в логах debug и radius встречается упоминание, лишь когда я пытался "Послать PoD" или пытался удалить сессию через админку.

И еще пара вопросов:
про долго закрываемые сессии радиус пишут про индексацию traffic_consumption, но у меня почему-то данная таблица пуста абсолютно. А сессии задерживаются все дольше и дольше. До перехода с 009 такого не замечалось.

Так же раз в месяц при переводе на новые тарифы при резком обрыве сессии повисают до перезагрузки ядра (начиная с 002 и до последней 003), был ли у кого такой баг?

и вопрос такого плана:


Что это и почему оно так жестко загаживает debug.log при log_level 1...

[Nik0n]

заметил в админке в "Дополнительно=>Атрибуты RADIUS" остаются записи от удалённых услуг, что вносит некоторый мусор.

вот думаю если их удалить из базы ручками (а лежат они в таблице radius_data) будут ли проблемы?

UPD
Сам спросил, сам себе и отвечу:
Удаление записей из базы ручками проблем не нажило....

хотя со стороны разработчиков неплохо было бы поправить это недоразумение...

Уважаемый maxxsoft, не поделишься запросом поиска и удаления "мусора" в radius_data ?

[maxxsoft]

Уважаемый maxxsoft, не поделишься запросом поиска и удаления "мусора" в radius_data ?

я удалял поштучно, ручками, потому как у меня немного было, но если их очень много, конечно нужно автоматизировать процесс примерно по такому сценарию:
1.получить список ид и родителя
2.проверить родителя на признак удалённости
3.удалить записи для удалённых родителей

поскольку родители у меня может быть 2х типов (всего их 4), то и запросов будет тоже 2:

для сервисных связок:

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

delete from radius_data WHERE radius_data.id in(select id from
(SELECT
rad.id
FROM
radius_data as rad,
service_links as sl
WHERE
rad.owner_id=sl.id
and sl.is_deleted=1
and rad.owner_type=10000)t );

А для услуг передачи ip трафика:

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

delete from radius_data WHERE radius_data.id in(select id from
(SELECT
rad.id
FROM
radius_data as rad,
iptraffic_services_data as sd
WHERE
rad.owner_id=sd.id
and sd.is_deleted=1
and rad.owner_type=3)t );

для услуг Dialup и Hotspot я owner_type не знаю, т.к. не использую, но так же по аналогии.

[TiRider]

После обновления до upd10 в debug.log валятся повторяющиеся строчки:

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

Jan 25 01:01:06 ?Debug : 9ffff700 DBACharge: coefficient calculation detail (1454259600-1451581200-0) / 2678400
Jan 25 01:01:06 ?Debug : 9ffff700 DBACharge: coefficient calculation detail (1454259600-1451581200-0) / 2678400
Jan 25 01:01:06 ?Debug : 9ffff700 DBACharge: coefficient calculation detail (1454259600-1451581200-0) / 2678400
Jan 25 01:01:06 ?Debug : 9ffff700 DBACharge: coefficient calculation detail (1454259600-1451581200-62189) / 2678400
Jan 25 01:01:06 ?Debug : 9ffff700 DBACharge: coefficient calculation detail (1454259600-1451581200-142384) / 2678400

Это нормально?

[TiRider]

Еще на upd10

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

Feb 01 11:46:19  ERROR : 9e13f700 DBAExistingError: get_accounting_period_iter: no such disc per 1789

Feb 01 11:46:19  ERROR : 9e13f700 RPCServer@0.0.0.0: rpcf_link_user_tariff: DBAExistingError: get_accounting_period_iter: no such disc per 1789

Хотя такого расчетного периода в помине нет...

сюда же

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

-- ERROR link 23217, account tariff link id 2744, not equal discount period ids

-- SQL DESC delete broken link (NOT RECOMMENDED)

-- UPDATE service_links SET is_deleted=1 WHERE id='23217';

-- UPDATE periodic_service_links SET is_deleted=1 WHERE id='23217';

-- UPDATE dialup_service_links SET is_deleted=1 WHERE id='23217';



-- 12 errors

-- 0 warnings

-- affected tables: dialup_service_links periodic_service_links service_links

-- RESTART utm5_core!

Пугает это SQL DESC delete broken link (NOT RECOMMENDED)

[TiRider]

Словили кору ядра

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

ERROR &#58; c977e700 DBConnection_mysql&#58; <0x22c4100> MySQL query failed&#58;<Duplicate entry '1454305891-15046-200-0' for key 'uniq_dbf2840cfffe4be64dbff06b1b8dfa00'> Trying to reconnect&#58; 0

кто в курсе как на mysql починить?

[Magnum72]

Словили кору ядра

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

ERROR &#58; c977e700 DBConnection_mysql&#58; <0x22c4100> MySQL query failed&#58;<Duplicate entry '1454305891-15046-200-0' for key 'uniq_dbf2840cfffe4be64dbff06b1b8dfa00'> Trying to reconnect&#58; 0

кто в курсе как на mysql починить?

Удалить дублирующиеся значение.

[TiRider]

Словили кору ядра

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

ERROR &#58; c977e700 DBConnection_mysql&#58; <0x22c4100> MySQL query failed&#58;<Duplicate entry '1454305891-15046-200-0' for key 'uniq_dbf2840cfffe4be64dbff06b1b8dfa00'> Trying to reconnect&#58; 0

кто в курсе как на mysql починить?

Удалить дублирующиеся значение.

Не подскажешь запрос правильный?

[TiRider]

Собственно после обновления до upd10 все было нормально. Сейчас не пойми, что творится с базой. Исчезли все отчеты, хотя ошибок нет... Подозреваю, что зря обновлялись...

[Magnum72]

Странная проблема.
У абонента уже сутки висит сессия, в админке в Radius сессиях показывает, что она обновляется каждую минуту, но по факту сессии нет уже эти сутки, пакетов радиуса с этим абонентом не летает, в логах debug и radius встречается упоминание, лишь когда я пытался "Послать PoD" или пытался удалить сессию через админку.

И еще пара вопросов:
про долго закрываемые сессии радиус пишут про индексацию traffic_consumption, но у меня почему-то данная таблица пуста абсолютно. А сессии задерживаются все дольше и дольше. До перехода с 009 такого не замечалось.

Так же раз в месяц при переводе на новые тарифы при резком обрыве сессии повисают до перезагрузки ядра (начиная с 002 и до последней 003), был ли у кого такой баг?

и вопрос такого плана:

Что это и почему оно так жестко загаживает debug.log при log_level 1...

Это сыпется при попытке поискать абонента в админке.

[maxxsoft]

Заметил что на 5.3-003up5 что на 5.3-003up10

В пуле карточек оплаты нельзя отсортировать данные по столбцу даты активации, вылезает следующая ошибка:

[VooDoo]

После обновления верификатор ругается
-- Verificator
-- You have to backup UTM5 database!
-- Affected tables list at the end of file

-- WARNING dtagg_iptraffic table has been converted

-- 0 errors
-- 1 warnings
-- affected tables:

не могу понять что ему не нравится

[taf]

При редактировании карточки клиента в логах биллинга получаем такое сообщение:
=====
Feb 15 16:19:14 ERROR : 1a4e4700 DBConnection_pgsql: PgSQL query failed: ОШИБКА: значение не умещается в тип character varying(255) Trying to reconnect, count: 4
=====

В логах СУБД видим такое:
=====
ОШИБКА: значение не умещается в тип character varying(255)
ОПЕРАТОР: INSERT INTO user_log(user_id,date,who,action,comment, what) VALUES ('13882','1455524114','-30','4','Full name changed from \"\" to \"Иван Иванович Каладримухаммединоабдальшпрингерцунгрелман\"\; Mobile telephone changed from \"\" to \"8ХХХХХХХХХХ\"\; Actual address changed from \"\"\; Connected date changed from \"15.02.2016\" to \"15.02.2016\"\; Floor changed from \"\" to \"4\"\; Flat number changed from \"\" to \"14\"\; Entrance changed from \"\" to \"1\"\; ','')
================

Естественно, что такая простыня не умещается в 255 символов.

По хорошему это поле прямо-таки вопиет о типе данных 'text'.

[taf]

Шаблоны документов в ods это очень хорошо и удобно (верстать шаблоны в html это был ад и ужас). Но в новой схеме есть очень большой изъян - все полученые для просмотра и печати с биллинга документы - акты, договора, _памятки_пользователю_, по новой схеме они оседают в $TEMP и остаются там и после закрытия программы (админка, диллер, кассир). Получается, что данные пользователей остаются на компьютере оператора/менеджера всегда, и будут доступны для злоумышленника без необходимости устанавливать сеанс связи с ядром биллинга.

Ребята, вы как хотите, но такое положение вещей это полный п.....ц.