| Каталог документации / Раздел "Сети, протоколы, сервисы" / Оглавление документа |
| |
|
Отсылка — это процесс, посредством которого LDAP-сервер, вместо того, чтобы вернуть результат запроса, возвращает ссылку (отсылку, referral) на другой LDAP-сервер, который может содержать дополнительную информацию. Отсылка может рассматриваться как переход к внешнему LDAP-серверу (DIT). В документации OpenLDAP в контексте отсылок используются запутанные термины вышестоящий (superior) и нижестоящий (subordinate). Условия, при которых OpenLDAP будет возвращать отсылки:
Общая отсылка возвращается в том случае, когда DN поискового запроса не входит в область ни одного из деревьев (суффиксов), обслуживаемых данным LDAP-сервером. Эта функция настраивается с помощью атрибута olcReferral (директивы referral) в глобальной записи cn=config (OLC) или в разделе глобальных настроек slapd.conf. Подробнее об этом здесь.
Если клиент пытается внести изменения в подчинённое DIT (или DIT потребителя), сервер может быть настроен на возврат отсылки с помощью атрибута olcUpdateref (директивы updateref) записи olcDatabase cn=config (OLC) или раздела database slapd.conf. Подробнее об этом здесь.
Использование объектного класса referral в DIT. Это позволяет делегировать ответственность за обслуживание части LDAP-системы одной или нескольким другим LDAP-системам. Подробнее об этом здесь.
По умолчанию за переход по отсылкам отвечает LDAP-клиент (LDAP-браузер или утилита). Есть опциональная возможность настроить серверы OpenLDAP на следование по определениям объектных классов referral (или их разрешение), вместо того, чтобы просто возвращать отсылку. Данная возможность использует наложение chain. Подробнее об этом здесь.
Если в запросе LDAP-клиента LDAP-серверу фигурирует неверный DN (базовая часть DN не входит ни в одно DN из указанных в директивах suffix данного сервера), то сервер вернёт ошибку. В то же время, сервер может быть сконфигурирован на возвращение отсылки (LDAP URI) на один или несколько серверов, которые, вероятно, смогут предоставить дополнительную информацию. Данная возможность определяется с помощью атрибута olcReferral (директивы referral) в глобальной записи cn=config (OLC) или в разделе глобальных настроек slapd.conf, как показано в следующем примере:
# olc cn=config или slapd.conf
# раздел глобальных настроек
...
# Если сервер получил поисковый запрос с DN
# который не входит ни в одно DN из указанных в olcSuffix/suffix
# какого-либо из разделов database, он вернёт оба LDAP URI.
# В данном случае отсылки будут возвращаться, если DN
# в поисковом запросе не заканчивается на dc=example,dc=net
# С использованием OLC (запись cn=config)
olcReferral: ldap://ldap-master.example.com
olcReferral: ldap://ldap-services.example.com:10389
# Подразумевается, что OLC-определение DIT - запись
# olcDatabase={X}zzz,cn=config с суффиксом
olcSuffix: dc=example,dc=net
# С использованием файла slapd.conf
referral ldap://ldap-master.example.com
referral ldap://ldap-services.example.com:10389
# раздел (разделы) database
database bdb
...
suffix "dc=example,dc=net"
...
Если LDAP-клиент пытается выполнить запрос на запись (модификацию) содержимого потребителя при репликации в стиле syncrepl (в конфигурации главный-подчинённый), этот запрос будет отклонён. В то же время, сервер может быть сконфигурирован на возвращение отсылки (LDAP URI), которая обычно указывает на главный сервер (на поставщика) репликации, с помощью атрибута oldUpdateref (директивы updateref), как показано в следующем примере:
# OLC
# olcDatabase={X}zzz,cn=config
olcSyncrepl: ....
# отсылка на поставщика
olcUpdateref: ldap://ldap-master.example.com
# slapd.conf подчинённого сервера (или потребителя)
...
# раздел (разделы) database
database bdb
...
# директива syncrepl
syncrepl ....
# отсылка на DIT главного сервера (поставщика)
updateref ldap://ldap-master.example.com
...
Отсылки могут быть явно определены в DIT с помощью объектного класса referral. У этого объектного класса единственный атрибут ref (LDAP URI).
Для иллюстрации этого процесса предположим, что есть LDAP-система с делегированием (основанная на отсылках), как показано на рисунке 7.3-1:
Рисунок 7.3-1 — Отсылки на LDAP2 и LDAP3
Чтобы определить отсылку от LDAP1 к LDAP2, используется следующий набор инструкций LDIF:
# данное определение создаёт RDN o=grommets # и устанавливает отсылку от него к ldap2 dn: o=grommets,dc=example,dc=com objectClass: referral objectClass: extensibleObject o: grommets ref: ldap://ldap2.example.com/o=grommets,dc=example,dc=net
Примечания:
Объектный класс extensibleObject позволяет добавить любой атрибут (в данном случае o (organizationName)) к объектному классу referral.
Отсылка к LDAP2 будет возвращаться (или будет выполнено её разрешение), если сервер LDAP1.example.com получит поисковый запрос с таким DN:
cn=cheri,ou=uk,o=grommets,dc=example,dc=com
Чтобы определить отсылку от LDAP2 к LDAP3, используется следующий набор инструкций LDIF:
# запись с объектным классом organizationalUnit # и с атрибутом organizationName (o), имеющим значение grommets, # должна быть определена на данном сервере, # либо суффикс LDAP2 должен быть задан как o=grommets,dc=examnple,dc=com # данное определение создаёт RDN o=uk # и устанавливает отсылку от него к ldap3 dn: ou=uk,o=grommets,dc=example,dc=com objectClass: referral objectClass: extensibleObject ou: uk ref: ldap://ldap3.example.com/ou=uk,o=grommets,dc=example,dc=net
Примечания:
Объектный класс extensibleObject позволяет добавить любой атрибут (в данном случае ou (organizationalUnit)) к объектному классу referral.
Отсылка к LDAP3 будет возвращаться (или будет выполнено её разрешение), если сервер LDAP2.example.com получит поисковый запрос с таким DN:
cn=cheri,ou=uk,o=grommets,dc=example,dc=com
При использовании стандартных утилит, таких как ldapmodify, удаление отсылок выполняется несколько мудрёно. Напомним, что LDAP-клиенты всегда следуют по отсылкам, таким образом, при поиске экземпляра отсылки, которую требуется удалить (или модифицировать), LDAP-сервер определяет объектный класс referral и немедленно посылает отсылку, по которой потом следует клиент, в результате запись-отсылка так и не будет найдена. Для пресечения подобного автоматического поведения отсылок на LDAP-сервере, клиент должен использовать элемент управления Manage DSA IT (OID 2.16.840.1.113730.3.4.2, определён в RFC 3296). В случае с ldapmodify для посылки данного элемента управления при попытке удаления или модификации записи-отсылки должен быть использован аргумент -M.
Обычно, если в процессе поиска LDAP-серверу встречается объект referral, он вернёт LDAP-клиенту отсылку. Однако, сервер может быть настроен на следование по отсылкам (разрешение отсылок) и возвращение клиенту полного результата. Этот процесс часто называется сцеплением (chaining) и конфигурируется на сервере с помощью наложения chain. Сцепление показано на рисунке 7.3-2:
Рисунок 7.3-2 — Сцепление с LDAP2 и LDAP3
В следующем примере демонстрируется конфигурация, которую нужно произвести на сервере LDAP1 для выполнения сцепления (следования) по двум отсылкам, как показано на рисунке 7.3-2:
# slapd.conf # раздел глобальных настроек ... # общая отсылка для запросов с неверным DN referral ldap:ldap-master.example.com ... # раздел (разделы) databases database bdb ... suffix "dc=example,dc=com" ... overlay chain # разрешаем следовать по двум отсылкам: из данного DIT # и из того DIT, на которое ссылается данное DIT chain-max-depth 2 # в случае какой-либо ошибки возвращается отсылка chain-return-error FALSE overlay chain chain-uri "ldap://ldap2.example.com" chain-rebind-as-user yes chain-idassert-bind bindmethod="simple" binddn="cn=admin,dc=example,dc=com" credentials="secret" mode="self" chain-uri "ldap://ldap3.example.com" chain-rebind-as-user yes chain-idassert-bind bindmethod="simple" binddn="cn=admin,dc=example,dc=com" credentials="secret" mode="self"
Полное описание директив конфигурации наложения chain здесь.
Псевдонимы LDAP (определены в RFC 4512) используют структурный (STRUCTURAL) объектный класс alias для определения позиции в текущем DIT и атрибут aliasedObjectName для определения DN записи, содержащей информацию. LDAP-сервер автоматически разыменовывает псевдоним и возвращает запись, на которую указывает DN в атрибуте aliasedObjectName. Псевдоним может рассматриваться как переход внутри LDAP-сервера, поскольку при его разыменовании используется только DN (в отличие от объектного класса referral, в котором используется LDAP URI). Примеры псевдонимов:
# Пример 1 # Классический псевдоним: два имени отображаются на одну запись. # Используется единственное DIT (суффикс dc=example,dc=com). # Любители танго возмутятся от такого псевдонима. dn: ou=candombe,ou=tango,dc=example,dc=com objectClass: alias objectClass: extensibleObject ou: candombe aliasedObjectName: ou=milonga,ou=tango,dc=example,dc=com # При ссылке на ou=candombe,ou=tango,dc=example,dc=com # возвращаются данные из ou=milonga,ou=tango,dc=example,dc=com # Пример 2 # Замена одного DN другим DN. # Допустим, одна компания поглотила другую. # Подразумевается, что оба DIT на одном сервере # (суффиксы dc=example,dc=de и dc=example,dc=kr) dn: uid=jschmidt,ou=people,dc=example,dc=de objectClass: alias objectClass: extensibleObject uid: jschmidt aliasedObjectName: uid=jschmidt,ou=people,dc=example,dc=kr # При ссылке на uid=jschmidt,ou=people,dc=example,dc=de # возвращаются данные из uid=jschmidt,ou=people,dc=example,dc=kr
Примечания:
Объектный класс extensibleObject позволяет добавить к объектному классу alias любой атрибут (в первом примере — ou (organizationalUnitName), во втором — uid).
Атрибут aliasedObjectName существенно влияет на то, какие записи будут возвращаться сервером LDAP. Так, в первом из приведённых примеров при запросе записи cn=Siga El Baile,ou=candombe,ou=tango,dc=example,dc=com будет возвращена запись cn=Siga El Baile,ou=milonga,ou=tango,dc=example,dc=com.
В отличие от отсылок, для удаления записей с объектным классом alias не требуется предпринимать каких-либо специальных действий, то есть при выполнении операции delete LDAP-сервер автоматически подавляет разыменование.
Уже совсем скоро (One day real soon nowOne day real soon now ™)
В этом разделе описывается репликация в стиле slurpd, которая считается устаревшей с выходом OpenLDAP версии 2.4. Она представляет интерес только в историческом плане и оставлена здесь для тех пользователей, кому в наследство достались старые операционные системы (с OpenLDAP до версии 2.4).
Репликация в стиле slurpd использовала репликационную стратегию "посылок" ("push"). Она устарела, начиная с версии 2.4. Этот раздел документации размещается здесь по историческим причинам, а также для всех тех, кто застрял на старых версиях OpenLDAP. Настройка и управление такой репликацией показана на рисунке 7.6-1:
7.6-1 Репликация в стиле slurpd
Когда slapd (1), обслуживающий главное DIT (7), принимает запрос на операцию модификации (9), он обновляет своё DIT и помещает копию произошедшей транзакции в файл журнала (2), указанный в директиве replogfile файла slapd.conf (5) главного сервера.
При первоначальной загрузке slurpd (3) получает свои операционные параметры из файла slapd.conf (5). Периодически, через промежуток времени, указанный в директиве replicationinterval, slurpd будет считывать содержимое файла журнала (2), указанного в директиве replogfile, и записывает обновления (10) на один (или несколько) подчинённых DIT (8), указанных в директивах replica в файле slapd.conf (5).
Подчинённые DIT (8) являются копиями "только для чтения" для всех клиентов, за исключением клиента, подсоединяющегося от имени DN, указанного в директиве updatedn. В ответ на все поступающие от клиентов операции модификации, за исключением тех, которые поступают от клиента, подсоединяющегося от имени DN, указанного в директиве updatedn, подчинённый сервер (4) возвращает LDAP URI, указанное в директиве updateref. Обе директивы updatedn и updateref определяются в файле slapd.conf (6). DN, указываемый в директиве updatedn в slapd.conf (6) ДОЛЖЕН совпадать с тем, который указан в директиве replica (параметр binddn) в slapd.conf (5) для данного подчинённого сервера.
Если slurpd (3) не удаётся обновить экземпляр подчинённого сервера, он создаёт файл отказов (REJECTION), имя которого совпадает с именем файла, указанного в директиве replogfile, с добавлением суффикса .rej, как показано в примере:
# директива reploglogfile slapd.conf replogfile /var/log/ldap/slave1.log # файл REJECTION будет называться # /var/log/ldap/slave1.log.rej
Каждое сообщение об ошибке в файле журнала REJECTION аналогично тому, которое используется в нормальном журнале транзакций, но оно предваряется строкой, начинающейся с ключевого слова ERROR и содержащей сообщение об ошибке. Вот пример:
ERROR: No such attribute replica: slave1.example.com:389 time: 809618633 dn: uid=rsmith,dc=example,dc=com changetype: modify replace: description description: clown - replace: modifiersName modifiersName: uid=rsmith,dc=example,dc=com - replace: modifyTimestamp modifyTimestamp: 20000805073308Z
Чтобы исправить ошибки, нужно либо внести изменения в содержимое каталога на подчинённом сервере (в случае с приведённым выше примером добавить в запись атрибут description), либо отредактировать журнал REJECTION, исправляя ошибки (в приведённом выше примере заменить строку replace: description на add: description). Нет необходимости удалять строки, начинающиеся с ERROR, поскольку они игнорируются. После внесения исправлений можно попытаться заново применить файл REJECTION путём запуска slurpd в режиме однократного прогона (после остановки работающего в данный момент slurpd) следующей командой:
slurpd -o -r /var/log/ldap/slave1.log.rej # здесь -r указывает путь к файлу REJECTION # а -o говорит о том, что запуск будет # произведён в режиме однократного прогона
slurpd применит транзакции из указанного файла (-r) и завершит работу. После этого следует снова запустить slurpd в нормальном режиме работы.
Конфигурация slapd.conf на главном сервере:
# главный сервер slapd # раздел глобальных настроек - проверка файла каждые 5 минут replicationinterval 300 # раздел database database bdb ... # подключение к подчинённому серверу ldap-rep1.example.com # с простым уровнем безопасности и паролем в открытом виде # директива используется только демоном slurpd replica uri=ldap://ldap-rep1.example.com bindmethod=simple binddn="uid=admin,ou=admin,dc=example,dc=com" credentials=guess # записывать изменения в указанный файл # директива используется обоими демонами slapd и slurpd replogfile /var/log/ldap/slavedit.log
Конфигурация slapd.conf на подчинённом сервере (хост ldap-rep1.example.com):
# подчинённый сервер slapd # раздел глобальных настроек # раздел database database bdb ... # указывается dn, который используется в # директиве replica на главном сервере # директива используется только демоном slurpd updatedn "uid=admin,ou=admin,dc=example,dc=com" # отсылка, возвращаемая клиенту, пытающемуся выполнить обновление подчинённого каталога updateref ldap://master-ldap.example.com
Перед тем как репликация в стиле slurpd сможет функционировать, DIT (главное и подчинённое (подчинённые)) должны быть приведены в одинаковое состояние. Сначала должен быть выполнен процесс ручной синхронизации, описанный ниже:
Примечание: slurpd считается устаревшим в OpenLDAP 2.4 и эта информация включена сюда лишь для полноты картины. В случае, когда OpenLDAP использует репликацию в стиле syncrepl, подчинённый сервер или один из главных серверов в конфигурации с несколькими главными серверами, может начать синхронизироваться, вообще не имея записей в DIT. Тем не менее, описанный ниже процесс также может быть использован, и, в зависимости от объёма каталога, он может обеспечить более эффективный (быстрый) запуск подчинённого DIT.Остановите LDAP-сервер, который будет содержать главный экземпляр DIT. Это необходимо для предотвращения дальнейшего внесения изменений в DIT.
Создайте LDIF-копию того DIT, которое будет реплицироваться, с помощью соответствующего off-line инструмента для LDAP-сервера.
(В OpenLDAP используйте slapcat).
Сконфигурируйте данный сервер для запуска главного экземпляра DIT.
Для репликации в стиле slurpd OpenLDAP: добавьте директивы replica, replogfile и replicationinterval в файл slapd.conf. Пока не перезапускайте сервер.
Примечание: Если OpenLDAP использует on-line конфигурацию (cn=config), сервер должен быть активен.
Скопируйте LDIF-файл, созданный на шаге 2, на сервер (серверы), на которых будет запущен подчинённый экземпляр DIT (или один из главных серверов в конфигурации с несколькими главными серверами, применимо только для репликации в стиле syncrepl).
Остановите LDAP-сервер, на котором будет запущен подчинённый экземпляр DIT (или один из главных серверов в конфигурации с несколькими главными серверами, применимо только для репликации в стиле syncrepl).
Примените LDIF-файл, скопированный на шаге 4, с помощью соответствующего off-line инструмента для LDAP-сервера.
(В OpenLDAP используйте slapadd. Поскольку сервер ещё не сконфигурирован, нужно использовать опцию -n (dbnum)).
Сконфигурируйте сервер, на котором будет запущен подчинённый экземпляр DIT (или один из главных серверов в конфигурации с несколькими главными серверами, применимо только для репликации в стиле syncrepl) на работу в качестве подчинённого или одного из главных серверов.
Для репликации в стиле slurpd OpenLDAP это означает определение директивы database и всех связанных с ней директив (поскольку при добавлении DIT использовалась опция -n dbnum, порядок, в котором определяются разделы database, очень важен), для спецификации репликации добавьте директиву updatedn и директивы updateref.
Примечание: Если OpenLDAP использует конфигурацию времени исполнения (cn=config), сервер должен быть активен.
В конфигурации главный-подчинённый запустите сервер, на котором будет работать подчинённый экземпляр DIT. Убедитесь, что он заработал. В конфигурации с несколькими главными серверами (только для репликации в стиле syncrepl) запустите данную копию главного сервера и убедитесь, что он заработал.
Запустите сервер, на котором работает главный экземпляр DIT, или другой главный сервер в конфигурации с несколькими главными серверами (только для репликации в стиле syncrepl).
Выполните тестовую транзакцию на главном сервере (на одном из главных серверов в конфигурации с несколькими главными серверами, только для репликации в стиле syncrepl) и убедитесь, что она была распространена на подчинённый сервер (или другой главный сервер). Если нет — изучайте журналы. И начинайте паниковать — это всегда помогает.
Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.
Нашли ошибку в переводе? Сообщите переводчикам!
Copyright © 1994-2017 ZyTrax, Inc. Все права защищены. Последнее изменение страницы: 7 марта 2017 г.
Переведено участниками проекта Pro-LDAP.ru в 2012-2014 г.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |