Обсуждение статьи Дмитрия Кругликова (Squid+SARG+Rejik)
Обсуждение статьи Дмитрия Кругликова (Squid+SARG+Rejik)
Обсуждение статьи Дмитрия Кругликова "Прекращение доступа в Инет по превышению установленного лимита. (Squid+SARG+Rejik)
Re: Обсуждение статьи Дмитрия Кругликова (Squid+SARG+Rejik)
А где можно почитать саму статью?Slava писал(а):Обсуждение статьи Дмитрия Кругликова "Прекращение доступа в Инет по превышению установленного лимита. (Squid+SARG+Rejik)
swoop
Re: Обсуждение статьи Дмитрия Кругликова (Squid+SARG+Rejik)
В разделе "Статьи" http://rejik.ru/830/index.htmlSerg писал(а):А где можно почитать саму статью?Slava писал(а):Обсуждение статьи Дмитрия Кругликова "Прекращение доступа в Инет по превышению установленного лимита. (Squid+SARG+Rejik)
Мне кажется слижком уж непродуманный метод.
Для блокировки по превышению лимита есть множество других,
более продуманных, гибконастраиваеммых программ.
Задачи у rejik совсем другие
Почему бы не использовать для отслеживания превышения
например netams?
Автору - дольнейших творческих успехов и привте земляку с далёкого севера Я родился в Полтаве 
Для блокировки по превышению лимита есть множество других,
более продуманных, гибконастраиваеммых программ.
Задачи у rejik совсем другие
Почему бы не использовать для отслеживания превышения
например netams?
Автору - дольнейших творческих успехов и привте земляку с далёкого севера
Я родился в Полтаве Re: Обсуждение статьи Дмитрия Кругликова (Squid+SARG+Rejik)
Чисто мое мнение!Slava писал(а):Обсуждение статьи Дмитрия Кругликова "Прекращение доступа в Инет по превышению установленного лимита. (Squid+SARG+Rejik)
1. У SARG (вообще вещь хорошая, ее и пользуюсь) основная фукция другая и соответственно не эффективно его использовать с этой целью.
2. Для ограничения лимита не нужен ни Rejik ни Sarg. Достаточно того что есть логи Squid и перл на котором можно писать скрипты.
Скрипт я написал и cron запускал его каждые 5 минут и все работает.
Проблема в другом у меня более 300 пользователей а трафик за сутки порядка 1,5-2Гб. Соответственно access.log за месяц накапливается около 1,5Гб и концу месяца скрипт требует больше и больше времени т.к. лог просматриваетя с начала при этом тормозит и Squid.
Разбивать лог меньше чем месяц не могу. Нужна суммарная статистика за месяц.
По хорошему надо запоминать позицию в файле access.log, накопленные данные о лимитах и в следующий раз продожать с запомненой позиции. Но не знаю как это сделать в перле и можно ли вообще.
Может кто подскажет?
swoop
www.netams.com
Продукт разрабатывают наши ребята, он полностью бесплатен.
Работает как BSD, так и с Linux, Solaris
Русский форум.
Продукт разрабатывают наши ребята, он полностью бесплатен.
Работает как BSD, так и с Linux, Solaris
Русский форум.
Re: Обсуждение статьи Дмитрия Кругликова (Squid+SARG+Rejik)
Для подсчёта статистики через sarg я использую скрипт sarg-reports от2. Для ограничения лимита не нужен ни Rejik ни Sarg. Достаточно того что есть логи Squid и перл на котором можно писать скрипты.
Скрипт я написал и cron запускал его каждые 5 минут и все работает.
Проблема в другом у меня более 300 пользователей а трафик за сутки порядка 1,5-2Гб. Соответственно access.log за месяц накапливается около 1,5Гб и концу месяца скрипт требует больше и больше времени т.к. лог просматриваетя с начала при этом тормозит и Squid.
Разбивать лог меньше чем месяц не могу. Нужна суммарная статистика за месяц.
По хорошему надо запоминать позицию в файле access.log, накопленные данные о лимитах и в следующий раз продожать с запомненой позиции. Но не знаю как это сделать в перле и можно ли вообще.
Может кто подскажет?
Ugo Viti http://www.i-synapse.it
Очень удобно. Особенно если ротация логов раз в месяц. В принципе так он и расчитан
Запоминать позицию в файле логов и не нужно.
Удобнее складывать статистику в БД и оттуда её использовать.
На таком принципе работает netams. Он считает, разбирается с квотами (как по пользователям, так и по группам), выводитрезультат через сгенерированные странички. Как говорится котлеты отдельно, мухи отдельно.
SQUID - прокси, REJIK - расправляется с баннерами и порно (и т.д.),
NETAMS - считает трафик, ограничивает скорость (если нужно), следит за квотами и т.д. SARG - выводит отчёты о трафике через прокси-сервер. Все довольны и наблюдают свои кртинки, графики, странички (но не чужие
)Как альтернативу SARG-у, запустил с ним параллельно
awstats. Очень занимательная штука, парсит кучу разных логов,
форматы логов можно указывать вручную, ибо не все логи выводят результаты в одинаковом виду и формате. Поддерживает логи прокси, вэб-сервреа, почтовые и проч. http://awstats.sourceforge.net/
Самая беда в том, что сквид делает запись о скачанном объекте в аксесс.лог только после полного стягивания оного (объекта). Патч, гуляющий в инете, на тему писать лог о скачке объекта кусками, ни фига не работает. И по этому всевозможные проекты на предмет ограничения по лимиту на базе кальмара, ИМХО, не рабочие.
Перед мною эта задача стояла года два назад
пользователей около 100
ходили они в инет через SQUID
я написал на perl-ле 3 скрипта
подправил файл паролей
файл паролей имел вид
login_user : cript_password : лимиты : принадлежность к группе
скрипты имели две своих директории и общий файл конфига
-одна папка логов:
user.log и user.size для каждого пользователя
-вторая для отчетов:
user.html -для каждого пользователя
index.html - сумарной статистики
причем обе эти папки находились в пути вида /год/месяц/
1-й скрипт
через cron запускался каждые 5 мин
при старте давал SQUID-у сигнал ему USER1 ( аналогично squid -k reconfigure ) на ротацию файлов лога после чего access.log.1 он копировал в свою директорию а родной access.log.1 обнулялся
далее копия лога построчно читалась и каждая строка разбиралась добавлялись пользователю байты и время в файл user.size
далее строка в чуть измененном виде дописывалась в user.log
в конце перечитывались все user.size и читался файл паролей и при превышении лимита файл паролей правился (пользователь отключался)
Такая схема обработки на мой взгляд имеет следующие
преимущества
- скрипт можно запускать как-угодно часто если часто запускать файл лога маленький и быстро обрабатывается (зачем обрабатывать одно и тоже каждых 5 мин !!!) ели запускать через большие интервалы то обрабатываться будет дольше
- есть готовый лог для каждого пользователя
- есть байты и время для каждого пользователя
- скрипт седал не много ресурсов сервера
недостатки
- ели пользователь начал закачку большого файла и она незакончилась до момента ротации файлов лога она продолжится закачку не прервать !
2-й скрипт
формировал отчеты запускался раз в сутки по cron-ну(можно запускать произвольно) и из файлов пользователей user.log строил user.html и общую статистику по пользователям, дизайн я у кого-то слизал
1-го числа нового месяца лимиты пользователей возобновлялись автоматически
3-й скрипт
административный работал только с файлом паролей
позволял заводить новых пользователей и новые группы
оределять администратора как общего так и на группу
админ группы не мог раздать лимитов больше чем назначил общий админ на группу
позволял пользователям менять свои пароли и просматривать свои логи
эта ситема работает уже давно без особых замечаний хотя остались некоторые мелкие недоработки но у меня уже нет желания её выводить в ноль
Не судите строго я только хотел поделиться своим методом решения по ограничению установленного лимита, кому интересно могу выслать скрипты
пользователей около 100
ходили они в инет через SQUID
я написал на perl-ле 3 скрипта
подправил файл паролей
файл паролей имел вид
login_user : cript_password : лимиты : принадлежность к группе
скрипты имели две своих директории и общий файл конфига
-одна папка логов:
user.log и user.size для каждого пользователя
-вторая для отчетов:
user.html -для каждого пользователя
index.html - сумарной статистики
причем обе эти папки находились в пути вида /год/месяц/
1-й скрипт
через cron запускался каждые 5 мин
при старте давал SQUID-у сигнал ему USER1 ( аналогично squid -k reconfigure ) на ротацию файлов лога после чего access.log.1 он копировал в свою директорию а родной access.log.1 обнулялся
далее копия лога построчно читалась и каждая строка разбиралась добавлялись пользователю байты и время в файл user.size
далее строка в чуть измененном виде дописывалась в user.log
в конце перечитывались все user.size и читался файл паролей и при превышении лимита файл паролей правился (пользователь отключался)
Такая схема обработки на мой взгляд имеет следующие
преимущества
- скрипт можно запускать как-угодно часто если часто запускать файл лога маленький и быстро обрабатывается (зачем обрабатывать одно и тоже каждых 5 мин !!!) ели запускать через большие интервалы то обрабатываться будет дольше
- есть готовый лог для каждого пользователя
- есть байты и время для каждого пользователя
- скрипт седал не много ресурсов сервера
недостатки
- ели пользователь начал закачку большого файла и она незакончилась до момента ротации файлов лога она продолжится закачку не прервать !
2-й скрипт
формировал отчеты запускался раз в сутки по cron-ну(можно запускать произвольно) и из файлов пользователей user.log строил user.html и общую статистику по пользователям, дизайн я у кого-то слизал
1-го числа нового месяца лимиты пользователей возобновлялись автоматически
3-й скрипт
административный работал только с файлом паролей
позволял заводить новых пользователей и новые группы
оределять администратора как общего так и на группу
админ группы не мог раздать лимитов больше чем назначил общий админ на группу
позволял пользователям менять свои пароли и просматривать свои логи
эта ситема работает уже давно без особых замечаний хотя остались некоторые мелкие недоработки но у меня уже нет желания её выводить в ноль
Не судите строго я только хотел поделиться своим методом решения по ограничению установленного лимита, кому интересно могу выслать скрипты
Судя по описания, хорошая штука Squid Traffic Counter. http://stc.nixdev.org/
Скоро буду пробовать.
Скоро буду пробовать.
Ну во первых:
squid -k reconfigure иногда может гробить открытые сессии пользователей, поэтому постоянное дерганье конфига приводит к тому, что зачастую невозможно докачать файлы большого размера!
Во вторых:
SARG - штука весьма и весьма сырая! На нестандартных запросах его можно запросто валить в кору! Соответственно работать такая схема будет криво и потенциально имеет дыру! (Отвлеченно: неужели автору сарга так сложно написать нормальную парсилку лога Она на обычном перле за 5 минут пишется!)
На мой взгляд правильным решением будет написать второй фильтр для сквида (первый это режик), который статистику и лимиты читает из файлов!
Если пойти дальше, я бы сделал коллектор на базе файрвольных правил на 3128 порт! Раз в минуту проверяются файрвольные счетчики, и при достижении определенного лимита создаются на диске файлы с именем "IP адрес юзера". Фильтром же при запросе проверяется наличие этого файла на диске! Во первых это работает быстро, во вторых мы не теряем оборванные сессии! Ночью очищаются счетчики и файлы созданные в течение дня.
А если пойти еще дальше!! То самым лучшим решением будет
написать скрипт который работает исключительно с файрвольными правилами и тогда отрубать пользователя можно будет прямо на лету, меняя файрвольное правило, и не давая докачивать 200 меговый файл имея всего 10 мег в лимите! Кстати, что бы пользователи имели возможность узнать причину их отключения - вместо запрета доступа редиректите их на любой сервак который захотите и там выдавайте любое предупреждение или высвечивайте его личную статистику! такой скрипт отрабатывает очень быстро и дергать его можно по крону хоть каждую минуту!
По поводу нетамс! Всячески рекомендую! По моему мнению очень логично продумана система хранения статистики! Однако у них есть один минус! Им не хватает что бы конфиги правил и юнитов хранились в базе данных наравне со статистикой! Это в значительной степени облегчило бы интеграцию с другими приложениями! А так... если не придираться - приятный продукт!
squid -k reconfigure иногда может гробить открытые сессии пользователей, поэтому постоянное дерганье конфига приводит к тому, что зачастую невозможно докачать файлы большого размера!
Во вторых:
SARG - штука весьма и весьма сырая! На нестандартных запросах его можно запросто валить в кору! Соответственно работать такая схема будет криво и потенциально имеет дыру! (Отвлеченно: неужели автору сарга так сложно написать нормальную парсилку лога
Она на обычном перле за 5 минут пишется!)На мой взгляд правильным решением будет написать второй фильтр для сквида (первый это режик), который статистику и лимиты читает из файлов!
Если пойти дальше, я бы сделал коллектор на базе файрвольных правил на 3128 порт! Раз в минуту проверяются файрвольные счетчики, и при достижении определенного лимита создаются на диске файлы с именем "IP адрес юзера". Фильтром же при запросе проверяется наличие этого файла на диске! Во первых это работает быстро, во вторых мы не теряем оборванные сессии! Ночью очищаются счетчики и файлы созданные в течение дня.
А если пойти еще дальше!! То самым лучшим решением будет
написать скрипт который работает исключительно с файрвольными правилами и тогда отрубать пользователя можно будет прямо на лету, меняя файрвольное правило, и не давая докачивать 200 меговый файл имея всего 10 мег в лимите! Кстати, что бы пользователи имели возможность узнать причину их отключения - вместо запрета доступа редиректите их на любой сервак который захотите и там выдавайте любое предупреждение или высвечивайте его личную статистику! такой скрипт отрабатывает очень быстро и дергать его можно по крону хоть каждую минуту!
По поводу нетамс! Всячески рекомендую! По моему мнению очень логично продумана система хранения статистики! Однако у них есть один минус! Им не хватает что бы конфиги правил и юнитов хранились в базе данных наравне со статистикой! Это в значительной степени облегчило бы интеграцию с другими приложениями! А так... если не придираться - приятный продукт!
Последний раз редактировалось A_I_M Пн фев 07, 2005 0:27, всего редактировалось 2 раза.
Ну смотря насколько критична точность такого ограничения...as писал(а):Самая беда в том, что сквид делает запись о скачанном объекте в аксесс.лог только после полного стягивания оного (объекта). Патч, гуляющий в инете, на тему писать лог о скачке объекта кусками, ни фига не работает. И по этому всевозможные проекты на предмет ограничения по лимиту на базе кальмара, ИМХО, не рабочие.
1. На закачку больших объектов обычно ставится узкая полоса через dalay pools...
2. Кроме техничеких мер, есть еще и административные... можно на пару месяцев вообще человеку инет отрубить...