Перейти до

Ошибка БД после миграции


Рекомендованные сообщения

Добрый день! Познакомились с UBilling'ом, и в процессе знакомства случился забавный инцидент.

 

Вот такой алерт сейчас можно увидеть в живом демо, если перейти на вкладку "Онлайн".

 

cbxk7HeQunQ.jpg

 

Что мы делали (Step for reproduce):
 

1. Переходим на вкладку "Консоль разработчика"

2. Выбираем вкладку "Миграция 2"

3. Загружаем csv файл. В нем у нас есть восемь столбцов. Распределяем их по полям новой БД, как на скриншоте ниже. В своем примере, я использовал поля Login, Password, IP, MAC, tariff, cash, address, realName. Всё остальное выставлял по-умолчанию (set_to_none). В user registration mode выбираем PHP Script

 

5NmfOpZXGgM.jpg

 

4. Жмем большую кнопку.

5. На выходе получаем таблицу. Соглашаемся.

6. Хватаем сгенерированный пхп-код в буфер обмена

7. Снова переходим в консоль разработчика, на этот раз на вкладку PHP-консоль

8. Вставляем код из буфера обмена в консоль и запускаем его.

9. Если всё сделано правильно, на вкладке "Онлайн" у вас будут отображаться все абоненты.

10. Теперь удалим одного любого абонента. (Выираем абонента, переходим на вкладку "Черная магия" -> "Удалить абонента", если что)

11. Наблюдаем беду как на первом скриншоте.

 

Ок. Давайте попробуем через поиск пользователей

1. Выбираем Поиск Пользователей

2. Вводим любой адрес. (Я вводил Зловещенск - Вязов - непомнюкакойдом - кв.2)

3. Жмём!

 

8G40uHsXuqU.jpg

 

 

Если посмотреть файл api.address.php то мы увидим, что происходит обращение к переменной $apts

Я в php не силён. Но судя по надписи Undefined index, я так понимаю, что не возможно найти такую запись в БД (Массиве, HashMap, и т.п.) по такому ключу.

 

8df7K7OAC7c.jpg

 

 

 

Буду рад - если наша информация окажется полезной для проекта.

 

И вопрос один. Как можно исправить ситуацию в случае повторения ситуации? :)

 

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

Відредаговано jurrio
Ссылка на сообщение
Поделиться на других сайтах

Насколько понимаю, ваша проблема возникает при попытках доливки юзеров, поверх существующих. Собственно модуль "миграция 2" является сторонним, и мы слабо представляем чего там внутри вообще происходит. Есть подозрения, что он банально криво строит связи вида город->улица->дом->квартира->юзер, что заканчивается удалением неверных апартаментов, соседнего юзера. На практике, в случае миграции больших абонбаз мы используем старый модуль миграции, после чего пишем кастомный обработчик адресов уже для исходного формата.

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)

Практически. При дальнейшем тестировании выяснилось что можно сломать даже при полном отсутствии абонентов в базе изначально и ничего не удаляя после этого. Но в общем-то мы уже разобрались с проблемой. Даже сразу с двумя. Удаление номера квартиры при удалении абонента и кривой номер квартиры (при наших кривых ручках. ВНЕЗАПНО выяснилось, что номера офисов у нас записаны как 414/2. После изменения в формат 4142 - всё заработало. Ну и бекапы наше всё :)

Відредаговано jurrio
Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від camchatix
      Добрий день,
      створили запасний NAS із зайвою хромосомою, все працює але коли треба вбити сесію користувача - то у списку NAS серверів лише один (той що основний)
      переназначити швидкість теж не можу
      я так розумію пакети CoA Disconnect, CoA connect, PoD - ідуть на IP адресу старого NAS ?
    • Від grach_witch_cheese
      Вітаю, колеги!
      Маю наступну схему:
      DHCP-сервер: Accel-PPP (IPoE) DHCP-Relay: MikroTik RADIUS: Запущений безпосередньо на сервері uBilling Зараз авторизація абонентів здійснюється за MAC-адресою, але планується перехід на авторизацію через Option 82.
      У документації uBilling наведені приклади конфігурацій, коли DHCP-сервер працює локально (на самому uBilling) і містить відповідні шаблони для обробки Option 82.
      Однак немає чіткої інформації про використання Option 82 при віддаленому DHCP-сервері, зокрема, коли Accel-PPP використовується як DHCP-сервер у режимі remote та налаштований через Купаген.
      Питання:
      Чи можливо використовувати Accel-PPP як віддалений DHCP-сервер з авторизацією через Option 82? Якщо так, то де відбувається парсинг значень Remote-ID і Circuit-ID? Де в цьому випадку мають зберігатися шаблони для Option 82? Буду вдячний за роз'яснення або посилання на відповідні приклади.
    • Від nightfly
      Ubilling 1.5.2 rev 9302 Book of Endings
       
      Зміни в структурі БД. alter.ini: нова опція FASTPROFITCALC_ENABLED, що вмикає швидкий підрахунок прибутку. alter.ini: нова необов'язкова опція KARMA_IN_PROFILE що вмикає показ карми в профілі користувача. alter.ini: нова опція SWITCHES_AUTH_ENABLED, що вмикає довідник даних авторизації пристроїв. alter.ini: нова опція PON_SCRIPTS_ENABLED, що вмикає підтримку скриптів OLT в ПОНізаторі. alter.ini: нова опція PON_ONU_FDB_SELFFILTER, що вмикає фільтр MAC-ів при відображенні FDB за ONU. alter.ini: нова опція USERBYIP_ENABLED, що вмикає виклик userbyip в RemoteAPI. alter.ini: пачка нових опцій PB_FASTURL_*, що керують поведінкою модулю відсилання коротких посилань на оплату. Модуль PONizer: виправлена помилка зникнення PON інтерфейсів при опиті BDCOM GP3600 Модуль “Профіль користувача”: для опису плагінів профілю та оверлеїв на кшталт “чорної магії” тепер опційно можливо вказувати link_target. Модуль “Панель задач”: для опису елементів панелі задач, тепер опційно можна вказувати LINK_TARGET. Модуль Записи телефонних розмов: вирішено проблеми швидкодії, при перегляді списку записів дзвінків. Модуль “Записи телефонних розмов”: більше не призводить до вичерпання пам'яті процесу, при перегляді великих архівів дзвінків. Модуль “Записи телефонних розмов”: новий аудіо-плеєр для прослуховування записів з візуалізацією аудіо-хвилі. Модуль “Пошук оплат”: реалізовано можливість швиденького підрахунку прибутку по обраних чекбоксами платежах. Модуль УКВ: реалізовано можливість швиденького підрахунку прибутку по обраних чекбоксами платежах. Модулі Мапа обладнання та користувачів: трішки вичищено код. Ліпше не стало. Модуль “Мапа будинків”: поле пошуку при розташуванні будинку, тепер попередньо заповнено локацією, при переході за посиланням “розташувати на мапі”. Модуль “Панель задач”: опція TB_QUICKSEARCH_INLINE змінила свою поведінку, та може тепер приймати значення 0|1|2. Модуль “Звіт по трафіку”: виправлено проблему відображення графіків OphanimFlow для NAS на роздільних здатностях менше ніж FullHD. Кабінет користувача: в модулі “Відеоспостереження” відображення попереднього перегляду каналів користувача, стало трішки притомнішим. Сховище зображень: трішки покращено поведінку форми завантаження. RemoteAPI: новий виклик onusigcompressor, що радикально стискає розпухаючі дані історії сигналів ONU. RemoteAPI: новий виклик pbxmonrefill, що оновлює кеш записів телефонних розмов. RemoteAPI: новий виклик userbyip, що повертає дані про користувача за його IP. OpenPayz: в бекенді та фронтенді platon виправлено проблему диких заокруглень, при вказанні зовнішньої комісії.  
      Повний чейнджлог
      Оновлена демка
       

    • Від ppv
      Після оновлення до 1.5.1 не відображаються сигнали на
      OLT BDCOM P3310B (Device version10.1.0B)

      та
      P3608-2TE (Firmware Version10.1.0E). 

      3310C та P3608B ніяких проблем немає, знімає все добре. 
      З GPON3600-8 все зрозуміло будуть виправлення в Ubilling: 1.5.2.
       
      Може в когось було щось подібне? Хочу знати куди копати.
    • Від mac
      Глюк в тому, що один (так - тільки один) mac адрес onu існує в білінгу у вигляді строки. Це трохи заважає.
      olt - bdcom gepon.
      Наскільки зрозумів, це виключно проблема реалізації snmpwalk у freebsd, де snmpwalk може на свій розсуд віддати mac адресу не як hex-string, а як звичайний string.
      Можливо snmpwalk тригериться на якомусь символі, мені невідомо.
       
      # tcpdump -vv -i em0 udp port 161 and host olt and host ub | grep "3320.101.10.4.1.1.241 ... olt.snmp > ub.47940: [udp sum ok] { SNMPv2c C="*****" { GetResponse(44) R=93278354 E:3320.101.10.4.1.1.241="8LO"W*" } } ub.47940 > olt.snmp: [udp sum ok] { SNMPv2c C="*****" { GetNextRequest(34) R=93278355 E:3320.101.10.4.1.1.241 } } snmpwalk -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = STRING: "8LO\"W*" snmpwalk -Ox -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = Hex-STRING: 38 4C 4F 22 57 2A  
      Це стосується таких параметрів у snmp конфізі bdcom
       
      [signal] MACINDEX=".1.3.6.1.4.1.3320.101.10.4.1.1" [misc] ONUINDEX=".1.3.6.1.4.1.3320.101.11.1.1.3"  
      За для усунення глюку спробував трошки змінити код і завдати тип snmp параметру явно у ./api/libs/api.ponbdcom.php у function collect()
      Це працює. Мабуть станеться у нагоді:
       
      # diff api.ponbdcom.php{.new,.bak} 37c37 < $onuIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); --- > $onuIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); 91c91 < $macIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE); --- > $macIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE);  
      P.S. Створив тему, а зараз міркую: а може це глюк у ПЗ olt. Оновлю фірмваре olt та перевірю...
       

×
×
  • Створити нове...