Jump to content
Калькуляторы

Вопрос спецам по Lanbilling'y переход с 1.9 до 2.0

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

Edited by bos9

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

 

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

 

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

Edited by n3o

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

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

Edited by bos9

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

hsvt

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

 

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

Share this post


Link to post
Share on other sites

hsvt

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

 

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

У меня местная телефония тарифицируется нормально, а зоновая и мг-телефония почему-то не тарифицируется совсем. Стоимость пишет 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

 

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

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

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.