5. Настройка slapd

После того как программное обеспечение было собрано и установлено, можно приступать к настройке slapd(8) для работы Вашего каталога.

В OpenLDAP 2.3 и более новых версиях осуществлён переход к использованию механизма динамической конфигурации времени исполнения, slapd-config(5). slapd-config(5):

полностью поддерживает LDAP;
управляется с помощью стандартных операций LDAP;
хранит свои конфигурационные данные в базе данных LDIF, обычно в директории /usr/local/etc/openldap/slapd.d;
позволяет менять все настройки slapd на лету, обычно не требуя перезагрузки демона для вступления изменений в силу.

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

Конфигурационный файл в старом стиле slapd.conf(5) до сих пор поддерживается, но его использование не рекомендуется. В будущих версиях OpenLDAP его поддержка будет прекращена. Настройка slapd(8) с помощью slapd.conf(5) описана в следующем разделе.

За информацией о том, как с помощью slapd автоматически преобразовать файл slapd.conf(5) в формат slapd-config(5), обратитесь к man-странице slapd(8).

Примечание: Несмотря на то, что система slapd-config(5) хранит свою конфигурацию в LDIF (текстовых) файлах, Вам ни в коем случае не следует напрямую редактировать какие-либо LDIF-файлы. Изменения конфигурации должны выполняться с помощью операций LDAP, таких как ldapadd(1), ldapdelete(1) или ldapmodify(1).

Примечание: Необходимо продолжать использование старой системы конфигурации slapd.conf(5) в том случае, когда для работы Вашего каталога OpenLDAP требуется один или несколько механизмов манипуляции данными или наложений, которые еще не адаптированы для использования с системой slapd-config(5). В OpenLDAP версии 2.4.33 адаптированы все официальные механизмы манипуляции данными. Однако могут быть неадаптированы некоторые дополнительно распространяемые или экспериментальные наложения.

5.1. Макет конфигурации

Конфигурация slapd хранится в специальном каталоге LDAP с предопределенными схемой и DIT. Для хранения глобальных конфигурационных опций, определений схем, механизмов манипуляции данными, баз данных и различных других значений используются специфические объектные классы. Примерное дерево конфигурации показано на рисунке 5.1.

Рисунок 5.1: Примерное дерево конфигурации.

В конфигурации могут быть и другие объекты, но для ясности иллюстрации они были исключены.

У дерева конфигурации slapd-config очень специфичная структура. Корневая запись называется cn=config и содержит глобальные установки конфигурации. Дополнительные установки содержатся в отдельных дочерних записях:

Модули, загружаемые динамически
Определения схемы
Настройки конкретных механизмов манипуляции данными
Настройки конкретных баз данных

К конфигурационной информации применимы обычные правила для LDIF-файлов. Строки комментариев, начинающиеся с символа '#', игнорируются. Если строка начинается с единичного пробела, то она считается продолжением предыдущей строки (даже если предыдущие строки является комментарием) и этот пробел будет удален. Записи разделяются пустыми строками.

Основные разделы конфигурационного LDIF выглядят следующим образом:

        # глобальные настройки конфигурации
        dn: cn=config
        objectClass: olcGlobal
        cn: config
        <глобальные настройки>

        # определения схемы
        dn: cn=schema,cn=config
        objectClass: olcSchemaConfig
        cn: schema
        <системная схема>

        dn: cn={X}core,cn=schema,cn=config
        objectClass: olcSchemaConfig
        cn: {X}core
        <набор схемы core>

        # дополнительные определённые пользователем наборы схемы 
        ...

        # определения механизма манипуляции данными
        dn: olcBackend=<typeA>,cn=config
        objectClass: olcBackendConfig
        olcBackend: <typeA>
        <настройки, специфичные для механизма манипуляции данными>

        # определения базы данных
        dn: olcDatabase={X}<typeA>,cn=config
        objectClass: olcDatabaseConfig
        olcDatabase: {X}<typeA>
        <настройки, специфичные для базы данных>

        # последующие определения и настройки
        ...

В названиях некоторых из перечисленных выше записей есть числовой индекс "{X}". Дело в том, что базы данных LDAP изначально неупорядочены, а большинство настроек конфигурации имеют зависимость от порядка их применения, то есть применение одной настройки возможно только до (или только после) применения другой. Числовые индексы как раз используются для обеспечения последовательного упорядочения в базе данных конфигурации, таким образом соблюдается зависимость от порядка применения настроек. В большинстве случаев не требуется явного указания индекса; он будет сгенерирован автоматически на основании порядка занесения записей.

Директивы конфигурации задаются как значения отдельных атрибутов. Большинство атрибутов и объектных классов, используемых в конфигурации slapd, содержат в своих именах префикс "olc" (OpenLDAP Configuration). Практически, поддерживается однозначное соответствие между атрибутами в новом стиле конфигурации и ключевыми словами файла slapd.conf в старом стиле: названием атрибута служит ключевое слово файла с добавлением префикса "olc".

Директивы конфигурации могут иметь аргументы. В таком случае аргументы разделяются пробелами. Если в самом аргументе есть пробел, этот аргумент должен быть заключён в двойные кавычки "вот так". В дальнейшем тексте описания аргументов, которые требуется заменить на актуальный текст, заключены в угловые скобки <>.

В дистрибутиве есть пример конфигурационного файла, который будет устанавливаться в директорию /usr/local/etc/openldap. Несколько файлов, содержащих определение схемы (типов атрибутов и объектных классов) также помещаются в директорию /usr/local/etc/openldap/schema.

5.2. Директивы конфигурации

В этом подразделе детально описаны часто используемые директивы конфигурации, полный список директив можно найти в man-странице slapd-config(5). Конфигурационные директивы в этом подразделе рассматриваются в порядке "сверху-вниз", начиная от глобальных директив в записи cn=config. Для каждой директивы дается её описание, значение по умолчанию (если есть), и пример использования.

5.2.1. cn=config

Директивы, содержащиеся в этой записи, как правило, касаются сервера в целом. Большинство из них являются системными или ориентированными на подключение, и не связаны с базами данных. Эта запись должна иметь объектный класс olcGlobal.

5.2.1.1. olcIdleTimeout: <целое число>

Определяет количество секунд до того, как принудительно закрыть простаивающее клиентское соединение. При установке в 0 (значение по умолчанию), эта функция отключается.

5.2.1.2. olcLogLevel: <уровень>

Эта директива определяет уровень отладочной информации и статистики работы slapd, которая должна быть журналирована (в настоящее время журналируется в канал LOG_LOCAL4 syslogd(8)). Чтобы это работало (за исключением двух уровней статистики, которые всегда включены), при конфигурации перед сборкой OpenLDAP нужно указать --enable-debug (по умолчанию включено). Уровни журналирования могут быть указаны целым числом или ключевым словом. Можно задать несколько уровней журналирования, либо указать несколько уровней как сумму соответствующих целых чисел. Чтобы узнать соответствие числового значения типу отладочной информации, запустите slapd с ключом -d? или посмотрите таблицу ниже. Возможные значения <уровня>:

Таблица 5.1: Уровни отладки
Уровень	Ключевое слово	Описание
-1	any	включить всю отладочную информацию
0		отключить отладку
1	(0x1 trace)	отслеживать вызовы функций
2	(0x2 packets)	отладка обработки пакетов
4	(0x4 args)	усиленная отладка
8	(0x8 conns)	управление соединениями
16	(0x10 BER)	вывод посылки и приёма пакетов
32	(0x20 filter)	обработка поисковых фильтров
64	(0x40 config)	обработка конфигурации
128	(0x80 ACL)	обработка списков контроля доступа
256	(0x100 stats)	статистика соединений/операций/результатов
512	(0x200 stats2)	статистика посылки записей журнала
1024	(0x400 shell)	вывод взаимодействия с механизмами манипуляции данными shell
2048	(0x800 parse)	вывод отладочной информации разбора записей
16384	(0x4000 sync)	обслуживание потребителей syncrepl
32768	(0x8000 none)	только сообщения, выводимые независимо от заданного уровня журналирования (то есть высокоприоритетные)

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

                olcLogLevel 129
                olcLogLevel 0x81
                olcLogLevel 128 1
                olcLogLevel 0x80 0x1
                olcLogLevel acl trace

эквивалентны.

Примеры:

 olcLogLevel -1

Это вызывает журналирование большого количества отладочной информации.

 olcLogLevel conns filter

Журналирование только информации о соединениях и обработке поисковых фильтров.

 olcLogLevel none

Журналирование только тех сообщений, которые выводятся вне зависимости от настроенного уровня журналирования. Это отличается от установки уровня журналирования в 0, когда журналирование отсутствует. Для журналирования высокоприоритетных сообщений требуется как минимум уровень None.

Значение по умолчанию:

 olcLogLevel stats

По умолчанию настраивается журналирование основных статистических сведений. Однако, если не определено никакого olcLogLevel, журналирования не происходит (как в уровне 0).

5.2.1.3. olcReferral <URI>

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

Пример:

        olcReferral: ldap://root.openldap.org

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

5.2.1.4. Пример записи

dn: cn=config
objectClass: olcGlobal
cn: config
olcIdleTimeout: 30
olcLogLevel: Stats
olcReferral: ldap://root.openldap.org

5.2.2. cn=module

Если при сборке slapd была включена поддержка динамически загружаемых модулей, можно использовать записи cn=module для указания набора модулей, которые требуется загрузить. Записи module должны иметь объектный класс olcModuleList.

5.2.2.1. olcModuleLoad: <имя файла>

Указывает имя динамически-загружаемого модуля, который требуется загрузить. Параметр <имя файла> может быть определён либо как абсолютный путь к файлу, либо просто именем файла. Если для файла не задан абсолютный путь, то slapd попытается найти его в директориях, указанных в директиве olcModulePath.

5.2.2.2. olcModulePath: <список путей>

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

5.2.2.3. Примеры записей

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: /usr/local/lib/smbk5pwd.la

dn: cn=module{1},cn=config
objectClass: olcModuleList
cn: module{1}
olcModulePath: /usr/local/lib:/usr/local/lib/slapd
olcModuleLoad: accesslog.la
olcModuleLoad: pcache.la

5.2.3. cn=schema

Запись cn=schema содержит все определения системной схемы данных, которые жёстко вкомпилированы в slapd. В связи с этим, значения этой записи генерируются самим slapd и не требуется указывать никаких значений системной схемы в конфигурационном файле. Тем не менее, эта запись должна быть указана, поскольку она служит базовой записью для добавления пользовательских наборов схемы. Записи schema должны иметь объектный класс olcSchemaConfig.

5.2.3.1. olcAttributeTypes: <описание типа атрибута согласно RFC4512>

Эта директива определяет тип атрибута. О том, как использовать эту директиву, читайте в разделе Спецификация схемы данных каталога.

5.2.3.2. olcObjectClasses: <описание объектного класса согласно RFC4512>

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

5.2.3.3. Примеры записей

dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema

dn: cn=test,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: test
olcAttributeTypes: ( 1.1.1
  NAME 'testAttr'
  EQUALITY integerMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
olcAttributeTypes: ( 1.1.2 NAME 'testTwo' EQUALITY caseIgnoreMatch
  SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
olcObjectClasses: ( 1.1.3 NAME 'testObject'
  MAY ( testAttr $ testTwo ) AUXILIARY )

5.2.4. Директивы, специфичные для механизмов манипуляции данными

Настройки из директив backend применяются ко всем экземплярам баз данных того же типа и, в зависимости от директивы, могут переопределяться директивами конкретной базы данных. Записи backend должны иметь объектный класс olcBackendConfig.

5.2.4.1. olcBackend: <тип>

Эта директива обозначает запись, в которой задаётся конфигурация, специфичная для конкретного механизма манипуляции данными. <Тип> должен быть одним из поддерживаемых типов механизмов, перечисленных в таблице 5.2.

Таблица 5.2: Механизмы манипуляции данными
Тип	Описание
`bdb`	Механизм Berkeley DB с поддержкой транзакций (устаревший)
`config`	Механизм конфигурации slapd
`dnssrv`	Механизм DNS SRV
`hdb`	Иерархический вариант механизма bdb (устаревший)
`ldap`	Механизм Lightweight Directory Access Protocol (прокси)
`ldif`	Механизм Lightweight Data Interchange Format (LDIF)
`mdb`	Механизм Memory-Mapped DB (отображаемая в памяти база данных)
`meta`	Механизм мета-каталога
`monitor`	Механизм мониторинга
`passwd`	Предоставление доступа только для чтения к passwd(5)
`perl`	Программируемый механизм Perl
`shell`	Механизм запуска внешних программ Shell
`sql`	Программируемый механизм SQL

Пример:

        olcBackend: bdb

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

5.2.4.2. Пример записи

 dn: olcBackend=bdb,cn=config
 objectClass: olcBackendConfig
 olcBackend: bdb

5.2.5. Директивы, специфичные для базы данных

Директивы в этом подразделе поддерживаются всеми типами баз данных. Записи database должны иметь объектный класс olcDatabaseConfig.

5.2.5.1. olcDatabase: [{<индекс>}]<тип>

Эта директива обозначает запись для конкретного экземпляра базы данных. Цифровой {<индекс>} может быть указан для того, чтобы различать несколко баз данных одного и того же типа. Обычно этот индекс можно опустить, и slapd сгенерирует его автоматически. <Тип> должен быть одним из поддерживаемых типов механизмов манипуляции данными, перечисленных в таблице 5.2, или тип frontend.

Специальная база данных frontend используется для указания настроек уровня базы данных, которые будут применяться ко всем остальным базам данных. Определения в записях конкретных баз данных могут переопределять некоторые настройки базы данных frontend.

Также существует специальная база данных config; обе базы данных config и frontend всегда неявно создаются, даже если они не были сконфигурированы явно, и они создаются перед всеми остальными базами данных.

Пример:

        olcDatabase: bdb

Здесь обозначено начало определения настроек нового экземпляра базы данных BDB.

5.2.5.2. olcAccess: to <what> [ by <who> [<accesslevel>] [<control>] ]+

Эта директива предоставляет доступ (заданный аргументом <accesslevel>) к набору записей и/или атрибутов (заданный аргументом <what>) одному или нескольким пользователям (заданным аргументом <who>). Смотрите раздел Контроль доступа данного руководства для получения подробных сведений о настройке.

Замечание: Если не задано ни одной директивы olcAccess, применяется политика контроля доступа по умолчанию access to * by * read, предоставляющая всем пользователям (как авторизованным, так и анонимным) доступ на чтение.

Замечание: Настройки контроля доступа, определённые в базе данных frontend, добавляются к настройкам контроля доступа всех остальных баз данных.

5.2.5.3. olcReadonly { TRUE | FALSE }

Эта директива переводит базу данных в режим "только для чтения". На все попытки внесения в базу данных изменений возвращается ошибка "unwilling to perform" ("не желают выполнять"). Если эта директива настроена на потребителе репликации, модификации, посылаемые механизмом syncrepl, всё равно будут применяться.

Значение по умолчанию:

        olcReadonly: FALSE

5.2.5.4. olcRootDN: <DN>

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

Пример с записью:

        olcRootDN: "cn=Manager,dc=example,dc=com"

Пример с SASL:

        olcRootDN: "uid=root,cn=example.com,cn=digest-md5,cn=auth"

Информацию об аутентификационных идентификационных сущностях SASL можно посмотреть в разделе Аутентификация SASL.

5.2.5.5. olcRootPW: <password>

Эта директива может использоваться для назначения пароля для DN из rootdn (когда в качестве rootdn назначен DN из этой базы данных).

Пример:

        olcRootPW: secret

Также можно назначить хэш пароля в форме RFC2307. Для генерации хэша пароля можно использовать slappasswd(8).

Пример:

        olcRootPW: {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN

Данный хэш был сгенерирован командой slappasswd -s secret.

5.2.5.6. olcSizeLimit: <целое число>

Эта директива определяет максимальное количество записей, возвращаемых поисковым запросом.

Значение по умолчанию:

        olcSizeLimit: 500

Для получения дополнительной информации смотрите раздел Ограничения этого руководства и slapd-config(5).

5.2.5.7. olcSuffix: <dn суффикса>

Эта директива определяет DN суффикса запросов, которые будут направляться в эту базу данных. Возможно определение нескольких суффиксов. Обычно как минимум один суффикс должен быть определён для каждой базы данных. (Некоторые типы механизмов манипуляции данными, такие как frontend и monitor используют жестко-прописанный суффикс, который невозможно переопределить в конфигурации).

Пример:

        olcSuffix: "dc=example,dc=com"

Запросы с DN, оканчивающимся на "dc=example,dc=com" будут направлены в эту базу данных.

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

5.2.5.8. olcSyncrepl

        olcSyncrepl: rid=<replica ID>
                provider=ldap[s]://<имя хоста>[:порт]
                [type=refreshOnly|refreshAndPersist]
                [interval=dd:hh:mm:ss]
                [retry=[<интервал между повторами> <количество повторов>]+]
                searchbase=<base DN>
                [filter=<строка фильтра>]
                [scope=sub|one|base]
                [attrs=<список атрибутов>]
                [attrsonly]
                [sizelimit=<limit>]
                [timelimit=<limit>]
                [schemachecking=on|off]
                [bindmethod=simple|sasl]
                [binddn=<DN>]
                [saslmech=<mech>]
                [authcid=<identity>]
                [authzid=<identity>]
                [credentials=<passwd>]
                [realm=<realm>]
                [secprops=<properties>]
                [starttls=yes|critical]
                [tls_cert=<file>]
                [tls_key=<file>]
                [tls_cacert=<file>]
                [tls_cacertdir=<path>]
                [tls_reqcert=never|allow|try|demand]
                [tls_cipher_suite=<ciphers>]
                [tls_crlcheck=none|peer|all]
                [logbase=<base DN>]
                [logfilter=<filter str>]
                [syncdata=default|accesslog|changelog]

Эта директива определяет, что текущая база данных будет репликой содержимого каталога основного сервера, и текущий slapd(8) будет работать в роли сервера-потребителя репликации путём запуска механизма syncrepl. Основная база данных располагается на сервере-поставщике репликации, указанном в параметре provider. База данных реплики синхронизируется с содержимым каталога основного сервера с использованием LDAP Content Synchronization protocol (протокол синхронизации содержимого LDAP). Описание протокола можно найти в RFC4533 ^(рус.) (RFC4533 ^(ориг.)).

Параметр rid используется для идентификации текущей директивы syncrepl в пределах сервера-потребителя репликации. <ID реплики> — уникальный идентификатор спецификации syncrepl, описываемой текущей директивой syncrepl. <ID реплики> должен быть положительным числом длиной не более трёх десятичных цифр.

Параметр provider определяет адрес поставщика репликации как LDAP URI. Параметр provider указывается схемой (ldap или ldaps), именем хоста и, опционально, номером порта, на котором будет слушать slapd поставщика. В качестве <имени хоста> может быть как доменное имя, так и IP-адрес. Например, ldap://provider.example.com:389 или ldaps://192.168.1.1:636. Если <порт> не задан, используются стандартные номера портов LDAP (389 или 636). Обратите внимание, что механизм syncrepl использует протокол, инициируемый со стороны потребителя, поэтому директивы его настройки располагаются на сервере потребителя, в то время как директивы replica располагаются на стороне поставщика. Директивы syncrepl и replica определяют две независимые части механизма репликации. Они не устанавливают никаких взаимных потоков репликации друг к другу.

Содержимое реплики syncrepl формируется как результат поискового запроса. slapd потребителя посылает поисковые запросы к slapd поставщика согласно данной ему спецификации поискового запроса. Спецификация поискового запроса включает в себя параметры searchbase, scope, filter, attrs, attrsonly, sizelimit и timelimit, как и в случае обычного поискового запроса. У параметра searchbase нет значения по умолчанию и он должен быть задан обязательно. Значения по умолчанию остальных параметров: scope — sub, filter — (objectclass=*), attrs — "*,+" (то есть репликация и пользовательских, и операционных атрибутов), attrsonly по умолчанию не задан. Параметры sizelimit и timelimit по умолчанию установлены в "unlimited", и могут задаваться либо положительным целым числом, либо "unlimited".

У протокола LDAP Content Synchronization два типа операций: refreshOnly и refreshAndPersist. Тип операций задаётся параметром type. При типе операций refreshOnly время выполнения следующей операции синхронизационного поиска периодически переназначается на заданный временной интервал после окончания предыдущей операции синхронизации. Интервал указывается параметром interval, по умолчанию заданным в 1 день. При типе операций refreshAndPersist синхронизационный поиск постоянно выполняется в экземпляре slapd поставщика. При дальнейшем обновлении каталога поставщика будет генерироваться searchResultEntry и отправляться slapd потребителя как ответ на постоянный синхронизационный поиск на стороне поставщика.

При возникновении ошибок в процессе репликации, потребитель будет пытаться сделать повторное подключение в соответствии с указанным в параметре retry списком пар значений <интервал между повторами> и <количество повторов>. Например, retry="60 10 300 3" позволяет получателю повторять запрос через каждые 60 секунд первые 10 раз, а затем через каждые 300 секунд еще 3 раза перед тем, как прекратить попытки. Если в <количестве повторов> указан +, то повторные попытки будут осуществляться до получения положительного результата (неограниченное количество раз).

С помощью параметра schemachecking можно включить принудительную проверку получаемых данных на соответствие схеме данных на стороне потребителя LDAP Sync. Если он установлен в on, каждая реплицируемая запись будет проверяться, не нарушит ли она целостности схемы данных при помещении её в базу данных реплики. Каждая запись в реплике должна содержать те атрибуты, которые помечены как обязательные в определении схемы. Если этот параметр установлен в off, записи будут сохраняться без проверки на соответствие схеме. Значение по умолчанию — off.

Параметр binddn указывает DN, под которым будет происходить соединение с slapd поставщика для выполнения поисковых запросов syncrepl. Этот DN должен иметь права на чтение к реплицируемому содержимому каталога на главном сервере.

Параметр bindmethod может быть либо simple, либо sasl, в зависимости от метода аутентификации (простая парольная или SASL), используемого при соединении с slapd поставщика.

Лучше не использовать простую аутентификацию, если не предприняты адекватные меры защиты целостности и конфиденциальности данных (такие как TLS или IPsec). При использовании простой аутентификации требуется задать параметры binddn и credentials.

В общем случае рекомендуется использование аутентификации SASL. Аутентификация SASL требует указания механизма с использованием параметра saslmech. В зависимости от механизма, можно задать аутентификационную идентификационную сущность и/или учётные данные с помощью соответствующих параметров authcid и credentials. Параметр authzid может быть использован для определения авторизационной идентификационной сущности.

Параметр realm указывает realm, с которым некоторые механизмы проводят аутентификацию идентификационной сущности. В параметре secprops указываются настройки безопасности Cyrus SASL.

Параметр starttls указывает использование расширенной операции StartTLS для установки сессии TLS до начала аутентификации при подключении к серверу-поставщику. Если установлен аргумент critical, сессия будет прервана в случае неудачного завершения запроса StartTLS. Если этот аргумент не был установлен, сессия syncrepl будет продолжена без TLS. Параметр tls_reqcert по умолчанию установлен в "demand", значения по умолчанию других настроек TLS соответствуют значениям аналогичных основных настроек TLS slapd.

Вместо того, чтобы реплицировать записи целиком, потребитель может запрашивать журналы изменений данных. Этот режим работы называется дельта-syncrepl. В дополнение к вышеперечисленным параметрам, нужно установить параметры logbase и logfilter в соответствии с типом журнала, который будет использоваться. Параметр syncdata должен быть задан либо в "accesslog" если журнал соответствует формату slapo-accesslog(5), либо в "changelog" если журнал соответствует устаревшему формату changelog. Если параметр syncdata пропущен или установлен в "default", то параметры журналирования игнорируются.

Механизм репликации syncrepl поддерживается механизмами манипуляции данными bdb, hdb и mdb.

Дополнительная информация по использованию этой директивы в разделе Репликация на основе LDAP Sync этого руководства.

5.2.5.9. olcTimeLimit: <целое число>

Эта директива указывает максимальное количество секунд, которое slapd может потратить, чтобы ответить на поисковый запрос. Если запрос не был обработан за это время, клиенту возвращается уведомление о превышении времени обработки.

Значение по умолчанию:

        olcTimeLimit: 3600

Для получения дополнительной информации смотрите раздел Ограничения этого руководства и slapd-config(5).

5.2.5.10. olcUpdateref: <URL>

Эта директива применяется только в случае работы slapd в режиме подчинённого сервера. Она указывает URL, возвращаемый клиентам при попытке выполнить на реплике запрос на обновление. Если директива указывается несколько раз, клиенту возвращаются все URL.

Пример:

        olcUpdateref:   ldap://master.example.net

5.2.5.11. Примеры записей

dn: olcDatabase=frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: frontend
olcReadOnly: FALSE

dn: olcDatabase=config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: config
olcRootDN: cn=Manager,dc=example,dc=com

5.2.6. Директивы баз данных BDB и HDB

Директивы этой категории применимы как к базам данных BDB, так и HDB. Они используются в записи olcDatabase в дополнение к общим директивам баз данных, описанным выше. Полное руководство по конфигурационным директивам BDB/HDB смотрите в slapd-bdb(5). В дополнение к объектному классу olcDatabaseConfig, записи баз данных BDB и HDB должны иметь объектные классы olcBdbConfig и olcHdbConfig соответственно.

5.2.6.1. olcDbDirectory: <директория>

Эта директива указывает директорию, где будут находиться файлы BDB, содержащие базу данных, и соответствующие им индексы.

Значение по умолчанию:

        olcDbDirectory: /usr/local/var/openldap-data

5.2.6.2. olcDbCachesize: <целое число>

Эта директива указывает размер (в количестве записей) кэша в оперативной памяти, создаваемого экземпляром базы данных механизма манипуляции данными BDB.

Значение по умолчанию:

        olcDbCachesize: 1000

5.2.6.3. olcDbCheckpoint: <Кбайты> <минуты>

Эта директива устанавливает контрольные точки для сброса журнала транзакций BDB. При срабатывании контрольной точки буферы базы данных записываются на диск и в журнал помещается запись о прохождении контрольной точки. Срабатывание контрольной точки наступает либо когда определённое количество <Кбайт> было записано, либо когда с момента последней контрольной точки прошло определённое количество <минут>. По умолчанию оба аргумента установлены в ноль, в этом случае они игнорируются. Когда аргумент <минуты> не нулевой, периодический процесс будет запускаться через указанное количество <минут> для выполнения контрольной точки. Дополнительные детали можно найти в документации Berkeley DB.

Пример:

        olcDbCheckpoint: 1024 10

5.2.6.4. olcDbConfig: <настройки DB_CONFIG>

Этот атрибут указывает директиву конфигурации, которая будет помещена в файл DB_CONFIG в директории, где находятся файлы базы данных. Если во время запуска сервера такого файла не существует, он будет создан, и в него будут записаны настройки из этого атрибута. Если файл существует, его содержимое будет прочитано и отображено в этом атрибуте. Атрибут может иметь несколько значений для размещения нескольких директив конфигурации. Значения по умолчанию не определены, но, чтобы добиться хорошей производительности сервера, в этом атрибуте важно использовать правильные настройки.

Любые изменения данного атрибута будут записаны в файл DB_CONFIG и заставят окружение базы данных перечитать свои настройки, поэтому изменения будут применены сразу. Если кэш окружения базы данных большой и давно не сбрасывался при прохождении контрольной точки, данная операция перечитывания настроек может занять продолжительное время. В таком случае может быть целесообразным выполнить единичный сброс в контрольной точке вручную, используя утилиту Berkeley DB db_checkpoint, перед тем, как использовать операцию LDAP Modify для изменения этого атрибута.

Пример:

        olcDbConfig: set_cachesize 0 10485760 0
        olcDbConfig: set_lg_bsize 2097512
        olcDbConfig: set_lg_dir /var/tmp/bdb-log
        olcDbConfig: set_flags DB_LOG_AUTOREMOVE

В этом примере устанавливается размер кэша BDB в 10Мб, размер буфера журнала транзакций BDB в 2Мб, и директория /var/tmp/bdb-log указывается как место хранения файлов журнала транзакций. Также устанавливается флаг, требующий, чтобы BDB удалял файлы журнала транзакций по мере сброса их содержимого во время прохождения контрольных точек, когда информация в этих файлах уже не нужна. Без этой настройки файлы журнала транзакций будут складироваться до тех пор, пока не будут удалены какой-нибудь другой процедурой очистки. Подробнее об этом смотрите в описании команды db_archive в документации Berkeley DB. Полный список флагов Berkeley DB можно найти на странице http://www.oracle.com/technology/documentation/berkeley-db/db/api_c/env_set_flags.html.

В идеале размер кэша BDB должен быть настолько велик, чтобы в неё как минимум помещался рабочий набор данных базы данных, размер буфера журнала должен вмещать большое количество транзакций без переполнения, а директория хранения журнала должна помещаться на отдельном от основных файлов базы данных физическом диске. Обе эти директории (хранящие базу данных и журналы) не должны также размещаться на диске, используемом для регулярной работы системы, то есть на том, где размещены корневая, загрузочная файловые системы и область подкачки. Дополнительные детали можно найти в FAQ-o-Matic и документации Berkeley DB.

5.2.6.5. olcDbNosync: { TRUE | FALSE }

Эта опция отменяет немедленную синхронизацию между данными в оперативной памяти и содержимым базы данных на диске при внесении изменений. Установка этой опции в TRUE может повысить производительность за счёт возможной потери целостности данных при крахе системы. Эта директива имеет тот же эффект, что и использование

        olcDbConfig: set_flags DB_TXN_NOSYNC

5.2.6.6. olcDbIDLcacheSize: <целое число>

Указывает размер (в слотах индексов) кэша индексов в оперативной памяти. По умолчанию равен нулю. Большее значение увеличит скорость выполнения частых запросов на получение индексированных записей. Оптимальный размер зависит от данных и поисковых характеристик базы данных, однако хорошей отправной точкой будет использование кэша индексов, в 3 раза превышающего кэш записей.

Пример:

        olcDbIDLcacheSize: 3000

5.2.6.7. olcDbIndex: {<список атрибутов> | default} [pres,eq,approx,sub,none]

Эта директива определяет индексирование, которое будет применяться к указанным атрибутам. Если задан только <список атрибутов>, к этим атрибутам будет применяться индексирование по умолчанию. Ключевые слова, с помощью которых задаются индексы, коррелируют с обычными типами соответствия, которые могут быть использованы в поисковых фильтрах LDAP.

Примеры:

        olcDbIndex: default pres,eq
        olcDbIndex: uid
        olcDbIndex: cn,sn pres,eq,sub
        olcDbIndex: objectClass eq

В первой строке задаётся набор индексов по умолчанию, включающий индексы наличия (pres) и равенства (eq). Во второй строке эти индексы по умолчанию (pres,eq) устанавливаются для типа атрибута uid. В третьей строке для типов атрибутов cn и sn устанавливаются индексы наличия, равенства и равенства подстроке (sub). В четвёртой строке устанавливается индекс равенства для типа атрибута objectClass.

Не существует ключевого слова индекса для соответствий типа "неравенство". Как правило, такие соответствия не используют индексы. Однако, некоторые атрибуты поддерживают индексирование для соответствий типа "неравенство", основанное на индексе равенства.

Индекс равенства подстроке может быть задан более конкретно как subinitial, subany или subfinal, коррелируя с тремя возможными компонентами фильтра соответствия равенству подстроке. Индекс subinitial индексирует только подстроки, с которых начинается значение атрибута. Индекс subfinal индексирует только подстроки, которыми закачивается значение атрибута, а индекс subany индексирует подстроки, которые могут встретиться в любом месте значения атрибута.

Обратите внимание, что, по умолчанию, установка индекса на какой-либо атрибут также влияет на каждый подтип этого атрибута. Например, установка индекса равенства на атрибут name создаст аналогичное индексирование на cn, sn и все остальные атрибуты, унаследованные от name.

По умолчанию индексирование не применяется. В общем случае, важно установить хотя бы индекс равенства на тип атрибута objectClass.

        olcDbindex: objectClass eq

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

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

5.2.6.8. olcDbLinearIndex: { TRUE | FALSE }

Если данная директива установлена в TRUE, slapindex будет индексировать по одному атрибуту за раз, а если в FALSE (значение по умолчанию), то все проиндексированные атрибуты записи будут обрабатываться одновременно. Поскольку при установке в TRUE каждый индексированный атрибут обрабатывается индивидуально, приходится несколько раз проходить по всей базе данных. Эта опция повышает производительность slapindex, если размер базы данных превышает размер кэша BDB. Если размер кэша BDB достаточно велик, использование этой опции не требуется и может понизить производительность. Также, по умолчанию, slapadd выполняет полное индексирование, поэтому отдельно запускать slapindex не требуется. Если эта опция установлена в TRUE, slapadd не выполняет индексирования, и нужно обязательно запускать slapindex.

5.2.6.9. olcDbMode: { <восьмеричное> | <символическое представление> }

Эта директива указывает режим защиты файлов, который будет задан для вновь создаваемых файлов индексов базы данных. Режим может быть указан либо в форме 0600, либо в форме -rw-------

Значение по умолчанию:

        olcDbMode: 0600

5.2.6.10. olcDbSearchStack: <целое число>

Указывает глубину стека, используемого для оценки поискового фильтра. Оценка поисковых фильтров происходит с помощью стека, в котором размещаются вложенные условия AND / OR. Для каждого серверного потока выделяется собственный стек. Глубина стека определяет, насколько комплексный фильтр может быть оценен без необходимости выделения какой-либо дополнительной памяти. Для операции поиска с фильтром, вложенность которого глубже, чем глубина поискового стека, потребуется отдельный стек, который будет выделен для выполнения этой конкретной операции. Такие отдельные выделения памяти могут оказать существенное негативное влияние на производительность сервера, но, с другой стороны, выделение слишком большого стека также приведёт к потреблению большого объёма памяти. Каждый поиск использует 512Кб на один уровень на 32-битной машине, или 1024Кб на один уровень на 64-битной машине. Глубина стека по умолчанию — 16, таким образом, каждому процессу выделяется по 8Мб или по 16Мб оперативной памяти на 32 и 64-битных машинах соответственно. Размер одного слота стека в 512Кб устанавливается с помощью константы во время компиляции, при необходимости его можно изменить; чтобы изменения вступили в силу, требуется перекомпиляция исходного кода.

Значение по умолчанию:

        olcDbSearchStack: 16

5.2.6.11. olcDbShmKey: <целое число>

Указывает ключ разделяемой памяти для окружения BDB. По умолчанию окружение BDB использует отображаемые в памяти файлы. Если задано ненулевое значение, оно будет использовано как ключ для идентификации области разделяемой памяти, в которой будет помещено окружение.

Пример:

        olcDbShmKey: 42

5.2.6.12. Пример записи

dn: olcDatabase=hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: hdb
olcSuffix: "dc=example,dc=com"
olcDbDirectory: /usr/local/var/openldap-data
olcDbCacheSize: 1000
olcDbCheckpoint: 1024 10
olcDbConfig: set_cachesize 0 10485760 0
olcDbConfig: set_lg_bsize 2097152
olcDbConfig: set_lg_dir /var/tmp/bdb-log
olcDbConfig: set_flags DB_LOG_AUTOREMOVE
olcDbIDLcacheSize: 3000
olcDbIndex: objectClass eq

5.3. Пример конфигурации

Далее приведён пример конфигурации вперемешку с поясняющим его текстом. В нём определены две базы данных (обе они BDB), содержащие разные части дерева X.500. Номера строк приведены с целью дальнейших пояснений и не должны включаться в реальный файл. Итак, сначала секция глобальных настроек:

  1.    # пример конфигурационного файла - секция глобальных настроек
  2.    dn: cn=config
  3.    objectClass: olcGlobal
  4.    cn: config
  5.    olcReferral: ldap://root.openldap.org
  6.

Строка 1 — комментарий. Строки 2-4 идентифицируют данную запись как запись глобальной конфигурации. Директива olcReferral: в строке 5 означает, что на запросы, не относящиеся ни к одной из баз данных, определённых ниже, будет возвращаться отсылка на LDAP сервер, работающий на стандартном порту (389) по адресу root.openldap.org. Пустая строка 6 указывает на окончание определения записи.

  7.    # внутренняя схема данных
  8.    dn: cn=schema,cn=config
  9.    objectClass: olcSchemaConfig
 10.    cn: schema
 11.

Строка 7 — комментарий. Строки 8-10 идентифицируют данную запись как корень поддерева схемы данных. Актуальные определения схемы в этой записи жёстко вкомпилированы в slapd, поэтому не требуется дополнительных атрибутов для их указания при конфигурации. Пустая строка 11 указывает на окончание определения записи.

 12.    # подключение набора схемы core
 13.    include: file:///usr/local/etc/openldap/schema/core.ldif
 14.

Строка 12 — комментарий. Строка 13 — это LDIF-директива include для доступа к определениям набора схемы core в формате LDIF. Строка 14 пуста.

Далее идут определения баз данных. Первая база данных — это специальная база данных frontend, настройки которой применяются глобально ко всем остальным базам данных.

 15.    # глобальные параметры баз данных
 16.    dn: olcDatabase=frontend,cn=config
 17.    objectClass: olcDatabaseConfig
 18.    olcDatabase: frontend
 19.    olcAccess: to * by * read
 20.

Строка 15 — комментарий. Строки 16-18 идентифицируют данную запись как запись глобальной базы данных. В строке 19 определён глобальный уровень контроля доступа. Он применяется ко всем записям (после применения к ним правил контроля доступа, специфичных для базы данных). Строка 20 пуста.

Следующая запись определяет механизм манипуляции данными config.

 21.    # поставим rootpw для БД config, чтобы можно было к ней подсоединиться.
 22.    # запретим доступ всем остальным.
 23.    dn: olcDatabase=config,cn=config
 24.    objectClass: olcDatabaseConfig
 25.    olcDatabase: config
 26.    olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy
 27.    olcAccess: to * by * none
 28.

Строки 21 и 22 — комментарии. Строки 23-25 идентифицируют данную запись как запись базы данных config. В строке 26 определён пароль администратора для этой базы данных. (По умолчанию DN администратора — "cn=config".) Строка 27 запрещает любой доступ к этой базе данных, таким образом, только администратор может получить к ней доступ. (Такой контроль доступа установлен к базе данных config по умолчанию. Здесь он приведён только для иллюстрации, и для того, чтобы еще раз подчеркнуть, что если параметры аутентификации администратора не будут заданы явно, база данных config будет недоступна).

Строка 28 пуста.

Следующая запись определяет базу данных механизма манипуляции данными BDB, которая будет обрабатывать запросы к части дерева "dc=example,dc=com". К некоторым атрибутам будет применяться индексирование, а атрибут userPassword защищается от несанкционированного доступа.

 29.    # определения BDB для example.com
 30.    dn: olcDatabase=bdb,cn=config
 31.    objectClass: olcDatabaseConfig
 32.    objectClass: olcBdbConfig
 33.    olcDatabase: bdb
 34.    olcSuffix: dc=example,dc=com
 35.    olcDbDirectory: /usr/local/var/openldap-data
 36.    olcRootDN: cn=Manager,dc=example,dc=com
 37.    olcRootPW: secret
 38.    olcDbIndex: uid pres,eq
 39.    olcDbIndex: cn,sn pres,eq,approx,sub
 40.    olcDbIndex: objectClass eq
 41.    olcAccess: to attrs=userPassword
 42.      by self write
 43.      by anonymous auth
 44.      by dn.base="cn=Admin,dc=example,dc=com" write
 45.      by * none
 46.    olcAccess: to *
 47.      by self write
 48.      by dn.base="cn=Admin,dc=example,dc=com" write
 49.      by * read
 50.

Строка 29 — комментарий. Строки 30-33 идентифицируют данную запись как запись конфигурации базы данных BDB. В строке 34 определён DN суффикса запросов, обслуживаемых этой базой данных. В строке 35 указана директория, в которой будут размещаться файлы базы данных.

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

Строки с 38 по 40 устанавливают индексирование для различных атрибутов.

Строки с 41 по 49 определяют контроль доступа к записям в этой базе данных. Во всех записях с атрибутом userPassword изменять этот атрибут может пользователь, ассоциированный с этой же самой записью или с записью "admin". Этот атрибут может использоваться в целях аутентификации/авторизации, в ином случае он недоступен для чтения. Все остальные атрибуты доступны для изменения пользователем, ассоциированным с этой же самой записью или с записью "admin", но доступны для чтения всем пользователям, независимо от того, прошли они аутентификацию или нет.

Пустая строка 50 указывает на окончание определения записи.

Следующая запись определяет другую базу данных BDB. Она обслуживает запросы к поддереву dc=example,dc=net, но управляется той же самой учётной записью, что и первая база данных. Обратите внимание, что если опустить строку 60, доступ на чтение всё равно будет предоставлен по глобальному правилу доступа в строке 19.

 51.    # определения BDB для example.net
 52.    dn: olcDatabase=bdb,cn=config
 53.    objectClass: olcDatabaseConfig
 54.    objectClass: olcBdbConfig
 55.    olcDatabase: bdb
 56.    olcSuffix: "dc=example,dc=net"
 57.    olcDbDirectory: /usr/local/var/openldap-data-net
 58.    olcRootDN: "cn=Manager,dc=example,dc=com"
 59.    olcDbIndex: objectClass eq
 60.    olcAccess: to * by users read

5.4. Конвертирование конфигурационного файла в старом стиле slapd.conf(5) в формат cn=config

Перед тем как конвертировать в формат cn=config, Вы должны убедиться, что механизм манипуляции данными config корректно настроен в уже имеющемся у Вас конфигурационном файле. Дело в том, что механизм config является встроенным и всегда присутствует в slapd. По умолчанию права доступа к нему имеет только его rootDN, однако нет учетных данных, ассоциированных с этой rootDN по умолчанию. Таким образом, если Вы явно не настроите учётные данные для аутентификации к механизму config, его нельзя будет использовать.

Если у Вас ещё нет секции database config, добавьте что-то вроде этого в конец файла slapd.conf

 database config
 rootpw VerySecret

Замечание: Поскольку механизм config может быть использован для загрузки произвольного кода в процесс slapd, особенно важно обеспечить тщательную сохранность всех учётных данных для доступа к нему. Простые пароли уязвимы к атакам методом перебора, поэтому, как правило, лучше отказаться от rootpw и использовать только аутентификацию SASL для rootDN механизма config.

Существующий файл slapd.conf(5) может быть переконвертирован в новый формат с помощью slaptest(8) или любой из slap-утилит:

        slaptest -f /usr/local/etc/openldap/slapd.conf -F /usr/local/etc/openldap/slapd.d

Попробуем возможность доступа к записям поддерева cn=config с использованием rootdn по умолчанию и rootpw, сконфигурированного выше:

        ldapsearch -x -D cn=config -w VerySecret -b cn=config

После этого Вы можете отказаться от старого файла slapd.conf(5). Убедитесь, что Вы запускаете slapd(8) с параметром -F для указания пути к конфигурационной директории, если Вы не используете конфигурационную директорию по умолчанию.

Замечание: При конвертировании из формата slapd.conf в формат slapd.d все подключаемые файлы должны быть также интегрированы в итоговую базу данных конфигурации.