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

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

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

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

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

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

Сообщение RomanCh »

Доброго времени всем.

И так, к делу. Есть у меня желание написать кроссплатформенный DHCP сервер изначально ориентированный на работу с различными SQL СУБД. На сколько я понимаю - подобный софт будет очень востребованным в провайдерской деятельности.

Имеются следующие вопросы к всем заинтересованным лицам:
1. Есть-ли смысл привязываться к какой-то конкретной структуре БД (определённым таблицам, представлениям, полям в них и т.д) или структура БД не принципиальна?
2. По каким принципам идентифицировать DHCP клиентов? Мне видится актуальным: по MAC адресу, option-82. Возможно что-то ещё?

Интересно будет услышать пожелания и предложения по данной теме.

PS Решения вида http://www.netpatch.ru/dhcp2radius.html (моё решение) - в расчёт не берутся ибо являются костылём по своей сути. Кроме того - очень не хочется как-либо связываться с кодом от ISC в силу его страшной неуклюжести.
Удобность работы с DHCP через FreeRADIUS ИМХО не слишком очевидна и выглядит несколько костылеобразно.

amix
Сообщения: 50
Зарегистрирован: Чт фев 24, 2005 15:05

Сообщение amix »

Имхо если делать чтото подобное, то только в виде патча к isc
идеально было бы увидеть чтонить типа bind+dlz

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

Сообщение RomanCh »

amix писал(а):Имхо если делать чтото подобное, то только в виде патча к isc
идеально было бы увидеть чтонить типа bind+dlz
Предлагаю на досуге ознакомиться с исходниками от ISC. Лучше всего их использовать в качестве примера "как не надо писать код".
Благодаря этой особенности в них куча багов, которые каждый дистрибьютор ОС патчит по своему. FreeBSD по своему, Gentoo по своему, Debian по своему и т.д... В итоге патч применять становится крайне затруднительно. Где-то он работает, где-то нет.
Например изначально разработчиками ISC задумывалось что dhcpd не должен уметь слушать loopback интерфейс, но он умеет слушать, потому в сорцах без патчей от сторонних дистрибьютеров есть возможность запустить dhcpd & freeradius на одном и том же хосте. Но например в FreeBSD пропатчили эту багу, и если брать сорцы из портов - на одном хосте без жуткого шаманизма запустить не получается. Или "это не баг, это фича!"?

Да и вообще - какой смысл прилепливать "сбоку припёку" к проекту который изначально на это не расчитан? По факту - тот патч из ISC DHCP использует только функцию получения запроса, чтения конфига и отправки ответа. Всё остальное - написано мною включая логику ответов DHCP. Ибо сделать так проще, быстрее и даже правильней, чем пытаться понять что имели ввиду девелоперы ISC пишущие функции по 600 строчек в одной, рекурсивно вызывающие друг друга...

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

Сообщение Arti »

Зачем нужен полноценный?

Если конфиг хранится в mysql, то скорей всего работает релей + 82 опция, а это юникаст. Программа становится очень простой...

В сети есть уже готовые реализации. В свое время я начал делать свое... Кстати в isc смотреть особо нечего, от туда нужно только dhcp.h :).

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

Сообщение RomanCh »

Arti писал(а):Зачем нужен полноценный?
Если конфиг хранится в mysql, то скорей всего работает релей + 82
Что-то не вижу собой связи между mysql и релеем.
Arti писал(а): опция, а это юникаст. Программа становится очень простой...
Ну так ни кто и не говорит что программа архисложная. Она вообще относительно простая в любом случае. Просто почему-то ни кто не реализует ничего нормального до сих пор. В основном пользуются различными костылями.
Arti писал(а):В сети есть уже готовые реализации.
Пример пожалуйста. Адекватный, поддерживаемый, написанный не на питоне.

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

Сообщение Arti »

RomanCh писал(а): Что-то не вижу собой связи между mysql и релеем.
Самая прямая. Если используется БД - значит кофиг большой и/или содержит условия выдачи адресов. Стандартный вариат сообщить дополнительные данные о клиенте - 82 опция. Как правило 82 опция заполняется коммутатором именно при релее.

В общем если все можно описать парой десятков строк - не вижу недостатков в версии от isc ;).

Был где-то готовый сервачёк. Точно не вспомню название точно... SСND или еще как... Врядли автор его поддерживает. там радиус/snmp/dhcp в одном флаконе. DHCP там был кстати реализован именно для работы с релеем.

Ну также не факт что Вы будете поддерживать свой продукт :).

P.S.
Нашел я страничку SCND
http://www.chics.ru/~daniil/scnd/doc/

max1976
Сообщения: 8
Зарегистрирован: Вс авг 14, 2005 21:18

Сообщение max1976 »

RomanCh писал(а): Адекватный, поддерживаемый, написанный не на питоне.
http://sourceforge.net/projects/opendhcp/ этот посмотрите...

Аватара пользователя
Chris
Сообщения: 2323
Зарегистрирован: Чт июн 02, 2005 14:08
Откуда: 33 76 77 71 86 37 98

Сообщение Chris »

The "opendhcp/v1.0.0/opendhcp-1.0.0.tar.gz" file could not be found or is not available. Please select another file.

max1976
Сообщения: 8
Зарегистрирован: Вс авг 14, 2005 21:18

Сообщение max1976 »

Chris писал(а):The "opendhcp/v1.0.0/opendhcp-1.0.0.tar.gz" file could not be found or is not available. Please select another file.
http://downloads.sourceforge.net/projec ... 0.1.tar.gz

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

Сообщение RomanCh »

Arti писал(а): Самая прямая. Если используется БД - значит кофиг большой и/или содержит условия выдачи адресов. Стандартный вариат сообщить дополнительные данные о клиенте - 82 опция. Как правило 82 опция заполняется коммутатором именно при релее.
Честно говоря сомнительные на мой взгляд доводы. К тому же - релей вовсе не обязательно свитч с опцией 82. Ну да ладно - это не важно.
Arti писал(а): В общем если все можно описать парой десятков строк - не вижу недостатков в версии от isc ;).
Я выше указал недостатки.
Arti писал(а): Врядли автор его поддерживает.
А на кой он тогда нужен? Самому если что дописывать? Спасибо, я уже наупражнялся ;-)
Arti писал(а): там радиус/snmp/dhcp в одном флаконе.
Испытываю органическое отвращение к подобным "кухонным комбайнам". Это не более чем моё ИМХО конечно. Хотя - не только моё.
Arti писал(а): Ну также не факт что Вы будете поддерживать свой продукт :).
А я его изначально постараюсь написать так что бы при желании можно было поддерживать кому угодно без сверх трудозатрат. И кроме того постараюсь добиться включения в популярные дистрибутивы. Не будет желания/времени поддерживать самому - отдам на поддержание коммунити. Желающие поддерживать наверняка найдутся. Было бы что поддерживать.
Arti писал(а): P.S.
Нашел я страничку SCND
http://www.chics.ru/~daniil/scnd/doc/
Ага, посмотрел. Стиль примерно тот же что у ISC, только круче. Открыл файл dhcp.c, наблюдаю в нём функцию dhcp() без малого на 700 строчек. С кучей строк имеющих "магические числа" внутри, типа:

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

for&#40; n=0, err_f=0; n<sizeof&#40;buf&#41; - 240 ; n += option->leng +2&#41;
Вопрос - что такое 240? 2 - я ещё могу догадаться более-менее по контексту. У ISC все подобные цифры хотя бы являются задефайненными именованными константами.
Уже "впечатляет". Не удивительно что ни кем не поддерживается.
Далее:
ОС FreeBSD, (под Linux собирается, но не тестировался)
Ай, ай. У меня даже не собрался. Вникать почему так - нет особого желания, коли автор не позаботился о нормальном конфигураторе который скажет что не так.
При установки SCND в среде FreeBSD все вышеперечисленные пакеты устанавливаются из портов, кроме библиотек xmlrpc-c. К сожалению, порт xmlrpc-c давно не обновлялся, и этот пакет придется установить вручную, скачав исходный код с сайта http://xmlrpc-c.sourceforge.net/.
Тоже как-то стрёмновато выглядит. Вам не кажется?
DHCP сервер обрабатывает пакеты с сообщениями, прошедшие через маршрутизатор с функцией DHCP Relay. DHCP сервер не может непосредственно обслуживать напрямую подключенную сеть, так как работает только с юникастовыми пакетами.
Это уже НЕ DHCP сервер, а что-то такое недоделанное. Как в общем и ожидалось от "кухонного комбайна". Далее обсуждать смысла не вижу.

max1976 - посмотрел. Поддерживает только PostgreSQL. Согласен - БД хорошая, сам обычно её юзаю. Но... Что использует большинство? Я думаю Вы знаете.
Опять же - у меня на Gentoo даже не собралось. Почему? Потому что автор взялся писать на С++ по стандартам 95го года (примерно) или вобоще без стандартов. :( Уж не знаю в чём он его собирал что собралось...

Касательно обоих предложений - ИМХО то что они не включены ни в один популярный диструбутив крайне подозрительно. Не зря же так случается.

Аватара пользователя
Chris
Сообщения: 2323
Зарегистрирован: Чт июн 02, 2005 14:08
Откуда: 33 76 77 71 86 37 98

Сообщение Chris »

max1976 писал(а):
Chris писал(а):The "opendhcp/v1.0.0/opendhcp-1.0.0.tar.gz" file could not be found or is not available. Please select another file.
http://downloads.sourceforge.net/projec ... 0.1.tar.gz
ПИЛЯТЬ... САМ ТО ЗАХОДИЛ ТУДА? ПИШЕТ The "opendhcp/v1.0.1/opendhcp-1.0.1.tar.gz" file could not be found or is not available. Please select another file.

Аватара пользователя
Chris
Сообщения: 2323
Зарегистрирован: Чт июн 02, 2005 14:08
Откуда: 33 76 77 71 86 37 98

Сообщение Chris »

Роман! Идея супер, я тебя поддерживаю! Остальные идите отдыхайте! Чего то все ищите скрипты для автоматизации работы с ISC DHCPD

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

Сообщение Arti »

RomanCh писал(а): Честно говоря сомнительные на мой взгляд доводы. К тому же - релей вовсе не обязательно свитч с опцией 82. Ну да ладно - это не важно.
А при каких обстоятельствах еще может быть большой конфиг? Или Вы предлагаете вязать адрес к маку? Это идея точно сомнительная.

Что не все свичи умеют 82-юу это понятно....

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

Да еще... для случая релея перл/питон или еще что-то из области "изилёрниг" в общем-то не так плохо т.к. программка получается очень легкая, хотя я сам против использования этих языков для чего серьёзного.

Вобще конешно как знаете. Я лишь указал на то, что для большинства случаев использование DHCP (30 и 35 длинки на доступ - практически стандарт) можно существенно сократить функционал и как следствие упростить разработку.

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

Сообщение RomanCh »

Arti писал(а): А при каких обстоятельствах еще может быть большой конфиг? Или Вы предлагаете вязать адрес к маку? Это идея точно сомнительная.
Кому сомнительная, а кем применяется очень активно на практике и юзеры в восторге от локальных ресурсов за которыми не надо лазать в инет. ;-) Есть предложения как на постоянной динамике админить локальную сеть, раздавать быны неугодным, мониторить активность локальных ресурсов и т.д? Гнать всех через VPN грузя VPN сервера? Глупость, если можно этого избежать.
Arti писал(а): Вобще Вы слишком категоричны, особено если учесть что ничего еще не написано, как будет поддерживаться гипотетически созданная вами софтина тоже неизвестно.
Всё будет. Не спешите. Я же зашёл спросить "как лучше сделать" что бы изначально делать более-менее подходяще для большинства.
Arti писал(а): Я лишь указал на то что для большинства случаев использование DHCP ( 30 и 35 длинки на доступ - практически стандарт) можно существенно сократить функционал и как следствие упростить разработку.
Можно упростить. Но ИМХО если делать, так делать основательно. Что бы работало правильно а не "как проще получается"

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

Сообщение Arti »

RomanCh писал(а):
Arti писал(а): А при каких обстоятельствах еще может быть большой конфиг? Или Вы предлагаете вязать адрес к маку? Это идея точно сомнительная.
Кому сомнительная, а кем применяется очень активно на практике и юзеры в восторге от локальных ресурсов за которыми не надо лазать в инет. ;-) Есть предложения как на постоянной динамике админить локальную сеть, раздавать быны неугодным, мониторить активность локальных ресурсов и т.д? Гнать всех через VPN грузя VPN сервера? Глупость, если можно этого избежать.
Управлять доступом нужно на порту свича. Т.е. клиент однозначно идентифицируется парой айди свича (обычно ip адрес) порт свича.

Например баланс ушел в ноль - дальше "личного кабинета" пользователь не уйдет, даже к соседу в этом же доме ;).

Ответить