LDAP Linux HOWTO

В этом документе представлена информация об установке, настройке, запуске и обслуживании LDAP (Lightweight Directory Access Protocol) сервера на Linux. Также приводятся детали создания LDAP баз данных, способов обновления и удаления информации из базы данных, путей реализации роуминга и способов использования Netscape Address Book. В основном этот документ основывается на информационных страницах о LDAP Мичиганского Университета (University of Michigan) и OpenLDAP Administrator’s Guide.

Введение

Главная цель этого документа — установка и использование сервера каталогов LDAP на вашей Linux машине. Вы научитесь устанавливать, настраивать, запускать и обслуживать LDAP сервер. Далее вы научитесь способам помещения, извлечения и обновления информации в вашем каталоге с помощью клиентов LDAP и утилит. Демон для LDAP сервера каталогов называется slapd , и он запускается на многих различных UNIX платформах.

Также есть другой демон, который заботится о репликации между LDAP серверами. Он называется slurpd и, в данный момент, вам не следует о нем беспокоится. В этом документе вы запускаете slapd, который предоставляет службу каталогов только для вашего домена, без репликации, следовательно, без slurpd.

Такие простые настройки сервера хороши для начала, и, если вы захотите, позже их легко можно обновить до другой конфигурации. Представленная в этом документе информация представляет собой хорошее введение в использование протокола LDAP. Возможно, после прочтения этого документа вы почувствуете себя увереннее для расширения возможностей вашего сервера, и даже написания собственных клиентов, используя доступные C, C++ и Java Development Kits.

Что такое LDAP?

LDAP — клиент-серверный протокол для доступа к службе каталогов. Изначально он использовался как надстройка над X.500, но он также может быть использован с автономными и прочими видами служб каталогов.

Что такое служба каталогов?

Каталог подобен базе данных, но склонен содержать более описательную, основанную на атрибутах информацию. Обычно информация в каталоге более часто считывается, чем записывается. И, как следствие, каталоги обычно не реализуют сложные транзакции или схемы отката, которые используются в обычных базах данных для выполнения сложных и объемных обновлений. Обновления каталога обычно простые изменения вида все-или-ничего, если они вообще разрешены.

Каталоги настроены для обеспечения быстрого отклика при обзоре большого объема данных или операциях поиска. Они могут иметь способность широко реплицировать информацию, для обеспечения высокой доступности и надежности, при одновременном уменьшении времени ответа. Когда информация каталога реплицирована, допустимы временные несоответствия между репликациями, пока они, в конечном счете, не синхронизируются.

Существует много различных путей реализовать службу каталогов. Различные методы позволяют помещать в каталоге информацию различного типа, помещать различные требования на то, как на эту информацию можно ссылаться, запрашивать и обновлять, как она защищается от несанкционированного доступа и т.п. Некоторые службы каталогов локальны, и предоставляют службы в ограниченном контексте (например, служба finger на одной машине). Другие службы глобальны, и предоставляют обслуживание в более обширном контексте.

Как работает LDAP?

Служба каталогов LDAP основана на клиент-серверной модели. Один или более серверов LDAP содержат данные составляющие дерево каталога LDAP, или базу данных LDAP. Клиент LDAP подключается к LDAP серверу и задает ему вопросы. Сервер выдает ответ или указатель места, где клиент может получить более подробную информацию (обычно, другой LDAP сервер). Не имеет значения, к какому LDAP серверу подключается клиент, он видит один и тот же каталог; имя представленное в одном LDAP сервере ссылается на тот же элемент что и другой LDAP сервер. Это важное свойство глобальной службы каталогов LDAP.

Механизмы баз данных LDAP, объекты и атрибуты

Slapd поставляется с тремя различными механизмами баз данных, которые вы можете выбрать. Это: LDBM — высокоскоростная дисковая база данных; SHELL — интерфейс базы данных к обычным UNIX командам и shell скриптам; и PASSWD — простая база данных на основе файла паролей.

В этом документе я предполагаю, что вы выбрали базу данных LDBM.

База данных LDBM работает, назначая компактный уникальный четырехбайтовый идентификатор каждому элементу базы данных. Она использует этот идентификатор для ссылок на записи из индексов. База данных состоит из одного главного файла индексов под названием id2entry, который устанавливает соответствие уникального индекса элемента (EID) текстовому представлению самого элемента. Также поддерживаются другие индексные файлы.

Для импортирования или экспортирования информации каталога между серверами каталогов основанных на LDAP или для описания набора вносимых в каталог изменений, обычно используется формат LDIF, т.е. LDAP Data Interchange Format. Файл LDIF хранит информацию об объектно-ориентированной иерархии элементов. Пакет LDAP, который вы собираетесь использовать, поставляется с утилитой конвертирования LDIF файлов в LDBM формат.

Типичный LDIF файл выглядит так:

Вы можете заметить, что каждый элемент уникально идентифицируется отличительным именем DN. Отличительное имя состоит из имени элемента плюс путь имен ведущих к вершине иерархии каталога.

В LDAP, класс объектов определяет набор атрибутов, которые используются для определения элемента. Стандарт LDAP определяет такие основные виды классов объектов:

Группа каталогов, включая неупорядоченный список индивидуальных объектов или групп объектов.

Местоположение, такое как имя страны и описание.

Организации в каталоге.

Люди в каталоге.

Элемент может принадлежать более чем одному классу. Например, элемент человека определен классом объектов person , но также могут быть определены атрибуты в классах объектов inetOrgPerson, groupOfNames и organization. Структура классов объектов сервера (его схема) определяет общий список требуемых и разрешенных атрибутов отдельного элемента.

Данные каталога представлены в виде пар атрибут-значение. Любая определенная часть информации ассоциируется с этим описательным атрибутом.

Например, атрибут commonName, или cn, используется для размещения имени человека. Человек по имени Jonas Salk может быть представлен в каталоге как

Каждый человек, введенный в каталог, определяется набором атрибутов в классе объектов person . Прочие атрибуты этого элемента могут включать:

Требуемые атрибуты включают атрибуты, которые могут представляться в элементах, используя класс объектов. Все элементы требуют наличия атрибута objectClass, в котором перечислены классы объектов, к которым принадлежит элемент.

Разрешенные атрибуты включают атрибуты, которые могут быть представлены в элементах класса объектов. Например, в классе объектов person, обязательны атрибуты cn и sn. Атрибуты description, telephoneNumber, seeAlso, и userpassword разрешены, но не обязательны.

Каждый атрибут имеет соответствующее синтаксическое определение. Синтаксическое определение описывает тип предоставляемой атрибутом информации:

bin «binary» двоичный

ces «case exact string» строка с соответствием регистра (регистр символов должен совпадать при сравнении)

cis «case ignore string» строка с игнорированием регистра (регистр символов игнорируется при сравнении)

tel строка с номером телефона (подобен cis но пробелы и тире `- ‘ игнорируются при сравнении)

dn «distinguished name» отличительное имя

Чтобы узнать, где в вашей системе лежат классы объектов и атрибуты, перейдите к первому параграфу Разд. Настройка LDAP сервера >.

Новые версии этого документа

В этот документ могут вноситься исправления и обновления на основе обратной связи с читателями. Новые версии этого HOWTO следует искать на:

Домашняя страница перевода http://mvd.h1.ru/tr/

Мнения и предложения

Если у вас есть какие-либо сомнения по поводу приведенной в этом документе информации, пожалуйста, свяжитесь со мной по следующему email адресу:

Также дайте мне знать, если у вас есть комментарии и/или предложения!

История издания

В этой секции перечислены отсортированные по дате выпуски этого документа. Каждый выпуск включает в себя изменения, внесенные в более ранние версии плюс новые дополнения и корректировки:

v1.0: 20 Июня 1999, Первоначальная версия

v1.01: 15 Февраля 2000, дополнен следующими секциями:

Утилиты миграции LDAP

Аутентификация с помощью LDAP

Графические утилиты LDAP

v1.02: 13 Сентября 2000, коррекция опечаток и дополнения в следующих секциях:

v1.03: 28 Сентября 2000, представлен OpenLDAP 2.0, который охватывает LDAPv3, определенный в RFC2251.

v1.04: 28 Февраля 2001, исправления опечаток и обновления в следующих секциях:

Аутентификация с помощью LDAP

v1.05: 22 Июня 2001, исправления длинных строк, которые вызывали несовместимость с PDF версией этого документа.

Благодарности

Этот Howto — результат моей интернатуры в TUDelft University — Нидерланды. Я хотел бы поблагодарить людей, которые помогали мне в написании этого документа: Rene van Leuken и Wim Tiwon. Огромное им спасибо. Они такие же поклонники Linux, как и я.

Также я хотел бы поблагодарить Thomas Bendler, автора Немецкого варианта Ldap-Howto — Joshua Go, за его дополнения к моему документу, великих добровольцев из проекта LDP и Hugo van der Kooij, за его подсказки по секции Роуминг.

Авторские права и отречение

Авторские права на LDAP Linux HOWTO Copyrighted 1999 принадлежат Luiz Ernesto Pinheiro Malere. Документ может свободно распространяться. Он не может модифицироваться. Если у вас есть какие-либо предложения, пожалуйста, пришлите мне email сообщение (если предложение приемлемо, я обновлю документ).

Если вы хотите его перевести, например, на Португальский язык, вы также можете прислать мне сообщение.

За содержимое этого документа не может возлагаться никакая ответственность. Я не ответственен за последствия приведенных в этом документе шагов.

Если у вас есть вопросы, пожалуйста, свяжитесь с координатором HOWTO по адресу

Источник

выбор LDAP

Задача — централизованное хранение пользователей одной взятой службы в некой конторе — т.е. хождение во внутреннюю wiki, мессенеджер (matrix/jabber), интеграция с freeradius для хождения на сетевые железки, сервера Linux, Gitea и т.д.

Что брать? Samba4, FreeIPA, OpenLDAP?

samba реализует вынь-совместимые услуги. ну там «сетевое окружение» и т.п.
у юниксов вместо этого свои фишки типа nfs, autofs, NIS и т.д.

плюс всякие samba наверное реализует эти самые «груповые пАлитике» — сиреч просто централизованно хранимые конфиги для софта.

так что тут вопрос в задаче. Если бы я делал сеть состоящию из юникс хостов то самба была бы нужна только для затесавшихся вынь-машин.

openldap — это голый сервак, так нравится автору Symas, но инфы достаточно много, ручками можно реализовать что угодно.

FreeIPA содержит в себе другой ldap сервер, но главное что это шапко-центричное поделие, с типа бОльшим уровнем комфорта в виде готовых инструментов типа гуёв на жабе. Ну и галавный фокус FreeIPA это идентификация и «безопасность» (потому что РедХат хорошо кормится с подобных контрактов, ориентированных на секьюрити).

По твоему описанию выходит что мне нужен FreeIPA

посмотри univention , никакой жабы,все на питоне. самба и slapd обслуживают одну и и ту же базу. Но можно ставить без самбы. Хороший веб, куча интегрированных приложений.

Возьми ПО и посмотри что оно поддерживает для интеграции

хм, выглядит слишком заманчиво для бесплатного и свободного. в чем подвох?

Right to redistribution (e. g. OEMs)
No, separate agreement required

Может я чего недопонял конечно.

хм, выглядит слишком заманчиво для бесплатного и свободного. в чем подвох?

он как proxmox, можешь, если хочешь платить, тогда будешь получать саппорт и стабильные релизы. На бесплатных репозиториях ты немного бетатестер. Поэтому я обновляю релизы на две недели позже того, как они выходят ( в этому времени уже все обычно запатчено)

Но платить не советую. У них как и у proxmox сумашедшая кабальная политика подписки. Когда ты не платишь деньги, то все свободно и хорошо. Как только ты подписываешься с тебя начинают сосать деньги за любой чих. На примере proxmox это количество ядер, на univention это жесткое ограничение по количеству пользователей и конские цены. Мы даже с ними переговоры вели, типа , мы хотели бы вам дать денег, потому что вы делаете хороший продукт, но мы не хотим делать подписку в ущерб своей фирме:)

не знаю, может быть.

Ипу можно и как чисто ldap-сервер использовать (шапка для ИПЫ специально купила у тогда еще novell’а код их NDS), но его назначение наверное не в этом..

ещё у самба4 свой ldap и kerberos сервер.

из скудного описания задачи openldap вполне подходит.

Вообще, тут главное чтобы софт который выступает ldap-клиентом хорошо с этим справлялся. А какой там сервер дело второе.

В итоге запилил FreeIPA — то что нужно. Подцепил dokuwiki, zabbix, на очереди gitea.

Источник

LDAP. Настройка отказоустойчивого LDAP сервера

В этой статье я расскажу вам о сервере службы каталогов 389 Directory Server (он же Fedora Directory Server, он же Redhat Directory Server). Так уж повелось, что для доступа к серверу каталогов используется протокол LDAP. Если вы не работали с LDAP, я очень рекомендую ознакомиться со статьями в Wikipedia (тут про cлужбу каталогов, а тут про протокол LDAP).

Итак, сначала кратко о том, зачем же вообще использовать сервер службы каталогов (далее — LDAP-сервер). LDAP-сервера, в основном, применяются для централизованного хранения учетных записей, и всего, что с ними связано. LDAP-сервер представляет собой иерархическую БД, а значит в нем можно хранить любые данные.

Казалось бы, вполне логичен вопрос: а почему именно LDAP? Что мешает хранить учетные записи в MySQL или PostgreSQL? Ответ очевиден — ничего =)

Но над любой RDBMS служба каталогов обладает целым рядом преимуществ:

• Это стандарт. Многие приложения поддерживают аутентификацию/авторизацию через LDAP;
• Данные хранятся как иерархическое дерево, что позволяет делать эффективные операции поиска, выделив нужную часть дерева;
• Число операций чтения в тысячи раз превышают число операций записи, в связи с этим появляется огромное число плюсов: нет необходимости применения транзакций и rollback’ов, репликация работает без проблем, которые присущи RDBMS;
• Приложение должно видеть одну и ту же информацию на всех серверах службы каталогов, если сервер не хранит информацию, нужную клиентскому приложению, он может сам запросить ее у другого сервера или перенаправить само приложение к другому серверу;
• Из-за описанных выше свойств службы каталогов, этот сервис отлично масштабируется горизонтально.

Выбор сервера службы каталогов пал на 389 Directory Server. История этого LDAP сервера тесно связана с компанией Netscape (если интересно, почитать историю можно тут).

Ключевые особенности этого LDAP-сервера:

• Мультимастер репликация. На все сервера, участники MM-репликации, можно записывать данные одновременно, причем конфликты репликации разрешаются автоматически благодаря ведению changelog базы и системе автоматического разрешения конфликтов. MM-репликацию можно комбинировать с master-slave и каскадной репликацией, благодаря чему можно получить гибкий и масштабируемый сервис. Так же поддерживается частичная репликация, что крайне полезно, если мы не хотим, чтобы некоторые данные присутствовали на реплике;
• Мощный механизм ACL. С помощью ACL можно указать кому, когда, на каком LDAP-сервере, с каким атрибутом и какое действие выполнять. ACL хранится вместе с данными как операционные атрибуты, благодаря этому для них, как и для других данных, работают операции репликации и резервного копирования.
• Синхронизация с Microsoft Active Directory. Поддерживается двунаправленная синхронизация пользователей, групп и паролей (для синхронизации паролей из AD в 389-ds необходимо поставить специальный софт на каждый контроллер домена)
• SSL/TLS. Простой поддержкой SSL/TLS сейчас никого не удивишь. 389-ds поддерживает аутентификацию/авторизацию на основании SSL-сертификатов. Так же есть возможность шифрования атрибутов при записи на диск. При ручном вводе ключа при запуске сервера это может защитить от утечки данных путем копирования файлов с БД.
• Управление сервером через протокол LDAP. Сервер поддерживает конфигурацию путем изменения атрибутов в cn=config, большинство параметров применяются без перезагрузки сервера. Так же на сервере можно запускать резервное копирование/восстановление и другие task-и путем добавления новой записи в cn=tasks,cn=config.
• Plugins. Весь функционал реализован в виде plugin-ов (MM-репликация, синхронизация с AD, ACL, и т.п.). Написать и добавить свой plugin довольно легко, т.к. имеется хорошая документация с примерами.

После обзора возможностей 389 Directory Server познакомимся поближе с его структурой.

Общая структура 389 Directory Server

389 DS состоит из нескольких компонентов.

• Сам сервер каталогов. Это приложение ns-slapd, именно этот процесс принимает и обрабатывает запросы от клиента, производит репликацию, читает и записывает данные в базу, передает управление плагинам, и т.д.
• Сервер администрирования (Administration Server). Он управляет сервером каталогов. Сервер предоставляет интерфейс управления через протокол HTTP(S), так же предоставляет веб-интерфейс для просмотра логов и статуса репликации. Физически это apache + модули для управления ns-slapd.
• Консоль администрирования. Java-приложение, которое подключается к серверу администрирования и позволяет настраивать сервер каталогов через удобный интерфейс. Есть версия под windows и linux, под mac os работает через проброс X-сессии с linux-машины.

Сначала я хотел написать теоретическую и практическую части отдельно, но потом стало ясно, что первая часть стала бы слишком скучной, а вторая слишком сухой. Поэтому сразу за куском теории будет идти практическое применение.

Итак, задача. Необходимо настроить отказоустойчивый сервис службы каталогов. Для этого настроим два сервера, настроим multimaster-репликацию между ними и поднимем перемещающийся IP-адрес (pacemaker + openais).

Если один из серверов станет недоступен, другой возьмет на себя этот IP и сервис продолжит работу.

После восстановления сервера данные будут реплицированы на него и IP-адрес переключится обратно на LDAP00, или же, в зависимости от настройки кластера, останется на LDAP01.

На одном сервере может быть несколько изолированных инстансов ns-slapd со своими настройками, схемой, правилами репликации и т.д. Чтобы иметь возможность управлять этими инстансами из консоли управления на каждом сервере должен стоять сервер Administration Server (далее admin server). admin server сам нуждается в одном инстансе LDAP сервера, поскольку хранит там run-time конфигурацию. По умолчанию конфигурация admin server хранится вместе с пользовательскими данными, но я считаю это небезопасным, поэтому у нас будет два инстанса на каждом сервере: один будет содержать конфигурацию для admin server-а, а второй данные. В такой схеме в случае отказа одной из нод сохраняется не только работоспособность LDAP-сервиса, но и возможность управления им.

Для нашего сервиса службы каталогов мы используем два сервера ldap00 и ldap01. На каждом из них будут установлены два инстанса LDAP сервера, один для нужд admin server-ов, второй для наших данных.
План установки будет такой:

1. Установка первого сервера на ldap00;
2. Настройка репликации на ldap00;
3. Установка и настройка ldap инстанса на ldap01;
4. Установка admin server-а на ldap01;
5. Установка и настройка ldap инстансов для хранения пользовательских данных.

Установка первого сервера на ldap00

Готовые rpm собраны в репозитории EPEL для Centos, RHEL и Fedora Core. Если у вас одна из этих систем — подключите репозиторий EPEL и выполните установку через yum.

Мы используем SLES, поэтому нам пришлось собирать все пакеты под эту систему в нашем OpenSUSE Build Service. Если у вас debian/ubuntu — прочтите этот документ.

Вместе с 389 DS идет набор perl скриптов, которые используются для установки инстансов сервера.

Вот некоторые из них:

• setup-ds.pl — устанавливает инстанс LDAP-сервера, сервер создается не подключенным к admin server-у;
• setup-ds-admin.pl — устанавливает admin server, при необходимости устанавливает инстанс LDAP-сервера для хранения своей конфигурации;
• register-ds-admin.pl — подключает инстанс к admin server-у, при необходимости устанавливает admin server;
• remove-ds.pl — удаляет инстанс;
• remove-ds-admin.pl — удаляет admin server и все инстансы;
• dsktune — выводит параметры системы, которые нужно изменить, чтобы добиться большей производительности.

Для начала запустим dsktune:

# dsktune
389 Directory Server system tuning analysis version 10-AUGUST-2007.

NOTICE: System is x86_64-unknown-linux2.6.27.42-0.1-xen (1 processor).

NOTICE: The net.ipv4.tcp_keepalive_time is set to 7200000 milliseconds
(120 minutes). This may cause temporary server congestion from lost
client connections.

WARNING: There are only 1024 file descriptors (hard limit) available, which
limit the number of simultaneous connections.

WARNING: There are only 1024 file descriptors (soft limit) available, which
limit the number of simultaneous connections.

Утилита написала о системных параметрах, которые нужно подкрутить. В моем случае это net.ipv4.tcp_keepalive_time и лимит открытых файлов.

tcp_keepalive_time — это время от последнего посланного пакета до первой посылки keepalive. При большом значении, если клиент «умер», соединение останется открытым долгое время (по умолчанию 120 минут). Установим это значение в 10 минут.

echo 600 > /proc/sys/net/ipv4/tcp_keepalive_time

Добавим в /etc/sysctl.conf:

для увеличения лимита открытых файлов добавляем в /etc/security/limits.conf:

запускаем еще раз dsktune и убедимся, что у нас все готово для установки.

Теперь запускаем скрипт setup-ds-admin.pl
Нас спросят, хотим ли мы установить 389 Directory и Administration Server, согласны ли мы с лицензией, еще раз запустят dsktune и, наконец, появится меню выбора типа установки.

1. Express
Allows you to quickly set up the servers using the most
common options and pre-defined defaults. Useful for quick
evaluation of the products.

2. Typical
Allows you to specify common defaults and options.

3. Custom
Allows you to specify more advanced options. This is
recommended for experienced server administrators only.

To accept the default shown in brackets, press the Enter key.

Choose a setup type [2]:

Выбираем третий пункт (мы же experienced server administrators =) )

Далее будет предложено указать FQDN и имя/группу, от которого(ой) будет запускаться LDAP-сервер.

If you do not yet have a configuration directory server, enter ‘No’ to
be prompted to set up one.

Do you want to register this software with an existing
configuration directory server? [no]:

Тут нас спрашивают, хотим ли мы использовать существующий сервер каталогов для сохранения информации о сервере. Так как это наш первый сервер, отвечаем No.

Далее идут вопросы об admin server-е: administrator ID, пароль, Administration Domain, ответы на них оставляем по умолчанию (кроме пароля).

Затем надо будет указать, какой порт будет слушать LDAP-сервер. Мы договорились, что это инстанс, который хранит лишь конфигурацию для admin server-а, поэтому пересаживаем его на порт 6389. Далее указываем Directory server identifier. Назовем свой инстанс config-instance. На вопрос о суффиксе корневого дерева отвечаем по умолчанию, корневого дерева в этом инстансе не будет, так что его потом можно удалить.

Затем нас ждет вопрос о Directory Manager DN.

Directory Manager — это пользователь с правами root-а в LDAP-сервере. У каждого инстанса есть свой локальный Directory Manager.

Далее следуют вопросы о пароле к Directory Manager-у, хотим ли мы поставить примеры записей в наш root suffix и хотим ли мы заполнить наш новый инстанс какими-нибудь данными, спросят имя порта, IP-адрес и имя пользователя от которого admin server будет работать. После этого последний раз спросят подтверждение и начнут установку.

Настройка репликации на ldap00

Для подключения к серверу нужно поставить и запустить консоль управления 389-console.

В качестве Adminstration URL нужно ввести адрес admin server-а и порт который вы указали при установке.

Далее мы попадаем в панель управления серверами. У нас сейчас только один инстанс, выберем его.

Из консоли управления удаляем суффикс dc=edu,dc=scalaxy,dc=local

У нас остался всего один суффикс и база, в которой находятся конфигурационные данные для admin server-а.

Теперь немного теории о принципах репликации.

В репликации участвуют два типа серверов, supplier и consumer.

supplier — сервер, который копирует реплику на другой сервер.

обязанности supplier сервера:

• отвечать на запросы клиентов на чтение и запись;
• поддержание информации о состоянии изменений реплики;
• инициализация репликации на consumer сервера.

supplier сервер должен быть всегда доступен, поскольку запись производится только на этом сервере, а потом реплицируется на другие севера.

Если связь с supplier сервером будет потеряна, то запись в каталог станет невозможна.

consumer — сервер, который сохраняет реплику с другого сервера. В случае с мультимастер репликацией, два сервера одновременно являются supplier-ом и consumer-ом.

consumer должен:

• отвечать на read запросы клиентов;
• пересылать запросы на обновления данных на сервер;
• при получении запроса на добавление, удаление или обновления записи, запрос пересылается на supplier сервер.

Каждый supplier сервер имеет свой changelog, в котором хранится информация обо всех изменениях, которые произошли на реплике.

Supplier сервер повторяет эти изменения на каждом consumer сервере.

Теперь, когда мы немного подкованы теоретически, можно настраивать мультимастер репликацию инстанса с конфигурацией.

Ведение changelog-а изменений по умолчанию выключено, включается он во вкладке Replication. Changelog включается для всех баз одновременно.

Дальше включаем репликацию для базы NetscapeRoot. Необходимо указать Replica ID и Supplier DNs.

Supplier DN — это имя пользователя, которому разрешено выполнять репликацию на LDAP-сервере. Такого пользователя нужно создать на всех LDAP-серверах, которые участвуют в мультимастер репликации.

Быстрее всего это сделать через утилиту ldapmodify. Эта утилита позволяет модифицировать данные в LDAP в интерактивном режиме или брать команды из ldif файла.

ldapmodify -h 127.0.0.1 -p 6389 -x -D «cn=root» -W
Enter LDAP Password:
dn: cn=replication manager,cn=config
changetype: add
objectClass: inetorgperson
objectClass: person
objectClass: top
objectClass: organizationalPerson
cn: replication manager
sn: RM
userPassword:

Ответ должен быть
adding new entry «cn=replication manager,cn=config»

Итого, у нас получилось:

Сразу же создадим Replication Agreement для второго сервера. В контекстном меню для базы NetscapeRoot выбираем New Replication Agreement и заполняем аналогичным образом:

Нас предупредят, что подключение к серверу невозможно (так как его еще нет), доходим до последнего пункта, ставим Do not initialize consumer.

Установка и настройка ldap инстанса на ldap01

Теперь нужно настроить второй LDAP-сервер. С ним несколько иначе, т.к. установка admin server-а должна уже происходить в установленный LDAP-сервер и первичную настройку мы будем производить из консоли с помощью утилиты ldapmodify (что является нехилым плюсом, если стоит задача разобраться, как же работает этот сервер каталогов).

Сначала на втором сервере с помощью скрипта setup-ds.pl нужно создать инстанс, который не управляется admin server-ом.

Ответы на вопросы скрипта аналогичны предыдущим.

После установки LDAP-сервера подключаемся к нему через ldapmodify и настраиваем.

Подключение производится примерно так:

ldapmodify -h 127.0.0.1 -p 6389 -D «cn=root» -W

dn: cn=changelog5,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: changelog5
nsslapd-changelogdir: /var/lib/dirsrv/slapd-ldap01/changelogdb

changelogdir должен указывать на директорию с названием вашего инстанса.

2) добавляем пользователя replication manager:

dn: cn=replication manager,cn=config
changetype: add
objectClass: inetorgperson
objectClass: person
objectClass: top
objectClass: organizationalPerson
cn: replication manager
sn: RM
userPassword:

20380119031407Z означает, что срок действия пароля не ограничен.

3) Создаем суффикс netscaperoot:

dn: cn=»o=netscaperoot»,cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: NetscapeRoot
cn: «o=netscaperoot»

4) Создаем базу для суффикса netscaperoot:

dn: cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config
changetype: add
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix: o=netscaperoot

Кстати, 389 DS по умолчанию для хранения записей каталога использует модифицированную версию нереляционной базы данных Berkeley DB. Если есть желание, подробнее вы можете прочитать тут.

5) Создаем корневой o=NetScapeRoot:

dn: o=NetscapeRoot
changetype: add
objectClass: organization
objectClass: top
o: NetscapeRoot

6) Разрешаем репликацию для o=netscaperoot:

dn: cn=replica,cn=»o=netscaperoot», cn=mapping tree, cn=config
changetype: add
objectClass: nsDS5Replica
objectClass: top
nsDS5ReplicaId: 2
nsDS5ReplicaRoot: o=netscaperoot
cn: replica
nsDS5Flags: 1
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsds5ReplicaChangeCount: 0
nsds5ReplicaPurgeDelay: 604800
nsDS5ReplicaType: 3

Не забываем изменить nsDS5ReplicaId на номер вашего сервера (nsDS5ReplicaType — тип репликации, 3 — multimaster).

На данном этапе у нас уже есть настроенная репликация в одну сторону с ldap00 на ldap01.

Последним этапом будет:

7) Настройка репликации от ldap01 на ldap00:

dn: cn=Multimaster replication, cn=replica, cn=»o=netscaperoot», cn=mapping
tree, cn=config
changetype: add
objectClass: top
objectClass: nsDS5ReplicationAgreement
cn: Multimaster replication
description: replication for netscaperoot
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindMethod: SIMPLE
nsds5replicaChangesSentSinceStartup:
nsDS5ReplicaCredentials:

nsDS5ReplicaHost: ldap00.edu.scalaxy.local
nsDS5ReplicaPort: 6389
nsDS5ReplicaRoot: o=netscaperoot
nsDS5ReplicaTransportInfo: LDAP
nsds5replicaUpdateInProgress: FALSE

nsDS5ReplicaBindDN — имя пользователя, от имени которого будет производится репликация
nsDS5ReplicaCredentials — пароль

8) Первичная инициилизация репликации с ldap00 на ldap01:

На первом сервере выполняем эту команду:
dn: cn=Multimaster replication,cn=replica,cn=»o=netscaperoot»,cn=mapping tree,cn=config
changetype: modify
replace: nsds5beginreplicarefresh
nsds5beginreplicarefresh: start

Эта команда реплицирует данные с ldap00 на ldap01, эта операция обязательна, тк на втором сервер сейчас пустой o=netscaperoot.

Теперь мы имеем полностью реплицируемые каталоги с конфигурацией admin server-а.

Установка admin server-а на ldap01

Нужно поднять admin server на втором сервере. Запускаем скрипт register-ds-admin.pl

Когда нам предложат указать Configuration directory server URL, вводим LDAP URL второго сервера ldap://ldap01.edu.scalaxy.local:6389/o=NetscapeRoot

Дальнейшая настройка тривиальна, следуем указаниям скрипта.

Установка и настройка ldap инстансов для хранения пользовательских данных

Теперь подключаться через консоль управления можно к любому admin server-у.

На каждом из серверов в Server Group создаем новый инстанс LDAP server-а, это будет LDAP-server, в котором мы будем хранить наши данные.

Настраиваем мультимастер репликацию между двумя инстансами по тому же принципу (теперь вы можете настроить репликацию как через GUI, так и через консоль).

Поздравляю! Вы настроили отказоустойчивый сервис службы каталогов! Далее нужно настроить openais+pacemaker, чтобы исключить простои в работе сервиса.

Источник