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