Linux - статьи

         

Общедоступная теория


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

Вообще-то, в мире UNIX всегда существовали методы и утилиты поиска, типа finger или whois, но они хорошо работали, в основном, в масштабах одного сервера — и для новых реалий не подходили.

Задача заключалась в создании централизованных адресных книг для целых корпораций с развитой сетью отделений, а также с международными филиалами, подключаемыми по интернету. Ко всему, было принято решение сделать этот каталог платформонезависимым. Поэтому IBM, Lotus, Microsoft и Netscape договорились о применении единого метода доступа — LDAP — для доступа к адресной информации. К этому соглашению приложили усилия и многие другие гранды сетевого компьютинга, к примеру Sun и Novell.

LDAP расшифровывается как Lightweight Directory Access Protocol — то есть "легковесный протокол доступа к каталогам". Эта самая "легковесность" LDAP наводит на мысль, что где-то должен существовать и его "тяжеловесный" собрат. И действительно: в качестве прототипа выступал полновесный протокол доступа к каталогам DAP, известный также как X.500 или "Проект "Белые Страницы”" (White Pages Project).

Этот протокол был разработан консорциумом OSI и ориентирован на локальные корпоративные сети и большие мэйнфреймы. Адаптацию этого сложного и редко используемого всуе протокола к нуждам современного интернета и персональным компьютерам выполнили хакеры Мичиганского университета, которые вообще известны креативными поделками. В последнее время LDAP используется для доступа и к не-X.500-совместимым серверам каталогов, а к информиции, отличной от адресных книг.

На сегодня существует три версии LDAP. Причем первая не в счет — в ней сразу же были найдены серьезные проблемы. Вторая, и самая распространенная, версия LDAP2 зафиксирована в документах RFC 1777, 1778 и 1779. Наиболее современной на момент написания этой статьи была версия LDAPv3, окончательно «устаканенная» в 1997 г. В этой версии, с одной стороны, лучше поддерживается X.500, а с другой — больше внимания уделено не-X.500-серверам.

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

Возможность построения сетей каталогов — это основа для постепенного развертывания служб LDAP: можно начать с одного минимально настроенного сервера и постепенно расширять его функциональность.

Собственно LDAP реализуется в виде клиента и сервера. Сервер LDAP хранит и индексирует записи определенного формата. В качестве полей выступают имя пользователя, его физический и электронный адреса, телефоны и т.д. Администрирование сервера производится по правилам среды: для Linux это файлы настройки и командная строка, для Windows и Mac OS — графические приложения. В последнее время для администрирования, в том числе удаленного, все чаще применяется веб-интерфейс. Серверы, согласно X.500, могут объединяться в сеть, так что пользователь в поисках нужной информации может переходить от одного сервера к другому.

Кроме того, для повышения производительности существуют и LDAP-прокси серверы, эффективно кэширующие частые запросы.

Клиентом чаще всего выступает почтовый клиент. Он содержит форму запроса к удаленному серверу, наподобие той, что используется для поиска в ICQ. Обычно клиентское ПО реализует не все возможности (которых очень много), а какое-то их подмножество. В той или иной мере LDAP поддерживают все современные почтовые клиенты, такие как Outlook Express, Eudora, Netscape, OS X Mail и т.д. Часто доступ к LDAP-серверу, особенно глобальному, можно получить через веб-интерфейс.

Быстро получить окно поиска на заданном сервере обычно можно, введя в окне браузера URL вида ldap://server[:port]. К примеру, в нашей локальной сети это будет ldap://192.168.0.99. Через косую черту вы можете сразу указать параметры поиска (конечно же, обычно эту строку будет формировать какое-то приложение). Так, ввод в браузер ldap://192.168.0.99/cn=Antonchuk,dc=comizdat,dc=com непосредственно отобразит информацию о главном редакторе К+П. Этот тип URL поддерживается Internet Explorer и Firefox (Netscape) — но не поддерживается, например, в Opera.

Как уже было сказано, LDAP, помимо системы обслуживания запросов, изначально включает и систему аутентификации. Администратор задает привилегии пользователей и определяет записи, к которым тот или иной из них может осуществлять доступ. Списки правил доступа (ACL, Access Control List) позволяют настроить доступ любым образом: в типичном случае пользователь имеет право изменять собственную частную информацию, а все остальные — просматривать ее. Однако можно, например, защитить отдельные поля частной записи от просмотра или модификации.

Собственно, существуют и общественные LDAP-серверы, доступные для поиска всему миру (к примеру, BigFoot или Infospace) — но все-таки основное применение протокол находит на уровне больших и средних корпораций. Не прекращаются попытки создать методы объединения отдельных серверов с целью создания "глобального каталожества". Но до реального воплощения пока далеко.

Также LDAP используется для каталогов сетевых ресурсов и других вещей, отличных от персональных данных. Например, тот же Netscape Communicator при создании пользовательского экаунта создает запись в централизованной базе данных LDAP и пытается хранить там все ваши настройки, такие как закладки часто посещаемых вами страниц.

В этом смысле LDAP в некоторых сферах может поконкурировать с методом доступа SQL, поскольку работает напрямую через TCP/IP и хорошо адаптирован к работе в сети. Однако учтите, что LDAP ориентирован на быстрый поиск и доступ (чтение) данных — но внесение изменений не является настолько же быстрой и эффективной операцией. Так что этот протокол ориентирован, скорее, на статические данные: адреса, телефоны, пароли, сетевые ресурсы — и не подойдет для информации, которая склонна быстро меняться.

По сути, LDAP — не реляционная база данных. Структура базы LDAP скорее напоминает XML, где запись представляет собой комбинацию атрибут: значение. Поскольку существует возможность определять новые типы полей, то в LDAP можно сохранить любую текстовую или бинарную информацию. Это обуславливает большую гибкость для описания новых полей и структур, но в общем случае поиск по неиндексированному полю — операция довольно медленная.



Содержание раздела