Глава 7. Отсылки, псевдонимы и проксирование (сцепление)

Содержание

  1. 7.1 Обзор репликации и отсылок
  2. 7.2 Репликация
    1. 7.2.1 Репликация OpenLDAP
      1. 7.2.1.1 Репликация OpenLDAP в стиле syncrepl
      2. 7.2.1.2 Тип RefreshOnly репликации syncrepl в OpenLDAP
        1. Пример конфигурации с использованием OLC
        2. Пример конфигурации с использованием slapd.conf
      3. 7.2.1.3 Тип RefreshAndPersist репликации syncrepl в OpenLDAP
        1. Пример конфигурации с использованием OLC
        2. Пример конфигурации с использованием slapd.conf
      4. 7.2.1.4 Репликация syncrepl с несколькими главными серверами (Multi-Master) в OpenLDAP
        1. Пример конфигурации с использованием OLC
        2. Пример конфигурации с использованием slapd.conf
      5. 7.2.1.5 Журналы сессии, журналы доступа и delta-синхронизация при репликации syncrepl в OpenLDAP
        1. Пример конфигурации с использованием OLC
        2. Пример конфигурации с использованием slapd.conf
      6. 7.2.1.6 Синхронизация DIT перед запуском репликации в стиле syncrepl
    2. 7.2.2 Репликация ApacheDS
  3. 7.3 Отсылки
    1. 7.3.1 Удаление отсылок
    2. 7.3.2 Сцепление при отсылках
  4. 7.4 Псевдонимы
  5. 7.5 LDAP-прокси и сцепления
  6. 7.6 Устаревший материал — Репликация OpenLDAP в стиле slurpd (устарела, начиная с версии 2.4)
    1. 7.6.1.1 Ошибки при репликации OpenLDAP в стиле slurpd
    2. 7.6.1.2 Синхронизация DIT перед запуском репликации в стиле slurpd

7.3 Отсылки

Отсылка — это процесс, посредством которого LDAP-сервер, вместо того, чтобы вернуть результат запроса, возвращает ссылку (отсылку, referral) на другой LDAP-сервер, который может содержать дополнительную информацию. Отсылка может рассматриваться как переход к внешнему LDAP-серверу (DIT). В документации OpenLDAP в контексте отсылок используются запутанные термины вышестоящий (superior) и нижестоящий (subordinate). Условия, при которых OpenLDAP будет возвращать отсылки:

  1. Общая отсылка возвращается в том случае, когда DN поискового запроса не входит в область ни одного из деревьев (суффиксов), обслуживаемых данным LDAP-сервером. Эта функция настраивается с помощью атрибута olcReferral (директивы referral) в глобальной записи cn=config (OLC) или в разделе глобальных настроек slapd.conf. Подробнее об этом здесь.

  2. Если клиент пытается внести изменения в подчинённое DIT (или DIT потребителя), сервер может быть настроен на возврат отсылки с помощью атрибута olcUpdateref (директивы updateref) записи olcDatabase cn=config (OLC) или раздела database slapd.conf. Подробнее об этом здесь.

  3. Использование объектного класса referral в DIT. Это позволяет делегировать ответственность за обслуживание части LDAP-системы одной или нескольким другим LDAP-системам. Подробнее об этом здесь.

По умолчанию за переход по отсылкам отвечает LDAP-клиент (LDAP-браузер или утилита). Есть опциональная возможность настроить серверы OpenLDAP на следование по определениям объектных классов referral (или их разрешение), вместо того, чтобы просто возвращать отсылку. Данная возможность использует наложение chain. Подробнее об этом здесь.

7.3.1 Общие отсылки

Если в запросе 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"
...

7.3.2 Отсылки при попытках внести изменения в подчинённый сервер (сервер-потребитель)

Если 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
...

Наверх

7.3.3 Объекты referral

Отсылки могут быть явно определены в DIT с помощью объектного класса referral. У этого объектного класса единственный атрибут ref (LDAP URI).

Для иллюстрации этого процесса предположим, что есть LDAP-система с делегированием (основанная на отсылках), как показано на рисунке 7.3-1:

Отклики на отсылки, определённые в LDAP

Рисунок 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

Примечания:

  1. Объектный класс extensibleObject позволяет добавить любой атрибут (в данном случае o (organizationName)) к объектному классу referral.

  2. Отсылка к 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

Примечания:

  1. Объектный класс extensibleObject позволяет добавить любой атрибут (в данном случае ou (organizationalUnit)) к объектному классу referral.

  2. Отсылка к LDAP3 будет возвращаться (или будет выполнено её разрешение), если сервер LDAP2.example.com получит поисковый запрос с таким DN:

    cn=cheri,ou=uk,o=grommets,dc=example,dc=com
    

Наверх

7.3.4 Удаление отсылок

При использовании стандартных утилит, таких как ldapmodify, удаление отсылок выполняется несколько мудрёно. Напомним, что LDAP-клиенты всегда следуют по отсылкам, таким образом, при поиске экземпляра отсылки, которую требуется удалить (или модифицировать), LDAP-сервер определяет объектный класс referral и немедленно посылает отсылку, по которой потом следует клиент, в результате запись-отсылка так и не будет найдена. Для пресечения подобного автоматического поведения отсылок на LDAP-сервере, клиент должен использовать элемент управления Manage DSA IT (OID 2.16.840.1.113730.3.4.2, определён в RFC 3296). В случае с ldapmodify для посылки данного элемента управления при попытке удаления или модификации записи-отсылки должен быть использован аргумент -M.

Наверх

7.3.5 Сцепление (следование по отсылкам) и проксирование

Обычно, если в процессе поиска LDAP-серверу встречается объект referral, он вернёт LDAP-клиенту отсылку. Однако, сервер может быть настроен на следование по отсылкам (разрешение отсылок) и возвращение клиенту полного результата. Этот процесс часто называется сцеплением (chaining) и конфигурируется на сервере с помощью наложения chain. Сцепление показано на рисунке 7.3-2:

Отклики на отсылки, определённые в LDAP

Рисунок 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 здесь.

Наверх

7.4 Псевдонимы

Псевдонимы 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

Примечания:

  1. Объектный класс extensibleObject позволяет добавить к объектному классу alias любой атрибут (в первом примере — ou (organizationalUnitName), во втором — uid).

  2. Атрибут 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.

  3. В отличие от отсылок, для удаления записей с объектным классом alias не требуется предпринимать каких-либо специальных действий, то есть при выполнении операции delete LDAP-сервер автоматически подавляет разыменование.

Наверх

7.5 LDAP-прокси и сцепления

Уже совсем скоро (One day real soon nowOne day real soon now ™)

Under construction

Наверх

7.6 Устаревший материал

Репликация OpenLDAP в стиле slurpd (устарела, начиная с версии 2.4)

В этом разделе описывается репликация в стиле slurpd, которая считается устаревшей с выходом OpenLDAP версии 2.4. Она представляет интерес только в историческом плане и оставлена здесь для тех пользователей, кому в наследство достались старые операционные системы (с OpenLDAP до версии 2.4).

Репликация в стиле slurpd использовала репликационную стратегию "посылок" ("push"). Она устарела, начиная с версии 2.4. Этот раздел документации размещается здесь по историческим причинам, а также для всех тех, кто застрял на старых версиях OpenLDAP. Настройка и управление такой репликацией показана на рисунке 7.6-1:

Репликация в стиле slurpd

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) для данного подчинённого сервера.

7.6.1 Ошибки при репликации OpenLDAP в стиле slurpd (устарела, начиная с версии 2.4)

Если 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 в нормальном режиме работы.

Примеры конфигурации 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

Наверх

7.6.2 Синхронизация DIT перед запуском репликации в стиле slurpd

Перед тем как репликация в стиле slurpd сможет функционировать, DIT (главное и подчинённое (подчинённые)) должны быть приведены в одинаковое состояние. Сначала должен быть выполнен процесс ручной синхронизации, описанный ниже:

Примечание: slurpd считается устаревшим в OpenLDAP 2.4 и эта информация включена сюда лишь для полноты картины. В случае, когда OpenLDAP использует репликацию в стиле syncrepl, подчинённый сервер или один из главных серверов в конфигурации с несколькими главными серверами, может начать синхронизироваться, вообще не имея записей в DIT. Тем не менее, описанный ниже процесс также может быть использован, и, в зависимости от объёма каталога, он может обеспечить более эффективный (быстрый) запуск подчинённого DIT.

  1. Остановите LDAP-сервер, который будет содержать главный экземпляр DIT. Это необходимо для предотвращения дальнейшего внесения изменений в DIT.

  2. Создайте LDIF-копию того DIT, которое будет реплицироваться, с помощью соответствующего off-line инструмента для LDAP-сервера.

    (В OpenLDAP используйте slapcat).

  3. Сконфигурируйте данный сервер для запуска главного экземпляра DIT.

    Для репликации в стиле slurpd OpenLDAP: добавьте директивы replica, replogfile и replicationinterval в файл slapd.conf. Пока не перезапускайте сервер.

    Примечание: Если OpenLDAP использует on-line конфигурацию (cn=config), сервер должен быть активен.

  4. Скопируйте LDIF-файл, созданный на шаге 2, на сервер (серверы), на которых будет запущен подчинённый экземпляр DIT (или один из главных серверов в конфигурации с несколькими главными серверами, применимо только для репликации в стиле syncrepl).

  5. Остановите LDAP-сервер, на котором будет запущен подчинённый экземпляр DIT (или один из главных серверов в конфигурации с несколькими главными серверами, применимо только для репликации в стиле syncrepl).

  6. Примените LDIF-файл, скопированный на шаге 4, с помощью соответствующего off-line инструмента для LDAP-сервера.

    (В OpenLDAP используйте slapadd. Поскольку сервер ещё не сконфигурирован, нужно использовать опцию -n (dbnum)).

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

    Для репликации в стиле slurpd OpenLDAP это означает определение директивы database и всех связанных с ней директив (поскольку при добавлении DIT использовалась опция -n dbnum, порядок, в котором определяются разделы database, очень важен), для спецификации репликации добавьте директиву updatedn и директивы updateref.

    Примечание: Если OpenLDAP использует конфигурацию времени исполнения (cn=config), сервер должен быть активен.

  8. В конфигурации главный-подчинённый запустите сервер, на котором будет работать подчинённый экземпляр DIT. Убедитесь, что он заработал. В конфигурации с несколькими главными серверами (только для репликации в стиле syncrepl) запустите данную копию главного сервера и убедитесь, что он заработал.

  9. Запустите сервер, на котором работает главный экземпляр DIT, или другой главный сервер в конфигурации с несколькими главными серверами (только для репликации в стиле syncrepl).

  10. Выполните тестовую транзакцию на главном сервере (на одном из главных серверов в конфигурации с несколькими главными серверами, только для репликации в стиле syncrepl) и убедитесь, что она была распространена на подчинённый сервер (или другой главный сервер). Если нет — изучайте журналы. И начинайте паниковать — это всегда помогает.

Наверх



Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.

Нашли ошибку в переводе? Сообщите переводчикам!

Copyright © 1994-2017 ZyTrax, Inc. Все права защищены. Последнее изменение страницы: 7 марта 2017 г.
Переведено участниками проекта Pro-LDAP.ru в 2012-2014 г.