Отчет по лабораторной работе №2 «Novell NetWare»

Отчет по лабораторной работе №2 «Novell NetWare»

по курсу «Эксплуатация АСОИУ»

 

 

Группа ИУ5-82

Кошик В.

Калугин В.

Трофимова Д.

Бельская А.

Николаев С.

 

Москва 2012

NetWare — сетевая операционная система и набор сетевых протоколов, которые используются в этой системе для взаимодействия с компьютерами-клиентами, подключёнными к сети. Операционная система NetWare создана компанией Novell. NetWare является закрытой операционной системой, использующей кооперативную многозадачность для выполнения различных служб на компьютерах с архитектурой Intel x86. В основе сетевых протоколов системы лежит стек протоколов XNS. В настоящее время NetWare поддерживает протоколы TCP/IP и IPX/SPX. NetWare является одним из семейств XNS-систем. К таким системам, например, относятся Banyan VINES и Ungerman-Bass Net/One. В отличие от этих продуктов и XNS, система NetWare заняла существенную долю рынка в начале 1990-х и выдержала конкуренцию с Microsoft Windows NT, после выпуска которой прекратили своё существование другие конкурирующие с ней системы.

В основу NetWare была положена очень простая идея: один или несколько выделенных серверов подключаются к сети и предоставляют для совместного использования своё дисковое пространство в виде «томов». На компьютерах-клиентах с операционной системой MS-DOS запускается несколько специальных резидентных программ, которые позволяют «назначать» буквы дисков на тома. Пользователям необходимо зарегистрироваться в сети, чтобы получить доступ к томам и иметь возможность назначать буквы дисков. Доступ к сетевым ресурсам определяется именем регистрации.

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

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

История

Система NetWare была создана в результате работы SuperSet Software — консалтинговой группы, основанной друзьями Дрю Мэйджером, Дэйлом Найбауэром, Кайлом Пауэллом и позднее вошедшим в эту группу Марком Хёрстом. В основу этой работы были положены результаты их занятий в университете Бригама Янга в городе Прово, штат Юта в октябре 1981 года.

В 1983 году Рэймонд Ноорда присоединился к работе группы SuperSet. Первоначально перед группой стояла задача создания системы CPM совместного использования дисков для сетей на основе оборудования CP/M, которое в то время продавала компания Novell. Внутри группы сложилось убеждение, что CP/M является обречённой на неуспех платформой, и в результате было предложено альтернативное решение для только что выпущенных IBM-совместимых ПК. Группой также было написано приложение Snipes — работающая в текстовом режиме игра, которую они использовали для тестирования новой сети и демонстрации её возможностей. Snipes был первым сетевым приложением для IBM PC и фактически являлся предшественником многих популярных многопользовательских игр, таких как Doom и Quake.

Эта сетевая операционная система позже была названа Novell NetWare. В NetWare используется протокол NCP (англ. NetWare Core Protocol — протокол ядра NetWare), который является протоколом передачи пакетов, позволяющим клиентам передавать запросы на серверы NetWare и получать от них ответы. Первоначально NCP был привязан к протоколам IPX/SPX, то есть система NetWare сама по себе могла использовать для взаимодействия в сети только IPX/SPX. Для хранения информации аутентификации использовалась встроенная система на основе СУБД Btrieve.

Первый программный продукт с именем NetWare был выпущен в 1983 году. Он назывался NetWare 68 (или Novell S-Net), работал на процессоре Motorola 68000 и использовал топологию «звезда». Этот продукт был заменён в 1985 году на NetWare 86, который был написан для работы на процессорах Intel 8086. После выпуска процессора Intel 80286 компания Novell выпустила NetWare 286 (в 1986 году). В 1989 году, после выпуска процессора Intel 80386, последовала NetWare 386. Позже Novell пересмотрела нумерацию версий NetWare: NetWare 286 стала NetWare 2.x, а NetWare 386 стала NetWare 3.x.

 

NetWare 286 2.x

Настройка NetWare версии 2 требовала значительных усилий: для любого изменения было необходимо перекомпилировать ядро и перезагружать систему. NOS поставлялась в виде набора объектных моделей. Перекомпиляция для замены драйвера ЛВС требовали поочерёдного использования 20 дискет. Тем не менее именно в этой версии произошла изоляция ядра сетевой операционной системы (NOS) от технологии - архитектуры коммуникаций. Конкурирующие с NetWare продукты представляли собой " коробочные" решения, сочетавшие софт и железки из одного ящика. Администрирование NetWare выполнялось с помощью текстовых утилит, например SYSCON. В NetWare 2 использовалась файловая система NetWare File System 286, или NWFS 286.

NetWare 3.x

NetWare версии 3 была упрощена за счёт построения по модульному принципу. Функции операционной системы выполнялись отдельными программными модулями — загружаемыми модулями NetWare (NLM), которые могли быть загружены как при запуске системы, так и по мере необходимости после запуска. Такая архитектура позволила добавлять необходимые функции в систему, такие как антивирусную защиту, резервное копирование, поддержку длинных имён файлов (в то время имена файлов в распространённой MS-DOS ограничены 8 символами имени и 3 символами расширения имени) или поддержку файлов Macintosh. Управление NetWare по-прежнему предлагалось выполнять в текстовых утилитах. В NetWare 3.x появилась новая файловая система, которая использовалась по умолчанию во всех системах NetWare до NetWare 5.x, — Netware File System 386, или NWFS 386.

Первоначально в NetWare для аутентификации использовалась служба Bindery. Это была система, в которой все данные о правах доступа пользователей и данные системы защиты хранились отдельно на каждом сервере. Когда в сети было несколько серверов, пользователям нужно было регистрироваться в каждом из этих серверов отдельно, а каждый сервер должен был содержать свой список пользователей с правами доступа.

NetWare 4.x

Версия 4 в 1993 году представила службу каталогов Novell (NDS) — служба Bindery была заменена службой глобального каталога, в котором описывалась вся сетевая инфраструктура и который управлялся из одной точки. Это означало, что пользователю достаточно было аутентифицироваться в NDS один раз, чтобы получить доступ к ресурсам любого сервера в структуре дерева каталога. Таким образом пользователи могли получить доступ к сетевым ресурсам вне зависимости от того, на каком именно сервере эти ресурсы располагались. В версии 4 также появился ряд полезных компонентов и утилит, такие как служба распределённой печати Novell (NDPS), поддержка Java и асимметричное (с публичным и секретным ключами) шифрование RSA. Легенда: В недрах Novell с проектом NDS конкурировал проект Super Bindery идейно очень напоминавший Active Directory от 2000 года. Плоской базе данных " связей" просто добавляли еще одно измерение..

NetWare 4.1x

В NetWare 4.11 (intraNetWare, выпуск 1996 г.) вошёл ряд улучшений, позволивших упростить установку операционной системы и её управление, а также сделать её более быстрой и стабильной. С этой версией поставлялся также первый полностью 32-разрядный клиент для рабочих станций Microsoft Windows и утилита NetWare Administrator (NWADMIN или NWADMN32) — графическая утилита администрирования NetWare. В то время компания Novell всё ещё сохраняла привязку своей системы к стеку протоколов IPX/SPX, так как протокол NCP поддерживался только с этим стеком. Однако благодаря увеличению популярности TCP/IP в NetWare 4.11 был включён ряд компонентов и утилит, которые позволяли создавать интрасети и подключать локальные сети к Интернету. В рамках концепции Защищенная интеграция с операционной системой поставлялись средства для подключения рабочих станций ( NIAS, Novell Internet Acces Server ) IPX к сетям IP, - шлюз IPX/IP. Компания Novell в первый раз включила в поставку приложение веб-сервер (англ. Webserver), которое позволяло организовать веб-сайты на базе серверов NetWare. В этой версии также началась интеграция Интернет-технологий, например путём реализации протоколов DHCP и DNS на платформе NetWare. NetWare 4.11 послужила полигоном для новой системы печати по протоколу TCP/IP - NDPS - Novell Distributed Print Services созданного на основе протокола LPR/LPD.

В это же время компания Novell интенсифицировала работы по интеграции своих продуктов со службой каталогов NDS. Почтовая система GroupWise была интегрирована с NDS, и компания Novell выпустила ряд других продуктов с поддержкой каталога: ZENworks, BorderManager, Novell Modular Authentication Services и другие.

NetWare IP

Дополнительный программный продукт, поставлявшийся в комплекте NetWare 4.11 Достоин упоминания из-за необычной истории. Да, Novell сохранила верность своему стеку IPX/SPX, и протокол NCP поддерживался только с ним. Однако шлюз IPX/IP был не единственным решением, которое Novell предлагала клиентам. Существовал и параллельный проект - инкапсуляция дэйтаграмм IPX в пакеты UDP протокола TCP/IP. Эту задачу выполнял продукт, названный NetWare IP или NWIP на внутреннем сленге NOvell. Особенно интересен способ объявления серверов в сети, которая идеологически не поддерживает широковещательный сообщения: NWIP использовал систему фиктивных доменов DNS. В домене действующей сети IP создавался фиктивный домен, имя которого сообщалось клиентам, а ответственный за него сервера имен DNS и были серверами! Это практически полностью исключало потребность в широковещательных сообщениях. Самое интересное: Этот механизм объявления серверов сейчас использует Microsoft Windows. Только имя фиктивного домена там фиксировано: ms$domain. В NetWare 5.х места NetWareIP уже не нашлось: Novell делает ставку на добрые старые широковещательные сообщения и новый сервис SLP.

NetWare 5.x

С выпуском в октябре 1998 года NetWare 5, компания Novell признала решающую роль Интернета и сделала основной для протокола NCP поддержку стека TCP/IP, а не IPX/SPX. Стек протоколов IPX/SPX поддерживался, но роль основного стека стал играть TCP/IP. Большинство утилит Novell и продуктов других компаний надо было переписывать для работы с TCP/IP, а не с IPX/SPX. С NetWare 5 поставлялась первая версия графической Java-консоли администрирования — ConsoleOne, которую предполагалось использовать вместе с утилитами NWAdmin.

 

Большим изменениям подверглось ядро системы. Novell изменила кооперативной многозадачности! NetWare 5.x стала одной из первых операционных систем, предложивших запуск сомнительных приложений в защищенном адресном пространстве (Protected address space) ставшем в настоящее время стандартом.

Продукт NetWare 5 был выпущен во время уменьшения доли рынка NetWare (на западных рынках) по мере замены серверов NetWare на серверы Windows NT. Также было выпущено последнее обновление для операционной системы NetWare 4 — NetWare 4.2.

Последней версией NetWare 5 стала версия 5.1, представленная в январе 2000 года. В продукт NetWare 5.x было включено множество новых компонентов, включая поддержку SAN и кластеров, новой файловой системы NSS (Novell Storage Services), заменившей традиционную файловую систему NWFS, служба сертификатов, IBM WebSphere, службы мультимедиа, службы поиска на веб-ресурсах, Oracle 8, Novell SQL, служба инфраструктуры открытых ключей (PKIS) и другие.

Тем не менее концептуальная слабость продукта бросалась в глаза: предлагалась по прежнему та же самая NetWare, основой которой был файловый сервер. " Pure IP" кроме общности протоколов с сетью Internet ничего не давал пользователям новой NetWare. Сервера WEB она так и не получила; проекты сначала Netscape FastTrack server, а потом и Netscape Enterprise server с треском провалились: эти сервера оказались очень ненадежными в работе, были плохо совместимыми с Internet explorer, но самое главное - проблему скриптинга Web страниц Novell удалось условно решить только после перехода на сервер Apache. Формально сервера Netscape поддерживали asp скрипты, но к сожалению, формальностью сходство заканчивалось. Скрипты обрабатывало приложение netbasic опасность и проблемность которого вошла в фольклор администраторов NetWare. Функционал также был очень скуден: полная противоположность Microsoft, сумевшего в кратчайшие сроки создать мощную интеграцию сценариев Web страниц с ресурсами операционной системы. Клиенты же Novell могли рассчитывать только на java скриптинг, трудоемкий и имевший свои ограничения на данной платформе. Немудрено, что число клиентов NetWare начало таять в геометрической прогрессии..

NetWare 6.x

Основное отличие NetWare 6 от предшественницы связано с очередным поворотом в мировоззрении менеджеров Novell: видя безнадежность поддержания пользовательского интереса к головному продукту в традиционном ключе компании, было принято эпохальное решение портирования в ядро NetWare большего объема POSIX - кода с целью портирования на платформу NetWare 6 популярных UNIX программ, таких как WEB Server Apache, SQL сервера MySQL, Php, SSh и других приложений. Именно это позволило сдвинуть наконец историю операционной системы с мертвой точки. С выпуском в октябре 2001 года NetWare 6, изменения были продолжены: была добавлена улучшенная поддержка симметричной многопроцессорной обработки (SMP — несколько процессоров в одном сервере), iFolder (синхронизация файлов локальной папки с сервером и предоставления защищённого доступа к ним в локальной сети и через Интернет), iManager (веб-утилита администрирования NetWare и других продуктов), Native File Access Pack (NFAP — компонент, предоставляющих доступ к ресурсам сервера NetWare клиентам Windows, Macintosh и UNIX-подобных систем по протоколам соответствующих сетей), NetDrive (утилита, позволяющая назначать буквы дисков на HTTP- и FTP-ресурсы, а также на серверы iFolder), а также веб-сервер по умолчанию был заменён с Netscape Enterprise Server на Apache. Также база данных Btrieve (используемая с предыдущих версиях NetWare) была заменена на Pervasive PSQL, представляющего собой развитие того же Btrieve.

Open Enterprise Server

В основе идеологии Open Enterprise Server лежит по-своему трезвая мысль: чем портировать приложения мира *nix под NetWare (а большинство вендоров согласилось принять участие в этом проекте только под финансовым давлением Novell) гораздо проще портировать саму NetWare под *nix!

OES 1.0

После версии NetWare 6.5 компания Novell выпустила в 2003 году операционную систему Open Enterprise Server (OES), в которой пользователи могут выбирать ядро операционной системы — NetWare или SUSE Linux Enterprise Server (англ.). Эта интеграция была выполнена вскоре после приобретения компанией Novell компаний Ximian и немецкого поставщика GNU/Linux компании SuSE. Тем самым Novell сместила своё внимание с NetWare и портирует приложения на GNU/Linux. Хотя официально компания Novell это отрицает и заявляет, что она будет вести разработку и NetWare, и Linux. Тем не менее 7 марта 2010, Novell прекратила основную поддержку NetWare, предложив клиентам перейти на OES: Linux^[1]. Также, NetWare отсутствует в списке поддерживаемых операционных систем другого флагманского продукта компании Novell GroupWise 2012, вышедшего в январе 2012 года.

OES 2.0

OES 2 был выпущен 8 октября 2007. Он включил в себя NetWare 6.5 SP7 и новую, основанную на Linux — SLES10 SP1.

• OES 2 SP1 был выпущен в Декабре 2008, и включал NetWare 6.5 SP8 и SLES 10 SP2.
• OES 2 SP2 был выпущен в Ноябре 2009, и включал SLES 10 SP3.
• OES 2 SP3 был выпущен в Декабре 2010, и включал SLES 10 SP3.

OES 11

• OES 11 основанный на SLES 11 SP1 (только 64 Бит) был выпущен 13 Декабря 2011. Это первый выпуск OES, доступный только в 64-битной (x86_64) редакции.

Производительность

Система NetWare доминировала на рынке сетевых операционных систем с середины 80-х годов до конца 90-х благодаря чрезвычайно высокой производительности по сравнению с другими сетевыми операционными системами. Большинство сравнительных тестов в то время указывали на преимущество в производительности в соотношении от 5: 1 до 10: 1 по сравнению с продуктами Microsoft, Banyan и других компаний. Результаты одного сравнительного теста были особенно интересны: система NetWare 3.x со службами NFS, работающими по протоколам TCP/IP (не по разработанному для NetWare протоколу IPX), сравнивалась с дорогостоящим выделенным сервером Auspex NFS и с сервером SCO Unix с запущенными службами NFS. Производительность NetWare NFS превысила производительность обоих систем NFS, являющихся частью соответствующих операционных систем, и превысила в два раза производительность SCO Unix NFS на одинаковом оборудовании.

Было несколько причин такой производительности NetWare.

Эффективность протокола NCP

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

1. Клиент отправлял запрос на сервер.
2. Сервер подтверждал получение запроса.
3. Клиент подтверждал получение подтверждения.
4. Сервер отправлял запрошенные данные клиенту.
5. Клиент подтверждал получение данных.
6. Сервер подтверждал получение подтверждения.

В основе же протокола NCP лежала концепция надёжной доставки пакетов сетью в большинстве случаев. Поэтому ответ на запрос служил в большинстве случаев подтверждением. Пример запроса чтения клиента в данной модели.

1. Клиент отправлял запрос на сервер.
2. Сервер отправлял запрошенные данные клиенту.

Все запросы содержали последовательный номер, поэтому если клиент не получал ответа в течение указанного времени, он отправлял запрос повторно с тем же последовательным номером. Если сервер уже обрабатывал этот запрос, он отправлял кэшированный ответ повторно. Если у сервера не было времени на обработку запроса, он отправлял «положительное подтверждение», что означало «я получил запрос, но ещё не дошёл до его обработки, не беспокойте меня». Все было бы хорошо, но для оперативной работы с таблицами баз данных типа.DBF.DBT а также их индексами.ntx.cdx был придуман лукавый протокол opportunistic file lock level 2 или сокращенно oplock 2. Сущность его состояла в том, что сервер по запросу клиента якобы монопольно открывшего файлы на запись не производил изменений на дисковом устройстве, но отправлял клиенту фиктивное подтверждение о том, что оная запись сделана. На самом деле изменения вносились только в прокешированный образ открытого на запись файла, само событие записи просто ставилось на конвейер файловой системы и отрабатывалось по мере очередности. Конкурирующим на " монопольное" открытие данного файла клиентам отсылались обновленные данные, благодаря чему целостность данных не нарушалась. Это приводило к громадному росту производительности работы баз данных, оперировавших таблицами указанных форматов, и не только ими. Но зато решение этой проблемы в рамках концепции разделяемых дисков не составило проблемы: зато для модели файловых служб стало неразрешимой задачей на долгие годы.

Результатом использования этой модели «надёжной сети» было уменьшение на две трети сетевого трафика и связанных с ним задержек.

Схема каталога

Основной частью DIB и Directory Services является схема каталога (Directory Schema). Схема каталога - это набор правил, определяющих характеристики информации по объектам, атрибуты и значения, которые можно добавить в дерево каталогов. Эти правила можно сохранить в специальной части DIB, и копия их хранится на каждом сервере имен. Все серверы имен в сети содержат одну и ту же информацию схемы.

Понимание принципов организации объектов должно помочь вам понять назначения и организацию схемы каталога. Если мы возьмем несколько объектов реального мира и начнем перечислять характеристики каждого, то обнаружим, что некоторые объекты имеют одни и те же характеристики. Одни объекты имеют ручки, другие красные, некоторые закрываются, а некоторые находятся далеко. Если мы соберем и объединим все характеристики в один список, то можем использовать его как справочник по всем выбранным для определения характеристикам. Таким образом, нам не нужно определять каждую карактеристику для каждого объекта отдельно. Ручка есть ручка, независимо от того, какая это ручка - двери, ящика стола или другого объекта.

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

Пусть, например, мы классифицируем объекты как сферы. По определению мы можем потребовать, чтобы сферы описывались характеристиками размера, и чтобы это размер (радиус) представлялся числом. Соотнесем это со схемой каталога. Тогда orb будет классом объекта, размер size - атрибутом, а число number - синтаксисом атрибута. (Иногда в документации Novell атрибуты объекта называются характеристиками. Мы выбрали в этой главе термин " атрибуты", так как в справочном руководстве программиста Directory Schema в качестве типов характеристик и синтаксиса характеристик определяет типы атрибута Attrubute Types и синтаксис атрибута Attrubute Sytaxes.)

Чтобы легче было идентифицировать объекты orb, вы можете определить другие атрибуты. Для каждой сферы orb вы можете отслеживать характеристику конструкции construction. Сфера может быть пустой, твердой или наполненной. Другим атрибутом может быть назначение purpose. Бейсбольный мяч - для игры, стальной шарик - для применения в механизмах (например, в шарикоподшипниках), а планета - для обитания. Вы можете также захотеть знать, кто является владельцем сферы - owner. Мы можем также ввести атрибут, используемый только для целей идентификации и назвать его именем - name. Если требуется, этот список можно продолжить. Пока же мы должны решить, что хотим отслеживать следующие характеристики каждого объекта-сферы:

 

Radius: расстояние от точки на поверхности объекта до центра объекта.

 

Construction: структурное качество объектов.

 

Purpose: возможное использование объекта.

 

Owner: тот, кто отвечает за этот объект.

 

Name: то, что мы используем для идентификации объекта.

 

Информацию, которую мы решили отслеживать, можно рассматривать в качестве правил построения информационной базы. Когда мы начинаем идентифицировать объекты как сферы, мы делаем это, задавая для них специальную информацию. Это дает вам представление о том, что представляет собой схема каталога (Directory Schema). Она охватывает правила для построения базы данных - дерева каталогов (Directory Tree).

Кроме определения объекта и правил атрибутов, схема включает в себя правила для построения значений заданных атрибутов. Например, атрибут радиуса сферы можно представить строкой символов ASCII с символами из подмножества " 0, 1, 2, 3, 4, 5, 6, 7, 8, 9". Его можно представить в виде двоичного значения или числа символов перед нулевым символом. Здесь можно использовать множество форм. Мы должны специфицировать ту форму, которую будем использовать. В схеме это делается с помощью определений синтаксиса атрибутов.

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

Определение схемы для каждого объекта включает в себя правила, которые управляют взаимосвязью объектов друг с другом в дереве каталога. Эти правила составляют определение включения. При создании объекта в дереве каталога он может быть подчиненным в дереве только тем объектам, которые находятся в определении включения его объектного класса. Если вернуться к примеру сфер, то мы можем определить объект с именем basketball - баскетбольный мяч. Если объекты класса orb ограничены своим отношением включения и должны подчиняться другим объектам класса room (комната), то можем обнаружить, что объект basketball содержится в объекте с именем closet (стенной шкаф), который представляет собой " маленькую комнату". Либо он обнаруживается в объекте с именем gymnasuim (спортзал), который является большой комнатой. Однако, согласно этому определению, мы не можем получить объект класса orb на футбольном поле, так как поле - это не комната.

Чтобы получить более полное представление об этом дереве, мы может рассмотреть его детальнее и обнаружить, что объект с именем gymnasium имеет родительский объект с именем West_High (название района), который, в свою очередь, имеет родительский объект Smalltown (городок). Полное имя объекта в Directory Services тогда будет иметь вид basketball.gymnasium.West_High.Smalltown. Каждое определение класса объекта включает в себя класс объектов, которые могут быть родительскими для данного объекта. Эта спецификация является определением включения.

Схема каталога задает также, какие атрибуты необходимы при создании объекта данного класса и какие необязательны. Это называется обязательными атрибутами и необязательными атрибутами.

В определении класса объектов вы должны задать, какие атрибуты будут использоваться для наименования объекта. В примере со сферами вы можете потребовать указания для наименования всех сфер владельца и имени. Одну сферу тогда можно идентифицировать как John's baseball (бейсбольный мяч Джона), а другую - как John's earth (Земля Джона).

По различным причинам для заданного объекта вам может потребоваться назначить другое имя (псевдоним). Такие псевдонимы представляют собой объекты, которые могут добавляться к дереву каталога и ссылаться на исходный объект. Эти псевдонимы разыменовываются в объект, псевдонимом которого они являются. Например, на John' earth можно ссылаться по псевдониму объекта с именем world (мир). Взглянув на объект с именем world, вы можете захотеть разыменовать его обратно к исходному объекту с именем John's earth.

Для каждого определенного в схеме атрибута задается синтаксис атрибута. Этот синтаксис может определять форму и тип. Объекты класса room может иметь атрибут с именем dimensions (размеры). Синтаксисом атрибута dimension будет три числа, представляющих высоту, ширину и длину. В данном случае синтаксисом значения являются три числа. Помните, что определение синтаксиса специфицирует тип значений, а не сами фактические значения.

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

Схема каталога должна проектироваться и создаваться до того, как объекты добавляются в дерево каталога. Определенная Novell схема каталога называется базовой схемой. Если базовая схема не полностью отвечает вашим нуждам, вы можете добавить к ней другие определения, используя подходящие функции API Directory Services, которые обсуждаются в данной главе ниже.

Разделы

DIB может храниться в виде распределенных по сети фрагментов на различных серверных машинах. Схема представляет собой часть DIB, которая хранится на каждом сервере имен. Дерево каталогов Directory Tree - это часть DIB, которую можно разделить на фрагменты, называемые разделами. При создании раздела в качестве места разделения дерева выбирается объект. Это объект становится корнем раздела.

Не путайте корень раздела с корнем [root] дерева каталога. [root] - это имя самого верхнего раздела всего дерева. Каждый раздел - это другая часть дерева, но она может копироваться и храниться в нескольких местах. Это обеспечивает более быстрый доступ и гарантирует, что если один сервер имен выходит из строя, то вы сможете поддерживать доступ к информации дерева каталогов через другой сервер имен.

Разделы могут иметь три вида: основная копия, вспомогательная копия и копия, доступная только по чтению. Каждый из них позволяет выполнять клиентам Directory Services определенные функции. Например, сервер имен с копией, доступной только по чтению, не может использоваться для добавления к дереву новых объектов. Клиент должен связаться с сервером имен с основной или вспомогательной копией и дать запрос на обновление. Вскоре после добавления нового объекта к основной или вспомогательной копии все другие копии также будут обновлены в соответствии с этой новой информацией. Этот процесс обновления называется синхронизацией службы каталогов - DSS (Directory Services Synchronization).

Служба каталогов Directory Services будет обновлять разделы и синхронизировать данные без какого-либо вмешательства клиента или пользователя. Когда изменение вносится в DIB, то через несколько секунд (в большинстве случаев) это изменение отражается во всех копиях.

Доступ

Вы можете получить доступ к серверам NetWare 4.0, используя предыдущие оболочки клиентных рабочих станций или использовать новую оболочку NetWare 4.0, которая называется реквестором. Лучший способ получить доступ к DIB с клиентной рабочей станции состоит в использовании реквестора NetWare 4.0. NLM становятся клиентами и получают доступ к Directory Services с помощью библиотеки DSAPI.NLM. Рабочая станция становится клиентом путем загрузки реквестора NetWare 4.0 и использования библиотеки интерфейса Си (CLIB). Спецификации функций API в DSAPI.NLM и в библиотеки интерфейса Си совпадают. И это неплохо, потому что один и тот же программный код на языке Си (с минимальными изменениями) можно скомпилировать в файл EXE для работы на вашей рабочей станции или в NLM для работы на сервере.

Клиент Directory Services по определению представляет собой рабочую станцию или NLM, имеющий доступ к DIB и способный давать запросы Directory Services. Чтобы стать клиентом службы, отличной от Directory Services, вы должны пройти проверку полномочий доступа к данным средствам. Контроль доступа Access Control - это одно из средств, предусмотренных в Directory Services, но оно используется для облегчения отслеживания и контроля доступа к другим сетевым средствам.

Защита доступа к DIB

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

Тем, кто уже работал с базой объектов Bindery, полномочия доступа могут быть знакомы. Bindery имеет пять уровней защиты: Attached, Logged in, Object, Supervisor и Bindery. Эти уровни реализуют полезную и простую системы защиты Bindery.

Защита доступа DIB служит тем же целям, но она гораздо более гибкая и ориентированная на объекты, чем защита, реализованная для Bindery. Она значительно более мощная и позволяет вам управлять доступом практически любым нужным вам способом. Если вы знакомы с тем, как в NetWare 4.0 реализована защита файловой системы, вам не следует беспокоиться об изучении наследования полномочий доступа к DIB. Нужно только не забывать о разделении двух типов защиты. Защита каталога предназначена для ограничения доступа к каталогу, а защита файловой системы - для ограничения доступа к файлам.

Bindery организует доступ по уровням защиты. Неважно, к какому объекты вы пытаетесь обратиться, важно только, что этот объект имеет определенный уровень защиты. Защита Bindery достаточно эффективна, но она не такая гибкая как защита DIB. С помощью каталога отдельной группе пользователей можно предоставить полномочия доступа к объектам, отдельным атрибутам объекта или всем атрибутам.

Полномочия доступа DIB, допускающие обращение к объектам, отличны от тек, которые допускают обращение к атрибутам. Для объектов это следующие полномочия:

 

Просмотр (Browse)

 

Добавление (Add)

 

Удаление (Delete)

 

Переименование (Rename)

 

Супервизор (Supervisor)

 

а для атрибутов:

 

Сравнение (Compare)

 

Чтение (Read)

 

Запись (Write)

 

Сам (Self)

 

Супервизор (Supervisor)

 

Есть четыре способа получить любое из этих полномочий или их все: с помощью прямого назначения, путем наследования от родителей в дереве, из эквивалентных присваиваний полномочий и по членству в группе (Group Membership). Существует процесс фильтрации, который применяется к каждому из этих типов назначений для конкретного объекта. Давайте познакомимся с каждым из них поближе.

Назовем в нашем обсуждении те объекты, которым присваиваются полномочия доступа, субъектами. Субъект - это то, чему (или кому) дается право на действие, и часто это объект пользователя, объект сервера или объект группы, однако этом может быть любой объект в дереве. Целью является то, над чем этот субъект выполняет действия. Целью может быть заданный объект, конкретный атрибут объекта или все его атрибуты. Полномочия доступа назначаются с помощью атрибута целевого объекта, который называется списком управления доступом - ACL (Access Control List). ACL содержит список назначений полномочий доступа.

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

Полномочия наследуются на основе структуры дерева каталога. Подчиненные объекты наследуют привилегии, которые даны их родительским объектам. На основе их взаимосвязей в древовидной структуре они используют полномочия, предоставленные родительским объектам (независимо от того, насколько удаленными они являются). Предположим, например, что подчиненными объектами в дереве объектов Novell являются Olga и Julia. Если мы предоставляем полномочия Novell, то Olga и Julia также будут иметь эти полномочия. Как это работает, показано на Рис. 3.2.

 

+----------------+

 

¦ Popurri ¦

 

+-----+-----+----+

 

+-----------+ +----------+

 

+--------+-------+ +--------+-------+

 

¦ Researching ¦ ¦ Marketing ¦

 

+--------+-------+ +-----+-----+----+

 

+-------+ +-----------+ +---+

 

+--------+-------+ +--------+-------+ +--------+-------+

 

¦ Olga ¦ ¦ Julia ¦ ¦ Kirill ¦

 

+----------------+ +----------------+ +----------------+

 

Access Control List =

 

права чтения Popurri

 

Olga и Kirill могут считывать атрибуты Julia

Некоторые типы объектов имеют атрибут равной защиты, который указывает, что в смысле полномочий доступа один объект равен другому (или другим). Таким образом, объект получит все назначения полномочий, присвоенный тому объекту, к которому он приравнен. Аналогично, объект получает все полномочия той группы, членом которой он является. Если объект Dina равен по защите объекту Lina, которому присвоены полномочия на Printserver, Dina имеет на Printserver те же полномочия, что и Lina.

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

1234Следующая ⇒

Поделиться: