https://www.opennet.ru/openforum/vsluhforumID12/6909.html Доброго времени.<br>RHEL 6.0, squid 3.1.20, winbind из пакета samba 3.6.8.<br><br>Количество пользователей ок. 1500, канал 60Мбит. Для аутентификации юзеров используется связка winbind+AD.<br><br>Примерно при такой нагрузке<br><br>SqStat: 1360 users and 3381 connections<br><br>netstat -ant&#124; awk '{print $4}'&#124;grep '.8080'&#124;wc -l<br>11079<br><br>top - 16:05:11 up 11 days, 17:48, 3 users, load average: 0.41, 0.45, 0.39<br>Tasks: 1385 total, 2 running, 1383 sleeping, 0 stopped, 0 zombie<br>Cpu(s): 8.1%us, 4.0%sy, 0.0%ni, 86.0%id, 0.1%wa, 0.2%hi, 1.7%si, 0.0%st<br>Mem: 8062044k total, 7067616k used, 994428k free, 574564k buffers<br>Swap: 1691640k total, 40848k used, 1650792k free, 3126468k cached<br><br> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND<br>23589 squid 20 0 729m 524m 3800 R 84.6 6.7 100:21.87 squid<br>26741 root 20 0 242m 53m 24m S 20.7 0.7 12:43.91 winbindd<br>26743 root 20 0 221m 34m 28m S 9.2 0.4 5:55.48 winbindd<br><br><br>Смотрю squidclient -p 8080 https://www.opennet.ru/openforum/vsluhforumID12/6909.html#13 Tue, 25 Dec 2012 09:26:19 GMT День добрый.<br>После гугления, анализа и прочего прочего остановился на negotiate схеме с хелпером kerb_auth. Для недоменных юзеров(точнее будет сказать для юзеров, чьи машины не в домене, но которые имеют учетку в АД для доступа в Инет) basic схема с хелпером ldap_auth. Проверка на принадлежность к группе через ldap_group.<br>Пока что данная схема проходит этап тестирования и утверждения. Как она покажет себя при нагрузке в 1500 человек сказать не могу. Остается только верить в лучшее, так как пути назад уже нет: ntlm_auth через winbind себя уже изжил. Никогда эта связка у меня не работала надежно.<br>Есть и пару "но". <br>Иногда на недоменных машинах выскакивает окно авторизации,а в cache.log ошибка:<br><br>authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information. '<br><br>Так же периодически появляются записи в cache.log:<br><br>squid_ldap_group WARNING, LDAP search error 'Can't contact LDAP ser https://www.opennet.ru/openforum/vsluhforumID12/6909.html#12 Wed, 05 Dec 2012 15:25:00 GMT &gt;[оверквотинг удален]<br>&gt;&gt; внутри группы.<br>&gt; Как вариант, в вашем случае, не отказываться от рабочей схемы взаимодействия сервера <br>&gt; прокси (squid) и сервера учетных данных (samba+AD). Попробуйте задачу по проверке <br>&gt; пользователей повесить на Squid_kerb_auth, а проверку по принадлежности к группе оставить <br>&gt; как есть через samba. В этом случае вы снизите нагрузку на <br>&gt; самбу, минуя ее, в части проверки пользователей. Грубо говоря, проверка пользователей <br>&gt; будет производиться напрямую по такой схеме: <br>&gt; squid-&gt;squid_kerb_auth-&gt;AD_KERBEROS вместо squid-&gt;ntlm_auth-&gt;samba_server-&gt;ActiveDirectory <br>&gt; Если вы решитесь попробовать, сообщите результат. Ваш опыт может помочь другим пользователям <br>&gt; ищущим решения подобных проблем.<br><br>Только сейчас обратил внимание на "auth_param ntlm children 1100". Мне кажется такое количество хелперов излишне, попробуйте сократить количество до реально нужного количества. В моем случае, нужное количество хелперов я получал из расчета пикового использования сервера (смотрел https://www.opennet.ru/openforum/vsluhforumID12/6909.html#11 Wed, 05 Dec 2012 14:46:26 GMT &gt;[оверквотинг удален]<br>&gt;&gt; вложенные группы?<br>&gt; Честно сказать, не пробовал, возможно, можно построить такой запрос. Вот пример из <br>&gt; конфига: <br>&gt; external_acl_type ldap_group ttl=3600 negative_ttl=3600 <br>&gt; children=30 %LOGIN /usr/local/libexec/squid/squid_ldap_group -P -R -b "dc=ччч,dc=ццц,dc=ттт" <br>&gt; -f "(&(samaccountname=%v)(memberof=cn=%a,OU=Internet,OU=Access List,DC=ччч,DC=ццц,DC=ттт))" <br>&gt; -D squid_ldap_user@ччч.ццц.ттт -W /usr/local/etc/squid/ldap.pass -K -h ldap.domain.server <br>&gt; судя по всему в ключе -f можно построить нужный вам запрос, который <br>&gt; будет проверять не только принадлежность к группе, но и к группам <br>&gt; внутри группы.<br><br>Как вариант, в вашем случае, не отказываться от рабочей схемы взаимодействия сервера прокси (squid) и сервера учетных данных (samba+AD). Попробуйте задачу по проверке пользователей повесить на Squid_kerb_auth, а проверку по принадлежности к группе оставить как есть через samba. В этом случае вы снизите нагрузку на самбу, минуя ее, в части проверки пользовател https://www.opennet.ru/openforum/vsluhforumID12/6909.html#10 Wed, 05 Dec 2012 14:29:01 GMT &gt; Благодарю откликнувшихся.<br>&gt; Андрей,вопрос к вам. Точнее уточнение.<br>&gt; Я писал: <br>&gt;&gt; Насколько помнится LDAP_auth не поддерживает авторизацию по вложенным группам?<br>&gt; Имел ввиду, что у меня Инетовские юзера лежат в группе вида grp.XX.internet, <br>&gt; где ХХ - порядковый номер. Все эти группы входят в одну <br>&gt; grp.all.internet, по которой и происходит авторизация. Так вот, как LDAP_auth отнесется <br>&gt; к тому, что ему придется работать с группой, в которой есть <br>&gt; вложенные группы?<br><br>Честно сказать, не пробовал, возможно, можно построить такой запрос. Вот пример из конфига:<br>external_acl_type ldap_group ttl=3600 negative_ttl=3600 children=30 %LOGIN /usr/local/libexec/squid/squid_ldap_group -P -R -b "dc=ччч,dc=ццц,dc=ттт" -f "(&(samaccountname=%v)(memberof=cn=%a,OU=Internet,OU=Access List,DC=ччч,DC=ццц,DC=ттт))" -D squid_ldap_user@ччч.ццц.ттт -W /usr/local/etc/squid/ldap.pass -K -h ldap.domain.server<br><br>судя по всему в ключе -f можно построить нужный вам запрос, который будет проверять не только принадлеж https://www.opennet.ru/openforum/vsluhforumID12/6909.html#9 Wed, 05 Dec 2012 12:20:45 GMT Благодарю откликнувшихся.<br>Андрей,вопрос к вам. Точнее уточнение.<br><br>Я писал:<br>&gt; Насколько помнится LDAP_auth не поддерживает авторизацию по вложенным группам?<br><br>Имел ввиду, что у меня Инетовские юзера лежат в группе вида grp.XX.internet, где ХХ - порядковый номер. Все эти группы входят в одну grp.all.internet, по которой и происходит авторизация. Так вот, как LDAP_auth отнесется к тому, что ему придется работать с группой, в которой есть вложенные группы?<br><br> https://www.opennet.ru/openforum/vsluhforumID12/6909.html#8 Wed, 05 Dec 2012 03:34:31 GMT Попробуйте отключить дисковый кэш сквида. Дисковый кэш сам по себе тормоз, а при таком количестве юзеров думаю еще больший тормоз. cache_mem 512 mb. Попробуйте и его увеличить. <br> https://www.opennet.ru/openforum/vsluhforumID12/6909.html#7 Tue, 04 Dec 2012 20:18:27 GMT &gt;&gt;Важно выяснить на каком этапе происходит задержка <br>&gt;&gt; ответа авторизации.<br>&gt; В том то и дело, что оба проксика настроены на один контроллер. <br>&gt; Проксик, который работает без нагрузки отдает страницы быстро, без задержек. =&gt;тормозит <br>&gt; Samba.<br>&gt; Насколько помнится LDAP_auth не поддерживает авторизацию по вложенным группам?<br><br>Не совсем так, squid имеет достаточно хороший арсенал для авторизации.<br>Ниже не полный список всех возможных хелперов.<br><br>FreeBSD# ls /usr/local/libexec/squid/<br>cachemgr.cgi ntlm_auth squid_ldap_group<br>digest_ldap_auth pam_auth squid_radius_auth<br>digest_pw_auth smb_auth squid_session<br>diskd smb_auth.sh squid_unix_group<br>ip_user_check squid_db_auth unlinkd<br>msnt_auth squid_kerb_auth wbinfo_group.pl<br>ncsa_auth squid_ldap_auth<br><br>squid_ldap_group - вот то что вам нужно, если вам необходимо проверять принадлежность к группе. Насколько https://www.opennet.ru/openforum/vsluhforumID12/6909.html#6 Tue, 04 Dec 2012 10:48:53 GMT &gt;Важно выяснить на каком этапе происходит задержка <br>&gt; ответа авторизации.<br><br>В том то и дело, что оба проксика настроены на один контроллер. Проксик, который работает без нагрузки отдает страницы быстро, без задержек. =&gt;тормозит Samba.<br><br>Насколько помнится LDAP_auth не поддерживает авторизацию по вложенным группам? <br> https://www.opennet.ru/openforum/vsluhforumID12/6909.html#5 Mon, 03 Dec 2012 22:04:16 GMT &gt;[оверквотинг удален]<br>&gt; 0% 1440 <br>&gt; refresh_pattern -i (/cgi-bin/&#124;\?) 0 0% <br>&gt; 0 <br>&gt; refresh_pattern -i onegate.unicreditgroup.eu/. <br>&gt; 3600 100% 3600 <br>&gt; refresh_pattern . <br>&gt; 0 <br>&gt; 20% 4320 <br>&gt; sleep_after_fork 10000 <br>&gt; max_filedescriptors 16384 <br><br>Когда-то была похожая ситуация, при подобных настройках, узким местом в этой связке выступал один из нагруженных серверов Active Directory. В вашем случае может оказаться не только сервер АД узким местом но и Samba сервер, которая может давать о себе знать. Большое количество занятых хелперов, &#1108;то признак медленной работы сервера авторизации, но вот от кого именно, Samba или AD, вам предстоит выяснить. Для начала сравните настройки Samba с двух прокси серверов, посмотрите разницу. После попробуйте посмотреть какие сервера АД используют оба сервера Прокси. Важно выяснить на каком этапе происходит задержка ответа авторизации. <br><br>В моем случае, в подобных ситуации, я отказался от такой авторизации