Организация данных в LDAP

До сих пор мы говорили только об одном элементе, но спрос на каталоги, содержащие только один элемент, очень мал. Как только мы станем рассматривать каталоги, содержащие много элементов, перед нами тотчас встанет вопрос, с которого начиналось данное приложение: как найти что-либо?

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

Если вы посмотрите на рис. В.1, то увидите, что мы рассмотрели все составляющие элемента, кроме его имени. У каждого элемента есть имя, известное как DN, или его отличительное имя (Distinguished Name). DN состоит из строки RDN, или относительных отличительных имен (Relative Distinguished Names). К отличительным именам мы скоро вернемся, но сначала остановимся на составляющих блоках RDN.

RDN состоит из одной или нескольких пар «имя-значение атрибута» (name-value). Например, cn=Jay Sekora (где en- это «common name», или имя) вполне может быть относительным отличительным именем, Имя атрибута - сп, а его значение - Jay Sckora.

Ни в спецификации LDAP, ни в спецификации Х.500 не указано, из каких атрибутов должно состоять RDN. Единственное, что требуется, уникальность RDN на каждом уровне в иерархии каталогов. Такое oграничение существует из-за того, что LDAP ничего не знает о «третьем элементе четвертой ветви дерева каталогов» и должен полагаться на уникальные имена на каждом уровне, чтобы различать на нем элементы. Посмотрим, как это ограничение действует на практике.

Возьмем, к примеру, еще одно значение RDN: cn=Ronert Smith. Вероятно, это не лучший выбор для RDN, поскольку даже в средней организации, скорее всего, существует не один Роберт Смит. Если в организации работает много людей, а иерархия LDAP довольно плоская, то подобные пересечения имен вполне вероятны. Более правильный элемент состоит из двух атрибутов, например cn=Rcbert Sriith + i=B(Атрибуты в RDN объединяются при помощи знака «плюс».)

Но с исправленным RDN, к которому добавлен атрибут 1 (местоположение), по- прежнему будут проблемы. Вероятно, мы отложили конфликт имен, но не исключили полностью вероятность его возникновения. Более того, если Смит переедет, нам придется изменить и КВл элемента и местоположение (атрибут 1) в этом элементе. Вероятно, самое лучшее относительное имя, которое можно использовать, уникальный и неизменный идентификатор данного человека. В частности, можно выбрать электронный адрес человека, тогда RDN изменится на uid = rsrnith. Этот пример должен дать читателю представление о принимаемых в схемах решениях.

Проницательные читатели заметят, что мы на самом деле не расширили сферу обзора, а по-прежнему возимся с единственным элементом. Обсуждение RDN было прелюдией, а вот и настоящий переход: элементы организованы в виде древоподобной структуры, известной как информационное дерево каталогов (Directory Information Tree, DIT), или просто дерево каталогов. Лучше применять последний термин, поскольку в Х.500 аббревиатура DIT обычно служит для обозначения одного общего дерева, похожего на глобальную иерархию DNS или MIB, о которой речь пойдет позже, при обсуждении SNMP.

А теперь снова вернемся к отличительным именам. Каждый элемент из дерева каталогов можно найти по его отличительному имени (DN), состоящему из относительного имени элемента (RDN), за которым следуют все RDN (разделяемые запятыми или точками с запятой), найденные при движении от него вверх к корневому элементу. Если перемещаться в направлении, указанном стрелками (рис. В.2), и запоминать при движении относительные имена, то можно создать DN для каждого выделенного элемента.

Для первого элемента получилось бы такое DN (отличительное имя):

cn=Robert Smith. l-n:ain campus. ou=CCS, o=Hogwarts School, c=US

Для второго:

uid=rsmith, ou=syste-ins, ou=people, dc=ccs, dc-hogwarts, dc=edu

ou - это сокращение от «organizational unit» (подразделение организации), о - сокращение от «organization» (организация), dc - «domain component» (компонент домена, подобный DNS), а с - сокращение от «country» (страна) (не имеет ничего общего с Улицей Сезам).

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

Pat Hinds

288 St. Bucky Avenue

Anywhere, MA 02104

USA

начинается с частного (человек) и заканчивается самым общим компонентом (страна). То же имеет место и в DN. В примерах DN такой порядок хорошо заметен.

Вершина дерева каталогов называется суффиксом каталога, т. к. это последняя составляющая каждого отличительного имени из данного дерева каталогов. При создании иерархической инфраструктуры с использованием нескольких делегированных LDAP-серверов суффиксы очень важны. Применяя концепцию LDAPvS, известную под названием referral, можно добавить элемент в дерево каталогов, в котором говорится: «За всеми элементами с этим суффиксом обращайтесь к тому серверу». Направления указываются при помощи LDAP URL, которые очень похожи на обычные URL. Единственное их отличие - это ссылка на определенное имя или другую информацию, имеющую отношение к LDAP. Вот пример такой ссылки из RFC2255, определяющего формат LDAP URL:

ldap://lcap. ltd. unich. edJ/o=U-nversity%20o*%20Micr:3an.