Comments 57
Логики с более оптимальным использованием оперативной памяти не уловил. По-моему все осталось также + накладные расходы от вм.
А я и не говорил, что оперативная память стала лучше использоваться. Меня досаждало только, что ОЗУ забита, а процессор (практически самая дорогая часть системника) отдыхает. Здесь же я загрузил процессор, за счет чего появилось больше времени на распитие кофе.
А исходя из чего делался вывод о том, что ОЗУ забито? Если один экземпляр ntlm_auth занимает в оперативной памяти около 60 мегабайт, то делать вывод о том, что десять экземпляров будут занимать 600 мегабайт, мягко говоря, неверно.
Вывод делался на основе показаний top'а:
Просто в моей конфигурации, как я написал под UPD, используется скрипт, аналогичный wbinfo_group.pl, для определения самого доменного логина пользователя, чтобы можно было каждому конкретному пользователю выдать привилегии, отличающиеся от привилегии его группы (дополнительный запрет или дополнительное разрешение), так как в коробочной поставке Squid'а такого функционала нет. Соответственно, файл squid.conf становится значительно больше в размерах и больше ресурсов тратится на его обработку, что, конечно, не есть гуд, но в моем случае это нужно.
Просто в моей конфигурации, как я написал под UPD, используется скрипт, аналогичный wbinfo_group.pl, для определения самого доменного логина пользователя, чтобы можно было каждому конкретному пользователю выдать привилегии, отличающиеся от привилегии его группы (дополнительный запрет или дополнительное разрешение), так как в коробочной поставке Squid'а такого функционала нет. Соответственно, файл squid.conf становится значительно больше в размерах и больше ресурсов тратится на его обработку, что, конечно, не есть гуд, но в моем случае это нужно.
По данному выводу видно, что в наличии куча памяти и система вообще ничем не загружена.
p.s. А что такое «обработка squid.conf»? Это какой-то ресурсоёмкий процесс?
p.s. А что такое «обработка squid.conf»? Это какой-то ресурсоёмкий процесс?
Я вижу, что из 641116 K занято 607148K, свободно 33968K, то есть свободно 5%.
По поводу обработки squid.conf… Вообще, как мне кажется, чтение строки ACL и сравнение текущего запроса с этим ACL при большом количестве этих самых ACL, затем обработка http_access для этих ACL — довольно ресурсоемкий процесс. Особенно, если в конфиге содержится 1000 строк касательно http_access и 200 касательно ACL.
При этом несколько раз в секунду запускаются два процесса, отбирающие 100М оперативной памяти.
Это эмпирическое наблюдение, а не теоретические выкладки.
По поводу обработки squid.conf… Вообще, как мне кажется, чтение строки ACL и сравнение текущего запроса с этим ACL при большом количестве этих самых ACL, затем обработка http_access для этих ACL — довольно ресурсоемкий процесс. Особенно, если в конфиге содержится 1000 строк касательно http_access и 200 касательно ACL.
При этом несколько раз в секунду запускаются два процесса, отбирающие 100М оперативной памяти.
Это эмпирическое наблюдение, а не теоретические выкладки.
Системы unix-like используют «свободную» память под дисковый кеш и прочее.
Можете в этом убедиться, запустив htop. Он зеленым покажет использование памяти процессами userspace'а, а желтым — использование памяти под кеш.
Ну а по поводу памяти отдельного процесса, VIRT — это НЕ количество занимаемой физической памяти
Можете в этом убедиться, запустив htop. Он зеленым покажет использование памяти процессами userspace'а, а желтым — использование памяти под кеш.
Ну а по поводу памяти отдельного процесса, VIRT — это НЕ количество занимаемой физической памяти
> В случае же присутствия распределенной сети отделений, филиалов, когда обязанности и ответственность админов разделены, то такая система, «ожидающая» лучшей инфраструктуры — лучшее, что пришло в голову.
В таком случае лучшей идеей будет Forefront TMG в массиве, управляемом с Enterprise Management Server. IMHO.
В таком случае лучшей идеей будет Forefront TMG в массиве, управляемом с Enterprise Management Server. IMHO.
Как-то все сложно у вас получается, у меня 30 потоков ntlm_auth обслуживает ~300 пользователей (по 8 мегабайт на поток) + 2 потока winbind по 12 мегабайт.
Проблема с отваливанием контроллера домена и запросом авторизации решается через указание:
krb5.conf
dns_lookup_kdc = yes
ну и для верности:
admin_server=tcp/domain.local
kdc=tcp/domain.local
smb.conf
security = ads
password server = *
Проблема с отваливанием контроллера домена и запросом авторизации решается через указание:
krb5.conf
dns_lookup_kdc = yes
ну и для верности:
admin_server=tcp/domain.local
kdc=tcp/domain.local
smb.conf
security = ads
password server = *
upd: не туда глянул, по 2.5 мегабайта на поток + по 2 мегабайта на winbind
Вот с памятью и потоками ничего не мог поделать. Как-то они ее сжирают, как — не знаю :) Скриншот не врет. При первом тестировании было 5 процессов ntlm_auth, 4 пользователя прокси уже не осилил (или 5 — точно не помню).
За совет спасибо, обязательно потестирую, есть только один вопрос: когда проблема именно в контроллере домена (грубо говоря, из него выдернули сетевой кабель), приведенные вами опции спасут положение?
Для меня важно, чтобы даже в таком случае (с кабелем) все автоматически перешло на недоменную конфигурацию и продолжило работу до лучших времен :)
За совет спасибо, обязательно потестирую, есть только один вопрос: когда проблема именно в контроллере домена (грубо говоря, из него выдернули сетевой кабель), приведенные вами опции спасут положение?
Для меня важно, чтобы даже в таком случае (с кабелем) все автоматически перешло на недоменную конфигурацию и продолжило работу до лучших времен :)
Может быть лучше на этот случай иметь бакап-контроллер (а еще лучше не один)? Если выдергивают кабель из контроллера домена при единственном контроллере — это беда для домена…
Конечно, лучше, я не спорю :)
Но, во-первых, разделение полномочий :)
Во-вторых, пока есть глюки с доменом, есть глюки с проксей.
Здесь же, во-первых, уменьшается головная боль во время заскоков домена, во-вторых, есть отчетность, которая показывает, когда происходили заскоки и сколько они длились. Ну а третий фактор — легче администрировать. Может, он и очень субъективный, но радость доставляет :)
Но, во-первых, разделение полномочий :)
Во-вторых, пока есть глюки с доменом, есть глюки с проксей.
Здесь же, во-первых, уменьшается головная боль во время заскоков домена, во-вторых, есть отчетность, которая показывает, когда происходили заскоки и сколько они длились. Ну а третий фактор — легче администрировать. Может, он и очень субъективный, но радость доставляет :)
Т.е. у вас 200+ пользователей и 1 контроллер домена? Если из него выдернуть кабель, вся сеть перестанет корректно работать, оставшись без авторизации и DNS.
То, что я предложил, это динамическое переключение между контроллерами домена, т.е. их должно быть больше одного в сети.
То, что я предложил, это динамическое переключение между контроллерами домена, т.е. их должно быть больше одного в сети.
Я знаю, что будет, если выдернуть кабель :) Но статья-то о проксях :)
Тут просто нужно настучать по шее админу, кто следит за доменом, а не придумывать костыль, там где он не нужен, ИМХО.
Я, конечно, согласен.
Но, есть несколько замечаний.
1. Тематика данного ресурса не включает в себя вопросы рукоприкладства.
2. Ситуации в жизни бывают разные, решения для них нужны тоже разные.
3. Добрая половина всех решений в администрировании — костыли. Кто-то их использует, потому что нет денег на покупку software+hardware, кто-то просто из своих принципов. Костыли собираются в сборники, публикуются в блогах. Какой-то костыль дает ознакомившемуся с ним человеку вдохновение написать какую-то софтину, которая потом становится известным и признанным костылем, автоматизирующим что-то и позволяющим устранить недоработки или недосмотры крупных производителей ПО, и уже никто не называет ее костылем, а называют «классная софтина».
Но, есть несколько замечаний.
1. Тематика данного ресурса не включает в себя вопросы рукоприкладства.
2. Ситуации в жизни бывают разные, решения для них нужны тоже разные.
3. Добрая половина всех решений в администрировании — костыли. Кто-то их использует, потому что нет денег на покупку software+hardware, кто-то просто из своих принципов. Костыли собираются в сборники, публикуются в блогах. Какой-то костыль дает ознакомившемуся с ним человеку вдохновение написать какую-то софтину, которая потом становится известным и признанным костылем, автоматизирующим что-то и позволяющим устранить недоработки или недосмотры крупных производителей ПО, и уже никто не называет ее костылем, а называют «классная софтина».
В вашем случае проверялась принадлежность пользователя группе? Или каждой конкретной пользовательской доменной учетной записи можно было назначить свои права и привилегии, отличающиеся от тех, которые были предоставлены группе, членом которой он является?
Почему вы выбрали авторизацию ntlm_auth? Я после недолгого промежутка в работе с данной схемой решил отказаться от неё в пользу negotiate(kerberos).
Так же интересует отличие локального режима от доменного? Или вы дублировали всех пользователей с их паролями в отдельный файл и использовали basic авторизацию?
В итоге из 7 задач поставленных в начале — вы решили лишь две.
Так же интересует отличие локального режима от доменного? Или вы дублировали всех пользователей с их паролями в отдельный файл и использовали basic авторизацию?
В итоге из 7 задач поставленных в начале — вы решили лишь две.
Контроллер домена находится не в моем ведении, и у меня нет особого желания погружаться в дебри, рискуя свалить какой-нибудь сервис, ибо простой даже в один час очень дорого обходится. Я выбрал тот инструмент, который показался более удобным в тот момент времени.
Насчет отличий локального и доменного режима.
Данный прокси вводился мной для решения задач более информационной безопасности, нежели администрирования, учета рабочего времени и т.п. Основная его задача — блокирование передачи файлов в интернет (через веб-формы, через mail.ru агент, через icq). Эти задачи выполняет iptables гипервизора в независимости от домена. Вторая задача — разграничение доступа к интернету. При отсутствии связи с доменом, для того, чтобы никто не звонил, не писал, не заходил, не кричал, не плакал, я жертвую решением второй задачи, но я на 100% уверен, что решение первой задачи работает в прежнем режиме.
Насчет семи перечисленных… Насчет настройки Squid'а на работу с AD, я думаю, писать уже не стОит, ибо все давно написано. Очень хороший мануал есть у lissyara. Как пробросить пакеты мимо прокси средставми iptables — вроде тоже не очень сложная задача. А вот повышение отказоустойчивости с как можно меньшей стоимостью владения решением — это и есть тема топика :)
Насчет отличий локального и доменного режима.
Данный прокси вводился мной для решения задач более информационной безопасности, нежели администрирования, учета рабочего времени и т.п. Основная его задача — блокирование передачи файлов в интернет (через веб-формы, через mail.ru агент, через icq). Эти задачи выполняет iptables гипервизора в независимости от домена. Вторая задача — разграничение доступа к интернету. При отсутствии связи с доменом, для того, чтобы никто не звонил, не писал, не заходил, не кричал, не плакал, я жертвую решением второй задачи, но я на 100% уверен, что решение первой задачи работает в прежнем режиме.
Насчет семи перечисленных… Насчет настройки Squid'а на работу с AD, я думаю, писать уже не стОит, ибо все давно написано. Очень хороший мануал есть у lissyara. Как пробросить пакеты мимо прокси средставми iptables — вроде тоже не очень сложная задача. А вот повышение отказоустойчивости с как можно меньшей стоимостью владения решением — это и есть тема топика :)
Т.е. локальный режим разрешает доступ всем пользователям без авторизации, но с функцией блокировки?
Именно в данном случае — да. Естественно, никто не мешает накатать в качестве локального конфига что-то умопомрачительное, это вопрос времени и сил :) Хотелось рассказать и получить критику самой сути решения — пул прокси-серверов + переключение с уведомлением. Просто, как мне кажется, выпустить всех с блокировками гораздо лучше, чем, например, находясь на больничном или в отпуске, принять звонок со словами «у нас тут все поломалось, выходи срочно». А здесь — все работает и ждет своего часа. Все довольны.
>Автоматическое переключение между доменной и недоменной конфигурациями
Оно у вас запускается на каждом прокси сервере? Если нет — то получается, что реконфигурация запускается только на компьютере со скриптом. А другие сквиды работают с старым конфигом.
Оно у вас запускается на каждом прокси сервере? Если нет — то получается, что реконфигурация запускается только на компьютере со скриптом. А другие сквиды работают с старым конфигом.
У вас работает авторизация по kerberos, если пользователь находится в дружественном лесу, а не в основном?
> Изрядно намучившись с гуглом, различными продуктами и решениями, я подумал: «суть конфигурирования состоит в генерации файла squid.conf, на php мне как-то доводилось писать, а почему бы не реализовать веб-интерфейс самому?» Сказано — сделано.
А можно посмотреть, что сделано? Имею такие же проблемы с SAMS, думал в статье увидеть решение, а его там не оказалось. Спасибо
Это интерфейс в аскетическом стиле. Настройки хранятся в базе mysql. При нажатии ссылки «применить настройки» происходит генерирование файла squid.conf и реконфигурирование squid'а. Мне хватает :)
Скриншоты
Скриншоты
А не мог бы выложить iptables правила очень интересно посмотреть!
Правила блокирования передачи файлов? Или какие?
Да передачи файлов и балансировка
Балансировка — как в топике, только еще плюс
Где $GW_IP_2 — адрес интерфейса гипервизора, который смотрит в сеть прокси-серверов.
Про блокировку завтра напишу, сейчас под рукой нет, а наизусть не помню :)
iptables -t nat -A POSTROUTING --dst $PROXY_NET -p tcp --dport 3128 -j SNAT --to-source $GW_IP_2Где $GW_IP_2 — адрес интерфейса гипервизора, который смотрит в сеть прокси-серверов.
Про блокировку завтра напишу, сейчас под рукой нет, а наизусть не помню :)
Создаем цепочки для обработки:
Здесь сама логика обработки цепочек:
А вот так iptables понимает, что пакеты нужно направить в соответствующие цепочки:
iptables -N MRA_Packets
iptables -N ICQ_Packets
iptables -N WebForm_PacketsЗдесь сама логика обработки цепочек:
# MRA_Packets rules
iptables -A MRA_Packets -m u32 --u32 "52=0x26100000" -j LOG --log-prefix "MRA File Transferring: " --log-level 7
iptables -A MRA_Packets -m u32 --u32 "52=0x26100000" -j REJECT
# ICQ_Packets rules
iptables -A ICQ_Packets -m string --algo bm --hex-string '|09 46 13 43 4c 7f 11 d1 82 22 44 45 53 54 00|' -j LOG --log-prefix "ICQ File Transferring: " --log-level 7
iptables -A ICQ_Packets -m string --algo bm --hex-string '|09 46 13 43 4c 7f 11 d1 82 22 44 45 53 54 00|' -j REJECTА вот так iptables понимает, что пакеты нужно направить в соответствующие цепочки:
iptables -A INPUT -s 192.168.100.0/24 -m u32 --u32 "40=0xEFBEADDE" -j MRA_Packets
iptables -A OUTPUT -d 192.168.100.0/24 -m u32 --u32 "40=0xEFBEADDE" -j MRA_Packets
iptables -A INPUT -s 192.168.100.0/24 -m u32 --u32 "38&0xFFFF=0x2A02 && 46=0x00040006" -j ICQ_Packets
iptables -A OUTPUT -d 192.168.100.0/24 -m u32 --u32 "38&0xFFFF=0x2A02 && 46=0x00040007" -j ICQ_Packets
iptables -A INPUT -s 192.168.100.0/24 -m string --algo bm --string 'Content-Disposition: form-data; name="' -j WebForm_Packets
iptables -t nat -A PREROUTING -s 192.168.100.0/24 -m string --algo bm --string 'Content-Disposition: form-data; name="' -j WebForm_PacketsЗабыл логику для цепочки WebForm_Packets:
# WebForm_Packets rules
iptables -A WebForm_Packets -m string --algo bm --string 'filename=""' -j ACCEPT
iptables -A WebForm_Packets -m string --algo bm --string 'filename="' -j LOG --log-prefix "Uploading Packet: " --log-level 7
iptables -A WebForm_Packets -m string --algo bm --string 'filename="' -j REJECT
простите коллега, но чушь…
auth_param ntlm children = 200? не многовато? у меня 200 человек без проблемм на ntlm аутентификации сидят… если имеется ввиду проблема отвала домена с ошибкой в лог а ля…
libsmb/ntlmssp.c:342(ntlmssp_update)
got NTLMSSP command 1, expected 3
то она при компиляции самбы решается так…
/usr/ports/net/samba3/work/samba-3.0.37/source/libsmb/ntlmssp.c
строка 333.
Было:
if (ntlmssp_command != ntlmssp_state->expected_state) {
DEBUG(1, («got NTLMSSP command %u, expected %u\n», ntlmssp_command, ntlmssp_state->expected_state));
return NT_STATUS_INVALID_PARAMETER;
}
Стало:
if (ntlmssp_command != ntlmssp_state->expected_state) {
DEBUG(1, («got NTLMSSP command %u, expected %u\n», ntlmssp_command, ntlmssp_state->expected_state));
return NT_STATUS_OK;
}
сам долго мучался… грабли, но работает как часики
auth_param ntlm children = 200? не многовато? у меня 200 человек без проблемм на ntlm аутентификации сидят… если имеется ввиду проблема отвала домена с ошибкой в лог а ля…
libsmb/ntlmssp.c:342(ntlmssp_update)
got NTLMSSP command 1, expected 3
то она при компиляции самбы решается так…
/usr/ports/net/samba3/work/samba-3.0.37/source/libsmb/ntlmssp.c
строка 333.
Было:
if (ntlmssp_command != ntlmssp_state->expected_state) {
DEBUG(1, («got NTLMSSP command %u, expected %u\n», ntlmssp_command, ntlmssp_state->expected_state));
return NT_STATUS_INVALID_PARAMETER;
}
Стало:
if (ntlmssp_command != ntlmssp_state->expected_state) {
DEBUG(1, («got NTLMSSP command %u, expected %u\n», ntlmssp_command, ntlmssp_state->expected_state));
return NT_STATUS_OK;
}
сам долго мучался… грабли, но работает как часики
У нас в свое время прокси такого типа (squid+squidbalance+sams+AD) на более слабой машине и обслуживал более 200 клиентов и работал нормально.
Так что с вашей машиной «компьютер CPU Core i3/RAM 4 Gb/HDD 500 Gb;» вообще не должно было быть проблем с нормальной настройкой.
А по трафику у вас нет ограничений и по скорости?
Так что с вашей машиной «компьютер CPU Core i3/RAM 4 Gb/HDD 500 Gb;» вообще не должно было быть проблем с нормальной настройкой.
А по трафику у вас нет ограничений и по скорости?
Здесь тоже работал нормально на более слабой машине.
Я сделал запас ресурсов из-за постоянно появляющихся новых пользователей.
По трафику и скорости ограничений нет.
Я сделал запас ресурсов из-за постоянно появляющихся новых пользователей.
По трафику и скорости ограничений нет.
В вашем случае проверялась принадлежность пользователя группе? Или каждой конкретной пользовательской доменной учетной записи можно было назначить свои права и привилегии, отличающиеся от тех, которые были предоставлены группе, членом которой он является?
по группам, привилегии у нас были по IP+MAC, да и давно было уже.
А в моем случае привязка прав идет к группе+логину. Доступ к социальным сетям, почтовым серверам, файлообменникам ограничен. И вообще, руководителями выдвигаются различные требования к привилегиям доступа их сотрудников.
IP-адрес как критерий отбора я сразу отбросил, потому что на DHCP он уже не критерий.
MAC'и тоже есть как критерии, но у iptables на гипервизоре.
В общем, разобрались, куда память уходит :)
IP-адрес как критерий отбора я сразу отбросил, потому что на DHCP он уже не критерий.
MAC'и тоже есть как критерии, но у iptables на гипервизоре.
В общем, разобрались, куда память уходит :)
ntlm это прошлый век, kerberos лучше использовать
Никогда не встречал «белых» MAC-адресов =)
Устойчивая фраза «белый адрес» в моём понимании — глобально маршрутизируемый IP адрес.
Ошибка или некорректное использование «термина»? Работаю с сетями и эта фраза ой как глаз режет.
Правильно ли я понял, что все прокси выходят в интернет под одним IP адресом? Т.е. прокси имеют серый IP адрес на внешнем интерфейсе и потом пограничный маршрутизатор их NAT`ит?
Если на разных прокси будет настроен свой белый IP адреса, то будет плохо работать. Веб-сервера в интернете будут получать запрос с разных IP адресов для одной сессии пользователя, а многие привязывают сессию к IP адресу… СтОит добавить в текст.
Устойчивая фраза «белый адрес» в моём понимании — глобально маршрутизируемый IP адрес.
Ошибка или некорректное использование «термина»? Работаю с сетями и эта фраза ой как глаз режет.
Правильно ли я понял, что все прокси выходят в интернет под одним IP адресом? Т.е. прокси имеют серый IP адрес на внешнем интерфейсе и потом пограничный маршрутизатор их NAT`ит?
Если на разных прокси будет настроен свой белый IP адреса, то будет плохо работать. Веб-сервера в интернете будут получать запрос с разных IP адресов для одной сессии пользователя, а многие привязывают сессию к IP адресу… СтОит добавить в текст.
А как в такой реализации выглядела авторизация со стороны клиента. Я так понимаю сквозная авторизация не работает? То есть открывая браузер нужно еще и логин с паролем вводить, но только доменные? А если сдохло AD, то логин с паролем те-же? Если нет, то как пользователи должны об этом узнать? Если да, то как вы дублируете пароли из AD?
А про падения AD вы говорите так, как будто оно раз в неделю происходит. На моей памяти еще ни один DC не падал, и при этом их всегда было минимум два. А что до разделения обязанностей, так оно много где так. Должна быть плотная и постоянная коммуникация между сотрудниками/отделами/компаниями-оутсорсерами.
А про падения AD вы говорите так, как будто оно раз в неделю происходит. На моей памяти еще ни один DC не падал, и при этом их всегда было минимум два. А что до разделения обязанностей, так оно много где так. Должна быть плотная и постоянная коммуникация между сотрудниками/отделами/компаниями-оутсорсерами.
> А как в такой реализации выглядела авторизация со стороны клиента.
> А если сдохло AD, то логин с паролем те-же?
Комментарий выше
> А что до разделения обязанностей, так оно много где так. Должна быть
А деятельность законодательной, исполнительной и судебной властей должна быть направлена на защиту интересов граждан государства. Аналогию можете провести сами.
> А если сдохло AD, то логин с паролем те-же?
Комментарий выше
> А что до разделения обязанностей, так оно много где так. Должна быть
А деятельность законодательной, исполнительной и судебной властей должна быть направлена на защиту интересов граждан государства. Аналогию можете провести сами.
/usr/bin/ntlm_auth…
if [ $? != 0 ]; then
Сам так раньше писал. Но в shell-скриптах можно проще и красивее:
срабатывает, как раз когда код возврата ($?) не равен 0
if [ $? != 0 ]; then
Сам так раньше писал. Но в shell-скриптах можно проще и красивее:
if ! /usr/bin/ntlm...... ;thenсрабатывает, как раз когда код возврата ($?) не равен 0
А вот ктобы подсказал, как сделать отказоустойчивый кластер из squid с Kerberos аутентификацией… Пока сделал через 3 сквида, один из которых child с ACL и авторизацией и 2 parent, к которым не разрешен доступ напрямую.
Вот только failover тут нету никакого — падает child прокси и все…
Вот только failover тут нету никакого — падает child прокси и все…
А если по такому же принципу? ACL в отдельном месте, дети получают доступ к ним по сети, а от клиентов такой же разброс на child'ов?
Sign up to leave a comment.
Отказоусточивый прокси-сервер на базе Squid в домене Windows