Приложение A — LDAP: Головная боль с именованием корневой записи

Запись самого верхнего уровня в LDAP DIT (Directory Information Tree, информационном дереве каталога) в мире LDAP неоднозначно называется корневой (root), базовой (base) или суффиксом (suffix), в зависимости от документации, её автора, дня недели или каких-либо других переменных величин, доподлинно нам не известных.

Термин Root DSE определяет своего рода супер-корневую запись, содержащую все DIT, поддерживаемые сервером LDAP, а также операционные объекты.

Чаще всего в документации присутствует два разных подхода к предмету корневой записи (суффикса или базовой записи). Согласно первому, это нечто волшебное, находящееся за пределами понимания простых смертных, воздействовать на которое можно лишь посредством ритуалов, передающихся из поколения в поколение, а потому нет никакого смысла даже пытаться объяснять что-либо. Последователи второго подхода, наоборот, воспевают данный предмет в невероятно длинных песнопениях, обычно сопровождающихся плачем и скрежетом зубов, а также заклинаниями двуликому богу ITU и IETF.

Наш совет — если Вам не нужно предоставлять Ваш каталог в глобальный доступ, определите корневую запись как ou=gobbledegook и больше не забивайте этим голову. О том, как определить простую корневую запись или суффикс, читайте здесь.

Ну а теперь — шутки в сторону.

Источник головной боли — изначальная и похвальная цель X.500 (очевидно, имеющая продолжение в IETF): создать глобальную иерархию каталогов, схожую с системой DNS (если эта концепция Вам знакома).

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

Если же у Вас есть (или могут появиться в будущем) глобальные амбиции — читайте далее.

В X.500 в качестве стандарта корневой записи выбран ou=organisation name,c=country code, например, ou=Example Inc., c=u. Какие на то были побудительные мотивы, — непонятно; возможно, в тот момент подобная идея показалась хорошей, а может это связано с фазами Луны. Кое-что об определениях ou. О том, как определить корневую запись или суффикс в формате X.500, читайте здесь.

IETF (в RFC 2247, имеющем, впрочем, только статус информационного) решила использовать для именования корневой записи структуру доменных имён, например, dc=example, dc=com. Отчасти это связано с тем, что подобное именование основано на доменных именах DNS, являющихся по своей природе глобально уникальными, отчасти — по некоторым более специфическим причинам, как то: зная либо SRV-запись DNS, либо имя сервера LDAP, можно сделать предположение о суффиксе каталога. То есть, если имя сервера LDAP (полученное напрямую или через SRV-запись) — ldap.example.com, то разумно будет предположить, что суффикс каталога будет dc=example,dc=com. На наш взгляд, не слишком убедительно. О том, как определить корневую запись или суффикс в формате RFC 2247, читайте здесь.

Если у Вас нет доменного имени — что ж, Вам просто не повезло. Если у Вас несколько доменных имён, Вы вольны выбрать любое (Вы можете даже использовать их все), так как каждое доменное имя уникально.

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

Все три корневые записи на рисунке ниже являются верными. Две из них могут быть глобально уникальными, одна, сами понимаете, нет. Теперь всё!

Подходы к именованию корневой записи



Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.

Нашли ошибку в переводе? Сообщите переводчикам!

Copyright © 1994-2017 ZyTrax, Inc. Все права защищены. Последнее изменение страницы: 4 марта 2016 г.
Переведено участниками проекта Pro-LDAP.ru в 2012-2017 г.

Эта страница

Содержание

Приложение A — LDAP: Головная боль с именованием корневой записи
OpenLDAP 2.4 Руководство

Содержание

Введение в службы каталогов OpenLDAPБыстрое развёртывание и начало работыОбщая картина - варианты конфигурацииСборка и установка OpenLDAPНастройка slapd

 

Конфигурационный файл slapdЗапуск slapdКонтроль доступаОграниченияИнструментыМеханизмы манипуляции даннымиНаложенияСпецификация схемы

 

БезопасностьSASLTLSРаспределённая служба каталоговРепликацияОбслуживаниеМониторингПроизводительностьУстранение неполадок
Перевод официального руководства OpenLDAP 2.4 Admin Guide
Полное содержание здесь
LDAP для учёных-ракетчиков

Содержание

О книгеКонцепции LDAPОбъекты LDAPУстановка LDAPПримерыНастройкаРепликация и отсылкиLDIF и DSMLПротоколLDAP API

 

HOWTOНеполадкиПроизводительностьИнструменты LDAPБезопасностьЗаметкиРесурсы LDAPRFC и X.500ГлоссарийОбъекты
Перевод "LDAP for Rocket Scientists"
Полное содержание здесь
Ресурсы

Книги

Руководство OpenLDAP 2.4LDAP для учёных-ракетчиков

Другие

СтатьиТермины LDAPman-страницы OpenLDAP 2.4Список RFCКлиенты LDAPФайлы наборов схемы
Полезные ресурсы
Форум

 

Разделы форумаНепрочитанные сообщенияПоследние сообщения
Форум проекта
Главная

Pro-LDAP.ru

О проектеНовости проектаУчастникиСтаньте участником!Сообщите об ошибке!Об авторских правахСоглашения проекта
Присоединяйсь!