stg+dhcpserver+mysql

[yKpon]

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

 

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

 

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

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

 

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

[DarkSpider]

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

[Abram]

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

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

[Abram]

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

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

[nightfly]

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

 

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

[Abram]

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

Костыль.

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

[Ork Yason]

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

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

 

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

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

[nightfly]

Abram

Костыль

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

 

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

 

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

 

 

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

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

 

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

 

 

Ork Yason

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

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

[yKpon]

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

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

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

 

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

 

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

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

[nightfly]

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 а также вариант на сторед процедурах.

[Abram]

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

 

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

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

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

Нет.

 

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

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

 

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

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

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

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

Ничего не мешает, просто людям иногда очень хочется тянуть за собой если не 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 - компилируемый язык. Не знали?

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

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

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

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

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

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

[Abram]

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

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

[nightfly]

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

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

 

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

 

 

Нет.

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

 

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

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

 

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

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

 

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

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

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

 

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

 

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

 

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

 

 

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

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

 

# 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 таблиц - просто я их правильно написал

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

 

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

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

 

 

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

[Abram]

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

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

 

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

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

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

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

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

Я уловил, да.

 

 

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

 

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

 

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

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

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

[Abram]

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

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

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

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

 

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

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

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

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

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

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

 

P.S.:

 

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

[nightfly]

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

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

 

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

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

 

 

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

не боюсь.

 

 

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

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

 

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

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

 

 

[Abram]

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

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

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

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

 

 

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

 

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

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

 

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

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

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

[nightfly]

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

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

 

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

 

 

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

 

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

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

[Abram]

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

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

 

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

[nightfly]

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

[Abram]

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

trollface.jpg?

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

[nightfly]

trollface.jpg?

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

 

 

 

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

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

 

[yKpon]

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

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

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

[madf]

Поделюсь своим опытом. В прошлом году, когда я еще работал в провайдере, начальство озадачило наш отдел переводом всей сети (порядка 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'овских ОС).

[madf]

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

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