The OpenNET Project / Index page

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

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


17. Построение распределённой службы каталогов

Во многих системах достаточно запустить один или несколько slapd(8), содержащих полное поддерево данных. Однако часто бывает желательно, чтобы один slapd ссылался на другие службы каталогов, обслуживающие определённую часть дерева (эти службы также могут использовать slapd, а могут и не использовать).

slapd поддерживает взаимодействие с такими службами с помощью сведений о нижестоящих и вышестоящих частях дерева. Сведения о нижестоящих частях дерева хранятся в объектах referral (RFC3296).


17.1. Сведения о нижестоящих частях дерева

Сведения о нижестоящих частях дерева нужны для организации делегирования поддерева каталога. Они хранятся в самом каталоге в специальном объекте referral, который располагается в точке делегирования. Точнее объект referral выступает в качестве точки делегирования, склеивающей две службы друг с другом. Такой механизм позволяет строить иерархические службы каталогов.

Объект referral имеет структурный объектный класс referral и то же самое уникальное имя (Distinguished Name), что и делегируемое поддерево. Как правило, объект referral также будет иметь вспомогательный объектный класс extensibleObject. Это позволит записи хранить соответствующие значения относительного уникального имени (Relative Distinguished Name). Лучше всего продемонстрировать это на примере.

Если сервер a.example.net содержит дерево dc=example,dc=net и собирается делегировать поддерево dc=subtree,dc=example,dc=net другому серверу b.example.net, то на сервере a.example.net нужно добавить следующий именованный объект referral:

        dn: dc=subtree,dc=example,dc=net
        objectClass: referral
        objectClass: extensibleObject
        dc: subtree
        ref: ldap://b.example.net/dc=subtree,dc=example,dc=net

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

Для тех, кто знаком с X.500, именованный объект referral имеет сходство со сведениями о ссылках X.500, содержащимися в subr DSE.


17.2. Сведения о вышестоящих частях дерева

Сведения о вышестоящих частях дерева могут быть указаны с помощью директивы referral, значение которой - список URI, ссылающихся на вышестоящие службы каталогов. Если у какого-либо сервера нет непосредственного вышестоящего сервера (как у a.example.net из примера выше), он может быть настроен на использование службы каталогов с глобальными сведениями, такой, как OpenLDAP Root Service (http://www.openldap.org/faq/index.cgi?file=393).

        referral        ldap://root.openldap.org/

Однако, поскольку a.example.net - непосредственно вышестоящий сервер для b.example.net, нужно сконфигурировать b.example.net следующим образом:

        referral        ldap://a.example.net/

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

Для тех, кто знаком с X.500, данное использование атрибута ref имеет сходство со сведениями о ссылках X.500, содержащимися в Supr DSE.


17.3. Элемент управления ManageDsaIT

Как правило, добавление, изменение и удаление объектов referral выполняется с помощью ldapmodify(1) или подобных инструментов, поддерживающих элемент управления ManageDsaIT. Элемент управления ManageDsaIT сообщает серверу, что Вы будете производить манипуляции с объектом referral как с обычной записью. В этом случае сервер не будет возвращать отсылку в ответ на запросы получения или обновления объектов referral.

Не нужно указывать элемент управления ManageDsaIT при управлении обычными записями.

Параметр -M утилиты ldapmodify(1) (или другой) включает ManageDsaIT. Например:

        ldapmodify -M -f referral.ldif -x -D "cn=Manager,dc=example,dc=net" -W

или с ldapsearch(1):

        ldapsearch -M -b "dc=example,dc=net" -x "(objectclass=referral)" '*' ref


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


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


Примечание: как правило, операции LDAP, даже поиски по поддереву, получают доступ только к одной базе данных. Это можно изменить путём склеивания баз данных друг с другом с помощью ключевого слова subordinate/olcSubordinate. Подробности смотрите в slapd.conf(5) и slapd-config(5).




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

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