Перейти к содержимому
Local
yKpon

stg+dhcpserver+mysql

Рекомендованные сообщения

http://www.netpatch.ru/dhcp2radius.html

 

вот нашёл что-то подобное, связка DHCP c базой MySQL

 

сейчас конфиг dhcp3server генерится скриптом, было бы замечательно если его собрать чтобы он работал с БД, а именно с базой STG

option82 не нужно, сетка чисто на мыльницах

 

если есть желающие может попробуем? :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня работает, но на файлах

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Есть DHCP-сервер на Perl, который работает исключительно с базой.

Поищите на http://forum.nag.ru/forum/index.php?showforum=4 , автор - Ivan_83.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

http://forum.nag.ru/forum/index.php?showtopic=64849 - во, нашёл.

Он довольно-таки пилябельный, за день можно дописать под себя.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А в чем проблема генерации конфига+перезапуска при нужных событиях, скриптом?

 

Дхцпд - не есть хайлод штуковина где нужно сильно заморачиваться. Могу поспорить что изменения в итоговом конфиге (смена мака/регистрация нового юзера) у вас проходят не ежесекундно и не требуют здоровых выборок из БД.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А в чем проблема генерации конфига+перезапуска при нужных событиях, скриптом?

Костыль.

Кроме того, есть проблема с "перетыкальщиками" (см. nag.ru).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

сейчас конфиг dhcp3server генерится скриптом, было бы замечательно если его собрать чтобы он работал с БД, а именно с базой STG

option82 не нужно, сетка чисто на мыльницах

 

если у Вас стг работает с майсклом - то что мешает настроить дхцп, шоб он брал данные из Ваших таблиц?!

на крайний случаей создать вьюхи или процедуры подстать структуре БД для дхцп

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Abram

Костыль

Обоснуйте (С)

 

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

 

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

 

 

Кроме того, есть проблема с "перетыкальщиками" (см. nag.ru).

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

 

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

 

 

Ork Yason

если у Вас стг работает с майсклом - то что мешает настроить дхцп, шоб он брал данные из Ваших таблиц?!

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если у Вас стг работает с майсклом - то что мешает настроить дхцп, шоб он брал данные из Ваших таблиц?!

на крайний случаей создать вьюхи или процедуры подстать структуре БД для дхцп

именно это и хочется сделать, чтобы dhcp брал все данные из базы MySQL, но разьве это можно сделать стандартными средствами сервера dhcp?

 

Abram, так может попробуем допилить этот скрипт для работы с базой стг?

 

А в чем проблема генерации конфига+перезапуска при нужных событиях, скриптом?

именно так оно сейчас и работает, но хочется что-то более правильного что ли :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

yKpon

именно так оно сейчас и работает, но хочется что-то более правильного что ли

Что есть сейчас: по пинку старгейзера перезаписывается конфиг isc-dhcpd(?)

Что вы хотите: заменить isc-dhcpd на неведомую перловую зверушку которая будет по пинку старгейзера внешним скриптом получать данные из базы.

 

Эммм, а что тут "более правильного" если не секрет?

 

 

Не, ну я могу предположить "мотивы" что выборки по БД быстрее проходят чем глупый парс по текстовым файлам с одной стороны, с другой - парс проходит только на рестарте dhcpd и занимает всего-то вот столько при 7к+ статических хостов:

# time /usr/local/etc/rc.d/isc-dhcpd restart
Stopping dhcpd.
Starting dhcpd.

real	0m0.056s
user	0m0.027s
sys	0m0.035s

 

В то же время банальный SELECT * FROM `таже табличка по которой собирается конфиг`, без какой либо постобработки длится около 0.15с.

 

И где практическая польза?

 

PS для желающих еще поизвращаться есть еще anemon, dhcpsql а также вариант на сторед процедурах.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Обоснуйте (С)

 

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

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

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

Нет.

 

Кроме того, есть проблема с "перетыкальщиками" (см. nag.ru).

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

 

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

Хочу быть Вашим конкурентом.

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

если у Вас стг работает с майсклом - то что мешает настроить дхцп, шоб он брал данные из Ваших таблиц?!

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

Не путайте ситуацию и проституцию. Никто не говорит о ужасах вроде LDAP или (упаси Боже!) RADIUS.

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

SELECT ip FROM users WHERE mac = '00:11:22:33:44:55';

Отдавать будет не за 0.15, а за 0.001 секунды. Конечно же, сие справедливо, если база правильно спроектирована/настроена (не забываем о индексах и HTREE - иначе полнотекстовый поиск унесет всё в ж#пу).

Насчет перловых зверушек: ВНЕЗАПНО, Perl - компилируемый язык. Не знали? :D

У меня dhcp-сервер в один поток свободно обслуживает клиентов одного города (до 1000 человек), не создавая при этом особой нагрузки на CPU/базу (это при том, что на каждый DHCP-запрос делается 2-3 запроса в базу, местами из 2-3 таблиц - просто я их правильно написал).

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

Если Вы считаете, что парсить БД и сохранять в конфиг - не костыльное решение... Что ж. Удачи. :lol:

Что вы хотите: заменить isc-dhcpd на неведомую перловую зверушку которая будет по пинку старгейзера внешним скриптом получать данные из базы.

У Вас какая-то фантазия извращенная. Какой нафиг пинок старгейзера, какой нафиг внешний скрипт? :D

Пришел запрос - глянули в базу - дали ответ.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Abram, так может попробуем допилить этот скрипт для работы с базой стг?

Увы, я не использую stg.

Поделиться сообщением


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

Тобишь по каждому DHCPDISCOVER делать минимум по 1 select?

 

Умно-умно, а главное как продуктивно.

sarcasm.jpg

 

 

Нет.

ну кто бы сомневался

 

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

да хоть кофе им в постель носите, главное не забеременнейте :lol:

 

Отдавать будет не за 0.15, а за 0.001 секунды. Конечно же, сие справедливо, если база правильно спроектирована/настроена (не забываем о индексах и HTREE - иначе полнотекстовый поиск унесет всё в ж#пу).

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

 

Насчет перловых зверушек: ВНЕЗАПНО, Perl - компилируемый язык. Не знали?

Что вы этим хотели сказать?

php тоже можно скомпилить/собрать с рантаймом и что?

 

У меня dhcp-сервер в один поток свободно обслуживает клиентов одного города (до 1000 человек),

 

# cat /var/log/dhcpd.log | grep "Jul 28" | grep OFFER | wc -l
1830933

 

ну с того и начинайте что мы говорим о чуток разных уровнях

 

 

не создавая при этом особой нагрузки на CPU/базу

это достижение да? :lol:

 

# ps aux | grep dhcpd
dhcpd    19035  0.0  0.1  2948  2548  ??  Ss    4:16PM   0:00.07 /usr/local/sbin/dhcpd

 

он как-бы и не должен создавать нагрузки бай дефолт

 

это при том, что на каждый DHCP-запрос делается 2-3 запроса в базу, местами из 2-3 таблиц - просто я их правильно написал

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

 

Если Вы считаете, что парсить БД и сохранять в конфиг - не костыльное решение... Что ж. Удачи.

она всегда со мной

 

 

ЗЫ Хотя не могу не согласиться - если самоцель заняться жарким сексом с табуреткой вместо работы, то написание своих дхцп серверов на перлах, своих хттпд серверов на похапе и своих сендмейлов на пасквиле является хорошим решением.

Поделиться сообщением


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

Тобишь по каждому DHCPDISCOVER делать минимум по 1 select?

 

Умно-умно, а главное как продуктивно.

А Вы не смотрели, сколько SELECT-ов делает Ваш биллинг? :lol:

Повторюсь: правильные SELECT-ы с правильной структурой БД выполняются быстро и базу не грузят.

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

да хоть кофе им в постель носите, главное не забеременнейте :lol:

Я уловил, да.

 

sarcasm.jpg

 

У меня dhcp-сервер в один поток свободно обслуживает клиентов одного города (до 1000 человек),

 

# cat /var/log/dhcpd.log | grep "Jul 28" | grep OFFER | wc -l
1830933

 

ну с того и начинайте что мы говорим о чуток разных уровнях

Я тоже могу включить логгирование в isc-dhcpd (да, он у меня тоже есть - один город на нем, второй на своей "перловой зверушке") и посчитать кол-во выданных OFFER-ов.

Но у нас же тут вроде как была более-менее конструктивная беседа, а не мерянье пиписьками?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ёпт, пост не умещается, пришлось разбить.

не создавая при этом особой нагрузки на CPU/базу

это достижение да? :lol:

Это контр-аргумент на Ваши выпады о кол-ве SELECT-ов.

 

это при том, что на каждый DHCP-запрос делается 2-3 запроса в базу, местами из 2-3 таблиц - просто я их правильно написал

а джойны, нормализацию табличек и сторед процедуры так и не осилили.... пичаль-пичаль...

Я рад, что Вы владеете таким количеством умных слов :lol:.

Осилил, не бойтесь.

ЗЫ Хотя не могу не согласиться - если самоцель заняться жарким сексом с табуреткой вместо работы, то написание своих дхцп серверов на перлах, своих хттпд серверов на похапе и своих сендмейлов на пасквиле является хорошим решением.

Забыли биллинги на жабе (не, не у меня - я вообще).

 

P.S.:

trollercoaster-2.jpg

 

И вообще, предлагаю продолжить беседу на УКОСе, с пивом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
А Вы не смотрели, сколько SELECT-ов делает Ваш биллинг?

На перестройку конфига dhcpd? Ровно один в текущей версии. А что?

 

Но у нас же тут вроде как была более-менее конструктивная беседа, а не мерянье пиписьками?

конечно же, как вы могли предположить обратное?

 

sarcasm.jpg

 

Осилил, не бойтесь.

не боюсь.

 

 

Забыли биллинги на жабе (не, не у меня - я вообще).

они то причем к дхцп и старгейзеру? (см сабж)

 

И вообще, предлагаю продолжить беседу на УКОСе, с пивом.

пиво это хорошо, укос неожиданно накладывается на покатушки к более северным курортам, httpd на похапе - изврат.

 

 

feedme.jpg

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
А Вы не смотрели, сколько SELECT-ов делает Ваш биллинг?

На перестройку конфига dhcpd? Ровно один в текущей версии. А что?

Я не о конфиге dhpcd, а о биллинге вообще. Мысль в том, что запросы от dhcp на фоне запросов биллинга просто не будут заметны.

конечно же, как вы могли предположить обратное?

 

sarcasm.jpg

 

Спасибо :lol:. Поржал.

 

Забыли биллинги на жабе (не, не у меня - я вообще).

они то причем к дхцп и старгейзеру? (см сабж)

 

И вообще, предлагаю продолжить беседу на УКОСе, с пивом.

пиво это хорошо, укос неожиданно накладывается на покатушки к более северным курортам, httpd на похапе - изврат.

Биллинге на жабе здесь при том же, при чем и httpd на пыхпыхе. :lol:

4411674751_834d357f62_o.jpg

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Мысль в том, что запросы от dhcp на фоне запросов биллинга просто не будут заметны.

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

 

stato.png

Ну хотя соглашусь - намного ведь интерестней хотябы раз в минуту пинать базу, посмотреть "а не изменилось ли чего?", правда? :lol:

 

 

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

 

ЗЫ у старгейзера кстати изкайобки есть очень удобный механизм узнавания "не изменилось ли чего у юзера?" ликвидирующий надобность постоянно и как-то внешне мониторить текущее состояние БД. Механику проще и надежнее найти сложно: "что-то изменилось -> пнули дхцпд -> забыли".

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Я о кешировании внутри MySQL.

 

Ладно. На вкус и цвет все фломастеры разные.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Ладно. На вкус и цвет все фломастеры разные.

moon.jpg

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Ладно. На вкус и цвет все фломастеры разные.

moon.jpg

trollface.jpg?

Я вообще-то о том, что спорить можно долго. И бессмысленно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
trollface.jpg?

нивкоем случае, как вы могли такое подумать? :lol:

 

 

 

Я вообще-то о том, что спорить можно долго. И бессмысленно.

ну зато весело

 

yeah.jpg

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Abram, так может попробуем допилить этот скрипт для работы с базой стг?

Увы, я не использую stg.

а dhcp используете? рабоатет с базой?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поделюсь своим опытом. В прошлом году, когда я еще работал в провайдере, начальство озадачило наш отдел переводом всей сети (порядка 10к живых абонов) на DHCP + Opton82. Естественно, сразу встала задача подружить как-то DHCP с БД. Рассматривальись 3 варианта: ISC DHCPd, FreeRADIUS и OpenDHCP.

ICH DHCPd. С БД не работает принципиально и все просьбы к разработчикам остаются без ответа.

FreeRAIDUS. Странная зверушка. Вроде как RADIUS-сервер, но разработчики по неведомому нам желанию их левой пятки прикрутили к нему DHCP (правда, честно написали, что оно экспериментальное и претензии они не принимают). В общем, неведома зверушка.

OpenDHCP. Странная штука. Вроде бы супер крутая хрень, написанная на C++, которая все умеет только не летает.

 

Сперва товарищи решили позаморачиваться с FreeRADIUS. Оно у них даже заработало, но без Option82. Я вообще с подозрением отношусь ко всяким "комбайнам", тем более с пометкой "experimental" и негативной рекомендацией от самих разработчиков. По этому сам решил копать в сторону OpenDHCP. Собрал, установил. Что дальше? Документации нет. Полез в исходники - там комментарии на трех языках как минимум, и ни один из них не английский. Исходников туча, с ходу не разберешься. Построил ERD базы по ихним скриптам - получил что-то вроде 50 таблиц. Тоже ничего не понятно. В общем, бросил я эту затею и вернулся к ISC DHCPd.

 

Он, вроде как, умеет работать с LDAP, но уж очень не хотелось вводить промежуточное звено. По этому остановился на таком решении: строим файл лизов по базе, в реальном времени его синхронизируем по OMAPI и на всякий пожарный ежедневно, в 4 утра (минимум нагрузки от абонов) перегенериваем файл лизов (/var/lib/dhcp/dhcpd.leases, у него простенький формат). Что и было реализовано с двумя патчами. Один патч - адаптация старых патчей для поддержки subclassing в новых версиях сервера, а второй - обеспечение доступа к информации Option82 из OMAPI. OMAPI - это такой протокол, который поддерживают, по идее, все ISC'шные продукты. Он старый, кривой и они постоянно грозятся его выкинуть, но он работает. И даже есть биндинги к Perl.

 

Вот такая связка работает отличненько уже год и не требует никакого вмешательства. Нагрузки не создает, крутится в виртуалке, исправно предоставляет данные о том в какой порт какого свитча включен абонент (небольшая настройка rsyslog и вуаля - данные о лизах сливаются в базу прямо в нужно нам виде!). В процессе адаптации патча для subclassing и написания патча для поддержки аттрибутов Option82 в OMAPI я немного разобрался в том как работает этот демон. Написано все в духе старого-доброго C, писалось явно много лет и разными людьми, по этому внутри велосипеды пачками. Но все организовано достаточно логично и просто.

 

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

 

Да, после того как все было сделано и стабилизировано возникло дикое желание самому написать DHCP-сервер, но я его успешно подавил. Ибо нефиг очередной велосипед ваять. Тем более оно только с первого взгляда кажется простым, на самом деле везде есть свои подводные камни (много читал в коде комментариев про особенности работы с DHCP у Microsoft'овских ОС).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

К стати о птичках. Т.е. "перетыкальщиках". Это типа те кто втыкает кабель то в ноут то в комп и проблема в смене MAC? Проблема решена технически.

С помощью классификации неизвестные абоны (неизвестные MAC'и) получают адреса и настройки из отдельного пула и при попытке вылезти куда-то в инет попадают на страницу активации оборудования, где им вежливо предлагают ввести свой логин и пароль. Если логин и пароль правильные - MAC попадает в файл лиз и абон, переполучив адрес, продолжает работать. Те кого это не устраивает - покупают роутеры. Ибо нефиг.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.

×