17. Построение распределённой службы каталогов
Во многих системах достаточно запустить один или несколько slapd(8), содержащих полное поддерево данных. Однако часто бывает желательно, чтобы один slapd ссылался на другие службы каталогов, обслуживающие определённую часть дерева (эти службы также могут использовать slapd, а могут и не использовать).
slapd поддерживает взаимодействие с такими службами с помощью сведений о нижестоящих и вышестоящих частях дерева. Сведения о нижестоящих частях дерева хранятся в объектах referral (RFC3296).
17.1. Сведения о нижестоящих частях дерева
Сведения о нижестоящих частях дерева нужны для организации делегирования поддерева каталога. Они хранятся в самом каталоге в специальном объекте referral, который располагается в точке делегирования. Точнее объект referral выступает в качестве точки делегирования, склеивающей две службы друг с другом. Такой механизм позволяет строить иерархические службы каталогов.
Объект referral имеет структурный объектный класс referral и то же самое уникальное имя (
Если сервер 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
Данный сервер использует эту информацию для генерации отсылок и продолжения поиска на нижестоящих серверах.
Для тех, кто знаком с
17.2. Сведения о вышестоящих частях дерева
Сведения о вышестоящих частях дерева могут быть указаны с помощью директивы referral, значение которой - список
referral ldap://root.openldap.org/
Однако, поскольку a.example.net - непосредственно вышестоящий сервер для b.example.net, нужно сконфигурировать b.example.net следующим образом:
referral ldap://a.example.net/
Сервер использует эту информацию, чтобы генерировать отсылки для операций, производимых над записями, не входящими в пространство имён, содержащееся на этом сервере или нижестоящих к нему серверах.
Для тех, кто знаком с
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).
