# Включаем адрес основного сервера ldap, куда будет перенаправляться клиент, пытающийся модифицировать

# данные

updateref master.test.ru:389

# Надо дать необходимые привилегии репликатору, т.к. ему необходим доступ на запись данных

access to *

by dn="cn=root, dc=test, dc=ru" write

by dn="cn=replicator, dc=test, dc=ru" write

by self write

После настройки всех серверов необходимо перекопировать содержимое базы данных LDAP основного сервера на все вторичные сервера, для этого необходимо перенести содержимое DatabaseDir физически(!). После всего этого желательно проиндексировать базу, иначе поиск по ней замедляется:

slapindex -f /etc/ldap/slapd.conf     -b "dc=test, dc=ru"

Затем на главном сервере запускаем slurpd:

# slurpd

Использование stunnel в данном случае также приемлемо – на главном сервере устанавливаются клиенты туннеля, которые направлены ко вторичным LDAP-серверам, но на сервере эти туннели будут висеть на разных портах, и LDAP-сервер будет соединяться с локальными туннелями, висящими на портах, которые соответствуют рабам ldap:

stunnel -c -d 9636 -r  slave1.test.ru:636

stunnel -c -d 10636 -r  slave2.test.ru:636

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

Создание объектов LDAP. Файлы схем

LDAP, как уже было сказано, является расширяемой объектно-ориентированной системой, и вы можете добавлять новые классы с новыми атрибутами в базу LDAP. Для этой цели существуют файлы схем. В файле схемы описываются классы и их атрибуты, чтобы подключить схему к LDAP, необходимо прописать в файле slapd.conf полный путь к нужной схеме. По умолчанию к LDAP подключены несколько основных схем, существуют также сторонние схемы, например для SAMBA или некоторых почтовых серверов. Чтобы эти схемы использовать, в slapd.conf прописывают нечто подобное:

# Включаем схемы по умолчанию командой include

include /usr/share/openldap/schema/core.schema

include /usr/share/openldap/schema/cosine.schema

include /usr/share/openldap/schema/inetorgperson.schema

# Включаем схему самбы

include /usr/share/openldap/schema/samba.schema

# Включаем свою схему

include /usr/share/openldap/schema/my_cool.schema

Теперь разберёмся, как эти схемы создавать. Если вы откроете какую-нибудь схему, то сначала всё покажется довольно жутким. Хочу сразу же вас обрадовать: это действительно жутко! Чтобы хоть чего-то объяснить расскажу об OID. OID (уникальный идентификатор объекта) используется LDAP, чтобы не было наложений классов и их атрибутов. OID состоит из числовых значений разделённых точкой и составляющих в целом иерархию OID: