BiTel

Скажу сразу - я в полном ступоре. Может, конечно, я устал за этот год и отупел, а может, что весьма вероятнее, я не могу решится на изыскания мектодом научного тыка, выясняя ползанием по базе и дебаговым выводом что же и как работает в этих шлюзах.

Ну во первых, редакторы шлюза в договоре, они сделаны под стандартные реализации шлюзов, а под скриптовые шлюзы заглушки редакторов есть ? Что делать если завтра в редактор Manad добавят еще 12 фичей на 5 закладках и они все вылезут у тех кто использует этот редактор для своих скриптовых шлюзов ?
Чем собственно все эти редакторы отличаются, судя по скринам в доке и полному отсутствию описания тот же микротик ничем не отличается от манада, тогда зачем он кроме как для путаницы ?

Дальше, формирование правил, описания идеалогии вообще никакого. После втыкания в базу, скрипты и скрины у меня возникает мысль что правила создаются один раз и сохраняются в ipn_user_gate_X.rule_txt. Это так или не так ? Если это не так то расскажите в конце концов как это все происходит, не мучайте.
Или этот текст автоматически перегенерируется когда изменяет тип шлюза ? Тогда откуда берутся адреса на которых юзер натыкал галочки в случае использования того же Манад-редактора гейта ?

Попытался понять как реализован Cisco шлюз... опять полные непонятки, если для каждого договора определяются только некоторые из ACL, то где это хранится ?
Ок, читаем скрипты:

Вот кому то ясно что тут происходит кроме тех кто заказывал изначально этот скрипт и тех кто его написал ?
В описании API, такого класса я тоже не нашел, а ожидать увидить там хотя бы однострочное описание не приходится вообще, даже для методов и классов широко пользуемых в пользовательских скриптах.

В итоге либо надо засаживаться и обвешивать скрипт кучей отладочной информации и пытаться понять что там происходит, либо пытаться по названиям методов и перечню атрибутов догадаться что же там происходит. Последнее обречено на провал: откуда в ruleText находится AclId я не понимаю, хоть убейте.

Откуда вообще пользователь сможет получить информацию о том какие механизмы имеются у него в распоряжении при написании скрипта ? Берем хотя бы bitel.billing.server.ipn.bean где собраны основные классы которые так или иначе всплывают в примерах, кроме названий вообще ничего. Так все таки, пользовательские скрипты в BGBilling это демонстрация гибкости которой можно воспользоваться только после того как требуемую заготовку напишут разработчики после постановки им задачи, или это функционал биллинга ? Опять же не понятно в рамках чего просить от вас пример реализации требуемого скрипта, в рамках доработки ? :-\

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

менять свои скриптовые шлюзы . Если мы меняем свое api , то при переходе на новую версию приходится же переделывать скрипты поведения, тут аналогичный случай.. ну мы по идее не будем все кардинально ломать , мы обычно стараемся оставить совместимость ..кстати из-за этой вот совместимости некорые вещиприходится делать криво, т.к мы не можем все сломать и переделать.
в данном случае - подменяется только логика серверной части, конструктора для универсального редактора шлюза мы пока не сделали (и не знаю будем ли делать вообще) .



все правильно .. редактор mikrotik от о реадатора manad ничем не отличается, кроме того, что у них разная обработка на сервере, поэтому они вызывают разные action-ы ..mikoitik наследует manad и переопределяет имя action-а . Аналогично на сервере там это тоже фактичкси один action, микротик от негто наследуюется и добавляет свой параметр {CID} в списки замены ..во и все ..



rule_txt. возомжны два случая:
1. нет типа правила , т.е пользователськое правило
тогда rule_txt. - содержит просто сырой набор команд , котрый выполняет то, что забил пользователь как есть, без всяких приобразований
2. есть тип правила ..тогда в этом поле хрантся настройки для шлюза в договоре - выбранные ip, acl и т.п . все это хранится в виде строки и каждый шлюз сохраняет эту строку в своем формате и парсит ее по своему .. сами команды шлюза тогда беруться из вкладки команды в конифгурации типа шлюза , в этих командах производится замена макросов типов правил(если есть) на значения типов правил.. вообще с типами правил несколько запутанно получилось, это опять же из-за совместимости с первым вариантом, когда еще не было скриптовых шлюзов



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

в шлюзе циско есть выбор acl и эти acl настриваются в конфиге(описано в докуменентации) ..допутсим их 3 штуки - test, test2, test3 . для кадой из них создается AclOptions , в котрой как раз и есть эти опйии из конифга для конретной acl .. далее в договоре выбирается одна из этих acl, выбираются ip все это засовыввается в rule_txt( оно же status.rule.getRuleText() ) как уже описано выше ..

CiscoRuleOptions - это уже детали реализации циски. Как вы уже отметили выше, многие шлюзы похожи. Аналогичным образом циска наследуюетс от manad и добавляем туда acl . поэтому в rule_txt хрянятся вначале manad-ские настрйоки (ip) , а потом уже после специального разделителя настрйоки циски (какая acl и с какой позиции добавляются команды) .. хорошо добавим CiscoRuleOptions и AclOptions в api-doc..



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

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

по сути есть два подхода к реализации скрипа 1) шлюз без правил, тип правила все равно какой, скрипт раскручивает через RangeManager адреса по договору и в соответсвии со статусами реализует что ему нужно
2) скрипт опирается на стандартный механизм шлюзов где "опции" связки договор-шлюз будут хранится в ruletxt, используя класс используемого шлюза Микротик/Циско/etc "опции"+правила шлюза дают набор команд, затем используя этот набор команд, информацию с железки (парсинг acl например) и статусы формируется буфер команд для изменения

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

дальше, использовать ruletext как хранилище "опций" можно либо вбивая его руками в виде замысловатой строки и как то там самому парсить в скрипте, либо использовать стандартный обработчик

я только не понял зачем тогда "пользовательское правило" если используется стандартный обработчик (редактор гейта), если я не сделаю заглушку в типах правилах то обработчик рейдактора гейта не станет ничего сохранять в ruletext, и не важно уже какая логика работы самого обработчика подмененного скриптом, да ?

теперь хотя бы примерно ясно что дебажить, сеньк.

почти так ..вообще то связка договор-шлюз хранится в таблице ipn_user_gate ..там есть поля cid и fwid, можете посмотреть в dbinfo ..rule_text - хранит всего лишь конфиги - наборы ip, acl и позицию acl ..Имеейте ввиду что шлюз циски вычисляет при первом сохранении позицию acl отдельно (ищет свободную ) ..потом эта позиця отображается если открыть шлюз на редактирование ..



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


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


не совем понял что вы хотите сказать .. пользовтелское парвило - это просто взяди и забили "permit 192.168.155.11" ..т.е без тспользования макросов , циклов и т.п

в случае например с cisco не совсем понятно, если "пользовательское правило", то вы написали что оно сохранится в чистом виде в ruletext, в этом случае информация об ACL теряется или она дописывается так же в ruletext ?

Видов серверов авторизации может быть великое множество.
Видов NASов - еще больше.

А не проще, чем все это делать в системе, дать простой и хорошо документированный интерфейс?

К примеру, по различным событиям просто запуск на сервере определенной системной комманды с параметрами. Так, чтобы параметры можно было брать из свойств договора (логина). И получение ответа из стандартного вывода...
Чем проще - тем лучше.

Там событий-то этих немного. Удалить аккаунт, добавить аккаунт, задать параметры аккаунта, запрос статуса (если шлюз позволяет). Всего-то...

И тогда без проблем можно будет делать связки с чем угодно. Хоть с freeradius, хоть еще с чем... Вот это будет гибкость!

Есть промер в wiki, но он недостаточно функционален - не позволяет прописать логин-пароль, например. Этото решение, как я понял, просто позволяет открыть или закрыть NAS для клиента. Авторизации там я не увидел.

да скрипт тебе позволяет все это сделать, и много больше
просто все упирается в понимание java, классов bitel, структуры данных в БД

Да понятно, что позволяет. Но на практике, не бывает программеров, которые знают все языки. Кому-то проще сделать на перле. Другой лучше бинарник сделает... А тут только ява (точнее довольно редкий BGBS) и все. Да еще и малодокументированные классы. А полностью эти классы открывать врядли будут...

И другое. Вот, к примеру - свой радиус. И проблемы... А не проще взять отлаженный, отработанный и фриварный? Пусть биллинг занимается подсчетом. Для управления NASом - простой интерфейс. И делай дальше что душа пожелает. Хоть в AD авторизуйся

К тому же, это позволит больше усилий кинуть на сам биллинг. Да хоть на документацию!

С этого все и начаналось, только если бы речь шла только про авторизацию и акакутинг, например пользователей офиса - согласен что нибудь типа фрирадиуса идеально подойдет.

Но вот когда с каждым update пакетом приходит трафик который надо учитывать, а авторизировать не просто по таблице типа да/нет, а по сложному алгоритму, взаимодействие между биллинг=фрирадиус=нас становиться очень муторным...

skn, на счет последнего моего вопроса: если стоит "пользовательское правило", то в cisco шлюзе информация об ACL не сохраняется в ruletext ?

это вопрос к stark, его творение...

А можнт лучше не ложить в кучу авторизацию и подсчет трафика?
Хотя, где-то "в кучу" будет лучше...
Но в IPN это можно безболезненно разделить, думаю.
И оставить шлюзу функции шлюза - "открыл/закрыл/проверил(состояние)". Зачем на него еще что-то вешать? Чем меньше модули, тем больше гибкость... И надежность этих модулей.

С IPN сплошная головная боль, скольно провайдеров столько схем подключения клиентов + зоопарк оборудования...

Вот в том то и дело!
Как-то бы абстрагироваться от оборудования... И от схем подключения (если получится).
Т.е. дать простой интерфейс (ну, писал уже), примеры решений...
А дальше эти решения будут плодиться как мухи. Но ядра БГБ это касаться уже не будет. В итоге - простота и надежность самого БГБ. И мудрите с ним внутри что хотите... Главное интерфейс не трогайте...

Примеров в ИТ масса. И всегда выигрывали решения, которые давали универсальность - т.е. доступный, документированный, постоянный (и пр.) интерфейс. Т.е. стандарт. IBM PC, WIN API, SQL и т.д.

теряется .. либо пользователськое либо наш алгоритм с учетом ip и адресов ..в ползовательском ни acl, ни ip не нужны - они теряются

Ну вообще мысль такая у нас есть, т.е вынести работу со шлюзами в отдельную подсистему и отвязать ее от баланса . У некоторых есть желание просто управлять некоторыми шлюзами без зависимости на баланс. Но это придётся сломать модуль IPN и не факт что унас получится это сделать "нежно", поэтому могут возникнуть проблемы при переходе на следующую версию .. и пока непонятно стоит ли это делать..


по поводу универсальности самой системы работы со шлюзами и вызова сторонних скриптов - вы и сейчас можете это делать .. вот вызов внешнего скрипта(можете писать его на любом языке):
http://wiki.bgbilling.ru/index.php/%D0% ... 0%B7%D0%B0
мы можем реализовать это в виде стандартного шлюза, который вызывает внешний скрипт. Он вас похоже все равно не устоит , так вам нужны какие-то параметры конкретно под вас , другому нужны - другие. В свое время был только manad - тоже вроде относительно гибкое решение основанное на внешних скриптах, но тоже далеко не всех устраивало ..вам нужны какие-то конкретные события(например некоторые просят уход ниже лимита ), а в бгб они возможно вообще не возникают и нам нужно их генерировать конкретно под ваше решение ..со шлюзом могут хотеть кроме ip хранить кучу информации - логин/пароль , адрес шлюза, флаг используется/не используется, mac -адерса , привзяка mac к ip, привязка mac к порту , vlan к порту и т.п .. причем желательно не в виде конифигов, а с нормальныим интрефейсом, чтобы был учет свободных портов, проверки всякие и т.п .. и каждый видит это по своему

Пока не видна универсальная схема , есть хаос из оборудования, типов сетей и способов управления всем этим ..внешние скрипты дают гибкость, но не полную.

продолжаю вникать в реализацию шлюзов...

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

вторая ситуация еще более интересная: для шлюзов cisco факт наличия правил проверяется лишь по номеру правила в ACL, при этом не проверяется ни полнота правил, ни соответсвие адресных блоков, при изменении в адресах договора обработчик шлюза не будет изменять конфигурацию, так как он просто не будет ничего делать, статус то не меняется, а определить в скрипте что договор изменялся можно только сделав полный парсинг ACL и сравнить по адресно конфигурацию и ACL, либо забить на все приведенные примеры скриптов на вики и формировать ACL каждый раз с нуля

а как более удобно ? вообще пустого правило надо ввести прямо в пукнт выпадающего меню и сделать его выбранным по умолчанию, т.е чтобы не надо было его добавлять на тип шлюза, пусть всегда будет выбранно ..потом уже пользователськое, потом все остальные


Я проверил на 4.6 ..дает сохранить с пустым пользовательским правилом, но добавляет туда номер acl

да, согласен

2 Jimson , прошу прощения, вмсесто цитирования исправил одно из ваших сообщений по ошибке

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

это позволит ограничить интерфейс договора и упростит заведение договора

а вот что делать с адресами я не понимаю, предложенный алгоритм не будет даже отрабатывать ситуацию расторжения договора (закрытие по периоду), адреса освободились, а шлюз хз чем заимается...
переписывать все с использованием AddressRangeManager ?

Хорошо.. подумаем над этим



пока не понятно как это сделать .Алгоритм этот старый

ну как это сделать как раз понятно, проверять при каждой итерации шлюза по каждому адресу его валидность, т.е. принадлежность к одному из ipn_user_range по данному договору на текущую дату

другая проблема, что надо делать при каждой итерации полный проход по всем договорам, и проверки в стиле шлюза Cisco - стартовая позиция есть в ACL значит в ACL актуальная информация по договору - не правильны, надо или сносить каждый раз весь ACL и генерить его заново, либо каждую строку ACL валидировать

попробую переписать скрипт шлюза cisco через AddressRange, остается открытым вопрос как из скрипта лучше всего получить перечень интерфейсов по AdressRange, ибо мне интереснее как раз ситуация когда по одному договору могут быть блоки адресов из разных VLAN, как следствие привязаных к разным интерфейсам и блокируемых _разными_ ACL

можно ли только битовой арифметикой, без циклов, верифицировать диапазон IP адресов заданный начальным и конечным адресом на предмет того что они являются соответсвенно адресом подсети и бродкастом из той же самой подсети ?

если А адрес подсети, а В бродкаст этой подсети, то маска этой подсети есть NOT (A XOR B), но вот как верифицировать А и В без цикличного побитового сдвига я не могу придумать

Что-то вроде этого:

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

ну и еще результат будет неверен для ситуаций типа 10.0.0.4 - 10.0.0.11, в этом случае будет ответ 10.0.0.0/29, так как 10.0.0.11 используется только для первичного вычисления маски (размерности подсети) и в дальнейшем нигде не проверяется совпадение вычисленной сети с первичным диапазоном

объясните....
имеем таблица ipn_user_source
в ней ссылка на ipn_iface идет почему то через номер интерфейса, хотя в ipn_iface есть намек на первичный ключ ID
далее, смотрим API - RageIface class
метод getIface() возвращает null всегда, а метод getIfaceId() возвращает номер интерфейса

где логика ? поневоле возникает мысль что рано или позно, когда дойдут руки, это все перепишут "руками" и после какого-нибудь апдейта скрипты "сломаются"

RangeIfaceManager.getAdressRangeIfaces( int aid) -- опечатка в имени метода, пропустили букву, но когда писали код использующий этот метод ведь должны были заметить опечатку, визуальные средства разработки ?

P.S. я вот тут подумал... если я изменю номер интерфейса в списке интерфейсов модуля IPN, то.... отсутствие внешней ссылки на ID интерфейса из таблицы ipn_user_source наводит на мысли что все станет в интересную позу, я не прав ?

Лично я представляю возможность создавать шлюз со стороны интерфейса путем написания своей конфигурации:
например Текстовое поле... описывает по типу
Переменная=text1("Описание текстового поля";"длина текстового поля";"значение по умолчанию" ; "ну и по пожеланию парсер типа X-XX-XX ")
Либо меню типа список
Переменная=select1("Описание 1 текстового поля", "что отдаем в переменную если выбрано 1 значение"; "Описание 2 текстового поля", "что отдаем в переменную если выбрано 2 значение";)

Пользователь сам создает структуру своего интерфейса и может пользоваться стандартными "глобальными" переменными как Адрес, статус и прочее...
то что Шлюз надо вынести из самого модуля биллинга это однозначно...
Вам же просто придется один раз описать саму логику построения интерфейса, переменные, ну и АПИ функции

А потом вы захотите вкладку , красивое гибкое расположение, оригинальное взаимодействие компонтентов и т.п ..Т.е вам фактически swing нужен, т.е библиотека построения интерфейса ..Есть идея по добавлению возможности создавать свой интерфейс на BeanShell , но пока работа не начата

Хорошая идея... поддерживаю полностью