The OpenNET Project / Index page

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

Каталог документации / Раздел "Сети, протоколы, сервисы" / Оглавление документа


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

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

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

        back_<имя механизма>.la

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

        moduleload back_hdb.la

11.1. Механизмы Berkeley DB

11.1.1. Обзор

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

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 (LMDB, высокоскоростная отображаемая в памяти база данных).

Как и механизмы 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. Дополнительная информация

slapd-mdb(5)


11.5. Метакаталог

11.5.1. Обзор

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

Для понимания работы данного механизма рекомендуется разобраться в функционировании другого механизма — 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:

На создание данного механизма вдохновило устройство /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




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Ihor
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2019 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру