11. Механизмы манипуляции данными

Механизмы манипуляции данными выполняют реальную работу по хранению и извлечению данных в ответ на запросы LDAP. Они могут быть статически скомпилированы в slapd , или, если включена поддержка модулей, они могут быть загружены динамически.

Если ваша инсталляция slapd использует динамические модули, вам может понадобиться добавить соответствующие директивы moduleload как показано в следующих примерах. Название модуля механизма манипуляции обычно указывается в форме:

Например, для загрузки механизма hdb Вам нужно указать:

Механизм hdb является механизмом для нормальной базы данных slapd . Для хранения данных он использует пакет Oracle Berkeley DB ( BDB ). Этот механизм позволяет широко применять индексирование и кэширование для ускорения доступа к данным (смотрите раздел Настройка производительности).

hdb  — это вариант оригинального механизма bdb , первоначально написанного для работы с BDB. hdb использует иерархическую структуру базы данных с поддержкой переименований на уровне поддеревьев. Во всём остальном его поведение аналогично поведению bdb , и к обоим применимы одинаковые параметры конфигурации.

Замечание: База данных hdb требует большого размера idlcachesize для хорошей производительности операций поиска, как правило в три раза или более превышающего cachesize (размер кэша записи).

Замечание: Механизм hdb вытеснил bdb , а скоро оба они будут считаться устаревшими в пользу нового механизма mdb . Смотрите ниже.

Подробности будут позже.

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

При работе сессий, подключающихся к базе данных back-ldap , для каждой из них всегда создается отдельное соединение к удаленному серверу LDAP. При этом анонимные сессии будут работать в рамках одного фактического анонимного подключения к удалённому серверу. Сессии, устанавливаемые с использованием какого-либо механизма авторизации, при использовании одного и того же DN также будут использовать одно фактическое подключение. Подобная стратегия группировки соединений в пул может повысить эффективность прокси-сервера за счет снижения накладных расходов при неоднократной установке/разрыве многочисленных однотипных соединений.

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

Данный механизм доступа очень часто используется многими другими механизмами манипуляции данными и наложениями.

Как было сказано выше, slapd-ldap(5) используется за кулисами многих других механизмов манипуляции данными и наложений. Часто они имеют лишь небольшое количество собственных настроек, но предоставляют администратору возможность использовать все настройки slapd-ldap(5) .

Например, Translucent Proxy (прозрачный прокси), получающий записи с удалённого LDAP-сервера с возможностью частичной их замены из определённой базы данных, имеет только четыре собственных специфических translucent- директивы настройки, однако может быть сконфигурирован с использованием всех стандартных настроек slapd-ldap(5) . За подробностями обратитесь к slapo-translucent(5) .

Другие наложения позволяют Вам добавлять директивы перед вызовом нормальных директив slapd-ldap(5) . Например, так происходит с наложением slapo-chain(5) :

"Существует совсем немного директив, специфичных для наложения сцепления; однако, директивы, имеющие отношение к механизму манипуляции данными ldap, который неявно вызывается этим наложением, могут иметь особое значение в случае их использования с этим наложением (то есть отличное от директив самого механизма манипуляции данными ldap). Они описаны в slapd-ldap(5), и к ним также нужно добавлять префикс chain-."

Также можно встретить применение механизма манипуляции данными slapd-ldap(5) в описании репликации, основанной на посылках, в соответствующем разделе данного руководства.

Как видите, механизм манипуляции данными slapd-ldap(5) чрезвычайно гибок и активно используется во всем ПО OpenLDAP.

Пример, приведённый ниже, очень прост, но и он показывает сильные стороны механизма манипуляции данными slapd-ldap(5) , достигаемые за счёт использования списка uri :

Список URI разделяется пробелами или запятыми. Всякий раз, когда первый в списке сервер не отвечает, список пересортируется таким образом, что первым оказывается отвечающий в данный момент сервер, и при следующем запросе первая попытка обращения будет уже к нему.

Эта особенность может быть использована для обеспечения балансировки нагрузки при репликации в режиме зеркала (MirrorMode).

Механизм манипуляции данными LDIF — это один из основных механизмов для slapd (8), который хранит записи в текстовых файлах в формате LDIF и использует файловую систему для создания древовидной структуры базы данных. Этот механизм низкопроизводителен, однако прост в использовании и нетребователен к ресурсам.

При использовании динамической конфигурации cn=config для хранения постоянной базы данных конфигурации используется как раз этот механизм манипуляции данными. За дополнительной информацией обращайтесь к slapd-config (5).

Как и многие другие механизмы манипуляции данными, механизм LDIF подключается всего несколькими строками конфигурации:

Проследим, что происходит при добавлении новой записи. Чтобы добавить dcObject для dc=suretecsystems,dc=com создадим файл suretec.ldif со следующим содержимым:

Теперь добавим его в наш каталог:

Посмотрим, что получилось в директории ./ldif :

Наконец, заглянем внутрь этого файла:

Данный полный формат можно получить при экспорте Вашего каталога с помощью slapcat .

Механизм slapd (8) mdb является первичным и рекомендуемым механизмом для нормальных баз данных slapd . Он предназначен для замены механизмов манипуляции данными Berkeley DB и использует для хранения данных собственную библиотеку OpenLDAP Lightning Memory-Mapped Database ( LMDB , высокоскоростная отображаемая в памяти база данных).

Как и механизмы BDB, он поддерживает индексирование, но не использует кэширование и не требует тонкой подстройки для обеспечения максимальной производительности поиска. Также как и hdb , этот механизм полностью иерархичен и поддерживает одновременное переименование поддеревьев.

В отличие от механизмов BDB, mdb может быть проинициализирован с помощью всего нескольких строк конфигурации:

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

Механизм манипуляции данными slapd (8) meta выполняет основные операции LDAP-проксирования для множества удалённых серверов LDAP, называемых "цели" ("targets"). Информация, содержащаяся на этих серверах, может быть представлена как принадлежащая к одному информационному дереву каталога ( DIT ).

Для понимания работы данного механизма рекомендуется разобраться в функционировании другого механизма —  slapd-ldap (5), поскольку данный механизм был разработан как усовершенствование механизма ldap. Оба этих механизма имеют много общих особенностей (в действительности, они разделяют также части исходного кода). Если механизм ldap предназначен для выполнения прокси-операций в отношении одного сервера, то механизм meta в основном предназначен для проксирования нескольких серверов с возможностью подмены пространства имён.

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

Механизм манипуляции данными slapd (8) monitor в действительности не является базой данных; если он активирован, в каталоге автоматически создаётся и динамически поддерживается ветка с информацией о текущем статусе демона slapd.

Для просмотра полных данных мониторинга нужно сделать поисковый запрос с базовым DN cn=Monitor и указанием необходимости получения атрибутов "+" и "*". Дело в том, что механизм манипуляции данными monitor позволяет отслеживать большинство операционных атрибутов, и, поскольку их очень много, LDAP возвращает только те из них, которые были явно запрошены. Запрос атрибута "+" — это метафора, запрашивающая все операционные атрибуты.

За дополнительной информацией обратитесь к разделу Мониторинг.

База данных monitor может быть подключена только один раз, то есть только одно включение "database monitor" может присутсвовать в файле slapd.conf(5) . Суффикс ветки мониторинга также автоматически назначается как "cn=Monitor" .

Однако вы можете установить rootdn и rootpw . В примере ниже Вы найдёте всё, что нужно для подключения механизма манипуляции данными monitor:

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

Замечание: Набор схемы core.schema должен быть подгружен, чтобы база данных monitor могла функционировать.

Вот небольшой пример данных, возвращаемых ldapsearch :

Чтобы посмотреть более развёрнутые примеры того, какая информация доступна с помощью данного механизма манипуляции данными, обратитесь к разделу Мониторинг.

Механизм манипуляции данными slapd (8) Null — безусловно, самая полезная часть slapd:

• Поисковые запросы возвращают код успешного завершения, но записей не возвращают.
• Запросы на сравнение возвращают compareFalse.
• Запросы на обновление возвращают код успешного завершения (если, конечно, не включен режим "только для чтения"), но ничего не делают.
• Подключения не от rootdn заканчиваются неудачей, если не была указана директива "bind on" в секции database.
• Весьма интересно также поведение инструментов slapadd(8) and slapcat(8).

На создание данного механизма вдохновило устройство /dev/null .

Этот механизм обладает, пожалуй, самой простой и короткой настройкой, какую Вам когда-либо приходилось делать. Чтобы его протестировать, Ваш файл slapd.conf должен выглядеть примерно так:

bind on означает:

"Разрешается подключение от имени любого DN в данном суффиксе с любым паролем. Значение по умолчанию "off"."

Протестируем данных механизм с помощью ldapsearch :

Механизм манипуляции данными slapd (8) PASSWD предназначен для отображения учётных данных, перечисленных в системном файле passwd (5) (по умолчанию это /etc/passwd ).

Данный механизм предоставляется только в демонстрационных целях. DN каждой записи выглядит так: "uid=<username>,<suffix>".

Настройка данного механизма slapd.conf длиннее, чем предыдущего, но совсем немного:

Результат запроса с помощью ldapsearch будет примерно такой:

Механизм манипуляции данными slapd (8) Perl встраивает в slapd (8) интерпретатор perl (1). В каждой секции database perl конфигурационного файла slapd.conf (5) должно быть определено какие модули Perl следует использовать. Затем slapd создаёт новый объект Perl, который обрабатывает все запросы, относящиеся к данному экземпляру настроек механизма манипуляции данными.

Механизм манипуляции данными slapd (8) Shell вызывает внешние программы для выполнения операций. Он разработан, чтобы облегчить привязку уже существующих баз данных к интерфейсу запросов slapd. Этот механизм предназначен, прежде всего, для использования в прототипах.

slapd-shell (5) и slapd-perl (5)

Основное назначение данного механизма манипуляции данными slapd (8) — отображение пространства имён, определённого в базе данных этого же экземпляра slapd (8), в виртуальное пространство имён, с выполнением, если это необходимо, манипуляций над типами атрибутов и объектными классами. Для его работы требуется наложение rwm.

Этот механизм и вышеупомянутое наложение являются экспериментальными.

Основное назначение данного механизма манипуляции данными slapd (8) — представить информацию, хранящуюся в некоторой реляционной СУБД как поддерево LDAP без написания какого-либо программного кода (не будем принимать за программный код немного SQL и, возможно, хранимых процедур, верно?).

Где этому можно найти применение? К примеру, Вы (или некий поставщик услуг) храните учётные записи (адресные книги, телефонные справочники) в СУБД, и Вам хотелось бы использовать эти же данные в современных приложениях, ожидающих получить их из LDAP. Возможно, Вам нужно синхронизировать (или предоставить в общий доступ) информацию между различными сайтами/приложениями, использующими СУБД и/или LDAP. Или еще что-нибудь.

Отметим, что данный механизм НЕ разрабатывался в качестве полнофункционального механизма манипуляции данными, использующего реляционную СУБД вместо BerkeleyDB (то есть с полной поддержкой функциональности LDAP, как это делает стандартный механизм BDB). Его стоит рассматривать как механизм манипуляции данными с рядом ограничений. Дискуссию на этот счёт можно посмотреть в разделе Непростые взаимоотношения LDAP и реляционных СУБД.

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

Механизм SQL способен настраиваться под практически любую реляционную схему, без внесения в неё изменений (с помощью вышеупомянутой мета-информации). Для подключения к СУБД он использует ODBC, кроме того есть возможность подстройки под любой SQL-диалет, используемый в СУБД. Таким образом, он может быть использован для интеграции и распространения информации на любой СУБД, ОС, сетевом хосте и т.д., то есть в высокогетерогенной среде.

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

Настройка данного механизма одна из самых сложных и комплексных среди рассматриваемых нами. Поэтому здесь мы рассмотрим небольшой простой пример, идущий с дистрибутивом OpenLDAP, который можно найти в servers/slapd/back-sql/rdbms_depend/README

В этом примере будем использовать PostgreSQL.

Во-первых, добавим в /etc/odbc.ini такой блок настроек:

Информация, имеющая непосредственное отношение к нашему примеру, подсвечена стрелками '<===' справа.

Затем добавим в /etc/odbcinst.ini такой блок настроек:

Предполагается, что Вам известно, как в PostgreSQL создать базу данных, учётную запись пользователя и назначить ей пароль. Также предполагается, что Вы сможете наполнить созданную Вами базу данных 'example' с помощью следующих файлов из директории servers/slapd/back-sql/rdbms_depend/pgsql :

Наконец, запустим тест:

На выходе будет что-то вроде этого (урезано в целях экономии места):

Данный тест выполняется в режиме "только чтения" данных; он может быть применим к любой реляционной СУБД.

Другой тест (на запись), sql-test900-write, на сегодняшний момент может быть выполнен только в PostgreSQL и IBM db2.

Чтобы получить больше информации, посмотрите sql-test000 , файлы в директории servers/slapd/back-sql/rdbms_depend/pgsql/ и man-страницы.