proNovell

Уважаемые коллеги!
В продолжении темы о неспровоцированной блокировке пользователей

В рамках разбирательства по упомянутой теме на проблемном сервере был запущен DSTARCE-модуль в команде:
load dstarce -all +ldap
с протоколированием в файл.
В файл посыпались ошибки вида:

Код: Выделить всё

Monitor 0x1f3 found connection 0xc62e32e0 socket closed, err = -5871, 0 of 0 bytes read
Monitor 0x1f3 initiating close for connection 0xc62e32e0
Server closing connection 0xc62e32e0, socket error = -5871
Connection 0xc62e32e0 closed
New cleartext connection 0xd0eb6900 from 172.16.1.1:36778, monitor = 0x1f3, index = 2
New cleartext connection 0xd0eb69e0 from 172.16.1.1:36779, monitor = 0x1f3, index = 3
Connection 0xd0eb69e0 closed
Monitor 0x1f3 found connection 0xd0eb6900 socket closed, err = -5871, 0 of 0 bytes read
Monitor 0x1f3 initiating close for connection 0xd0eb6900
Server closing connection 0xd0eb6900, socket error = -5871
Connection 0xd0eb6900 closed
New cleartext connection 0xd0eb6900 from 172.16.1.1:36828, monitor = 0x1f3, index = 2
New cleartext connection 0xd0eb69e0 from 172.16.1.1:36829, monitor = 0x1f3, index = 3
Connection 0xd0eb69e0 closed
Monitor 0x1f3 found connection 0xd0eb6900 socket closed, err = -5871, 0 of 0 bytes read
Monitor 0x1f3 initiating close for connection 0xd0eb6900
Server closing connection 0xd0eb6900, socket error = -5871
Connection 0xd0eb6900 closed

Среди моря подобных постоянных сообщений иногда появляются островки спокойствия:

Код: Выделить всё

Connection 0xd0eb6900 closed
Work info status: Total:5 Peak:5 Busy:0
Thread pool status: Total:15 Peak:14 Busy:3
New cleartext connection 0xd0eb6900 from 172.16.1.1:36731, monitor = 0x1f3, index = 2
New cleartext connection 0xd0eb69e0 from 172.16.1.1:36732, monitor = 0x1f3, index = 3
New cleartext connection 0xd0eb6ac0 from 172.16.1.1:36733, monitor = 0x1f3, index = 4
New cleartext connection 0xd0eb6ba0 from 172.16.1.1:36734, monitor = 0x1f3, index = 5
New cleartext connection 0xd0eb6c80 from 172.16.1.1:36735, monitor = 0x1f3, index = 6
New cleartext connection 0xd0eb6d60 from 172.16.1.1:36736, monitor = 0x1f3, index = 7
New cleartext connection 0xd0eb6e40 from 172.16.1.1:36737, monitor = 0x1f3, index = 8
New cleartext connection 0xd0eb6f20 from 172.16.1.1:36738, monitor = 0x1f3, index = 9
New cleartext connection 0xc62e3040 from 172.16.1.1:36739, monitor = 0x1f3, index = 10
New cleartext connection 0xc62e3120 from 172.16.1.1:36740, monitor = 0x1f3, index = 11
New cleartext connection 0xc62e3200 from 172.16.1.1:36741, monitor = 0x1f3, index = 12
New cleartext connection 0xc62e32e0 from 172.16.1.1:36742, monitor = 0x1f3, index = 13
Monitor 0x1f3 found connection 0xd0eb6900 socket closed, err = -5871, 0 of 0 bytes read
Monitor 0x1f3 initiating close for connection 0xd0eb6900
Server closing connection 0xd0eb6900, socket error = -5871
Connection 0xd0eb6900 closed
Monitor 0x1f3 found connection 0xd0eb69e0 socket closed, err = -5871, 0 of 0 bytes read
Monitor 0x1f3 initiating close for connection 0xd0eb69e0
Server closing connection 0xd0eb69e0, socket error = -5871
Connection 0xd0eb69e0 closed

Вопросы:
Не помогут ли коллеги разобраться в этом протоколе?
как увязать сообщения в логе с активностью Дерева? как добиться (если можно) времЕннЫх меток в протоколе? где смотреть эти ошибки?
ну, и тд...
Спасибо за ответы или за ссылки на вменяемую доку.
PS. ип-аддр - это адрес лин-сервера, который с помощью сквида контролирует выход пользователей в Сеть.

Музалёв Николай писал(а):Уважаемые коллеги!
В продолжении темы о неспровоцированной блокировке пользователей

В рамках разбирательства по упомянутой теме на проблемном сервере был запущен DSTARCE-модуль в команде:
load dstarce -all +ldap
с протоколированием в файл.
В файл посыпались ошибки вида:

Код: Выделить всё

Monitor 0x1f3 found connection 0xc62e32e0 socket closed, err = -5871, 0 of 0 bytes read


Спасибо за ответы или за ссылки на вменяемую доку.
PS. ип-аддр - это адрес лин-сервера, который с помощью сквида контролирует выход пользователей в Сеть.

http://support.novell.com/cgi-bin/searc ... 095373.htm
Не та дока?

Не та дока?

Спасибо, конечно ее я смотрел...
Др. дело, что статья для меня не информативна: 4L свичей у меня вроде нет, а вот сквид в качестве LDAP-приложения... ммм... надо подумать...
Не исключено, что придется тралить канал шнифером и потом пробовать разобраться....
А еще кто чего скажет?

Музалёв Николай писал(а):сквид в качестве LDAP-приложения

The -5871 errors have also been known to be caused by a LDAP Client improperly terminating a connection.
Test another utility like Ldapsearch or Ldap Browser to see if it shows similiar results. If it does not show the -5871 errors, then the previous Ldap Client/Application is the culprit.

Подозреваю, что меня начнут бить ногами любители сквида, но кульбиты сквид действительно выкидывает и с соединениями (когда их много) и с протоколами (одно время наивно надеялся собрать нечто работоспособное Squid+ICAP, убил кучу времени пока не понял что подправлять дальше только кусок ICAP клиента просто не реально, исправления захватывают все больше и больше других кусков к ICAP-у не имеющих отношения). Неисключено что и с LDAP не все гладко.

Сниффер конечно хорошо, но и сквидовый лог не помешает
squid_ldap_auth или squid_ldap_group с ключиком -d (маленькой)
и более подробный лог dstrace (без -all)

и сквидовый лог не помешает

Угу... спасибо.
Мой лин-коллега будет в понедельник 10 ( а без него пока не горазд я лезть в лин-сервер), и посмотрим в соответствии с вашими советами...
Спасибо.

Музалёв Николай писал(а):Мой лин-коллега ( а без него пока не горазд я лезть в лин-сервер)

можно и под cygwin скомпилять, разобраться, может к понедельнику уже и созреет идея.