Вопрос спецам по Lanbilling'y

[bos9]

Планируем купить лицензию на обновление ПО и обновить нашу сборку (1.9 сборка 003) до актуальной (вроде как 2.0 сборка 010). Пока не ясно, что с конвертацией базы.. Нутром чую, что update.sql при таком разбеге версий ничем не поможет. Кто как мигрировал? Есть ли какие то накатанные решения?

Edited September 3, 2014 by bos9

[infery]

Просто личный опыт: Логин пользователя (который не в учетке, а в "Пользователи") должен быть уникальным и не быть пустым. Напоролись при обновлении. В остальном все гладко.

[VasiliyP]

Сам буквально на днях обновил с 4й до 7й сборки, вроде все гладко прошло, правильно говорят с логинами может быть косяк, ну и надо применять больше изменений, update.sql, deleting_zero_charges.sql, procedures-sales.sql, причем первую и вторую нам пришлось дважды применять, не все поля в таблицах создались, и пришлость из таблицы аккаунтс удалять key login, т.к. там вносятся изменения и теперь там unique key login

А так вполне гладко прошло, хотя я бы не рискнул на 10ю сразу обновляться, люди с форума жалеют что обновились))

[bos9]

ну и надо применять больше изменений, update.sql, deleting_zero_charges.sql, procedures-sales.sql,

 

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

 

хотя я бы не рискнул на 10ю сразу обновляться, люди с форума жалеют что обновились))

 

ланбиллинг такой ланбиллинг... думал они уже избавились от дестких болезней.

[ShyLion]

Планируем купить лицензию на обновление ПО и обновить нашу сборку (1.9 сборка 003) до актуальной (вроде как 2.0 сборка 010). Пока не ясно, что с конвертацией базы.. Нутром чую, что update.sql при таком разбеге версий ничем не поможет. Кто как мигрировал? Есть ли какие то накатанные решения?

Почему бы не купить заодно услугу по апгрейду и переложить этот гемор на производителя?

[bos9]

Почему бы не купить заодно услугу по апгрейду и переложить этот гемор на производителя?

 

недешевое для нас удовольствие

[megahertz0]

Обновляться на 10 сборку крайне не рекомендую пока.

Мы на свою голову обновились. В итоге под нас разрабы накатали уже штук пять хотфиксов. В основном проблемы с тем, что радиус теперь работает с отдельной БД. К примеру, не все поля создаются при создании на пользователе учетки именно в БД радиус-агента. Сейчас вроде бы поправили, но косяки все равно всплывают время от времени. При этом в хелпдексе лежит сборка ядра и агентов от 20140721 с массой глюков, в по факту более-менее рабочая 20140829. Видимо не включили еще пока все хотфиксы в основную ветку.

[s.lobanov]

лучше вообще не обновлять ланбиллинг. только если реально это нужно и нет workaround-а, а не ради какой-нибудь фичи, без которой можно прожить

[alibek]

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

Так что лучше уж обновлять регулярно.

[VasiliyP]

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

[s.lobanov]

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

Так что лучше уж обновлять регулярно.

 

Вы эксплуатируете ланбиллинг?

[alibek]

Нет, у меня Билл-Мастер.

Но его обновление с 6 до 9 версии мало отличается от запуска с нуля.

[No_name]

Мы с 7 на 10 сборку обновились, не без проблем. Все порешали довольно таки быстро, одна не критичная висит до сих пор.

Но я бы все-таки посоветовал не тестовом серваке обновиться, это критично, если используете радиус. И это, если используете фрю ниже чем 8.0,

то ее тоже придется обновить, потому как для старой версии сборок не будет.

[n3o]

Если планируете использовать личный кабинет версии 1 готовьтесь к тому, что он может перестать нормально отображать сообщения в helpdesk. Но у ЛБ есть фикс для этого.

 

Обратите внимание, если у Вас имеются пользователи с одинаковыми номерами договоров или кодами оплаты - это нужно фиксить.

Пользователи с одинаковыми логинами, также, должны быть исправлены.

 

А так - очень хорошо было бы собрать стенд с копией текущей базы+лб и отдельно прокрутить момент апдейта (хотябы поймете, сколько времени будете сидеть без биллинга) + попробуете посмотреть на работу Ваших скриптов, если вы используете API или ходите в базу за какой-то информацией. С недавних ревизий (внутри одной версии) API у Lanbilling поменялось без каких-либо уведомлений.

 

Отсутствие честного и человеческого changelog очень напрягает.

Edited September 11, 2014 by n3o

[hsvt]

Планируем купить лицензию на обновление ПО и обновить нашу сборку (1.9 сборка 003) до актуальной (вроде как 2.0 сборка 010). Пока не ясно, что с конвертацией базы.. Нутром чую, что update.sql при таком разбеге версий ничем не поможет. Кто как мигрировал? Есть ли какие то накатанные решения?

 

А как вы всё это время на 1.9 003 без лицензии сидели ? Там же ограничение по агентам вводится, плюс ядро переходит в restricted mode.

 

А вообще конечно удивляет подход к бизнесу со стороны разработчиков и руководства. Переходили с 1.9 до 2.0.008 и так же возникло множество проблем. Лучше как уже сказали всё проверять предварительно на стенде.

[bos9]

А как вы всё это время на 1.9 003 без лицензии сидели ? Там же ограничение по агентам вводится, плюс ядро переходит в restricted mode.

 

Вы не правильно поняли. Лицензия на использование бессрочна и она у нас есть, а вот лицензия на обновление приобретается на пол года.

 

А в целом от обновления планировали получить малой кровью более зрелый продукт, но видимо скорее получится наоборот... так что

лучше вообще не обновлять ланбиллинг. только если реально это нужно и нет workaround-а, а не ради какой-нибудь фичи, без которой можно прожить

Edited September 12, 2014 by bos9

[hsvt]

А LBinet кто нибудь ихний использует в продакшене для реализации IPoE? (DHCP+RADIUS) Стоит ли пробовать?

[D_Ev_io]

А LBinet кто нибудь ихний использует в продакшене для реализации IPoE? (DHCP+RADIUS) Стоит ли пробовать?

Да. Есть некоторые заморочки при работе DHCP-сервера с коммутаторами D-Link DES-3200 Series, а в целом всё гуд.

[hsvt]

А LBinet кто нибудь ихний использует в продакшене для реализации IPoE? (DHCP+RADIUS) Стоит ли пробовать?

Да. Есть некоторые заморочки при работе DHCP-сервера с коммутаторами D-Link DES-3200 Series, а в целом всё гуд.

 

Да... вот что то к сожалению не можем добиться работы address_binding в режиме dhcp_snoop на DES-3528(A5) - динамические списки ACL не строит. Но у них на стэнде на 3200-10 заработало.

[s.lobanov]

hsvt

а LB тут при чём?

[hsvt]

hsvt

а LB тут при чём?

 

Ну как... при этом LBinet выступает в роли DHCP сервера и на основании его пакетов на коммутаторах строится работа dhcp snooping в режиме acl, вот с ISC-DHCP это работает. У них на стэнде так же работает и с DES-3200-10, буду пробовать другой стэнд с DES-3200.

[D_Ev_io]

hsvt

а LB тут при чём?

 

Ну как... при этом LBinet выступает в роли DHCP сервера и на основании его пакетов на коммутаторах строится работа dhcp snooping в режиме acl, вот с ISC-DHCP это работает. У них на стэнде так же работает и с DES-3200-10, буду пробовать другой стэнд с DES-3200.

У нас хорошо работает только с HW C1. Ни А ни В не работают корректно с этим DHCP. Я тоже уже обсуждал это и на форуме ДЛинка.

Хочу попробовать НАГовские свичи погонять для эксперимента, но надобности особо нет, потому как закупаем только HW C1

[Andrei]

Коллеги! Понимаю, что "телефонистов" тут немного, но может быть кто-то использует ЛБ 2.0 (сейчас стоит сборка 006) для биллинга традиционной телефонии путем обработки plain-text cdr-ов (агент pcdr)? Есть вопросы по этому поводу. Если интересно общественности, могу описать тут, но думаю, что это слишком специфичное для данного форума использование ЛБ.

[wed]

Гм, а что специфичного? Используем - особых проблем вроде не испытываем...

[Andrei]

У меня местная телефония тарифицируется нормально, а зоновая и мг-телефония почему-то не тарифицируется совсем. Стоимость пишет 0, категория "Default"

Как настроено.

Т.к. мои услуги - только местная телефония, а зона и мг - по агентской схеме, то завел 3х операторов: себя (местный), Мегафон - зоновый, Ростелеком - МгМн

Создал соответствующие каталоги с кодами ABC/DEF, которые относятся к соответствующим операторам.

На основании каталогов создал мастер-категории: каждая мастер-категория - это зона с ABC/DEF-кодами, стоимость звонка на которые одинакова.

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

И в результате тарифицируются только местные звонки, т.е. те, коды которых внесены в мой (как оператора) каталог и мастер-категории.

 

Думаю - ОК. Наверное надо зайти через мультитариф.

Удаляю все "несвои" направления из направлений в тарифах, создаю доп.тариф (там есть галка соответствующая в свойствах тарифа) с названием "Зоновая телефонная связь - Мегафон". В свойствах этого доп.тарифа указываю каталог - "Мегафон"

Начинаю заполнять направления в тарифе на основании каталога и мастер-категорий Мегафона

А фиг! При попытке сохранить категории с направлениями в тарифе выдает ошибку:

 

, , ,,PROCEDURE billing.ERROR_INCONSISTENT_RECORD does not exist,, , ,,PROCEDURE billing.ERROR_INCONSISTENT_RECORD does not exist,, , ,,PROCEDURE billing.ERROR_INCONSISTENT_RECORD does not exist,, , ,,PROCEDURE billing.ERROR_INCONSISTENT_RECORD does not exist,, , ,,PROCEDURE billing.ERROR_INCONSISTENT_RECORD does not exist,, , ,,PROCEDURE billing.ERROR_INCONSISTENT_RECORD does not exist,, , ,,PROCEDURE billing.ERROR_INCONSISTENT_RECORD does not exist,, , ,,PROCEDURE billing.ERROR_INCONSISTENT_RECORD does not exist

 

Собственно на этом я и застопорился.

Есть конечно идея, что мне оно на фиг не надо, т.к. зоновая и междугородная связь - услуги не мои, я тут как агент и биллинговать эти несвои услуги у себя в биллинге не надо.

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

Спасибо, если дочитал до конца. :)