@ Карта сайта News Автора!

Bog BOS: Squid (кеширующий прокси для http): установка, настройка и использование

apache inn MySQL nntpcache Cyrus IMAP exim Squid ssh syslog tacacs ProFTPD wu-ftpd xntpd

Последние изменения:
2024.11.22: sysadmin: systemd-journald (централизованное хранение)
2024.11.11: sysadmin: Linux: пространства имён
2024.11.06: sysadmin: настройка TCP/IP в Linux: виртуальный интерфейс и виртуальный мост
2024.10.25: sysadmin: Linux VFS, атрибуты, расширенные атрибуты, ACL

Последнее изменение файла: 2024.01.23
Скопировано с www.bog.pp.ru: 2024.11.23

Bog BOS: Squid (кеширующий прокси для http): установка, настройка и использование

WWW  -> proxy/кеш -> Squid

Назначение

Представляет собой HTTP, FTP, gopher, SSL и WAIS (убрано в 2.6) proxy, кеширующий запросы. Также кеширует DNS. Один процесс на всех, неблокированный ввод/вывод, держит часто используемые объекты в виртуальной памяти. Бесплатен (GPL). Основан на проекте Harvest. Поддерживает иерархию или сеть серверов (ICP/UDP - Internet Cache Protocol, HTCP/TCP, multicast). Откуда брать объект определяется так (в упрощенном виде): послать ICP/HTCP/multicast запросы ко всем подходящим соседям; подождать определенное время; загрузить с первого соседа, пославшего HIT; иначе загрузить с первого отца, ответившего MISS; иначе загрузить с первоисточника. Предусмотрены различные методы оптимизации для выбора наиболее быстрого источника.

Делается различие между частными и общими объектами. Кешируются только общие объекты. Только метод GET дает общие объекты. Объекты, попавшие в стоп-лист есть частные объекты. Если запрос содержит аутентификационную информацию или ответ типа "401 Unauthorized" - это частный объект.

cache digest - очень компактная форма представления какие объекты имеются в кеше. Кеши могут обмениваться этой информацией с соседями, чтобы избежать необходимости делать ICP-запросы. В качестве ключей объектов используется MD5.

Текущая стабильная версия: Squid 3.0-STABLE24 (переписано на C++, официально добавлен ICAP), Squid 2.7-STABLE8, Squid 2.6-STABLE23; готовится к выходу 3.1 (отличия 2.7.STABLE8 от 2.6.STABLE23, 2.6.STABLE23 от 2.6.STABLE16, 2.6.STABLE16 от 2.6.STABLE12, 2.6.STABLE12 от 2.5.STABLE14, 2.5.STABLE14 от 2.5.STABLE6, 2.5.STABLE6 от 2.4, 2.4 от 2.3, 2.3 от 2.2).

Установка
Squid 2.6.STABLE21, Linux CentOS 5.4, x86_64, из пакетов
Squid 2.6.STABLE16, Linux CentOS 5.0 (головной для филиалов)
Squid 2.6.STABLE12, Linux CentOS 4.4 (головной для филиала)
Squid 2.5.STABLE6, Linux CentOS 4.0/4.4 (без излишеств)
Squid 2.5-PRE6, Linux RedHat 7.2 (transparent, балансировка нагрузки, антибаннер)
Squid 2.3-STABLE4, Linux RedHat 7.0 (два сервера: распасовщик и антибаннер)
Squid 2.3-STABLE2, Linux RedHat 6.2 (transparent proxy)
Squid 2.3-STABLE1, Linux RedHat 6.0 (распасовочный)
Squid 2.2-STABLE4, Linux RedHat 6.0, из rpm
Squid 2.2-STABLE2, Solaris 2.5, Sparc

Полезные ключи ./configure (--help, squid -v)

Ключи запуска squid

Формат squid.conf

Управление squid (Cache Manager)

Настройка прав доступа в squid.conf:

Управление squid с помощью программы client: /usr/local/squid/bin/client cache_object://localhost/команда

Управление squid с помощью cachemgr.cgi (лично я не пробовал и другим не советую):

Сколько надо оперативной памяти

Требования к памяти:

Причем большая часть используемой памяти не должна свопироваться (иначе работает безумно медленно). Например, при кеше в 7 ГБ (800 тысяч объектов) требуется 128 МБ оперативной памяти. При восстановлении оглавления кеша (после аварийной перезагрузки) требуется удвоенный объем.

Как уменьшить потребности:

Алгоритмы замещения кеша (LRU, GDSF, LFUDA)

Squid поддерживает размер кеша между low и high, регулярно запуская процедуру удаления объектов (чем ближе мы к high, тем агрессивнее очистка). Вместо удаления можно использовать очистку файлов (truncate) пока хватает inode. Удаление производится асинхронно внешней программой unlinkd. Если объект тянется в данный момент, то он не удаляется. Если объект "отрицательно кеширован", то он удаляется. Если объект частный, то он удаляется. Алгоритмы замешения:

Сравнение алгоритмов проводится в

Какие объекты кешируются

Кешируемость объектов в зависимости от кода возврата HTTP: 

Caching  Code
        Successful 2xx
c        200 OK
         201 Created
         202 Accepted
c        203 Non-Authoriative Information *
E        204 No Content
         205 Reset Content *
?        206 Partial Content *
        Redirection 3xx
C        300 Multiple Choices
C        301 Moved Permanently
t        302 Moved Temporarily
-        303 See Other *
-        304 Not Modified
E        305 Use Proxy (proxy redirect) *
        Client Error 4xx
E        400 Bad Request
-        401 Unauthorized
         402 Payment Required *
E        403 Forbidden
E        404 Not Found
E        405 Method Not Allowed *
         406 Not Acceptable *
-        407 Proxy Authentication Required *
         408 Request Timeout *
         409 Confict *
C        410 Gone *
         411 Length Required *
         412 Precondition Failed *
         413 Request Entity To Large *
E        414 Request-URI Too Long *
         415 Unsupported Media Type
        Server Error 5xx
E        500 Internal Server Error
E        501 Not Implemented
E        502 Bad Gateway
E        503 Service Unavailable
E        504 Gateway Timeout *
         505 HTTP Version Not Supported *

Notes:
* HTTP 1.1
c Cached unless a query response without expiry information
C Cached
E Negatively cached if no expiry headers
t Cached only if expiry information
- Not cached
Unless other said, the response code is not cached.

Кешируемость в зависимости от заголовков:

Справедливый дележ канала (delay pool)

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

Определены 3 класса пулов:

  1. одно ведро на всех из этого класса
  2. одно общее ведро и 255 отдельных для каждого хоста из C-сетки
  3. 255 ведер для каждой сетки (класс B) и отдельное для каждого хоста

Пример конфигурации: 

delay_pools 3     # 3 delay pools
delay_class 1 1   # pool 1 is class 1
delay_class 2 1   # pool 2 is class 1
delay_class 3 3   # pool 3 is class 3
delay_access 1 allow staff
delay_access 1 deny all
delay_access 2 allow students
delay_access 2 deny all
delay_access 3 allow college
delay_access 3 deny all
delay_parameters 1 640000/640000
delay_parameters 2 64000/64000
delay_parameters 3 64000/64000 32000/64000 6400/32000
                   # total_rest/total_max net_rest/net_max ind_rest/ind_max
где
  total - на всех
  net - на подсеть
  ind - на отдельный адрес
  rest - скорость заполнения (байт/сек)
  max - объем ведра (байт)

Ограничение для модемных клиентов, чтобы squid не подкачивал файл пока клиент еще не считал предыдущую порцию. 

acl clients src адреса
delay_pools 1
delay_class 1 2
delay_access 1 allow clients
delay_access 1 deny all
delay_parameters 1 -1/-1 8000/4000

Прижать любителей MP3: 

acl multimedia urlpath_regex -i \.mp3$ \.mpeg$ \.avi$ \.mov$
delay_pools 1
delay_class 1 1
delay_access 1 allow multimedia
delay_access 1 deny all
delay_parameters 1 16000/64000

quick abort д.б. установлен маленьким чтобы объект не качался на полной скорости после отпадения клиента (нет клиента для запроса - нет ограничений).

Squid как transparent proxy (только http)

В процессе участвуют маршрутизатор, Linux и Squid:

  1. http-пакеты, бегущие мимо, должны отлавливаться маршрутизатором и переадресовываться на proxy-сервер. Как понять, что это http-пакет? Будем считать, что все пакеты, направленные на tcp/80, являются запросами на HTTP. Возникал вопрос: а может кешировать и другие порты? После обработки статистики (большой объем - 422MB, в ситуации с добровольным использованием proxy) выяснилось, что всего обращений было 3120260, из них HTTP - 92%. Из них на нестандартные порты - 2.3% (3128 - 0.05%, 8000 - 0.09%, 8001 - 0.13%, 8080 - 1.06%, 8081 - 0.15%, 8100 - 0.11%, 8101 - 0.46%). Я не вижу смысла бороться за 1%, разве что найду готовое решение ;)
  2. ОС proxy-сервера должна принимать эти пакеты, как родные, и перенаправлять к squid
  3. squid д.б. скомпилирован так, чтобы он принимал эти пакеты, как родные.
  4. squid д.б. сконфигурирован так, чтобы обрабатывать эти пакеты соответствующим образом.

Проблема. дырка в firewall: запрос приходит на прокси-сервер, который от своего имени (уже изнутри) лезет куда не надо.

Формат журналов

Формат access.log (запись делается, когда клиент закрывает socket; для наших 300 тысяч запросов в день получается 60 MB в день!):

  1. timestamp (unix time in ms)
  2. elapsed (ms), если клиент "ушел, не попрощавшись", то здесь будет время потраченное на обнаружение данного факта, а не время реального обслуживания (иногда более получаса на маленький файл)
  3. client IP address
  4. type/HTTP reply code, где type:
  5. size (bytes to client)
  6. method (GET, POST, ...)
  7. URL
  8. ident ("-", если недоступен)
  9. hierarhy data/Hostname
  10. тип содержимого (MIME тип/подтип)

Формат store.log:

  1. time (unix format with ms)
  2. action
  3. HTTP reply code
  4. HTTP Date: reply header
  5. HTTP Last-Modified: reply header
  6. HTTP Expires: reply header
  7. HTTP Content-Type: reply header
  8. HTTP Content-Length: reply header
  9. реально полученное число байт (если не совпадает с предыдущим числом, объект не хранится)
  10. HTTP метод (GET, POST, ...)
  11. ключ доступа (обычно URL, частные объекты еще и последовательный номер и метод)

Еще можно собирать useragent.log, все HTTP-заголовки и отладочную информацию. Я собираю только access.log и этого очень много.

Время в журналах записывается в Unix-формате (число милисекунд с 1 января 1970 года), что неудобно. Преобразовать в человеческий формат можно, например, с помощью gawk: awk '{print strftime("%Y%m%d%H%M%S",$1), $2, $3, $4, $5, $6, $7, $8, $9, $10, $11}' (printlog.sh) или perl: s/^\d+\.\d+/localtime $&/e;

Squid не умеет работать с файлами, превышающими 2 ГБ, так что журналы надо регулярно чистить.

Обработка статистики

В комплекте поставки идут access-extract.pl, (увеличено MaxEntries до ...)  получающая на стандартный ввод журнал access.log выдающая на стандартный выво промежуточный результат,  и access-summary.pl (убрал выдачу ICP, которой у меня нет, за счет чего увеличил ширину колонки с именами хостов; в xsort изменил сортировку с COUNT на BYTES), делающая из него красивый отчет. Внутри используется squid-logs.pl. Его надо расширить новыми суффиксами имен файлов (bmp - Image; rm, mid, mp3 - Audio; pl, cgi, shtml, php, php3, phtml, asp, dll - Dynamic; rpm, cab, avc - Bundle; css - HTML; koi - Text; js - Software). За день получается 60МБ в access.log, поэтому у меня не хватает терпения дождаться результатов работы других процедур из комплекта.

Частота обращений к объектам извлекается из access.log с помощью (url_freq.sh)
awk '{print $7}' | sort | awk -f /usr/local/bin/count.awk | sort -nr -k 2,2
или без учета anchor и query-частей URL (url_freq_noq.sh)
awk '{print $7}' | awk -F'?' '{print $1}' | awk -F';' '{print $1}' | awk -F'#' '{print $1}' | sort | awk -f /usr/local/bin/count.awk | sort -rn -k 2,2

LightSquid - анализатор статистики использования squid и генератор отчётов

LightSquid 1.7.1 - набор скриптов на perl для анализа журналов, не требует СУБД, очень быстр. Состоит из скрипта lightparser.pl, преобразующего журналы squid в собственный набор данных и набора cgi-скриптов для генерации отчётов (безопасность скриптов неизвестна, обновление каждые 10 минут). Набор отчётов полон и очень удобен: отчёты по дням, месяцам и годам для всей организации, групп и отдельных пользователей с указанием трафика, доли трафика, использования кеша, популярных сайтах; пометки о превышении лимита, больших файлах и подозрительной доле POST/PUT; статистика по самым популярным сайтам и кто и когда их использовал; графики загрузки по дням для пользователей и всей организации; детальные графики по часам для каждого пользователя. Требуется perl, а для графических отчётов gd и perl-GD (взял из FC6).

Скрипт lightparser.pl быстр (20 тысяч строк на Xeon 1.6 GHz), самостоятельно разжимает архивы .gz и .bz2, данные для каждого дня помещаются в отдельный подкаталог в каталоге с отчётами, в котором данные для каждого пользователя помещаются в отдельный текстовый файл. Записи с кодом 4xx пропускаются. Некоторые URL приводятся к общей форме (mail.ru, spylog.com и др.). В качестве параметров можно указывать имя файла с журналом относительно каталога с журналами и ключевые слова "today", "yesterday" и дату в формате YYYYMMDD. Каталог report имеет относительно небольшой объём (у меня получилось 60 МБ на месяц), т.к. отчёты создаются по запросу.

Установка:

sarg (Squid Analysis Report Generator)

SARG (ранее sqmgrlog) - Squid Analysis Report Generator. Отчёты создаются в формате html (по умолчанию - в /var/www/html), для графиков используется библиотека gd. Установка пакета sarg-2.2-1.el4.rf.i386.rpm на CentOS 4.3 и sarg-2.2.3.1-1.el5.rf.i386.rpm на CentOS 5.0 (x86-64 не работает). Требуется пакет gd, отчёты складываются в /var/www/sarg, настройка доступа для apache в /etc/httpd/conf.d/sarg.conf). Конфигурационный файл /etc/sarg/sarg.conf (символ '#' - начало комментария, каждый параметр на отдельной строке):

Ключи запуска sarg:

Практика - программа глючная и медленная, точнее очень глючная (sites_users содержит какую-то ерунду; забывает удалять и закрывать файлы - требуется ulimit 60000; не все графики создаются; в результате пришлось разбить на 3 части, считающиеся в разные дни: полный список пользователей без подробностей, первые 10 пользователей с подробностями, первые 100 сайтов) и очень медленная (полный месячный отчёт - 180 GB трафика - обрабатывается в течение 2 часов). Версию 2.2.3 так и не удалось заставить работать. В результате отказался в пользу LightSquid. Сбор суммарной информации по использованию трафика пользователями за последний месяц: 

time nice -19  sarg -d $(date --date "1 month ago" +%d/%m/%Y)-$(date --date "1 day ago" +%d/%m/%Y) \
  -x -z -l /squid/logs/access.log.5.gz ...

где /etc/sarg/sarg.conf содержит

graphs no
resolve_ip no
user_ip yes
topuser_sort_field BYTES reverse
user_sort_field BYTES reverse
index yes
overwrite_report yes
records_without_userid ip
report_type topusers
usertab /etc/sarg/usertab
privacy no
exclude_string имя-своего-домена
topuser_fields NUM DATE_TIME USERID CONNECT BYTES %BYTES IN-CACHE-OUT USED_TIME MILISEC %TIME TOTAL AVERAGE
user_report_fields CONNECT BYTES %BYTES IN-CACHE-OUT USED_TIME MILISEC %TIME TOTAL AVERAGE
topuser_num 0
displayed_values bytes
user_report_limit 0
ulimit 60000

Сбор информацию куда ходил конкретный пользователь (10 самых "прожорливых" пользователей) за последний месяц (15 минут CPU): 

time nice -19 sarg -f /etc/sarg/sarg.top10user.conf \
  -d $(date --date "1 month ago" +%d/%m/%Y)-$(date --date "1 day ago" +%d/%m/%Y) \
  [-a IP-адрес] -x -z -l /squid/logs/access.log.5.gz ...

где /etc/sarg/sarg.top10user.conf содержит

graphs no
user_ip yes
topuser_sort_field BYTES reverse
user_sort_field BYTES reverse
records_without_userid ip
report_type topusers users_sites
usertab /etc/sarg/usertab
privacy no
exclude_string имя-своего-домена
topuser_fields NUM DATE_TIME USERID CONNECT BYTES %BYTES IN-CACHE-OUT USED_TIME MILISEC %TIME TOTAL AVERAGE
user_report_fields CONNECT BYTES %BYTES IN-CACHE-OUT USED_TIME MILISEC %TIME TOTAL AVERAGE
topuser_num 10
displayed_values bytes
user_report_limit 10
ulimit 60000

Ссылки:

redirector, как средство оптимизации

redirector - внешняя программа (небуфферизованный в/в), в цикле читает с stdin URL и пишет на stdout преобразованный URL (или пустую строку, если нет преобразований). Преобразование происходит после проверки ACL, но до проверки на присутствие в кеше. В 2.6 заменён на url_rewrite_program. Формат входной строки (поля, разделенные пробелами):

  1. URL
  2. ip-address/fqdn (если fqdn нет, то "-")
  3. ident ("-", если нет)
  4. method (GET, POST, ...)
  5. urlgroup (в 2.6)

В качестве примера использования редиректора для уменьшения трафика в поставке приводится редиректор, производящий нормализацию URL (приведение к стандартному виду), что увеличивает вероятность попадания в кеш. А также редиректор преобразующий запросы на загрузку всяких там IE, Netscape и пр. с различных зеркал в запросы к локальному www-серверу (автор клянется, что это дает 15%). См. также про борьбу с баннерами.

Примеры redirectors:

Борьба с баннерами

Только не будем спорить о морали :) Но и в transparent режиме этого делать не надо. Поставьте себе локальный прокси и радуйтесь. Кстати, теми же методами можно бороться со счетчиками и порно.

Превращение банеров-картинок в рваные прямоугольники:

  1. Насобирать "вредителей" (в виде регулярных выражений)
  2. Заводим файлы в /usr/local/squid/etc:
  3. В squid.conf 
    acl banners_path_regex urlpath_regex "/usr/local/squid/etc/banners_path_regex"
acl banners_regex url_regex "/usr/local/squid/etc/banners_regex"
acl banners_exclusion url_regex "/usr/local/squid/etc/banners_exclusion"
http_access deny banners_path_regex !banners_exclusion
http_access deny banners_regex !banners_exclusion

Замена рекламных банеров на пустое место. Если рваные прямоугольники оскорбляют эстетические чувства. Предполагается, что в исходных страницах заданы width и height, иначе страница поплывет (можно заменять банеры на картинки соответствующего размера, но это большой труд).

  1. Насобирать "вредителей" (в виде регулярных выражений)
  2. На своем http-сервере завести "заменитель" рекламных картинок void.gif
  3. Настраиваем redirector в squid.conf (если он уже используется, то добавить к старому; м.б. еще настроить redirector_access):
    redirect_program /usr/local/squid/bin/banners.pl
  4. banners.pl (perl выбран для простоты демонстрации): 
       #!/usr/bin/perl (или где perl живет)
   $|=1;
   while (<>) {
   s@регулярное-выражение@http://www.nospam.org/nospam.gif@;
   print;}

К сожалению, использование "http_access deny" для блокировки JavaScript программ не получается (броузер не показывает страницу совсем). Поэтому приходится заменять реальный скрипт через redirect (см. выше) на что-нибудь безобидное (и каждый случай обрабатывать отдельно :(. Например, если исходный скрипт открывал окно с рекламой (<script src=...>), то вместо него подсовываем 

   <html><head>
   <script language="JavaScript"><!-- window.close(); //--></script>
   </head><body></body></html>

вместо tx3 (если он встроен страницу с помощью SSI, то не поможет, да и зачем тогда его резать?): 

   document.write("&nbsp;");

Ссылки:

squidGuard

squidGuard позволяет фильтровать и переадресовывать запросы по именам доменов, URL и регулярным выражениям. Позволяет группировать пользователей по IP адресам с заданием различных правил для различных групп с указанием времени суток. Возможно задание списка "хороших" сайтов. Домены и URL могут храниться в текстовых файлах или в формате Berkeley DB. Не фильтрует содержимое запросов и встроенные скрипты. GPL. Можно использовать бесплатно в любых целях, кроме продажи. К сожалению не изменялся с 2001 года (хотя есть заплатки от последователей и последователей).

Устанавливаю из готового пакета (/usr/bin/squidGuard, /etc/squid/squidguard.conf, /etc/logrotate.d/squidguard, /var/log/squidguard/, /usr/share/doc/squidguard-1.2.0/), пакета с чёрным списком (/etc/squid/squidguard-blacklists.conf; /etc/logrotate.d/squidguard-blacklists; /etc/squid/local/bad/; /etc/squid/local/good/; /var/lib/squidguard/: ads/, adult/, aggressive/, audio-video/, drugs/, forums/, gambling/, hacking/, local, mail/, /proxy/, violence/, warez/). Из исходных текстов устанавливается обычным путём (./configure; make; make install), требуется Berkeley DB 2.x. После установки необходимо настроить /etc/squid/squidguard-blacklists.conf и просмотреть входящие в комплект чёрные списки. После установки необходимо настроить права доступа к /var/log/squidguard, а после первого создания БД (ключ -C) настроить права доступа к /var/lib/squidguard и /etc/squid/local/. Настроить squid.conf: 

redirector_bypass on
redirect_program /usr/bin/squidGuard -c /etc/squid/squidguard-blacklists.conf
acl squidGuard ...
redirector_access allow squidGuard

Опции squidGuard:

Файл настройки описывает поименованные группы интервалов времени (используется при описании группы клиентов), группы пользователей (по IP адресам), группы URL (ссылки на текстовые файлы и БД), группы правил переадресации и группы ACL. Комментарии начинаются с '#'; имеется большой список зарезервированных слов (в частности: anonymous, user, userlist); нельзя ссылаться на описания групп вперёд; описания групп начинаются с

тип-группы имя-группы {

и завершаются '}'. В начале файла указываются имена используемых файлов:

Описание интервала времени (имя типа: time) состоит из перечня спецификаций (каждое на отдельной строке, при перекрытии интервалы объединяются), следующих видов (вместо года, месяца или дня можно указать '*'):

Описание группы клиентов (имя типа: source) состоит из перечня адресов клиентов в следующих форматах (файл содержит на каждой строке IP адрес без ключевого слова "ip"; использование доменов требует log_fqdn в squid.conf; имена пользователей определяются по протоколу ident (доменные имена с обратной косой чертой не поддерживаются); спецификации одного типа объединяются, разных типов - пересекаются; группы могут пересекаться - приоритет имеет первая по тексту; имя журнала берётся относительно logdir):

Описание группы клиентов может иметь условие по времени: 

source имя-группы-клиентов [within|outside имя-интервала-времени] {
  ...
} else {
  ...
}

Описание группы URL (имя типа: destination) состоит из перечня URL в следующих форматах (спецификации любых типов объединяются; группы могут пересекаться - приоритет имеет первая в директиве pass; в списках необходимо использовать только строчные буквы; включение имени домена включает все хосты во всех поддоменах этого домена; при включении URL в список из него необходимо удалить "http://www.", ":8080" и завершающее имя или "/"; в строке списка URL можно в качестве второго поля указать новый URL для перенаправления (это работает быстрее, чем rewrite); использование регулярных выражений сильно замедляет работу; имя журнала берётся относительно logdir):

Описание группы URL может иметь условие по времени: 

destination имя-группы [within|outside имя-интервала-времени] {
  ...
} else {
  ...
}

Описание группы правил переадресации (имя типа: rewrite) состоит из перечня правил замены URL в следующих форматах

Описание группы правил переадресации может иметь условие по времени: 

rewrite имя-группы [within|outside имя-интервала-времени] {
  ...
} else {
  ...
}

Описание группы ACL (ровно одна непоименованная группа) содержит для каждой группы пользователей правила поведения фильтра в формате 

имя-группы-клиентов [within|outside имя-интервала-времени] {
  pass [!]имя-группы-URL ...
  [rewrite имя-группы-переадресации]
  [redirect [301:|302:]новый-адрес]
} else {
  ...
}

Имеется специальная группа пользователей default, в которую входят пользователи, не вошедшие ни в одну из остальных групп или вошедшие в группу, не имеющую ACL; здесь же задаются правило переадресации для групп клиентов, не имеющих собственных правил переадресации.

Имеется следующие встроенные группы URL

Директива redirect (если URL блокируется фильтром, то какой-нибудь redirect должен быть обязательно определён) позволяет производить подстановку переменных (в поставке имеется шаблон squidGuard.cgi для создания красивых страниц с объяснением):

Первый же сайт, на который я зашёл (rambler.ru), оказался в списках ads и adult.

Приемы конфигурации

Простейшие случаи иерархии. Основной squid с консервативными настройками и вспомогательный с агрессивными настройками (антибаннер ;).

Консервативный: Агрессивный:

Закрыть доступ к какой-то информации для клиентов

badobjects - это произвольное имя ACL; ERR_ACCESS_DENIED - имя файла в /usr/lib/squid/errors/English или в подобном месте, вместо этого файла можно поставить для каждой ситуации свой файл; воздействие http_access зависит от места, в которое его поставить; если squid получает от parent TCP_DENIED, то он лезет напрямую:

Шаблон для борьбы с RealPlayer

http://[^/]+/SmpDsBhgRl

Как удалить объект из кеша

В squid.conf: 
acl PURGE method purge
acl localhost src 127.0.0.1
http_access allow purge localhost
http_access deny purge
Теперь для каждого удаляемого объекта: client -m PURGE URI

Использование дополнительного канала для доступа в Интернет

Имеем маршрутизатор (Cisco) с двумя каналами доступа в Интернет через двух различных провайдеров. Клиентские компьютеры расположены в адресном пространстве одного из них, а хочется нагрузить оба канала на прием. Создаем файл as.list, содержащий список AS ,к которым мы хотим обращаться через второй канал. Конфигурируем squid:

Конфигурируем вспомогательный squid-сервер (можно даже на том же хосте - специально выбран нестандартный порт; только прямого доступа к нему давать не надо):

SNMP

Для сбора статистики с помощью встроенного агента SNMP Squid должен быть собран с ключом --enable-snmp. По умолчанию, squid слушает SNMP запросы на порту 3401 (вместо стандартного 161).

Для обеспечения прав доступа надо записать в squid.conf (не забывайте про сетевой экран): 

acl snmppublic snmp_community имя-сообщества
# snmp_port 3401
snmp_access allow snmppublic localhost

MIB файл называется /usr/local/squid/share/mib.txt: надо убрать фигурные скобки со всем содержимым из описания модуля, положить его в /usr/share/snmp/mibs. Извлечение полного дерева объектов:
   snmpwalk -p 3401 -m SQUID-MIB имя-хоста имя-сообщества squid

При описании использована форма записи SMIv2, хотя поддерживается только SNMPv1. Единственная переменная, определенная как read-write: cacheLoggingFacility (нечаянно?). trap отсутствуют. Все объекты лежат в поддереве iso.org.dod.internet.private.enterprises.nlanr.squid (1.3.6.1.4.1.3495.1):

  1. cacheSystem
    1. cacheSysVMsize (объем кеша в оперативной памяти, в KB)
    2. cacheSysStorage (объем кеша на диске, в KB)
    3. cacheUptime (в 1/100 секунды)
  2. cacheConfig
    1. cacheAdmin (e-mail)
    2. cacheSoftware
    3. cacheVersionId
    4. cacheLoggingFacility
    5. cacheStorageConfig
      1. cacheMemMaxSize (значение cache_mem в MB)
      2. cacheSwapMaxSize (значение cache_dir в MB)
      3. cacheSwapHighWM
      4. cacheSwapLowWM
  3. cachePerf
    1. cacheSysPerf
      1. cacheSysPageFaults (потребовавших физического в/в)
      2. cacheSysNumReads (число команд ввода для HTTP)
      3. cacheMemUsage (в KB, у меня -1 :)
      4. cacheCpuTime (секунд)
      5. cacheCpuUsage (%, у меня всегда 3% :)
      6. cacheMaxResSize (в KB, у меня 0 :)
      7. cacheNumObjCount (число объектов в кеше)
      8. cacheCurrentLRUExpiration
      9. cacheCurrentUnlinkRequests (число запросов к unlinkd)
      10. cacheCurrentUnusedFDescrCnt (свободных дескрипторов файлов)
      11. cacheCurrentResFileDescrCnt (зарезервированных fd)
    2. cacheProtoStats
      1. cacheProtoAggregateStats
        1. cacheProtoClientHttpRequests
        2. cacheHttpHits
        3. cacheHttpErrors
        4. cacheHttpInKb (от клиентов)
        5. cacheHttpOutKb (клиентам)
        6. cacheIcpPktsSent
        7. cacheIcpPktsRecv
        8. cacheIcpKbSent
        9. cacheIcpKbRecv
        10. cacheServerRequests (к HTTP серверам и родителям)
        11. cacheServerErrors
        12. cacheServerInKb (от серверов)
        13. cacheServerOutKb
        14. cacheCurrentSwapSize (в KB)
        15. cacheClients (число клиентских кешей)
      2. cacheMedianSvcTable (усредненная статистика за интервал времени, указанный в cacheMedianTime)
        1. cacheMedianSvcEntry (индекс доступа к экземпляру: cacheMedianTime)
          1. cacheMedianTime (интервал времени усреднения: 1, 5 и 60 минут)
          2. cacheHttpAllSvcTime (среднее время обслуживания всех запросов, милисекунд)
          3. cacheHttpMissSvcTime (среднее время обслуживание запросов, отсутствующих в кеш или устаревших)
          4. cacheHttpNmSvcTime (HTTP near miss service time)
          5. cacheHttpHitSvcTime (среднее время обслуживание запросов, найденных в кеш; по-моему, считается неправильно: TCP_HIT для локального хоста без обращения к серверу картинки в 8 кБ иногда требует больше получаса)
          6. cacheIcpQuerySvcTime
          7. cacheIcpReplySvcTime
          8. cacheDnsSvcTime (среднее время обслуживания DNS)
          9. cacheRequestHitRatio (%, можно вычислить по cacheProtoClientHttpRequests и cacheServerRequests)
          10. cacheRequestByteRatio (%, можно вычислить по cacheServerInKb и cacheHttpOutKb)
  4. cacheNetwork
    1. cacheIpCache (статистика кеша IP: получение IP адреса по имени и доступность сервера)
      1. cacheIpEntries (элементов в кеше IP)
      2. cacheIpRequests
      3. cacheIpHits
      4. cacheIpPendingHits
      5. cacheIpNegativeHits
      6. cacheIpMisses
      7. cacheBlockingGetHostByName
      8. cacheAttemptReleaseLckEntries
    2. cacheFqdnCache (определение полного имени по простому)
      1. cacheFqdnEntries (у меня их всего 2)
      2. cacheFqdnRequests
      3. cacheFqdnHits
      4. cacheFqdnPendingHits
      5. cacheFqdnNegativeHits
      6. cacheFqdnMisses
      7. cacheBlockingGetHostByAddr
    3. cacheDns
      1. cacheDnsRequests
      2. cacheDnsReplies
      3. cacheDnsNumberServers
  5. cacheMesh (таблицы соседей и клиентов, их состояние и статистика, у меня не работает, да и в описании ошибки)

Мониторинг с помощью rrdtool

Для мониторинга работы Squid можно использовать MRTG или rrdtool. В последнее время я потихонечку перевожу весь свой мониторинг с MRTG на rrdtool. Хотя использование rrdtool более трудоемко, зато он требует меньше ресурсов при работе и не заполняет всю имеющуюся память при проблемах с сетью. К тому же он позволяет выводить больше 2 графиков на одну картинку. При этом я имитирую внешний вид и поведение mrtg. К сожалению, не вся статистика доступна по SNMP (например, доля прерванных соединений), а часть той статистики, что должна извлекаться согласно документации, извлекается с ошибками. Нам надо: спроектировать структуру БД и создать ее; обеспечить внесение изменений каждые 5 минут; обеспечить регулярное обновление суточных, недельных, месячных и годовых графиков; создать набор HTML страниц для доступа к графикам.

Все данные, связанные с работой Squid, у меня хранятся в одной БД. К сожалению, rrdtool не позволяет добавлять или удалять DS (data source) из существующей БД (разве что с помощью dump/restore), так что если в дальнейшем потребуется собирать дополнительную информацию, то ее придется хранить во второй БД. Интервал измерения как в mrtg - 300 секунд. Значения каждой DS хранятся в четырех RRA с использованием усреднения по 1, 6, 24 и 288 отсчетам соответственно. Размер RRA выбран достаточным для построения графиков за 2 дня, 2 недели, 2 месяца и 2 года соответственно. Информация извлекается с помощью протокола SNMP. Команду для создания БД можно взять в архиве. Имена DS совпадают с простыми дескрипторами объектов Squid MIB (некоторые пришлось "укоротить" из-за ограничения на длину имени DS в rrdtool):

Изменения запрашиваются и вносятся в БД каждые 5 минут с помощью скрипта squid_update.sh (вызывается из crontab).

Суточные, недельные, месячные и годовые графики генерируются скриптом squid_graph.sh соответственно раз в 5 минут, 30 минут, 2 часа и 1 день (вызывается из crontab). Скрипт имеет 2 параметра: начало отсчета (-2days, -14days, -50days и -20month) и суффикс имени PNG-файла (5min, 30min, 2h, 1d). Получаются следующие графики (за дизайн извиняйте - мне в детстве медведь наступил не только на ухо :):

Все 4 графика каждого типа объединяются в одну HTML страницу. Чтобы не писать 15 почти одинаковых страниц, используется SSI, а именно: сделан шаблон и 15 страниц типа (title - заголовок страницы, groupprefix - начало имени файла, к которому в шаблоне добавлются суффиксы вида "_5min.png"): 

<!--#set var="title" value="Squid CPU Usage" -->
<!--#set var="groupprefix" value="squid_cpu" -->
<!--#include file="rrdtool_template.shtml" -->

Все страницы, посвященные мониторингу Squid, объединяются индексной страницей, содержащей 5-минутные графики всех типов и ссылки на соответствующие страницы.

В действительно, мониторится не только Squid, так что вызовы описанных выше скриптов включены в вызовы скриптов верхнего уровня, а ссылка на индексную страницу - в управляющую консоль.

Извлечение и удаление объектов из кеша

Утилита (была на http://www.cache.dfn.de/DFN-Cache/Development/Purge/) purge позволяет извлекать сохраненные объекты из кеша (с сохранением информации о структуре URL и самих файлах) или удалять их (как "правильные" объекты с помощью обращения к Squid методом PURGE, так и ошибочные файлы напрямую).

Сборка производится с помощью команды make (не надо читать про RCS в README!). Извлечение файлов MP3 из кеша (ограничитель шаблона - $ - ставить не надо, так как некоторые сервера добавляют всякий мусор в конце URI дабы избежать кеширования): 

./purge -n -a -s -C /tmp/MP3s/ -e '\.mp3|\.wav'|fgrep -v 'strange file'

Ссылки:
@ Карта сайта News Автора!

Bog BOS: Squid (кеширующий прокси для http): установка, настройка и использование

apache inn MySQL nntpcache Cyrus IMAP exim Squid ssh syslog tacacs ProFTPD wu-ftpd xntpd

Последние изменения:
2024.11.22: sysadmin: systemd-journald (централизованное хранение)
2024.11.11: sysadmin: Linux: пространства имён
2024.11.06: sysadmin: настройка TCP/IP в Linux: виртуальный интерфейс и виртуальный мост
2024.10.25: sysadmin: Linux VFS, атрибуты, расширенные атрибуты, ACL
Copyright © 1996-2024 Sergey E. Bogomolov; www.bog.pp.ru