https://opennet.ru/openforum/vsluhforumID1/78303.html Доброго всем времени.<br><br>Хочу спросить совета в следующем: работает сервер доступа ВПН, которые бегает за авторизацией и прочими ААА к радиус-серверу, построенному на связке freeradius+mysql. Сейчас стоит необходимость в другом месте прикрутить еще один радиус-сервер, но вот указать ему БД нужно ту же самую, которую использует первый сервер. На эксперименты времени нет - связка стоит в продакшене. Не возникнет ли в данной схеме (когда два радиуса терзают одну БД) каких-нибудь проблем? Есть ли у кого практический опыт такой вязки?<br><br>ЗЫ: Уточню, что имелось ввиду не просто использование одной БД, а и использование тех же самых таблиц, под те же самые цели....<br> https://opennet.ru/openforum/vsluhforumID1/78303.html#5 Tue, 22 Jan 2008 12:25:50 GMT &gt;Эмсь. Ситуация вобщем-то какая - с радиусом (в итоге) будут работать 2-3 <br>&gt;NAS. В radacct есть еще поле AcctUniqueSessionId - неужели там нет <br>&gt;механизма разрула ситуации с его уникальностью? Не может же быть радиус <br>&gt;расчитан на 1 NAS. :-O <br><br> Радиус много разных насов обслужить может, но в одиночку, а вот как второй радиус будет <br>AcctUniqueSessionId делать, и не пересекутся ли они - вот в чем вопрос....<br><br> https://opennet.ru/openforum/vsluhforumID1/78303.html#4 Tue, 22 Jan 2008 11:58:29 GMT &gt;&gt;&gt; Для авторизации/аутентикации никаких, а вот с аккаунтингом возможны проблемы, <br>&gt;&gt;&gt;там лучше accounting в разные таблы разносить <br>&gt;&gt;<br>&gt;&gt;с одной БД. Я думаю, что выбор Unique AccountingID идет согласно <br>&gt;&gt;имеющимся в БД записям. Посему мне кажется, что вероятность генерации двух <br>&gt;&gt;одинаковых случайных значений обоими радиусами очень мала.... <br>&gt;<br>&gt; session-id не радиус генерит, а nas, поэтому возможно все, а решение <br>&gt;- заменить имя table <br>&gt;в sql.conf - всего и делов... <br><br>Эмсь. Ситуация вобщем-то какая - с радиусом (в итоге) будут работать 2-3 NAS. В radacct есть еще поле AcctUniqueSessionId - неужели там нет механизма разрула ситуации с его уникальностью? Не может же быть радиус расчитан на 1 NAS. :-O<br> https://opennet.ru/openforum/vsluhforumID1/78303.html#3 Tue, 22 Jan 2008 11:50:41 GMT &gt;&gt; Для авторизации/аутентикации никаких, а вот с аккаунтингом возможны проблемы, <br>&gt;&gt;там лучше accounting в разные таблы разносить <br>&gt;<br>&gt;с одной БД. Я думаю, что выбор Unique AccountingID идет согласно <br>&gt;имеющимся в БД записям. Посему мне кажется, что вероятность генерации двух <br>&gt;одинаковых случайных значений обоими радиусами очень мала.... <br><br> session-id не радиус генерит, а nas, поэтому возможно все, а решение - заменить имя table<br>в sql.conf - всего и делов...<br><br> https://opennet.ru/openforum/vsluhforumID1/78303.html#2 Fri, 18 Jan 2008 11:22:33 GMT &gt; Для авторизации/аутентикации никаких, а вот с аккаунтингом возможны проблемы, <br>&gt;там лучше accounting в разные таблы разносить <br><br>Именно этот момент меня и смущал. Но пока рассудил так - такая связка - мера временная. В ближайшее время радиус снова станет один с одной БД. Я думаю, что выбор Unique AccountingID идет согласно имеющимся в БД записям. Посему мне кажется, что вероятность генерации двух одинаковых случайных значений обоими радиусами очень мала....<br> https://opennet.ru/openforum/vsluhforumID1/78303.html#1 Fri, 18 Jan 2008 05:22:24 GMT &gt;Доброго всем времени. <br>&gt;<br>&gt;стоит необходимость в другом месте прикрутить еще один радиус-сервер, но вот <br>&gt;указать ему БД нужно ту же самую, которую использует первый сервер. <br>&gt;На эксперименты времени нет - связка стоит в продакшене. Не возникнет <br>&gt;ли в данной схеме (когда два радиуса терзают одну БД) каких-нибудь <br><br> Для авторизации/аутентикации никаких, а вот с аккаунтингом возможны проблемы,<br>там лучше accounting в разные таблы разносить<br><br>