A. Изменения по сравнению с предыдущей версией

В следующих подразделах предпринята попытка обобщить новые возможности и изменения в программном обеспечении OpenLDAP по сравнению с версией 2.3.x и в Руководстве администратора OpenLDAP.

A.1. Новые разделы руководства

Чтобы Руководство администратора стало более глубоким и охватывало большинство вопросов, задаваемых в списках рассылки OpenLDAP и обсуждаемых там способов их решения, мы добавили следующие разделы:

Кроме того, для облегчения навигации в содержании теперь представлены разделы 3-го уровня вложенности.

A.2. Новые функции и возможности в версии 2.4

A.2.1. Лучшая функциональность cn=config

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

   olcDatabase={1}bdb,cn=config
   olcSuffix: dc=example,dc=com

и Вы хотите добавить новую подчинённую базу данных, теперь Вы можете добавить такую запись с помощью ldapadd:

   olcDatabase={1}bdb,cn=config
   olcSuffix: dc=foo,dc=example,dc=com

Новая база данных BDB будет добавлена в слот 1, а все последующие базы данных будут смещены на единицу; таким образом, оригинальная база данных BDB теперь будет называться:

   olcDatabase={2}bdb,cn=config
   olcSuffix: dc=example,dc=com

A.2.2. Лучшая функциональность cn=schema

В версии 2.3 Вы могли лишь добавлять новые элементы схемы, а удалять или изменять существующие элементы - нет. В 2.4 Вы можете изменять схему по своему желанию (конечно, за исключением жёстко закодированной системной схемы).

A.2.3. Более тонкая настройка Syncrepl

Оригинальная реализация Syncrepl в OpenLDAP 2.2 была предназначена для поддержки нескольких потребителей для одной базы данных, но эта возможность никогда не работала и была исключена в OpenLDAP 2.3; в этой версии Вы могли настроить только одного потребителя для каждой базы данных.

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

A.2.4. Разнонаправленная репликация с несколькими главными серверами

В результате работы по поддержке контекста нескольких потребителей система syncrepl теперь поддерживает разнонаправленную репликацию с несколькими главными серверами с разрешением конфликтов на уровне записи. Конечно, есть ряд важных ограничений: для того чтобы поддерживать целостность данных между всеми серверами, Вы должны обеспечить полную синхронизацию времени на всех серверах-участниках (например, использовать NTP на всех серверах).

Используемые для репликации entryCSN теперь сохраняют метки времени с разрешением в микросекунды, а не просто в секундах. Код delta-syncrepl ещё не был обновлён для использования в варианте с несколькими главными серверами, планируется осуществить это позже в ходе дальнейшей разработки версии 2.4.

A.2.5. Репликация конфигурации slapd (syncrepl и cn=config)

Syncrepl над cn=config был явно отключен в 2.3. В 2.4 он полностью поддерживается; Вы можете использовать syncrepl для репликации всей конфигурации сервера с одного сервера на сколь угодно большое количество других серверов. Можно клонировать всю конфигурацию работающего slapd, используя небольшое количество настроек (менее 10 строк), можно реплицировать только поддерево схемы данных, можно придумать и другие варианты. В тестах 049 и 050 из набора тестов есть рабочие примеры этих возможностей.

A.2.6. Репликация в режиме посылок

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

В версии 2.4 Вы можете определить базу данных как "hidden", это означает, что при проверке конфликта имён её суффикс будет проигнорирован, и что база данных не будет использоваться для ответов на поступающие извне запросы. Использование данной возможности скрытых ("hidden") баз данных позволяет настроить несколько баз данных с одним и тем же суффиксом, что в свою очередь позволяет настроить несколько экземпляров back-ldap для отправки репликации одной базы данных на несколько целевых серверов. Есть и другие способы применения скрытых баз данных (например, использование потребителя syncrepl для поддержки *локального* зеркала базы данных на отдельной файловой системе).

A.2.7. Более гибкое управление конфигурацией TLS

В версии 2.3 настройки TLS в slapd использовались только для входящих подключений к демону slapd. Для исходящих подключений, используемых, например, back-ldap или syncrepl, параметры TLS этих подключений брались из системного файла ldap.conf.

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

A.2.8. Улучшения производительности

Слишком много, чтобы всё перечислить. Некоторые заметные изменения - ldapadd когда-то был на два порядка медленнее, чем "slapadd -q". Теперь он в худшем случае в два раза медленнее slapadd -q. Некоторые сравнения всех релизов OpenLDAP 2.x доступны по адресу http://www.openldap.org/pub/hyc/scale2007.pdf.

В этом исследовании сравниваются версии 2.0.27, 2.1.30, 2.2.30, 2.3.33 и последующие. По диаграмме "Производительность кэшированных запросов" трудно увидеть разницу, поскольку время отклика очень мало, но новый код примерно на 25% быстрее чем 2.3, который примерно на 20% быстрее чем 2.2, который примерно на 100% быстрее чем 2.1, который примерно на 100% быстрее чем 2.0 в данном конкретном сценарии поиска. В этом тесте производился поиск по базе данных размером 1.3GB, содержащей 380836 записей (все в кэше записей slapd) менее чем за 1 секунду, таким образом, на CPU 2.4GHz с RAM DDR400 ECC/Registered мы можем производить поиск со скоростью более чем 500 тысяч записей в секунду. Поиск осуществлялся по неиндексированным атрибутам с использованием фильтра, не соответствующего ни одной записи, чтобы заставить slapd исследовать каждую запись в базе данных на соответствие фильтру.

По существу, кэш записей slapd в back-bdb/back-hdb настолько эффективен, что время на осуществление самого поиска практически незаметно; время отклика ограничивается только пропускной способностью памяти машины (скорость поиска данных соответствует примерно 3.5GB/сек; пропускная способность памяти машины составляет примерно 4GB/сек, что связано с задержками ECC и регистров).

A.2.9. Новые наложения

slapo-constraint (Ограничения на значения атрибутов)
slapo-dds (Динамические службы каталогов, RFC 2589)
slapo-memberof (Обратное обслуживание членства в группах)

A.2.10. Новые возможности в существующих наложениях

slapo-pcache
- Инспектирование/Обслуживание
  - Доступ к базе данных кэша может быть получен напрямую через LDAP путём добавления специального элемента управления к каждому запросу LDAP; специальная расширенная операция позволяет последовательно удалять кэшированные записи и кэшированные запросы целиком
- Горячая перезагрузка
  - Закэшированные запросы сохраняются на диск при остановке сервера, и вновь загружаются при следующем запуске, если срок их действия ещё не истёк
slapo-rwm может безопасно взаимодействовать с другими наложениями
Наложения Dyngroup/Dynlist объединенены, а также улучшена безопасность
- добавлена поддержка dgIdentity (draft-haripriya-dynamicgroup)

A.2.11. Новые возможности в slapd

мониторинг back-bdb и back-hdb: заполнение кэша, поиск по неиндексированным атрибутам;
управление отслеживанием сессий (draft-wahl-ldap-session);
удаление поддерева в back-sql (draft-armijo-ldap-treedelete);
отсортированные значения в в атрибутах с несколькими значениями для более быстрого поиска соответствий;
облегчённый диспетчер для повышения пропускной способности при высокой нагрузке и на многопроцессорных машинах (на 33% быстрее чем 2.3 на AMD quad-socket двухядерном сервере).

A.2.12. Новые возможности в libldap

API клиента ldap_sync (LDAP Content Sync Operation, RFC 4533)

A.2.13. Новые клиенты, инструменты и усовершенствования существующих инструментов

ldapexop для любых расширенных операций;
Полная поддержка элементов управления в запросах/ответах для всех клиентов;
Клиентские инструменты LDAP теперь соблюдают SRV-записи.

A.2.14. Новые опции сборки

Поддерживается сборка с GnuTLS

A.3. Устаревшие возможности, удалённые из версии 2.4

Следующие возможности серьёзно устарели в 2.3 и были удалены в версии 2.4.

A.3.1. Slurpd

Чтобы ознакомиться с тем, почему этот демон больше не присутствует в OpenLDAP, прочитайте раздел Репликация.

A.3.2. back-ldbm

back-ldbm был и медленным, и ненадёжным одновременно. Его устаревший код индексирования был склонен к спонтанному разрушению, это было связано с основополагающими библиотеками баз данных (GDBM или NDBM), которые обычно использовались с данным механизмом манипуляции данными. back-bdb и back-hdb превосходят данный механизм во всех аспектах: упрощённое индексирование, позволяющее избежать разрушения индексов, высокоточная блокировка для улучшения параллельной работы, иерархическое кэширование для повышения производительности, модернизированный формат хранения данных на диске для повышения эффективности и переносимости, и полная поддержка транзакций для повышения надёжности.