Непонятки с winbind

Главное, что в это время в log'е squid (cache.log)?

Это значит, что DC (samba или AD?) захлебнулся запросами от winbindd и в течении длительного времени не отдал положенный ответ. Причин м.б. несколько:

1) Запросы от winbind встали в очередь к DC, достигли потолка, после чего DC/Samba отвалилась и перестала отвечать вообще. Решение - увеличить количество ntlm/basic детей на пол порядка. На ~300 клиентов я бы положил 500-600 детей. Соотношение ntlm/basic зависит от ваших потребностей, у меня например 250/25. Причина - одномоментный лок 20-30 ntlm_auth процессов 1 клиентом на длительное (минута-две) время:

# TAG: auth_param
auth_param ntlm program /usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 250

authenticate_ttl 20 minutes
auth_param basic program /usr/local/bin/ntlm_auth --helper-protocol=squid-2.5-basic
auth_param basic children 25
auth_param basic realm Squid proxy-caching web server


2) Система просто очень нагружена и честно не успевает выполнить необходимые запросы, что приводит к таймауту, тогда можно воспользоваться кешем winbind чтобы усреднить загрузку:

#cache cred for much load systems
winbind offline logon = true
winbind cache time = 900

Комбинированный подход дает лучшие результаты. Статистику по использованию ntlm_auth и пр, можно посмотреть в реальном времени, забыл уже как, но все равно :)