Jump to content

OpenLDAP

OpenLDAP
Разработчик(и) Проект OpenLDAP
Первоначальный выпуск 26 августа 1998 г .; 25 лет назад ( 1998-08-26 ) [1]
Стабильная версия
2.6.8 [2] / 21 мая 2024 г .; 2 месяца назад ( 21 мая 2024 г. )
Репозиторий
Написано в С
Операционная система Любой
Платформа Кросс-платформенный
Тип LDAP Служба каталогов
Лицензия Публичная лицензия OpenLDAP [3]
Веб-сайт www .openldap .org  Edit this on Wikidata

OpenLDAP — это бесплатная открытым исходным кодом реализация с облегченного протокола доступа к каталогам (LDAP), разработанная проектом OpenLDAP. Он выпускается под собственной лицензией в стиле BSD, называемой OpenLDAP Public License. [4]

LDAP — это протокол, независимый от платформы. Несколько распространенных дистрибутивов Linux включают программное обеспечение OpenLDAP для поддержки LDAP. Программное обеспечение также работает на BSD -вариантах, а также на AIX , Android , HP-UX , macOS , OpenVMS , Solaris , Microsoft Windows (NT и производные, например 2000, XP, Vista, Windows 7 и т. д.) и z/. ОС .

Проект OpenLDAP [5] была основана в 1998 году Куртом Зейленгой. [6] Проект начался с клонирования эталонного источника LDAP из Мичиганского университета , где длительный проект поддерживал разработку и развитие протокола LDAP до окончательного выпуска этого проекта в 1996 году.

По состоянию на май 2015 г. В проекте OpenLDAP четыре основных члена команды: Говард Чу (главный архитектор), [7] Куана Гибсон-Маунт, Холлвард Фурусет и Курт Зейленга. Есть множество других важных и активных участников, включая Ондрея Кузника, Люка Ховарда, Райана Тэнди и Гэвина Генри. Среди прошлых членов основной команды — Пьеранджело Масарати. [8]

Компоненты

[ редактировать ]

OpenLDAP состоит из четырех основных компонентов:

Кроме того, проект OpenLDAP включает в себя ряд подпроектов:

  • JLDAP — библиотеки классов LDAP для Java. [9]
  • JDBC-LDAP — Java JDBC — драйвер моста LDAP [9]
  • ldapc++ — библиотеки классов LDAP для C++. [9]
  • LMDB - библиотека базы данных с отображением в памяти [9]

Серверные части

[ редактировать ]

Общая концепция

[ редактировать ]

Исторически архитектура сервера OpenLDAP (slapd, автономный демон LDAP) была разделена на интерфейсную часть, которая обеспечивает доступ к сети и обработку протоколов, и внутреннюю часть, которая занимается исключительно хранением данных. Такая разделенная конструкция была особенностью оригинального кода Мичиганского университета, написанного в 1996 году. [10] и продолжился во всех последующих выпусках OpenLDAP. Исходный код включал один основной сервер базы данных и два экспериментальных/демо-сервера. Архитектура является модульной, и теперь доступно множество различных серверных частей для взаимодействия с другими технологиями, а не только с традиционными базами данных.

Примечание. В более старых версиях (1.x) термины «серверная часть» и «база данных» часто использовались как синонимы. Если быть точным, «бэкенд» — это класс интерфейса хранилища, а «база данных» — это экземпляр бэкэнда. Сервер slapd может использовать произвольное количество бэкэндов одновременно и иметь произвольное количество активных экземпляров каждого бэкенда (т.е. произвольное количество баз данных). [11]

Доступные бэкэнды

[ редактировать ]

В настоящее время в дистрибутив OpenLDAP включено 17 различных бэкэндов, и известно, что различные третьи стороны поддерживают другие бэкэнды независимо. Стандартные серверные части условно разделены на три категории:

  • Серверные хранилища данных — они фактически хранят данные
    • back-bdb: первый транзакционный бэкэнд для OpenLDAP, построенный на базе Berkeley DB , удаленный с OpenLDAP 2.5. [12]
    • back-hdb: вариант back-bdb, который является полностью иерархическим и поддерживает переименование поддерева, удален в OpenLDAP 2.5. [13]
    • back-ldif: создан на основе текстовых LDIF . файлов [11]
    • back-mdb: транзакционный бэкэнд, построенный на основе базы данных OpenLDAP Lightning Memory-Mapped (LMDB). [11]
    • back-ndb: транзакционный бэкэнд, построенный на кластерном механизме MySQL NDB, удаленный в OpenLDAP 2.6. [14]
    • back-wiredtiger: экспериментальный транзакционный бэкэнд, построенный на WiredTiger , представленный в OpenLDAP 2.5. [11]
  • Прокси-серверы — они действуют как шлюзы к другим системам хранения данных.
    • back-asyncmeta: асинхронный прокси с функциями метакаталога, представленный в OpenLDAP 2.5. [11]
    • back-ldap: простой прокси для других серверов LDAP [11]
    • back-meta: прокси с функциями метакаталога [11]
    • back-passwd: использует пароль и групповые данные системы Unix. [11]
    • back-relay: внутреннее перенаправление на другие серверные части slapd [11]
    • back-sql: обращается к произвольным базам данных SQL, объявлено устаревшим в OpenLDAP 2.5. [11]
  • Динамические бэкэнды — они генерируют данные на лету.
    • back-config: настройка slapd через LDAP [11]
    • back-dnssrv: находит серверы LDAP через DNS. [11]
    • back-monitor: статистика slapd через LDAP [11]
    • back-null: бэкенд-приемник/без операций, аналог Unix /dev/null [11]
    • back-perl: вызывает произвольные модули perl в ответ на запросы LDAP, которые устарели в OpenLDAP 2.5. [11]
    • back-shell: вызывает сценарии оболочки для запросов LDAP, удаленные в OpenLDAP 2.5. [15]
    • back-sock: перенаправляет запросы LDAP через IPC произвольным демонам. [11]

Некоторые серверные части, доступные в старых выпусках OpenLDAP, больше не используются, в первую очередь back-ldbm, который был унаследован от исходного кода UMich, и back-tcl, который был похож на back-perl и back-shell. [16]

Поддержка других бэкэндов также скоро будет прекращена. back-ndb теперь удален, поскольку партнерство с MySQL, которое привело к его разработке, было прекращено Oracle после того, как Oracle приобрела MySQL. back-bdb и back-hdb были удалены в пользу back-mdb, поскольку back-mdb превосходит их по всем аспектам производительности, надежности и управляемости.

На практике такие бэкэнды, как -perl и -sock, позволяют взаимодействовать с любым произвольным языком программирования, обеспечивая тем самым безграничные возможности для настройки и расширения. По сути, сервер slapd становится механизмом RPC с компактным, четко определенным и повсеместным API.

Наложения

[ редактировать ]

Общая концепция

[ редактировать ]

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

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

Доступные наложения

[ редактировать ]

В настоящее время в основном дистрибутиве OpenLDAP имеется 25 оверлеев, еще 24 оверлея находятся в разделе кода, вносимого пользователями, и еще несколько ожидают одобрения для включения. [17]

Другие модули

[ редактировать ]

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

OpenLDAP также поддерживает SLAPI, архитектуру плагинов, используемую Sun и Netscape/Fedora/Red Hat. В текущих версиях платформа SLAPI реализована внутри оверлея slapd. Хотя многие плагины, написанные для Sun/Netscape/Fedora/Red Hat, совместимы с OpenLDAP, очень немногие члены сообщества OpenLDAP используют SLAPI. [19]

Доступные модули

[ редактировать ]
  • Собственные модули slapd
    • acl/posixgroup – поддержка членства в posixGroup в элементах управления доступом [18]
    • comp_match – поддержка сопоставления на основе компонентов [18]
    • kinit — поддерживать/обновлять TGT Kerberos для slapd [18]
    • passwd/ — дополнительные механизмы хеширования паролей. В настоящее время включает Kerberos , Netscape, RADIUS и SHA-2 . [18]
  • Плагины SLAPI
    • addrdnvalue – добавить значение RDN к записи, если оно было опущено в запросе на добавление. [20]

Краткое описание выпуска

[ редактировать ]

Основные (функциональные) выпуски программного обеспечения OpenLDAP включают:

  • OpenLDAP версии 1 представлял собой общую очистку последней версии проекта Мичиганского университета (выпуск 3.3) и объединение дополнительных изменений.
  • OpenLDAP версии 2.0, выпущенная в августе 2000 года, включала в себя основные улучшения, включая поддержку LDAP версии 3 (LDAPv3), поддержку Интернет-протокола версии 6 ( IPv6 ) и множество других улучшений.
  • Версия OpenLDAP 2.1, выпущенная в июне 2002 года, включала в себя серверную часть транзакционной базы данных (на основе базы данных Berkeley или BDB), поддержку простого уровня аутентификации и безопасности (SASL), а также экспериментальные мета-, мониторные и виртуальные серверные части.
  • OpenLDAP версии 2.2, выпущенная в декабре 2003 года, включала механизм синхронизации LDAP с поддержкой репликации (syncrepl), оверлейный интерфейс и многочисленные функциональные улучшения, связанные с базами данных и RFC.
  • Версия OpenLDAP 2.3, выпущенная в июне 2005 года, включала в себя серверную часть конфигурации (динамическую конфигурацию), дополнительные оверлеи, включая RFC-совместимое программное обеспечение политики паролей, а также множество дополнительных улучшений.
  • Версия OpenLDAP 2.4, выпущенная в октябре 2007 года, представила N-стороннюю репликацию MultiMaster, резервный мастер, возможность удалять и изменять элементы схемы на лету, а также многое другое. [21]
  • OpenLDAP версии 2.5, выпущенный в апреле 2021 года, представил прокси-сервер балансировки нагрузки LDAP, поддержку транзакций LDAP, поддержку протокола HA proxy v2 и многое другое. [22]
  • OpenLDAP версии 2.6, выпущенная в октябре 2021 года, представила дополнительные стратегии балансировки нагрузки и дополнительные параметры для улучшения согласованности с некоторыми элементами управления LDAP, а также расширила операции демона LDAP Load Balancer, а также возможность входа непосредственно в файл, а не через системный журнал как для slapd, так и для lloadd [23]

Репликация

[ редактировать ]

OpenLDAP поддерживает репликацию с использованием синхронизации контента, как указано в RFC 4533. [24] В дальнейшем эта спецификация называется «syncrepl». В дополнение к базовой спецификации также поддерживается расширение, известное как delta-syncrepl. Дополнительные улучшения были реализованы для поддержки репликации с несколькими хозяевами . [25]

синкрепл

[ редактировать ]

Базовая операция синхронизации описана в RFC 4533. [24] Протокол определен таким образом, что постоянная база данных изменений не требуется. Скорее, набор изменений подразумевается через информацию о порядковом номере изменений (CSN), хранящуюся в каждой записи и оптимизированную с помощью дополнительного журнала сеансов, который особенно полезен для отслеживания недавних удалений. Модель работы заключается в том, что клиент репликации (потребитель) отправляет «поиск синхронизации контента» на сервер репликации (поставщик). Потребитель может предоставить файл cookie при этом поиске (особенно, если он ранее был синхронизирован с поставщиком). В реализации OpenLDAP RFC 4533 этот файл cookie включает последний CSN, полученный от провайдера (называемый contextCSN).

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

Поиск может выполняться либо в режиме обновления, либо в режиме обновленияAndPersist, что определяет, какие этапы происходят. Этап обновления всегда происходит первым. На этапе обновления могут произойти две фазы: присутствие и удаление, где присутствие всегда происходит перед удалением. Фазы разделяются посредством ответа с информацией о синхронизации, который указывает, какая фаза завершена. Этапы обновления и сохранения также разграничиваются посредством такого ответа с информацией о синхронизации. Дополнительная оптимизация для более компактного представления группы записей, которые должны быть представлены или удалены, заключается в использовании ответа с информацией о синхронизации, содержащего syncIdSet, который идентифицирует список значений входных UUID этих записей.

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

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

дельта-синкрепл

[ редактировать ]

Этот протокол хранит постоянную базу данных доступов для записи (изменений) и может точно представлять каждое изменение (имеется в виду только те атрибуты, которые изменились). Он по-прежнему основан на стандартной спецификации Syncrepl, которая всегда отправляет изменения как полные записи. Но в delta-syncrepl передаваемые записи фактически отправляются из базы данных журнала, где каждое изменение в основной базе данных записывается как запись журнала. Записи журнала записываются с использованием схемы журнала LDAP. [26]

См. также

[ редактировать ]
  1. ^ «Анонсируем OpenLDAP 1.0, дистрибутив LDAP с открытым исходным кодом» . 26 августа 1998 года . Проверено 22 марта 2018 г.
  2. ^ «OpenLDAP 2.6.8 теперь доступен» . 21 мая 2024 г. Проверено 22 мая 2024 г.
  3. ^ «Общественная лицензия OpenLDAP, версия 2.8» . openldap.org . 1 августа 2003 года . Проверено 15 августа 2015 г.
  4. ^ «OpenLDAP, общественная лицензия для 2.4.39» . Openldap.org . Проверено 17 февраля 2014 г.
  5. ^ «OpenLDAP, Проект» . Openldap.org . Проверено 17 февраля 2014 г.
  6. ^ «OpenLDAP, Курт Д. Зейленга» . Openldap.org . Проверено 17 февраля 2014 г.
  7. ^ Говард Чу. «Разная страница Говарда» . Highlandsun.com . Проверено 17 февраля 2014 г.
  8. ^ «Домашняя страница Андо» . Aero.polimi.it . Проверено 17 февраля 2014 г.
  9. ^ Jump up to: а б с д и ж г час «Главная страница OpenLDAP» . Проверено 25 октября 2021 г.
  10. ^ «Архивная копия» . Архивировано из оригинала 17 февраля 2005 года . Проверено 19 августа 2013 г. {{cite web}}: CS1 maint: архивная копия в заголовке ( ссылка )
  11. ^ Jump up to: а б с д и ж г час я дж к л м н тот п «Справочная страница OpenLDAP по серверным модулям slapd» . Проверено 25 октября 2021 г.
  12. ^ «Справочная страница OpenLDAP 2.4 slapd-bdb» . Проверено 25 октября 2021 г.
  13. ^ «Справочная страница OpenLDAP 2.4 slapd-hdb» . Проверено 25 октября 2021 г.
  14. ^ «Справочная страница OpenLDAP 2.5 slapd-ndb» . Проверено 25 октября 2021 г.
  15. ^ «Справочная страница OpenLDAP 2.4 slapd-shell» . Проверено 25 октября 2021 г.
  16. ^ «Справочная страница OpenLDAP 2.3 slapd-ldbm» . Проверено 25 октября 2021 г.
  17. ^ Jump up to: а б с д и ж г час я дж к л м н тот п д р с т в v В х и С «Справочная страница по наложениям OpenLDAP» . Проверено 25 октября 2021 г.
  18. ^ Jump up to: а б с д и ж г час я дж к л м н тот п д р с т в v В х и С аа аб «Исходный код дополнительных модулей OpenLDAP» . Проверено 25 октября 2021 г.
  19. ^ «Справочная страница плагинов OpenLDAP SLAPI» . Проверено 25 октября 2021 г.
  20. ^ «Подключаемые модули SLAPI для OpenLDAP» . Проверено 25 октября 2021 г.
  21. ^ «Анонс OpenLDAP 2.4» . Openldap.org. 3 октября 2007 г. Проверено 17 февраля 2014 г.
  22. ^ «Анонс OpenLDAP 2.5» . Openldap.org. 29 апреля 2021 г.
  23. ^ «Анонс OpenLDAP 2.6» . Openldap.org. 25 октября 2021 г.
  24. ^ Jump up to: а б Чхве, Чон Хёк; Зейленга, Курт (июнь 2006 г.). «RFC4533» . Проверено 25 октября 2021 г.
  25. ^ «Документация по репликации OpenLDAP» . Проверено 25 октября 2021 г.
  26. ^ Чу, Ховард (5 мая 2006 г.). «draft-chu-ldap-logschema-00 — Схема регистрации протокола LDAP» . Tools.ietf.org . Проверено 17 февраля 2014 г.
[ редактировать ]


Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 374c4e3742dda2a0ff8e820b186f9922__1706623260
URL1:https://arc.ask3.ru/arc/aa/37/22/374c4e3742dda2a0ff8e820b186f9922.html
Заголовок, (Title) документа по адресу, URL1:
OpenLDAP - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)