один из пользователей не может подключиться

[napTu 4]

второй раз появляется такой глюк:

- пользователь не может подключиться - кнопка подключения выпадает назад.

- если изменить символ в имени или пароле - выдается соответствующая ошибка о неверном имени/пароле.

- по trafshow обмен с сервером во время попыток подключения идет.

- наблюдается только у одного пользователя, у других всё в порядке.

- лечится перезапуском сервера.

 

система freeBSD4.10,

сервер:

2008-01-08 12:54:03 -- Stg started successfully.

2008-01-08 12:54:03 -- Module: 'Stg configurator v.0.05'. Start successfull. 220

2008-01-08 12:54:03 -- Module: 'Always Online authorizator v.1.0'. Start successfull. 70

2008-01-08 12:54:03 -- Module: 'InetAccess authorizator v.1.1'. Start successfull. 50

2008-01-08 12:54:03 -- Module: 'netflow_cap v.1.3.4'. Start successfull. 15

2008-01-08 12:54:03 -- Traffcounter started successfully.

2008-01-08 12:54:03 -- Users started successfully.

2008-01-08 12:54:03 -- Storage plugin: file_store v.1.02. Loading successfull.

2008-01-08 12:54:03 -- Timer thread started successfully.

2008-01-08 12:54:03 -- Message queue created successfully. msgKey=5555 msgID=131072

2008-01-08 12:54:03 -- Stg v. Stg 2.403b

 

скриптообработчиков - 3 штуки.

пользователей 350.

 

Посоветуйте пожалуйста, что можно поделать?

[den68 0]

 

Посоветуйте пожалуйста, что можно поделать?

построчный вывод правил файрвола в тот момент когда его не пускает.

[napTu 4]

ты не понял, я не перегружаю машину, я перезапускаю stargazer и всё становится замечательно. Какие претензии к фаерволу?

 

В фаерволе у меня не вводятся блокирующие правила при отключении пользователя, а удаляются разрешающие для онного. Перед этим стоит одно разрешающее для всех чтобы пропускать авторизацию и у всех при этом всё хорошо.

 

кроме того при неверном имени-пароле обмен нормальный.

 

кстати, проблема возникала у разных пользователей.

[madf 279]

Могу посоветовать обновиться до 2.404. Была куча исправлений именно по плагину авторизации.

[napTu 4]

переехал я на 2.404, но ситуация осталась неизменной.

Случайный пользователь не может подключиться, кнопка авторизатора отпадает. При изменении логина сообщает об ошибке. Перезапускаем старгейзер - всё в норме.

Кстати, старые версии авторизатора перестали сообщать об ошибке.

 

Как бы протрассировать этот глюк?

[madf 279]

Запусти в отладочном режиме и приведи выхлоп старгейзера в момент неподключения юзера.

[napTu 4]

отличное предложение!

он же на консоль сыпет лог.

да и доступа нет к компу щас. тока ssh

а пользователь у меня раз в 1-5 суток не может подключиться.

и как я этот выхлоп буду дежурить?

причем среди сыпания сообщений об неуспешности удаления несуществующих правил:

ipfw: rule 32643: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 32644: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 32645: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 38264: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 42641: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 42642: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 42643: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 42644: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 3640: setsockopt(IP_DUMMYNET_DEL): Invalid argument

ipfw: rule 3641: setsockopt(IP_DUMMYNET_DEL): Invalid argument

ipfw: rule 3642: setsockopt(IP_DUMMYNET_DEL): Invalid argument

ipfw: rule 31021: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 31022: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 31023: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 31024: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 31025: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 38102: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 41021: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 41022: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 41023: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 41024: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 2020: setsockopt(IP_DUMMYNET_DEL): Invalid argument

ipfw: rule 2021: setsockopt(IP_DUMMYNET_DEL): Invalid argument

ipfw: rule 2022: setsockopt(IP_DUMMYNET_DEL): Invalid argument

ipfw: rule 31795: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 38179: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 41791: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 41792: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 41793: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 41794: setsockopt(IP_FW_DEL): Invalid argument

ipfw: rule 2790: setsockopt(IP_DUMMYNET_DEL): Invalid argument

ipfw: rule 2791: setsockopt(IP_DUMMYNET_DEL): Invalid argument

ipfw: rule 2792: setsockopt(IP_DUMMYNET_DEL): Invalid argument

[madf 279]

Лог можно перенаправить в файл. А потом по времени отследить. Файл, конечно, будет большой, но нам приходилось разбирать логи и по сотне Гб

Проверь скрипты. Где-то ошибка...

[napTu 4]

перенаправление в файл можно сделать, но надо добраться до сервера, ибо при отвале ssh упадет всё что в этой сессии запущено и не демонизировано.

 

перенаправлял кстати в файл. там просто список ип адресов, которые, как я предполагаю, подключились. по одному на строку.

 

в скриптах не ошибка, а фича . для разных тарифов разные строки правил инициируются, а при отключении удаляются все правила для любого тарифа.

[madf 279]

перенаправление в файл можно сделать, но надо добраться до сервера, ибо при отвале ssh упадет всё что в этой сессии запущено и не демонизировано.

 

перенаправлял кстати в файл. там просто список ип адресов, которые, как я предполагаю, подключились. по одному на строку.

 

в скриптах не ошибка, а фича . для разных тарифов разные строки правил инициируются, а при отключении удаляются все правила для любого тарифа.

1. nohup?

2. Отладочный лог старгейзера - это намного больше чем просто список IP-адресов. Пересобери в debug-режиме и посмотри.

3. Так мож тогда их в /dev/null?

[napTu 4]

1. nohup?

- не знал...

2. Отладочный лог старгейзера - это намного больше чем просто список IP-адресов. Пересобери в debug-режиме и посмотри.

- дык я с чего и удивляюсь, собрал ./build debug , а оно мне список ип адресов пихает.

3. Так мож тогда их в /dev/null?

- да, спасибо за мысль, надо syslog.conf поковырять...

[napTu 4]

блин, ерунда какаято.

запускаю тестовый старгез собранный как ./build debug ,

а он мне ничего не выводит. конекчусь, дисконекчусь, авторизатором,конфигуратором - никаких сообщений.

че делать? ума не приложу.

[madf 279]

После сборки в режиме debug делай так:

1. В конфиге пропиши путь к модулям modulesPath=./modules

2. LD_LIBRARY_PATH=../../lib ./stargazer

(это все из каталога сбоки)

[napTu 4]

аааа, блиннн, точно, он же библиотеки перекомпилил, а я их не снес в общий доступ!

[napTu 4]

нет у меня возможности врубать в дебаг режиме (да еще и с его глюками) и копить логи (места мало).

 

Однако заметил следующую закономерность: невозможность подключения возникает в тех местах, где наблюдалась проблема с оборудованием (т.е., к примеру, свич с потерями). пользователь долбит подключение, не удается, а затем восстанавливаем свич, но его более не пускает. Причем не пускает именно его ИП,с другого ИП на томже логине можно подключиться.

Как будто бан какойто, или множество накопленных и не обработанных(не обрабатываемых) реквестов в очереди.

[madf 279]

Глюки режима отладки? Это что?

Бана никакого нету, и очереди тоже нету. Для авторизации используется протокол UDP. Если пакет не дошел - он уже не дойдет. Сейчас еще раз проверю таймаутер (он отвечает за смену фаз авторизции).

[madf 279]

Проверил код.

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

Все работает штатно. Какие-нибуть патчи на код накладывались?

 

Ты там говорил про какой-то "список IP". Stargazer не выводит никаких списков IP.

[napTu 4]

Глюки режима отладки? Это что?

да...начитался форума...про рассинхроницацию времени и прочую лабуду...

 

Какие-нибуть патчи на код накладывались?

ага, нетфлоу с его задержкой отключения пользователя

Ты там говорил про какой-то "список IP". Stargazer не выводит никаких списков IP.

это скомпиленный в дебаг режиме, но со старыми библиотеками, возможно это шло со скриптов, сейчас не важно, ибо дебаговый стг я пока не запускал в полном объеме.

[napTu 4]

попробую сымитировать эту ситуацию, отпишусь.

[madf 279]

...

 

Какие-нибуть патчи на код накладывались?

ага, нетфлоу с его задержкой отключения пользователя

 

...

Может в нем и баг.

[napTu 4]

неа, не в нем. перекомпилил без патча - снова жалобы (уже две).

 

Поставил у себя в фаерволе фичу с потерей пакетов, но пока не могу попасть на эту ситуацию.

[BECHA 0]

а прийти к этому пользователю с ноутом и воткнуться в его шнурочек не пробывали?

[napTu 4]

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

пробывали добавить еще один ип адрес в конфиг пользователя и с него подключится - работает.

смысл к нему идти?

зависает ип адрес в сервере стг.

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

[napTu 4]

madf , подскажи,

если, к примеру, множество пользователей одновременно ломятся на подключение, есть ли какая нить ограничивающая таблица, в которую они могут не влезть?

 

Хотя после перезапуска стг всё ок происходит, все подключаются без вопросов....

 

иль может автодисконнект не до конца сработавший прерыватся новой попыткой коннекта?

[madf 279]

Никаких таблиц. Все зпросы на подключения представляют собой UDP-пакеты. STG просто последовательно их вычитывает и обрабатывает. Процесс авторизации разбит на несколько фаз. У каждой из них есть таймаут. При привышении считается что пользователь отключился и все связанные с ним кеши и индексы очищаются.

В STG практически нет таблиц фиксированного размера - используются контейнеры STL. По этому ограничений никаких не налагается.