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

Исходное сообщение
"Два радиуса VS одна БД"
Отправлено shulik , 17-Янв-08 22:20

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

Содержание

Два радиуса VS одна БД,YuryD, 08:22 , 18-Янв-08
- Два радиуса VS одна БД,shulik, 14:22 , 18-Янв-08
  - Два радиуса VS одна БД,YuryD, 14:50 , 22-Янв-08
    - Два радиуса VS одна БД,shulik, 14:58 , 22-Янв-08
      - Два радиуса VS одна БД,YuryD, 15:25 , 22-Янв-08

Сообщения в этом обсуждении

"Два радиуса 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 делать, и не пересекутся ли они - вот в чем вопрос....