To
Музалёв Николай: Злой Вы, однако...
To
Denis aka Lu: Согласен с Николаем, что без английского в области IT-технологий... ну, скажем мягко, проблематично. В принципе, для понимания основ были две хороший переводные книги на русском языке - по администрированию NetWare 4 и по NetWare 6/6.5.
Ну а если совсем по существу заданного вопроса, то попробую перевести как я это понимаю.
Введение (от меня
)
1) Термины, оставленные без перевода:
- DS (Directory Services) - служба каталога;
- NDS (Novell Directory Services) - конкретная реализация этой службы компанией Novell;
- LDAP (Lightweight Directory Access Protocol) - один из наиболее распространённых открытых протоколов для доступа к службе каталога, см. RFC2251 и несколько следующих за ним (2252-2255, есть и многочисленные обновления/дополнения);
- NDAP Novell Directory Access Protocol - традиционный набор собственных (proprietary) API, использумый компанией Novell для доступа к своей службе каталога с момента её появления (доступный обычно через Novell Client);
- Bindery - предшественник NDS, существоваший во времена NetWare 3.x - плоская база данных с информацией о сетевых объектах (в первую очередь - пользователи, группы, принтеры).
2) В квадратных скобках я вставлял подразумеваемые по контексту слова или фразы, а мои комментарии - с пометкой "О.К."
Архитектура NDSАгент службы каталога (DS) на сервере NDS обрабатывает запросы от трёх типов клиентов. Два из них - клиенты NDAP и LDAP - обладают сходной функциональностью и имеют полный доступ к каталогу, его элементам, схеме, действиям и фоновым процессам. Третий клиент - клиент bindery - имеет ограниченный доступ, и должен обращаться через эмулятор bindery, который представляет каталог видимым как плоская база данных bindery и скрывает всю функциональность, недоступную в bindery [существовавшую во времена] NetWare 3.x. См.
Bindery Services для более подробной информации об эмуляции bindery.
Агент DS также взаимодействует с другими серверами NDS. Агент устанавливает клиентское содинение на другой сервер NDS и использует [это] соединение для чтения, записи и поиска информации [в элементах каталога], для выполнения связанных с разделами операций, а также для синхронизации данных. Следующий рисунок иллюстрирует коммуникационные пути.
[рисунок]
Клиенты и приложения LDAPКлиенты и приложения LDAP взаимодействуют со службой NDS через сервер Novell LDAP. LDAP-сервер общается непосредственно с агентом DS на своём сервере, а также с агентами DS на других серверах NDS. Клиент определяет, возвращает ли клиент ссылки
(referrals - термин из LDAP - О.К.) или же использует их [самостоятельно] для обхода дерева и удалённого "хождения" при поиске информации на других серверах NDS.
Поскольку клиенты и приложения LDAP не требуют Novell-овского клиента, то [само] LDAP-приложение [и] отвечает за установление соединения и аутентификацию к серверу NDS. Оно также отвечает за соответствие платформенным зависимостям. Например, LDAP-приложение, которое использует Java и работает на клиентской рабочей станции, должно иметь установленную JVM. Приложение LDAP JNDI должно иметь установленный [соответствующий] Java service provider.
Клиенты и приложения NDAPКлиенты и приложения NDAP требуют Novell-овского клиента, который включает поддержку для различных языков [программирования] (C/C++, Java и JNDI) и включает JVM и Java service provider
( странно - вроде бы новелловский клиент, например VLM, отнюдь не обязательно включает Java-компоненты, но тут написано именно так - О.К.). Скриптовые компоненты были построены поверх этих языков для поддержки дополнительных методов доступа к NDS.
Новелловский клиент устанавливает и организует аутентификацию в дерево NDS. Запрос от приложения он формулирует в виде запроса NDAP, который посылается агенту DS. Приложение может использовать соединение, установленное клиентом, или же может установить своё собственное.
Агенты DSАгенты DS отвечают за организацию информации, хранящейся в базе данных NDS, и координацию распределённых действий с другими серверами. Агент организует все NDS-запросы, включая следующие:
- безопасность (аутентификация и управление доступом);
- организацию элементов каталога (добавление, удаление, модификация, поиск, чтение);
- действия с разделами (разбиение, слияние, перемещение);
- действия с репликами (добавление, удаление, смена типа);
- синхронизацию реплик и схемы;
- организацию схемы (чтение и запись).
База данных каталога и схемы
База данных NDS содержит два основных типа информации: каталог и схема. Каталог содержит элементы с их атрибутами и значениями. Приложения Novell обычно ссылаются на элементы каталога как на "объекты" (objects), а на атрибуты - как на "свойства" (properties). Для более подробной информации о том, как NDS организует, использует и разрешает доступ к этой информации, смотри
Объекты eDirectory.
Часть базы данных "схема" содержит определения классов объектов и определения атрибутов. Эти определения управляют информацией, которая может быть добавлена в каталог. Например, схема содержит определение для объекта User (пользователь). Это определение регулирует, где в дереве NDS может быть расположен элемент "пользователь", как он может быть поименован и какие атрибуты обязаны иметь значения прежде чем элемент "пользователь" может быть создан.
Фоновые процессы
Агент службы каталога взаимодействует с фоновыми процессами, которые сохраняют базу данных NDS синхронизированной с другими серверами NDS и вычищенной от устаревших данных. Эти процессы работают без вмешательства пользователя, хотя некоторые [из них] позволяют ограниченное управление [со стороны] пользователя. Для более подробной информации об этих процессах смотри
Фоновые процессы. Для информации о командах для управления процессами смотри
Утилиты отслеживания службы каталога.
Ресурсы операционной системы
Сервер NDS имеет доступ к ресурсам операционной системы, таким как дисковое пространство и память, через интерфейс уровня примитивов. Данный уровень изолирует эту функциональность, так что NDS может быть реализована на различных операционных системах - таких как NetWare, NT и Solaris.