Все, что написано в данной статье, работает, удобно для меня и нравится мне. Вы можете настроить свою систему так же, или подобным образом, но я не несу ответственности за то, что у вас что-либо не получится, или будет работать не так, как вам того хотелось. Так же я врядли смогу сказать, почему у вас что-либо не получилось, так как каждая Юникс-система отлична от других. Я не Гуру и не хакер. Просто у меня получилось то, что я хотел, и может быть вам повезет так же, как и мне.

Постановка задачи:

Sarg имеет великолепную возможность вытягивать из access.log Squid-а информацию об имени пользователя или IP-адресе рабочей станции, которая посягнула на святое, на наш, сисадминский трафик. Так же, оный sarg умеет складывать в указанный файл эти имена или адреса, при достижении ими определенного лимита. К сожалению, нет возможности указывать лимит для каждого пользователя или станции. Но мне этого не нужно, а вам придется выполнять магические приседания самостоятельно, если захотите.

И так, мы можем получить список провинившихся.

Однообразия ради я заставил sarg вести учет только адресов рабочих станций, для того, чтобы Rejik не ругался, так как смешанный файл он не понимает. Вы можете настроить sarg таким образом, чтобы он вел учет только имен, но на вашей совести остается обеспечение условия единообразия, или имена, или адреса!

Для того, чтобы отчеты самого sarg остались в удобочитаемом виде, я создал файл с именами рабочих станций. Меня это устроило. Таким образом, sarg выполняет свои функции.

У меня по cron каждые 15 минут запускается специальный скрипт, который перенаправляет вывод sarg в /dev/null, иначе они сыпятся в почтовый ящик, что несколько надоедает. Отключать же отладочный вывод неинтересно, так как редко, но приходится звать sarg из командной строки, и этот самый вывод читать...

Если вдруг свершилось, и sarg отловил виноватого в превышении лимита, то нужно известить Rejik об этом счастливом событии. Не мудрствуя лукаво я добавил в скрипт запуска sarg строку реконфигурации squid.

Получилось следующее:
    server# cat /usr/local/bin/Sarg

    #! /bin/sh
    /usr/local/bin/sarg 2> /dev/null
    squid -k reconfigure

Если запускать этот скрипт по cron строкой:
    */15 8-20 * * 1-5 root /usr/local/bin/Sarg

То каждые 15 минут, с 8 по 20 часов с понедельника по пятницу у нас будет обновляться статистика sarg и проверяться условие достижения лимита на каждую рабочую станцию. И при этом "передергиваться" squid и rejik. Остается проблема "перекачки" за эти самые 15 минут, но меня она не сильно огорчает. Вы же можете сократить интервалы запуска Sarg до разумного предела, то есть, до 1 минуты:
    */1 * * * * root /usr/local/bin/Sarg
Но кто из нас страдает паранойей? :)

После всех этих приседаний появилась некоторая проблема: с ростом файла access.log время обработки этого файла стало слишком большим. Я просто включил его в систему ротации логов, которую описывать не стану, так как они различаются в разных системах. Так же к ротации логов я подключил и файл со списком виноватых.

ЗАМЕЧАНИЕ:

При ротации лог-файлов некоторые системы пишут в первой и последней строке время, дату и всякую другую информацию о том, что этот файл был обновлен. Читайте man на вашу систему, делайте что хотите, но в файле со списком IP-адресов для rejik текстовых строк быть не должно, иначе ваш squid рухнет. (Проверено на собственной шкуре, именно в тот день, когда я взял отгул).

Я написал:
    /var/log/squid/access.log nobody:nogroup 644 7 * @T00 B
    /var/log/squid/users.limit nobody:nogroup 644 5 * @T00 B
в /etc/newsyslog.conf, что справедливо только для FreeBSD. В Linux у вас будет logrotate или еще что-нибудь.

Таким образом мы получили ежедневную статистику sarg на нашем локальном сайте, который у нас должен быть, хотя бы для того, чтоб выложить на нем странички для rejik которые весьма любезно сообщают нашим пользователям о том, что порнухи им больше не видать. В дополнение к страничкам, идущим в поставке rejik я написал еще одну, о превышении лимита. Так же я немного подправил существующие странички с предупреждением о том, что обжалование действий системного администратора может привести к полному отсутствию Инета для данной машины .... Но это уже не имеет отношения к сегодняшней теме.

Собственно, настройки sarg

Нам нужно изменить всего три строки из тех, которые у вас должны быть настроены:
    user_ip yes # использовать IP вместо имен пользователей.

    per_user_limit /var/log/squid/users.limit 2 # файл, куда прописываются адреса машин, превысивших лимит 2М

usertab /usr/local/etc/sarg/names # файл, где прописаны имена, соответствующие ip-адресам в формате 192.168.1.1 Vasiliy_Pupkin

Теперь перейдем к настройкам regik-а

Надеюсь, что он у вас установлен, и уже настроен для банеров и порносайтов.

Нам необходимо добавить секцию:
    <LIMIT>
    ban_dir /usr/local/rejik3/banlists/limit
    url http://your.server.com/ban/limit.html
    work_ip f:/var/log/squid/users.limit
    reverse

По сравнению с остальными секциями у нас добавились две строки:

    work_ip f:/var/log/squid/users.limit
Это список адресов, который нам любезно предоставил sarg. Если вы решили использовать имена вместо адресов, то напишите:
    work_id f:/var/log/squid/users.limit

    reverse
А это разрешение ходить на сайты, прописаные в правилах ban_dir /usr/local/rejik3/banlists/limit. Тут у нас должны быть прописаны адреса как минимум нашего сервера, где лежит страничка с уведомлением о том, что Инет кончился.

В файле /usr/local/rejik3/banlists/limit/urls я рекомендую прописать:
    127.0.0.1
    192.168.1.1
    192.168.1.2
    .yuor.domain.com
То есть, те адреса, куда доступ должен быть предоставлен в случае превышения лимита. Если вы нашли способ создавать два файла, с именами и адресами отдельно, то напишите две секции, для имен и адресов соответственно. Так же вы можете поплясать с бубном и создать различные настройки для ограничений в 1М, 2М, 3М соответственно, если сможете ... Я так не утруждался ...

Не забудьте передернуть sarg и squid... Должно работать.

C наилучшими пожеланиями,
Дмитрий Кругликов
master [собака] kernel.pl.ua
Украина, Полтава.