Мне интерестно, а что если сделать такую штуку:1. Авторизация в SQUID'е происходит внешними модулями (например как тут http://www.opennet.me/base/net/win_domain_squid.txt.html)
2. Скрипт заносит /var/squid/access.log в БД (вариантов это сделать тоже много, например как это сделанно сдесь http://sourceforge.net/projects/squid-traffic)
3. В БД происходит агрегация по нужным параметрам (дата, пользователь, ip пользователя), а также подсчет лимитов.
4. А вот лимиты прикрутить к SQUID как external_acl_type. С помощью этого acl и банить пользователя (за исчерпания лимитов)
5. панель управления, отчеты, как водиться, через ВЕБ.
Как вам идея?
ЗЫ Ну, у меня каникулы до 9 числа, рискую успеть набросать.
ЗЫ ЗЫ А может что-то такое уже есть - тогда киньте ссылку, плиз
Попробую по подробнееМне нужно решение, не только авторизации по пользователям в домене, но и лимитировании.
Готовое решение я не нашел, а пост (хоть и старый) http://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi?quote... привел меня к мысле, что решения пока нет.>1. Авторизация в SQUID'е происходит внешними модулями (например как тут http://www.opennet.me/base/net/win_domain_squid.txt.html)
Я думал над тем, чтоб, проверку на лимиты засунуть в auth_helper, т.е.
Сначала проверить логин-пароль пользователя домена в AD, потом проверить его лимиты и, основываясь на этом, решать прошел он аутентификацию успешно или нет.Мне не нравиться:
1. Для случая Win2k домена нужна обертка для ntlm_auth, либо его модификация (вобщем то, не очень страшно)
2. Если юзверь исчерпал лимит, то он получет ответ access dained. По моему, в случае срабатывания ACL можно, отправить его на страничку где явно сказано, что он исчерпал лимит
(вобщем то, тоже не очень страшно, но сделает жизнь юзверя понятней:-)>
>2. Скрипт заносит /var/squid/access.log в БД (вариантов это сделать тоже много, например
>как это сделанно сдесь http://sourceforge.net/projects/squid-traffic)Такой способ избавляет от pipe'оф и не приводит к падению сквида, когда тот не может записать лог в файл, вместе с тем, есть какой-то элемент реального времени.
Обычно, в БД таких программ есть отдельная таблица с пользователями, нового пользоватля можно занести сюда в момент обработки строки с логами (именно так у меня сейчас и происходит:). Ведь, если его пустили через логин-пароль - то он, как бы, имеет право пользоваться инетом, а так как в БД нет информации о нем, то он им еще и не пользовался... (ой страшно не пиннайте:-). Лимиты ему можно поставить для начала "по умолчанию".
>3. В БД происходит агрегация по нужным параметрам (дата, пользователь, ip пользователя),
>а также подсчет лимитов.Сдесь, думаю поятно, хочешь триггерами, хочешь скриптом проводи аггрегацию.
Лично мне нужены дата и логин, и лимиты. Короче все что нужно для отчетов.>4. А вот лимиты прикрутить к SQUID как external_acl_type. С помощью этого
>acl и банить пользователя (за исчерпания лимитов)Тут мне интерестно, что можно написать как угодно много (скакими хочешь параметрами) acl (хотя в большинстве случаев можно обойтись и обычными сквидовскими ACL'ми), и извавляет от пункта 1.1
Плюс, лично мне не нравиться подход править конфиг squid'а программами как это сделанно в том же http://sourceforge.net/projects/squid-traffic
Я делал такую систему лет пять тому назад, все было собрано из перла, мускля, шелла и крона. Обрабатывались лимиты по времени работы и траффику. Нормально проработало около двух лет и сдохло за ненадобностью. Шейпинг канала делей-пулами, отсечка больших файлов и доступ руководства к отчетам SARG оказались менее геморройным и более эффективным подходом, чем введение "талонов на интернет".
>Я делал такую систему лет пять тому назад, все было собрано из
>перла, мускля, шелла и крона. Обрабатывались лимиты по времени работы и
>траффику. Нормально проработало около двух лет и сдохло за ненадобностью. Шейпинг
>канала делей-пулами, отсечка больших файлов и доступ руководства к отчетам SARG
>оказались менее геморройным и более эффективным подходом, чем введение "талонов на
>интернет".Вот я тоже подумал нагруженный прокси потребует большой и быстрой БД - иначе нет смысла.
Вот и думаю есть ли смысл, делать что-такое...
>Вот я тоже подумал нагруженный прокси потребует большой и быстрой БД -
>иначе нет смысла.
>
>Вот и думаю есть ли смысл, делать что-такое...если подружить процессы логера в БД (работающего через pipe со сквидом) и редиректора, который осуществляет проверку лимитов пользователей то нагрузка на БД меньше, чем при прямом доступе редиректора к БД.
т.е. суть в следующем:
1. процесс логера валит лог в БД (а можно обойтись и вовсе без БД :) ), и сообщает информацию о загруженном ресурсе процессу редиректора (вариантов много).
2. процесс редиректора содержит пул пользовательских записей (логин, лимит, текущий счетчик, время последнего обращения). Если пользователя нет в пуле то информация о нем загружается из БД или других источников (например логин и лимит брать из LDAP). мертвые учетки из пула можно периодически удалять.
P.S.
При такой реализации сложность возникает только в написании редиректора (особенно многопоточного). Особого внимания заслуживает процесс оптимизации взаимодействия хранилища статистики (БД, файлы) и компонентов системы (логер + редиректор)
>Мне интерестно, а что если сделать такую штуку:
>
>1. Авторизация в SQUID'е происходит внешними модулями (например как тут http://www.opennet.me/base/net/win_domain_squid.txt.html)
>
>2. Скрипт заносит /var/squid/access.log в БД (вариантов это сделать тоже много, например
>как это сделанно сдесь http://sourceforge.net/projects/squid-traffic)
>
>3. В БД происходит агрегация по нужным параметрам (дата, пользователь, ip пользователя),
>а также подсчет лимитов.
>
>4. А вот лимиты прикрутить к SQUID как external_acl_type. С помощью этого
>acl и банить пользователя (за исчерпания лимитов)
>
>5. панель управления, отчеты, как водиться, через ВЕБ.
>
>Как вам идея?
>
>ЗЫ Ну, у меня каникулы до 9 числа, рискую успеть набросать.
>
>ЗЫ ЗЫ А может что-то такое уже есть - тогда киньте ссылку,
>плиз
Всё уже спиз.... написано до нас - http://sams.irc.perm.ru/.