LDAP - занимаюсь самообразованием

Сколько пользователей? 8*10^10? Это что, реестр всех живших на Земле людей?

Прежде всего. LDAP - это протокол. Протокол обмена данными с каталогом. Каталог - это просто иерархическая база данных. Вот и всё.

Какой смысл вводить? Так вот такой и смысл, чтобы всё лежало в одном месте и не дублировалось.

лдап это просто БД, просто с древовидной структурой и распределением.

а удобство его начинается, когда пытаешься сделать 2 проги с единой базой юзверей.

А про трудность создания базы - имеется в виду чисто технологическая трудность. Надо как-то занести в базу миллиарды (если я правильно понял), даже десятки миллиардов записей. Не вручную же их вбивать до второго пришествия лонгхорна?

>>>это просто БД, просто с древовидной структурой

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

>>>удобство его начинается, когда пытаешься сделать 2 проги с единой базой юзверей.

Ну, LDAP тут как раз не единственный вариант. Если нужен только uid, gid, SHELL и HOME пользователя, то NSSwitch и Гесиода более чем достаточно.

>>Надо как-то занести в базу миллиарды (если я правильно понял), даже десятки миллиардов записей.

Это я как раз понимаю. Вопрос был, почему автору понравилось именно это число? Или он просто хотел поразить воображение читателя?

> "Если система уже настроена и содержит порядка 8*10^10 пользователей то вам трудно будет создать базу LDAP вручную". Задумался. Откуда взялось это число?

Смотрим оригинал стр.4 (real стр.77): "Но ведь если у вас система уже настроена и содержит порядка 8*10^10 пользователей, то будет немного трудновато всё это заново переписывать. Поэтому во многих дистрибутивах есть пакет openldap-migration,..."

Задумался. Откуда взялась цитируемая строка?

:-)

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

Ну вот Tivoli Directory Server держит данные в DB2. Как - не знаю и знать не хочу, но держит.

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

LDAP в основном могут оценить только сисадмины.
К примеру я добавляю только пользователя через web интерфейс в базу ldap, что я автоматически получаю:
1. он получает учетную запись в домене (samba или nfs, использую интергрировано обе), при необходимости квоты
2. почтовый ящик cyrus-imap, доступ на отправку наружу sendmail при необходимости, иначе только на локальный домен, acl храню в ldap
3. доступ в инет через squid, списки acl храню в ldap
4. учетную запись в копроративном jabber
5. несколько виртуальных почтовых доменов на xen, где все учетки также в  ldap
6. еще что то может забыл

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

>>>иначе мне пришлось бы делать кучу повторяющихся действий

Почему же? Насколько я знаю, если какой-то сервис может держать свои авторизационные данные в LDAP, то его можно сконфигурировать (возможно перекомпилировав) так, чтобы эти данные он получал из SQL базы данных. Мне кажется очевидным, что "иерархичность" данных LDAP сделана только потому, что это directory access protocol. На самом деле эта фича мало кому нужна, она только усложняет управление данными в LDAP, и реляционная модель здесь более уместна. Т.е. имеем индексированную таблицу с пользователями, и отдельные индексированные таблицы для каждого из сервисов. Получение информации о пользователе сервисом - JOIN таблицы пользователей с собственной таблицей сервиса.

Может быть, правда, кто-то без этой иерархичности жить не может, но я не могу представить, где она действительно необходима. За исключением, разумеется, ситуации, когда есть дерево каталогов и вы выставляете acl на каждый из подкаталогов. LDAP ведь для того и был придуман. А использовать его для хранения паролей - бред полный (это я статью вспоминаю).