stark писал(а):
... Толко вот добавим мы это наверное в 4.6. Рискнете скачать dhcp от 4.6 и протестировать если мы сейчас это исправим ? . накатывать на 4.5 пока это не хочется, так ошибки могут полезть . Может быть, если это заработает, то пропатчим 4.5 .
Протестировать могу и сообщить результаты. Однако я чуть дальше пошел и разбор зухелевского option82 для меня все-равно будет не достаточно, поэтому я пока использую свой писаный на perl'е dhcpd.
Цитата:
Вопрос - что вы хотите ? создать свой собственный редактор?
gate_manager.class, который вы подменяете , это серверный класс, экземпляр которого вызывается при синхронизации со шлюзом. Причем там подменяется только метод doSync, но не подменяется метод взаимодействия со шлюзами-предками, тут можно тоже сделать гибкое решение.
user_rule.editor.class - это клиентский класс , который представляет из себя панельку, наследуемую от swing-кого класса JPanel. Грубо говоря она умеет отображать на себе элементы и посылать запросы на сервер, показывать ответ сервера . Но со стороны сервера для поддержки этой панельки есть еще специальный action, или несколько action-ов, в зависимости от логики панели. допустим action сделать на BeanShell можно.Т.е это будет некоторое действие , которое можно будет взывать из клиента и получать результат. чисто теоретически можно сделать и создание gui с помощью beanshell и поддержать это клиенте биллинга, вопрос нужно ли это ? Плюс еще возможно вы захотите сохранять специфические данные для этого шлюза в специфических таблицах. Вопрос нужно ли нам делать подобную сложность? Может быть нам проще открыть исходники тогда возникнет вопрос с обновлениями, мы не сможем поддерживать отельную копию исходников на каждого клиента, да еще во все добавлять новый функционал . Короче я клоню просто к тому — какой редактор вам нужен? Может просто нам разработать его конкретно для вас и все ? Или сами его разрабатываете и добавляете отдельной jar-кой в исходники. или давайте поймем что вам нужно, может быть это нужно не только вам, и придумаем универсальное решение.
Пришлось разобраться и с Action'ами и описаниями шлюзов чтобы понять как происходит синхронизация зависимых шлюзов.
Чтобы было понятно зачем все это - мне нужно выдавать vlan на коммутатор, а юзеров авторизовать по номеру порта и mac'у, причем конфигурировать центральный свич cisco2 мне не нужно, хотя он физически в схеме сети присутствует. Возможно эту задачу можно решить стандартно, но я не разобрался как ((
После перебора всех возможных типов шлюзов и самих шлюзов (gate_manager.class, user_rule.editor.class), понял что "прямо" мою схему не реализовать.
Единственный подходящий мне user_rule.editor где есть привязка с порту и mac'у это bitel.billing.server.ipn.vlan.CiscoVlanGateWorker. Такая-же привязка есть и в bitel.billing.server.ipn.vlan.CiscoSSHSwitchGateWorker, но если использовать его, то необходимо использовать связку DHCP+Cisco2+Zyxel, только в этом случае DHCP будет синхронизироваться. При использовании bitel.billing.server.ipn.vlan.CiscoVlanGateWorker я делаю связку DHCP+Zyxel, при этом в редакторе я получаю то что мне нужно - ip, mac, port, vlan и синхронизацию DHCP. Лишнее при этом только вкладка CISCO, но она вообщем-то не мешает.
Далее столкнулся с проблемой, что при синхронизации шлюза DHCP, в dhcpd отсылается в параметре id номер vlan'а и нигде нет номера порта. Первая мысль - использовать свой скрипт в типе шлюза DHCP через use.script=1 и описать свой doSync().
Не вышло )))
В DHCPGateWorker мне нужно изменить parentSync, в котором содержится код по формированию XML'а для передачи в dhcpd. Ну выход нашел только один - написать свой myDHCPGateWorker, всунуть его в ipn.jar и указать в качестве gate_manager.class для типа шлюза DHCP.
Это помогло. В итоге получил достаточно гибкую для меня систему - авторизация юзера может выполняться по любым комбинациям из vlan, port, mac, либо возможно отсутствие одного из эти параметров (это реализовано в моем perl'ом dhcpd). Но вот в редакторе, если не указать номер порта, то и mac удаляется. Это я так понимаю нужно исправлять на стороне клиента.
Мой dhcp в итоге получает следующее:
Код:
<portMac gateId="7" vlan="403" port="1" ip="AC 14 01 01" mac="01 01 01 01 01 01"/>
<portMac gateId="7" vlan="403" port="1" ip="AC 14 01 02" mac="02 02 02 02 02 02"/>
<portMac gateId="7" vlan="403" port="2" ip="AC 14 01 03" mac="03 03 03 03 03 03"/>
И в данном конкретном случае на один порт N1 завязано два IP/MAC - например к порту будут через домашний свитч подключено два компьютера.
Лично я считаю, что если бы подмену того-же parentSync, да и вообще любого метода любого класса (ну или не любого) можно было делать подобно gate_manager.class, то система получила бы огромную гибкость.
Что касается обновлений, то тут конечно забота о совместимости своих кодов с новыми версиями должна ложиться на самого программера, который подменяет своим кодом стандартный.
Вход
Регистрация
FAQ
Поиск
