cacheSystem

cacheSysVMsize (объем кеша в оперативной памяти, в KB)

cacheSysStorage (объем кеша на диске, в KB)

cacheUptime (в 1/100 секунды)

cacheConfig

cacheAdmin (e-mail)

cacheSoftware

cacheVersionId

cacheLoggingFacility

cacheStorageConfig

cacheMemMaxSize (значение cache_mem в MB)

cacheSwapMaxSize (значение cache_dir в MB)

cacheSwapHighWM

cacheSwapLowWM

cachePerf

cacheSysPerf

cacheSysPageFaults (потребовавших физического в/в)

cacheSysNumReads (число команд ввода для HTTP)

cacheMemUsage (в KB, у меня -1 :)

cacheCpuTime (секунд)

cacheCpuUsage (%, у меня всегда 3% :)

cacheMaxResSize (в KB, у меня 0 :)

cacheNumObjCount (число объектов в кеше)

cacheCurrentLRUExpiration

cacheCurrentUnlinkRequests (число запросов к unlinkd)

cacheCurrentUnusedFDescrCnt (свободных дескрипторов файлов)

cacheCurrentResFileDescrCnt (зарезервированных fd)

cacheProtoStats

cacheProtoAggregateStats

cacheProtoClientHttpRequests

cacheHttpHits

cacheHttpErrors

cacheHttpInKb (от клиентов)

cacheHttpOutKb (клиентам)

cacheIcpPktsSent

cacheIcpPktsRecv

cacheIcpKbSent

cacheIcpKbRecv

cacheServerRequests (к HTTP серверам и родителям)

cacheServerErrors

cacheServerInKb (от серверов)

cacheServerOutKb

cacheCurrentSwapSize (в KB)

cacheClients (число клиентских кешей)

cacheMedianSvcTable (усредненная статистика за интервал времени, указанный в cacheMedianTime)

cacheMedianSvcEntry (индекс доступа к экземпляру: cacheMedianTime)

cacheMedianTime (интервал времени усреднения: 1, 5 и 60 минут)

cacheHttpAllSvcTime (среднее время обслуживания всех запросов, милисекунд)

cacheHttpMissSvcTime (среднее время обслуживание запросов, отсутствующих в кеш или устаревших)

cacheHttpNmSvcTime (HTTP near miss service time)

cacheHttpHitSvcTime (среднее время обслуживание запросов, найденных в кеш; по-моему, считается неправильно: TCP_HIT для локального хоста без обращения к серверу картинки в 8 кБ иногда требует больше получаса)

cacheIcpQuerySvcTime

cacheIcpReplySvcTime

cacheDnsSvcTime (среднее время обслуживания DNS)

cacheRequestHitRatio (%, можно вычислить по cacheProtoClientHttpRequests и cacheServerRequests)

cacheRequestByteRatio (%, можно вычислить по cacheServerInKb и cacheHttpOutKb)

cacheNetwork

cacheIpCache (статистика кеша IP: получение IP адреса по имени и доступность сервера)

cacheIpEntries (элементов в кеше IP)

cacheIpRequests

cacheIpHits

cacheIpPendingHits

cacheIpNegativeHits

cacheIpMisses

cacheBlockingGetHostByName

cacheAttemptReleaseLckEntries

cacheFqdnCache (определение полного имени по простому)

cacheFqdnEntries (у меня их всего 2)

cacheFqdnRequests

cacheFqdnHits

cacheFqdnPendingHits

cacheFqdnNegativeHits

cacheFqdnMisses

cacheBlockingGetHostByAddr

cacheDns

cacheDnsRequests

cacheDnsReplies

cacheDnsNumberServers

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):

cacheSysPageFaults

cacheSysNumReads

cacheCpuTime

cacheCpuUsage (не используется для построения графиков)

cacheNumObjCount

cacheCurrentUnlink

cacheCurrentUnusedF

cacheProtoClientHtt

cacheHttpHits

cacheHttpErrors

cacheHttpOutKb

cacheServerRequests

cacheServerErrors

cacheServerInKb

cacheCurrentSwap

cacheHttpAllSvcTime

cacheHttpMissSvc

cacheHttpHitSvcTime

cacheDnsSvcTime

cacheRequestHit (не используется для построения графиков)

cacheRequestByte (не используется для построения графиков)

cacheIpEntries

cacheIpRequests

cacheIpHits

cacheIpNegativeHits

cacheDnsRequests

cacheDnsReplies

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

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

squid_hr_???.png (эффективность кеширования в хитах и байтах)

squid_cpu_???.png (использование CPU)

squid_svctime_???.png (среднее время обслуживания запросов)

squid_traffic_???.png (траффик от серверов и к клиентам)

squid_request_???.png (число запросов в секунду)

squid_ipreqs_???.png (число запросов в секунду к DNS-кешу)

squid_ipentries_???.png (число объектов в DNS-кеше)

squid_dnsreqs_???.png (число запросов в секунду к DNS-серверу)

squid_pf_???.png (число обращений в секунду к файлу подкачки)

squid_reads_???.png (число чтений HTTP в секунду)

squid_unlinks_???.png (число удалений объектов из кеша в секунду)

squid_unusedfd_???.png (число используемых и свободных дескрипторов файлов)

squid_swapsize_???.png (используемое под кеш место на диске)

squid_objects_???.png (число объектов в дисковом кеше)

squid_errors_???.png (число ошибок в секунду)

Все 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, так что вызовы описанных выше скриптов включены в вызовы скриптов верхнего уровня, а ссылка на индексную страницу - в управляющую консоль.

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

Утилита purge позволяет извлекать сохраненные объекты из кеша (с сохранением информации о структуре URL и самих файлах) или удалять их (как "правильные" объекты с помощью обращения к Squid методом PURGE, так и ошибочные файлы напрямую).

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

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

5. Squid и Web Cache Control Protocol (WCCP)

Если Ваш тpаффик в Internet выходит чеpез Cisco router, IOS котоpого умеет WCCP, transparent HTTP caching/proxying можно оpганизовать с помощью этого пpотокола. Это гоpаздо лучше, чем использовать для этого policy routing. Hачиная с веpсии 2.3, Squid умеет WCCP 1. Router будет отслеживать состояние Вашего Squid'а. И если он не pаботает, пpекpатит пеpенапpавлять на него тpанзитные HTTP запpосы. Также, можно использовать несколько HTTP cache/proxy сеpвеpов, оpганизуя, таким обpазом, pаспpеделение нагpузки. Я пpиведу пpимеp моих настpоек для IOS 12.0(7):

ip wccp enable

ip wccp redirect-list fwd-2-squid

! Это интеpфейс, чеpез котоpый выходит тpаффик в Internet.

interface Serial1

ip web-cache redirect

! Этот acl опpеделяет, чьи запpосы надо пеpенапpавлять.

! Обязательно запpетите пеpенапpавление запpосов от Вашего

! HTTP cache/proxy сеpвеpа, иначе они зациклятся.

! В данном пpимеpе, 192.168.1.1 - это адpес, с котоpого

! посылает свои запpосы Squid.

ip access-list standard fwd-2-squid

deny 192.168.1.1

permit any

В конфигуpационном файле Squid'а Вы должны указать адpес router'а, котоpый будет пеpенапpавлять запpосы:

wccp_router 192.168.1.2

Далее Вы должны настpоить Squid и Вашу OS для обpаботки пеpенапpавленных запpосов. Об этом смотpите ниже.

5.1 Transparent HTTP caching/proxying

Имеется возможность организовать использование Вашего HTTP прокси сервера прозрачно для пользователей. Это значит, что им не придется что-то настраивать в своих браузерах. Для этого Вам надо решить следующие задачи:

Добится того, что бы HTTP запросы пользователей попали на компьютер, где работает Ваш HTTP прокси сервер.

После этого, необходимо, что бы они попали собственно в "лапы" прокси.

И наконец, что бы Ваш HTTP прокси сервер их правильно обработал.

Выполнить первый пункт можно разными способами. Поставить HTTP прокси сервер на роутер, через который проходить весь траффик, или форвардить запросы с помощью policy routing'а на Cisco роутере или ipfw на FreeBSD:

add fwd x.x.x.x tcp from any to any http in via ed0

add pass all from any to any

Здесь x.x.x.x - IP адрес HTTP прокси сервера, ed0 - интерфейс, через который входит траффик от пользователей.

Что бы HTTP запросы пользователей попали к HTTP прокси серверу, можно воспользоваться опять же ipfw (если у Вас FreeBSD):

add fwd 127.0.0.1,3128 tcp from any to any http in via ed0

add pass all from any to any

Здесь 3128 - порт, на котором принимает запросы Ваш HTTP прокси, а ed0 - интерфейс, через который запросы пользователей попадают на этот компьютер.

Если прокси сервер должным образом настроен, он правильно обработает полученные запросы и все будут довольны. Вот пример настроек Squid'а:

httpd_accel_host virtual

httpd_accel_port 80

httpd_accel_with_proxy on

httpd_accel_uses_host_header on

Внимание, если Вы используете FreeBSD и ipfw, для форварда HTTP запросов, ядро должно быть собрано со следующими опциями:

options IPFIREWALL

options IPFIREWALL_FORWARD

Информацию о настройке transparent HTTP caching/proxying Вы также можете найти здесь:

6. Открытый прокси

Открымтый промкси-семрвер -- прокси-сервер, обрабатывающий запросы от любых IP-адресов в Интернете. В отличие от обычных прокси-серверов, которыми пользуется ограниченное количество доверенных лиц (обычно в зоне ответственности владельца прокси-сервера -- например, в локальной сети), открытый прокси-сервер позволяет практически любому узлу сети обращаться через себя к другим узлам сети.

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

Вы можете проверить легкость доступа на ваш сайт, используя анонимные прокси, размещенные в разных частях мира. Список анонимных прокси регулярно обновляется на странице поддержки программы. Что же такое анонимный прокси сервер?

Любой веб-сайт в мире может отслеживать ваши движения через свои страницы и следить за вашими действиями, используя ваш IP address, уникальный идентификатор, назначенный каждому компьютеру в Интернете. Зависимо от политики Интернет ресурса, вы, возможно, не сможете получить доступ к желаемой информации. Также, ваш визит может быть зарегистрирован и использован позже, чтобы получить вашу персональную информацию.

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

Используя только ваш IP адрес и информацию о вашей операционной системе, веб-сайт может автоматически находить слабые места в вашей операционной системе. Для этого существуют не очень сложные, готовые, бесплатные хакерские программы. Некоторые из таких программ могут просто "повесить" вашу машину, чтобы вы ее перезагрузили, а другие, более мощные, могут получить доступ к содержимому вашего жесткого диска или оперативной памяти. Анонимный прокси не допускает этого, скрывая ваш IP адрес. И, таким образом, никто не сможет получить доступ к вашему компьютеру через интернет. Однако, в большинстве случаев, прокси информируют целевой сервер об адресе вашего компьютера, который сделал запрос, передавая в разных формах ваш IP-адрес.

Анонимные (по-настоящему анонимные!) прокси серверы не передают информацию об IP-адресе клиента, и, таким образом, эффективно скрывают информацию о вас и о ваших интересах. Кроме того, некоторые прокси серверы могут скрывать сам факт, что вы путешествуете по сети через прокси сервер! Анонимные прокси могут использоваться для всех видов веб-услуг, таких как веб-почта (MSN Hot Mail, Yahoo mail), веб-чаты, архивы FTP, и т.д.

Причины возникновения

Прокси-сервер может быть сделан открытым (общедоступным) по воле владельца сервера или в результате неправильной конфигурации обычного прокси-сервера (ошибка при проверке принадлежности пользователя, в настройке "слушающего" интерфейса, в списке транслируемых портов в NAT/PAT).

Использование

В случае разницы в цене трафика в разных сетях, открытый прокси-сервер, находящийся в "своей" сети, может использоваться для получения более дорогого трафика из "чужой" сети. Так, например, многие российские пользователи, которым на работе запрещён доступ к иностранным сайтам, могут всё-таки получить такой доступ через открытый прокси-сервер. Кроме того, открытый прокси-сервер может иметь собственный кэш, несколько ускоряющий доставку сетевых ресурсов клиенту.

Анонимные открытые прокси-серверы могут использоваться для обеспечения (частичной) анонимности в Интернете, так как скрывают IP-адрес пользователя, направляя все пользовательские запросы от своего адреса. При этом сам прокси-сервер может вести логи обращений.

Запреты на анонимные открытые прокси-серверы

Потенциальное использование открытых прокси-серверов для скрытия адреса пользователя приводит к тому, что сайты некоторых интернет-сервисов запрещают доступ к своим ресурсам с открытых прокси-серверов. Например, почтовые службы "Yandex" отказываются работать с пользователями открытых прокси-серверов[1]. В Википедии использование анонимных открытых прокси-серверов также запрещено[2].

Пример ошибочного появления открытого прокси

В приватной сети 192.168.0.0/8 установлен прокси-сервер 192.168.1.2, имеющий доступ во внешнюю сеть через NAT на маршрутизаторе с внешним адресом 100.100.100.100. Фильтрация запросов по IP-адресам не осуществляется (т. к. доступ к серверу имеют только пользователи локальной сети). Если в случае ошибки маршрутизатор начнёт пропускать пакеты из внешней сети на узел 192.168.1.2 (например, при настройке PAT для веб-сервера на узле 192.168.1.2 не будет ограничен список портов), то обращаясь к адресу, для которого настроен PAT (например, 100.100.100.101, где настроен веб-сервер на 80-ом порту) по порту прокси-сервера (например, 8080), любой пользователь сети сможет получить и отправить информацию через прокси-сервер, который и будет с этого момента считаться открытым.

Анонимные прокси

Вы можете проверить легкость доступа на ваш сайт, используя анонимные прокси, размещенные в разных частях мира. Список анонимных прокси регулярно обновляется на странице поддержки программы. Что же такое анонимный прокси сервер?

Любой веб-сайт в мире может отслеживать ваши движения через свои страницы и следить за вашими действиями, используя ваш IP address, уникальный идентификатор, назначенный каждому компьютеру в Интернете. Зависимо от политики Интернет ресурса, вы, возможно, не сможете получить доступ к желаемой информации. Также, ваш визит может быть зарегистрирован и использован позже, чтобы получить вашу персональную информацию.

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

Используя только ваш IP адрес и информацию о вашей операционной системе, веб-сайт может автоматически находить слабые места в вашей операционной системе. Для этого существуют не очень сложные, готовые, бесплатные хакерские программы. Некоторые из таких программ могут просто "повесить" вашу машину, чтобы вы ее перезагрузили, а другие, более мощные, могут получить доступ к содержимому вашего жесткого диска или оперативной памяти. Анонимный прокси не допускает этого, скрывая ваш IP адрес. И, таким образом, никто не сможет получить доступ к вашему компьютеру через интернет. Однако, в большинстве случаев, прокси информируют целевой сервер об адресе вашего компьютера, который сделал запрос, передавая в разных формах ваш IP-адрес.

Анонимные (по-настоящему анонимные!) прокси серверы не передают информацию об IP-адресе клиента, и, таким образом, эффективно скрывают информацию о вас и о ваших интересах. Кроме того, некоторые прокси серверы могут скрывать сам факт, что вы путешествуете по сети через прокси сервер! Анонимные прокси могут использоваться для всех видов веб-услуг, таких как веб-почта (MSN Hot Mail, Yahoo mail), веб-чаты, архивы FTP, и т.д.

7. Linux ACLs

Иногда в процессе работы администратор сервера может столкнуться с проблемой правильной установки прав доступа. Например, возникла ситуация, когда на один файл необходимо установить право на чтение трем пользователям разных групп и право на чтение и выполнение для пользователя четвертой группы. Решение этой проблемы стандартными средствами является достаточно сложной задачей. Права доступа в Linux задаются девятью битами, что предполагает установку прав только для пользователя-владельца, группы-владельца и всех остальных. Какие-либо дополнительные возможности по установке прав доступа к файлу в стандартной конфигурации ОС Linux отсутствуют. В результате для решения задачи может потребоваться внесение пользователей в общие группы или создание дополнительных групп, что является не всегда приемлемым и помимо всего прочего создает дополнительные проблемы управления.

Оптимальным решением в ситуации такого рода может послужить программная разработка Linux ACLs.

Linux ACLs (Access Control Lists) - это набор заплаток для ядра операционной системы и приложений для работы с файловой системой и несколько дополнительных программ, дающих возможность устанавливать права доступа к файлам не только для пользователя-владельца и группы-владельца файла, но и для любого пользователя и группы.

Linux ACLs использует расширенные атрибуты для хранения данных о правах доступа к файлам пользователей и групп. Список расширенного контроля доступа существует для каждого файла в системе и состоит из шести компонентов. Первые три являются копией стандартных прав доступа к файлу. Они содержаться в единственном экземпляре в ACL и есть у каждого файла в системе:

*ACL_USER_OBJ - режим доступа к файлу пользователя-владельца;

*ACL_GROUP_OBJ - режим доступа к файлу группы-владельца;

*ACL_OTHER - режим доступа к файлу остальных пользователей.

Следующие два компонента устанавливаются для каждого файла в отдельности и могут присутствовать в ACL в нескольких экземплярах:

*ACL_USER - содержит UID и режим доступа к файлу пользователя, которому установлены права, отличные от основных. На каждого пользователя со своими правами на данный файл хранится отдельная запись. Не может существовать более одной записи на одного и того же пользователя;

*ACL_GROUP - содержит те же самые данные, что и ACL_USER, но для группы пользователей;

*ACL_MASK - маска действующих прав доступа для расширенного режима.

При установке дополнительных прав доступа присваивается значение и элементу ACL_MASK.

Каталоги также могут иметь список контроля доступа по умолчанию. В отличие от основного ACL, он действует на создаваемые внутри данного каталога файлы и каталоги. При создании файла внутри такого каталога файл получает ACL, равный ACL по умолчанию этого каталога.

Для использования Linux ACLs необходимо получить на сайте разработчика пакет Linux ACLs и заплатки к ядру ОС Linux и некоторым программам системного окружения. Сначала необходимо наложить заплатку на исходные файлы ядра, чтобы получить поддержку листов доступа, затем собрать ядро с поддержкой расширенных атрибутов и листов контроля доступа. После сборки ядра с поддержкой листов доступа нужно наложить заплатки на некоторые системные программы и пересобрать их. Далее необходимо собрать пакет приложений ACL, который тоже находится на сайте разработчика. С помощью приложений этого пакета производится управление расширенными правами доступа. Весь процесс установки Linux ACLs, начиная наложением заплаток и заканчивая сборкой пакета ACL, подробно описан в документации программного пакета.

После включения в системе поддержки Linux ACLs манипулирование расширенными атрибутами производится с помощью двух программ, входящих в пакет ACL - getfacl и setfacl. Первая программа позволяет получить информацию о расширенных правах доступа файла. Вторая производит изменение этих прав доступа. Синтаксис командных строк этих программ подробно описан в соответствующих man-руководствах пакета.

Размещено на Allbest.ru

...