![The Internet Engineering Task Force (IETF)](https://habrastorage.org/getpro/habr/post_images/966/fe1/2a8/966fe12a8c06ae93f213db730be54820.gif)
В этой статье я расскажу вам о сервере службы каталогов
389 Directory Server (он же Fedora Directory Server, он же Redhat Directory Server). Так уж повелось, что для доступа к серверу каталогов используется протокол
LDAP. Если вы не работали с LDAP, я очень рекомендую ознакомиться со статьями в Wikipedia (
тут про cлужбу каталогов, а
тут про протокол LDAP).
Итак, сначала кратко о том, зачем же вообще использовать сервер службы каталогов (далее — LDAP-сервер). LDAP-сервера, в основном, применяются для централизованного хранения учетных записей, и всего, что с ними связано. LDAP-сервер представляет собой иерархическую БД, а значит в нем можно хранить любые данные.
Казалось бы, вполне логичен вопрос: а почему именно LDAP? Что мешает хранить учетные записи в MySQL или PostgreSQL? Ответ очевиден — ничего =)
Но над любой RDBMS служба каталогов обладает целым рядом преимуществ:
- Это стандарт. Многие приложения поддерживают аутентификацию/авторизацию через LDAP;
- Данные хранятся как иерархическое дерево, что позволяет делать эффективные операции поиска, выделив нужную часть дерева;
- Число операций чтения в тысячи раз превышают число операций записи, в связи с этим появляется огромное число плюсов: нет необходимости применения транзакций и rollback'ов, репликация работает без проблем, которые присущи RDBMS;
- Приложение должно видеть одну и ту же информацию на всех серверах службы каталогов, если сервер не хранит информацию, нужную клиентскому приложению, он может сам запросить ее у другого сервера или перенаправить само приложение к другому серверу;
- Из-за описанных выше свойств службы каталогов, этот сервис отлично масштабируется горизонтально.
Выбор сервера службы каталогов пал на 389 Directory Server. История этого LDAP сервера тесно связана с компанией Netscape (если интересно, почитать историю можно
тут).