Глава 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.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-2019 ZyTrax, Inc. Все права защищены. Последнее изменение страницы: 16 апреля 2018 г.
Переведено участниками проекта Pro-LDAP.ru в 2019 г.

Эта страница

Содержание

Репликация OpenLDAP в стиле slurpd (устарела, начиная с версии 2.4)7.6.1 Ошибки при репликации OpenLDAP в стиле slurpd (устарела, начиная с версии 2.4)7.6.2 Синхронизация DIT перед запуском репликации в стиле slurpd
7.6 Устаревший материал
OpenLDAP 2.4 Руководство

Содержание

Введение в службы каталогов OpenLDAPБыстрое развёртывание и начало работыОбщая картина - варианты конфигурацииСборка и установка OpenLDAPНастройка slapd

 

Конфигурационный файл slapdЗапуск slapdКонтроль доступаОграниченияИнструментыМеханизмы манипуляции даннымиНаложенияСпецификация схемы

 

БезопасностьSASLTLSРаспределённая служба каталоговРепликацияОбслуживаниеМониторингПроизводительностьУстранение неполадок
Перевод официального руководства OpenLDAP 2.4 Admin Guide
Полное содержание здесь
LDAP для учёных-ракетчиков

Содержание

О книгеКонцепции LDAPОбъекты LDAPУстановка LDAPПримерыНастройкаРепликация и отсылкиLDIF и DSMLПротоколLDAP API

 

HOWTOНеполадкиПроизводительностьИнструменты LDAPБезопасностьЗаметкиРесурсы LDAPRFC и X.500ГлоссарийОбъекты
Перевод "LDAP for Rocket Scientists"
Полное содержание здесь
Ресурсы

Книги

Руководство OpenLDAP 2.4LDAP для учёных-ракетчиков

Другие

СтатьиТермины LDAPman-страницы OpenLDAP 2.4Список RFCКлиенты LDAPФайлы наборов схемы
Полезные ресурсы
Форум

 

Разделы форумаНепрочитанные сообщенияПоследние сообщения
Форум проекта
Главная

Pro-LDAP.ru

О проектеНовости проектаУчастникиСтаньте участником!Сообщите об ошибке!Об авторских правахСоглашения проекта
Присоединяйсь!