[Deac]

Добавить аливы, раз в 5 минут не будет напряжно.

[roysbike]

Добавить аливы, раз в 5 минут не будет напряжно.

в MPD5? или где ?

[Deac]

В MPD конечно же.

	set auth acct-update 180

Это для 3-х минут.

Изменено 11 января, 2012 пользователем Deac

[Alex/AT]

Дык, допилить.

=юзать CURL, с вышеуказанным результатом.

Не обязательно CURL. Я юзаю связку RP-PPPoE+свой ISG/SSG+FreeRADIUS+скрипты, опрашиваю CoA-пакетами. + допиленный checkrad. Шустро и ненавязчиво.

Изменено 11 января, 2012 пользователем Alex/AT

[Deac]

Не обязательно CURL. Я юзаю связку RP-PPPoE+свой ISG/SSG+FreeRADIUS+скрипты, опрашиваю CoA-пакетами. + допиленный checkrad. Шустро и ненавязчиво.

Где тут MPD?

Я юзаю MPD с аливами и ничего опрашивать не приходится.

[Alex/AT]

Ну, как знаете. Что с MPD/*BSD, что с RP-PPPoE на Linux, опрос живости сессии делается сходным образом.

То, о чём вы говорите, в терминологии RADIUS называется не "keepalive", а "interim accounting", использовать для ловли сессий можно, но это костыль.

Который, к тому же, в условиях большого числа юзеров потребует осторожности в реализации.

Но это уже лирика. Тут всё зависит от желания "построить _систему_" или "на скорую руку позатыкать дыры".

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

P.S. Это просто взгляд на вещи, ничего личного.

Изменено 11 января, 2012 пользователем Alex/AT

[Deac]

То, о чём вы говорите, в терминологии RADIUS называется не "keepalive", а "interim accounting"

Сие может называться "Interim-Update" или "Alive", FreeRADIUS-у по барабану, мне привычнее "Alive". :)

 

И это не костыль, это штатная фича, имеющаяся в любом RADIUS-е. :)

[Alex/AT]

Interim-Update - это собственно пакет (я бы даже сказал - режим внутри пакета) аккаунтинга. А процесс называется interim accounting / interim accounting update. Ну да это ладно, это лирика.

Эта штатная фича предназначена для обновления аккаунтинговой информации в процессе работы пользователя, использование её для установки факта "живости" сессий - костыль.

Изменено 11 января, 2012 пользователем Alex/AT

[Deac]

Interim-Update - это собственно пакет аккаунтинга.

Acct-Status-Type = 3 - это Interim-Update или ALIVE, FreeRADIUS принимает и то и то.

 

Эта штатная фича предназначена для обновления аккаунтинговой информации в процессе работы пользователя

Это правильно.

 

использование её для установки факта "живости" сессий

...наиболее логично.

 

костыль.

Где же костыль то?

Изменено 11 января, 2012 пользователем Deac

[Alex/AT]

...наиболее логично.

Ничего логичного.

 

Просто вполне реально себе вижу возможную _штатную_ (!) ситуацию, когда по тем или иным причинам продолжает работать авторизация, стартстопы и прочее, но запаздывает interim аккаунтинг (интеримы вообще не генерятся или сбрасываются). При отсутствии нормальной проверки живости сессий в этой ситуации начнётся бардак. Ну и вижу ситуацию, когда период интеримов колеблется от минуты до получаса в зависимости... Да и таймаут в час (да даже в 5 минут) - это здорово, но пользователь как бы пораньше в инет хочет, желательно в течение нескольких секунд после выхода.

 

Ладно, я уже говорил - это просто разница в подходах. Смысла спорить нет, на вкус и цвет...

Изменено 11 января, 2012 пользователем Alex/AT

[lagman]

Можно по Inherim-Update обновлять некое поле в БД и по ивент-шедьюлеру или крону проверять наличие сессий, которые формально живые, но с которых не прилетал Inherim-Update в последний отчетный период. Я именно так и делаю ;)

[Deac]

Просто вполне реально себе вижу возможную _штатную_ (!) ситуацию, когда по тем или иным причинам продолжает работать авторизация, стартстопы и прочее, но запаздывает interim аккаунтинг (интеримы вообще не генерятся или сбрасываются).

Не встречал такого и даже никогда не слышал, но на всякий случай simultaneous check проверяется 2xAlive

 

Да и таймаут в час (да даже в 5 минут) - это здорово, но пользователь как бы пораньше в инет хочет, желательно в течение нескольких секунд после выхода.

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

Вот зависшие сессии будут препятствовать входу на время 2xAlive, у меня 2x3=6 минут.

Таковых сессий немного и проблем это не вызывает.

 

Можно по Inherim-Update обновлять некое поле в БД и по ивент-шедьюлеру или крону проверять наличие сессий, которые формально живые, но с которых не прилетал Inherim-Update в последний отчетный период. Я именно так и делаю ;)

Да это лишнее, просто делаешь в simultaneous check проверку на 2xAlive и всё, никаких лишних телодвижений.

Новая сессия откроется с другим Session-Id и более поздним Start-Time, т.ч. предыдущие, пусть и не закрытые, сессии мешать работе не будет.

Изменено 11 января, 2012 пользователем Deac

[Alexandr Ovcharenko]

Можно по Inherim-Update обновлять некое поле в БД и по ивент-шедьюлеру или крону проверять наличие сессий, которые формально живые, но с которых не прилетал Inherim-Update в последний отчетный период. Я именно так и делаю ;)

У нас тоже так делается. ПО крону раз в 5 минут стартует скрипт, который делает выборку из БД всех активных сессий и проверяет по ним разницу между меткой времени последнего Interim-Update и текущим временем. Если разница превышает 3мин (в МПД у нас set auth acct-update 90), то сессия закрывается.

При ежедневном он-лайне в 4тыс абонентов пару раз в год бывают жалобы, что после вылета с инета (например свич на доме ребутнулся от скачка электричества) реконнект идет не сразу.

В общем, кто ищет решения - тот находит решения, а кто ищет отмазки - тот находит отмазки. :)

 

Да это лишнее, просто делаешь в simultaneous check проверку на 2xAlive и всё, никаких лишних телодвижений.

Новая сессия откроется с другим Session-Id и более поздним Start-Time, т.ч. предыдущие, пусть и не закрытые, сессии мешать работе не будет.

У нас такое не канает. Потому как под одним логином возможен только 1 коннект.

Изменено 14 января, 2012 пользователем Alexandr Ovcharenko

[Deac]

нас такое не канает. Потому как под одним логином возможен только 1 коннект.

Так для того и нужен simultaneous check.