URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 78303
[ Назад ]

Исходное сообщение
"Два радиуса VS одна БД"

Отправлено shulik , 17-Янв-08 22:20 
Доброго всем времени.

Хочу спросить совета в следующем: работает сервер доступа ВПН, которые бегает за авторизацией и прочими ААА к радиус-серверу, построенному на связке freeradius+mysql. Сейчас стоит необходимость в другом месте прикрутить еще один радиус-сервер, но вот указать ему БД нужно ту же самую, которую использует первый сервер. На эксперименты времени нет - связка стоит в продакшене. Не возникнет ли в данной схеме (когда два радиуса терзают одну БД) каких-нибудь проблем? Есть ли у кого практический опыт такой вязки?

ЗЫ: Уточню, что имелось ввиду не просто использование одной БД, а и использование тех же самых таблиц, под те же самые цели....


Содержание

Сообщения в этом обсуждении
"Два радиуса VS одна БД"
Отправлено YuryD , 18-Янв-08 08:22 
>Доброго всем времени.
>
>стоит необходимость в другом месте прикрутить еще один радиус-сервер, но вот
>указать ему БД нужно ту же самую, которую использует первый сервер.
>На эксперименты времени нет - связка стоит в продакшене. Не возникнет
>ли в данной схеме (когда два радиуса терзают одну БД) каких-нибудь

Для авторизации/аутентикации никаких, а вот с аккаунтингом возможны проблемы,
там лучше accounting в разные таблы разносить


"Два радиуса VS одна БД"
Отправлено shulik , 18-Янв-08 14:22 
> Для авторизации/аутентикации никаких, а вот с аккаунтингом возможны проблемы,
>там лучше accounting в разные таблы разносить

Именно этот момент меня и смущал. Но пока рассудил так - такая связка - мера временная. В ближайшее время радиус снова станет один с одной БД. Я думаю, что выбор Unique AccountingID идет согласно имеющимся в БД записям. Посему мне кажется, что вероятность генерации двух одинаковых случайных значений обоими радиусами очень мала....


"Два радиуса VS одна БД"
Отправлено YuryD , 22-Янв-08 14:50 
>> Для авторизации/аутентикации никаких, а вот с аккаунтингом возможны проблемы,
>>там лучше accounting в разные таблы разносить
>
>с одной БД. Я думаю, что выбор Unique AccountingID идет согласно
>имеющимся в БД записям. Посему мне кажется, что вероятность генерации двух
>одинаковых случайных значений обоими радиусами очень мала....

session-id не радиус генерит, а nas, поэтому возможно все, а решение - заменить имя table
в sql.conf - всего и делов...


"Два радиуса VS одна БД"
Отправлено shulik , 22-Янв-08 14:58 
>>> Для авторизации/аутентикации никаких, а вот с аккаунтингом возможны проблемы,
>>>там лучше accounting в разные таблы разносить
>>
>>с одной БД. Я думаю, что выбор Unique AccountingID идет согласно
>>имеющимся в БД записям. Посему мне кажется, что вероятность генерации двух
>>одинаковых случайных значений обоими радиусами очень мала....
>
> session-id не радиус генерит, а nas, поэтому возможно все, а решение
>- заменить имя table
>в sql.conf - всего и делов...

Эмсь. Ситуация вобщем-то какая - с радиусом (в итоге) будут работать 2-3 NAS. В radacct есть еще поле AcctUniqueSessionId - неужели там нет механизма разрула ситуации с его уникальностью? Не может же быть радиус расчитан на 1 NAS. :-O


"Два радиуса VS одна БД"
Отправлено YuryD , 22-Янв-08 15:25 
>Эмсь. Ситуация вобщем-то какая - с радиусом (в итоге) будут работать 2-3
>NAS. В radacct есть еще поле AcctUniqueSessionId - неужели там нет
>механизма разрула ситуации с его уникальностью? Не может же быть радиус
>расчитан на 1 NAS. :-O

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