Slapd linux ��� ���

slapd — автономный демон LDAP. Он ожидает подсоединений LDAP на портах с любым номером (по умолчанию 389 ), выдавая ответ на операции LDAP, получаемые им по этим соединениям. Обычно slapd вызывается во время загрузки, как правило из /etc/rc.local . После запуска slapd обычно производит ответвление и отсоединяется от терминала, из которого был запущен. Если это настроено в конфигурационном файле (или конфигурационной директории), процесс slapd выведет свой идентификатор (смотрите getpid (2)) в файл .pid , а также указываемые при вызове параметры командной строки в файл .args (смотрите slapd.conf (5)). Если при вызове был указан флаг -d , даже со значением 0 (ноль), slapd не будет производить ответвления и отсоединяться от терминала, из которого запущен.

Дополнительные детали по slapd смотрите в «Руководстве администратора OpenLDAP».

ПАРАМЕТРЫ

Помните, что при включении уровня журналирования packets будут выводиться пакеты, содержащие пароли подсоединения, так что если журнал перенаправляется в файл, то этот файл должен быть защищён от прочтения. -s syslog-level Данный параметр сообщает slapd , какого уровня отладочные сообщения следует журналировать средствами syslog (8). В качестве syslog-level может быть установлено любое значение или комбинация значений, допустимая в параметре -d . slapd отправляет на регистрацию все сообщения выбранного уровня syslog-level с уровнем важности syslog (3) DEBUG в канал, определённый параметром -l . -n service-name Определяет имя службы для журналирования и других целей. По умолчанию соответствует базовому имени в argv[0], то есть «slapd». -l syslog-local-user Определяет пользовательский канал для syslog (8). Значение может быть от LOCAL0 , до LOCAL7 , а также USER и DAEMON . По умолчанию — LOCAL4 . Однако, этот параметр разрешено применять только в системах, поддерживающих пользовательские каналы в syslog (8). Журналирование в syslog(8) происходит с уровнем важности «DEBUG». -f slapd-config-file Определяет конфигурационный файл slapd. По умолчанию /usr/local/etc/openldap/slapd.conf . -F slapd-config-directory Определяет конфигурационную директорию slapd. По умолчанию /usr/local/etc/openldap/slapd.d . Если указаны сразу и -f и -F , конфигурационный файл будет прочтён, переконвертирован в формат конфигурационной директории и записан в указанную директорию. Если не указан ни один из этих параметров, slapd попытается прочитать конфигурационную директорию по умолчанию, а затем использовать конфигурационный файл по умолчанию. Если существует конфигурационная директория в правильном формате, то конфигурационный файл игнорируется. Такое поведение соблюдается всеми slap-утилитами, использующими эти параметры командной строки. -h URLlist slapd по умолчанию будет обслуживать ldap:/// (LDAP по TCP на всех интерфейсах на порту LDAP по умолчанию). То есть, будет обслуживать подсоединения на INADDR_ANY и порту 389 . Параметр -h может использоваться, чтобы указать список LDAP URL (и URL с другими схемами), который требуется обслуживать. Например, если slapd передано -h dqldap://127.0.0.1:9009/ ldaps:/// ldapi:///dq , он будет ожидать соединения LDAP на 127.0.0.1:9009, LDAP поверх TLS на 0.0.0.0:636, а также LDAP поверх IPC (доменные сокеты Unix). Адрес хоста 0.0.0.0 представляет собой INADDR_ANY (любой интерфейс). В качестве значения параметра ожидается разделённый пробельными символами список URL. Схемы URL должны быть LDAP, LDAPS или LDAPI, поддержка последних двух схем зависит от параметров конфигурации. В общем случае URL не должны содержать DN или других дополнительных параметров (за исключением обсуждаемых ниже). Хосты могут быть указаны по имени или адресами в форматах IPv4 и IPv6. Если указывается порт, он должен быть приведён в виде числового номера. Порт по умолчанию для ldap:// — 389 , для ldaps:// — 636 .

Для LDAP поверх IPC в качестве имени хоста в URL указывается имя сокета, а указания порта не требуется, более того, не разрешается; обратите внимание, что символ разделителя директорий в имени сокета должен быть закодирован в формате URL, как и все остальные символы, являющиеся специальными для URL; таким образом, сокет

должен быть указан как

Расположение IPC-сокета по умолчанию — /usr/local/var/run/ldapi.

Разрешения на соединения обозначаются конструкциями «x-mod=-rwxrwxrwx», «x-mod=0777» или «x-mod=777», где любой символ в сочетании «rwx» может быть заменён на «-» для запрета соответствующего разрешения, а символы на месте «7» могут быть любой допустимой восьмеричной цифрой в соответствии с chmod(1). Открываемые соединения могут воспользоваться расширением «x-mod» для реализации грубых ограничений на операции, например, разрешить операции чтения («r», применяющееся для операций search и compare), операции записи («w», применяющееся для операций add, delete, modify и modrdn), и операции исполнения («x», означающее, что требуется операция bind). Разрешения, определяемые для «пользователя», применяются к пользователям, прошедшим аутентификацию, а определяемые для «остальных» — к анонимным пользователям; разрешения для «группы» игнорируются. Например, «ldap:///. x-mod=-rw——-» означает, что операции чтения и записи разрешены только соединениям, в которых пользователи прошли аутентификацию, и для всех операций требуется подсоединение. Данное свойство является экспериментальным и его необходимо явно указывать во время конфигурации. -r directory Определяет директорию, которая станет корневой. slapd изменит текущую рабочую директорию на указанную директорию, а затем выполнит в неё chroot (2). Это осуществляется после открытия портов на прослушивание, но до чтения каких-либо конфигурационных файлов и инициализации каких-либо механизмов манипуляции данными. Если этот параметр применяется в качестве механизма безопасности, его следует использовать совместно с параметрами -u и -g . -u user slapd будет запущен с правами пользователя, указанного именем или идентификатором, и к нему будет применён список доступа дополнительных групп этого пользователя согласно initgroups(3). Идентификатор группы также будет изменён на gid этого пользователя, если это не переопределено параметром -g . Обратите внимание, что при использовании с -r slapd будет искать базу данных пользователей в окружении изменённой корневой директории.

Имейте ввиду, что на некоторых системах при запуске с правами непривилегированного пользователя для механизмов манипуляции данными passwd будет предотвращён доступ к зашифрованным паролям. Также имейте ввиду, что любые механизмы манипуляции данными shell будут запускаться с правами указанного непривилегированного пользователя. -g group slapd будет запущен с правами группы, указанной именем или идентификатором. Обратите внимание, что при использовании с -r slapd будет искать базу данных групп пользователей в окружении изменённой корневой директории. -c cookie Данный параметр предоставляет куки для потребителя репликации syncrepl. Куки представляет собой разделённый запятыми список пар имя=значение . Поддерживаемые в настоящий момент поля syncrepl-куки — rid , sid , и csn . rid идентифицирует процесс репликации на сервере-потребителе и используется для нахождения в slapd.conf (5) или slapd-config (5) спецификации syncrepl, имеющей в своём определении соответствующий идентификатор репликации. Если в этом параметре используются какие-либо другие значения, rid также должен быть указан. sid — это идентификатор сервера в конфигурации репликации с несколькими главными серверами (multi-master) или репликации в режиме зеркала (mirror-mode). csn — это порядковый номер изменения, полученный во время предыдущей синхронизации и представляющий собой состояние содержимого потребительской реплики, которое механизм syncrepl будет синхронизировать с текущим содержимым каталога поставщика. В случае конфигурации репликации с несколькими главными серверами или репликации в режиме зеркала могут присутствовать несколько разделённых запятыми значений csn . Для принудительной полной перезагрузки используйте только часть rid данного параметра. -o option [ = value ] Данный параметр предоставляет универсальную возможность указывать опции без необходимости выделения для них отдельной буквы.

Поддерживаются следующие опции: slp= < on | off | slp-attrs >Когда в slapd вкомпилирована поддержка SLP, эта опция отвечает за её отключение ( off ), её включение путём регистрации на SLP DA без специфических атрибутов SLP ( on ), или со специфическими атрибутами SLP slp-attrs , которые должны представлять из себя определение списка атрибутов SLP в соответствии со стандартом SLP.

Например, с параметром «slp=(tree=production),(server-type=OpenLDAP),(server-version=2.4.15)» slapd регистрируется на SLP DA с тремя атрибутами SLP: tree, server-type и server-version с приведёнными выше значениями. Это позволяет сделать конкретный запрос к SLP DA на предмет серверов LDAP, содержащих дерево production в случае, если доступно несколько деревьев.

ПРИМЕРЫ

Чтобы запустить slapd с альтернативным конфигурационным файлом и включить вывод большого объёма отладочной информации в стандартный поток ошибок, выполните:

Чтобы протестировать корректность конфигурационного файла, выполните:

Источник

6. Конфигурационный файл slapd

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

Файл slapd.conf (5) по умолчанию устанавливается в директорию /usr/local/etc/openldap . Альтернативное расположение конфигурационного файла можно указать с помощью параметра командной строки при запуске slapd (8).

Файл slapd.conf (5) состоит из трёх типов настроечной информации: глобальной, специфичной для механизмов манипуляции данными и специфичной для баз данных. Глобальные настройки указываются первыми, затем следуют настройки для конкретного типа механизма манипуляции данными, за которыми, в свою очередь, следуют настройки конкретного экземпляра базы данных. Глобальные директивы могут переопределяться директивами механизма манипуляции данными и/или базы данных, а директивы механизма манипуляции данными могут переопределяться директивами базы данных.

Пустые строки и строки комментариев, начинающиеся с символа ‘ # ‘ игнорируются. Если строка начинается с пробельного символа, она считается продолжением предыдущей строки (даже если предыдущая строка является комментарием).

Общий формат файла slapd.conf:

У директивы конфигурации могут быть аргументы, которые отделяются друг от друга пробельными символами. Если пробельный символ содержится внутри аргумента, аргумент заключается в двойные кавычки «вот так» . Если аргумент содержит двойные кавычки или символ обратного слеша ` \ ‘, данные символы должны экранироваться символом обратного слеша ` \ ‘.

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

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

Описанные в данном подразделе директивы применяются ко всем механизмам манипуляции данными и базам данных, если они специально не переопределяются настройками конкретного механизма манипуляции или базы данных. Аргументы, которые требуется заменить актуальными значениями, показаны в угловых скобках <> .

6.2.1.1. access to [ by [] [ ] ]+

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

6.2.1.2. attributetype

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

6.2.1.3. idletimeout

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

6.2.1.4. include

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

Замечание: При использовании данной директивы соблюдайте осторожность: не существует разумных ограничений на количество вложенных директив include, и зацикливание не распознаётся.

6.2.1.5. loglevel

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

Таблица 6.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)	только сообщения, выводимые независимо от заданного уровня журналирования (то есть высокоприоритетные)

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

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

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

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

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

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

6.2.1.6. objectclass

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

6.2.1.7. referral

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

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

6.2.1.8. sizelimit

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

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

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

6.2.1.9. timelimit

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

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

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

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

6.2.2.1. backend

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

Таблица 6.2: Механизмы манипуляции данными

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

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

Директивы этого подраздела применяются только к тем базам данных, для которых они определены. Они поддерживаются всеми типами баз данных.

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

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

6.2.3.2. limits [ [. ]]

Определяет ограничения по времени и размеру в зависимости от инициатора операции или базового DN.

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

6.2.3.3. readonly

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

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

6.2.3.4. rootdn

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

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

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

6.2.3.5. rootpw

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

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

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

6.2.3.6. suffix

Эта директива определяет DN суффикса запросов, которые будут направляться в эту базу данных. Возможно определение нескольких суффиксов. Как минимум один суффикс должен быть определён для каждой базы данных.

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

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

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

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

Параметр 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 , exattrs , attrsonly , sizelimit и timelimit , как и в случае обычного поискового запроса. У параметра searchbase нет значения по умолчанию и он должен быть задан обязательно. Значения по умолчанию остальных параметров: scope — sub , filter — (objectclass=*) , attrs — «*,+» (то есть репликация и пользовательских, и операционных атрибутов), attrsonly по умолчанию не задан. Параметры sizelimit и timelimit по умолчанию установлены в «unlimited», и могут задаваться либо положительным целым числом, либо «unlimited». Также можно использовать необязательный параметр exattrs для указания атрибутов, которые должны быть исключены из входящих записей.

У протокола 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.

Параметр network-timeout задаёт промежуток времени, в течение которого потребитель репликации будет ожидать установления сетевого соединения с поставщиком. После того, как соединение установлено, параметр timeout определяет, как долго потребитель будет ожидать завершения выполнения первоначального запроса Bind. Значения по умолчанию для этих параметров берутся из настроек в файле ldap.conf (5).

Параметр 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.

Параметр keepalive задаёт значения времени простоя, количества проб и интервалов между выполнением проб, используемых для проверки работоспособности сокета; время простоя — это количество секунд, в течение которого соединение должно бездействовать перед тем, как TCP начнет выполнять проверку работоспособности; количество проб представляет собой максимальное число проверок работоспособности, которое следует выполнить TCP перед тем, как разорвать соединение; интервал представляет собой количество секунд между посылками проб работоспособности. Эти значения разрешено задавать лишь в некоторых системах; в остальных системах параметр keepalive будет проигнорирован, и будут использованы общесистемные установки. Например, при указании keepalive=»240:10:30″ будет выполнено 10 проб работоспособности с интервалом 30 секунд после того, как сокет будет неактивен в течение 240 секунд. Если ответа на эти пробы не будет получено, соединение будет разорвано.

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

Параметр suffixmassage позволяет потребителю получать записи из удалённого каталога, контекст именования которого отличается от контекста именования локального каталога. Составная часть DN записей из удалённого каталога, совпадающая с DN в параметре searchbase, будет заменена значением DN из параметра suffixmassage.

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

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

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

6.2.3.8. updateref

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

Директивы этой категории применимы только к базам данных BDB и HDB . Поэтому они должны следовать за строками «database bdb» или «database hdb» и до любых последующих строк «backend» или «database». Полное руководство по конфигурационным директивам BDB/HDB смотрите в slapd-bdb (5).

6.2.4.1. directory

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

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

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

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

В строке 4 определён глобальный уровень контроля доступа. Он применяется ко всем записям (после применения к ним правил контроля доступа, специфичных для базы данных).

В следующей секции конфигурационного файла определена база данных механизма манипуляции данными BDB, которая будет обрабатывать запросы к части дерева «dc=example,dc=com». База данных будет реплицироваться на два подчинённых slapd, один из которых на хосте truelies, а другой — на judgmentday. К некоторым атрибутам будет применяться индексирование, а атрибут userPassword защищается от несанкционированного доступа.

Строка 5 — комментарий. Начало определения базы данных обозначено ключевым словом database в строке 6. В строке 7 определён DN суффикса запросов, обслуживаемых этой базой данных. В строке 8 указана директория, в которой будут размещаться файлы базы данных.

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

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

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

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

Источник