- nameserver
Для трансляции имен в адреса обычно используют семейства gethostbyname
(сразу замечу что OOPS их старается не использовать, дальше станет ясно
почему). Использование этих вызовов удобно по нескольким причинам:
во-первых это просто, во-вторых - gethostbyname позволяет использовать не
только DNS в качестве источника информации об IP-адресах, но и nis, файлы
hosts и т.д. К сожалению, при определенных условиях gethostbyname (и
thread-safe вариант gethostbyname_r) представляют собой существенный
"тормоз" при попытке параллельного резолвинга нескольких имен, а именно:
имена будут резолвиться по-очереди. Поэтому OOPS использует свой внутренний
простенький резолвер, лишенный этого недостатка(зато имеющий другие...).
На сегодняшний день он осуществляет только трансляцию имен в адреса и
для этого ему нужен nameserver, которому OOPS посылает запросы.
В конфиге может быть несколько строк nameserver. Запросы к ним
посылаются по очереди, начиная с первого. После отправки первого запроса
к первому серверу выдерживается небольшая пауза (в надежде что он ответит
и последующие запросы не понадобятся). Если ответа нет мы с увеличивающимся
интервалом начинаем периодически рассылать запросы всем серверам. Успешные
ответы кэшируются и хранятся в течение получаса для того, что-бы не
накладывать большую нагузку на nameserver.
Строки nameserver могут вовсе отсутствовать в конфиге, в этом
случае OOPS будет работать через gethostbyname, со всеми вытекающими
последствиями.
- bind
ip-адрес, на котором будут приниматься запросы. Если машина, на которой
работает OOPS имеет имеет несколько интерфейсов (или алиасов), то по умолчанию
будут приниматься соединения, приходящие на любой из этих адресов. Иногда
это неудобно. Например, Вы хотите, что-бы OOPS принимал соединения, приходящие
только на интерфейсе, обращенном в сторону Вашей локальной сети. В этом
случае в опции bind укажите имя хоста (или ip-адрес) на котором
OOPS должен слушать. Учтите, если интерфейса с указанным адресом на машине
нет, то эта опция не сработает, OOPS будет слушать на всех адресах.
- http_port
Это номер порта, на котором http-прокси будет принимать запросы. Эта
стока может отсутствовать, тогда будет использоваться умолчание: 3128.
Для того, что-бы отключть http-прокси можно использовать номер порта 0.
К этой опции так-же имеет отношение опция bind она указывает на
каком именно ip-адресе OOPS будет слушать (по умолчанию - на всех).
- icp_port
Номер порта, на котором принимаются ICP-запросы.
- connect-from
Если эта опция отсутствует, то OOPS при установлении соединения c
http-сервером OOPS не будет пытаться установить какого-либо адреса для
своего конца соединения. Это может быть неудобно: например, Ваша машина
имеет на эзернете два адреса, причем первым установлен адрес, который
резолвится не в имя proxy.yourdomain.tld. В этом случае исходящие
соединения, скорее всего, будут устанавливаться от неподходящего имени.
Для исправления этой ситуации служит connect-from - эта опция "фиксирует"
адрес с которого устанавливаются соединения.
- bind_acl
Это более гибкий вариант предыдущей директивы (за гибкость нужно платить
использование этой директивы увеличивает накладные расходы на обработку
каждого запроса). Эта директива работает следующим образом: если запрос
удовлетворяет указанноми ACL, то при соединении с http-сервером нашему
концу соединения будет присвоен соответствующий ip-адрес.i
Таких директив может быть несколько, каждый запрос проходит через
все перечисленные ACL в порядке появления в конфиге, до первого совпадения.
Если ни-одна строка не сработала, используется директива connect-from, а
если ее нет, то никакой привязки не производится.
- lo_mark
OOPS имеет двухуровневый кэш: кэш в памяти и кэш на диске. Во время
обслуживания запроса пользователя документ сначала ищется в памяти, затем
(в случае неудачи) - на диске. Любой вновь принимаемый документ сначала
помещается в in-memory кэш, откуда он рано или поздно может попасть на диск.
После старта программы обьем закэшированных в памяти документов начинает
расти. lo_mark устанавливает предел, до которого этот обьем модет дойти.
Как только этот предел достигнут, документы начинают сбрасываться на диск,
и этот процесс продолжается до тех пор, пока обьем документов в памяти
не вернется в нужные рамки. Кстати, именно поэтому если Вы запустили OOPS
на 10 минут и приняли через него 10 документов, то скорее всего на диске
никаких следов этих документов не обнаружится. Учтите так-же, что
максимальный суммарный размер документов не означает "допустимый размер
программы в памяти". Размер пограммы в памяти всегда больше чем lo_mark
и, как правило, раза в три превышает lo_mark. На размер программы в памяти
влияют такие параметры как maxresident, размер внутреннего кэша BerkeleyDB
и то, какую стратегию захвата/освобождения памяти используют функции
malloc/free.
Процесс подсчета суммарного обьема документов и сравнения с lo_mark
происходит раз в 10 секунд.
Т.о. рассматривайте lo_mark как как "хинт", указание на то, до каких
пределов программа может расти в памяти. Реальный размер будет в среднем
раза в три больше чем lo_mark.
- mem_max
Тоже предел на размер памяти. При сильной загрузке скорость поступления
кэшируемых документов может превысить скорость, с которой OOPS может
сбрасывать их на диск. при этом окажется, что OOPS будет безгранично
расти в памяти. mem_max предотвращает такую неприятность: если суммарный обьем
документов в памяти превысит mem_max, документы просто уничтожаются
в памяти, не попадая на диск (естественно до тех пор, пока обьем не
опустится до mem_max). При небольшой (и даже при средней) нагрузке
такого не происходит, поэтому не следует устанавливать mem_max слишком
близко к lo_mark. Соотношение mem_max = 2*lo_mark является вполне приемлемым.
- userid
хотя были приложены все усилия для того, что-бы программу нельзя было
использовать для взлома системы, Вы не обязаны верить в то, что эти усилия
увенчались успехом. Поэтому сразу после старта программа может сменить
текущий uid на uid непривилегированного пользователя для того, что-бы
последствия такого взлома были минимальными. Вы можете не использовать
эту опцию, тогда OOPS будет работать от имени того пользователя, от имени
которго он был запущен.
При использовании userid возникают некоторые ограничения на
процедуру реконфигурации. В частности, Вы не сможете создать новый порт
для приема соединений с номером порта ниже 1024.
Если Вы используете эту опцию - очень важно что-бы все файлы,
к кторым OOPS должен иметь доступ имели соответствующие права доступа для
выбранного пользователя.
Так-же важно, что-бы OOPS запускался от рута - это позволяет ему снять
ограничения, накладываемые системой на использование ресурсов: числа
открытых файлов, обьем используемой памяти и т.д. Если OOPS запускается
не от рута, то OOPS не сможет снять этих ограничений, что может быстро
привести к проблемам.
- stop_cache
Простейший (и самый быстрый) способ управления кэшируемостью документов.
Если эта инструкция есть в конфиге, то для любого запроса выполняется
следующая проверка: входит ли строка, фигурирующая в опции как подстрока в
путь, фигурирующий в запросе. Например директива 'stop_cache ?' предотвращает
кэширование любого URL вида http://hostname/path?request. Внимание!
сравнению подвергается только путь!
- local_domain
В случае, если используется какя-либо иерархия кэшей (icp или parent)
local_domain указывает, какие домены являются для Вас локальными и
удовлетворение запросов к этим доменам не требует взаимодействия с другими
кэшами.
- local_networks
Аналогично local_domain, но перечисляются сети, а не домены.
Использование local_networks с необходимостью приводит к тому, что во время
обработки каждого запроса приходится резолвить хостовую часть URL (даже
если после этого окажется, что запрос уйдет к перенту), что может привести к
замедлению работы. Так что, если возможно - избегайте этой опции.