GNU Radius 1.0 released

а кто-нить может объяснмть нормально зачем он нужен-то?

short answer: для аутентификации.

A kak u nego naschet web interface ? Est u kogo opyt? 10x :) uspeh

это-то то я и сам догадался %) а где он нужен-то?

на ISP

>это-то то я и сам догадался %) а где он нужен-то?
authorization, autentication, accaunting
дальше объяснять?

с freeradius кто-нибуть сравнить может ?

Круче freeradius могут быть только горы... :)) Особенно если к нему биллинг (например, FreeNIBS ;) прикрутить :)...

Я честно, не вкуриваю, кому это чудо-юдо нужно? На сколько я понял, фич в нем никаких нет. Кому нужен обычный RADIUS, без поддержки RDBMS тот юзает какой-нибудь cistron.

FreeRadius - тоже еще тот уродец. Его лепит явно какое-то безконтрольное стадо. Послали туда рабочий патч - через неделю наш патч полностью переписали и закомитили. Но он перестал работать :) Работа с ORACLE как там сделана - это полный пи@#ец. Модули rlm_python и rlm_perl - мля, это ваще шедевр. Все херачится в один тред и там крутится... Пипец, акаунтинг с 10 девайсов в одну дырку, нах.

Вобщем, мы уже чуть было не начали писать свой радиус с нуля. Но, к счастью нашли OpenRadius (www.openradius.net). Всем заинтересованым очень рекомендую - это просто супер! Настоящий UNIX-way. Немного своеобразный формат конфига, но разобраться можно. Есть дока.

а билингуете чем ?

А мне понравился xtradius, к нему прикручивается все что угодно.

qwe

Согласен! FreeRadius разрабатывает неконтролируемое стадо! Убивает то, что в raddb/postgresql.conf была ошибка, причем конкретная, послал патч 27 января - не заметили, потом еще раз 5 посылал в список рассылки, Alan De Kok и Peter Nixon - последний сказал чтьо посмотри и опять забыл. Следующее письмо осталось без ответа. И только в эту пятницу эта ошибка была исправлена! А она выеденного яйца не стоила и была очень проста!

И еще. Видя то, каким образом люди на C пишут код - мне страшно становится! Не порверятся длина строк, Переполнение буфера на раз плюнуть сделать! Ужас.

А то как сделали /src/billing и в нее вложили сразу же биллинг для h323... Это отдельная песня Короче .... Не знаешь на чем и работать

2 coxx

OpenRADIUS module that queries any DBI/DBD-supported database!!! DBI/DBD это просто смешно.

По крайней мере если сравнивать с sql движком Freeradius. Попробуй на DBI/DBD собирать ~540 alive пакетов в минуту.

> Попробуй на DBI/DBD собирать ~540 alive пакетов в минуту.

А в чем проблема?

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

А зачем с нуля?
Можно например выделить auth и acct в модули в обычном
radiusd-cistron и потом менять только их.

Вы не представляете, насколько легко самому написать RADIUS-сервер вместе с биллингом.

* modularity is based on pipes and processes, not on libraries or a hybrid for of a library and a process such as some DLL designs;

* concurrency is achieved by offloading work to multiple other processes, not by multithreading within the same process.

А plugin будет процессом, а radsql написан на perl-е - вот тут тормоза DBI/DBD и выползут. К тому же там db schema фиксированая и на каждый чих надо переписывать radsql.

Вот в нашем билинге все свелось к select * from rad_check(username,password,..etc) и rad_reply аналогично. Это все в freeradius+postgresql и изменить-то пришлось несколько строк в конфигах freeradius-а...

> OpenRADIUS module that queries any DBI/DBD-supported database!!!

> DBI/DBD это просто смешно.

Ты не фкурил. Это туфта написана для примера чисто. Если DBI/DBD будет тормозить - будет C-шный модуль.

На самом деле можно использовать все что угодно, хоть shell-скрипт, хоть (faster than hell) С-программу которая будет работать с БД через нативный C'шный API. Фишка в том, что ядро радиус-сервера запускает N child процессов, и работает с ними через пайпы. (a-la Fast-CGI). Child-процессы один раз коннектятся к БД, короче, думаю дальше все понятно.

> По крайней мере если сравнивать с sql движком Freeradius. Попробуй на

> DBI/DBD собирать ~540 alive пакетов в минуту.

Блин, sql-движок для FreeRadius сделан с расчетом MySQL. Ну нельзя с ORACLE работать, как с MySQL. Все начинает тормозить страшно уже на 10 пакетах в секунду.

to cold (*) (2003-06-30 20:12:39.508793)

>К тому же там db schema фиксированая и на каждый чих надо переписывать radsql.

Не вводи народ в заблужение! Ты недочитал доку и недоразобрался.

"db schema" для openradius'а там может быть любая, ее может ваще не быть. Openradius - это просто ядро, обеспечивающее сетевую поддержку radius-пакетов.

Типа, как inetd (xinetd), только дочерние процессы стартуют один раз, при запуске (экономим на fork'ах и старте жирных интерпретаторов).

> Openradius - это просто ядро, обеспечивающее сетевую поддержку radius-пакетов. и кому нужно "просто ядро"? ты то будешь юзать это ядро + нужный backend для текущего radsql схема фиксирована, он написан та perl-е и значит еще и медленный

и вообще есть большой вопрос: что хорошее в такой архитектуре radius сервера?

так нельзя сделать нормальное разделение функций модулей, к примеру: в freeradius-е на этапе авторизации модуль sql вытягивает из базы пароль юзера (или ldap модуль или еще хрен знает что), на этапе аутентификации модуль chap или pap или ms-chap/v2 или eap сравнивает настоящий пароль с предоставленым...

нифига не понял ни про OpenRADIUS ни про FreeRADIUS. Вот использую уже много лет на production-серверах xtradius. Его даже помогал доводить до ума разработчику. Там все просто - на start-пакет запускается start-скрипт с параметрами, который отдаются в коммандную сторку RADIUS'ом. Тоже со stop'ами,keepalive-пакетами и прочими типами запросов к серверу (их совсем немного - 3-мя-4мя прогаммами можно запросто ВСЕ забиллить, я вот h323 биллю уже несколько лет без проблем). А вот что такого наворотили в OpenRADIUS'е и FreeRADIUS'е? какое взаимодейстийствие с базой а-ля fastCGI? какой CGI ра RADIUS'е? зачем RADIUS'у "знать" по SQL-сервер? поясните, люди добрые, кто знает - просвятите pls!

2 mazay (*) (2003-07-01 02:01:26.874115) > Вот использую уже много лет на production-серверах xtradius

Я как бы тоже юзал его, причем тоже без патчей не обошлось.

Но, есть одно НО. Не надо забывать, что xtradius делает exec. А каждый exec - это новый процесс, новый коннект к БД. Или вы voip биллите без БД ? :))) Не, конечно MySQL'у может и пофиг на коннекты, особеено если заюзать --skip-grant-tables и такая конфигурация (xtradius+application+MySQL) у меня работает. Но это не для высокой нагрузки.

Собрал, попробовал. Работает, на первый взляд, вполне прилично.

qwe

>Но это не для высокой нагрузки. извини, что что в твоем понимании "высокая нагрузка"? Вот у меня успешно работало без потерь биллингом звонков при нагруженных voip 2-х потоках E1, причем скорость нарастания звонков в часы пик была в районе 5...8 звонков в секунду (5...8 новых подключений к базе в секунду), mysqladmin выдал сейчас статистику Queries per second avg: 1.826 Если имеется в виду обслуживание одним RADIUS'ом сотен NAS'ов/потоков, боюсь, прийдется действительно столкнуться с трудностями в эксплуатации такого решения, но для большинства случаев (думаю, до 10 E1 точно) его вполне достаточно, без взяких костылей типа --skip-grant-tables. К тому же, если ты говоришь о технологии CGI, то там тоже используется тот же принцип, что и в xtradius - а именно передача значений через командную строку.

Кстати, в xtradius можно не использовать командную строку. Он инициирует переменные окружения соответствующие A/V парам.

qwe

2 mazay (*) (2003-07-01 14:31:07.232881) > извини, что что в твоем понимании "высокая нагрузка"? > Вот у меня успешно работало без потерь биллингом звонков при > нагруженных voip 2-х потоках E1, причем скорость нарастания звонков > в часы пик была в районе 5...8 звонков в секунду (5...8 новых > подключений к базе в секунду)

Дык, пардон, Оракл не поймет 5-8 новых подключений в секунду. Поэтому и получается - либо простая структура данных + MySQL и хоть сто коннектов в секунду, либо сложная структура + ORACLE + пул постоянных коннектов.