11. Механизмы манипуляции данными
Механизмы манипуляции данными выполняют реальную работу по хранению и извлечению данных в ответ на запросы LDAP. Они могут быть статически скомпилированы в slapd, или, если включена поддержка модулей, они могут быть загружены динамически.
Если ваша инсталляция slapd использует динамические модули, вам может понадобиться добавить соответствующие директивы moduleload как показано в следующих примерах. Название модуля механизма манипуляции обычно указывается в форме:
back_<имя механизма>.la
Например, для загрузки механизма hdb Вам нужно указать:
moduleload back_hdb.la
11.1. Механизмы Berkeley DB
11.1.1. Обзор
Механизм hdb является механизмом для нормальной базы данных slapd. Для хранения данных он использует пакет Oracle Berkeley DB (
hdb — это вариант оригинального механизма bdb, первоначально написанного для работы с BDB. hdb использует иерархическую структуру базы данных с поддержкой переименований на уровне поддеревьев. Во всём остальном его поведение аналогично поведению bdb, и к обоим применимы одинаковые параметры конфигурации.
Замечание: База данных hdb требует большого размера idlcachesize для хорошей производительности операций поиска, как правило в три раза или более превышающего cachesize (размер кэша записи).
Замечание: Механизм hdb вытеснил bdb, а скоро оба они будут считаться устаревшими в пользу нового механизма mdb. Смотрите ниже.
11.1.2. Настройка back-bdb/back-hdb
Подробности будут позже.
11.1.3. Дополнительная информация
slapd-bdb(5)
11.2. LDAP
11.2.1. Обзор
Механизм slapd LDAP в действительности не является базой данных; вместо этого он выступает как прокси для перенаправления входящих запросов на другой сервер LDAP. Во время обработки запроса происходит также разрешение ссылок, то есть ссылки обрабатываются полностью, а не возвращаются LDAP-клиенту.
При работе сессий, подключающихся к базе данных back-ldap, для каждой из них всегда создается отдельное соединение к удаленному серверу LDAP. При этом анонимные сессии будут работать в рамках одного фактического анонимного подключения к удалённому серверу. Сессии, устанавливаемые с использованием какого-либо механизма авторизации, при использовании одного и того же DN также будут использовать одно фактическое подключение. Подобная стратегия группировки соединений в пул может повысить эффективность прокси-сервера за счет снижения накладных расходов при неоднократной установке/разрыве многочисленных однотипных соединений.
Также механизм манипуляции ldap может использоваться для получения какой-либо дополнительной информации из службы каталогов, для этого на удалённый сервер передаются данные аутентификации локально-авторизованных клиентов, возможно в несколько изменённой форме. С этой целью прокси присоединяет к удалённому серверу под учетной записью с административными правами и, если необходимо, запрашивает данные для той учётной записи, которую ему подали на вход.
Данный механизм доступа очень часто используется многими другими механизмами манипуляции данными и наложениями.
11.2.2. Настройка back-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:
database ldap
suffix "dc=suretecsystems,dc=com"
rootdn "cn=slapd-ldap"
uri ldap://localhost/ ldap://remotehost ldap://remotehost2
Список URI разделяется пробелами или запятыми. Всякий раз, когда первый в списке сервер не отвечает, список пересортируется таким образом, что первым оказывается отвечающий в данный момент сервер, и при следующем запросе первая попытка обращения будет уже к нему.
Эта особенность может быть использована для обеспечения балансировки нагрузки при репликации в режиме зеркала (MirrorMode).
11.2.3. Дополнительная информация
slapd-ldap(5)
11.3. LDIF
11.3.1. Обзор
Механизм манипуляции данными LDIF — это один из основных механизмов для slapd(8), который хранит записи в текстовых файлах в формате LDIF и использует файловую систему для создания древовидной структуры базы данных. Этот механизм низкопроизводителен, однако прост в использовании и нетребователен к ресурсам.
При использовании динамической конфигурации cn=config для хранения постоянной базы данных конфигурации используется как раз этот механизм манипуляции данными. За дополнительной информацией обращайтесь к slapd-config(5).
11.3.2. Настройка back-ldif
Как и многие другие механизмы манипуляции данными, механизм LDIF подключается всего несколькими строками конфигурации:
include ./schema/core.schema
database ldif
directory ./ldif
suffix "dc=suretecsystems,dc=com"
rootdn "cn=LDIF,dc=suretecsystems,dc=com"
rootpw LDIF
Проследим, что происходит при добавлении новой записи. Чтобы добавить dcObject для dc=suretecsystems,dc=com создадим файл suretec.ldif со следующим содержимым:
dn: dc=suretecsystems,dc=com objectClass: dcObject objectClass: organization dc: suretecsystems o: Suretec Systems Ltd
Теперь добавим его в наш каталог:
ldapadd -x -H ldap://localhost:9011 -f suretec.ldif -D "cn=LDIF,dc=suretecsystems,dc=com" -w LDIF adding new entry "dc=suretecsystems,dc=com"
Посмотрим, что получилось в директории ./ldif:
ls ./ldif dc=suretecsystems,dc=com.ldif
Наконец, заглянем внутрь этого файла:
cat ldif/dc\=suretecsystems\,dc\=com.ldif dn: dc=suretecsystems objectClass: dcObject objectClass: organization dc: suretecsystems o: Suretec Systems Ltd. structuralObjectClass: organization entryUUID: 2134b714-e3a1-102c-9a15-f96ee263886d creatorsName: cn=LDIF,dc=suretecsystems,dc=com createTimestamp: 20080711142643Z entryCSN: 20080711142643.661124Z#000000#000#000000 modifiersName: cn=LDIF,dc=suretecsystems,dc=com modifyTimestamp: 20080711142643Z
Данный полный формат можно получить при экспорте Вашего каталога с помощью slapcat.
11.3.3. Дополнительная информация
slapd-ldif(5)
11.4. LMDB
11.4.1. Обзор
Механизм slapd(8) mdb является первичным и рекомендуемым механизмом для нормальных баз данных slapd. Он предназначен для замены механизмов манипуляции данными Berkeley DB и использует для хранения данных собственную библиотеку OpenLDAP Lightning Memory-Mapped Database (
Как и механизмы BDB, он поддерживает индексирование, но не использует кэширование и не требует тонкой подстройки для обеспечения максимальной производительности поиска. Также как и hdb, этот механизм полностью иерархичен и поддерживает одновременное переименование поддеревьев.
11.4.2. Настройка back-mdb
В отличие от механизмов BDB, mdb может быть проинициализирован с помощью всего нескольких строк конфигурации:
include ./schema/core.schema
database mdb
directory ./mdb
suffix "dc=suretecsystems,dc=com"
rootdn "cn=mdb,dc=suretecsystems,dc=com"
rootpw mdb
maxsize 1073741824
В дополнение к обычным параметрам, необходимым для минимальной конфигурации, механизм mdb требует указания максимального размера. Он задаётся в байтах и должен быть больше ожидаемого размера базы данных, даже с учётом её прироста. В файловой системе также должно быть достаточно свободного места для размещения базы такого размера.
11.4.3. Дополнительная информация
11.5. Метакаталог
11.5.1. Обзор
Механизм манипуляции данными slapd(8) meta выполняет основные операции LDAP-проксирования для множества удалённых серверов LDAP, называемых "цели" ("targets"). Информация, содержащаяся на этих серверах, может быть представлена как принадлежащая к одному информационному дереву каталога (
Для понимания работы данного механизма рекомендуется разобраться в функционировании другого механизма — slapd-ldap(5), поскольку данный механизм был разработан как усовершенствование механизма ldap. Оба этих механизма имеют много общих особенностей (в действительности, они разделяют также части исходного кода). Если механизм ldap предназначен для выполнения прокси-операций в отношении одного сервера, то механизм meta в основном предназначен для проксирования нескольких серверов с возможностью подмены пространства имён.
Эти функции, безусловно полезные во многих ситуациях, могут привести к чрезмерному расходу ресурсов для некоторых приложений, поэтому использование данного механизма должно быть тщательно продумано.
11.5.2. Настройка back-meta
БУДЕТ ПОЗЖЕ
11.5.3. Дополнительная информация
slapd-meta(5)
11.6. Мониторинг
11.6.1. Обзор
Механизм манипуляции данными slapd(8) monitor в действительности не является базой данных; если он активирован, в каталоге автоматически создаётся и динамически поддерживается ветка с информацией о текущем статусе демона slapd.
Для просмотра полных данных мониторинга нужно сделать поисковый запрос с базовым DN cn=Monitor и указанием необходимости получения атрибутов "+" и "*". Дело в том, что механизм манипуляции данными monitor позволяет отслеживать большинство операционных атрибутов, и, поскольку их очень много, LDAP возвращает только те из них, которые были явно запрошены. Запрос атрибута "+" — это метафора, запрашивающая все операционные атрибуты.
За дополнительной информацией обратитесь к разделу Мониторинг.
11.6.2. Настройка back-monitor
База данных monitor может быть подключена только один раз, то есть только одно включение "database monitor" может присутсвовать в файле slapd.conf(5). Суффикс ветки мониторинга также автоматически назначается как "cn=Monitor".
Однако вы можете установить rootdn и rootpw. В примере ниже Вы найдёте всё, что нужно для подключения механизма манипуляции данными monitor:
include ./schema/core.schema
database monitor
rootdn "cn=monitoring,cn=Monitor"
rootpw monitoring
Также вы можете назначить этой базе данных контроль доступа так же, как и любой другой, например:
access to dn.subtree="cn=Monitor"
by dn.exact="uid=Admin,dc=my,dc=org" write
by users read
by * none
Замечание: Набор схемы core.schema должен быть подгружен, чтобы база данных monitor могла функционировать.
Вот небольшой пример данных, возвращаемых ldapsearch:
ldapsearch -x -H ldap://localhost:9011 -b 'cn=Monitor'
# extended LDIF
#
# LDAPv3
# base <cn=Monitor> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# Monitor
dn: cn=Monitor
objectClass: monitorServer
cn: Monitor
description: This subtree contains monitoring/managing objects.
description: This object contains information about this server.
description: Most of the information is held in operational attributes, which
must be explicitly requested.
# Backends, Monitor
dn: cn=Backends,cn=Monitor
objectClass: monitorContainer
cn: Backends
description: This subsystem contains information about available backends.
Чтобы посмотреть более развёрнутые примеры того, какая информация доступна с помощью данного механизма манипуляции данными, обратитесь к разделу Мониторинг.
11.6.3. Дополнительная информация
slapd-monitor(5)
11.7. Null
11.7.1. Обзор
Механизм манипуляции данными slapd(8) Null — безусловно, самая полезная часть slapd:
- Поисковые запросы возвращают код успешного завершения, но записей не возвращают.
- Запросы на сравнение возвращают compareFalse.
- Запросы на обновление возвращают код успешного завершения (если, конечно, не включен режим "только для чтения"), но ничего не делают.
- Подключения не от rootdn заканчиваются неудачей, если не была указана директива "bind on" в секции database.
- Весьма интересно также поведение инструментов slapadd(8) and slapcat(8).
На создание данного механизма вдохновило устройство /dev/null.
11.7.2. Настройка back-null
Этот механизм обладает, пожалуй, самой простой и короткой настройкой, какую Вам когда-либо приходилось делать. Чтобы его протестировать, Ваш файл slapd.conf должен выглядеть примерно так:
database null
suffix "cn=Nothing"
bind on
bind on означает:
"Разрешается подключение от имени любого DN в данном суффиксе с любым паролем. Значение по умолчанию "off"."
Протестируем данных механизм с помощью ldapsearch:
ldapsearch -x -H ldap://localhost:9011 -D "uid=none,cn=Nothing" -w testing -b 'cn=Nothing'
# extended LDIF
#
# LDAPv3
# base <cn=Nothing> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
11.7.3. Дополнительная информация
slapd-null(5)
11.8. Passwd
11.8.1. Обзор
Механизм манипуляции данными slapd(8) PASSWD предназначен для отображения учётных данных, перечисленных в системном файле passwd(5) (по умолчанию это /etc/passwd).
Данный механизм предоставляется только в демонстрационных целях. DN каждой записи выглядит так: "uid=<username>,<suffix>".
11.8.2. Настройка back-passwd
Настройка данного механизма slapd.conf длиннее, чем предыдущего, но совсем немного:
include ./schema/core.schema
database passwd
suffix "cn=passwd"
Результат запроса с помощью ldapsearch будет примерно такой:
ldapsearch -x -H ldap://localhost:9011 -b 'cn=passwd'
# extended LDIF
#
# LDAPv3
# base <cn=passwd> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# passwd
dn: cn=passwd
cn: passwd
objectClass: organizationalUnit
# root, passwd
dn: uid=root,cn=passwd
objectClass: person
objectClass: uidObject
uid: root
cn: root
sn: root
description: root
11.8.3. Дополнительная информация
slapd-passwd(5)
11.9. Perl/Shell
11.9.1. Обзор
Механизм манипуляции данными slapd(8) Perl встраивает в slapd(8) интерпретатор perl(1). В каждой секции database perl конфигурационного файла slapd.conf(5) должно быть определено какие модули Perl следует использовать. Затем slapd создаёт новый объект Perl, который обрабатывает все запросы, относящиеся к данному экземпляру настроек механизма манипуляции данными.
Механизм манипуляции данными slapd(8) Shell вызывает внешние программы для выполнения операций. Он разработан, чтобы облегчить привязку уже существующих баз данных к интерфейсу запросов slapd. Этот механизм предназначен, прежде всего, для использования в прототипах.
11.9.2. Настройка back-perl/back-shell
БУДЕТ ПОЗЖЕ
11.9.3. Дополнительная информация
slapd-shell(5) и slapd-perl(5)
11.10. Транслятор
11.10.1. Обзор
Основное назначение данного механизма манипуляции данными slapd(8) — отображение пространства имён, определённого в базе данных этого же экземпляра slapd(8), в виртуальное пространство имён, с выполнением, если это необходимо, манипуляций над типами атрибутов и объектными классами. Для его работы требуется наложение rwm.
Этот механизм и вышеупомянутое наложение являются экспериментальными.
11.10.2. Настройка back-relay
БУДЕТ ПОЗЖЕ
11.10.3. Дополнительная информация
slapd-relay(5)
11.11. SQL
11.11.1. Обзор
Основное назначение данного механизма манипуляции данными slapd(8) — представить информацию, хранящуюся в некоторой реляционной СУБД как поддерево LDAP без написания какого-либо программного кода (не будем принимать за программный код немного SQL и, возможно, хранимых процедур, верно?).
Где этому можно найти применение? К примеру, Вы (или некий поставщик услуг) храните учётные записи (адресные книги, телефонные справочники) в СУБД, и Вам хотелось бы использовать эти же данные в современных приложениях, ожидающих получить их из LDAP. Возможно, Вам нужно синхронизировать (или предоставить в общий доступ) информацию между различными сайтами/приложениями, использующими СУБД и/или LDAP. Или еще что-нибудь...
Отметим, что данный механизм НЕ разрабатывался в качестве полнофункционального механизма манипуляции данными, использующего реляционную СУБД вместо BerkeleyDB (то есть с полной поддержкой функциональности LDAP, как это делает стандартный механизм BDB). Его стоит рассматривать как механизм манипуляции данными с рядом ограничений. Дискуссию на этот счёт можно посмотреть в разделе Непростые взаимоотношения LDAP и реляционных СУБД.
Идея состоит в использовании некой мета-информации для трансляции LDAP-запросов в SQL-запросы, оставляя нетронутой реляционную схему данных, чтобы старые приложения могли и дальше ее использовать без внесения в них изменений. Это позволяет SQL- и LDAP-приложениям взаимодействовать и обмениваться данными друг с другом без репликации.
Механизм SQL способен настраиваться под практически любую реляционную схему, без внесения в неё изменений (с помощью вышеупомянутой мета-информации). Для подключения к СУБД он использует ODBC, кроме того есть возможность подстройки под любой SQL-диалет, используемый в СУБД. Таким образом, он может быть использован для интеграции и распространения информации на любой СУБД, ОС, сетевом хосте и т.д., то есть в высокогетерогенной среде.
Данный механизм хранения и доступа к данным является экспериментальным.
11.11.2. Настройка back-sql
Настройка данного механизма одна из самых сложных и комплексных среди рассматриваемых нами. Поэтому здесь мы рассмотрим небольшой простой пример, идущий с дистрибутивом OpenLDAP, который можно найти в servers/slapd/back-sql/rdbms_depend/README
В этом примере будем использовать PostgreSQL.
Во-первых, добавим в /etc/odbc.ini такой блок настроек:
[example] <===
Description = Example for OpenLDAP's back-sql
Driver = PostgreSQL
Trace = No
Database = example <===
Servername = localhost
UserName = manager <===
Password = secret <===
Port = 5432
;Protocol = 6.4
ReadOnly = No
RowVersioning = No
ShowSystemTables = No
ShowOidColumn = No
FakeOidIndex = No
ConnSettings =
Информация, имеющая непосредственное отношение к нашему примеру, подсвечена стрелками '<===' справа.
Затем добавим в /etc/odbcinst.ini такой блок настроек:
[PostgreSQL]
Description = ODBC for PostgreSQL
Driver = /usr/lib/libodbcpsql.so
Setup = /usr/lib/libodbcpsqlS.so
FileUsage = 1
Предполагается, что Вам известно, как в PostgreSQL создать базу данных, учётную запись пользователя и назначить ей пароль. Также предполагается, что Вы сможете наполнить созданную Вами базу данных 'example' с помощью следующих файлов из директории servers/slapd/back-sql/rdbms_depend/pgsql :
backsql_create.sql, testdb_create.sql, testdb_data.sql, testdb_metadata.sql
Наконец, запустим тест:
[root@localhost]# cd $SOURCES/tests
[root@localhost]# SLAPD_USE_SQL=pgsql ./run sql-test000
На выходе будет что-то вроде этого (урезано в целях экономии места):
Cleaning up test run directory leftover from previous run.
Running ./scripts/sql-test000-read...
running defines.sh
Starting slapd on TCP/IP port 9011...
Testing SQL backend read operations...
Waiting 5 seconds for slapd to start...
Testing correct bind... dn:cn=Mitya Kovalev,dc=example,dc=com
Testing incorrect bind (should fail)... ldap_bind: Invalid credentials (49)
......
Filtering original ldif...
Comparing filter output...
>>>>> Test succeeded
Данный тест выполняется в режиме "только чтения" данных; он может быть применим к любой реляционной СУБД.
Другой тест (на запись), sql-test900-write, на сегодняшний момент может быть выполнен только в PostgreSQL и IBM db2.
Чтобы получить больше информации, посмотрите sql-test000, файлы в директории servers/slapd/back-sql/rdbms_depend/pgsql/ и man-страницы.
Замечание: Этот механизм манипуляции данными является экспериментальным.
11.11.3. Дополнительная информация
slapd-sql(5) и servers/slapd/back-sql/rdbms_depend/README
