Напишу полноценный DHCP сервер работающий с SQL СУБД.

Технические вопросы по UTM 5.0
Ответить

Как по вашему, нужен-ли кроссплатформенный DHCP сервер хранящий конфигурацию SQL БД?

Да.
71
79%
Нет.
10
11%
Затрудняюсь ответить.
9
10%
 
Всего голосов: 90

RomanCh
Сообщения: 20
Зарегистрирован: Вт авг 18, 2009 16:54
Контактная информация:

Сообщение RomanCh »

Arti писал(а):Управлять доступом нужно на порту свича. Т.е. клиент однозначно идентифицируется парой айди свича (обычно ip адрес) порт свича.

Например баланс ушел в ноль - дальше "личного кабинета" пользователь не уйдет, даже к соседу в этом же доме ;).
Это да. Если каждый юзер в умный свитч воткнут отдельно. А если нет?.. И как "управлять доступом" админам частных ресурсов? По каждому бану звонить провайдеру и просить узнать что такого-то числа во столько-то накакал на его форуме?.. А потом просить его залочить?

Arti
Сообщения: 266
Зарегистрирован: Пн окт 01, 2007 02:44

Сообщение Arti »

По-моему конструктив закончился или не начинался....

Удачи Вам и заранее спасибо.

RomanCh
Сообщения: 20
Зарегистрирован: Вт авг 18, 2009 16:54
Контактная информация:

Сообщение RomanCh »

Arti писал(а):По-моему конструктив закончился или не начинался....
Я думаю второе.

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

Davion
Сообщения: 267
Зарегистрирован: Чт дек 01, 2005 13:36

Сообщение Davion »

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

AndrewE
Сообщения: 230
Зарегистрирован: Пн июл 17, 2006 07:38

Сообщение AndrewE »

RomanCh, вы напишите DHCP-Server с хранением лизов, параметров пользователя в БД, будет просто супер. Как вы наверное уже поняли, очень многие нуждаются в подобном решении.

Авторизация абонентов: Opt82 и MAC, это достаточно, в любом случае других вариантов практически нет. Разумеется нужно предусмотреть возможность работы без привязки к Opt82 или MAC (например для публичных сетей).

очень пригодилось бы, наличие информации о том, когда последний раз клиент (по id свитча + порт или MAC) обращался к DHCP.

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

RomanCh
Сообщения: 20
Зарегистрирован: Вт авг 18, 2009 16:54
Контактная информация:

Сообщение RomanCh »

AndrewE писал(а):Разумеется нужно предусмотреть возможность работы без привязки к Opt82 или MAC (например для публичных сетей).
Т.е. обычный динамический пул? Ну это само собой подразумевается.
AndrewE писал(а): очень пригодилось бы, наличие информации о том, когда последний раз клиент (по id свитча + порт или MAC) обращался к DHCP.
Это тоже обязательно. Как в логах сервера, так и в БД.
AndrewE писал(а): Ну и главное на мой взгляд, предусмотреть возможность самому писать SQL запросы для получения необходимых параметров для работы сервер DHCP. Данная фишка позволит адаптировать сервер практически к любому биллингу.
На мой взгляд в любом случае придётся унифицировать ответы сервера БД. Т.е. выдавать их в формате аналогичном формату RADIUS БД: первая колонка - код опции, вторая - значение опции. На сколько я понимаю - это можно будет сформировать на любой БД.
Сами SQL-запросы разумеется задаются пользователем.

Кстати кто что думает на тему IPv6? Я так полагаю что поддержку надо хотя бы заложить в обязательном порядке. Вроде как недолго IPv4 жить осталось.

AndrewE
Сообщения: 230
Зарегистрирован: Пн июл 17, 2006 07:38

Сообщение AndrewE »

RomanCh писал(а): На мой взгляд в любом случае придётся унифицировать ответы сервера БД. Т.е. выдавать их в формате аналогичном формату RADIUS БД: первая колонка - код опции, вторая - значение опции. На сколько я понимаю - это можно будет сформировать на любой БД.
Сами SQL-запросы разумеется задаются пользователем.
ну мб в dhcpd.conf
сделать что -то типа такого:

sql_get_client_params = "SELECT ... as client_ip, ... as client_netmask, ... as client_gateway FROM... WHERE ...."

т.е. SQL запросы к БД должны быть настраивамые с возвратом предопределеных полей. Разумеется в качестве примера, можно сделать демонстрационную БД с примерами запросов к ней.
RomanCh писал(а): Кстати кто что думает на тему IPv6? Я так полагаю что поддержку надо хотя бы заложить в обязательном порядке. Вроде как недолго IPv4 жить осталось.
IPv4 осталось жить еще минумум лет 10, но основу для IPv6 заложить конечно нужно.


Если я могу чем-то помочь, пишите на shicoy () mail.ru
т.е. можем помочь с разработкой web-admin для DHCPd, проектированием DB, тестированием.

RomanCh
Сообщения: 20
Зарегистрирован: Вт авг 18, 2009 16:54
Контактная информация:

Сообщение RomanCh »

AndrewE писал(а): сделать что -то типа такого:

sql_get_client_params = "SELECT ... as client_ip, ... as client_netmask, ... as client_gateway FROM... WHERE ...."

т.е. SQL запросы к БД должны быть настраивамые с возвратом предопределеных полей. Разумеется в качестве примера, можно сделать демонстрационную БД с примерами запросов к ней.
Не не, думаю это как раз не верное решение. Теоретически мы можем в БД закладывать десятки параметров для клиентов. И динамически изменять их число. Следовательно придётся каждый раз лезть в конфиг и изменять его. Помоему надо придеживаться концепции

Код: Выделить всё

SELECT option_id, option_value FROM ...
А вот то что после FROM уже должно настраиваться. Т.е. в принципе к нужному формату ответа БД можно привести при помощи организации дополнительных VIEW либо с использованием UNION (кстати этот вариант испробованный и достаточно экономичный). В случае использования VIEW в принципе можно в конфиге сервера вообще ничего не менять.
AndrewE писал(а): Если я могу чем-то помочь, пишите на shicoy () mail.ru
т.е. можем помочь с разработкой web-admin для DHCPd, проектированием DB, тестированием.
Спасибо, буду иметь ввиду. Сообщу как только будет что-нибудь мало-мальски рабочее.

Ещё всплыл вопрос. В каких обычно форматах передаются опции 82 различными моделями устройств? Совершенно очевидно что парсинг 82й опции так же нужно делать настраиваевым. Хочется увидеть возможные варианты представления этих опций в разных моделях сетевого оборудования от различных вендоров.

dk
Сообщения: 424
Зарегистрирован: Чт авг 10, 2006 08:52

Сообщение dk »

А БД не загнётся?..

RomanCh
Сообщения: 20
Зарегистрирован: Вт авг 18, 2009 16:54
Контактная информация:

Сообщение RomanCh »

dk писал(а):А БД не загнётся?..
А с чего она должна загнуться? У нас - работает и не загинается. В сети более 25 тысяч пользователей.

JAO
Сообщения: 1153
Зарегистрирован: Вт дек 11, 2007 08:17

Сообщение JAO »

Включайте кэш запросов, тогда не загнется. В этом случае обращений на чтение в разы больше чем на запись. А когда так, есть смысл включить кэш. Если конечно база не считывается целиком в память по факту ее изменения. Тогда единственное что может загнуться - это сам dhcpd.

RomanCh
Сообщения: 20
Зарегистрирован: Вт авг 18, 2009 16:54
Контактная информация:

Сообщение RomanCh »

JAO писал(а):Включайте кэш запросов, тогда не загнется. В этом случае обращений на чтение в разы больше чем на запись. А когда так, есть смысл включить кэш.
Ну в патче к dhcpd как раз это и реализовано. Без кэша сервер конечно начал бы загинаться достаточно быстро. Непосредственно запрос к БД идёт только в случае получения DHCPDISCOVER.
JAO писал(а): Если конечно база не считывается целиком в память по факту ее изменения. Тогда единственное что может загнуться - это сам dhcpd.
Это ИМХО какой-то совсем странный путь решения :-)

JAO
Сообщения: 1153
Зарегистрирован: Вт дек 11, 2007 08:17

Сообщение JAO »

Тем не менее шустро будет бегать. Когда давят запросами, начинается пора оптимизаций типа кто быстрее - тот и тащит. Быстрее обычно оказывается оперативка, медленнее - диск. Чем больше обращений в оперативку и чем меньше на диск - тем лучше, большую нагрузку выдержит. Это верно как для однопроцессорных машин, так и для SMP. Чем шустрее отдельные ноды в кластере, тем лучше. Поэтому появились memcached, nginx, буферизация чтения-записи и много тому подобного.

RomanCh
Сообщения: 20
Зарегистрирован: Вт авг 18, 2009 16:54
Контактная информация:

Сообщение RomanCh »

JAO писал(а):Тем не менее шустро будет бегать. Когда давят запросами, начинается пора оптимизаций типа кто быстрее - тот и тащит. Быстрее обычно оказывается оперативка, медленнее - диск. Чем больше обращений в оперативку и чем меньше на диск - тем лучше, большую нагрузку выдержит.
Именно потому и организовано кэширование запросов но на уровне DHCP протокола, а не полного дампа БД ;-)

JAO
Сообщения: 1153
Зарегистрирован: Вт дек 11, 2007 08:17

Сообщение JAO »

Это и правильно. Но в том посте имелся в виду кэш запросов MySQL, я его включаю везде, где запросов на чтение больше чем на запись. Тогда фактическое обращение к базе идет только если была в нее запись, а так все летит из кэша. Если же нет гарантии, что какой-то конкретный движок БД (или сервер) умеет кэшировать запросы, то лучше нечто свое слепить.

Ответить