[ новости /+++ | форум | теги | ]

НАЗВАНИЕ

ОБЗОР

ОПИСАНИЕ

Шаблон определяется путём указания строки фильтра, а также индекса, идентифицирующего набор атрибутов. Строка шаблона для запроса может быть получена путём удаления значений утверждения из представленного в формате RFC 4515 поискового фильтра этого запроса. Запрос считается удовлетворяющим шаблону, если его строка шаблона и набор предполагаемых для получения атрибутов соответствуют предназначенному для кэширования шаблону. Примеры строки шаблона: (mail=), (|(sn=)(cn=)), (&(sn=)(givenName=)).

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

overlay pcache

Данная директива добавляет наложение кэширующего прокси к текущей базе данных механизма манипуляции данными. Наложение кэширующего прокси может использоваться с любым механизмом манипуляции данными, однако предназначено для использования с механизмами ldap, meta, и sql. Обратите внимание, что в базе данных, к которой применяется это наложение, должна быть настроена директива rootdn.

pcache <database> <max_entries> <numattrsets> <entry_limit> <cc_period>

Эта директива включает прокси-кэширование в текущей базе данных и задаёт основные параметры кэша. Механизм манипуляции данными, указанный в параметре <database>, будет использоваться подспудно для сохранения кэшированных записей. Выбранная база данных также должна быть настроена, как показано ниже. Ротация записей в кэше начинается, когда размер кэша достигает количества записей <max_entries>, и продолжается до тех пор, пока количество записей в кэше не станет меньше этого значения. Значение <numattrsets> должно совпадать с количеством последующих директив pcacheAttrset. Запросы кэшируются, только если они соответствуют шаблону запросов, подлежащих кэшированию (задаётся директивой pcacheTemplate), и количество возвращаемых на этот запрос записей меньше, чем значение <entry_limit>. Проверка целостности выполняется каждый раз по прошествии периода <cc_period> (задаётся в секундах). В каждом цикле запросы с просроченным "временем жизни" (TTL) удаляются. Пример конфигурации кэша:

pcache mdb 10000 1 50 100

pcacheAttrset <index> <attrs...>

Используется для связывания набора атрибутов <attrs..> с индексом <index>. Каждый набор атрибутов связан с целым числом от 0 до <numattrsets>-1. Эти индексы используются директивой pcacheTemplate для определения шаблонов запросов, подлежащих кэшированию. Набор атрибутов не может быть пустым. Набор атрибутов может содержать специальные атрибуты "*" (все пользовательские атрибуты), "+" (все операционные атрибуты) или оба этих шаблона атрибутов; в последнем случае указание любого другого атрибута будет избыточным и для ясности их указывать не следует. Набор атрибутов может состоять из единственного атрибута "1.1"; в этом случае в кэш помещается только факт наличия записи. Для атрибутов с префиксом "undef:" не требуется их наличия в схеме данных каталога.

pcacheMaxQueries <queries>

Указывает максимальное количество запросов, которые можно кэшировать. Значение по умолчанию - 10000.

pcacheValidate { TRUE | FALSE }

Указывает, необходимо ли выполнять проверку того, что результаты предназначенного для кэширования запроса могут впоследствии быть без ошибок возвращены из кэша DSA прокси-сервера. При включении этого параметра записи, возвращаемые предназначенным для кэширования запросом, перед помещением к кэш проверяются на предмет для обеспечения согласованности со схемой данных, известной DSA прокси-сервера. В случае обнаружения несогласованности данный запрос не кэшируется. По умолчанию такая проверка отключена.

pcacheOffline { TRUE | FALSE }

Переводит кэш в автономный режим. В автономном режиме прекращается проверка согласованности кэша с удалённым сервером и проверка истечения срока действия записей. Это позволяет использовать содержимое кэша неопределённое количество времени, пока у прокси-сервера нет доступа по сети к удалённому DSA. Значение по умолчанию - FALSE, то есть проверки согласованности и истечения срока действия записей выполняются.

pcachePersist { TRUE | FALSE }

Указывает, должны ли закэшированные запросы сохраняться при перезапуске кэширующего прокси для обеспечения "горячего" запуска кэша. Повторно загружаются только запросы с неистекшим временем жизни. Значение по умолчанию - FALSE.

ПРЕДОСТЕРЕЖЕНИЕ: Конечно же, конфигурация кэширующего прокси не должна меняться при перезапуске; наложение pcache не выполняет никаких проверок целостности по этому поводу. Точнее говоря, данную опцию следует отключить, если порядок или содержимое существующих директив pcacheAttrset и pcacheTemplate изменялись. Если же были добавлены новые наборы атрибутов и шаблоны, либо изменились другие настройки наложения pcache, это не должно повлиять на данную настройку.

pcacheTemplate <template_string> <attrset_index> <ttl> [<negttl> [<limitttl> [<ttr>]]]

Определяет шаблон запроса, подлежащего кэшированию, а также "время жизни" <ttl> для запросов, удовлетворяющих этому шаблону. Опциональное значение <negttl> может использоваться для указания того, что запросы с негативными результатами (то есть в ответ на которые было возвращено ноль записей) также следует кэшировать на указанное время. По умолчанию запросы с негативными результатами не кэшируются (<negttl> установлено в 0). Опциональное значение <limitttl> может использоваться для указания того, что запросы, в результате которых было превышено ограничение по размеру, также следует кэшировать на указанное время. По умолчанию запросы с превышением ограничений по размеру не кэшируются (<limitttl> установлено в 0). Опциональное значение <ttr> ("время перезагрузки") может использоваться для указания того, что закэшированные записи следует автоматически перезагружать по истечении определенного времени. Записи перезагружаются только в том случае, если они не просрочены, то есть, чтобы данная настройка приносила пользу, значение <ttl> должно быть больше значения <ttr>. По умолчанию записи в кэше не перезагружаются (<ttr> установлено в 0).

pcacheBind <filter_template> <attrset_index> <ttr> <scope> <base>

Определяет шаблон для кэширования удостоверяющих данных, используемых для выполнения простого подсоединения (Simple Bind) на основе заранее определённого в директиве pcacheTemplate шаблона. Строка <filter_template> аналогична строке <template_string>, за исключением того, что некоторые значения в ней могут присутствовать. Предназначение этого параметра - позволить наложению сгенерировать фильтр по аналогии с тем, который генерируют сторонние приложения при выполнении поиска, непосредственно предшествующего операции Bind. Например, если клиентское приложение типа nss_ldap настроено на поиск пользователя с фильтром "(&(objectClass=posixAccount)(uid=<username>))", то в параметре <filter_template> следует использовать шаблон "(&(objectClass=posixAccount)(uid=))". При конвертации в стандартную строку шаблона "(&(objectClass=)(uid=))", полученная строка, а также набор атрибутов с индексом <attrset_index> должны совпасть с уже определённым в директиве pcacheTemplate условием. Значение "время перезагрузки" <ttr> определяет интервал времени, по истечении которого закэшированные удостоверяющие данные могут быть перезагружены. Первый запрос Bind, выполненный по прошествии этого времени, запустит попытку перезагрузки. Если кэш находится в автономном режиме, перезагрузка не выполняется. Для удостоверяющих данных Bind не предусмотрено отдельного параметра "время жизни", они считаются просроченными в соответствии со значением <ttl> директивы pcacheTemplate. Значения <scope> и <base> должны совпадать с диапазоном и базой поиска, используемыми клиентом, производящим аутентификацию. Закэшированные удостоверяющие данные хранятся не в виде открытого текста, а хэшируются с использованием алгоритма по умолчанию, применяемого для хэширования паролей. По умолчанию кэширование удостоверяющих данных Bind отключено.

pcachePosition { head | tail }

Указывает, должна ли функция обработки ответа данного наложения располагаться в конце (tail) списка вызова таких функций (поведение по умолчанию), или в его начале (head) (а точнее, там, где она должна располагаться согласно последовательности помещения наложений в стек). Данная настройка влияет на то, как наложение pcache взаимодействует с другими наложениями, поскольку наложение кэширующего прокси должно выполняться как можно раньше (и, следовательно, присутствовать в настройках как можно позже), чтобы иметь шанс вернуть закэшированные результаты. С другой стороны, при раннем выполнении в обработке ответа, оно будет кэшировать записи, которые позже могут быть преобразованы другими наложениями базы данных, и потому в первый раз такие записи будут возращены в состоянии после преобразования, а после кэширования эти же записи будут возвращаться в состоянии до преобразования.

Существуют некоторые ограничения:

все числовые значения должны быть положительными числами;

значение <entry_limit> должно быть меньше или равным <max_entries>;

с помощью директивы pcacheAttrset ДОЛЖНО быть определено <numattrsets> наборов атрибутов;

на каждый набор атрибутов ДОЛЖНА указывать хотя бы одна директива pcacheTemplate;

Следующие директивы добавляют шаблон со строкой фильтра (&(sn=)(givenName=)), атрибутами mail, postaladdress, telephonenumber и TTL 1 час.

pcacheAttrset 0 mail postaladdress telephonenumber
pcacheTemplate (&(sn=)(givenName=)) 0 3600

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

directory /var/tmp/cache
cachesize 100

Могут быть использованы любые директивы, относящиеся к выбранному типу баз данных. Для обрабатываемых запросов следует настроить соответствующие индексы. Кроме того, следует настроить индекс equality для атрибута pcacheQueryid для упрощения удаления данных просроченных запросов.  

ОБРАТНАЯ СОВМЕСТИМОСТЬ

proxycache

используйте pcache

proxyattrset

используйте pcacheAttrset

proxycachequeries

используйте pcacheMaxQueries

proxycheckcacheability

используйте pcacheValidate

proxysavequeries

используйте pcachePersist

proxytemplate

используйте pcacheTemplate

response-callback

используйте pcachePosition

ПРЕДОСТЕРЕЖЕНИЯ

Удалённый сервер должен предоставлять атрибут objectClass, поскольку он может понадобиться в базе данных, хранящей закэшированные записи, для оптимальной локальной обработки этих записей.

На прокси-сервере в полном объёме должна поддерживаться схема данных каталога, требуемая для обработки кэшируемых записей. В большей степени это относится к определению в схеме данных тех типов атрибутов, которые используются в шаблонах запросов. Если в шаблоне запроса используется атрибут objectClass, в схеме данных прокси-сервера требуется наличие определения объектных классов тех записей, которые, предположительно, попадут в кэш. Ответственность за приведение схемы данных прокси-сервера в соответствие со схемой данных удалённого сервера лежит на администраторе прокси-сервера.

Ещё одно потенциальное (и тонкое) несоответствие может возникнуть, когда данные извлекаются с удалённого сервера от имени разных идентификационных сущностей и на удалённом сервере настроен специфичный для разных идентификационных сущностей контроль доступа. Если данные были излечены от имени идентификационной сущности, для которой правилами доступа на удалённом сервере разрешено получение лишь частичных результатов, другие пользователи, привилегии доступа которых на удалённом сервере отличаются, получат разные результаты при прямом обращении к удалённому серверу и из кэша. Если у этих пользователей на удалённом сервере более высокие привилегии, то из кэша они получат лишь подмножество тех результатов, которые могли бы получить с удалённого сервера. Если же их привилегии ниже, они получат из кэша больше того, что могли бы получить непосредственно с удалённого сервера. И то и другое может быть как приемлемым, так и неприемлемым, в зависимости от политик безопасности кэша и удалённого сервера. Важно понимать, что в этом случае прокси-сервер нарушает политику безопасности удалённого сервера за счёт раскрытия одной идентификационной сущности данных, собранных другой идентификационной сущностью. По этой причине, при совместном использовании кэширующего прокси сервера с механизмом back-ldap, предлагается для кэширования использовать функционал утверждения идентификационной сущности (identity assertion) slapd-ldap(5) (смотрите описание настроек idassert-bind и idassert-authz), таким образом, чтобы опрос удалённого сервера происходил от имени фиктивной идентификационной сущности, обладающей относительно высокими привилегиями доступа на поиск (search) и чтение (read), а "реальный" контроль доступа делегировался ACL прокси-сервера. Имейте ввиду, что поскольку кэширующему прокси доступна только закэшированная часть реальных данных, может оказаться невозможным установить в точности те же правила доступа, что и на удалённом сервере. Когда обеспечение безопасности каталога имеет важное значение, правила доступа для кэширующего прокси-сервера должны быть тщательно спроектированы.  

ФАЙЛЫ

/usr/local/etc/openldap/slapd.conf

конфигурационный файл slapd по умолчанию.

СМОТРИТЕ ТАКЖЕ

АВТОРЫ

Index

НАЗВАНИЕ

ОБЗОР

ОПИСАНИЕ

ОБРАТНАЯ СОВМЕСТИМОСТЬ

ПРЕДОСТЕРЕЖЕНИЯ

ФАЙЛЫ

СМОТРИТЕ ТАКЖЕ

АВТОРЫ

Партнёры:

Хостинг: