Доброго времени всем.
И так, к делу. Есть у меня желание написать кроссплатформенный DHCP сервер изначально ориентированный на работу с различными SQL СУБД. На сколько я понимаю - подобный софт будет очень востребованным в провайдерской деятельности.
Имеются следующие вопросы к всем заинтересованным лицам:
1. Есть-ли смысл привязываться к какой-то конкретной структуре БД (определённым таблицам, представлениям, полям в них и т.д) или структура БД не принципиальна?
2. По каким принципам идентифицировать DHCP клиентов? Мне видится актуальным: по MAC адресу, option-82. Возможно что-то ещё?
Интересно будет услышать пожелания и предложения по данной теме.
PS Решения вида http://www.netpatch.ru/dhcp2radius.html (моё решение) - в расчёт не берутся ибо являются костылём по своей сути. Кроме того - очень не хочется как-либо связываться с кодом от ISC в силу его страшной неуклюжести.
Удобность работы с DHCP через FreeRADIUS ИМХО не слишком очевидна и выглядит несколько костылеобразно.
Напишу полноценный DHCP сервер работающий с SQL СУБД.
Предлагаю на досуге ознакомиться с исходниками от ISC. Лучше всего их использовать в качестве примера "как не надо писать код".amix писал(а):Имхо если делать чтото подобное, то только в виде патча к isc
идеально было бы увидеть чтонить типа bind+dlz
Благодаря этой особенности в них куча багов, которые каждый дистрибьютор ОС патчит по своему. FreeBSD по своему, Gentoo по своему, Debian по своему и т.д... В итоге патч применять становится крайне затруднительно. Где-то он работает, где-то нет.
Например изначально разработчиками ISC задумывалось что dhcpd не должен уметь слушать loopback интерфейс, но он умеет слушать, потому в сорцах без патчей от сторонних дистрибьютеров есть возможность запустить dhcpd & freeradius на одном и том же хосте. Но например в FreeBSD пропатчили эту багу, и если брать сорцы из портов - на одном хосте без жуткого шаманизма запустить не получается. Или "это не баг, это фича!"?
Да и вообще - какой смысл прилепливать "сбоку припёку" к проекту который изначально на это не расчитан? По факту - тот патч из ISC DHCP использует только функцию получения запроса, чтения конфига и отправки ответа. Всё остальное - написано мною включая логику ответов DHCP. Ибо сделать так проще, быстрее и даже правильней, чем пытаться понять что имели ввиду девелоперы ISC пишущие функции по 600 строчек в одной, рекурсивно вызывающие друг друга...
Что-то не вижу собой связи между mysql и релеем.Arti писал(а):Зачем нужен полноценный?
Если конфиг хранится в mysql, то скорей всего работает релей + 82
Ну так ни кто и не говорит что программа архисложная. Она вообще относительно простая в любом случае. Просто почему-то ни кто не реализует ничего нормального до сих пор. В основном пользуются различными костылями.Arti писал(а): опция, а это юникаст. Программа становится очень простой...
Пример пожалуйста. Адекватный, поддерживаемый, написанный не на питоне.Arti писал(а):В сети есть уже готовые реализации.
Самая прямая. Если используется БД - значит кофиг большой и/или содержит условия выдачи адресов. Стандартный вариат сообщить дополнительные данные о клиенте - 82 опция. Как правило 82 опция заполняется коммутатором именно при релее.RomanCh писал(а): Что-то не вижу собой связи между mysql и релеем.
В общем если все можно описать парой десятков строк - не вижу недостатков в версии от isc
.Был где-то готовый сервачёк. Точно не вспомню название точно... SСND или еще как... Врядли автор его поддерживает. там радиус/snmp/dhcp в одном флаконе. DHCP там был кстати реализован именно для работы с релеем.
Ну также не факт что Вы будете поддерживать свой продукт
.P.S.
Нашел я страничку SCND
http://www.chics.ru/~daniil/scnd/doc/
http://sourceforge.net/projects/opendhcp/ этот посмотрите...RomanCh писал(а): Адекватный, поддерживаемый, написанный не на питоне.
http://downloads.sourceforge.net/projec ... 0.1.tar.gzChris писал(а):The "opendhcp/v1.0.0/opendhcp-1.0.0.tar.gz" file could not be found or is not available. Please select another file.
Честно говоря сомнительные на мой взгляд доводы. К тому же - релей вовсе не обязательно свитч с опцией 82. Ну да ладно - это не важно.Arti писал(а): Самая прямая. Если используется БД - значит кофиг большой и/или содержит условия выдачи адресов. Стандартный вариат сообщить дополнительные данные о клиенте - 82 опция. Как правило 82 опция заполняется коммутатором именно при релее.
Я выше указал недостатки.Arti писал(а): В общем если все можно описать парой десятков строк - не вижу недостатков в версии от isc
А на кой он тогда нужен? Самому если что дописывать? Спасибо, я уже наупражнялсяArti писал(а): Врядли автор его поддерживает.
Испытываю органическое отвращение к подобным "кухонным комбайнам". Это не более чем моё ИМХО конечно. Хотя - не только моё.Arti писал(а): там радиус/snmp/dhcp в одном флаконе.
А я его изначально постараюсь написать так что бы при желании можно было поддерживать кому угодно без сверх трудозатрат. И кроме того постараюсь добиться включения в популярные дистрибутивы. Не будет желания/времени поддерживать самому - отдам на поддержание коммунити. Желающие поддерживать наверняка найдутся. Было бы что поддерживать.Arti писал(а): Ну также не факт что Вы будете поддерживать свой продукт
Ага, посмотрел. Стиль примерно тот же что у ISC, только круче. Открыл файл dhcp.c, наблюдаю в нём функцию dhcp() без малого на 700 строчек. С кучей строк имеющих "магические числа" внутри, типа:
Код: Выделить всё
for( n=0, err_f=0; n<sizeof(buf) - 240 ; n += option->leng +2)Уже "впечатляет". Не удивительно что ни кем не поддерживается.
Далее:
Ай, ай. У меня даже не собрался. Вникать почему так - нет особого желания, коли автор не позаботился о нормальном конфигураторе который скажет что не так.ОС FreeBSD, (под Linux собирается, но не тестировался)
Тоже как-то стрёмновато выглядит. Вам не кажется?При установки SCND в среде FreeBSD все вышеперечисленные пакеты устанавливаются из портов, кроме библиотек xmlrpc-c. К сожалению, порт xmlrpc-c давно не обновлялся, и этот пакет придется установить вручную, скачав исходный код с сайта http://xmlrpc-c.sourceforge.net/.
Это уже НЕ DHCP сервер, а что-то такое недоделанное. Как в общем и ожидалось от "кухонного комбайна". Далее обсуждать смысла не вижу.DHCP сервер обрабатывает пакеты с сообщениями, прошедшие через маршрутизатор с функцией DHCP Relay. DHCP сервер не может непосредственно обслуживать напрямую подключенную сеть, так как работает только с юникастовыми пакетами.
max1976 - посмотрел. Поддерживает только PostgreSQL. Согласен - БД хорошая, сам обычно её юзаю. Но... Что использует большинство? Я думаю Вы знаете.
Опять же - у меня на Gentoo даже не собралось. Почему? Потому что автор взялся писать на С++ по стандартам 95го года (примерно) или вобоще без стандартов.
Уж не знаю в чём он его собирал что собралось... Касательно обоих предложений - ИМХО то что они не включены ни в один популярный диструбутив крайне подозрительно. Не зря же так случается.
ПИЛЯТЬ... САМ ТО ЗАХОДИЛ ТУДА? ПИШЕТ The "opendhcp/v1.0.1/opendhcp-1.0.1.tar.gz" file could not be found or is not available. Please select another file.max1976 писал(а):http://downloads.sourceforge.net/projec ... 0.1.tar.gzChris писал(а):The "opendhcp/v1.0.0/opendhcp-1.0.0.tar.gz" file could not be found or is not available. Please select another file.
А при каких обстоятельствах еще может быть большой конфиг? Или Вы предлагаете вязать адрес к маку? Это идея точно сомнительная.RomanCh писал(а): Честно говоря сомнительные на мой взгляд доводы. К тому же - релей вовсе не обязательно свитч с опцией 82. Ну да ладно - это не важно.
Что не все свичи умеют 82-юу это понятно....
Вобще Вы слишком категоричны, особено если учесть что ничего еще не написано, как будет поддерживаться гипотетически созданная вами софтина тоже неизвестно.
Да еще... для случая релея перл/питон или еще что-то из области "изилёрниг" в общем-то не так плохо т.к. программка получается очень легкая, хотя я сам против использования этих языков для чего серьёзного.
Вобще конешно как знаете. Я лишь указал на то, что для большинства случаев использование DHCP (30 и 35 длинки на доступ - практически стандарт) можно существенно сократить функционал и как следствие упростить разработку.
Кому сомнительная, а кем применяется очень активно на практике и юзеры в восторге от локальных ресурсов за которыми не надо лазать в инет.Arti писал(а): А при каких обстоятельствах еще может быть большой конфиг? Или Вы предлагаете вязать адрес к маку? Это идея точно сомнительная.
Есть предложения как на постоянной динамике админить локальную сеть, раздавать быны неугодным, мониторить активность локальных ресурсов и т.д? Гнать всех через VPN грузя VPN сервера? Глупость, если можно этого избежать.Всё будет. Не спешите. Я же зашёл спросить "как лучше сделать" что бы изначально делать более-менее подходяще для большинства.Arti писал(а): Вобще Вы слишком категоричны, особено если учесть что ничего еще не написано, как будет поддерживаться гипотетически созданная вами софтина тоже неизвестно.
Можно упростить. Но ИМХО если делать, так делать основательно. Что бы работало правильно а не "как проще получается"Arti писал(а): Я лишь указал на то что для большинства случаев использование DHCP ( 30 и 35 длинки на доступ - практически стандарт) можно существенно сократить функционал и как следствие упростить разработку.
Управлять доступом нужно на порту свича. Т.е. клиент однозначно идентифицируется парой айди свича (обычно ip адрес) порт свича.RomanCh писал(а):Кому сомнительная, а кем применяется очень активно на практике и юзеры в восторге от локальных ресурсов за которыми не надо лазать в инет.Arti писал(а): А при каких обстоятельствах еще может быть большой конфиг? Или Вы предлагаете вязать адрес к маку? Это идея точно сомнительная.
Например баланс ушел в ноль - дальше "личного кабинета" пользователь не уйдет, даже к соседу в этом же доме
.