madf

и тем не менее он встречается. редко, но встречается. происходит как правило в том случае, когда один логин используется на 2х и более компьютерах. пользователь вытягивает кабель (авторизатор не отключая), переключает его в другой компьютер и подключиться уже не может. СТГ отвечает, что логин уже используется. сессия пользовательская не отваливается от сервака ни через минуту, ни через 12 часов. эта ситуация подтверждена на 2х серверах. Чертовски странно. Тоже ни разу не встречал такого бага. lalex про авторизатор пишет а не про конфигуратор. Постараюсь на выходных выложить.

Зачем Stargazer'у быть RADIUS'ом?

Альтернативный подход - это не привязываться к авторизациям Stargazer а только работать с его базой. Тогда достаточно FreeRADIUS без всяких шаманств со стороны Stargazer. Мануал по rlm_stg есть (в pdf-ке). И есть пример конфигурации Stargazer + FreeRADIUS + PPtP с Readme в каталоге scripts.

Обычно у торрент-клиентов все-таки стоит ограничение поменьше. Тут проблема в том что на общем фоне pps одиночного пользователя почти незаметен. Я пришел к таким выводам по косвенным факторам: небольшому росту объемов NetFlow-трафика (считанные проценты) и резким увеличением количества записей в дереве пакетов TRAFFCOUNTER. При чем для "зависания" нужно чтобы все эти 200000 записей принадлежали одному пользователю и были сгенерированы примерно в одно время.

В первую очередь рассмотреть альтернативные варианты. А потом (если альтернативы все-таки не подходят) вооружиться текстовым редактором и компилятором и исправить все ошибки сборки.

Падает, зараза. Смотреть надо. Собирать в отладочном режиме и ловить корку. Или запускать из-под gdb и смотреть бектрейс. Если готов на такие шаги - могу рассказать что делать.

Ну естественно. Это модуль для 2.401, а у тебя 2.406.

Это я про то что торрент к этому отношения не имеет.

Я разрабатываю Stargazer, sgauth, sgconf, rscriptd, rlm_stg, convertor, qia, InetAccess и SgConfig (ну и еще много разного, но это не важно). К WEB-интерфейсу обсуждаемому в этой теме я отношения не имею, это все nightfly делает. Я же имел в виду WEB-интерфейс именно к консольному авторизатору. После компиляции будет бинарник с именем sgauth и несколько библиотек. Может и ясно, а может и нет Документация на консольный конфигуратор есть в PDF-ке и при запуске без ключей. Фактически, то что написано в PDF-ке повторяет вывод самого конфигуратора при запуске. Документацию к консольному авториз

Какие-то проблемы с базой. Я предупреждал что модуль для MySQL очень нестабилен.

Более 200000 разных ip-port за 30 секунд? Мне кажется, это не нормально. А примерно при такой нагрузке проблемы и начинаются. git://madf.dyndns.org/stg.git Но предупреждаю, что там изменения в траффкаунтере серьезные, может трафик неправильно считать. Надо за ним следить внимательно.

Это цикл, но это не подвисание. Я эти трейсы видел уже сто раз, и даже трассировал отладчиком. Это именно обработка трафика. Скорее всего от какого-то юзера идет портскан или подобная фигня когда трафик от него состоит из кучи маленьких пакетов по разным IP-адресам (или портам). Если интересно, могу выложить экспериментальную версию исходников, которые, по идее, должны справляться с этой проблемой.

Нифига не понял о каких авторизаторах идет речь? sgauth? InetAccess? qia?

Не совсем так. Там еще есть конфиг-файл и веб-интерфейс. Сперва влом было описывать, а потом забылось. Документации на консольный конфигуратор тоже долго небыло, но у него есть вменяемый help так что она и не нужна была особо. А вот про авторизатор тупо забыл

Так топикстартер не использует модуль радиуса.

вчера добавил по вашему совету, изначально в стартовом дампе был только просто "admin" Ну теперь по идее должно нормально журналировать.

Да, в том-то и дело, что только недавно приобрели новое серверное железо, а стабильности добиться не получается. Вроде бы только отточили, - добавили 200Мбит канала и как правило к вечеру ложится сервак. Если смотреть на графики, то получается, что при достижении пика происходит сбой. Может проблема в службе рассылки сообщений? Изначально мы ей так и не пользуемся, так как при отправке сообщений пользователям нагрузка возрастает и сервер загибается. Это было и на старом железе, а сейчас и на новом. Подскажите, в какую сторону копать? Кто на каком железе работает? Были ли у кого-то проблемы с

Добавил или он там был?

Мда... Надо бы дописать.

А есть ли в базе в таблице tb_admins админ с логином "@stargazer"? Если его нет - это причина. Нужно добавить вручную. В поле пароля можно забить "NO_PASSWORD", а в остальные поля нули. Тогда доступа для админа с таким логином не будет (а в слудующих версиях я его просто фильтрую), но журналирование будет работать. В скриптах для базы уже исправил.

В процессе работы не меняется.

Проблемы в системе. Либо с libstdc++, либо с компоновщиком. Еще в гугле говорят что такое может быть когда часть программы собрана gcc-3.*, а часть gcc-4.*. Сделай make clean и пересобери снова. собирал с помощью ./build сделал make clean и результат тотже. кроме того аналогичный результат при сборке sgconf, sgauth, rscriptd, convertor ... собрался только rlm_stg проблемы в системы - маловероятны, только установил систему Тем не менее они есть

Я так понимаю, используется древняя патченная версия со встроенным RADIUS-сервером? Тогда сразу предупреждаю что могут быть разные люки и я вряд-ли смогу чем-то помочь. Далее. А зачем "тушить" PPP-тоннель? Может достаточно файрволом блокировать инет по классической схеме, оставляя PPP-сессию в покое? Тогда и RADIUS особо не нужен. Еще посмотри кредит и параметр FreeMbAllowInet, как было замечен выше.

Зачем sudo в /etc/rc.local? Оно и так от рута запустит. А если цель запускать не от рута - он не будет работать.

Основная машина - это какая машина? Чтобы управлять доступом нужно настроить файрвол и скрипты OnConnect/OnDisconnect. Задавайте более четкие вопросы, оперируя понятиями "роутер", "локальная сеть", "канал", "интерфейс" и т.д. А то не очень понятно о чем именно спрашиваете.