Перейти до

Налаштування UHW


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

FreeBSD 9.3  9.2 x86
uBilling ставив через ubinstaller

 

Здрастуйте, така проблемка:
 

Якщо чемно слідувати інструкції по встановленню UHW на пункті

 

"6. Уносим uhw из дистрибутива Ubilling в соответствующее место:"

на команду "cp -R docs/uhw..."
 

система матюкається "No such file or directory" =(

 

передивився диск, включив WinSCP, кинув пошук, не знайшов.

Хтось може підказати, куди рити?

 

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

В FreeBSD 9.3 по дефолту собран Apache 2.4.

Собственно а вас не насторожило, что базовый путь к директории billing  из которой вы пытались чего-то куда-то копировать, у вас выглядит как /usr/local/www/apache24/data/billing ?

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

Дякую Вам, познайомився з командою locate, :)

знайшов папку uhw в "..apache22/data/billing/docs/uhw"

потрібно було лише опуститися в папку )

 

 

В FreeBSD 9.3 по дефолту собран Apache 2.4.

Собственно а вас не насторожило, что базовый путь к директории billing  из которой вы пытались чего-то куда-то копировать, у вас выглядит как /usr/local/www/apache24/data/billing ?

 

Якщо мислити логічно, стоїть 9.2 )

Дякую

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

 

Дякую Вам, познайомився з командою locate, :)

Залишилось, ще познайомитись з find і буде взагалі люкс.

 

FreeBSD 9.3 x86 uBilling ставив через ubinstaller

Екхм?

 

 

 

Дякую Вам, познайомився з командою locate, :) знайшов папку uhw в "..apache22/data/billing/docs/uhw"

Екхм!

 

 

 

Якщо мислити логічно, стоїть 9.2 )

Не бачу жодної логіки. Свідомість зламано. Відсипте і мені троха тої трави.

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

 

 

Дякую Вам, познайомився з командою locate, :)

Залишилось, ще познайомитись з find і буде взагалі люкс.

 

FreeBSD 9.3 x86 uBilling ставив через ubinstaller

Екхм?

 

 

 

Дякую Вам, познайомився з командою locate, :) знайшов папку uhw в "..apache22/data/billing/docs/uhw"

Екхм!

 

 

 

Якщо мислити логічно, стоїть 9.2 )

Не бачу жодної логіки. Свідомість зламано. Відсипте і мені троха тої трави.

 

ну, ви кажете в 9.3 по дефолту apache 2.4, отже в мене старіша версія системи, а отже 9.2.

 

бачу систему треба вчити

 

Коли ваша ласка, підкажіть що почитати для розуміння налаштування DHCP 

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

 

 

Только не говорите, что не знали... 

 

Взагалі команди не знав,

після повідомлення пана Nightfly про апач 2.4, подивився в вебморді Ubilling'у

дякую, тепер і так буду вміти.

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

Ще допоможіть, коли ваша ласка, з такою проблемою:

 

коли незареєстрованого користувача форвардить на 192.168.12.252/uhw/ йому показується та сторінка, яка потрібно (UHW),

потім кидає на "сайт провайдера"(поставив google.com.ua, бо сайту нема і не треба),

оскільки користувач невідомий,

його знову форвардить на ../uhw/
 

і так циклічно прокручує його по цьому замкнутому колі.

як зрозумів з коду,
проблема з перевіркою значення "unknown network" користувача.

 

чи може бути проблема в тому, що мережа 192.168.8.0/21 (мережа адрес невідомих користувачів) (прикрутив так для того, щоб було видно сервер на 192.168.12.252)
перекривається з  моєю загальною 192.168.12.0/20 ?

 

тоді питання, якщо нормально прописувати все це діло (розносити на неперекриваємі),
то чи потрібно в модулі "Сети и услуги" (та DHCP відповідно) прописувати окрему мережу?

 

P.S. коли написав, поняв, що можна було невідомих користувачів в окремій мережі прописати і прикрутити аліас на інтерфейс, але може проблема і не в цьому?

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

 

чи може бути проблема в тому, що мережа 192.168.8.0/21 (мережа адрес невідомих користувачів) (прикрутив так для того, щоб було видно сервер на 192.168.12.252)

перекривається з  моєю загальною 192.168.12.0/20 ?

Ну візьміть калькулятор та порахуйте собі перекриваються чи ні, в чому проблема? :)

 

На справді, чисто логічно якщо подумати - як UHW мав би вгадати по вигляду однакових мереж повгадувати, хто з тих абонентів є "невідомим"?

 

Взагалі - чим далі та мережа буде від реалій нормальних абонентів, тим краще. Дивимось в мануал і звертаємо увагу на оте місце де сказано про аліас, на який повинна ходити отаво мережа "невідомих". Загалом я так підозрюю вся ваша проблема, тільки в "зворотньому" розумінні роботи даного сервісу.

 

ЗІ раз вже почали гратись в заверталки абонентів, також раджу звернути увагу на заворот боржників в кабінет і як воно спільно з UHW працює.

 

P.S. коли написав, поняв, що можна було невідомих користувачів в окремій мережі прописати і прикрутити аліас на інтерфейс, але може проблема і не в цьому?

Блін. Поки дописав своє повідомлення помітив оцей постскриптум.Так саме - в цьому. :)

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

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

В uhw.ini треба правильно вказати 

UNKNOWN_MASK="ххх.ххх."

Де ххх.ххх - це перші, або можно і три октети адрес невідомих.

Без цього фаєр буде заворачувати на ухв, а ухв скаже, шо вони не невідомі і відправить на гугля - і так по колу.

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

з заворотом розібрався, спасибі Богу, документації, форуму і man.

 

Моя проблема була в тому, що не знав отого пункту про "UNKNOWN_MASK". (тобто нерозуміння роботи механізму ПХП функціїї яка перевіряє "невідомість" користувача)

 

Дякую за чіткі відповіді.

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

 

раджу звернути увагу на заворот боржників в кабінет

з заворотом розібрався, спасибі Богу, документації, форуму і man.

 

Моя проблема була в тому, що не знав отого пункту про "UNKNOWN_MASK". (тобто нерозуміння роботи механізму ПХП функціїї яка перевіряє "невідомість" користувача)

 

Дякую за чіткі відповіді.

 

Якщо уважно подивитися у доку по УХВ, то можна знайти наступне:

; Маска IP подсети неизвестных пользователей 

UNKNOWN_MASK="172.32."

UNKNOWN_LEASE="DHCPACK on "

А також дуже важливий пункт, без якого УХВ не працює

Правильный уровень логирования isc-dhcpd

Для того чтобы облегчить поиск и диагностику проблем у пользователей рекомендуется в /etc/syslog.conf вписать в конец конфига

!dhcpd

*.* /var/log/dhcpd.log

с последующим перезапуском dhcpd и syslogd

# touch /var/log/dhcpd.log

# /usr/local/etc/rc.d/isc-dhcpd restart

# /etc/rc.d/syslogd restart

И правильно вказати у конфігу УХВ шлях до логу дхцп.

 ; Пути к необходимому ПО

SUDO_PATH="/usr/local/bin/sudo"

CAT_PATH="/bin/cat"

GREP_PATH="/usr/bin/grep"

TAIL_PATH="/usr/bin/tail"

LOG_PATH="/var/log/dhcpd.log"

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

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

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

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

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

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

Вхід

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

Войти сейчас
  • Зараз на сторінці   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 та перевірю...
       

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