Н.Т. Кустов
АДМИНИСТРИРОВАНИЕ ИНФОРМАЦИОННО ВЫЧИСЛИТЕЛЬНЫХ СЕТЕЙ
МИНИСТЕРСТВО ОБРАЗОВАНИЯ РФ ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
Н.Т. Кустов
АДМИНИСТРИРОВАНИЕ ИНФОРМАЦИОННО-ВЫЧИСЛИТЕЛЬНЫХ СЕТЕЙ Учебное пособие
Томск 2004
УДК 681.3 (075.8) ББК 32.97 С918 С 918 Кустов Н.Т. Администрирование информационновычислительных сетей: Учебное пособие. – Томск: Томский государственный университет, 2004. – 247 с.
В книге излагаются основные принципы построения современных аппаратных, коммуникационных и программных средств, составляющих информационно-вычислительную сеть, а также основные понятия администрирования сетей. В примерах рассматриваются конкретные операционные системы и их составляющие компоненты. Даются рекомендации для построения сетей в средних и крупных организациях. Для начинающих администраторов, а также для широкого круга читателей, желающих расширить свой кругозор. УДК 681.3 (075.8) ББК 32.97
© Томский государственный университет, 2004 © Кустов Н.Т., 2004
СОДЕРЖАНИЕ СПИСОК СОКРАЩЕНИЙ.................................................................... 6 ПРЕДИСЛОВИЕ .................................................................................... 8 ВВЕДЕНИЕ........................................................................................... 10 Основные понятия................................................................................ 10 Функции администратора ИВС........................................................... 12 Г Л А В А 1 . СОСТАВНЫЕ ЧАСТИ ИНФОРМАЦИОННОВЫЧИСЛИТЕЛЬНОЙ СЕТИ .............................................................. 14 1.1. Аппаратное обеспечение .............................................................. 14 1.1.1. Вычислительные установки ...................................................... 14 1.1.2. Кабельное оборудование ........................................................... 17 1.1.3. Канало- и сетеобразующее оборудование ............................... 19 1.1.4. Периферийное оборудование.................................................... 22 1.1.5. Дополнительное оборудование................................................. 23 1.2. Программное обеспечение ........................................................... 25 1.2.1. КЛАССИФИКАЦИЯ ПО........................................................... 26 1.2.2. Уровни современного программного обеспечения................. 28 1.2.3. Модели вычислений, реализуемые в программном обеспечении ............................................................................... 29 Вопросы и задания ............................................................................... 30 Г Л А В А 2 . ОПЕРАЦИОННАЯ СИСТЕМА ...................................... 31 2.1. Общие вопросы ............................................................................. 31 2.1.1. Определение операционной системы и основные понятия.... 31 2.1.2. Составные части ......................................................................... 32 2.1.3. Сетевое программное обеспечение........................................... 33 2.1.4. Классификация ОС..................................................................... 35 2.2. Серверная ОС ................................................................................ 36 2.2.1. Требования к серверной ОС ...................................................... 36 2.2.2. Функции серверной ОС ............................................................. 37 2.2.3. Службы серверной ОС............................................................... 38 2.2.4. Дополнительное ПО, расширяющее функции основных служб ОС ...................................................................................... 44 2.2.5. Выводы и перспективы развития серверных ОС .................... 45 2.2.6. Функции администратора серверной ОС................................. 46 2.3. Novell NetWare............................................................................... 48 2.3.1. Общие вопросы .......................................................................... 48 2.3.2. Файловая система NetWare ....................................................... 54 2.3.3. Сеть на основе NetWare и служба справочника NDS ............. 62
3
2.3.4. Служба безопасности ................................................................. 72 2.3.5. Установка NetWare..................................................................... 78 2.3.6. Средства администрирования NetWare.................................... 82 2.3.7. Подключение пользователей к сети NetWare .......................... 85 2.4. Microsoft Windows NT Server ....................................................... 92 2.4.1. Общие вопросы .......................................................................... 92 2.4.2. Файловая система NTFS .......................................................... 103 2.4.3. Сеть Microsoft Network и служба справочника Windows NT................................................................................ 107 2.4.4. Служба безопасности ............................................................... 114 2.4.5. Установка Windows NT Server ................................................ 122 2.4.6. Средства администрирования Windows NT........................... 125 2.4.7. Подключение пользователей к сети на основе Windows NT................................................................................ 128 2.5. Клиентская ОС............................................................................. 132 2.5.1. Требования к клиентской ОС .................................................. 132 2.5.2. Функции администратора клиентской ОС............................. 132 2.6. Microsoft Windows NT Workstation............................................ 133 2.6.1. Архитектура компонент сетевого ПО .................................... 133 2.6.2. Установка сетевого ПО............................................................ 135 2.6.3. Рабочая среда пользователя .................................................... 136 2.7. Microsoft Windows 95.................................................................. 138 2.7.1. История и версии ОС Windows 95.......................................... 138 2.7.2. Архитектура Windows 95......................................................... 139 2.7.3.Системный реестр ..................................................................... 142 2.7.4. Архитектура компонентов сетевого ПО ................................ 142 2.7.5. Профили пользователей........................................................... 143 2.8. Сравнение ОС Windows 9x и Windows NT Workstation .......... 143 Вопросы и задания ............................................................................. 146 Г Л А В А 3 . СИСТЕМА УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ ..... 148 3.1. Общие вопросы ........................................................................... 148 3.1.1. История СУБД с архитектурой «клиент-сервер» .................. 148 3.1.2. Требования к современной СУБД .......................................... 149 3.1.3. Функции администратора СУБД ............................................ 150 3.1.4. Основные понятия.................................................................... 151 3.1.5. Перспективы развития СУБД.................................................. 153
4
3.2. СУБД Oracle................................................................................. 154 3.2.1. Составные части СУБД Oracle ................................................ 154 3.2.2. Установка и настройка............................................................ 162 3.2.3. Служба безопасности и аутентификации............................... 169 3.2.4. Обеспечение надежности......................................................... 175 Вопросы и задания ............................................................................. 180 Г Л А В А 4 . ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ДЛЯ ГРУППОВОЙ РАБОТЫ ....................................... 181 4.1. Общие вопросы ........................................................................... 181 4.1.1. Определение ПО для групповой работы................................ 181 4.1.2. Функции ПО для групповой работы....................................... 182 4.1.3. Требования к ПО групповой работы ...................................... 183 4.1.4. Составные части ....................................................................... 183 4.1.5. Выводы...................................................................................... 188 4.2. Пакет групповой работы Lotus Domino/Notes .......................... 191 4.2.1. История и версии пакета.......................................................... 191 4.2.2. Основные компоненты и функциональные возможности, не зависящие от версии ............................................................. 193 4.2.3. Построение сети на основе Lotus Notes ................................. 194 4.2.4. Служба справочника ................................................................ 197 4.2.5. Основные БД для администрирования................................... 201 4.2.6. Система безопасности.............................................................. 208 4.2.7. Репликация в Lotus Notes......................................................... 217 4.2.8. Электронная почта Lotus Notes ............................................... 223 4.2.9. Установка пакета Lotus Notes.................................................. 231 4.2.10. Настройка пакета Lotus Notes ............................................... 238 4.2.11. Функции администратора Lotus Notes. Основные инструменты для администрирования .................................. 243 Вопросы и задания ............................................................................. 246 ПОСЛЕСЛОВИЕ ................................................................................ 247 ЛИТЕРАТУРА .................................................................................... 248
5
СПИСОК СОКРАЩЕНИЙ БД – база данных ВУ – вычислительная установка СУБД – система управления базами данных ИВС – информационно-вычислительная сеть ЭВМ – электронно-вычислительная машина ЛВС – локальная вычислительная сеть ГВС – глобальная вычислительная сеть ЦП – центральный процессор ВЛВС – виртуальная ЛВС ОС – операционная система ОЗУ – оперативное запоминающее устройство (оперативная память) СОС – серверная операционная система КОС – клиентская операционная система МО – магнито-оптика ПО – программное обеспечение ИБП – источник бесперебойного питания ОАК – общая адресная книга ACL – Access Control List (список управления доступом) ACE – Access Control Entry (запись управления доступом) IRF – Inherited Rights Filter (фильтр унаследованных прав) ECC – Enhanced Correction Code (улучшенный код коррекции) ER – Entity–Relationship (сущность–связь) FAT – File Allocation Table (таблица размещения файлов) NTFS – New Technology File System (файловая система NT) RAID – Redundant Array of Independent Disks (массив независимых резервных дисков) SCSI – Small Computer Systems Interface (системный интерфейс малых компьютеров) SMP – Symmetric MultiProcessing (симметричная многопроцессорная обработка) API – Application Programming Interface (программный интерфейс приложений) OSI – Open Systems Interface (интерфейс открытых систем) LDAP – Lightweight Directory Access Protocol (облегченный протокол доступа к справочнику) NCP – Netware Core Protocol (протокол ядра Netware) SMB – Server Message Block (блок сообщений сервера)
6
SAM – Security Account Manager (менеджер бюджетов безопасности) SID – System Identifier (идентификатор системы) или Security Identifier (идентификатор безопасности) SNMP (Simple Network Management Protocol) – простой протокол сетевого управления UNC – Universal Name Conversion (универсальное преобразование имен) NDS – Novell Directory Services (служба справочника Novell) SQL – Structured Query Language (структурированный язык запросов) TNS – Transparent Network Specification (спецификация «прозрачной» сети) IDE – Integrated Development Environment (интегрированная среда разработки) GUI – Graphical User Interface (графический интерфейс пользователя) MTA – Mail Transfer Agent (агент передачи почты) SMTP – Simple Message Transfer Protocol (простой протокол передачи сообщений)
7
Моему сыну Сергею … ПРЕДИСЛОВИЕ Книга «Администрирование информационно-вычислительных сетей» составлена на основе одноименного курса лекций, который читается автором в течение трех лет на факультете информатики Томского государственного университета. Курс лекций предназначен для знакомства студентов с основными понятиями, использующимися при обслуживании и администрировании современных информационно-вычислительных сетей (далее «ИВС»), изучения основных принципов организации ИВС, а также для приобретения основных навыков администрирования ИВС. В рамках курса подробно рассматриваются основные программные компоненты современной ИВС: серверная и клиентская операционные системы, система управления базами данных, почтовая система и программное обеспечение для коллективной работы, их составные части, функции и особенности администрирования. Отдельный раздел курса посвящен рассмотрению аппаратного обеспечения ИВС: вычислительных установок, периферийного, кабельного, сетевого и дополнительного оборудования. Основной целью книги является обобщение и систематизация понятий, использующихся в практике администрирования ИВС, а также представление практических навыков администрирования ИВС на примерах реально использующихся при построении ИВС программных продуктов. При выборе программных продуктов для изучения в качестве примеров были учтены: продолжительность присутствия и распространенность программного продукта на рынке программного обеспечения, наглядность представления основных функций по управлению ресурсами ИВС, доступность продукта для практического изучения. В книге рассматриваются, прежде всего, вопросы администрирования ИВС среднего масштаба одной организации или предприятия. Рассмотрение таких вопросов, как взаимодействие ИВС нескольких предприятий, взаимодействие с глобальной сетью Internet и защита ИВС предприятия от доступа извне, а также администрирование территориально распределенной ИВС, осталось за рамками данной книги. Книга предполагает наличие у читателя некоторых навыков работы в ИВС, включая сети на основе ОС Novell NetWare и сети
8
Microsoft Network, а также представления об архитектурах построения вычислительных сетей, включая модель OSI, и архитектуре вычислительных установок, включая архитектуру фон Неймана. В первой главе книги рассматриваются основные понятия, использующиеся в практике администрирования ИВС, а также функции администратора ИВС. Во второй главе рассматриваются составные части ИВС: аппаратное и программное обеспечение ИВС. Подробно рассматриваются вычислительные установки: серверы и рабочие станции, требования к современным серверам и рабочим станциям; кабельное и сетеобразующее оборудование, без которого невозможно представить себе современную ИВС, а также периферийное и дополнительное оборудование. Дана классификация программного обеспечения, представлены уровни современного программного обеспечения и модели вычислений, реализуемые в современном ПО. В третьей главе рассматривается операционная система, дана классификация операционных систем. Отдельно рассматриваются вопросы администрирования операционных систем на примере серверных ОС Novell NetWare и Microsoft Windows NT Server и клиентских ОС Windows 95 и Windows NT Workstation. В четвертой главе рассматривается система управления базами данных и вопросы администрирования современной СУБД. Современная СУБД рассматривается на примере реляционной СУБД Oracle, реализованной в архитектуре «клиент-сервер». В пятой главе представлены программное обеспечение для групповой работы и почтовая система, как составная часть ПО для групповой работы. ПО для групповой работы рассматривается на примере пакета Lotus Domino/Notes. Автор выражает большую признательность декану факультета информатики ТГУ Б.А. Гладких, заведующему кафедрой прикладной информатики факультета информатики С.П. Сущенко и заведующему кафедрой теоретических основ информатики факультета информатики Ю.Л. Костюку за ценные советы по оформлению книги, замечания по содержанию книги и помощь в ее издании. Огромное спасибо моей жене Елене, вдохновлявшей меня и терпеливо переносившей мою занятость написанием книги, ее радактированием и оформлением.
9
ВВЕДЕНИЕ В связи с повсеместным распространением вычислительной техники и информационно-вычислительных сетей, их активным использованием на производстве, в бизнесе, а также для личных нужд, пользователям необходимо иметь представление об основных понятиях, имеющих отношение к данной сфере жизнедеятельности. На производстве и в бизнесе большое значение приобретают задачи по совместному использованию информационно-вычислительных ресурсов, разграничению доступа и управлению такими ресурсами. Основные понятия Информационно-вычислительная сеть (ИВС) – комплекс программных и аппаратных средств для обеспечения автоматизации производства и других сфер жизнедеятельности человека, включающий в качестве составной части кабельное и сетеобразующее оборудование. Администратор ИВС (Administrator) – должностное лицо, ответственное за работоспособность и надлежащее функционирование всех частей ИВС. У администратора большой ИВС в подчинении могут находиться администраторы частей и подсистем ИВС – например администратор локально-вычислительной сети, администратор сетевой ОС, администратор БД, а также технический персонал. Администратор подсистемы ИВС отвечает за работоспособность и надлежащее функционирование вверенных ему компонентов этой подсистемы ИВС. Пользователь ИВС (User) – физическое лицо, имеющее доступ к определенным ресурсам ИВС, идентифицируемое бюджетом пользователя (учетной записью). Администратор ИВС также является пользователем ИВС, обладая, в общем случае, неограниченным доступом ко всем ресурсам ИВС. Бюджет / учетная запись пользователя (Account) – запись в специализированной БД (БД учетных записей), содержащая информацию о пользователе ИВС. Используется для идентификации пользователя в системе, проверки полномочий пользователя и обеспечения доступа пользователя к тем или иным ресурсам системы. Характеризуется атрибутами, например имя для входа, пароль, профиль в системе, список принадлежности к группам и т.п. Пароль служит для защиты бюджета от несанкционированного использования.
10
Регистрация пользователя в системе (Registration) – создание администратором ИВС (или другим уполномоченным лицом) бюджета пользователя для данного физического лица. Аутентификация в системе (Authentication) – процесс установления подлинности пользователя ИВС. Заключается в предъявлении пользователем своего имени для входа и пароля, а также в проверке системой наличия бюджета в БД бюджетов пользователей и соответствия указанного пользователем пароля и пароля, хранящегося в БД. После успешной аутентификации в системе для пользователя на время сеанса работы создается маркер безопасности, отражающий его цифровой идентификатор в системе, а также его принадлежность группам пользователей, профилям и другим объектам системы безопасности. Ресурсы ИВС (Resources) – физические и логические объекты ИВС, имеющие определенную функциональность, доступную для использования. Примеры физических ресурсов – сервер ЛВС, каталог совместного использования на сервере, сетевой принтер; логических ресурсов – пользователь, группа пользователей, профиль в системе, очередь на печать и т.п. Права доступа к ресурсу (Access rights to the resource) – степень свободы действий пользователя (просмотр, использование, владение) по отношению к данному ресурсу. Имеют специфику применительно к разным ресурсам и подсистемам ИВС (создание/чтение/запись/удаление файлов и каталогов – для файловой службы; создание/печать документов/управление очередью на печать – для службы печати и т.д.). По определению, администратор ИВС имеет полные права на все ресурсы ИВС. Администратор части ИВС – полные права на ресурсы части ИВС. Права доступа напрямую связаны с ответственностью пользователя, которую он несет, пользуясь этими правами. Назначение прав доступа к ресурсу (User’s rights assignment) – процедура создания в системе специальной записи, с помощью которой учетной записи пользователя или ее аналогу (например, учетной записи группы пользователей) присваиваются определенные права доступа к ресурсу. Назначение прав доступа в современных информационно-вычислительных системах осуществляется через списки управления доступом (Access Control List / ACL).
11
Список управления доступом (Access Control List / ACL) – в виде отдельных записей хранит информацию о том, кто обладает правами на ресурс и каковы эти права. Например, для одного пользователя в ACL каталога файловой системы могут быть указаны права на чтение, а для другого пользователя – права на чтение и запись. Авторизация / Проверка прав доступа (Authorization / Rights verification) – процесс установления системой соответствия запрошенных прав доступа к ресурсу и фактических прав пользователя на ресурс и формирования управляемой реакции: разрешить или отвергнуть доступ пользователя к ресурсу. Например, пользователь выполняет операцию открытия файла на запись (запрашиваемые права), обладая при этом только правом просмотра (фактические права). Система запретит выполнение операции, мотивируя свое поведение недостатком прав у пользователя. Аудит / Контроль использования ресурсов (Audit) – процесс контроля использования ресурсов, включающий возможность ведения журнала попыток доступа к ресурсам. Журнал аудита ведется на основе данных, поступающих от процедур авторизации. Совместное использование ресурса (Resource sharing) – использование ресурса двумя и более пользователями ИВС. Функции администратора ИВС Администратор ИВС обеспечивает надлежащую работоспособность ИВС, выполняя определенные функции (или должностные обязанности). К основным функциям администратора относятся: Управление учетными записями пользователей. Включает регистрацию пользователей, контроль использования учетных записей, задание ограничений на использование учетных записей, блокирование временно не использующихся учетных записей, удаление учетных записей. Управление доступом к ресурсам. Включает создание логических и регистрацию физических ресурсов ИВС, обеспечение управляемого доступа к ресурсам с помощью списков управления доступом, контроль использования ресурсов. Обеспечение сохранности, секретности и актуальности данных. Включает создание и поддержание нужного количества резервных копий, восстановление при необходимости данных, защиту данных от несанкционированного доступа (путем установки соответствующих прав доступа), своевременное обновление данных.
12
Установка и сопровождение программного и аппаратного обеспечения. Включает установку ОС на серверах и рабочих станциях ИВС, установку серверного и клиентского ПО, установку дополнительного аппаратного обеспечения; настройку и контроль работоспособности программного и аппаратного обеспечения. Функции администратора части ИВС повторяют функции администратора ИВС применительно к определенной части ИВС и рассматриваются в соответствующих разделах книги. «Золотые» правила администратора: 1. Никогда не проводи экспериментов на работающей системе. Если это все-таки необходимо, сделай сначала полную резервную копию данных. 2. Никогда не меняй конфигурацию сервера (как аппаратную, так и программную), не сделав предварительно полную резервную копию данных. 3. Всегда документируй свои действия в журнале администратора. Если это возможно, пользуйся встроенными в серверные ОС средствами аудита и журналирования. 4. Если можно переложить часть работы на подчиненного, сделай это. Но если ты не уверен, что подчиненный справится с заданием должным образом, сделай это сам. 5. Всегда соотноси назначаемые права с мерой ответственности, связанной с теми или иными правами, т.е. пользователь, имеющий больше прав, берет на себя больше ответственности. Вывод: администратор должен обладать полными правами на вверенную ему систему. 6. При работе с ресурсами ИВС в качестве пользователя (редактирование документов, просмотр и отправка почтовых сообщений, разработка ПО и т. п.) используй учетную запись с обычными правами доступа, а не учетную запись администратора. 7. Регулярно меняй пароль учетной записи администратора. Но не полагайся на свою память – записывай пароль на бумаге и храни в месте с ограниченным доступом посторонних лиц (сейф, от которого ключи только у тебя и, может быть, твоего прямого начальника). Правила названы «золотыми», потому что невыполнение этих правил может дорого обойтись как администратору ИВС, так и предприятию, на котором он работает (прямые финансовые потери от простоев, разглашения «коммерческой тайны» и т.п.).
13
Г л а в а 1 . СОСТАВНЫЕ ЧАСТИ ИНФОРМАЦИОННО-ВЫЧИСЛИТЕЛЬНОЙ СЕТИ 1.1. Аппаратное обеспечение Аппаратное обеспечение является основой ИВС и определяет вычислительную мощность ИВС в целом. Все аппаратное обеспечение можно разделить на вычислительные установки, кабельное, канало- и сетеобразующее, периферийное и дополнительное оборудование. 1.1.1. Вычислительные установки
Вычислительные установки (далее ВУ) служат для выполнения основных вычислительных задач, т.е. задач по хранению и обработке информации. Вычислительные установки можно разделить на две большие группы: серверы и рабочие станции. Серверы Сервер (Server) – это вычислительная установка, которая служит преимущественно для совместного использования его информационно-вычислительных ресурсов, к которым относятся, прежде всего, центральный процессор или процессоры (например, если это SMP-система), оперативная и внешняя память (прежде всего, жесткие диски). Основные требования к современному серверу: Масштабируемость (Scalability) – возможность наращивания мощности ВУ (количество и быстродействие процессоров, объем оперативной и внешней памяти) для пропорционального увеличения скорости и плотности (определенное количество запросов в единицу времени) обработки запросов, а также объемов хранимой информации. Отказоустойчивость (Intolerance) – возможность системы полностью восстанавливать свою работоспособность при аппаратных сбоях и высокая доступность (High Level of Availability) – возможность системы продолжать обслуживание запросов при аппаратных сбоях. Обеспечивается дублированием (Duplexing) основных аппа-
14
ратных компонентов ВУ, чаще всего выходящих из строя (обычно имеющих механические части): источников питания; вентиляторов; жестких дисков, а также избыточностью (Redundancy) хранящейся информации. Управляемость (Manageability) – возможность удаленного управления, сбора сведений о работе подсистем сервера. Обеспечивается специальными программно-аппаратными комплексами, разрабатываемыми и поставляемыми производителями серверов (Compaq Insite Manager, Digital ServerWorks, IBM NetFinity). Технологии и компоненты для обеспечения отказоустойчивости Для обеспечения отказоустойчивости и высокой доступности в современных серверах используются следующие технологии и компоненты: Горячая замена компонент (Hot Swapping) – позволяет менять компоненты аппаратного обеспечения, не отключая электропитания от ВУ. Есть решения для жестких дисков, источников питания, вентиляторов и плат расширения. ОЗУ с хранением избыточной информации: память с паритетом (Parity Checking) – обеспечивается обнаружение однократных ошибок в ОЗУ; ECC-память (Enhanced Correction Code – улучшенный код коррекции), обеспечивается исправление однократных ошибок и обнаружение двукратных ошибок в ОЗУ. Массивы независимых резервных дисков (Redundant Array of Independent Disks / RAID). Применяются как в корпоративных серверах, так и серверах масштаба рабочей группы для обеспечения отказоустойчивости внешней памяти. Классификация по способу исполнения: Аппаратный RAID. Существует две реализации: 1) в виде хост-адаптера – вместо SCSI-адаптера шина со SCSIдисками подключается к RAID-адаптеру; 2) SCSI-to-SCSI – такой RAID является обычным SCSIустройством с точки зрения SCSI-адаптера, при этом можно организовать более емкую внешнюю память, являющуюся отказоустойчивой. Программный RAID. Реализуется системным ПО на уровне ядра ОС.
15
Классификация по принципу функционирования: RAID0 – разделение; RAID1 – зеркалирование (дублирование) данных; RAID3 – разделение данных с избыточностью (с выделенным диском четности); RAID5 – разделение данных с избыточностью (с равноправными дисками, т.е. информация о четности размыта по дискам). Кластерные технологии (Clustering). Кластер – это объединение двух и более ВУ (точнее, пары «процессор+оперативная память»), называемых узлами кластера, для работы с общей внешней памятью. При выходе из строя одного из узлов кластера, остальные узлы кластера берут на себя нагрузку по обслуживанию клиентских подключений. Для клиентов кластер выглядит как один узел сети. Типичный сервер масштаба предприятия: 1) архитектура RISC (Sparc, Alpha, PowerPC, Pentium Pro, Pentium II Xeon, Pentium III Xeon). 2) поддержка симметричной многопроцессорности (Symmetric MultiProcessing / SMP) – 2 и более процессоров. 3) 128 и более Мб ECC -памяти. 4) 36 и более Гб внешней памяти с возможностью горячей замены, объединенных в RAID-массив. 5) высокоскоростная системная шина и шина данных (на частоте 100МГц и выше). 6) высокоскоростной интерфейс с сетью (технологии FDDI, FastEthernet, ATM) с использованием специализированных адаптеров (резервный порт, дополнительная память, интеллектуальный процессор). Рабочие станции Рабочая станция (Workstation) – это вычислительная установка, которая преимущественно используется как индивидуальное рабочее место пользователя ИВС и служит точкой входа в ИВС. Основные требования к рабочей станции: Удобство работы (Convenience) – обеспечивается прежде всего установкой и поддержкой высокоскоростной графической подсистемой ввода/вывода (графическая плата, монитор, мышь).
16
Управляемость (Managability) – обеспечивается ПО, разрабатываемым и поставляемым производителями рабочих станций, а также независимыми производителями (Intel LANDesk ClientManager, Digital ClientWorks). Типичная рабочая станция: 1) архитектура PC (Pentium, Pentium Pro, Pentium II) или архитектура Mac(PowerPC). 2) 64 и более Мб оперативной памяти. 3) 4 и более Гб внешней памяти. 4) высокоскоростная системная шина, шина данных и шина графического порта (PCI, AGP). 5) 4 и более Мб памяти на графической плате. 6) Высокоскоростной интерфейс с сетью (Ethernet, FastEthernet, ATM). 7) 15”или 17” – монитор. Помимо общеизвестного стандарта на рабочие станции Personal Computer (PC), впервые предложенного компанией IBM и альтернативного стандарта Macintosh, предложенного компанией Apple, сегодня появились новые спецификации: NetPC и Network Computer. Основной целью выдвижения этих спецификаций явилось желание упростить сопровождение рабочих станций ИВС и реализовать сетецентрический подход в организации ИВС и управлении ресурсами ИВС. Новые спецификации призваны также стандартизовать функции удаленной загрузки, удаленного запуска, установки и настройки компонент программного обеспечения. 1.1.2. Кабельное оборудование
Совместное использование ресурсов ИВС подразумевает прежде всего физическую связанность этих ресурсов. Кабельное оборудование (или кабельная система) представляет собой те самые «веревки», которые связывают воедино разрозненные ВУ и другое оборудование ИВС (см. далее). Кабельное оборудование представлено кабелями различных типов, а также специальными розетками и вилками для подключения кабельных сегментов друг к другу и к сетевому оборудованию.
17
Распространенные типы кабелей: Коаксиальный кабель (Coaxial Cable) – представляет собой изолированную медную жилу, помещенную в медную оплетку, покрытую гибкой изоляционной оболочкой. Используется для построения сети по топологии «шина». Для согласования используются резисторы в виде «терминаторов». В частности, для сетей на базе технологии Ethernet применяются терминаторы с сопротивлением 50 Ом. С коаксиальным кабелем используются специализированные T-коннекторы для стыковки сегментов кабельной системы и подключения к ВУ. Достоинства: наружная оплетка должна быть хорошо заземлена, разрыв любой части сетевого кабеля приводит к выходу из строя всего сегмента сети. Недостатки: простота и дешевизна развертывания (не требуется коммутационное оборудование). Кабель на основе «витых пар» (Twisted Pairs Cable) – представляет собой изолированные медные провода, попарно скрученные и заключенные в гибкую оболочку. Существует неизолированный (UTP) и изолированный (STP) варианты данного типа кабеля. В последнем случае скрученные пары проводов заключаются в медную оплетку, которая заземляется. Характеризуется так называемой категорией, в частности, для сетей на базе технологии Ethernet допускается использование кабеля категории 3 и выше. С кабелем данного типа используются вилки и розетки стандарта RJ-45. Используется для построения сети по топологии «звезда». Чаще всего применяется для подключения ВУ к коммутационному оборудованию, а также для каскадного соединения элементов коммутационного оборудо-вания. Достоинства: повышенная защищенность, не требует заземления кабеля (справедливо для UTP), простота локализации неполадок в сети, легкость наращивания без остановки работы сети. Недостатки: большие расходы кабеля, дополнительные расходы на коммутационное оборудование. Оптоволоконный кабель (Fiber Optical Cable) – представляет собой стеклянную жилу – «световод», заключенную в гибкую оболочку. Используется для построения сети по топологии «точка-точка». Применяется для построения магистралей, т.е. создания каналов
18
связи между удаленными частями сети, а также для подключения серверов. Существуют две разновидности данного кабеля: – многомодовый оптоволоконный кабель – допускается передача нескольких пучков света – «мод» – по одному световоду, при этом обеспечивается дальность связи до 2 км; – одномодовый оптоволоконный кабель – вследствие меньшего диаметра световода возможна передача только одного пучка света, при этом обеспечивается дальность связи до 80 км (теоретически возможная). Достоинства: повышенная защищенность, не требуется заземление кабеля, способность обеспечивать связь на больших расстояниях. Недостатки: сложность прокладки и монтажа, дорогое оконечное оборудование (см. далее). 1.1.3. Канало- и сетеобразующее оборудование
Канало- и сетеобразующее оборудование (или просто «сетевое оборудование») – это оборудование для сопряжения кабельной системы ИВС с ВУ, а также различных частей кабельной системы. Каналообразующее оборудование обеспечивает функции канального уровня модели OSI для организации сети, а сетеобразующее – функции канального и сетевого уровня модели OSI. Сетевое оборудование можно разделить на две группы: Оконечное оборудование. К оконечному оборудованию относятся сетевые платы и модемы, которые устанавливаются в ВУ и обеспечивают подключение ВУ к сети. Коммутационное оборудование. К коммутационному оборудованию относятся концентраторы, мосты и коммутаторы, маршрутизаторы, которые служат для связи частей кабельной системы в единую сетевую инфраструктуру. Оконечное оборудование Рассмотрим далее каждый вид оконечного сетевого оборудования отдельно: Сетевая плата (Network Interface Card) – служит для поключения отдельно стоящей ВУ к ЛВС. Различают сетевые платы по типу реализуемой технологии передачи данных: Ethernet, FastEthernet,
19
Token-Ring и т.д.; по типу поддерживаемого слота расширения: ISA, EISA, MicroChannel, PCI; по типу поддерживаемого кабеля: TP, Coax, Combo (TP&Coax). Модем (Modem) – служит для подключения отдельно стоящей ВУ к ГВС. Различают модемы по типу генерируемого сигнала: аналоговые (Analog), цифровые (ISDN, xDSL); по типу используемой среды передачи: кабельные модемы и радиомодемы; по типу поддерживаемых стандартов: V.90, V.34, V.32, V.22 и т.д.; по варианту исполнения: внутренние (устанавливаются в слот расширения и имеют встроенный последовательный порт) и внешние (подключаются к имеющемуся последовательному порту ВУ). Коммутационное оборудование Рассмотрим далее каждый вид коммутационного сетевого оборудования отдельно: Концентратор служит для: 1) регенерации принимаемых пакетов; 2) отсеивания искаженных кадров; 3) согласования сегментов сети с использованием разных типов кабелей; 4) автоматического разделения зацикливаний в сегменте путем отключения портов; 5) разделения на домены коллизий узлов сети (для коммутирующих концентраторов). Концентраторы различаются по типу поддерживаемой технологии передачи данных: Ethernet, FastEthernet, Token-Ring, а также характеризуются количеством имеющихся портов, т.е. гнезд для подключения кабельных сегментов. Концентраторы относятся к каналообразующему оборудованию. Мост/коммутатор служит для: 1) обеспечения согласования разных технологий передачи данных (Ethernet/FastEthernet); 2) создания переключаемых каналов между узлами/сегментами сети (только для коммутаторов); 3) организации виртуальных ЛВС (только для коммутаторов). ВЛВС создаются для защиты портов коммутатора от широковещательных сообщений (порты одной ВЛВС не видят порты другой
20
ВЛВС при отсутствии маршрута между этими ВЛВС, обеспечиваемого маршрутизатором). Мосты и коммутаторы также относятся к каналообразующему оборудованию. (!)
Суммарный объем трафика не может превысить пропускной способности коммутатора.
Проблема потери коммутатором пакетов связана с коллизиями на выходном порту коммутатора. Существует несколько правил, решающих проблему потери пакетов: 1) Для сглаживания трафика на входящих портах необходимо использовать буферную память, которая будет сглаживать восходящие пики входящего трафика. В насыщенных сетях рекомендуется использовать коммутаторы с настраиваемой буферной памятью большого объема. 2) Некоторые коммутаторы могут предупреждать потерю пакетов, включая механизм создания искусственных коллизий на портах, создающих львиную долю трафика. Данная технология работает только для сетей Ethernet. 3) При организации сети на базе коммутаторов необходимо следить, чтобы «выходные порты» имели пропускную способность с запасом (100Mb – в магистраль против 10Mb для портов-клиентов; 1Гб – магистраль против 100Mb для портов-клиентов). Маршрутизатор – обеспечивает физическую связь нескольких ЛВС и маршрутизацию пакетов между ЛВС, а также поддержку различных технологий и топологий организации сети. Маршрутизаторы относятся к сетеобразующему оборудованию. (!)
Возможности большинства современных коммутаторов и маршрутизаторов ограничиваются ПРОПУСКНОЙ СПОСОБНОСТЬЮ самой сети.
Если для связи аппаратного обеспечения ИВС используются модемы и маршрутизаторы, и компоненты ИВС разнесены в пространстве, то комплекс аппаратных средств ИВС будем называть глобальной вычислительной сетью (ГВС), в противном случае – локальной вычислительной сетью (ЛВС).
21
1.1.4. Периферийное оборудование
Периферийное оборудование – это оборудование, расширяющее функциональные возможности ВУ (прежде всего функциями ввода/вывода). Периферийное оборудование подключается прямо к ВУ посредством специализированных интерфейсов, либо посредством канало- и сетеобразующего оборудования. Включает мониторы, клавиатуры, мыши, принтеры, сканеры, дисковые массивы и т. п. Монитор – устройство для вывода (отображения) информации в реальном масштабе времени. Принтер – устройства для вывода информации путем создания твердых (бумажных) копий электронных документов. Последнее время наметилась тенденция использовать сетевые принтеры – принтеры, напрямую подключенные к сети, а не через порт ВУ. Клавиатура и мышь – традиционные устройства для ввода информации с использованием графического интерфейса ОС. Сканер – устройство для ввода информации с документов методом анализа и распознавания. Примеры специализированных интерфейсов: PC-Video, Mac-Video, AT-Keyboard, PS/2 Keyboard, RS-232C (через последовательный порт), Centronix (через параллельный порт), PS/2 Mouse, USB, SCSI. Специализированные серверы Для совместного использования некоторых категорий периферийного оборудования (прежде всего, принтеров), а также некоторых специфических ресурсов (внешняя память на CD-ROM), разрабатываются ВУ, ориентированные на обслуживание указанных функций. Такие ВУ называются специализированными серверами. В специализированных серверах применяется встроенное ПО (в том числе, встроенные ОС), обеспечивающее реализацию соответствующих функций. Примеры специализированных серверов: Сервер CD-ROM или дисковый массив – ВУ, к которой подключено большое количество накопителей CD-ROM или обычных жестких дисков. Используется как хранилище справочной и другой информации. Совместимы со службами совместного использования ресурсов файловой системы сетей NetWare и Microsoft Network.
22
Cервер печати – ВУ, в которую на микропрограммном уровне встроена поддержка функции сервиса печати, совместимого с Novell Netware, Windows NT/LAN Manager или UNIX LPR/LPD. Такой подход разгружает универсальный сервер рабочей группы или предприятия, а также значительно увеличивает производительность сервиса печати. Факс-сервер – функции отправки и приема факсимильных сообщений встраиваются на микропрограммном уровне в ВУ и обеспечивается доступ к данному сервису с любой рабочей станции сети. Иногда интегрируется с сервером печати. 1.1.5. Дополнительное оборудование
Дополнительное оборудование – оборудование, необходимое для более эффективной и надежной работы основного оборудования ИВС. Включает прежде всего источники бесперебойного питания (далее ИБП), а также анализаторы сети, датчики состояния окружающей среды и т.п. Источники бесперебойного питания Источник бесперебойного питания (ИБП, UPS) – устройство, которое обеспечивает в течение некоторого времени бесперебойную работу основного оборудования сети в случае сбоев электропитания. Существуют два подхода к защите оборудования от неисправностей электропитания, предусматривающих использование ИБП: Централизованный подход – все компьютерное оборудование подключено к одному мощному ИБП, который постоянно работает и обеспечивает это оборудование электропитанием в течение достаточно продолжительного периода времени в случае сбоев. Подход на основе распределенной схемы защиты электропитания – каждый узел сети (рабочая станция, сервер, маршрутизатор и т.д.) подключается при необходимости к отдельному ИБП, который и обеспечивает некоторое время работу узла сети в случае сбоев в электропитании.
23
Классификация ИБП Любой ИБП с точки зрения преобразования входного электрического сигнала можно отнести к одному из следующих типов: On-line – считается, что только ИБП данного типа гарантируют защиту от всех нарушений в линиях силового питания. Подходят для зашумленных, ненадежных линий силового питания. Схема содержит два преобразователя. Первый превращает переменное нестабильное напряжение линии в постоянное, второй вырабатывает из постоянного напряжения, поступающего с выхода первого выпрямителя и с аккумуляторных батарей, переменное синусоидальное, которое непрерывно подается на нагрузку. Если параметры напряжения линии выходят за пределы допустимого, то первый преобразователь просто отключается и переход на полное питание от батарей происходит без всякой задержки. Достоинства: позволяет фильтровать помехи во всем частотном диапазоне, обеспечивает на выходе чистое синусоидальное напряжение с номинальными параметрами) Недоcтатки: за качество питания приходится платить повышенным выделением тепловой энергии, сложностью электрических схем и, как следствие, потенциальным снижением надежности и более высокой стоимостью. Off-line – выходное напряжение такого ИБП равно входному, если параметры питающей сети находятся в допустимых пределах. При выходе напряжения за допустимые пределы включается инвертор, преобразующий постоянное напряжение батарей в переменное. Время переключения – 4 мс, что вполне приемлемо, так как встроенные в ВУ импульсные источники питания допускают прерывание питающего напряжения не более чем на 40–50 мс. Источники питания ВУ также содержат шумовой фильтр, подавитель выбросов и стабилизатор напряжения, что допускает 15%-е отклонение входного напряжения от номинального. Рекомендуется использовать в электросетях с редкими сбоями преимущественно типа Blockout (полное пропадание электропитания). Line-interactive – занимает промежуточное положение между online и off-line ИБП. Содержит байпас – устройство, отвечающее за интеллектуальное переключение (среднее время переключения – 50 мкс) потребителей с входной линии на батареи путем постоянного анализа переменного напряжения на входе. Позволяет менять выходное напряжение в гораздо меньших пределах по сравнению с
24
большими перепадами входного за счет использования режимов SmartBoost и SmartTrim (терминология, использующаяся в ИБП компании APC). Рекомендуется использовать в электросетях с частыми и продолжительными отклонениями напряжения питания, например в промышленной зоне. Требования к ИБП серверных комнат: Наличие развитой системы оповещения – о нарушении работы в электросети система должна оповестить администратора всеми возможными способами: звуковым сигналом, предупреждением по локальной сети, вызовом на пейджер, автонабором номера телефона при установленном и подключенном к телефонной линии модеме; Управляемость – с любой рабочей станции сети с помощью программы клиента можно наблюдать за состоянием ИБП и получать от него сигналы предупреждения; дополнительно – поддержка ИБП простого протокола сетевого управления (Simple Network Management Protocol, SNMP). Поддержка нескольких серверов на один ИБП – мощные ИБП должны обладать возможностью подключения нескольких серверов и при сбоях питания обеспечивать корректное завершение работы ОС на всех ВУ. Масштабируемость – возможность увеличить мощность ИБП (обеспечивается за счет модульного строения как в APC Simmetra или MatrixUPS). Долговечность. Срок жизни современных ИБП составляет 10–15 лет, если своевременно выполнять операцию подзарядки батарей. Чтобы выполнить подзарядку батарей, нужно снять нагрузку с ИБП (выключить тумблер подключения нагрузки), оставив его физически подключенным к электросети в течение 16–24 ч (в зависимости от мощности батарей). 1.2. Программное обеспечение Программное обеспечение / Software (далее ПО) служит посредником между аппаратным обеспечением ИВС и пользователем ИВС при доступе последнего к ресурсам ИВС и выполнении различных информационно-вычислительных задач.
25
1.2.1. Классификация ПО Cовременное ПО можно разделить на некоторые группы, используя определенные критерии для классификации. Деление по функциональным возможностям: 1) Серверная операционная система (далее СОС) – хранится на дисках сервера и выполняется на процессоре(-ах) сервера, обслуживая другие информационно-вычислительные задачи (СУБД, почтовая система и т.д.). В зависимости от производителя и версии СОС обладает различной функциональностью и возможностями. Примеры: Novell NetWare, Microsoft Windows NT Server, IBM OS/2 LAN Server, SCO OpenServer. 2) Клиентская операционная система (далее КОС) – хранится на дисках рабочей станции (или на дисках сервера), выполняется на процессоре рабочей станции, обеспечивая пользователю ИВС базовый интерфейс (средство взаимодействия) для доступа к ресурсам ИВС. Также может обслуживать дополнительные задачи. В зависимости от производителя и версии КОС обладает различной функциональностью и возможностями. Примеры: MS DOS, Windows 95, Windows NT Workstation, OS/2 Warp Connect, Mac OS. 3) Система управления базами данных (далее СУБД) – служит для эффективного хранения и обработки большого объема упорядоченной определенным способом информации. На сегодняшний день чаще всего используются СУБД, поддерживающие реляционную модель хранения данных. Примеры: MS Access, FoxPro, Clarion, MS SQL Server, Oracle Server, Informix Universal Server, Interbase. 4) Почтовая система – служит для взаимодействия пользователей ИВС посредством самой ИВС, аналог обычной почты, реализованный в электронном виде. Система групповой работы (Groupware) – более совершенное средство взаимодействия пользователей, позволяет упорядочить и формализовать обмен сообщениями. Примеры почтовых систем: MS Mail, Lotus cc:Mail. Примеры систем групповой работы: MS Exchange, Novell GroupWise, Lotus Notes. 5) Средства обеспечения взаимодействия с Internet/Intranet – работа пользователей в ИВС на базе ГВС предполагает на сегодня работу в Internet – открытой информационно-вычислительной сети, охватывающей весь земной шар и имеющей миллионы пользователей. Intranet – ИВС предприятия, использующая средства Internet
26
для транспортировки своих информационных потоков между разбросанными по земному шару частями ИВС. Включают: 6) ПО для обеспечения прикладных сервисов – серверы WWW, FTP, SMTP/POP3 и т.п. Примеры: MS Internet Information Server, Lotus Domino, Netscape FastTrack Server. 7) ПО для получения доступа к прикладным сервисам – броузеры Интернет, FTP-клиенты, POP3-клиенты. Примеры: Microsoft Internet Explorer, Netscape Communicator. 8) ПО на границе ЛВС/ГВС для обеспечения безопасности корпоративных сетей – брандмауэры (Firewalls), прокси-серверы (Proxy), шлюзы (Gateways), туннели (Tunnels). Примеры: Firewall-1, Microsoft Proxy Server, WinProxy, Squid. 9) Средства сетевого и системного управления. Администратору большой ИВС требуется специальный инструментарий, позволяющий легко выполнять задачи по администрированию, сопровождению и управлению частями и компонентами ИВС. Примеры: HP OpenView, Novell ManageWise, CA-Unicenter TNG, MS Systems Management Server, Seagate BackupExec, APC PowerChute Plus. 10) Прикладное ПО – не связанное напрямую с ресурсами ИВС ПО. Служит для решения задач прикладной области: работа в офисе, автоматизация работы бухгалтерии, графическое макетирование и издательская деятельность и т.п. Примеры: MS Office, Lotus SmartSuite, 1С:Бухгалтерия, Adobe Illustrator. 11) Дополнительное ПО – ПО, облегчающее и делающее более удобной работу пользователей ИВС. Примеры: FAR, RAR, ZIP, Lotus Organizer, StarFish Dashboard. Деление ПО на системное и прикладное: Системное ПО – служит для выполнения задач по обслуживанию ИВС, прежде всего ее аппаратного обеспечения. К системному ПО относится большая часть программных компонент в составе ОС, а также различное ПО для обслуживания аппаратного обеспечения ИВС: ПО для резервного копирования, ПО для настройки сетевого оборудования и т.д. Прикладное ПО – служит для выполнения информационновычислительных задач, решаемых обычными пользователями ИВС. К прикладному ПО относятся СУБД, почтовая система, программные пакеты для работы в офисе и т.д.
27
Деление ПО по месту выполнения: Серверное ПО – выполняющееся как один и более процессов на ВУ, выполняющей роль сервера. Клиентское ПО – выполняющееся как один и более процессов на ВУ, выполняющей роль рабочей станции. Клиент-серверное ПО – распределенное ПО, выполняющееся как два и более процесса на двух и более ВУ (см. далее «Модели вычислений»). 1.2.2. Уровни современного программного обеспечения
Современное ПО не является монолитным и чаще всего строится по модульному принципу на основе уровневой архитектуры. В современном ПО можно выделить следующие основные уровни (или слои): 1) Уровень представления информации (уровень интерфейса с пользователем) – является передним краем приложения (FrontEnd), обращенным к пользователям; на этом уровне реализуется ввод информации для последующей обработки функциональными блоками и вывод обработанной информации. На сегодняшний день этот уровень чаще всего реализуется через функции программного интерфейса ОС, реализующие работу с примитивами графического интерфейса (например, Windows GDI API): окна, меню, панели инструментов, кнопки. 2) Уровень бизнес-правил (функциональный уровень) – является функциональной частью приложения и отвечает за проверку на допустимость, обработку и преобразование информации. На сегодняшний день налицо тенденция распределять слой бизнес-правил по нескольким ВУ. 3) Уровень именования и идентификации – отвечает за именование и идентификацию информационных ресурсов, а также аутентификацию пользователей в рамках программной системы. Данный уровень может использовать внешнюю службу именования и идентификации ресурсов и пользователей (например, службу справочника в составе серверной ОС). 4) Уровень безопасности – отвечает за разграничение прав доступа пользователей и проверку полномочий при доступе к информационным ресурсам через уровень представления. Данный уровень
28
тесно взаимодействует с уровнем именования и идентификации, поэтому также может использовать внешнюю службу для обеспечения безопасности. 5) Уровень оптимизации – выполняет анализ занятости вычислительных ресурсов и оптимально перераспределяет вычислительную и т.п. (см. выше рассмотренные уровни) нагрузку по доступным приложению ВУ. 6) Уровень хранения и извлечения информации – является базовой и наиболее удаленной от пользователей частью приложения, обращенной к ресурсам ВУ (BackEnd), обеспечивает эффективные структуры хранения введенной через приложение информации, а также алгоритмы извлечения информации для последующей обработки и отображения. Может использовать внешнюю СУБД либо самостоятельно реализовывать вышеуказанные структуры и алгоритмы (например, файловая система в составе ОС). 1.2.3. Модели вычислений, реализуемые в программном обеспечении
На сегодняшний день программное обеспечение разрабатывается на основе нескольких моделей вычислений в зависимости от места реализации тех или иных уровней приложения: Локализованная / централизованная модель вычислений – обработка и хранение данных осуществляется на одной ВУ. На основе этой модели реализуется большинство примеров современного прикладного ПО, некоторые почтовые системы и т.д. Недостатки: сильная зависимость от ВУ, плохая масштабируемость. Модель вычислений на основе файлового хранилища – разновидность локальной модели вычислений, только данные хранятся не на локальном диске ВУ, а на файловом сервере. Недостатки: сложность и ограниченность реализации совместного доступа. Распределенная модель вычислений – обработка и хранение данных осуществляется на двух и более ВУ. Наиболее яркими и распространенными на сегодняшний день разновидностями являются: а) Клиент-серверная модель. Такая модель вычислений реализована в современных СУБД с поддержкой SQL, также в современных почтовых системах и ПО групповой работы. С использованием этой модели работает большинство служб сетевых ОС, имеются успеш-
29
ные попытки встраивания этой модели вычислений в ОС для выполнения прикладного ПО. Существуют разновидности: толстый, тонкий и сверхтонкий клиенты. б) Модель на основе сервера приложений / монитора транзакций – реализуется пока ограниченно, чаще для доступа к ресурсам обычных клиент-серверных приложений через Web-интерфейс. Также есть попытки встраивания в ОС. Пример реализации: доступ к ресурсам Интернет через прокси-сервер. ПО, реализующее распределенную модель вычислений, называется распределенным ПО. В составе распределенного ПО должен быть реализован уровень взаимодействия – дополнительный уровень, который обеспечивает взаимодействие программных компонент, выполняющихся на разных ВУ. Вопросы и задания 1. Какие элементы входят в состав современной ИВС? 2. На какие категории можно разбить аппаратное обеспечение ИВС? 3. На какие группы можно разбить вычислительные установки? Перечислите критерии, которые используются для отнесения ВУ к той или иной группе. 4. Для каких целей в составе ИВС используется кабельное и сетевое оборудование? Приведите примеры сетевого оборудования и укажите выполняемые ими функции. 5. Какую роль в рамках ИВС играет периферийное оборудование? Приведите примеры оборудования данного типа. 6. Для чего в ИВС используется дополнительное оборудование? Для чего необходимы ИБП? Перечислите типы ИБП и укажите различия между ними. 7. Для каких целей используется программное обеспечение ИВС? Приведите классификацию ПО по функциональным возможностям. 8. Укажите уровни в составе современного программного обеспечения и модели вычислений, реализуемые в современном ПО.
30
Г л а в а 2 . ОПЕРАЦИОННАЯ СИСТЕМА С самого момента своего появления операционная система является основой программного обеспечения ИВС, определяет порядок разработки прикладного программного обеспечения и принципы работы пользователей с прикладным программным обеспечением. В данной главе будут рассмотрены общие вопросы организации и классификации операционных систем. Затем будут рассмотрены серверная ОС и ее службы, а также клиентская ОС. 2.1. Общие вопросы 2.1.1. Определение операционной системы и основные понятия
Операционная система (далее ОС) – это набор программных модулей, устанавливающихся и выполняющихся на ВУ как единое целое и обеспечивающих базовый интерфейс для доступа к ресурсам ВУ. Без установленной ОС пользоваться ВУ практически невозможно, так как для этого необходимо системное программирование, требующее глубоких знаний архитектуры конкретной ВУ, набора команд процессора и т.д. При наличии же ОС доступ к информационно-вычислительным ресурсам ВУ осуществляется путем манипулирования абстрактными логическими объектами типа программа, файл (документ), каталог (папка) и т.д. Рассмотрим далее наиболее распространенные примеры таких объектов. Программа / приложение – специально оформленная последовательность команд процессора, а также данных, служащая для обработки какой-либо информации. Загружается в оперативную память и выполняется под управлением ОС. Программы хранятся на диске в виде файлов. Файл – специально оформленная область внешней памяти, хранящая какую-либо информацию. Файлы бывают разных типов, в зависимости от хранимой в них информации (программные файлы, файлы данных, командные файлы и т.д.). Документ – более понятное название для файла с какими-либо данными, электронный аналог обычного (бумажного) документа. Каталог (или папка) – позволяет группировать файлы на диске подобно документам в папках. Каталог может содержать не только файлы, но и другие каталоги. Таким образом, файлы и каталоги на
31
диске образуют иерархическую логическую структуру – дерево каталогов файловой системы. (Сравнение: шкаф с ящиками, в которых располагаются папки с документами.) 2.1.2. Составные части
ОС состоит из двух основных частей: 1) системная часть или ядро; 2) прикладная часть или оболочка. Ядро состоит из драйверов – специальных программ для обслуживания компонентов аппаратного обеспечения ВУ (клавиатуры, мыши, сетевой платы, графической платы, оперативной и внешней памяти). Оболочка состоит из программных модулей, формирующих пользовательский интерфейс ОС. Пользовательский интерфейс определяет способ взаимодействия пользователя с ВУ. Чаще всего взаимодействие с ОС основано на командном принципе управления. Например, в DOS пользователь взаимодействует с ОС, набирая команды в командной строке, а затем нажимая клавишу [Enter]. В Windows 95 пользователь подводит указатель мыши к объекту, нажимает правую кнопку, выбирает в меню некоторый элемент (по сути, команду) и нажимает левую кнопку. Те или иные команды ОС позволяют пользователю взаимодействовать с ВУ и ее ресурсами, либо ресурсами всей ИВС. Например, выполняя команду DIR C: в DOS, можно получить на экране монитора список файлов и каталогов локального диска C:. Все современные ОС имеют развитой графический интерфейс пользователя. Помимо пользовательского интерфейса, ОС предоставляет пользователям программный интерфейс. Программный интерфейс предназначен для определенной категории пользователей – разработчиков системного и прикладного программного обеспечения. Программный интерфейс представляет собой набор программных вызовов, разбитых по функциональным группам. Одна группа функций обеспечивает выполнение высокоуровневых операций с оперативной памятью, другая – взаимодействие с файловой системой и т.д. Например, в ОС DOS программный интерфейс представлен «функциями» программных прерываний DOS (прежде всего Int 21).
32
В ОС Windows NT программный интерфейс Win32 API представляет собой набор функций и процедур сервиса исполняющей системы, экспортируемых для совместного использования приложениями. Чаще всего ОС предоставляет только базовый интерфейс для пользования ресурсами. Для расширения возможностей по использованию ресурсов (удобство, персонификация, минимум шагов для выполнения той или иной команды) используется дополнительное программное обеспечение. Например, сетевое ПО обеспечивает использование не только локальных ресурсов ВУ, но и ресурсов других ВУ. 2.1.3. Сетевое программное обеспечение
Пользователи ИВС совместно используют ресурсы ИВС, полагаясь на возможность ВУ взаимодействовать в сети. Для этого на каждой ВУ, включенной в сеть, помимо аппаратных компонентов сетеобразующего оборудования (сетевой платы, модема и т.п.), должно быть установлено сетевое ПО. Сетевое ПО – это специальное ПО для обеспечения взаимодействия ВУ, подключенных к сети. Сетевое ПО может быть включено в состав ОС, если это сетевая ОС (см. далее «Классификация ОС»), либо устанавливаться дополнительно, если это персональная ОС. Сетевое ПО включает следующие основные компоненты: 1) Драйвер сетевой платы/модема. Обслуживает сетевую плату или модем, установленный в ВУ. Существует несколько спецификаций на драйверы сетевых плат, определяющие порядок взаимодействия с вышележащими уровнями: ODI (см. далее раздел «Novell NetWare»), NDIS (см. далее раздел «Windows NT Server). 2) Драйвер транспортного протокола. Позволяет нескольким ВУ общаться в сети, используя определенный язык для транспортировки сообщений (транспортный протокол). Примеры транспортных протоколов: TCP/IP, IPX/SPX, NetBEUI. 3) Редиректор (перенаправитель) и сервис прикладного уровня. Для каждого типа прикладного сервиса должен быть установлен и запущен определенный тип редиректора и/или сервиса прикладного уровня. Редиректор устанавливается на рабочей станции (ВУ, выполняющей роль клиента) и запрашивающей определенные ресурсы у сервера – ВУ с установленной и запущенной компонентойсервисом прикладного уровня. Редиректор и сервис прикладного
33
уровня взаимодействуют друг с другом, используя определенный протокол прикладного уровня. Например, в сетях на основе ОС Novell NetWare используются редиректор и сервис прикладного уровня на основе протокола NCP, а в сетях Microsoft Network – редиректор и сервис прикладного уровня на основе протокола SMB. Каждый из перечисленных программных компонентов в составе сетевого ПО, занимает определенный уровень в системе взаимодействия компьютеров (рис. 1). Каждый из уровней полагается на нижележащий при отправке сообщений, и каждый уровень переправляет последовательно сообщения на вышележащий уровень сетевой архитектуры при получении сообщений. Все уровни ниже прикладного являются посредниками при обмене информацией между клиентом и сервером (ср. общение людей с помощью посредников). Компьютер (Клиент) Редиректор
А
Драйвер транспортного протокола Драйвер сетевой платы Сетевая плата/модем Сетевой кабель
Виртуальный канал Виртуальный канал Виртуальный канал
Компьютер Б (Сервер) Сервис прикладного уровня Драйвер транспортного протокола Драйвер сетевой платы Сетевая плата/модем
Физический канал связи
Сетевой кабель
Рис. 1. Компоненты сетевого ПО
Рассмотренные выше уровни сетевого ПО соответствуют модели OSI для построения сетевого взаимодействия, хотя некоторые программные модули в составе сетевого ПО выполняют функции сразу нескольких уровней модели OSI.
34
2.1.4. Классификация ОС
Деление ОС на сетевые и персональные С точки зрения готовности для работы в сети ОС делятся на сетевые (серверные и клиентские) и несетевые (или персональные). Сетевая ОС в отличие от несетевой имеет встроенные программные компоненты для взаимодействия ВУ по сети. Примеры сетевых ОС: все ОС семейства Unix, Windows 95, OS/2 Warp Connect. Примеры персональных ОС: DOS, OS/2. Серверная ОС позволяет предоставить ресурсы ВУ для совместного использования. Ресурсы ВУ, предоставленные в совместное использование, называются сетевыми ресурсами. Примеры серверных ОС: SCO OpenServer, Windows NT Server, NetWare, OS/2 Warp Server. Клиентская ОС позволяет выдавать запросы на использование сетевых ресурсов. (Сравните: персональная ОС служит для использования только локальных ресурсов ВУ.) Примеры клиентских ОС: Windows 95, Windows NT Workstation, OS/2 Warp Connect. Чаще всего под сетевой ОС подразумевается именно серверная ОС, так как встроенная поддержка работы в сети в клиентских ОС появилась сравнительно недавно. Деление ОС на клиент-серверные и одноранговые В зависимости от того, какие компоненты сетевого ПО устанавливаются и запускаются на ВУ, будем выделять две архитектуры построения сети: Клиент-серверная (Client/Server) – в сети явно выделяются ВУ, выполняющие роль серверов, и ВУ, выполняющие роль клиентов или рабочих станций. На сервере устанавливается только серверный компонент сетевого ПО, а на рабочей станции – только клиентский компонент сетевого ПО. Одноранговая (Peer-To-Peer) – в сети не выделяются ВУ, выполняющие определенные функции. На одной и той же ВУ может быть запущена как служба редиректора, так и служба сервиса прикладного уровня. С точки зрения возможности реализации той или иной архитектуры построения сети ОС делятся на одноранговые и клиентсерверные.
35
Деление на ОС для рабочих групп и ОС для сетей масштаба предприятия В зависимости от возможности ОС обеспечивать эффективную работу персонала подразделения (рабочей группы) или всего предприятия выделяют две архитектуры для обеспечения функций регистрации и аутентификации в системе: – архитектура для работы в рабочих группах (Workgroup Computing) – данная архитектура предполагает выделение для каждого подразделения своего сервера, обслуживающего процессы регистрации и аутентификации. Связь между серверами на уровне БД учетных записей не поддерживается; – архитектура для работы в сети масштаба предприятия (Network/Enterprise Computing) – данная архитектура предполагает наличие единой службы регистрации и аутентификации в сети предприятия. Служба регистрации и аутентификации должна отражать организационную структуру предприятия. С точки зрения возможности реализации той или иной архитектуры для обеспечения функций регистрации и аутентификации ОС делятся на ОС для рабочих групп и ОС для сетей масштаба предприятия. 2.2. Серверная ОС Любая система, в том числе и серверная ОС (далее СОС), проектируется и разрабатывается с учетом определенных требований, которым эта система должна удовлетворять. Требования, предъявленные к системе, прежде всего оказывают влияние на ее функциональность. Функциональность СОС определяется в первую очередь службами СОС – программными компонентами, отвечающими за выполнение различных информационно-вычислительных задач. 2.2.1. Требования к серверной ОС
Первоначально к СОС предъявлялись следующие требования: 1) наличие высокопроизводительной службы для совместного использования файлов и принтеров; 2) поддержка многочисленных клиентских сред (DOS, OS/2, Windows, Mac, UNIX).
36
Сегодня к СОС предъявляются дополнительные требования: 3) возможность обслуживать сложную сеть масштаба предприятия (архитектура Enterprise Computing); 4) совместимость с различными программными и аппаратными средствами, аппаратная независимость; 5) обеспечение информационной безопасности; 6) тесная интеграция c Internet; 7) открытость и поддержка со стороны третьих фирм – производителей ПО. Отдельно отметим такие требования, как масштабируемость, отказоустойчивость и управляемость – традиционные требования к серверным компонентам ИВС (как программным, так и аппаратным). 2.2.2. Функции серверной ОС
Первоначально СОС выполняла следующие функции: 1) обеспечение возможности совместного использования файлов и принтеров – файлы, каталоги, расположенные на дисках сервера, и принтеры, подключенные к серверу, используются многими пользователями; 2) обеспечение прозрачного доступа к совместно использующимся ресурсам из разных клиентских сред – один и тот же ресурс из одной среды виден как ресурс, совместимый с одной средой, а из другой – как ресурс, совместимый с другой средой. Например, в DOS некоторый файл виден с именем TEST~3.DOC, а в OS/2 этот же файл может быть виден с именем TEST for Word processor.doc. Со временем в сетевых ОС появились новые функции: 3) поддержка большого количества пользователей за счет службы справочника, обеспечение возможности однократной регистрации в системе в противовес отдельной регистрации в каждой системе и/или сетевой службе; 4) возможность автоматического обнаружения и регистрации новых устройств и средств расширения, автоматическая настройка ОС при появлении новых вычислительных ресурсов (память, процессоры, диски); 5) встроенные средства шифрования с использованием технологии сертификатов;
37
6) поддержка средств архивирования и резервного копирования данных; 7) поддержка служб работы в Internet (WWW, FTP, архитектура Java). Рассмотрим далее традиционные службы, а также некоторые новые службы, входящие в состав серверной ОС и обеспечивающие выполнение основных функций СОС. 2.2.3. Службы серверной ОС
Служба для совместного использования ресурсов файловой системы Эта служба обеспечивает совместное использование дискового пространства одной ВУ с других ВУ. ВУ с установленной и запущенной службой для совместного использования ресурсов файловой системы будем называть файловым сервером. Служба для совместного использования ресурсов файловой системы может поддерживать одну и более файловых систем в составе серверной ОС (Windows NT: FAT, NTFS; Netware: TurboFAT, но не FAT). В зависимости от производителя и версии ОС в совместное использование предоставляются все ресурсы файловой системы (NetWare), либо только часть ресурсов (Windows NT, OS/2 LAN Server), при этом на администратора возлагается обязанность по созданию сетевых ресурсов. Для поддержки различных клиентских сред обеспечивается возможность работы с файлами и каталогами в соответствии с теми стандартами, которые приняты в соответствующих средах (именование, дополнительные атрибуты). Служба для совместного использования принтеров Эта служба обеспечивает совместное использование принтеров, подключенных локально к ВУ, а также к сетевым принтерам с других ВУ. ВУ с установленной и запущенной службой для совместного использования принтеров будем называть сервером печати. Для поддержки различных клиентских сред обеспечивается возможность прозрачного доступа к услугам сервера печати в соответствии с теми стандартами, которые приняты в соответствующих средах.
38
Служба справочника Служба справочника обеспечивает идентификацию информационно-вычислительных ресурсов, регистрацию и аутентификацию пользователей в системе. Кроме того, в БД, поддерживаемой службой справочника, может храниться дополнительная информация о каждом пользователе, а также информация о других ресурсах сети, например принтерах, серверах и т.д. Служба справочника тесно взаимодействует со службой безопасности (см. далее). На сегодняшний день служба справочника является одной из основных служб СОС, обеспечивающих эффективное построение ИВС и управление ресурсами ИВС, поэтому остановимся на этой службе более подробно. Требования к службе справочника: 1) Обеспечивать единую процедуру входа в сеть. Пройдя один раз процедуру аутентификации с помощью службы справочника, пользователь должен получить возможность доступа ко всем ресурсам сети, на которые он имеет право доступа (Сравните: каждый раз при попытке доступа к ресурсу пользователь должен проходить процедуру аутентификации, т.е. вводить имя учетной записи и пароль доступа). 2) Иметь единую базу данных для хранения информации как о физических (серверы, рабочие станции, принтеры, тома файловой системы), так и о логических (пользователь, группа пользователей, приложение, очередь на печать) ресурсах сети. Каждый ресурс ИВС должен быть представлен в виде отдельного объекта в базе данных службы справочника. 3) Иметь иерархическую логическую структуру, отражающую организационную структуру подразделений предприятия, а также логическую структуру ИВС. 4) Иметь одну утилиту для управления всеми ресурсами ИВС. Таким образом, может быть обеспечено централизованное управление ИВС из одной точки сети. 5) Обладать масштабируемостью. Разбиение базы данных на части позволяет распределять БД службы справочника по серверам сети и выравнивать нагрузку на серверы при росте количества объектов в БД.
39
6) Обладать надежностью. Возможность дублирования (тиражирования) частей базы данных службы справочника позволяет устранить проблему аутентификации в системе и авторизации для обеспечения доступа к сетевым ресурсам при отказе одного из серверов, поддерживающих службу справочника. 7) Поддерживать различные программно-аппаратные платформы, включая большие ЭВМ, мини-ЭВМ и UNIX-системы. Службу справочника в своем составе могут иметь не только серверные ОС, но и распределенные приложения (прежде всего, реализованные в архитектуре «клиент-сервер»). И хотя такие службы оптимизированы для выполнения определенных задач (например, для почтовой системы – это регистрация и аутентификация пользователей почтовой системы, а также для хранения информации о местоположении почтовых ящиков пользователей и других атрибутов), часто они хранят информацию, аналогичную хранящейся в справочниках серверных ОС. Если таких служб несколько (одна служба поставляется с серверной ОС, клиент-серверная СУБД содержит свою службу, почтовая система – еще одну и т.д.), то кратно увеличивается и количество объектов, которые должны храниться в справочниках, при этом информация по большей части дублируется. Как следствие, резко усложняется сопровождение всей системы администратором ИВС. Вывод Необходимо обеспечивать интеграцию распределенных приложений со справочниками серверных ОС, использовать средства синхронизации (ПО NDS for NT, средства синхронизации Domino Directory с NT Directory Service в составе пакета Lotus Domino/Notes) и единый протокол (например, LDAP), обеспечивающий прозрачный доступ к разнородным службам справочника. Служба безопасности Отвечает за управляемый доступ к ресурсам ВУ, на которой установлена данная служба в составе серверной ОС, а также к другим службам ОС. Основной задачей, которую призвана решать данная служба, является защита информации от несанкционированного доступа, что предполагает, прежде всего, возможность присваивания пользователям определяемых администратором прав доступа к ресурсам.
40
Выполнение функций обеспечивается: а) списками управления доступом к защищенным ресурсам; б) проверкой прав доступа (авторизацией) при попытках доступа к ресурсам – сравниваются запрашиваемые права доступа и действительные права доступа на ресурс; в) управляемой реакцией – в зависимости от результата проверки прав доступа система предоставляет доступ или отклоняет попытку доступа к ресурсам; г) шифрованием информации, хранящейся в БД службы справочника, в обычных файлах на жестких дисках и передаваемых по сети – прежде всего, шифруются пароли доступа, а также ключи шифрования и сертификаты; д) системными политиками, определяющими правила работы пользователей с ресурсами сети и ВУ, на которой установлена серверная ОС. Служба безопасности тесно взаимодействует со службой аудита и журналирования. Служба аудита и журналирования Идея контроля использования ресурсов системы хорошо известна еще со времен больших ЭВМ. К сожалению, в составе операционных систем поставляются средства аудита только начального уровня. Однако существуют программные продукты производства третьих фирм, обеспечивающие более полное выполнение функций контроля и журналирования. Функции службы контроля и журналирования: 1) тесное взаимодействие с основными службами серверной ОС для получения в реальном масштабе времени информации о событиях, происходящих в системе; 2) поддержка БД журнала службы контроля для оперативного документирования происходящих событий с возможностью фильтрации имеющихся записей по определенному условию; 3) возможность независимого управления службой для проведения внешнего контроля. Контроль может вестись на нескольких уровнях: 1) Аппаратный уровень – сбор и отслеживание изменений в конфигурации серверов. Существуют специальные программные средства, например, ServerWorks (Digital), NetFinity (IBM), Insite Manager (Compaq).
41
2) Уровень основных служб ОС – сбор сведений о настройках ОС, контроль запуска драйверов и основных служб (менеджер памяти, подсистема ввода/вывода и т. п.), контроль использования информационно-вычислительных ресурсов. Хорошим примером для ОС NetWare может служить Novell ManageWise. 3) Уровень службы безопасности – сбор сведений о событиях безопасности (успешные или безуспешные попытки доступа к ресурсам, смена прав доступа, создание и удаление защищенных ресурсов). 4) Уровень приложений (включая некоторые службы ОС) – сбор сведений о функционировании приложений (запуск, изменение параметров, завершение работы). Служба архивирования и резервного копирования Возросшие объемы хранимой и обрабатываемой информации требуют особого внимания к вопросам архивирования и резервного копирования данных, хранящихся на дисках сервера. Архивирование заключается в выполнении сжатия данных, хранящихся на дисках сервера, с целью уменьшения объема пространства, занимаемого данными. В состав современных серверных ОС входят средства автоматического, либо ручного архивирования редко использующихся ресурсов файловой системы. Резервное копирование заключается в создании на съемных носителях частичных или полных копий данных, хранящихся на дисках сервера. Современные серверные ОС имеют встроенные средства резервного копирования, поддерживающие различные устройства и носители, например, устройства для записи и считывания на магнитно-оптические диски (МО-дисководы), устройства для записи и считывания на магнитные ленты (стриммеры), устройства CD-R(W) и т.д. Варианты выполнения резервного копирования: Полное копирование – на съемном носителе создается полная копия данных. Достоинства: полное восстановление данных с одного носителя за минимальное время. Недостатки: большой расход носителей (требуется много места для хранения резервных копий), невозможно выполнить частичное восстановление данных.
42
Инкрементное копирование – сначала выполняется полное копирование, затем на каждом следующем шаге резервного копирования выполняется запись изменений, произошедших в данных со времени последнего резервного копирования. Достоинства: минимальный расход носителей, наиболее гибкая процедура частичного восстановления. Недостатки: полное восстановление требует доступности данных, сохраненных на всех шагах процедуры резервного копирования, и достаточно большого времени для выполнения восстановления. Дифференциальное копирование – сначала выполняется полное копирование, затем на каждом следующем шаге выполняется запись изменений, произошедших в данных со времени полного копирования, т.е. происходит накопление изменений в данных. Достоинства: для полного восстановления достаточно носителя с полной копией, сделанной на первом шаге, и носителя с копией, сделанной на последнем шаге. Недостатки: на каждом новом шаге процедуры резервного копирования требуется все больше места на съемном носителе для хранения изменений. Требования к службе архивирования и резервного копирования: 1) автоматическая поддержка различных вариантов резервного копирования; 2) наличие агентов для копирования данных с различных ВУ сети (серверов и рабочих станций); 3) наличие или возможность подключения агентов для on-line резервного копирования данных, хранящихся в СУБД и других серверных приложениях; 4) поддержка различных аппаратных и программных платформ; 5) возможность создания системного диска для восстановления информации на дисках ВУ после механических сбоев, приведших к замене дисков ВУ с системными файлами ОС; 6) поддержка заданий, расписаний для автоматического выполнения заданий; 7) поддержка режимов частичного и полного восстановления информации.
43
Службы для обеспечения работы в Internet Многие современные сетевые ОС имеют встроенные средства поддержки служб Internet. Системы UNIX изначально основывались на протоколах Internet, поэтому поддержка Internet интегрирована в них наиболее полно. Все современные сетевые ОС поставляются со встроенными средствами для работы в Internet. ОС Netware с включенными в нее средствами поддержки Internet позиционируeтся теперь на рынке как IntranetWare. OC Windows NT содержит в себе информационный сервер MS IIS, а полный пакет серверных приложений MS BackOffice содержит также не включенную в ОС службу электронной почты. Большинство коммерческих версий UNIX поставляется со встроенной поддержкой функций брандмауэра и прокси-сервера, серверов WWW, FTP и SMTP/POP3. По причине своей обширности, рассмотрение служб для обеспечения работы в Internet/Intranet находится за рамками данной книги. 2.2.4. Дополнительное ПО, расширяющее функции основных служб ОС
Не все службы, даже основные, имеющиеся в стандартной поставке различных версий серверных ОС, функционально идентичны. Поэтому для обеспечения некоторых функций приходится задействовать дополнительное ПО, расширяющее и дополняющее функциональность, обеспечиваемую службами, входящими в поставку СОС. Например, в файловой службе ОС Windows NT отсутствует функция квотирования дискового пространства, используемого пользователями. Для ограничения размера каталогов и файлов совместного использования на серверах Windows NT устанавливается ПО Quota Server или Quota Manager (однако даже эти продукты не позволяют задать индивидуальные ограничения для пользователя). ВУ с установленным и запущенным серверным или клиентсерверным ПО, обеспечивающим дополнительные функции, будем называть сервером приложений.
44
2.2.5. Выводы и перспективы развития серверных ОС
Выводы Требования, предъявляемые к серверной ОС, достаточно жесткие, поэтому на сегодня не существует СОС, которая удовлетворяла бы всем потребностям гетерогенных (неоднородных) корпоративных сетей. По этой причине многие крупные организации и предприятия используют две и более серверных ОС, каждая из которых используется для решения преимущественно тех задач, с которыми она лучше справляется. И, как следствие, значительно возрастает стоимость развертывания и сопровождения ИВС – совокупная стоимость владения (Total Cost of Ownership / TCO). Прогнозы Коммерческие версии ОС семейства Unix (Sun Solaris, HP-UX, SCO OpenServer, Digital UNIX) будут доминировать в компьютерных системах среднего и крупного масштаба и их позиции на этом рынке сохранятся. Продолжится постепенное расширение доли рынка бесплатных вариантов Unix (FreeBSD, Linux), однако сфера их влияния будет ограничена. ОС Windows NT/2000 сохранит за собой весомую часть рынка серверных ОС за счет внедрения в сетях среднего и мелкого масштаба и усилит свое влияние на рынке сетей масштаба предприятия. Причина: наличие у фирмы Microsoft комплексных решений на базе этой ОС (пакет BackOffice), а также большая популярность у разработчиков ПО Win32 API – программного интерфейса, единого для клиентской и серверной ОС семейства Windows. Влияние ОС NetWare будет продолжать уменьшаться, и возможно, только служба справочника NDS сохранит свое лидирующее положение на рынке служб справочника. Перспективы В перспективе в стандартную поставку серверных ОС могут быть включены средства сетевого и системного управления, имеющие консоль сетевого/системного управления, а также средства удаленного управления через Internet. Для поддержки функций удаленного
45
управления сетевые ОС должны оснащаться средствами поддержки протоколов удаленного управления (например, SNMP), что позволит удаленно управлять ВУ, на которых установлены серверные ОС. 2.2.6. Функции администратора серверной ОС
Администратор ИВС или администратор серверной ОС должен выполнять следующие функции: 1.Установка и настройка серверной ОС. Включает следующие задачи: а) Установка программных файлов СОС на ВУ в роли сервера. б) Создание и поддержка томов файловой системы, в том числе для целей совместного использования ресурсов файловой системы. в) Установка и настройка основных и дополнительных служб ОС. 2. Сопровождение серверной ОС. Включает: а) Управление объектами службы справочника, в том числе учетными записями пользователей. б) Обеспечение безопасного доступа пользователей к совместно использующимся ресурсам. в) Обеспечение надежности ресурсов файловой системы и выполнение их резервного копирования. г) Контроль работы серверной ОС и ее служб, включая контроль доступа к ресурсам. д) Подключение пользователей и настройка рабочей среды пользователей. В следующих двух разделах мы рассмотрим особенности администрирования серверной ОС на примере двух распространенных СОС: Novell NetWare и Microsoft Windows NT Server. Подробно будут рассмотрены: особенности архитектуры СОС; файловые системы, использующиеся для обеспечения совместного использования ресурсов; служба справочника и служба безопасности; порядок установки СОС; средства администрирования; порядок подключения пользователей и настройки рабочей среды пользователей. В рамках данной книги не рассматриваются ОС семейства Unix, потому что последние занимают определенную нишу в ИВС: прежде всего, они устанавливаются на ВУ для выполнения функций серверов приложений (СУБД, почтовая система, WWW-сервер) и для обеспечения взаимодействия с сетью Интернет. Кроме того, при
46
написании книги не ставилась задача рассмотреть все реально существующие примеры программных компонентов в составе ИВС.
47
2.3. Novell NetWare Операционная система Novell NetWare (далее «NetWare») является «ветераном» на рынке серверных операционных систем. Для многих пользователей ИВС NetWare является синонимом слова «сеть», и наоборот. Рассмотрим подробно особенности архитектуры ОС NetWare, основные службы в составе NetWare и особенности администрирования ИВС на базе этой распространенной СОС. Рассмотрение будет проводиться на примере Novell NetWare версии 4.11. 2.3.1. Общие вопросы
История и версии NetWare Первая версия сетевой ОС Novell NetWare появилась еще в середине 80-х годов. Она работала в невыделенном режиме как надстройка над ОС DOS и обеспечивала подключение до 4 рабочих станций. Мы же кратко рассмотрим только версии NetWare, предлагаемые компанией Novell сегодня. NetWare 3.х (последняя – 3.2) Версия 3.0 (на момент выпуска называлась «NetWare 386») появилась в 1990 г. Разрабатывалась специально для процессора i386 с учетом его новых возможностей. Основные особенности версии: – 32-разрядная архитектура с ядром, поддерживающим не вытесняющую многозадачность, общая память для всех процессов, отсутствие виртуальной памяти. – Режим работы «выделенный сервер» с текстовым интерфейсом консоли для запуска и останова служб, а также оперативного контроля состояния сервера и его служб. – Архитектура вычислений Workgroup Computing – регистрация и аутентификация выполняется на каждом сервере индивидуально посредством службы справочника Bindery.
48
NetWare 4.х (последняя – 4.2) Версия 4.0 появилась в 1993 г., версия 4.11 – в августе 1996 г. Основные особенности версии: – Ядро с поддержкой многопроцессорной обработки, однако SMP поддерживается не полностью, так как системой используется только один так называемый «ведущий» процессор (за исключением обработчиков аппаратных прерываний), остальные процессоры являются «ведомыми» и могут быть задействованы только при выполнении оптимизированных для SMP приложений (например, Oracle Server для Novell NetWare SMP). – Улучшенная файловая система Turbo FAT – подразмещение блоков, миграция, сжатие данных. – Упрощенная схема выделения и освобождения памяти для процессов, попытка обеспечить защиту памяти введением доменов памяти, что упрощает разработку приложений, отсутствуют «утечки памяти». – Архитектура вычислений Network Computing – регистрация и аутентификация пользователей производится не на отдельном сервере, а в сети, с использованием службы справочника NDS (Novell Directory Services). – Расширение списка основных служб ОС включением служб для работы с Internet/Intranet: Novell WebServer, Novell Internet Access Server, Novell FTP Server. 5.х (последняя – 5.1) Версия Netware 5 появилась осенью 1998 года. Основные особенности версии: – Полностью переработанное ядро ОС: вытесняющая многозадачность, поддержка истинно (!) симметричной многопроцессорной обработки, защита памяти и поддержка виртуальной памяти. Как следствие, не все приложения для предыдущих версий Netware будут работать под управлением Netware 5. – Встроенная поддержка технологии Java: наличие виртуальной машины и графической подсистемы на сервере. Однако производительность графической подсистемы очень низкая и предъявляются высокие требования к аппаратным ресурсам ВУ. – Работа протокола NCP (протокол транспортного уровня служб ОС) поверх одного или двух (по выбору) сетевых протоколов – TCP/IP и SPX/IPX без инкапсуляции (!).
49
– Поддержка новой файловой системы NSS, обеспечивающей динамическое изменение размера тома (как в сторону увеличения, так и в сторону уменьшения), а также быстрое монтирование. Однако файловая система NSS не обладает многими возможностями Turbo FAT (аудит, сжатие, квотирование и т.п.). – Новая модульная архитектура для драйверов периферийных устройств. Особенности NetWare, не зависящие от версии а) Открытая наращиваемая архитектура. Достигается следующими элементами: б) Загружаемые модули. Обеспечивают динамическое изменение функциональности сервера NetWare без необходимости переконфигурирования ядра и эффективное использование оперативной памяти для выполнения необходимых задач. Подробно описаны в разделе «Загружаемые модули». в) Открытый интерфейс канала данных (Open DataLink Interface / ODI). Для поддержки нескольких сетевых плат на один сетевой протокол и нескольких сетевых протоколов на одной сетевой плате компаниями Novell и Apple была предложена спецификация на программные интерфейсы доступа к сети передачи данных. Спецификация ODI включает следующие уровни: 1) Уровень MLID-драйвера сетевой платы с расположенным над ним интерфейсом множества каналов связи (Multiple Link Interface); 2) Уровень поддержки канала связи (Link Support Layer / LSL) – программный переключатель между множеством каналов связи и множеством стеков протоколов; 3) Уровень стека протоколов с расположенным над ним интерфейсом (Transport Layer Interface / TLI); 4) Уровень потоков передачи данных. г) NetWare API. Для разработки распределенных приложений, использующих инфраструктуру сетевой ОС Novell NetWare, как на сервере, так и на рабочей станции (с установленным клиентским ПО) присутствует программный интерфейс для доступа к различным службам ОС (служба совместного использования ресурсов файловой системы, служба печати, служба справочника). Netware API включает в себя рассмотренные выше программные интерфейсы ODI.
50
д) Аппаратная независимость. Хотя сегодня ОС Netware разрабатывается исключительно для аппаратной платформы PC с процессором i386 компании Intel и выше и его клонами, однако можно говорить об аппаратной «независимости» ОС за счет: – поддержки большого количества средств расширения (платы контроллеров жестких дисков, сетевые платы и т.д.); – поддержки SMP архитектур различных производителей (Intel, Compaq, Tricord). е) Возможность удаленного управления. Обеспечивается: – возможность удаленного доступа к консоли сервера как по ЛВС, так и по низкоскоростным каналам (с использованием утилиты Remote Console); – поддержка протокола SNMP (с помощью модуля SNMP.NLM). ж) Встроенная служба безопасности. Рассматривается подробно в разделе «Служба безопасности» далее. з) Оптимизированная для совместного использования файловая система Turbo FAT. Рассматривается подробно в разделе «Файловая система» далее. Загружаемые модули NetWare Основу архитектуры NetWare составляет микроядро ОС. Микроядро обеспечивает переключение процессора в защищенной режим, управляет запуском и переключением между процессами, а также распределением оперативной памяти. Микроядро хранится в файле SERVER.EXE на сервере и загружается в оперативную память ВУ под управлением DOS в минимальной конфигурации. В дальнейшем функциональность сервера NetWare наращивается путем загрузки в память загружаемых модулей NetWare (Netware Loadable Modules / NLM). Загружаемые модули NetWare – это программные модули, разработанные специально для ОС NetWare и являющиеся аналогом выполняемых программ в DOS. В виде NLM-модулей в NetWare представлены: – драйверы сетевых плат (файлы *.LAN); – драйверы контроллеров жестких дисков (файлы *.DSK); – драйверы транспортных протоколов (например, TCPIP.NLM, IPXS.NLM, SPXS.NLM); – службы ОС (например, DS.NLM или PSERVER.NLM);
51
– утилиты консоли, предназначенные для мониторинга работы сервера (например, MONITOR.NLM) и выполнения других административных функций (например, INSTALL.NLM, VREPAIR.NLM, DSREPAIR.NLM). При загрузке NLM-модуля в память порождается новый процесс, которому выделяется часть оперативной памяти, доступной для использования ОС. Если созданный процесс обеспечивает отображение некоторой информации на мониторе, подключенном к ВУ, то создается экран – аналог окна для операционных систем с графическим интерфейсом пользователя. NLM-модули могут загружаться в память и выполняться в пакетном режиме с помощью командных файлов (NetWare Command File / NCF) – аналогов командных BAT-файлов в DOS. Организация внешней памяти на сервере под управлением NetWare После установки ОС NetWare на ВУ, на жестком диске в обязательном порядке присутствуют: Раздел DOS. Служит для хранения файлов DOS минимальной конфигурации, а также для хранения файлов ядра ОС NetWare, включая драйверы контроллеров жестких дисков и программу SERVER.EXE – загрузчик и микроядро ОС NetWare. В ОС NetWare включена поддержка файловой системы FAT, но только для обеспечения доступа к некоторым системным файлам ОС на этапе загрузки системы, а не для совместного использования ресурсов файловой системы. Раздел NetWare. Представляет собой раздел на жестком диске для хранения томов файловой системы Turbo FAT (см. далее раздел «Файловая система»). На каждом физическом диске может быть только один раздел NetWare. Файловая система Turbo FAT была специально разработана для совместного использования ресурсов файловой системы Том SYS. Он содержит все остальные файлы ОС NetWare (в каталогах SYSTEM, LOGIN, PUBLIC, MAIL и ETC). Кроме тома SYS: в разделах NetWare может быть создано произвольное количество томов файловой системы Turbo FAT.
52
Последовательность запуска сервера под управлением NetWare 1. Включение питания на сервере. 2. Загрузка DOS в минимальной конфигурации (без менеджера расширенной памяти !!!). 3. Ручной или автоматический (через AUTOEXEC.BAT) запуск файла SERVER.EXE из каталога с файлами ядра ОС Netware. При запуске файла SERVER.EXE используется командный файл STARTUP.NCF из каталога с файлами ядра для загрузки драйвера(ов) контроллера жестких дисков и установки параметров работы системы. Параметры запуска: – NA – отключить использование файла AUTOEXEC.NCF из каталога SYSTEM на томе SYS; – NS – отключить использование файла AUTOEXEC.NCF из каталога SYSTEM на томе SYS и файла STARTUP.NCF из каталога с файлами ядра. 4. Обнаружение на жестких дисках сервера тома SYS и его монтирование для доступа к системным файлам и файлу AUTOEXEC.NCF. 5. Запуск системы TTS. 6. Выполнение командного файла AUTOEXEC.NCF. В процессе выполнения файла производится открытие БД NDS и установление временной синхронизации с другими серверами Netware. Также, если это указано, выполняется монтирование томов, загружаются драйверы сетевых плат, выполняется привязка протоколов и загрузка дополнительных служб, например службы сервера печати. Завершение работы сервера под управлением NetWare 1. Подача команды DOWN на консоли сервера. 2. Автоматическая рассылка сообщения о завершении работы сервера на все рабочие станции, подключенные к серверу. 3. Сброс содержимого кэш-буферов на диск. 4. Размонтирование томов файловой системы (кроме SYS). 5. Закрытие БД NDS. 6. Завершение работы системы TTS. 7. Размонтирование тома SYS. 8. Выдача команды EXIT для возврата в DOS, либо отключение питания на сервере.
53
2.3.2. Файловая система NetWare
Характеристика файловой системы Файловая система NetWare, которая называется Turbo FAT, была разработана на основе файловой системы FAT, использующейся в DOS. За счет применения ряда технологических новинок стало возможным эффективное использование новой файловой системы для работы службы совместного использования ресурсов файловой системы. Отличительные черты файловой системы Turbo FAT: Высокая производительность, которая достигается за счет использования следующих технологий: – опережающее чтение данных в файловый кэш (в память считываются не только запрошенные блоки данных, но и последующие); – кэширование каталогов (считывание всей таблицы FAT в оперативную память при монтировании тома); – хэширование каталогов (создание дополнительного индекса в памяти для ускорения поиска элементов каталога); – кэширование файлов (запись файлов в оперативной памяти, а не на диске); – поддержка индексированных файлов (для файлов большого размера создаются дополнительные индексы, содержащие информацию из таблицы FAT, ускоряющие поиск блоков данных файлов); – элеваторный поиск (создание очереди запросов к диску и выполнение их в порядке прохождения головками цилиндров); – поддержка RAID уровней 0 (ускоренная запись) и 1 (ускоренное чтение). Гибкость: – тома файловой системы Turbo FAT являются монтируемыми по требованию, поэтому, если том не используется, можно выполнить размонтирование и оперативная память освободится; – поддержка множества пространств имен (DOS, MAC, LONG, NFS) для прозрачного доступа к одним ресурсам с разных клиентских платформ; – возможность восстановления удаленных файлов (процедура Salvage);
54
– подразмещение блоков (только в 4.х) – для экономии дискового пространства на больших томах некоторые кластеры дополнительно разбиваются на блоки меньшего размера для хранения файлов небольшого размера; – сжатие файлов (только в 4.х) – для эффективного использования дискового пространства. Надежность / Отказоустойчивость: – дублирование таблицы FAT и таблицы каталогов на разных цилиндрах диска для каждого тома и автоматическое переключение при сбоях; – проверка чтением после записи блока данных на диск и автоматическое переназначение блока при сбоях (механизм Hot-Fix I); – поддержка RAID 1 (зеркалирование и дублирование) на уровне разделов, при сбоях в момент чтения данные извлекаются с зеркальной копии раздела (механизм Hot-Fix II); – наличие службы TTS (Transaction Tracking System) – изменения в информации, хранящейся на диске, производятся в непротиворечивом режиме на основе транзакций, в журнал транзакций записываются изменения и при сбоях производится откат или обратное восстановление, используется файл журнала BACKOUT.TTS на томе SYS. Безопасность: – ограничение доступа к файлам и каталогам путем задания опекунских прав (Trustees), а также фильтра наследуемых прав (IRF); – ограничение доступа к тому путем задания квот на использование дискового пространства тома; – поддержка системы аудита для отслеживания попыток доступа к ресурсам файловой системы. Логическая структура файловой системы Логическая структура файловой системы NetWare имеет древовидный характер (рис. 2) и полностью повторяет логическую структуру файловой системы FAT в DOS, если не учитывать различие в именовании логических дисков/томов (в NetWare логические диски называются томами). В отличие от DOS имя тома файловой системы NetWare может содержать от двух до 50 букв. Каждый ресурс файловой системы NetWare характеризуется стандартными атрибутами, такими как имя ресурса (файла или каталога), дата создания, размер и т. п., а также специальными атрибутами, использующимися файловой системой NetWare и службой для совместного использования ресурсов.
55
Рис. 2. Логическая структура файловой системы NetWare
Атрибуты каталогов: – Запрет удаления (Delete Inhibit, Di) – обеспечивает запрет на удаление каталога. – Не подвергать сжатию (Don’t compress, Dc) – содержимое каталога не будет подвергаться сжатию, несмотря на то что на томе включен механизм сжатия хранящейся инфорамации. – Не перемещать (Don’t migrate, Dm) – содержимое каталога не будет перемещаться на съемные носители даже в случае их редкого использования. – Скрытый (Hidden, H) – каталог не виден при просмотре стандартными средствами для работы с ресурсами файловой системы. – Немедленное сжатие (Immediate Compress, Ic) – при любом изменении содержимого каталога будет выполняться его немедленное сжатие. – Нормальный (Normal, N) – служит для очистки всех других атрибутов каталога. – Очистка (Purge, P) – содержимое каталога не может быть восстановлено процедурой Salvage.
56
– Запрет на переименование (Rename Inhibit, Ri) – невозможно изменить имя каталога. – Системный (System, Sy) – каталог является системным. Атрибуты файлов: – Невозможно сжать (Can’t compress, Cc) – такой атрибут может быть выставлен ОС при невозможности выполнить сжатие (например, не хватает места на диске для выполнения сжатия или установлен запрет на сжатие). – Сжатый (Compressed, Co) – файл сжат средствами ОС. – Запрет копирования (Copy Inhibit, Ci) – запрет на копирование файла стандартными средствами. – Запрет удаления (Delete Inhibit, Di) – запрет на удаление файла стандартными средствами. – Не подвергать сжатию (Don’t compress, Dc) – аналогичен одноименному атрибуту для каталогов. – Не перемещать (Don’t migrate, Dm) – аналогичен одноименному атрибуту для каталогов. – Только исполняемый (Execute Only, X) – возможен только запуск файла на выполнение, но не чтение или редактирование. – Скрытый (Hidden, H) – аналогичен одноименному атрибуту для каталогов. – Немедленное сжатие (Immediate Compress, Ic) – аналогичен одноименному атрибуту для каталогов. – Индексирован (Indexed, I) – при первом открытии для файла создается хэш-индекс в памяти, обеспечивающий быстрый доступ к его содержимому, автоматически устанавливается для больших файлов. – Перемещенный (Migrated, M) – файл перемещен на съемные носители, так как редко использовался пользователями или системой. – Нормальный (Normal, N) – аналогичен одноименному атрибуту для каталогов. – Очистка (Purge, P) – аналогичен одноименному атрибуту для каталогов. – Только для чтения (Read Only, Ro) – файл доступен только для чтения его содержимого.
57
– Запрет на переименование (Rename Inhibit, Ri) – аналогичен одноименному атрибуту для каталогов. – Разделяемый (Shareable, Sh) – файл используется совместно, необходимо устанавливать такой атрибут для файлов, которые однвоременно открываются несколькими пользователями. – Системный (System, Sy) – аналогичен одноименному атрибуту для каталогов. – Транзакционный (Transactional, T) – при работе с файлом используется система TTS (см. далее) для отслеживания изменений содержимого файла. Физическая структура файловой системы На самом верхнем уровне физической организации файловой системы Turbo FAT находится раздел NetWare. Раздел NetWare представляет собой раздел на жестком диске для хранения томов файловой системы Turbo FAT. На каждом физическом диске может быть создан только один раздел NetWare. Содержимое раздела Netware делится на область переадресации (Hot Fix Redirection Area) и область данных (Data Area). При сбоях во время записи в блоки области данных система автоматически помечает блоки как сбойные, подключая при этом для хранения данных необходимое количество блоков из области переадресации. Обычно область переадресации занимает не более 2% общего размера раздела. Между двумя разделами Netware возможно установление режима зеркального отображения, прежде всего для обеспечения дополнительной надежности (такой режим соответствует спецификации RAID1). Сегмент – это некоторая подобласть области данных раздела NetWare. В пределах раздела может быть определено до 8 сегментов. Том – это аналог логического диска в DOS. Том файловой системы Turbo FAT может состоять из одного и более сегментов, размещенных в одном и более разделах Netware. Благодаря организации томов на основе сегментов, том можно наращивать в любой момент времени после создания и начала использования. Кроме того, том, состоящий из сегментов с разных разделов (т.е. размещенный на нескольких жестких дисках), соответствует спецификации RAID0 и позволяет ускорить чтение данных, хранящихся на томе.
58
Каждый том содержит две копии таблицы FAT и две копии таблицы каталогов. Каждая копия занимает непрерывный участок внешней памяти в пределах тома. Все остальное пространство тома предоставляется для размещения файлов. Все ресурсы файловой системы размещаются в блоках (или кластерах) – адресуемых участках внешней памяти в пределах тома. Блок состоит из одного и более расположенных последовательно секторов блочного устройства, например, жесткого диска. Существует несколько типов блоков. В блоках таблицы FAT размещается таблица FAT – таблица размещения файлов, позволяющая получить список блоков, занимаемых тем или иным файлом. Блоки таблицы FAT имеют фиксированный размер (512 байтов) и содержат по 64 записи таблицы FAT (размером 8 байтов). Каждая запись ссылается на один блок данных в пределах адресуемого пространства тома (см. далее). Размер таблицы FAT ограничен только размером адресуемой оперативной памяти (4Гбайт). Блоки таблицы каталогов содержат информацию об элементах каталогов (файлы и другие каталоги) файловой системы. В каждом блоке может содержаться до 32 записей таблицы каталогов (размером 128 байтов) разного типа: – записи о файлах или каталогах для каждого пространства имен, поддерживающегося на томе; – записи опекунов файлов или каталогов (формирующие ACL файла или каталога); – свободные записи. Размер блоков таблицы каталогов фиксированный (4 К). Блоки выделяются динамически по запросу системы и более не освобождаются (но могут использоваться повторно). Максимально под таблицу каталогов может быть выделено 65536 блоков. Блоки данных содержат данные, хранящиеся в виде файлов. Размер блоков для хранения данных может быть выбран из множества (4, 8, 16, 32 и 64 К), хотя при создании тома система предлагает оптимальный размер блока в зависимости от размера создаваемого тома. Внутри больших по размеру блоков может быть выполнено дополнительное подразбиение на блоки меньшего размера (512 байтов) для эффективного хранения небольших по размеру файлов. Свободные блоки – это блоки, которые еще не принадлежат какому-либо файлу или таблице каталогов.
59
Монтирование томов файловой системы Монтирование тома файловой системы NetWare служит для обеспечения доступа ОС к данным, хранящимся на томе, а также для обеспечения совместного доступа к данным на томе через сеть. Заключается в считывании в память таблицы FAT и корневого каталога, выделении кэш-памяти для операций с файлами и создании индексов (хэш-таблиц) для ускорения поиска записей в таблицах каталогов. К сожалению, файловая система NetWare унаследовала от FAT возможность фрагментации файлов и каталогов при активной работе с ними и связанной с изменением размеров файлов и каталогов. В случае большой фрагментации время монтирования тома увеличивается. Монтирование выполняется вручную командой MOUNT <имя тома> на сервере, либо автоматически при запуске сервера путем включения соответствующей команды в файл AUTOEXEC.NCF. Размонтирование томов выполняется автоматически при завершении работы сервера, либо вручную командой DISMOUNT <имя тома> на сервере. Поддержка множества пространств имен Поддержка множества пространств имен для ресурсов тома файловой системы обеспечивает прозрачный доступ клиентов, запущенных на различных платформах, к файлам и каталогам, хранящимся на томе. По умолчанию, на томе поддерживается пространство имен DOS со стандартными именами DOS в формате 8.3. При установленной поддержке дополнительного пространства имен для каждого создаваемого файла или каталога на томе создается дополнительная запись в таблице каталогов для поддержки соответствующих соглашений об именовании. Это следует учитывать при добавлении поддержки пространства имен к томам. Установка пространства имен для тома выполняется следующим образом: 1) загружается соответствующий модуль поддержки пространства имен, например LONG.NAM; 2) выполняется команда ADD <имя пространства имен> TO <имя тома>.
60
При выполнении монтирования тома система распознает, поддержку каких пространств имен необходимо обеспечить и автоматически загружает в память соответствующие модули. Удаление поддержки пространства имен для тома выполняется утилитой VREPAIR на сервере. Предварительно выполняется операция размонтирования тома. Ограничение доступа к ресурсам файловой системы Для ограничения доступа пользователей к информации, хранящейся на томах файловой системы, используется встроенная в NetWare служба безопасности. Служба безопасности, применительно к ресурсам файловой системы, будет рассмотрена подробно далее. Информация для управления доступом хранится в виде дополнительных элементов таблицы каталогов файловой системы. Восстановление случайно удаленных файлов В NetWare все удаленные файлы сохраняются с другим именем в том же каталоге, где они находились до удаления, при этом, они становятся недоступными для пользователей. Поэтому ошибочно удаленные файлы можно восстановить (выполнить процедуру Salvage). Лишь в случае нехватки места на диске для новых файлов удаленные ранее файлы будут затерты. Если файлы удаляются вместе с каталогом, то все удаленные файлы помещаются в скрытый каталог DELETED.SAV на соответствующем томе. Для очистки содержимого тома от удаленных, но сохраненных файлов выполняется операция очистки тома – Purge. Удаленные файлы восстанавливаются утилитой Filer. Восстановление файловой системы при сбоях Какой бы надежной ни была система, сохраняется вероятность сбоя (зависание системы, отключение питания) и, как следствие, нарушения целостности хранящейся информации. Для восстановления после такого рода сбоев используется утилита VREPAIR. Эта утилита позволяет с учетом избыточной информации и данных системы трассировки транзакций (Transaction Tracking System, TTS)
61
привести содержимое тома в непротиворечивое состояние. Восстановление при помощи VREPAIR выполняется системой автоматически при невозможности смонтировать том. В более критических случаях, связанных с физическим повреждением диска, восстановление выполняется повторным созданием тома и копированием информации с резервной копии тома. 2.3.3. Сеть на основе NetWare и служба справочника NDS
ИВС на основе NetWare реализует архитектуру «клиент-сервер» для построения сети (см. раздел «Классификация серверных ОС»). В роли серверов могут выступать ВУ с установленной ОС NetWare (далее «серверы NetWare»), а в роли рабочих станций – ВУ с установленными ОС DOS, DOS+Windows 3.xx, Windows 9x, Windows NT, OS/2, Mac OS и установленной клиентской частью сетевого ПО в составе NetWare. Для взаимодействия клиентской и серверной частей сетевого ПО используется протокол прикладного уровня NCP (NetWare Core Protocol). Для транспортировки сообщений между клиентом и сервером используется, в общем случае, транспортный протокол IPX/SPX (Internetwork Packet eXchange/Sequenced Packet eXchange). Основу сети составляют серверы NetWare, которые с помощью службы справочника в составе ОС NetWare образуют и поддерживают дерево NDS (рис. 3). Если сервер NetWare принадлежит одному дереву NDS, то он не может принадлежать в то же самое время другому дереву NDS. Сетевыми ресурсами являются ресурсы серверов NetWare (прежде всего, тома файловой системы NetWare и сетевые принтеры, подключенные к серверам NetWare), зарегистрированные в службе справочника. С рабочих станций сети, на которых установлено клиентское ПО NetWare, пользователи могут выполнять аутентификацию в сети с помощью службы справочника и использовать доступные сетевые ресурсы.
62
Рис. 3. Сеть на основе NetWare
Распределенная служба справочника ресурсов сети в составе NetWare называется Novell Directory Services (далее «NDS»). NDS управляет как физическими, так и логическими ресурсами ИВС. Организация и управление ресурсами реализуются в соответствии с логической структурой сети без учета физического местонахождения определенных ресурсов. Пользователь может получить доступ к ресурсам (если на это ему будет предоставлено право), даже не зная их точного местонахождения. NDS основана на стандарте X.500 для службы справочника. Пользователь регистрируется и аутентифицируется в сети, а не на сервере. Аутентификация в сети происходит после присоединения к ближайшему серверу сети. Аутентификация и связанная с ней операция присоединения к другим серверам происходят для пользователя незаметно в фоновом режиме.
63
Логическая структура NDS Логическая структура NDS подобна иерархической структуре дерева. Поэтому логическую структуру NDS называют еще деревом NDS. Дерево NDS обеспечивает наглядное представление организационно-штатной структуры организации или предприятия, а также ИВС организации или предприятия. По этой причине перед установкой NDS необходимо выполнить тщательное планирование дерева NDS для создания максимально эффективной и удобной структуры. Основными элементами, из которых формируется дерево NDS, являются объекты. Объекты NDS Каждый объект NDS характеризуется некоторым набором свойств. Каждому свойству может приписываться одно и более значений. Есть обязательные свойства, например Login Name для объекта Пользователь. Таким свойствам обязательно должны быть приписаны значения. Обязательным свойством для любого объекта является его имя. И есть необязательные свойства, например Login Script. Для них значения могут отсутствовать. Вся информация об объектах NDS, их свойствах и значениях свойств хранится в БД NDS (О БД NDS и физической структуре NDS см. далее). Объект NDS является структурой, в которой хранится информация о ресурсе, и не является подлинным объектом (как, например, в объектно-ориентированных БД). Любой объект NDS создается как экземпляр определенного класса. Набор классов, на основе которых могут создаваться объекты в дереве NDS, определяет схему дерева NDS. Если объект Объект1 создан на базе класс Класс1, то будем говорить об Объекте1, как объекте типа Класс1. Различают также несколько категорий объектов: а) физические объекты – существуют физически как ресурсы сети (например, пользователь, принтер, сервер); б) логические объекты – необходимы для удобства управления сетевой средой (например, группы пользователей, очередь на печать, замещаемая должность); в) объекты, предназначенные для построения дерева NDS (например, организация, подразделение). Управление объектами NDS осуществляется с помощью утилиты NetWare Administrator.
64
Построение дерева NDS В ЛВС, а тем более в ГВС, может существовать несколько деревьев NDS. Каждое дерево NDS является независимым и идентифицируется уникальным именем, например EDU. Начало дерева NDS образуется специальным объектом, который обозначается как объект [Root] (далее «корень»). При установке первого сервера NetWare на нем создается БД NDS и в нее помещается корень вновь создаваемого дерева. Дерево NDS «растет» от корня вниз и в ширину с помощью контейнерных объектов (Container Objects) подобно тому, как на обычном дереве растут ветви, образуя логическую структуру дерева. Контейнерные объекты могут содержать в себе другие контейнерные объекты или объекты-листья. Объекты-листья (Leaf Objects) завершают логическую структуру NDS, располагаясь внутри контейнерных объектов подобно тому, как листья растут на ветках обычных деревьев. Объекты-листья представляют собой ресурсы сети и не могут содержать в себе другие объекты. Рассмотрим далее примеры классов, на основе которых могут быть созданы контейнерные объекты и объекты-листья. Примеры классов контейнерных объектов: Страна (Country, обозначается как C ) – имя объекта данного типа представляет аббревиатуру из двух символов (RU, US и т.п.). Объект типа Страна может содержать только контейнерные объекты типа Организация или лист-объекты типа Псевдоним, не является обязательным объектом. Организация (Organization, обозначается как O ) – объект данного типа предназначен для построения логической структуры дерева NDS, т.е. для расстановки всех других контейнерных и листобъектов внутри NDS. Как правило, объекты типа Организация соответствуют основным отделам предприятия. В дереве NDS должен существовать по крайней мере один объект типа Организация. Объект данного типа располагается непосредственно под корневым объектом и объектом типа Страна. Объект данного типа не может содержать объекта типа Организация внутри себя, а только объекты типа Подразделение или лист-объекты.
65
Подразделение (Organisation Unit, обозначается как OU ) – с помощью объектов данного типа образуются подразделения. Используя объекты данного типа, можно выполнять разделение ствола дерева NDS на любое количество уровней. Объект типа Подразделение может содержать другие контейнерные объекты типа Подразделение и лист-объекты. Объект типа Подразделение помещается под объектом типа Организация или под уже существующим объектом типа Подразделение. Примеры классов лист-объектов: Пользователь (User) – объект данного типа создается для каждого пользователя сети, является учетной записью пользователя. Группа пользователей (Users’ Group) – объект данного типа создается для удобства управления пользователями, в частности для назначения прав доступа на ресурсы. Профиль – объект данного типа позволяет определить одинаковую рабочую среду для группы пользователей. Шаблон – объект данного типа создается как основа для последующего создания множества объектов типа Пользователь с похожими свойствами. Замещаемая должность – обьект данного типа является аналогом группы пользователей. Сервер NetWare – объект данного типа создается при установке сервера NetWare и представляет сервер в дереве NDS. Том – объект данного типа создается при определении тома файловой системы NetWare. Очередь на печать – объект данного типа обеспечивает совместное использование объектов типа Принтер, а также позволяет управлять заданиями пользователей на печать. Сервер печати – объект данного типа создается при установке службы печати на сервере NetWare. Принтер – объект данного типа представляет в NDS физическое устройство – принтер. Псевдоним – с помощью объектов данного типа обеспечивается удобная работа пользователя в сети с текущим контекстом, отличным от контекста учетной записи данного пользователя, а также с ресурсами контекста, отличного от контекста учетной записи данного пользователя (см. далее «Контекст, простые и полные имена объектов»).
66
Неизвестный тип – объекту NDS присваивается данный тип, если утилита администрирования NetWare Administrator не знает, как интерпретировать значения свойств объекта. NDS является открытой службой справочника и позволяет добавлять к существующим классам объектов новые, а также расширять список свойств существующих классов объектов, таким образом расширяя и модифицируя схему NDS. Например, ПО Z.E.N.works регистрирует в NDS новые классы объектов для управления настольными рабочими станциями, а ПО NDS for NT добавляет новые классы объектов для синхронизации службы справочника NDS и службы справочника в составе ОС Windows NT. Для поддержки новых классов объектов необходимо установить расширения схемы NDS на сервере NetWare (требуются права администратора дерева NDS), а также специальные библиотеки (SnapIn’s) для поддержки новых классов объектов утилитой администрирования NetWare Administrator. Обычно это делается автоматически при установке ПО с поддержкой новых классов NDS. Контекст NDS, простое и полное имена объектов Контекстом NDS будем называть местоположение объекта в дереве NDS. Формат описания контекста – символьная строка, состоящая из полей, отделенных одно от другого точкой. Каждое поле представляет собой имя контейнерного объекта. Контекст можно записывать как с указанием класса объекта, так и без него. Контекст показывает, какие контейнерные объекты NDS надо пройти от корня по ветвям дерева, чтобы найти требуемый объект. Например, OU=INF.O=TSU. Контекст дерева NDS аналогичен каталогу, определяющему местонахождение файла в файловой системе. Любой лист-объект обладает собственным именем, которое называется простым именем (Common Name, сокращенно CN). Это имя должно быть уникальным в пределах контейнерного объекта. Полное имя объекта NDS складывается из контекста объекта и простого имени объекта. Например, CN=TSU_INF.OU=INF.O=TSU. Полное имя объекта должно быть уникальным в пределах одного дерева NDS. Для идентификации ресурсов сети при работе с ними, в общем случае, должно использоваться полное имя объекта. В частности, при входе в сеть пользователь должен указывать свое полное имя.
67
Для обеспечения удобства пользователям при входе с сеть и работе с ресурсами NDS используется понятие текущего контекста. Текущий контекст по своему назначению аналогичен понятию текущего каталога в файловой системе. Он указывает, какой контейнерный объект является текущим при работе с объектами NDS. Правильная настройка текущего контекста обеспечивает возможность использования в работе только простых имен объектов. Текущий контекст назначается при выполнении процедуры входа в сеть и, впоследствии может быть изменен с использованием команды CX. Например, чтобы текущим контекстом сделать контейнерный объект-родитель, введите: C:\>CX . Чтобы текущим контекстом сделать INF.TSU, введите: C:\>CX .INF.TSU . Чтобы текущим сделать контейнер, являющийся потомком текущего контейнера, введите: C:\>CX <имя контейнера-потомка>. Физическая структура службы справочника NDS Служба NDS является распределенной службой справочника. Вся информация об объектах NDS хранится в распределенной БД NDS. БД NDS состоит из частей, называемых разделами БД NDS. Разделы NDS могут быть распределены по различным серверам сети (рис. 4). Раздел NDS образует блок данных в дереве, который используется для хранения информации БД NDS, а также для копирования информации на другие серверы, т.е. для дублирования частей NDS. Дублирование обеспечивает высокий уровень доступности информации, хранящейся в БД NDS. Разделы могут создаваться автоматически при установке новых серверов, а также вручную при помощи утилиты NDS Manager. При установке в организации первого сервера NetWare создается корневой объект дерева NDS. Одновременно с этим создается и первый раздел БД NDS. Этот раздел получает имя корневого раздела (Root-Partition), потому что он содержит объект [Root]. При установке следующего сервера в контекст, который ранее не существовал в дереве, программа инсталляции автоматически создаст для БД NDS новый раздел. Этот раздел будет содержать всю информацию об объектах, расположенных в том же контексте, что и сервер.
68
Для обеспечения надежности и доступности БД NDS разделы NDS дублируются на различные серверы сети. Одна копия раздела называется репликой раздела. Существует возможность создания произвольного количества реплик (более 10 не рекомендуется) для хранения их на различных серверах сети. Существуют четыре типа реплик разделов NDS: 1) Master – для каждого раздела может существовать только одна Master-реплика, автоматически создается при создании раздела; 2) Read/Write – может существовать любое количество, автома-
Рис. 4. Пример разбиения БД NDS на разделы
тически создается при установке нового сервера в существующий контекст; 3) Read – также может существовать любое количество, служит только для считывания информации; 4) Subordinate – физически является не копией раздела БД, а ссылкой на реплику типа (1)–(3). Тип реплики можно поменять в любой момент времени. Если Master-реплика преобразуется в Read/Write, то первая доступная Read/Write-реплика становится Master, и наоборот.
69
Синхронизация БД NDS Для правильной синхронизации реплик разделов БД NDS в сети на базе ОС NetWare используется единое пространство времени для всех серверов, а также для рабочих станций. Единое пространство времени поддерживается серверами времени (Time Servers). Существуют четыре типа серверов времени: 1) Одиночный справочный сервер времени (Single Reference) – все узлы сети (серверы и рабочие станции) получают время от него. В сети может существовать только один SR-сервер. 2) Вторичный сервер времени (Secondary) – такой сервер получает текущее значение времени от одиночного справочного, первичного или справочного сервера. Для вторичных серверов действительны следующие правила: – Если в сети уже есть одиночный справочный сервер, то другие могут быть только вторичными серверами. – Если в сети есть первичный и справочный временные серверы, то остальные могут быть только вторичными. 3) Первичный сервер времени (Primary) – периодически согласует свое время хотя бы с одним из других первичных или справочных временных серверов, чтобы потом предоставить его вторичным серверам и рабочим станциям. 4) Справочный сервер времени (Reference) – такой сервер задает время для всех других серверов и рабочих станций сети. Он получает (например, от внешней службы эталонного времени) и хранит точное значение времени в сети. Кроме того, он периодически опрашивает первичные серверы и указывает им точное значение времени. Существуют две модели построения сети, определяющие порядок взаимодействия серверов времени (рис. 5 и 6).
70
Рис. 5. Модель на базе одиночного справочного сервера. Для малых сетей
Рис. 6. Модель на базе справочного и первичных серверов. Для больших распределенных сетей
71
2.3.4. Служба безопасности В ОС NetWare встроена служба безопасности. Эта служба обеспечивает разграничение и контроль доступа к информационновычислительным ресурсам, предоставляемым другими службами ОС, например файловой службой и службой справочника NDS, рассмотренных ранее. Основные механизмы службы безопасности для управления доступом Установка прав доступа на защищенные ресурсы для пользователя осуществляется путем назначения опекунства (Trustee Assignment). Опекуном является пользователь или другой объект со специальными привилегиями или правами доступа. Чтобы система знала, кто и на что обладает правами, для каждого защищенного ресурса (каждого каталога, каждого файла, каждого объекта и каждого свойства) создается и поддерживается список контроля доступа (Access Control List – ACL). В ACL ресурса хранится информация о том, кто обладает правами на ресурс (является опекуном) и каковы эти права. Важнейшим аспектом системы безопасности NetWare является наследование прав доступа по дереву (будь то дерево каталогов файловой системы или дерево NDS). Это означает, что если некоторый объект является опекуном защищенного ресурса, обладая при этом определенными правами, например чтение и просмотр, то эти же права доступа автоматически распространяются ниже по дереву. Действие механизма наследования прав прекращается, если на некотором нижележащем уровне этот же объект снова назначен опекуном. Каждый защищаемый ресурс имеет фильтр наследуемых прав (Inherited Rights Filter – IRF), который по умолчанию не активизирован. Фильтр состоит из полей наподобие флажков, по одному на каждое право доступа, которое возможно для данного ресурса. Если поле отмечено, то право доступа наследуется вниз по дереву, если сброшено, то нет (т.е. выполняется операция логического И). Таким образом, регулируется действие механизма наследования прав. Если некоторый объект является опекуном некоторого ресурса, например, каталога DOC с правом чтения (R) и записи (W), он имеет та-
72
кие же права и на подкаталог DOS_DOC и ниже, но только в случае, если не сброшены поля R и W для IRF подкаталога DOS_DOC. (!)
IRF одинаково действует на все объекты, которые пытаются получить доступ к ресурсам.
Еще одной важной особенностью системы безопасности является механизм обеспечения доступа через эквивалентность прав (Security Equivalence). Например, объект А имеет права доступа на чтение, запись и просмотр ресурса R. Если некоторый объект B эквивалентен A, то он обладает теми же правами, даже не будучи явно назначен как опекун ресурса R. Чаще всего для определения эквивалентности прав используется объект типа Группа (Group) или Замещаемая роль (Organization Role). Группа назначается опекуном некоторого ресурса, и пользователи, члены группы, получают соответствующие права доступа к ресурсу. Действительные права доступа Действительные права – это фактические права на каталог, файл или другой защищенный ресурс. Действительные права определяются непосредственно в момент доступа объекта к ресурсу и получаются путем суммирования прав, которые объект приобрел в результате действия следующих механизмов: 1) прямое предоставление объекту прав опекуна на ресурс; 2) наследование прав от родительского каталога в сочетании с IRF ресурса; 3) предоставление прав через эквивалентность прав (в том числе через членство в группе, которой предоставлено право опекуна); 4) предоставление прав через назначение объекта [Public] опекуном некоторого ресурса; 5) предоставление прав через назначение контейнерного объекта (включая объект [Root]), содержащего в себе рассматриваемый объект, опекуном некоторого ресурса. Типы прав доступа, использующиеся в NetWare В NetWare предусмотрены права доступа: а) на каталоги; б) на файлы; в) на объекты NDS; г) на свойства объектов NDS.
73
Права доступа определяют допустимые действия с защищенными ресурсами: объектами, свойствами и т.д. Допустимые права на каталог: – Право супервизора (S) – опекуну передаются все полномочия на каталог и все находящиеся в нем подкаталоги и файлы. Право S не может быть ограничено с помощью IRF. – Право на чтение (R) – опекун может открывать и читать существующие файлы в каталоге и подкаталогах. – Право на запись (W) – опекун может изменять содержимое существующих файлов, открывая их для этого. – Право на создание (С) – опекун может создавать новые файлы и подкаталоги. – Право на удаление (E) – дает возможность удалять файлы в каталоге и подкаталогах. – Право на контроль доступа (A) – дает возможность опекуну назначать других опекунами данного каталога и подкаталогов, а также вносить изменения в IRF каталога и подкаталогов. Данное право не дает возможности предоставить кому-либо право супервизора на объект. – Право на просмотр (F) – дает право получить список файлов и подкаталогов данного каталога при просмотре. – Право на модифицирование (M) – дает возможность изменять атрибуты файлов и подкаталогов, включая их имена. Не дает право на модификацию содержимого файлов. Допустимые права на файл: – Право супервизора (S) – опекун получает все права на файл. Право S не может быть ограничено с помощью IRF. – Право на чтение (R) – опекун может открывать и читать файл. – Право на запись (W) – опекун может изменять содержимое существующего файла, открывая его для этого. – Право на создание (С) – опекун может восстановить удаленный файл, используя утилиту Salvage. – Право на удаление (E) – дает возможность удалить файл. – Право на контроль доступа (A) – дает возможность опекуну назначать других опекунами данного файла, а также вносить изменения в IRF файла. Данное право не дает возможности предоставить кому-либо право супервизора.
74
– Право на просмотр (F) – дает возможность видеть файл при просмотре содержимого каталога. – Право на модифицирование (M) – дает возможность изменять атрибуты файла, включая его имя. Допустимые права на объект: – Право супервизора (S) – опекун получает все права доступа к объекту, включая права доступа к его свойствам. В NDS право супервизора может быть ограничено IRF. – Право на просмотр (B) – предоставляет возможность видеть объект NDS при просмотре дерева. – Право на создание (C) – может предоставляться только для контейнерного объекта. Дает возможность создавать объекты внутри данного контейнерного объекта. – Право на удаление (D) – предоставляет опекуну возможность удалять объекты NDS. – Право на переименование (R) – позволяет переименовывать объекты. Допустимые права на свойства объекта: – Право супервизора (S) – опекун получает все права на свойства. В NDS право супервизора может быть ограничено IRF. – Право на чтение (R) – дает возможность читать значение свойства, а также выполнять сравнение значения свойства (при поиске). – Право на запись (W) – дает возможность дополнять, изменять и удалять значения свойства. Чтобы иметь возможность назначать опекунов объекта NDS, необходимо обладать правом записи или правом супервизора на свойство ACL объекта. – Право добавить или удалить себя (As) – дает возможность добавлять или удалять самого себя (как объект NDS) в качестве значения свойства.
Атрибуты ресурсов файловой системы для дополнительного ограничения прав доступа Как уже говорилось ранее, каждый ресурс файловой системы имеет специальные атрибуты файловой системы NetWare. Атрибуты имеют более высокий приоритет по сравнению с правами досту-
75
па. Атрибуты файлов и каталогов могут быть изменены лишь при наличии права модификации в качестве действительного права. В общем случае, атрибуты не наследуются. Атрибуты, которые обеспечивают дополнительное ограничение доступа: – Запрет копирования (Copy Inhibit, Ci) – запрет на копирование файла стандартными средствами. – Запрет удаления (Delete Inhibit, Di) – запрет на удаление файла или каталога стандартными средствами. – Только исполняемый (Execute Only, X) – возможен только запуск файла на выполнение, но не чтение или редактирование. – Скрытый (Hidden, H) – файл или каталог не виден при просмотре стандартными средствами работы с ресурсами файловой системы. – Только для чтения (Read Only, Ro) – файл или каталог доступен только для чтения его содержимого. – Запрет на переименование (Rename Inhibit, Ri) – файл или каталог не может быть переименован. Механизмы защищенного взаимодействия клиента и сервера Для обеспечения защищенности информационных ресурсов недостаточно просто назначить права доступа к ресурсам и обеспечить механизм аутентификации в сети. Необходимо обеспечить защищенный канал взаимодействия компонентов службы безопасности, выполняющихся на клиенте и сервере. Взаимодействие в процессе аутентификации Процесс аутентификации в сети на базе ОС Novell Netware использует симметричный и асимметричные варианты системы шифрования и выполняется по следующей схеме: 1. Клиентский процесс выдает запрос на обнаружение ближайшего сервера (Get_Nearest_Server) и после ответа сервера посылает ему запрос на аутентификацию. В запросе на аутентификацию указывается имя учетной записи пользователя. 2. Служба аутентификации (в составе NDS) направляет клиенту его частный ключ, который будет использоваться в асимметричной
76
схеме шифрования RSA. Частный ключ кодируется с использованием симметричной схемы шифрования (улучшенный вариант DES) паролем учетной записи, хранящимся в БД NDS. 3. Клиентский процесс делает попытку расшифровать полученный ключ, используя пароль, введенный пользователем в приглашении для входа в сеть. Если пароль был указан правильно, то частный ключ будет успешно декодирован и процедура аутентификации завершится успешно. После этого пароль пользователя удаляется из памяти рабочей станции и в дальнейшем используется частный ключ клиента. Обмен информацией между клиентом и сервером Если в системе используется передача сообщений с сигнатурами (параметр NCP Packet Signature сетевого программного обеспечения NetWare), то все сообщения от клиента к серверу и обратно будут сопровождаться цифровой подписью. Для каждого блока данных формируется контрольная сумма, которая затем кодируется с использованием частного ключа. После получения сообщения от клиента сервер декодирует сигнатуру, используя открытый ключ клиента (хранится в БД NDS). Затем подсчитывается КС сообщения и сравнивается со значением сигнатуры. При совпадении значений сервер считает данные от клиента достоверными. Аналогично выполняется процедура проверки при получении клиентом данных от сервера. Открытый ключ сервера при этом высылается в процессе аутентификации клиента в сети. При выполнении фоновой аутентификации на других серверах сети при доступе к ресурсам каждый раз создается защищенный сеанс связи клиент-сервер. Клиент выдает запрос на доступ к ресурсам, после чего сервер генерирует случайное число, кодирует его, используя асимметричную схему и открытый ключ клиента. Клиент получает это случайное число (идентификатор сеанса) и декодирует его. Затем, используя открытый ключ сервера, клиент формирует пакет с информацией о себе с учетом идентификатора сеанса и отсылает его на сервер. Последний проверяет подлинность информации и выдает подтверждение.
77
2.3.5. Установка NetWare
Установка серверной ОС NetWare выполняется в два этапа: I. Подготовительный этап Перед установкой сервера NetWare необходимо провести работу по планированию сетевой среды, а также выбрать стратегию именования объектов создаваемой сетевой среды на базе службы каталогов. Служба справочника NDS служит для регистрации и аутентификации в системе пользователей, а также отражения структуры организации или предприятия, где развертывается сеть NetWare. Поэтому прежде чем устанавливать сервер NetWare, нужно изучить структуру организации: какие подразделения имеются, какие информационные задачи решаются, как взаимодействуют работники подразделений и т.д. 1. Подготовить и установить компоненты аппаратного обеспечения. 2. Проверить работоспособность. 3. Обеспечить соответствие вычислительных ресурсов требованиям для устанавливаемой версии ОС. Для NetWare 4.11 рекомендуется ВУ с процессором не ниже i486 и 32 Мбайт памяти, а также SCSI-диск не менее 1Гбайт и сетевая карта PCI или EISA. 4. Подготовить список настроек установленных в ВУ аппаратных компонентов (прерывания, каналы DMA, порты ввода-вывода, занимаемые слоты локальной шины). II. Основной этап В зависимости от варианта установки (с CD-ROM, по сети и т.п.) некоторые действия могут выполняться по запросу программы установки. Возможные варианты установки: – с загружающегося CD-ROM; – из раздела DOS с локально подключенного накопителя CDROM; – из раздела DOS с CD-ROM, установленного в существующий сервер NetWare путем переназначения локального диска ВУ на том сервера NetWare; – из раздела DOS с CD-ROM, установленного в рабочую станцию путем запуска утилиты rconsole.exe.
78
Рассмотрим далее порядок установки ОС на чистую машину с локально подключенного накопителя CD-ROM: 1) загрузиться с системной дискеты DOS; 2) создать загружаемый раздел DOS – 50Mбайт; 3) установить поддержку CD-ROM под DOS; 4) запустить программу установки INSTALL.BAT с диска, содержащего дистрибутив NetWare, например C:\>E:\INSTALL.BAT; 5) указать имя создаваемого сервера, например TEST_NW; 6) задать внутренний номер IPX-сети (8-значное число в 16ричной системе счисления), например 12345678; 7) копирование файлов в каталог запуска, например, C:\NWSERVER; 8) указать код страны, кодовую страницу и раскладку клавиатуры; 9) задать дополнительные параметры в файле STARTUP.NSF (для ISA-архитектуры); 10) подтвердить модификацию файла autoexec.bat для автоматического запуска системы при включении питания ВУ; 11) запуск ядра системы и модуля установки INSTALL.NLM; 12) выбрать необходимый (ые) драйвер (ы) контроллера жесткого диска и указать дополнительные параметры (прерывание, порт), например AHA1540.DSK port=330; 13) выбрать необходимый (ые) драйвер (ы) сетевой платы и указать дополнительные параметры (прерывание, порт), например 3C5X9.LAN ISA port=340 frame=Ethernet_802.3; 14) загрузка драйверов дисковой памяти и сетевой платы; 15) задать протокол (ы) транспортного уровня, например, IPX, IP; 16) создать раздел (ы) Netware на диске (ах) сервера (рекомендуется выбрать режим Manually); 17) создать том (а) файловой системы, например SYS:, WORK:; 18) монтирование томов файловой системы, включая том на CDROM (например, NW411); 19) указать путь на дистрибутиве для копирования файлов ОС (обычно при успешном монтировании тома на CD-ROM достаточно подтвердить предложенное значение), например, NW411:\PRODUCTS\NW411\INSTALL\IBM\DOS\XXX\ENGLISH (для 4)11) и NW410:NW410\INSTALL\ENGLISH (для 4.10);
79
20) отредактировать при необходимости файлы STARTUP.NCF и AUTOEXEC.NCF; 21) копирование файлов на SYS: для обеспечения дальнейшей установки; 22) указать, будет ли служба NDS интегрироваться с существующим деревом или будет создано отдельное дерево (для создания нового дерева нажать Ins и ввести имя нового дерева, например EDU); 23) задать тип временного сервера и часовой пояс, а также настройки для летнего времени, например Secondary, TSK-7TSD;NO; 24) ввести название объекта-организации, например TSU, а также объекта-подразделения, в контексте которого будет создан новый объект-сервер, например INF. Задать пароль администратора нового дерева или ввести пароль (при включении в существующее дерево); 25) установить лицензии на сервер; 26) отредактировать конечный вариант файла STATUP.NCF; 27) отредактировать конечный вариант файла AUTOEXEC.NCF; 28) копирование файлов на SYS: в каталоги SYSTEM, PUBLIC, LOGIN и т.д.; 29) установить, если необходимо, дополнительные компоненты, например утилиту NWADMIN, NIAS, Web server или FTP Services; 30) для перезагрузки сервера выполнить команду DOWN, затем EXIT. Рассмотрим также порядок установки ОС на чистую машину с накопителя CD-ROM, подключенного к рабочей станции, с помощью утилиты rconsole.exe. Этапы установки на сервере: 1. Загрузиться с системной дискеты DOS. 2. Создать загружаемый раздел DOS – 50Mбайт. 3. Создать каталог NWSERVER и скопировать в него файлы для загрузки ядра ОС (содержимое каталога X:\..\BOOT на дистрибутивном CD-ROM) – прежде всего это server.exe, драйвер дисковой памяти, драйвер сетевой платы, модули remote, rspx, install и icmd. 4. Создать в каталоге NWSERVER файл autoexec.ncf примерно следующего содержания: file server name TEST_NW ipx internal net 12345678
80
load 3c5x9 isa port=340 frame=ethernet_802.3 bind ipx to 3c5x9 net=103 load remote <пароль для rconsole> load rspx 5. Запустить мини-ядро ОС путем загрузки программы SERVER.EXE (желательно в DOS минимальной конфигурации); Этапы установки на рабочей станции: 1. Если еще нет, то установить поддержку CD-ROM. 2. Установить на рабочую станцию клиента ОС NetWare (с дистрибутива ОС NetWare) – прежде всего lsl, драйвер сетевой платы и ipxodi. 3. Скопировать файл rconsole.exe и rsonsole.msg в каталог с клиентским ПО (с дистрибутива ОС NetWare). 4. Загрузить в память lsl, драйвер сетевой платы, ipxodi, а затем rconsole.exe. 5. Выбрать в списке доступных серверов новый сервер (TEST_NW), нажать [Enter] и ввести пароль для доступа к консоли. 6. Находясь в окне с приглашением системы, набрать load install для запуска модуля установки. 7. Вручную выполнить этапы установки, начиная с 10-го этапа варианта установки с локального CD-ROM. Для этого нужно последовательно выбирать элементы меню модуля INSTALL и вводить запрашиваемую информацию. 8. При запросе пути для копирования системных файлов нужно нажать [F4] и указать путь на дистрибутивном CD-ROM, задав в качестве имени диска локальное имя CD-ROM на рабочей станции, например D:\ PRODUCTS\NW411\INSTALL\IBM\DOS\XXX\ENGLISH. Установка пакетов поддержки После выхода коммерческой версии ОС возможно выявление ошибок в работе компонент ОС, не обнаруженных на этапе betaтестирования. C целью устранения этих ошибок фирма Novell выпускает пакеты поддержки (support packs). (!)
Перед установкой пакета поддержки на работающий сервер крайне рекомендуется выполнить полное резервное копирование системных файлов.
81
Для установки пакета поддержки необходимо: 1. Скопировать дистрибутив пакета на том сервера (если он не на CD-ROM). 2. C консоли сервера запустить модуль INSTALL. 3. Выбрать Products Options, а затем Install Product not listed. Указать путь к дистрибутиву пакета на томе, например WORK: DISTRIB\IWSP6. 4. Выбрать опции для установки пакета (например, нужно ли делать резервную копию замещаемых файлов системы). 5. После установки пакета поддержки необходимо перезапустить сервер и проверить его работоспособность. 2.3.6. Средства администрирования NetWare
Для выполнения администратором своих функций в ИВС на основе NetWare предусмотрены следующие средства администрирования: – Консоль сервера. – Утилита RCONSOLE. – Утилита NetWare Administrator. – Утилита NDS Manager. Консоль сервера. Команды и утилиты консоли Консоль сервера Netware служит для мониторинга работы служб, запущенных на сервере, для запуска и выгрузки служб, для завершения работы сервера. После запуска ОС на консоли сервера функционируют одна и более задач с текстовым интерфейсом. Каждой задаче принадлежит 0 и более экранов. Переключение между экранами задач выполняется клавишами [Alt]+[Esc] или [Ctrl]+[Esc] с последующим выбором необходимого экрана клавишей-цифрой. Задачи, имеющие экран: Системная консоль – в экране этой задачи отображаются все системные сообщения, также здесь присутствует приглашение для ввода команд консоли в виде <имя сервера>:, например TEST_NW:. Задача Monitor – позволяет получить сведения о работе сервера, в частности о количестве активных клиентских подключений; объе-
82
ме кэш-буферов, в том числе выделенных, свободных и использующихся в текущий момент; статистику о работе сетевых плат, загруженности процессоров ВУ и т.д. Задача PSERVER – сервер печати, обслуживающий подключенный к серверу принтер или сетевой принтер, и позволяющий получить информацию о количестве заданий в очереди на печать, количестве обслуживаемых принтеров и их текущем состоянии и т.д. Основные команды консоли: – LOAD <имя модуля>/UNLOAD <имя модуля> – загрузка/выгрузка NLM-модуля, в том числе драйверов контроллеров дисков, сетевых плат, пространств имен. – BIND <имя протокола> TO <имя сетевой платы> /UNBIND <имя протокола> – привязка протокола транспортного уровня к сетевой плате / отключение протокола. – MOUNT <имя тома>/DISMOUNT <имя тома> – монтирование/ размонтирование тома. – ENABLE/DISABLE LOGIN – разрешение/запрещение подключения к данному серверу. При выполнении некоторых операций на сервере, например, восстановление тома, рекомендуется запретить на время работ доступ пользователей к ресурсам сервера. – BROADCAST/SEND «сообщение» [TO <номер подключения>, …] – отправить сообщение всем рабочим станциям, подключенным к серверу, или на рабочую станцию с определенным номером подключения. – DISPLAY SERVERS – отобразить известные серверы и их удаленность от данного сервера. Отображаются все известные системе серверы и службы, использующие протокол оповещения SAP. – DISPLAY NETWORKS – отобразить известные внутреннему маршрутизатору IPX-сети и сетевые адреса, в том числе внутренние, являющиеся IPX-именами серверов Netware, а также количество переприемов пакетов или «прыжков»(Hops) в тиках таймера (тик таймера равен 1/18 с) для достижения этих сетей. Переприем пакета происходит при преодолении маршрутизатора. – DOWN – завершить работу сервера, очистив кэш-буфера, размонтировав все тома и закрыв БД NDS. – EXIT – вернуться в DOS после завершения работы сервера. – HELP – получить список всех команд консоли.
83
Основные утилиты сервера: Monitor – служит для контроля работы сервера, получения актуальной информации о загруженности процессоров (Utilization), расходовании памяти (Original/Current/Dirty Cache Buffers), статистике работы сетевых плат (кол-во переданных/принятых пакетов, ошибки CRC и т.д.), активных подключениях к серверу. Install – служит для установки компонентов ОС (драйверов внешней памяти и сетевых плат, служб ОС, включая NDS), установки продуктов третьих фирм, а также для управления разделами и томами NetWare, просмотра и редактирования командных файлов STARTUP и AUTOEXEC. Vrepair – служит для восстановления томов после сбоев при невозможности их монтирования, а также для удаления информации о пространстве имен. DSRepair – служит для восстановления, а также принудительной синхронизации реплик разделов NDS, находящихся на данном сервере. Утилита RCONSOLE Эта утилита позволяет получить доступ к консоли сервера с рабочей станции сети. Для этого на сервере NetWare необходимо загрузить модуль REMOTE, указав при запуске пароль для доступа к консоли, а также модуль RSPX. Теперь, находясь за консолью рабочей станции, необходимо запустить на выполнение файл RCONSOLE.EXE из каталога SYS:\PUBLIC. Затем выбрать в меню необходимый тип соединения, например, SPX (возможно также удаленное подключение через телефонную линию). В появившемся списке доступных серверов выбрать необходимый сервер, например TEST_NW, и указать пароль для доступа к консоли. После этого на экране рабочей станции появится активное окно физической консоли сервера. Для управления сервером с удаленной консоли используется следующий порядок: 1. Нажатие комбинации клавиш [Alt]+[F1] приводит к появлению специального меню утилиты RCONSOLE. 2. В этом меню выбирается необходимая команда. 3. Кроме этого, для завершения удаленной сессии с сервером можно нажать [Alt]+[F2]. Для переключения окон на физической консоли сервера используйте комбинацию [Alt]+[F4].
84
Утилита NetWare Administrator Эта утилита используется для управления всеми ресурсами сети на основе NetWare. Управление ресурсами заключается в создании и поддержании логической структуры дерева NDS. Утилита NetWare Administrator для платформы Win32 располагается в файле NWADMN32.EXE в каталоге SYS:\PUBLIC\WIN32. Утилита NDS Manager Эта утилита обеспечивает управление физической структурой NDS, включая создание разделов, создание и изменение типов реплик разделов, проверку целостности БД NDS, установку расширений схемы NDS. Утилита NDS Manager для платформы Win32 располагается в файле NDSMGR32.EXE в каталоге SYS:\PUBLIC\WIN32. 2.3.7. Подключение пользователей к сети NetWare
После установки и настройки сервера под управлением NetWare выполняются установка и настройка клиентской части сетевого ПО на рабочие станции сети, с которых пользователи будут входить в сеть на основе NetWare. После установки и настройки клиентского ПО администратор выполняет регистрацию пользователей и проводит настройку рабочей среды пользователей. Настройка клиентского программного обеспечения сетей NetWare После установки клиентской части сетевого программного обеспечения (далее «клиентское ПО») на рабочих станциях пользователей администратору может потребоваться выполнить настройку некоторых параметров клиентского ПО. Следующие параметры клиентского ПО имеют решающее значение для нормального функционирования сети: 1) Название дерева NDS. Для работы с ресурсами сети NetWare необходимо указать имя дерева NDS, в котором зарегистрирована учетная запись пользователя. 2) Текущий контекст. Для того чтобы работа пользователя в сети была более удобной, администратор указывает в качестве текущего контекста контекст учетной записи пользователя сети, либо
85
контекст основных объектов – ресурсов сети, с которыми работает пользователь. При входе в систему пользователю, помимо имени учетной записи и пароля, необходимо будет указывать название контейнерного объекта, который будет назначен текущим при работе с ресурсами сети. Если будет выбран контекст, отличный от контекста пользователя, то при входе нужно будет указывать полное имя учетной записи пользователя. 3) Настройка транспортного протокола. При установке клиентского ПО необходимо будет установить транспортный протокол SPX/IPX (обычно выполняется автоматически при установке ПО Novell Client for Netware). 4) Уровень использования цифровой подписи NCP-пакетов. Для обеспечения высокого уровня безопасности передаваемой по сети информации администратор может указать на сервере значение параметра NCP Signature Level = 3. При этом вводится обязательное подписывание всех пакетов, передаваемых между клиентом и сервером. Для того чтобы клиентское ПО могло взаимодействовать с таким сервером, необходимо указать уровень использования цифровой подписи не ниже 1 в настройках клиентского ПО. 5) Выполнение сценариев входа в сеть. Если администратор сети использует сценарии входа в сеть для настройки рабочей среды, то необходимо обеспечить выполнение этих сценариев при входе пользователей в сеть. Для этого нужно установить флажок «Выполнение сценариев входа в сеть» в настройках клиентского ПО. Регистрация пользователей Для регистрации пользователя в службе справочника NDS необходимо создать объект типа Пользователь. Для этого, используя утилиту NetWare Administrator, необходимо: 1) находясь в рамках определенного контейнерного объекта, выполнить команду Object->Create… , а затем выбрать в диалоговом окне тип создаваемого объекта Пользователь (User) и нажать кнопку ОК; 2) указать простое имя объекта (Login Name). Указать полное имя пользователя (Full Name); 3) выбрать объект типа Шаблон (Template), если пользователь будет создаваться на основе существующего объекта; 4) если необходимо, указать домашний каталог (Home Directory) пользователя (см. далее);
86
5) если необходимо, выставить флажок «Определить дополнительные атрибуты» (Define Additional Properties); 6) нажать кнопку Создать (Create); После создания учетной записи пользователя может потребоваться выполнение настройки рабочей среды пользователя. Свойства объекта типа Пользователь Основная часть настройки рабочей среды пользователя производится редактированием атрибутов соответствующего объекта типа Пользователь. Рассмотрим основные атрибуты: Язык (Language) – указывает, какой язык использовать в меню утилит и справочной системе. Имеет значение, если клиентское ПО поддерживает соответствующий язык. Домашний каталог (Home Directory) – каталог на сервере, где хранятся рабочие файлы и каталоги пользователя. Обычно при создании пользователя указывается, где будет находиться домашний каталог, и пользователь автоматически назначается опекуном своего домашнего каталога с максимальными правами (S,R,W,C,E,M,F,A). Чтобы при создании пользователя на домашний каталог назначались другие права, необходимо сначала создать объект типа Шаблон и указать, какими опекунскими правами на домашний каталог наделять пользователя. Ограничения (Restrictions) – группа свойств, обеспечивающих задание определенных ограничений на использование учетной записи: – дата истечения действия учетной записи – дата, после которой вход в систему будет блокирован; – максимальное число одновременных подключений – количество станций сети, с которых возможна одновременная работа под указанной учетной записью; – разрешение на смену пароля, минимальный размер пароля, ограничение на время действия пароля, разрешение на использование пароля, срок действия которого истек; – ограничение по времени работы в сети; – ограничение на адреса рабочих станций сети, с которых возможна работа в сети.
87
Настройки печати – группа свойств, которые обеспечивают создание конфигураций заданий на печать для пользователя с определенными настройками (количество копий, заголовок, режим оповещения о завершении печати и т.д.). Используются в утилите CAPTURE. Права на файлы и каталоги – не являются фактически свойством объекта. Позволяют определить индивидуальные права доступа пользователя к файловым ресурсам сети. Права на объекты и свойства объектов NDS – не являются фактически свойством объекта. Позволяют определить индивидуальные права доступа пользователя к ресурсам сети – объектам NDS. Членство в группах и эквивалентность в правах (Group Membership and Security Equivalence) – обеспечивают удобный механизм назначения прав доступа пользователю путем установления эквивалентности прав. Сценарии входа в сеть Дополнительно для настройки рабочей среды пользователя используются сценарии входа в сеть (Login Scripts). Существуют следующие типы сценариев: Системный – в этом сценарии определяются глобальные условия среды, общие для всех пользователей, принадлежащих определенному контейнеру. Сценарий данного типа не обязателен, но если определен, то выполняется в обязательном порядке для всех пользователей данного контейнерного объекта. Редактируется путем изменения свойства Login Script контейнерного объекта. Профильный – сценарий данного типа не обязателен. Устанавливается путем создания объекта типа Профиль (Profile) и назначения этого профиля пользователю. Пользователю может быть назначен только один объект Профиль. Местонахождение профиля и пользователя в дереве NDS значения не имеет. Позволяет задать одинаковую рабочую среду для группы пользователей. Редактируется путем изменения свойства Login Script объекта Профиль. Пользовательский – определяет уникальные для пользователя настройки рабочей среды. Редактируется путем изменения свойства Login Script объекта User. По умолчанию – выполняется, если для пользователя не создан его собственный пользовательский сценарий. Хранится в файле LOGIN.EXE (и в клиентском ПО) и не может быть изменен.
88
Когда пользователь, используя клиентское ПО, входит в сеть, выполняется один и более сценариев входа в сеть в следующем порядке: 1) системный; 2) профильный; 3) пользовательский или по умолчанию. Команды, использующиеся в сценариях входа в сеть: – #<путь к программе\имя программы> [параметры] – вызов внешней программы; – EXIT [«<имя программы>»] – выход с возможным запуском программы; – WRITE «<сообщение>» – вывод строки; – MAP – выполнение команды назначения сетевого ресурса на локальный диск рабочей станции, позволяет задать параметры отображения назначений дисков; – IF <условие> THEN <команды> [ELSE <команды>] END – задание условия на выполнение команды сценария; – REM – комментарий; – DRIVE <буква>: – установить текущий диск. Назначение сетевых и поисковых дисков Для удобства работы пользователя система предусматривает назначение сетевых ресурсов на локальные диски рабочей станции. Возможно два варианта назначения: 1) назначение обычного сетевого диска – позволяет получать доступ к сетевым файловым ресурсам, используя букву локального диска, обеспечивает разбиение ресурсов по категориям. <буква>: = <том_сервера>\<каталог>\..\<каталог> 2) назначение поискового диска – позволяет определить назначение сетевого диска и добавить имя сетевого диска в переменную среды PATH. Это обеспечивает запуск программ, находящихся на сервере, без указания пути к файлу. Буква создаваемого логического диска создается автоматически, начиная с Z:, затем Y: и так далее. <буква>: = <том_сервера>\<каталог>\..\<каталог> и SET PATH=<буква>:.;%PATH% В путь поиска прописывается буква логического диска с ука(!) занием символа текущего каталога на этом диске (например, Z: . ), поэтому при смене текущего каталога на данном диске путь поиска будет ссылаться на другой каталог.
89
Для назначения сетевых дисков используется команда MAP. Формат команды MAP: MAP [параметры] [<диск>:= <путь>] Если диск обычный (не поисковый), то вместо <диск> подставляется буква локального диска, иначе строка Sn, где n=1..16. Номер n указывает позицию (порядок просмотра при поиске) в переменной PATH, куда нужно подставлять создаваемый диск. Параметры команды MAP: DISPLAY ON/OFF – переключатель вывода на экран всех назначений дисков (A: – Z:) ERRORS ON/OFF – переключатель вывода ошибок INS – добавление (а не замена) буквы диска в переменную PATH DEL – удаление диска ROOT – определение логического диска с корневым каталогом Примеры команды MAP. MAP ROOT H:=TEST_NW\WORK:USERS\ADMIN1 MAP S1:=SYS:PUBLIC MAP INS S16:=SYS:PUBLIC\OS\MSDOS\622 Переменные времени выполнения сценария входа в сеть Если переменная используется в сценарии, то для получения значения переменной используется символ % перед названием переменной. Существует несколько категорий переменных времени выполнения: дата – DAY (1..31) – NDAY_OF_WEEK (1..7) – MONTH (1..12) время – GREETING_TIME – HOUR24 (0..23) пользователь – FULL_NAME – LAST_NAME – LOGIN_NAME – MEMBER OF «<имя группы>» рабочая станция – MACHINE – OS – OS_VERSION
90
– Среда DOS Пример сценария входа в сеть MAP DISPLAY OFF WRITE «Здравствуйте, %FULL_NAME !!!» MAP INS S1:=SYS:PUBLIC MAP ROOT H:=WORK:USERS\ADMIN\%LOGIN_NAME DRIVE H: IF MEMBER OF «ASU» THEN MAP ROOT T:=WORK:PRODUCTS ELSE MAP ROOT S:=WORK:ARM END EXIT «WIN.BAT»
91
2.4. Microsoft Windows NT Server Операционная система Microsoft Windows NT Server относится к семейству ОС Windows, точнее ветви ОС Windows NT – высоконадежных универсальных ОС для серверов и рабочих станций. В следующих разделах на примере ОС Microsoft Windows NT Server версии 4.0 будут рассмотрены особенности архитектуры, основные службы и вопросы администрирования всего семейства ОС Windows NT (далее «Windows NT»). Где это необходимо, будет явно указано на особенности, свойственные именно ОС Windows NT Server. 2.4.1. Общие вопросы
История и версии Windows NT ОС Windows NT является наследницей ОС Microsoft OS/2 1.x, точнее она разрабатывалась как аппаратно-независимая версия OS/2 (с рабочим номером версии 3). После успеха Windows 3.0, Microsoft перестала заниматься разработкой OS/2 (OS/2 разрабатывалась совместно с IBM), а свою новую ОС переименовала в Windows NT. С момента выпуска ОС Windows NT существуют два варианта комплектации с единым ядром: Server – в качестве серверной ОС и Workstation – ОС для высокопроизводительных рабочих станций (количество одновременных подключений при использовании в качестве сервера какой-либо службы ограничено 10). Рассмотрим далее особенности существующих версий Windows NT. Windows NT 3.1 и Windows NT 3.1 Advanced Server Появились в 1993 г. Заложены базовые концепции ОС нового поколения (NT – сокращение от New Technology): встроенная поддержка SMP и независимость от аппаратной платформы, встроенная поддержка сети (наследие продукта LAN Manager for OS/2) и система безопасности. Полностью 32-разрядная ОС с вытесняющей многозадачностью. Знакомый графический интерфейс Windows 3.1. Программный интерфейс Win32 API. Плохая поддержка сетей NetWare (только протокол NWLINK, программно совместимый с SPX/IPX).
92
Windows NT Workstation/Server 3.5 (3.51) Появились в 1994 г. Доверительные отношения между доменами позволили говорить о Windows NT как об ОС для сетей масштаба предприятия. Улучшенная поддержка сети Internet (службы DHCP, FTP, WINS, RAS с поддержкой SLIP и PPP). Улучшены механизмы взаимодействия с NetWare (встроенный клиент сетей NetWare 3.x). Windows NT Workstation/Server 4.0 Появились в 1996 г. Новый графический интерфейс Windows 95. Более эффективная графическая подсистема за счет изменений в архитектуре Windows NT 4.0: менеджер окон (модуль User) , библиотека графического интерфейса (модуль GDI) и драйверы графических устройств из процесса-сервера Win32 перенесены в микроядро. Это потенциально увеличило вероятность сбоев и отказов в системе из-за некорректно написанных программных модулей, поставляемых третьими фирмами. Однако при этом значительно возросла скорость работы графических приложений. Улучшенная поддержка сети Internet (службы DHCP, FTP, WWW, DNS, WINS, RAS с поддержкой SLIP, PPP и PPTP). Улучшены механизмы взаимодействия с NetWare (встроенный клиент для сетей NetWare 4.x). Windows 2000 Professional/Server/Advanced Server В продаже с февраля 2000 г. Фактически новая версия ОС Windows NT (версия 5) с названием в стиле «Windows 9x». Новая версия файловой системы NTFS с поддержкой квотирования дискового пространства и динамического управления томами. Распределенная файловая система (DFS) обеспечивает прозрачный доступ к сетевым ресурсам независимо от их физического местоположения. Пересмотренная система безопасности: подсистема аутентификации обеспечивает встроенную поддержку двух механизмов аутентификации – NT/LAN Manager и Kerberos, сертификаты Интернет (x.509), туннелирование (L2TP, PPTP, IPSec), файловая система шифрования и другие механизмы. Новая служба справочника масштаба предприятия Active Directory (Server и Advanced Server). Единая утилита управления Microsoft Management Console. Встроенная служба терминального доступа для удаленного управления сервером (ср. RConcole в NetWare) и запуска приложений (архитектура «сверхтонкого» клиента). Новая модель драйверов, поддержка Plug-n-Play и нового оборудования. Полная реализация объектной модели взаимодействия COM+. Кластерные технологии для обеспе-
93
чения отказоустойчивости и высокодоступности (только Advanced Server). Особенности Windows NT, не зависящие от версии Основные особенности ОС Windows NT были заложены еще при проектировании ОС и сохранились неизменными во всех версиях ОС. Это: Расширяемость – обеспечивается модульной и уровневой архитектурой на основе микроядра. Масштабируемость – обеспечивается поддержкой SMP-систем. Нити системных и пользовательских процессов могут распределяться для выполнения на любом из доступных процессоров. Переносимость – обеспечивается поддержкой различных аппаратных платформ. Замена уровня аппаратных абстракций (HAL) и перекомпиляция на новой аппаратной платформе обеспечивают полную переносимость ОС и приложений. Защищенность – обеспечивается встроенной на уровне ядра системой безопасности. Поддержка распределенной обработки – встроенные сетевые возможности: транспортные протоколы TCP/IP, NetBEUI, IPX/SPX, DLC; программные интерфейсы Named Pipes, Remote Procedure Call (RPC), Windows Sockets, Mail Slots. Открытость – модульный подход, основанный на архитектуре WOSA и спецификации NDIS, позволяет легко расширять функциональные возможности. Объектная парадигма – все ресурсы описываются как объекты, доступ к которым осуществляется путем указания дескриптора, получаемого при создании экземпляра объекта. Надежность и отказоустойчивость – обеспечивается программной и аппаратной поддержкой RAID, ИБП, файловой системой транзакционного типа. Надежность обеспечивается также следующими архитектурными особенностями: 1) ОС на основе микроядра. Значительная часть модулей ОС функционирует в пользовательском режиме процессора, а в привилегированном режиме выполняется только код, обеспечивающий управление аппаратурой, а также низкоуровневые функции ОС – управление памятью, переключение между процессами. 2) ОС с архитектурой клиент-сервер. Процессы, работающие в пользовательском режиме, взаимодействуют между собой путем
94
выдачи и обработки запросов. Компонентный подход позволяет вносить изменения локально в каждую подсистему, не затрагивая других частей системы. 3) Использование объектов на уровне ядра системы. Объекты всех типов имеют заголовок единого формата, который используется для централизованного выполнения операций, например, для проверки прав доступа к объекту. Модульная структура Windows NT ОС Windows NT построена по модульному принципу и использует преимущества современных процессоров, позволяющих разделять пользовательские процессы и процессы, функционирующие в режиме ядра. В кольце 0 выполняются специальные процессы ОС – диспетчеры, а в кольце 3 – различные подсистемы (службы) и прикладные процессы. Основные модули ОС: Уровень аппаратных абстракций (файл HAL.DLL) – виртуализирует аппаратные интерфейсы для остальных частей ОС (в том числе ядра и драйверов устройств). Обеспечивает независимость остальной части ОС от конкретных аппаратных особенностей. Ядро (файл NTOSKRNL.EXE) – является основой модульного строения ОС, координирует работу всех частей ОС. Занимается диспетчеризацией нитей (потоков), планируя таким образом работу процессора. Запускается по одной копии на процессор и обеспечивает синхронизацию работы процессоров в SMP-системах. Выполняет обработку аппаратных прерываний и исключительных ситуаций. Исполняющая система – обеспечивает общий сервис системы посредством программных интерфейсов, которые могут использовать подсистемы среды. Состоит из составляющих, каждая из которых предназначена для определенного системного сервиса: диспетчер объектов, диспетчер виртуальной памяти, диспетчер процессов, диспетчер ввода-вывода, монитор безопасности, средство вызова локальных процедур. Защищенные подсистемы среды – Win32, Windows-On-Windows (WOW) / Win16, Virtual DOS Machine (VDM) и т. д. Обеспечивают запуск соответствующих приложений в изолированной защищенной среде. Подсистема Win32 является основной. Она отвечает также за управление клавиатурой, мышью и экранным вводом-выводом для всех других подсистем, получение и доставку системных сообщений. Как уже было сказано ранее, часть подсистемы Win32, отве-
95
чающая за графический ввод-вывод, выполняется на уровне ядра. На пользовательском уровне находятся функции-заглушки, обеспечивающие программный интерфейс для приложений (рис. 7).
сетевые/локальные драйверы
Рис. 7. Архитектура Windows NT
Службы Windows NT Особенностью ОС Windows NT являются службы Windows NT. Службы Windows NT (Windows NT Services) – это программные компоненты в составе Windows NT, либо устанавливающиеся дополнительно в составе серверного или клиент-серверного ПО для выполнения определенных задач. Службы могут запускаться автоматически при запуске ОС на ВУ, либо вручную утилитой Server Manager. В отличие от обычного Win32-приложения, служба, запущенная автоматически, выполняется от имени учетной записи са-
96
мой ВУ (см. далее раздел «Служба справочника») и не требует для запуска предварительного выполнения процедуры локальной аутентификации на ВУ с установленной ОС Windows NT. Примеры служб Windows NT: Workstation (клиентская часть сетевого ПО сети Microsoft Network), Server (серверная часть сетевого ПО сети Microsoft Network), Net Logon (служба для проведения локальной аутентификации), Spooler (служба для выполнения печати), Microsoft DNS Server (служба DNS-сервера). Системный реестр Системный реестр (Registry), являющийся универсальным хранилищем настроек ОС и приложений, пришел на смену многочисленным INI-файлам, использовавшимся в Windows 3.x. Использование реестра значительно снизило трудоемкость сопровождения системы, обеспечило безопасную, унифицированную БД о конфигурации аппаратных и программных средств, пользователях и других ресурсах системы. Все компоненты Windows NT, ответственные за настройку и использование программно-аппаратной среды, обращаются к реестру. К таким компонентам относятся: программа распознавания и проверки работоспособности оборудования, ядро ОС, драйверы устройств, службы Windows NT, утилиты администрирования, программы установки компонент ОС и приложений третьих фирм. Логическая структура Логическая структура реестра имеет древовидный характер, похожа на логическую структуру файловой системы и состоит из следующих элементов: Ключи (ср. c томами или логическими дисками) – обеспечивают разбиение информации на функциональные группы. Подключи (ср. с подкаталогами) – для группировки информации, хранящейся в реестре. Значимые элементы (ср. с файлами) – являются элементарными единицами информации, представленной в реестре. Ключи реестра: – HKEY_LOCAL_MACHINE – содержит информацию о локальной ВУ, включая аппаратные средства и данные ОС, такие как тип шины, системная память, драйверы устройств и данные управления запуском. Содержит следующие основные подключи:
97
– HKEY_LOCAL_MACHINE\SAM – подключ с информацией службы справочника; – HKEY_LOCAL_MACHINE\SECURITY – подключ с информацией cистемы безопасности (политики локальной безопасности или привилегии доступа); – HKEY_LOCAL_MACHINE\SOFTWARE – подключ с информацией о программных компонентах ОС (преимущественно пользовательского уровня) и установленных приложениях; – HKEY_LOCAL_MACHINE\SYSTEM – подключ с информацией о программных компонентах ОС уровня исполняющей системы; – HKEY_LOCAL_MACHINE\HARDWARE – подключ с информацией об аппаратных средствах ВУ. – HKEY_CLASSES_ROOT – содержит данные об объектах связи и внедрения (OLE) и данные для связи файловых классов. – HKEY_CURRENT_USER – содержит информацию о профиле пользователя, успешно прошедшего локальную аутентификацию в системе, включая системные переменные, настройки рабочего стола, настройки программного обеспечения, активные сетевые соединения, установленные принтеры и приложения. Если в ключах HKEY_CURRENT_USER и HKEY_LOCAL_MACHINE есть совпадающие подключи и значимые элементы, то больший приоритет имеют значения, указанные в ключе HKEY_CURRENT_USER. Кроме этого, значения в HKEY_CURRENT_USER могут просто хранить дополнительную информацию о подключах, указанных в HKEY_LOCAL_MACHINE (чаще всего личные настройки приложений). – HKEY_USERS – содержит все активно загруженные в оперативную память профили пользователей, включая профиль HKEY_CURRENT_USER и системный (HKEY_USERS\.DEFAULT). Профили пользователей, подключающихся к ресурсам данного компьютера по сети, в этом ключе не присутствуют. – HKEY_CURRENT_CONFIG – содержит информацию о текущей конфигурации компьютера (только для Windows NT 4.0). – HKEY_DYN_DATA – содержит динамическую информацию о системе (только для Windows NT 4.0). Информация, представленная в реестре, делится на статическую и динамическую. Статическая информация хранится на жестком диске ВУ, а динамическая – формируется при каждой загрузке
98
Windows NT, хранится в оперативной памяти ВУ и действительна только в течение одного сеанса работы с системой. Физическая структура Физическая структура реестра представлена ульями. Улей – это часть реестра, хранящая информацию об определенных ключах и подключах реестра. Улей представлен на диске одним и более файлами (для обеспечения надежности). Файлы ульев реестра хранятся в каталоге %SystemRoot%\SYSTEM32\CONFIG (значение по умолчанию), файлы ульев для профилей пользователей хранятся в файлах %SystemRoot%\Profiles\%USERNAME%\ ntconfig.dat (значение по умолчанию), где %USERNAME% – имя учетной записи пользователя. Ульи реестра: – SAM – хранит информацию подключа HKEY_LOCAL_MACHINE\SAM. – SECURITY – хранит информацию подключа HKEY_LOCAL_MACHINE\SECURITY. – SOFTWARE – хранит информацию подключа HKEY_LOCAL_MACHINE\SOFTWARE. – SYSTEM – хранит информацию подключа HKEY_LOCAL_MACHINE\SYSTEM. –
– хранит информацию подключа HKEY_CURRENT_USER. – DEFAULT – хранит информацию подключа HKEY_USERS\.DEFAULT. Для обеспечения надежности информация записывается в ульи в режиме транзакций. Для обеспечения защищенности информации, хранящейся в реестре, для доступа к тому или иному элементу реестра могут быть назначены определенные права доступа. Для просмотра и изменения содержимого реестра используется утилита Registry Editor, точнее два варианта этой утилиты: Regedit.exe и Regedt32.exe. Первая позволяет сохранять содержимое подключей реестра в виде текстовых сценариев (файлы с расширением reg) и впоследствии импортировать их. Вторая позволяет сохранять и затем восстанавливать содержимое подключей реестра, включая права доступа к элементам реестра, в виде двоичных фай-
99
лов (файлы с расширением dat), просматривать и менять права доступа к элементам реестра. Организация внешней памяти на ВУ под управлением Windows NT ОС Windows NT поддерживает следующие файловые системы на жестких дисках ВУ: FAT, NTFS. Она может быть установлена на томе любой из поддерживаемых файловых систем, однако рекомендуется устанавливать систему на томе NTFS, так как это обеспечит защиту файлов ОС от случайной или умышленной порчи. Все файлы ОС Windows NT располагаются обычно в каталоге WINNT, расположенном на томе файловой системы, выбранном для установки файлов ОС. Последовательность запуска сервера под управлением Windows NT 1. Включение электропитания на сервере. 2. После загрузки в память загрузочной записи (Boot Record) активного раздела, система ищет в этом разделе загрузчик ОС (файл NTLDR) и загружает его в память. 3. Загрузчик ОС выполняет загрузку в память программы NTDETECT.COM, которая выполняет анализ аппаратной конфигурации ВУ и готовит данные для динамических ключей реестра HKEY_CURRENT_CONFIG и HKEY_LOCAL_MACHINE\HARDWARE. 4. Затем загрузчик читает файл BOOT.INI и определяет местонахождение системы (том и каталог с файлами операционной системы). Система отображает меню на основе содержимого файла BOOT.INI, которое позволяет выбрать систему для загрузки. Пример файла BOOT.INI: [boot loader] timeout=10 default=multi(0)disk(0)rdisk(0)partition(1)\WINNT [operating systems] Multi(0)disk(0)rdisk(0)partition(1)\WINNT=«Windows NT Server Version 4.0» C:\=«MS DOS»
100
Для загрузки ОС, отличной от NT, необходимо присутствие файла BOOTSECT.DOS с загрузочным сектором соответствующей ОС. 5. После выбора системы загрузчик формирует переменную среды %SystemRoot% на основе строки, указанной в файле BOOT.INI, а затем ищет и загружает в память микроядро ОС (файл %SystemRoot%\system32\ntoskrnl.exe). Микроядро переводит процессор в защищенный режим, а затем на основе данных из улья SYSTEM выполняется загрузка драйверов и диспетчеров в режиме ядра (на основе информации в подключе Local_Machine\SYSTEM\ControlSet\Services). Если необходимо, выполняется проверка или преобразование томов файловой системы. Затем запускается служба транзакций и выполняется обработка журнала транзакций. После этого выполняется обработка улья SOFTWARE и загрузка всех служб пользовательского режима (на основе информации в подключе Local_Machine\SYSTEM\ControlSet\Services), включая подсистему Win32, обеспечивающую графический интерфейс пользователя. 6. Наконец, подсистема Win32 запускает процесс входа в систему (Logon Process), который загружает в память системный профиль (см. далее раздел «Профили пользователей») и отображает приглашение для входа. К моменту появления приглашения для входа некоторые службы ОС могут еще находиться в процессе загрузки. Завершение работы сервера под управлением Windows NT 1. Находясь за консолью сервера, необходимо нажать комбинацию клавиш Ctrl+Alt+Del. 2. Нажать в диалоговом окне кнопку Завершить работу (Shut Down). 3. Система генерирует сообщение о завершении работы и рассылает его всем подсистемам. 4. Содержимое кэш-буферов записывается на диск: отрабатывают система транзакций и диспетчер кэша.
101
5. После появления сообщения «Теперь можно выключить питание» (Now You can turn off the power) можно выключить питание сервера.
102
2.4.2. Файловая система NTFS
ОС Windows NT имеет встроенную поддержку следующих файловых систем: FAT16 (с длинными именами), NTFS (см. далее), CDFS (на дисках CD-ROM), MSFS и NPFS (для связи между процессами). Есть также драйверы третьих производителей для поддержки HPFS, NetWare FAT, FAT32. Благодаря модульной архитектуре Windows NT для обеспечения поддержки новой файловой системы достаточно разработать новый драйвер режима ядра и провайдер именования ресурсов, который выполняется в пользовательском режиме под управлением подсистемы Win32. Все файловые системы используют одни и те же программные модули в составе диспетчера ввода/вывода для взаимодействия с остальными частями ОС. Организация диспетчера ввода-вывода Диспетчер ввода-вывода является частью исполняющей системы Windows NT и управляет всеми операциями ввода-вывода. Любая установленная в системе файловая система будет иметь доступ ко всем компонентам диспетчера, включая диспетчер кэша, диспетчер очередей запросов и т.д. Это значительно упрощает решение задачи по реализации функций файловой системы разработчикам системного ПО. Более того, любой редиректор (клиентская компонента сетевого ПО, см. раздел «Сетевое ПО»), а также серверная компонента сетевого ПО определенной сетевой службы прикладного уровня также реализуется как файловая система. Это обеспечивает унифицированный доступ к файловым ресурсам, расположенным как на локальной ВУ, так и на ВУ сети. Основная компонента в составе диспетчера ввода/вывода – диспетчер кэша – обеспечивает работу файловых систем в режиме отложенной записи (lazy write) и отложенной фиксации (lazy commit), что значительно увеличивает эффективность файловой системы. Отложенная запись означает, что запись изменений в некоторый файл происходит в кэш-памяти, и только по истечении некоторого времени содержимое кэш-памяти сбрасывается на диск. Аналогично происходит отложенная фиксация: завершение транзакции помечается в памяти, и только по истечении некоторого времени, когда
103
освобождается процессор, информация о завершении транзакции будет сохранена в журнале транзакций (справедливо только для файловой системы NTFS). Далее будет рассмотрена файловая система NTFS, как наиболее предпочтительная файловая система для обеспечения совместного использования ресурсов файловой системы. Характеристика файловой системы NTFS Файловая система NTFS обладает следующими возможностями: Более эффективная (по сравнению с FAT) поддержка дисков большой емкости – размер кластера (512/../65536 байт) задается при форматировании тома и не зависит напрямую от размера тома, как следствие – меньше подвержена фрагментации. Большая надежность – дублирование системных областей, равномерное распределение данных по диску – меньший износ, запись информации в режиме транзакций, поддержка горячего фиксирования (Hot Fix) – для томов с кластером не более 4096. Для NTFS возможно также создание отказоустойчивых томов, соответствующих спецификации RAID1 и RAID5. Быстрое восстановление в случае сбоев – запись всех изменений в журнал транзакций; вместо сканирования всего диска на предмет несогласованности данных сканируется журнал транзакций и выполняется завершение подтвержденных транзакций и откат неподтвержденных. Поддержка системы безопасности введением дескриптора безопасности для каждого ресурса (файла или каталога). Гибкость и удобство – естественная поддержка длинных имен, поддержка именования ресурсов в кодировке Unicode, встроенная поддержка динамического сжатия (для томов с кластером не более 4096) хранящейся на томе информации (регулируется на уровне отдельного ресурса – файла или каталога). Эффективный поиск ресурсов за счет реализации каталогов как индексов на основе B-деревьев.
104
Логическая структура NTFS Логическая структура NTFS полностью повторяет логическую структуру файловой системы FAT, включая именование логических дисков или томов файловой системы. Однако, хотя тома NTFS именуются, так же как и логические диски FAT, буквами латинского алфавита, сама ОС манипулирует не буквами, а внутренними именами, например Multi(0)Disk(0)Rdisk(0)Partition(1) и т.п. Файловая система NTFS – это объектная файловая система, основанная на атрибутах. Вся служебная и пользовательская информация файловой системы представлена в виде объектов-файлов (см. далее «Физическая организация»), характеризующихся атрибутами. Каждый объект-файл имеет стандартные атрибуты, например имя объекта, дата создания, размер, содержимое (или данные) и т.д. Кроме того, каждый ресурс (файл или каталог) может иметь дополнительные атрибуты. Прежде всего, к таким атрибутам относится дескриптор защиты, содержащий ACL объекта-файла (см. раздел «Служба безопасности» ), а также имя ресурса в записи 8.3 для DOS и Win16 приложений. Физическая организация NTFS Ресурсы файловой системы NTFS хранятся на жестких дисках в пределах томов NTFS в первичных или расширенных разделах. Пространство тома NTFS разделено на равные блоки, называемые кластерами. Местоположение кластера задается логическим номером (Logical Cluster Number – LCN). Вся информация на томе NTFS хранится в виде файлов, таким образом, все пространство на томе поделено между содержимым файлов и свободным пространством тома. Каждый файл на томе представлен записью в специальном файле MFT (Master File Table). Записи MFT имеют размер от 1 до 64 К и чаще всего совпадают с размером кластера тома. Небольшие по размеру файлы полностью хранятся в MFT, файлы большого размера – в так называемых фрагментах, на которые имеется ссылка из записи в файле MFT. Каждый атрибут файла NTFS имеет имя и значение. Каждый атрибут физически состоит из заголовка, где указывается тип атрибута (см. далее), а также его имя, смещение относительно заголовка атрибута и длина). Атрибуты файлов, хранящиеся в MFT, называ-
105
ются резидентными (имя файла, дата создания, размер). Остальные атрибуты файла называются нерезидентными (например, данные для большого файла и т.п.). Для нерезидентных атрибутов выделяются дополнительные блоки на диске, которые называются отрезками (Extents) и размер которых зависит от размера кластера тома (каждый отрезок может включать один или несколько кластеров). При увеличении размера нерезидентного атрибута выделяются дополнительные отрезки (максимум). Местоположение отрезков файла отслеживается при помощи виртуальных номеров кластеров (Virtual Cluster Number – VCN). Цепочка отрезков, принадлежащих нерезидентному атрибуту, восстанавливается при помощи таблицы отображения VCN->LCN, хранящейся в записи файла MFT в заголовке нерезидентного атрибута. Например, если в заголовке атрибута Данные находится таблица VCN LCN Число кластеров 0 1355 4 4 1588 4 8 1960 4 то это значит, что данные файла находятся в трех отрезках, занимающих кластеры с номерами 1355, 1356, 1357, 1358, 1588, …, 1960, …, 1963. Каталог файловой системы NTFS – это специальный файл, являющийся индексом имен файлов, имеющих в качестве префикса заданный путь. Для индексирования используется B+ дерево (двухуровневое дерево). Каждый каталог имеет следующие специфические для каталогов атрибуты: Корень индекса – содержит верхний уровень (корень) B+ дерева, в котором в лексикографическом порядке хранятся атрибуты-имена содержащихся в каталоге файлов, являющиеся индексами для второго уровня B+ дерева. С каждым именем файла в корне индекса связан необязательный указатель на индекс второго уровня, который размещается в дополнительном отрезке. Размещение индекса – в этом атрибуте хранится таблица отображения VCN->LCN для дополнительных отрезков, занимаемых индексом каталога. Битовая карта – служит для указания занятости каждого VCN в дополнительных отрезках, занимаемых индексом каталога.
106
MFT содержит следующие записи: № запиНазначение записи си 1 Запись, описывающая собственно сам файл MFT (с именем $MFT). 2 Запись файла $MFTMirr, хранящего копию первых 16 записей файла MFT. 3 Запись файла $LogFile журнала транзакций. 4 Запись файла $AttrDef с таблицей определения атрибутов объектов файловой системы. 5 Запись файла $. С корневым каталогом тома. 6 Запись файла $Bitmap битовой карты тома, указывающего занятость кластеров на томе. 7 Запись файла $Boot, который содержит копию загрузочного сектора тома. 8 Запись файла $BadClus с плохими кластерами (в том числе переназначенными механизмом HotFix). 9 Запись файла $Volume, который содержит метку тома, версию NTFS, бит «том поврежден». … … 17 Записи пользовательских файлов и каталогов. и далее Первые 16 файлов являются системными и скрыты от просмотра стандартными средствами. Эти файлы содержат мета-данные тома. Для надежности, содержимое первых 16 записей MFT дублируется в файле $MFTMirr. Местоположение MFT и MFTMirr на диске указывается в секторе начальной загрузки NTFS-тома. Сам сектор начальной загрузки на диске дублируется (файл $Boot). 2.4.3. Сеть Microsoft Network и служба справочника Windows NT
При рассмотрении службы справочника в составе Windows NT необходимо представить концепцию построения сети с точки зрения компании Microsoft.
107
Сеть Microsoft Network Сеть Microsoft Network – это множество компьютеров с установленным сетевым ПО, поддерживающим совместное использование ресурсов по протоколу прикладного уровня SMB (Server Message Block). Сеть Microsoft Network может объединять компьютеры с установленными на них ОС DOS, DOS+Win3.x, DOS+WFW 3.11, Windows 95/98, Windows NT (а также LAN Manager for OS/2, OS/2 Warp Connect, OS/2 LAN Server и т. д.). Для транспортировки сообщений протокола SMB может использоваться любой из следующих транспортных протоколов: TCP/IP, IPX/SPX, NetBEUI, с установленной поддержкой программного интерфейса NetBIOS. Сети Microsoft Network могут быть реализованы как сети архитектуры «клиент-сервер», так и как одноранговые сети. Сетевые ресурсы и их идентификация В отличие от сети NetWare, где все ресурсы сервера являются автоматически сетевыми ресурсами, при рассмотрении сети Microsoft Network отдельно выделяется понятие сетевого ресурса. Сетевой ресурс – это ресурс ВУ (например, каталог, принтер, серверная часть распределенного приложения или еще что-либо), предоставляемый в совместное использование. Операция предоставления локального ресурса в совместное использование (Sharing) выполняется утилитой Server Manager. Сетевые ресурсы идентифицируются следующим образом: \\<имя сервера>\<имя сетевого ресурса>, например \\MX\ NetLogon или \\MX\EpsonFX. Если имя сетевого ресурса заканчивается символом $, то такой ресурс не виден при просмотре сети стандартными средствами. Однако его, как и любой другой сетевой ресурс, можно использовать при наличии соответствующих прав. При обращении к файловому ресурсу (например, файлу), расположенному в сетевом каталоге, можно выполнить назначение сетевого каталога на локальный диск (см. далее раздел «Рабочая среда пользователя») и указывать путь как к локально расположенному ресурсу, либо использовать UNC-нотацию для указания полного пути к такому ресурсу: \\<имя сервера>\<имя сетевого каталога>\<имя подкаталога>\…\<имя файла>.
108
Права доступа к сетевым ресурсам Права доступа к ресурсам сети Microsoft Network могут быть назначены как индивидуально или на уровне пользователя (UserLevel), так и на уровне ресурса (Share-Lеvel). В первом случае для ресурса создается ACL, в котором указывается, какие объекты службы справочника имеют права доступа на ресурс и каковы эти права. Во втором случае для ресурса просто указывается пароль доступа для выполнения операций чтения, и отдельно – пароль для выполнения операций записи. В отличие от сетей NetWare, где пользователь «видит» только те ресурсы сети, на которые он имеет как минимум право просмотра, пользователь сети Microsoft Network видит все не скрытые сетевые ресурсы. Однако пользователь может получить доступ только к тем ресурсам, на которые он имеет действительные права (см. раздел «Служба безопасности»). Концепция рабочей группы и домена В сетях на основе Windows NT используются две модели построения сети: модель рабочих групп и модель доменов. Рабочая группа – это поименованная организационная единица, представляющая собой набор сгруппированных вместе компьютеров (рис. 8). Каждый компьютер рабочей группы сам отвечает за управление своими сетевыми ресурсами (модель Workgroup Computing). Применительно к Windows NT каждый компьютер содержит свою БД SAM (см. далее раздел «Служба безопасности»). Рабочая группа может быть построена на базе любых из упомянутых выше ОС, за исключением DOS и DOS+Win 3.x, так как на них могут быть установлены только клиентские части сетевого ПО. Особенностью рабочей группы является полное равноправие всех входящих в нее компьютеров. Компьютер с ОС Windows NT Server может присутствовать в рабочей группе при условии, что ОС Windows NT Server выполняет роль отдельно стоящего сервера (Stand-Alone). Домен – это поименованная организационная единица, представляющая собой совокупность компьютеров, совместно использующих базу данных службы справочника и единую политику безопасности (модель Network Computing). Домен Windows NT организуется с помощью одной и более ВУ с ОС Windows NT Server, вы-
109
полняющих роль контроллеров домена. Контроллеры домена хранят
Рис. 8. Сеть Microsoft Network на основе рабочей группы
110
Рис. 9. Сеть Microsoft Network на основе домена и рабочей группы копии одной и той же БД SAM. При этом первичный контроллер домена (Primary Domain Controller / PDC) содержит копию БД для чтения/записи, а резервные контроллеры домена (Backup Domain Controller / BDC) – копии только для чтения. Для домена может быть определен только один PDC, а также один и более BDC. Через каждые 15 мин PDC рассылает обновления, внесенные в БД SAM. Кроме контроллеров в домен могут быть включены члены домена: рабочие станции с ОС Windows NT Workstation и серверы с ОС Windows NT Server в роли Stand-Alone Server. (!) Роль, которую будет выполнять Windows NT Server, указывается при установке на ВУ. Чаще всего домен или рабочая группа Windows NT соответствуют подразделению или филиалу организации или предприятия. Например, для отдела бухгалтерии может быть создана рабочая группа Buhgalteria, для отдела АСУ – домен ASU и т.д. (рис. 9). Доверительные отношения между доменами При обмене информацией между подразделениями, а также совместном использовании ресурсов возможно установление доверительных отношений между доменами. Доверительные отношения позволяют пользователям одного домена (учетным записям из одной БД SAM) получать доступ к ресурсам другого домена/сервера (с другой БД SAM) при наличии соответствующих прав доступа. Доверительные отношения между доменами позволяют организовать сеть масштаба предприятия, в которой осуществляется тесное взаимодействие между отделами или подразделениями (см. далее). В общем случае доверительные отношения являются односторонними и обозначаются так: <Домен1> -> <Домен2>. Например, INFORMATICS -> EDU означает, что домен INFORMATICS доверяет домену EDU и разрешает пользователям этого домена использовать своим ресурсы (входить в сеть, используя рабочие станции домена; использовать каталоги и принтеры совместного доступа). Кроме этого, если A -> B и B -> C, то из этого не следует A -> C, т.е. доверительные отношения не являются транзитивными. Дове-
111
рительные отношения устанавливаются при помощи утилиты User Manager for Domains. При включении в домен рабочей станции с ОС Windows NT Workstation или сервера с ОС Windows NT Server в роли StandAlone Server устанавливаются неявные доверительные отношения (рабочая станция или сервер доверяют контроллеру домена). Способы организации сети масштаба предприятия на основе доменов Существует несколько способов организации сети предприятия или организации: 1. На базе одиночного домена – для небольшой организации с небольшой сетью. 2. На базе главного домена – для большой организации с централизованным управлением и насыщенными ресурсами подразделениями. Выделяется главный домен – домен, где регистрируются все пользователи сети, при этом остальные домены – ресурсные – содержат информационно-вычислительные ресурсы подразделений и доверяют главному домену. 3. На базе множества главных доменов – для очень большой организации с распределенным управлением. Несколько доменов – главные домены – отражают основные подразделения организации и содержат учетные записи пользователей. Между ними устанавливаются двусторонние доверительные отношения. Остальные домены – ресурсные – доверяют этим доменам. 4. На базе множества доверяющих друг другу доменов – для организаций с децентрализованным управлением или консорциума предприятий. Домены отражают филиалы или самостоятельные отделы предприятия. Все домены равноправны и доверяют друг другу. Служба справочника Windows NT На каждом компьютере с установленной ОС Windows NT присутствует служба справочника SAM (Security Account Manager). Эта служба обслуживает специальную БД, где хранятся все объекты службы справочника. БД SAM хранится как улей SAM системного реестра (см. ранее раздел «Системный реестр»). Управление объек-
112
тами БД SAM осуществляется утилитой User Manager / User Manager for Domains. В БД SAM могут создаваться объекты следующих типов: Пользователь – представляет пользователя в системе и является его учетной записью. Глобальная группа – служит для логического объединения объектов-пользователей домена для отражения организационной структуры подразделения, например администраторы домена, пользователи домена, разработчики ПО, пользователи и т. д. Стандартные группы: Domain Administrators, Domain Users и Domain Guests. Кроме этого в системе есть специальная глобальная группа, которая не присутствуют в списке глобальных групп при просмотре утилитой User Manager и в которую нельзя включать и из которой нельзя удалять объекты. Это группа Everyone, в которую неявно включены все пользователи сети. Локальная группа – служит для определения прав доступа и задания политики безопасности на компьютере с ОС Windows NT, в БД SAM которого она создана. То есть если локальная группа создается в БД SAM контроллера домена, то она позволяет задать доступ к ресурсам контроллеров домена, а если в БД SAM рабочей станции или сервера – члена домена, то она позволяет задать доступ к ресурсам рабочей станции или сервера. Может включать как пользователей, так и глобальные группы, в том числе и из доверяемых доменов. Стандартные группы: Administrators (включает Domain Administrators), Users (включает Domain Users), Guests (включает Domain Guests) и т.д. Кроме этого в системе есть специальные локальные группы, которые не присутствуют в списке локальных групп при просмотре утилитой User Manager и в которые нельзя включать или из которых нельзя удалять другие объекты. Это группы Network (все пользователи, подключившиеся к ВУ по сети), Interactive (все локально подключившиеся пользователи), Creator Owner (включает учетную запись пользователя, создавшего объект или взявшего его во владение). Вычислительная установка (Рабочая станция) – служит для идентификации узла сети с ОС Windows NT при установлении безопасного канала связи между ВУ, а также установления доверительных отношений. Для контроллеров домена объект-вычислительная установка создается автоматически при установке ОС. Для членов
113
домена (рабочей станции и отдельно стоящего сервера) объектвычислительная установка создается при включении узла сети в домен утилитой Server Manager. Объект-вычислительная установка может присутствовать в ACL защищенных ресурсов под именем SYSTEM. Идентификация объектов службы справочника Служба справочника Windows NT не поддерживает иерархических имен (как в NDS), поэтому каждый объект в рамках одной БД SAM должен именоваться уникальным образом. В пределах области видимости БД SAM объект службы справочника идентифицируется своим простым именем (свойство Имя объекта), например User1, а при междоменном взаимодействии – полным именем, включающим название домена и простое имя, например EDU/User1. 2.4.4. Служба безопасности
Основной целью службы безопасности Windows NT является контроль и управление доступом к защищенным объектам системы (в том числе, к ресурсам файловой системы NTFS, сетевым ресурсам, элементам реестра и т.д.). Контроль доступа (аудит) позволяет записывать события, происходящие в системе, с целью фиксирования успешных и безуспешных попыток доступа к объектам и запрашиваемых при этом прав доступа. Программные компоненты службы безопасности Процесс входа в систему (Logon Process) – принимает запросы на вход в систему от интерактивных и удаленных пользователей. После ввода логического имени и пароля, а также указания места аутентификации – имени рабочей станции или имени домена (см. далее «Рабочая среда пользователя»), система переправляет введенную пользователем информацию либо LSA, запущенному на локальном компьютере, либо LSA на удаленном компьютере (контроллере домена). Распорядитель локальной безопасности (LSA – Local Security Authority) – основа подсистемы безопасности, генерирует маркеры доступа системы безопасности, управляет политикой локальной безопасности и обеспечивает интерактивный сервис аутентифика-
114
ции пользователя. Также регистрирует сообщения (в журнале событий аудита), сгенерированные монитором безопасности. Диспетчер бюджетов безопасности (SAM – Security Account Manager) – поддерживает БД учетных записей службы справочника. SAM обеспечивает аутентификацию пользователей, проверяя предоставляемые имена и пароли на соответствие имеющимся в БД. Монитор безопасности (Security Reference Monitor) – проверяет, имеет ли пользователь права доступа к защищенному объекту и отслеживает любое предпринимаемое пользователем действие. Проводит в жизнь политику безопасности, благодаря которой доступ к объектам получают только пользователи и процессы, имеющие соответствующие разрешения (Permissions). Генерирует контрольные события службы аудита. Структуры данных службы безопасности Каждый зарегистрированный в системе объект службы справочника (пользователь, группа пользователей, вычислительная установка), идентифицируется с помощью уникального идентификатора безопасности (Security ID). Когда пользователь входит в систему, система Windows NT создает для него маркер доступа. Он включает SID пользователя, SID групп, к которым принадлежит пользователь, а также информацию о логических именах пользователя и групп и информацию о привилегиях пользователя (см. раздел «Привилегии доступа»). Дополнительно, каждый процесс, который выполняется от имени этого пользователя, будет иметь копию его маркера доступа. Все именованные, а также некоторые неименованные объекты могут быть объектами безопасности (или защищенными объектами). Атрибуты безопасности описываются дескриптором безопасности объекта. Дескриптор безопасности содержит: 1) Идентификатор безопасности владельца (пользователя или группы). Владелец имеет право менять права доступа к объекту. 2) Контролируемый список доступа (ACL) объекта – указывает, каким пользователям или группам разрешен или запрещен доступ к объекту. Системный ACL – управляет списком генерируемых системой сообщений контроля. В этот список заносятся пользователи и груп-
115
пы, для которых ведется аудит, а также те права, при попытке использования которых необходимо генерировать события. Каждый ACL состоит из элементов управления доступом (ACE – access control entry), которые указывают определенный тип доступа или разрешение на контроль со стороны системы применительно к отдельному объекту для отдельного пользователя или группы. Существует 4 типа ACE: 1. AccessAllowed – для предоставления доступа; 2. AccessDenied – для запрещения доступа; 3. SystemAuditSuccess – для контроля успешных попыток доступа к ресурсу; 4. SystemAuditFail – для контроля неудавшихся попыток доступа к ресурсу. По определению, все ACE типа AccessDenied располагаются в списке перед ACE остальных типов. (!) Существует важное отличие объекта с пустым ACL от объекта без ACL. В первом случае доступ неявно запрещен, во втором – объект не является защищенным объектом. Каждый ACE включает маску доступа, которая определяет возможные действия над объектом в зависимости от его типа. Разрешения предоставляются или отклоняются на основании этой маски. В маске представлены типы прав доступа, допустимые для данного защищенного объекта. Права доступа Службой безопасности Windows NT предусмотрено использование нескольких типов прав доступа (Permissions) для назначения необходимого уровня доступа через ACL: Стандартные права – относятся ко всем защищенным объектам: 1) SYNCHRONIZE – используется для синхронизации доступа к объекту; 2) WRITE_OWNER – право назначать владельца объекта; 3) WRITE_DAC – право на внесение изменений в ACL объекта; 4) READ_CONTROL – право чтения ACL и SID владельца объекта; 5) DELETE – право на удаление объекта.
116
Специфические права – объект любого типа может иметь до 16 специфических прав доступа.
117
Рассмотрим специфические права на файлы тома NTFS: 1) ReadData – право открывать файл и читать его содержимое; 2) WriteData – право открывать файл и изменять его содержимое; 3) AppendData – право открывать файл и добавлять в него данные; 4) Execute – право выполнять файл; 5) ReаdAttributes – право читать стандартные атрибуты файла; 6) WriteAttributes – право изменять стандартные атрибуты файла; 7) ReаdEA – право читать расширенные атрибуты файла; 8) WriteEA – право изменять расширенные атрибуты файл. Общие (агрегированные) права – формируются из специфических и стандартных прав логическим сложением. Например, для объектов-файлов существуют следующие общие права: 1) File_Generic_Read – включает права просмотра атрибутов и содержимого файла, а также право чтения расширенных атрибутов и стандартное право SYNCHRONIZE; 2) File_Generic_Write – включает права изменения атрибутов и содержимого файла, добавления данных в файл, право изменения расширенных атрибутов и стандартное право SYNCHRONIZE; 3) File_Generic_Execute – включает права чтения атрибутов файла, право выполнения файла и стандартное право SYNCHRONIZE. Дополнительно, графический интерфейс утилит администрирования защищенных ресурсов предоставляет возможность назначения групповых прав. Например, для объектов-файлов возможно назначение следующих групповых прав: 1) чтение (Read) – право чтения содержимого файла, его атрибутов и его запуска, если это выполняемый файл; 2) изменение (Change) – дополнительно к праву Read включает право изменять атрибуты, редактировать содержимое файла, удалять файл; 3) полный доступ (Full Control) – дополнительно к праву Change включает право изменять владельца файла и ACL. Служба безопасности Windows NT является чрезмерно открытой и гибкой, что таит в себе большую опасность. Например, если учетную запись SYSTEM (см. выше) лишить права доступа к каталогу с системными файлами (%SystemRoot%), а также права доступа к определенным ключам реестра, то ОС Windows NT не сможет даже загрузиться. По этой причине, редактируя ACL ресурса, необходимо быть очень внимательным и, по возможности, включать в ACL учетную запись SYSTEM c правами не ниже Change.
118
«Наследование» прав доступа В системе безопасности Windows NT действует так называемое «статическое» наследование прав доступа (в отличие от «динамического» в NetWare). Это означает, что при создании объекта внутри некоторого контейнерного объекта (каталога или подключа реестра, например), содержимое ACL создаваемого объекта заполняется значениями ACE из ACL объекта-родителя. Однако при смене содержимого ACL контейнерного объекта нужно явно указывать системе, распространять ли новый ACL на объекты-потомки или нет. Поведение системы по «наследованию» прав доступа управляется флажками «Наследовать права доступа» (Replace Permissions) в диалоговых окнах утилит администрирования. По указанным выше причинам проверка прав доступа к защищенным ресурсам в ОС Windows NT отличается от механизмов, имеющих место в NetWare. Проверка прав доступа Когда пользователь пытается обратиться к объекту, система сравнивает информацию в маркере доступа пользователя с информацией безопасности в дескрипторе защиты объекта. При этом на основе запрашиваемого типа доступа (чтение, запись, удаление и т.п.) создается запрашиваемая маска доступа. Эта маска сравнивается с ACL объекта. При сравнении запрашиваемой маски с каждым ACE действительны следующие правила: Идентификатор безопасности в ACE сравнивается с набором идентификаторов в маркере доступа пользователя. Если соответствие не найдено, то ACE пропускается. Если найдено соответствие, то права, определенные в ACE, добавляются к динамически формируемому списку действительных прав для доступа к объекту. ACE просматриваются последовательно до тех пор, пока суммарных действительных прав не окажется достаточно для успешного доступа к объекту. Кроме того, если ACE имеет тип AccessDenied, то просмотр ACL завершается и доступ к объекту отклоняется. В случае, если список просмотрен до конца и действительных прав не хватает для удовлетворения запрашиваемого типа доступа, доступ к объекту в общем случае отклоняется. Если в запрашиваемой маске доступа присутствует запрос на Read_Control или Write_DAC и пользователь является владельцем (создателем) объекта, то доступ предоставляется.
119
Пример 1 Пользователь Peter, входящий в группу Users, запрашивает доступ на чтение и запись в файл My_DOC.txt. В ACL My_DOC.txt имеются следующие ACE: Allow (R,W) – Admins, Allow (R) – Users, Allow (W) – Peter. Система безопасности сравнивает запрашиваемую маску: С первым ACE – SID Admins отсутствует в маркере доступа, поэтому действительных прав у Peter не прибавляется. Со вторым ACE – SID Users есть в маркере доступа, поэтому появляется действительное право на чтение, но этого недостаточно для предоставления доступа. С третьим ACE – SID Peter также есть в маркере доступа, поэтому появляется дополнительное действительное право на запись. Теперь действительных прав достаточно для предоставления доступа. Просмотр завершается и предоставляется доступ. Пример 2 Пользователь Peter, входящий в группу Users, запрашивает доступ на чтение и выполнение файла My_work.exe. В ACL My_work.exe имеются следующие ACE: Denied – Users, Allow (R, X) – Peter. Система безопасности сравнивает запрашиваемую маску: С первым ACE – SID Users есть в маркере доступа, и так как ACE имеет тип AccessDenied, то дальнейший просмотр прекращается и доступ к объекту отклоняется (несмотря на то, что в ACL есть ACE, разрешающий доступ пользователю Peter). Привилегии доступа Обычно доступ к объекту определяется на основе сравнения информации о пользователе и группах, содержащихся в маркере доступа, и разрешениями, действующими для объекта. Однако некоторые операции, выполняемые пользователями, не связаны с отдельными объектами: вход в систему, запуск и останов компонент привилегированного режима, назначение себя владельцем защищенных объектов и т.д. В подобных случаях служба безопасности Windows NT позволяет назначить привилегии доступа (Rights). Для назначения объектам службы справочника привилегий доступа используется утилита User Manager.
120
Действительные права доступа В системе Windows NT действительные права доступа формируются: 1) Логическим сложением прав доступа к ресурсу, явно определенных для пользователя и неявно определенных через членство в группах. Например, если пользователю JohnT определено право чтения в каталоге C:\USERS\TEMP, а группе Managers, в которую он входит, право записи, то действительными правами доступа пользователя JohnT будут права на чтение и запись. 2) Логическим умножением прав доступа, определенных для одного ресурса и другого ресурса, включающего (инкапсулирующего) в себя данный ресурс. Например, если пользователю JohnT определены права чтения и записи на каталог совместного доступа \\TEST\TEMP на основе каталога C:\TEMP файловой системы NTFS, на который он имеет право чтения, то действительными правами доступа пользователя JohnT будет право на чтение при подключении к сетевому ресурсу \\TEST\TEMP. Кроме этого, привилегии доступа имеют больший приоритет по сравнению с правами доступа. Например, если у пользователя отсутствует привилегия на подключение к ресурсам компьютера по сети, то даже при наличии определенных разрешений на локальные и сетевые ресурсы, воспользоваться этими правами он не сможет. Механизмы защищенного взаимодействия клиента и сервера Прежде всего, в Windows NT обеспечивается механизм защищенного взаимодействия клиента и сервера в процессе аутентификации пользователя в сети. Процедура аутентификации Аутентификация пользователей выполняется на основе паролей учетных записей, хранящихся в зашифрованном виде на сервере в БД SAM. Пароли шифруются с помощью односторонней дайджест-функции. Зашифрованный пароль называется дайджестом. Знание дайджеста не позволяет восстановить исходное сообщение. При входе в систему пользователь указывает имя учетной записи и пароль. Пароль шифруется с использованием той же дайджестфункции, что используется при сохранении паролей в БД SAM, а имя учетной записи передается на сервер аутентификации.
121
Получив имя, сервер передает на рабочую станцию случайное проверочное слово-вызов. Оно шифруется на рабочей станции второй односторонней функцией, в качестве аргумента которой используется дайджест пароля, сформированный на рабочей станции. Полученный ответ передается на сервер. На сервере слово-вызов также шифруется с помощью второй функции и дайджеста пароля, хранящегося в БД SAM сервера. После этого вычисленное на сервере значение сравнивается со значением, полученным от рабочей станции. Если имеет место совпадение значений, то аутентификация прошла успешно, т.е. пользователь действительно знает свой пароль и при этом используется защищенный канал для взаимодействия. 2.4.5. Установка Windows NT Server
Установка ОС Windows NT Server выполняется в два этапа: I Подготовительный 0.1. Подготовить и протестировать аппаратное обеспечение на совместимость с устанавливаемой версией ОС. Обеспечить соответствие вычислительных ресурсов требованиям для устанавливаемой версии ОС. Для ОС Windows NT Server 4.0 рекомендуется ВУ с процессором не ниже Pentium-100, 64Mбайт памяти и жестким диском не менее 1Гбайт, а также сетевая карта PCI или EISA. Мышь рекомендуется. Если устанавливается поддержка UPS, на время установки системы необходимо отключить информационный кабель, связывающий UPS и ВУ (через последовательный порт). 0.2. Подготовить список настроек аппаратных компонент ВУ (номера прерываний, адреса портов ввода/вывода, номера занимаемых слотов локальной шины). 0.3. Подготовить дистрибутив ОС. Дистрибутив может быть расположен на CD-ROM или в каталоге совместного использования. II Основной В зависимости от варианта установки (с CD-ROM, по сети и т.п.) некоторые действия могут выполняться по запросу программы установки. Возможные варианты установки: – с загружающегося CD-ROM; – из раздела DOS c локально подключенного накопителя CDROM; – по сети из каталога совместного использования.
122
Рассмотрим порядок установки с локально подключенного накопителя CD-ROM: 1.1. Загрузиться с системной дискеты DOS. 1.2. Создать первичный раздел (FAT16) минимум 100Мб. Если в этот раздел будет устанавливаться система, рекомендуется минимум 500Мбайт. Сделать его загружаемым DOS-разделом. 1.3. Установить поддержку CD-ROM под DOS. 1.4. Загрузиться с созданного раздела и с дистрибутива запустить файл WINNT.EXE с параметром /B (загрузка программы установки с жесткого диска, а не с гибких дисков). <копирование на жесткий диск файлов для установки, требуется до 80Мб> 1.5. Перезагрузить систему и в меню запуска выбрать Windows NT Install/Upgrade. ---------------------- Текстовая часть установки ---------------------2.1. Подтвердить выбор автоматически определенного системой контроллера жестких дисков или указать вручную (если отсутствует в списке, потребуется дискета с драйвером от производителя). 2.2. Ввести основные параметры ВУ: архитектура ВУ (MPS, обычный PC), тип дисплея, тип мыши, тип клавиатуры, раскладка клавиатуры (обязательно указать US). 2.3. Создать / выбрать раздел на жестком диске для установки системы. 2.4. Указать каталог для установки (по умолчанию, WINNT). <копирование системных файлов в каталог установки> 2.5. перезагрузить систему ---------------------- Графическая часть установки -----------------3.1. Ввести имя ответственного за лицензирование лица и название организации. 3.2. Ввести серийный номер (например, 040-1111111). 3.3. Указать имя сервера, например TEST_NT. 3.4. Выбрать роль, которую будет выполнять сервер в сети : PDC, BDC, Stand-Alone. 3.5. Ввести пароль администратора сервера/домена. 3.6. Указать, нужно ли создавать Emergency Repair Disk после завершения установки. На нем будут сохранены файлы ульев реестра после установки сервера. 3.7. Выбрать прикладные компоненты для установки (Accessories, Multimedia и т.п.)
123
<установка сетевых компонентов 3.8. Выбрать, подключен ли сервер к сети локально или через низкоскоростные линии. 3.9. Указать, нужно ли устанавливать MS IIS. 3.10. Произвести автоматическое обнаружение / выбрать из списка сетевое оборудование. (При отсутствии необходимого оборудования в списке, потребуется дискета с драйвером от производителя.) 3.11. Выбрать транспортные протоколы, которые необходимо установить (TCP/IP в обязательном порядке). 3.12. Выбрать сетевые службы, которые необходимо установить (Workstation, Server, Netlogon в обязательном порядке) <настройка компонент сетевого ПО, загрузка и регистрация в сети> 3.13. Настроить драйвер сетевой платы (прерывание, номер слота). 3.14. Настроить транспортный протокол (для IP: статический или динамический IP-адрес, маска подсети, шлюз, DNS-сервер). 3.15. Настроить службы сети : задать приоритеты привязки протоколов и служб. 3.16. Если выполняемая сервером роль – Stand-Alone, то указать – включать сервер в домен или в рабочую группу. В первом случае, ввести имя домена, логическое имя и пароль администратора домена. Если BDC, то указать имя домена и дождаться выполнения синхронизации БД SAM. ----------------- Завершающая часть установки --------------------4.1. Выбрать часовой пояс. 4.2. Подтвердить автоматически обнаруженный тип графической видеоплаты, либо выбрать вручную из списка (если отсутствует в списке, потребуется дискета с драйвером от производителя). <сохранение настроек в реестре> 4.3. Перезагрузить сервер. 4.4. Войти в систему и из папки Control Panel запустить модуль настройки Regional Settings. Указать там Russian в качестве кодировки по умолчанию. 4.5. Если будет устанавливаться поддержка UPS, отредактировать файл BOOT.INI, добавив в строку выбора системы ключ /NoSerialMice:COM, где – номер последовательного порта. Этот ключ указывает системе, не искать на указанном порту устройство ввода типа «мышь». После этого можно к последовательному порту подключать информационный кабель, связывающий UPS и ВУ. 4.6. Перезагрузить сервер.
124
Установка сервисных пакетов Даже после выполнения открытого тестирования ОС возможно выявление ошибок в работе компонент ОС уже после выпуска финальной версии (релиза). Для устранения выявленных ошибок, а также для расширения функциональности ОС (например, для поддержки нового оборудования) фирма Microsoft выпускает сервисные пакеты. Сервисные пакеты распространяются бесплатно через Internet или по подписке, например TechNet или MSDN. (!)
Перед установкой сервисного пакета на работающий сервер крайне рекомендуется выполнить полное резервное копирование системных файлов.
Для установки сервисного пакета необходимо: 1. Запустить загруженный через Internet (например, с FTPсервера Microsoft) самораспаковывающийся exe-файл c сервисным пакетом. Например, ntsp3_i.exe. 2. Затем, если необходимо, нужно указать, чтобы был создан каталог для сохранения замещаемых системных файлов (для удаления сервисного пакета). Программа обновления произведет копирование системных файлов и попросит выполнить перезагрузку сервера. 3. Выполнить перезагрузку сервера и убедиться, что обновление ОС прошло успешно. 2.4.6. Средства администрирования Windows NT
Для выполнения административных функций в сети на базе ОС Windows NT Server необходимо использовать следующие утилиты: – User Manager. – User Manager for Domains. – Server Manager. – File Manager и Windows NT Explorer. – Add Printer Wizard. – Event Viewer. – System Policy Editor. – Disk Administrator. Файлы c утилитами администрирования располагаются в каталоге %SystemRoot%\System32 компьютера с ОС Windows NT.
125
Утилита User Manager Утилита User Manager хранится в файле musrmgr.exe и служит для создания, просмотра, редактирования и удаления учетных записей пользователей и групп на компьютере с ОС Windows NT Workstation. Эта утилита позволяет создавать локальных пользователей и локальные группы. Данная утилита также позволяет назначать пользователям и группам определенные привилегии доступа (не путать с разрешениями) на локальный компьютер, например вход в систему локально, право смены системного времени и т.п. Наконец, используя эту утилиту, администратор управляет режимом работы службы контроля по использованию ресурсов ВУ (выключить или включить службу и, если включить, то для отслеживания каких событий). Утилита User Manager for Domains Утилита User Manager for Domains (файл usrmgr.exe) служит для создания, просмотра, редактирования и удаления учетных записей пользователей и групп на компьютере с ОС Windows NT Server в роли контроллера домена. Позволяет создавать пользователей, локальные и глобальные группы. Данная утилита позволяет также назначать пользователям и группам определенные привилегии доступа на компьютеры, являющиеся контроллерами домена, например вход в систему локально, право смены системного времени и т.п. Дополнительно, утилита User Manager for Domains позволяет определить доверительные отношения между доменами. При наличии доверительных отношений и соответствующих прав доступа, можно управлять БД SAM нескольких доменов, в том числе БД SAM компьютеров-членов домена (элемент Select Domain). Утилита Server Manager Утилита Server Manager (файл srvmgr.exe) служит для: 1) контроля активных подключений к серверам домена (компьютерам с запущенной службой сервера); 2) запуска и останова сетевых служб; 3) создания, просмотра и редактирования свойств, удаления каталогов совместного доступа.
126
4) включения компьютеров в члены домена и удаления компьютеров из домена (создание и удаление учетных записей компьютеров – членов домена в БД SAM). 5) выполнения операции назначения резервного контроллера домена первичным контроллером (элемент Promote to Primary DC) и операции синхронизации БД SAM на всех контроллерах домена (Synchronize Entire Domain). При наличии доверительных отношений и соответствующих прав доступа можно управлять БД SAM нескольких доменов (элемент Select Domain). Утилиты File Manager и Windows NT Explorer Утилиты File Manager (файл winfile.exe) и Windows NT Explorer (файл explorer.exe) позволяют выполнять все базовые операции с ресурсами файловых систем, включая: 1) создание, редактирование и удаление файлов и каталогов; 2) редактирование атрибутов файлов и каталогов. Для ресурсов файловой системы NTFS обеспечивается также возможность управления дескрипторами безопасности, включая: – управление правами доступа через ACL объектов файловой системы (закладка Security – кнопка Permissions); – управление работой системы контроля (закладка Security – кнопка Audit); – возможность назначить себя владельцем ресурса при наличии соответствующих прав (закладка Security – кнопка Owner). Утилита Add Printer Wizard Утилита Add Printer Wizard позволяет выполнять установку драйверов принтеров и подключать сетевые принтеры. Кроме того, данная утилита служит для определения принтеров совместного доступа (закладка Sharing) и управления дескрипторами безопасности установленных в системе принтеров, включая: 1) управление правами доступа (закладка Security – кнопка Permissions); 2) управление работой системы контроля (закладка Security – кнопка Audit);
127
3) возможность назначить себя владельцем ресурса (при наличии соответствующих прав). Утилита Event Viewer Утилита Event Viewer (файл eventvwr.exe) позволяет просматривать записи службы контроля по трем категориям: System, Security (доступна, если включен режим контроля событий безопасности), Application. Есть возможность просматривать только записи, удовлетворяющие определенному условию (на основе фильтра). Утилита System Policy Editor Утилита System Policy Editor (файл poledit.exe) позволяет создавать и редактировать файлы системных политик для рабочих станций c ОС Windows NT и Windows 95/98, а также прямо вносить изменения в подключи реестров рабочих станций, связанные с системными политиками. Утилита Disk Administrator Утилита Disk Administrator (файл windisk.exe) служит для управления жесткими дисками локального компьютера, включая выполнение следующих операций: – создание и удаление разделов; – создание, форматирование и удаление томов файловых систем FAT и NTFS. Для компьютеров с ОС Windows NT Server обеспечивается возможность создания отказоустойчивых томов в спецификации RAID уровней 0,1 и 5 (программный RAID). 2.4.7. Подключение пользователей к сети на основе Windows NT
Для подключения пользователей к сети на основе Windows NT администратор выполняет установку и настройку клиентcкой части сетевого ПО для сети Microsoft Network на рабочие станции пользователей. Затем администратор регистрирует пользователей в службе справочника и настраивает рабочую среду пользователей. Рабочая среда пользователя определяется атрибутами учетной записи, такими как домашний каталог и сценарий входа в систему,
128
формируется из доступных пользователю сетевых ресурсов (каталоги, принтеры), автоматически устанавливаемых соединений, профиля пользователя и управляется системными политиками. Настройка клиентского программного обеспечения сети Microsoft Network Следующие параметры клиентского ПО имеют решающее значение для нормального функционирования сети: Название рабочей группы или домена. Если сеть организуется на основе модели рабочих групп, то название рабочей группы, которой будут приписаны рабочие станции пользователей, будет влиять только на возможность просмотра сетевых ресурсов. При входе в систему необходимо будет указывать имя локального компьютера в качестве места аутентификации пользователей. Если сеть организуется на основе модели доменов, то при установке ОС Windows NT на рабочую станцию необходимо будет выполнять регистрацию ВУ в «домашнем» домене пользователей (домене, где зарегистрированы пользователи). При этом параметр «название рабочей группы/домена» получит необходимое значение. При входе в систему пользователи смогут указывать имя локального компьютера, либо имя «домашнего» домена в качестве места аутентификации. Вариант построения сети с доверительными отношениями между доменами более сложен и здесь не рассматривается. Настройка транспортного протокола. При установке клиентского ПО на рабочие станции необходимо будет установить тот транспортный протокол, который был установлен на серверах сети Microsoft Network. В обязательном порядке необходимо также установить поддержку интерфейса NetBIOS для выбранного протокола, обеспечивающего взаимодействие узлов сети Microsoft Network. Атрибуты учетной записи пользователя Атрибуты учетной записи пользователя позволяют управлять рабочей средой пользователя. Основные атрибуты учетной записи:
129
1) Принадлежность группам (локальным и глобальным) – позволяет назначить пользователю те или иные права доступа и привилегии в системе через установление эквивалентности, а также отражать организационную структуру подразделения. 2) Ограничения – группа атрибутов, включающая ограничения на: – срок действия пароля – без ограничения (индивидуально или для всех) или срок действия (один для всех, у кого включено ограничение на срок действия); – минимальную длину пароля; – использование пароля, срок действия которого истек; – привилегии системных политик (User Rights Policies); – время работы в системе; – рабочие станции, с которых возможен вход в систему. 3) Блокировка учетной записи при неправильном вводе пароля. 4) Домашний каталог – каталог, назначаемый пользователю на сервере или рабочей станции для хранения своих рабочих файлов. 5) Сценарий входа в систему – с каждым пользователем Windows NT может быть связан один сценарий входа в систему. Имя и путь к сценарию указываются в свойстве Logon Script учетной записи пользователя. По умолчанию, все сценарии хранятся в каталоге %SystemRoot%\SYSTEM32\REPL\IMPORT\SCRIPTS контроллеров домена (является сетевым ресурсом с именем NETLOGON) и представляют собой текстовые командные файлы (с расширением cmd или bat). Сценарии входа в сеть Так же как и в сетях NetWare, в сетях Microsoft Network могут использоваться сценарии входа в сеть для настройки рабочей среды пользователей (прежде всего для подключения сетевых ресурсов). Команды сценария входа в сеть 1) Команда назначения сетевого ресурса на локальный ресурс NET USE <имя локального ресурса > <имя сетевого ресурса> [параметры]. Например, выполнение команды NET USE H: \\SRV1\USERS обеспечит возможность работы с сетевым каталогом как с локальным диском, а выполнение команды NET USE LPT1: \\SERVER\LASERJET позволит печатать на сетевом принтере документы, отправленные в локальный параллельный порт.
130
2) Команда отображения текстового сообщения ECHO «<текст сообщения>» 3) Команда вызова командного файла CALL <имя командного файла> (!)
При вызове командного файла из сценария входа в сеть необходимо учитывать, что текущий каталог и названия локальных дисков сервера в момент выполнения сценария отсутствуют. Поэтому, чтобы выполнить командный файл, расположенный на сервере, необходимо указать полный путь к нему в UNC-нотации.
4) Переменные времени выполнения сценария: %HOMEDRIVE% – диск (локальный или сетевой), где располагается домашний каталог пользователя; %HOMEPATH% – путь к домашнему каталогу, включая его имя; %HOMESHARE% – UNC-имя разделяемого каталога, в котором хранится домашний каталог (если он хранится на сервере, а не на рабочей станции); %USERNAME% – имя учетной записи пользователя; %USERDOMAIN% – домен, которому принадлежит учетная запись пользователя; %OS% – ОС рабочей станции пользователя, например «Windows_NT»; %PROCESSOR_LEVEL% – тип процессора, например «486». Пример сценария входа в сеть @ECHO OFF ECHO Здравствуйте, %USERNAME% !!! REM Выполнение сценария для группы разработки ПО Call \\SRV\NETLOGON\GroupScripts\develop.cmd REM Подключение домашнего каталога NET USE H:=\\SRV1\USERS H:
131
2.5. Клиентская ОС Клиентская ОС, как уже говорилось ранее, устанавливается на рабочие станции пользователей ИВС и обеспечивает им доступ к локальным вычислительным ресурсам и сетевым ресурсам ИВС. 2.5.1. Требования к клиентской ОС
С учетом требований, предъявляемых к ВУ в роли рабочей станции (см. раздел «Вычислительные установки»), можно выдвинуть следующие требования к клиентской ОС: 1) Удобный и высокопроизводительный графический интерфейс – обеспечивает эффективную и наглядную, интуитивно понятную, работу пользователей с ресурсами ИВС. 2) Открытость – подразумевает поддержку различных вариантов сетевого ПО, что обеспечивает независимость клиентской ОС от одного варианта построения ИВС, а также возможность использования ресурсов неоднородной ИВС. 3) Наличие единого подхода при работе с сетевыми ресурсами, предоставляемыми различными сетевыми ОС – пользовательский и программный интерфейс клиентской ОС должны обеспечивать прозрачный однообразный доступ пользователей к разнородным сетевым ресурсам за счет абстракций типа «сеть», «узел сети», «сетевой ресурс» и специализированных программных прослоек в составе сетевого ПО. 4) Управляемость, обеспечивающая создание уникальной настраиваемой рабочей среды для пользователя, возможность удаленного управления этой рабочей средой (например, с помощью системных политик), а также возможность установки и настройки программного обеспечения на рабочие станции пользователей. 2.5.2. Функции администратора клиентской ОС
Администратор ИВС (или администратор рабочих станций) должен выполнять следующие функции: 1) Установка клиентской ОС на рабочие станции пользователей. 2) Установка и настройка сетевого ПО. 3) Управление рабочей средой пользователей. 4) Установка и настройка приложений для их выполнения под управлением клиентской ОС.
132
2.6. Microsoft Windows NT Workstation ОС Microsoft Windows NT Workstation (далее «Windows NT Workstation»), как уже было сказано ранее, относится к семейству ОС Windows NT. Этой ОС свойственны все отличительные особенности уже рассмотренной ОС Windows NT Server: надежность, переносимость, встроенная система безопасности, встроенная поддержка сети и т.д. В данном разделе мы уделим внимание таким важным вопросам администрирования клиентской ОС, как установка клиентской части сетевого ПО и настройка рабочей среды пользователя применительно к Windows NT Workstation. Так как Windows NT Workstation (как, впрочем, и Windows NT Server) разрабатывалась как сетевая ОС, в ней есть встроенная поддержка сетей Microsoft Network и сетей NetWare, а также есть возможность для установки поддержки дополнительных типов сетей. Такая возможность обеспечивается за счет уровневой архитектуры построения программных модулей, отвечающих за взаимодействие ОС Windows NT Workstation с другими ВУ сети. 2.6.1. Архитектура компонент сетевого ПО
Компоненты сетевого ПО в составе Windows NT выполняются как в режиме ядра (в составе диспетчера ввода-вывода), так и в пользовательском режиме. В пользовательском режиме ОС сетевое ПО представлено маршрутизатором множественных поставщиков услуг (Multuple Provider Router / MPR) и поставщиками услуг (провайдерами) сетей различного типа. Вот ключевые преимущества архитектуры интерфейса поставщика сетевых услуг: Открытый интерфейс, позволяющий любым производителям поставлять сетевое ПО, полностью интегрируемое с Windows NT. Универсальный доступ и управление сетевыми ресурсами и компонентами через пользовательский интерфейс Windows NT, включая Network Neighborhood и опцию Network в Control Panel.
133
Рис. 10. Архитектура компонентов сетевого ПО в составе Windows NT
Вызовы интерфейса поставщика сетевых услуг (в составе Win32 API) используются приложениями для выдачи запросов на услуги сети. Windows NT переправляет вызов соответствующему поставщику сетевых услуг, который и обеспечивает запрашиваемый сервис сети (рис. 10). Поставщик сетевых услуг – это специфичная для данной сети библиотека, реализующая вызовы функций интерфейса поставщика сетевых услуг из маршрутизатора поставщиков услуг. Обеспечиваемые функции включают аутентификацию пользователей, когда они пытаются получить доступ к серверу сети, управление паролями, добавление или уничтожение соединений с сервером, а также просмотр ресурсов сети. Поставщики сетевых услуг тесно взаимодействуют с соответствующими редиректорами, выполняющимися в режиме ядра напрямую, либо посредством менеджера устанавливаемых файловых систем (IFSMGR).
134
IFSMGR, как уже говорилось ранее, является основой диспетчера ввода-вывода. IFSMGR является своего рода маршрутизатором запросов, отправляемых в драйвер той или иной установленной файловой системы. Редиректоры сетевого ПО различного типа (Microsoft Network, NetWare и т.д.), реализованные как файловые системы, получают все преимущества от такой организации подсистемы ввода-вывода, в частности доступ к диспетчеру кэша файловых систем. Ниже слоя редиректоров располагается интерфейс NetBIOS, необходимый для взаимодействия ВУ в сети Microsoft Network. Под ним располагаются различные драйверы транспортных протоколов. Еще ниже находится интерфейс NDIS для организации привязки нескольких протоколов к одной сетевой плате и / или использования несколькими сетевыми платами одного транспортного протокола. В самому низу сетевой уровневой архитектуры Windows NT размещается NDIS-драйвер сетевой платы. 2.6.2. Установка сетевого ПО
Сетевое ПО на ВУ с Windows NT Workstation может быть установлено как в процессе установки ОС, так и после ее установки. Кроме того, может быть выбрана установка сетевого ПО для сетей Microsoft Network (в составе Windows NT) и/или для сетей на основе NetWare (поставляется с ОС Novell NetWare). Для установки сетевого ПО для сетей Microsoft Network в составе Windows NT необходимо: 1. Используя кнопку Пуск (Start), выполнить команду Пуск>Настройки->Панель управления->Сеть. Система сообщит, что сеть не установлена и предложит это сделать. 2. Указать сетевую плату, которая установлена в ВУ, например 3с509, и, возможно, указать дополнительные параметры (номер аппаратного прерывания, адреса портов ввода-вывода и т.п.), например, аппаратное прерывание: 5 и порт ввода-вывода: 340. Здесь может потребоваться носитель с драйверами для сетевых плат. 3. Указать транспортный протокол, который будет использоваться, например, TCP/IP. Указать дополнительные параметры, например, IP-адрес узла сети, маска сети, шлюз, адрес DNS-сервера и т.д.
135
4. Указать сетевые службы, которые необходимо установить. В обязательном порядке устанавливаются службы Workstation, Server и NetLogon. 5. Выполнить настройку клиентского ПО, например указать домен или рабочую группу, в которую будет включена ВУ с установленным сетевым ПО. При включении рабочей станции в домен необходимо будет указать пароль администратора для создания учетной записи вычислительной установки в БД SAM домена. 6. Выполнить перезагрузку ОС, чтобы изменения вступили в силу. 2.6.3. Рабочая среда пользователя
Рабочая среда пользователя определяет порядок работы пользователя с ресурсами ВУ и ресурсами ИВС. Для управления рабочей средой пользователя в Windows NT используются профили пользователей. Профили пользователей Профилем пользователя называется каталог файловой системы с информацией о персональных настройках рабочей среды пользователя, загружаемых при входе в систему. К персональным настройкам относятся: 1) внешний вид графического интерфейса (цвет рабочего стола, цвет и положение панели задач, размер шрифтов, использующихся для отображения элементов графического интерфейса); 2) настройки установленных в системе приложений; 3) настройки установленных в системе принтеров; 4) значения переменных среды (TEMP, HOMEDIR и т.д.); 5) индивидуальное меню программ, вызываемое по нажатию кнопки Start (Пуск); 6) объекты, находящиеся на рабочем столе; 7) текущие сетевые подключения и т.д. Профили хранятся на рабочих станциях пользователей (в каталоге %SystemRoot%\Profiles) или на сервере (в каталоге \\<имя сервера>\Profiles). В последнем случае профиль называется перемещаемым или блуждающим (Roaming Profile). Перемещаемый профиль позволяет пользователю иметь одни и те же настройки рабочей среды при работе с разных ВУ сети.
136
Типы профилей: – Обязательный (Mandatory)– создается администратором, если рабочая среда пользователя должна оставаться неизменной. – Персональный (может быть локальным и блуждающим) – все изменения, вносимые пользователем в течение сеанса работы с системой, сохраняются в профиле и в точности воспроизводятся при следующем входе в систему. По умолчанию, хранится в подкаталоге с именем, являющимся именем учетной записи пользователя, внутри каталога профилей. Например, C:\Winnt\Profiles\4219. – По умолчанию – используется при первом входе пользователя в систему (на основе этого профиля создается персональный профиль). Также может использоваться, если отсутствует доступ к персональному профилю и при входе в качестве гостя (учетная запись Guest). Хранится в подкаталоге Default User каталога профилей пользователей. – Cистемный – специальный профиль, который всегда присутствует в системе. Этот профиль загружается в память при запуске Windows NT. Является активным, когда на экране присутствует приглашение для входа в систему. Хранится как файл с именем Default в каталоге с ульями реестра.
137
2.7. Microsoft Windows 95 2.7.1. История и версии ОС Windows 95
Первая ОС семейства Windows 9x, которая называлась Windows 95, появилась в августе 1995 г. После того, как поутихла рекламная шумиха, выяснилось, что «абсолютно новая 32-разрядная ОС» построена на проверенной годами парадигме «DOS+Windows». Поэтому все ОС семейства Windows 9x являются прямыми наследницами ОС DOS и операционной среды Windows 3.x, точнее расширенного режима работы этой операционной среды, использовавшего новые возможности процессора i386 для обеспечения многозадачности. Более того, некоторые программные компоненты (например, 32-разрядные программные компоненты файловой системы), вошедшие в состав Windows 95, впервые были представлены еще в Windows for Workgroups 3.11. А архитектура программных компонентов Windows 3.x режима ядра (см. далее «Архитектура Windows 9x») полностью перенесена в ОС семейства Windows 9x. Однако, как показало время, «недостатки» Windows 95, за которые так ругали ОС Windows 95 и компанию Microsoft «теоретики от информатики», сторонники чистых и правильных систем, не помешали этой ОС распространиться на миллионы настольных компьютеров и ознаменовать повсеместный переход на 32-разрядные приложения. После выхода ОС Windows NT Workstation версии 4.0 с пользовательским интерфейсом в стиле Window 95 стало ясно, в чем состоял замысел корпорации Microsoft, развивавшей две ветви ОС семейства Windows: постепенно подвести корпоративных пользователей к необходимости использования на рабочих станциях более надежной и защищенной Windows NT Workstation и 32-разрядных приложений. Для домашних пользователей, равно как и для пользователей малых офисов, которым не требуется надежность, управляемость и защищенность Windows NT Workstation, компания Microsoft предлагает ОС семейства Windows 9x. Расcмотрим далее существующие версии ОС семейства Windows 9x.
138
Windows 95 Удобный графический интерфейс в стиле «рабочего стола» с панелью задач и кнопкой Пуск (Start) пришел на смену неудобному и ограниченному в своих возможностях графическому интерфейсу Windows 3.x на основе Менеджера Программ (Program Manager). 32-разрядный программный интерфейс Win32 API, являющийся подмножеством Win32 API из Windows NT, обеспечил возможность разрабатывать большинство приложений для единой платформы Win32. Поддержка длинных имен в FAT сделала работу пользователей с папками и документами (новые названия для файлов и каталогов) более понятной и удобной. Системный реестр обеспечил централизованное управление настройками ОС и приложений. Введена поддержка профилей пользователей (см. раздел «Рабочая среда пользователя»). Включена поддержка стандартов управления электропитанием ACPI и Plug-n-Play, а также программного интерфейса Telephony API. Встроенная поддержка сети: драйверы сетевых плат, драйверы транспортных протоколов TCP/IP, NetBEUI, IPX/SPX, клиенты сетей Microsoft Network и NetWare (только для NetWare 3.x и 4.x в режиме Bindery). Windows 95 OSR2 (OEM Service Release 2) Обновленная версия Windows 95 для установки на новые компьютеры. Поддержка новой файловой системы FAT32 (32разрядный вариант FAT) обеспечивает эффективную работу с жесткими дисками большого объема. Клиент сети NetWare с поддержкой службы справочника NDS. Поддержка нового оборудования (интерфейс USB и т. п.) Windows 98 Встроенный в графическую оболочку браузер WWW-ресурсов Internet Explorer. Новая модель драйверов, призванная обеспечить использование одних и тех же драйверов устройств как для ОС семейства Windows 9x, так и для ОС семейства Windows NT. Поддержка нового оборудования (шина AGP, новые контроллеры жестких дисков PIIX-IDE и т. п.). 2.7.2. Архитектура Windows 95
ОС семейства Windows 9x продолжают использовать программный код MS-DOS (теперь версии 7.0 или MSWIN 4.XX.XXXX) для загрузки ядра защищенного режима и обеспечения эмуляции DOS в
139
Рис. 11. Архитектура ОС Windows 95
виртуальных DOS-машинах, содержат 16-разрядный код во многих DLL-библиотеках, продолжают использовать файловую систему FAT и не содержат никаких механизмов по обеспечению локальной безопасности (рис. 11). Центральное место в архитектуре ОС семейства Windows 9x отводится ядру защищенного режима (файл VMM32.VXD) и слою виртуальных драйверов (файлы с расширением VXD). Ядро ОС выполняется в кольце 0 и обеспечивает программный интерфейс (в стиле функций 21-го прерывания DOS) для подсистем и приложений пользовательского режима. Фактически ядро собирается из нескольких виртуальных драйверов при установке OC Windows 9x на ВУ.
140
В состав ядра входят: Менеджер виртуальных машин (VMM). VMM управляет созданием виртуальных машин, в том числе, он порождает системную виртуальную машину и загружает в нее подсистемы Win16 и Win32, которые затем загружают все остальные подсистемы пользовательского режима. Диспетчер памяти (V86MMGR). Управляет распределением XMS-памяти процессам, выполняющимся под управлением ОС. Также включает диспетчера поддержки виртуальной памяти. Драйвер подсистемы Win32 в режиме ядра (VWIN32.VXD). Обеспечивает сервис Win32-приложениям – управление нитями и т.п. Драйверы клавиатуры, мыши, дисплея, таймера (VKD, VMD, VDD, VTD). Виртуализируют соответствующее периферийное оборудование. Обеспечивают обработку аппаратных прерываний и предоставляют сервис для драйверов подсистемы Win16. Помимо драйверов, входящих в состав ядра, в память загружаются следующие виртуальные драйверы: Диспетчер ввода-вывода (IFSMGR.VXD) – менеджер устанавливаемых файловых систем (ср. с Windows NT). Управляет всем блочным вводом-выводом. Набор драйверов устанавливаемых файловых систем (VFAT.VXD, CDFS.VXD, VREDIR.VXD, VSERVER.VXD). Драйверы протоколов транспортного уровня (VIP.386, VTCP.386, VNETBIOS.VXD). Драйвер кэша файловых систем (VCACHE.VXD). Cупервизор вывода-вывода (IOS.VXD), управляющий драйверами блочных устройств, в том числе драйверами сетевых плат. Драйвер графической видеоплаты (например, S3.VXD). Одновременно с ядром защищенного режима в ОС Windows 9x присутствует ядро реального режима (WinBoot.sys). Это ядро обеспечивает загрузку ядра защищенного режима, а также обеспечивает эмуляцию ОС DOS в виртуальных DOS-машинах, программный интерфейс (функции 21-го прерывания DOS) для DOS-приложений и доступ DOS-приложений к сервисам ядра защищенного режима. В пользовательском режиме (кольцо 3) выполняются подсистемы Win32 (файл krnl32.dll) и Win16 (файл krnl386.exe), а также 16- и 32-разрядные варианты модулей User, GDI и Shell. Под управлением этих программных модулей производится запуск и выполнение
141
приложений Win32, Win16 и DOS. Кроме того, они обеспечивают программный интерфейс в стиле программных вызовов (Win32 API и Win16 API) ко всем сервисам ОС Windows 9x. Подсистема Win16 обеспечивает сервис ввода-вывода приложениям за счет драйверов периферийного оборудования (keyboard.drv, mouse.drv, display.drv, system.drv), которые занимаются преобразованием аппаратных прерываний в системные сообщения Windows. 2.7.3.Системный реестр
Системный реестр (Registry), так же как и в ОС Windows NT, является универсальным хранилищем настроек ОС и приложений. Однако в Windows 95 некоторые INI-файлы (прежде всего файлы WIN.INI и SYSTEM.INI) продолжают хранить многие настройки ОС. Эта уступка сделана в пользу более полной обратной совместимости с существующими Win16 приложениями по сравнению с Windows NT. Логическая структура системного реестра Window 95 идентична структуре реестра Windows NT, но элементы реестра не являются защищенными объектами ввиду полного отсутствия локальной защиты ресурсов в Windows 95. Кроме того, некоторые подключи, имеющиеся в Windows NT, отсутствуют в Windows 95 (например, HKEY_LOCAL_MACHINE/SAM), зато присутствуют уникальные подключи для Windows 95. Весь реестр состоит из одного системного улья и множества пользовательских ульев, хранящих индивидуальные настройки пользователей. Системный улей представлен файлом C:\<WinDir>\SYSTEM.DAT. Он хранит все ключи реестра, за исключением HKEY_CURRENT_USER. Пользовательские ульи представлены файлами USER.DAT, расположенными в каталогах профилей пользователей (см. далее). Они хранят информацию ключа HKEY_CURRENT_USER. Управление системным реестром осуществляется утилитой Registry Editor (regedit.exe), функционально идентичной одноименной утилите, имеющейся в Windows NT. 2.7.4. Архитектура компонентов сетевого ПО
Архитектура компонентов сетевого ПО была перенесена в Windows 95 из Windows NT. Однако из-за различий в реализации
142
этой архитектуры (разный формат драйверов режима ядра, отсутствие системы безопасности в Windows 95 и т.д.) приходится устанавливать разные варианты сетевого ПО третьих производителей на ВУ c Windows 95 и Windows NT. 2.7.5. Профили пользователей
Профили пользователей обеспечивают возможность индивидуальной настройки параметров рабочей среды пользователя ОС Windows 9X, а также установленных в системе приложений. Профилем пользователя называется каталог с информацией о персональных настройках рабочей среды пользователя, загружаемых при входе в систему. Профили хранятся на рабочих станциях пользователей (в каталогах C:\<Windir>\Profiles\%USERNAME%) или на сервере (например, в каталогах \\<имя сервера>\Profiles\%USERNAME%), где %USERNAME% – имя, которое указывает пользователь при входе в систему. Типы профилей: 1) Пользовательский (может быть локальным и блуждающим) – все изменения, вносимые пользователем в течение сеанса работы с системой, сохраняются в профиле и в точности воспроизводятся при следующем входе в систему. По умолчанию хранится в каталоге с именем, являющимся именем учетной записи пользователя. Например, C:\Windows\Profiles\4219. 2) Обязательный (Mandatory) – идентичен пользовательскому, за исключением того, что все изменения, внесенные в профиль, при завершении сеанса работы, будут потеряны. Предназначены для создания идентичных рабочих сред для нескольких пользователей ИВС. Улей системного реестра HKEY_CURRENT_USER для обязательного профиля хранится в файле USER.MAN. 2.8. Сравнение ОС Windows 9x и ОС Windows NT Workstation После выполнения сравнительного анализа естественно сделать вывод о месте каждой ОС в рамках ИВС. Исходя из архитектурных
143
и функциональных особенностей обеих ОС, можно рекомендовать использовать ОС Windows 95 там, где не требуются высокая надежность и защищенность, например в малых офисах, домашних офисах, либо там, где нет достаточных аппаратных ресурсов для эксплуатации Windows NT. Для разработки нового ПО при совместном использовании ресурсов ВУ (много пользователей на одну ВУ), эксплуатации в больших сетях рекомендуется использовать Windows NT Workstation. Кроме того, при развертывании ИВС не рекомендуется использовать одновременно обе ОС в качестве клиентской ОС. Причины, по которым этого не рекомендуется делать, следующие: 1) разные драйверы для оборудования; 2) разный подход к установке и сопровождению, отличия в системных реестрах; 3) несовместимые профили пользователей; 4) небольшие, но все же отличия в пользовательском интерфейсе.
144
В таблице перечислены основные отличия двух ветвей ОС семейства Windows: ХарактеWindows 9x Windows NT ристики Workstation Высокие: PentiumТребования к Средние: Pentium-100, 24Mбайт 200, 32Mбайт оборудованию Средняя: только Высокая: большинство Совместимость с ПО DOS и Win3.х приложений приложения, исDOS и Win (Win16, Win32s API), в том пользующие документированные числе VXD-драйверов 3.x функции, Win32s не поддерживается, VXD-драйверы не поддерживаются Высокая: огромный список Средняя: есть обоСовместирудование, для комость с ап- поддерживаемого оборуторого отсутствуют дования паратурой драйверы Менее гибкая и Установка и Более гибкая и удобная удобная процедура процедура установки, есть развертываустановки вариант установки из сети ние Встроенная поддержка Планируется в слеПоддержка ACPI и Plug-n-Play дующих версиях управления питанием и автоматического конфигурирования оборудования ПроизводиБолее высокая при ограни- Ниже из-за проверок системы безотельность ченных ресурсах (меньше пасности, большого 32 Мбайт ОЗУ) количества служебных структур данных Надежность Низкая: сбой программы Высокая: приложенезависимы, иногда порождает систем- ния ный сбой или блокировку, хотя возможны блотребующую полной пере- кировки системы загрузки Безопасность Низкая: нет системы за- Высокая: поддержка безощиты локальных ресурсов, механизмов для гибкой защиты сете- пасности на локальвых ресурсов требуется ном компьютере присутствие в сети ВУ с Windows NT
145
Вопросы и задания 1. Дайте определение ОС. Отметьте разницу между сетевой и персональной ОС. 2. Укажите программные компоненты в составе сетевого ПО и их назначение. 3. Какую роль в рамках ИВС играет серверная ОС? Перечислите основные службы серверной ОС и укажите их назначение. 4. Укажите особенности ОС NetWare, позволяющие говорить о ней как о клиент-серверной ОС масштаба предприятия. 5. Приведите характеристику файловой системы Turbo FAT в составе NetWare. Укажите механизмы в составе этой файловой системы для обеспечения гибкости и прозрачности для пользователей. 6. Опишите физическую структуру файловой системы Turbo FAT. Укажите механизмы для обеспечения надежности и порядок восстановления информации, хранящейся на томах файловой системы NetWare. 7. Опишите принципы организации сети на основе NetWare. Приведите примеры объектов службы справочника NDS, укажите способы идентификации ресурсов сети NetWare. 8. Объясните необходимость разбиения БД NDS на разделы, дайте определение реплики раздела БД NDS, укажите типы реплик. 9. Объясните необходимость поддержания единого времени в ИВС на основе NetWare, укажите примеры серверов времени и порядок их взаимодействия для малых сетей и больших распределенных сетей. 10. Перечислите основные механизмы для обеспечения безопасности в сети на основе NetWare. 11. Укажите порядок предоставления прав доступа, дайте определение действительных прав и объясните порядок их формирования в NetWare. 12. Приведите примеры прав доступа, использующихся в файловой системе и службе справочника. 13. Объясните роль атрибутов файловой системы для дополнительного ограничения доступа к ресурсам файловой системы. 14. Опишите порядок развертывания сети на основе NetWare, включая процедуру установки ОС NetWare. Какие вопросы должны быть рассмотрены до выполнения основного этапа установки?
146
15. Укажите основные настройки клиентского ПО, влияющие на работу пользователей в сети. 16. Опишите механизмы в составе NetWare для настройки рабочей среды пользователей, включая атрибуты объекта типа Пользователь и сценарии входа в сеть. 17. Укажите основные характеристики ОС семейства Windows NT. Объясните, почему ОС Windows NT Server используется преимущественно как базовая ОС для серверов приложений. 18. Дайте характеристику файловой системы NTFS. Опишите механизмы для обеспечения гибкости и универсальности этой файловой системы. 19. Опишите физическую структуру файловой системы NTFS. Укажите механизмы для обеспечения надежности. 20. Опишите принципы организации сети Microsoft Network. Объясните разницу между рабочей группой и доменом. Укажите порядок идентификации ресурсов сети Microsoft Network. Перечислите классы объектов службы справочника в составе Windows NT и их назначение. 21. Перечислите основные механизмы и структуры данных для обеспечения безопасности сетей на основе Windows NT. 22. Укажите типы прав доступа. Объясните разницу между правами (разрешениями) и привилегиями. Каковы механизмы формирования действительных прав в Windows NT? 23. Опишите процедуру развертывания сети на основе Windows NT Server. Отметьте различие между Windows NT Server в роли контроллера домена (первичного и вторичного) и отдельно стоящего сервера (или члена домена). 24. Какие настройки клиентского ПО сетей Microsoft Network являются основными? 25. Каким образом выполняется настройка рабочей среды пользователей сетей Microsoft Network? Опишите атрибуты учетной записи пользователя, включая сценарии для входа в сеть. 26. Какова роль клиентской ОС в ИВС? Укажите основные функции клиентской ОС. 27. Отметьте различие между ОС Windows NT Workstation и Windows 95/98. Сделайте выводы о месте каждой ОС в современной ИВС и их совместном использовании.
147
Г л а в а 3 . СИСТЕМА УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ 3.1. Общие вопросы Система управления базами данных (далее «СУБД») – это специализированное программное обеспечение, которое предназначено для эффективного хранения и обработки больших объемов информации, представленной особым образом. Исторически наибольшее распространение получили СУБД, поддерживающие реляционную модель хранения данных. Реляционная модель хранения данных была предложена И. Ф. Коддом в 1969 г. На сегодняшний день СУБД занимает одно из основных мест в структуре ИВС, обеспечивая защищенный, надежный и эффективный способ хранения и обработки информации различного типа. 3.1.1. История СУБД с архитектурой «клиент-сервер»
Рост объемов хранимой и передаваемой по сети информации, а также сложность управления существующими СУБД потребовал нетрадиционного подхода к организации и хранению данных (к системам с традиционным подходом будем относить СУБД, использующие централизованную модель вычислений, либо модель вычислений на основе файлового сервера, например, FoxPro, Clipper, dBase и т.п.). В 1979 г. появилась первая коммерческая версия СУБД (проект Oracle), в которой был реализован язык запросов SQL (Structured Query Language). СУБД Oracle была разработана небольшой компанией Silicon Valley (теперь Oracle Corporation). В 1985 г. вышла в свет СУБД Oracle 5, в которой впервые для реализации СУБД была использована архитектура вычислений «клиент-сервер». На сегодняшний день существует большое число СУБД, поддерживающих реляционную модель данных и архитектуру вычислений «клиент-сервер»: Oracle Server, Microsoft SQL Server, IBM DB/2 Universal Server, Sybase Adaptive Server, Informix Universal Server и т.д. Приняты стандарты на язык SQL: SQL-92, SQL3, SQL99. В частности, для обеспечения высокого уровня безопасности информации, хранящейся в БД под управлением СУБД, в стандарт
148
SQL-92 было введено разграничение прав доступа пользователей к элементам данных (таблицам, индексам и т.п.). 3.1.2. Требования к современной СУБД
Современная СУБД является одним из самых важных элементов в структуре ИВС, поэтому к ней предъявляются достаточно жесткие требования: Масштабируемость. Предполагает возможность СУБД хранить и обрабатывать увеличивающиеся в объеме данные, а также обслуживать большее количество одновременных сеансов работы пользователей, не теряя при этом в эффективности. Поддержка многоплатформенности. Иногда возможности СУБД масштабироваться ограничены возможностями самой ОС, под управлением которой выполняется СУБД (ограничение на размер файлов, ограничение на объем адресуемой памяти и т. п.). В таком случае, необходимо, чтобы при значительном увеличении объемов данных и количества пользователей, использующих СУБД, можно было поменять программно-аппаратную платформу на более мощную. При этом СУБД должна обеспечивать независимость программных приложений и логической структуры для хранения данных от программно-аппаратной платформы. Встроенные механизмы журналирования и архивирования. Современная СУБД должна иметь встроенную систему журналирования транзакций и резервного копирования данных (в том числе, в оперативном режиме), обеспечивающую быстрое восстановление работоспособности СУБД при сбоях и поддержание хранящихся данных в непротиворечивом состоянии. Поддержка внешних служб справочника. Наличие большого количества служб справочника в ИВС усложняет как работу пользователей, так и обслуживание ИВС администратором. Современная СУБД должна иметь средства для интеграции встроенной службы безопасности с внешней службой справочника и/или средства синхронизации своей службы справочника с внешней службой справочника. Чаще всего в качестве внешней службы справочника выступает служба справочника в составе ОС, под упарвлением которой выполняется СУБД. Единая утилита администрирования СУБД. Управление распределенной ИВС, включающей не один узел с развернутой СУБД, требует наличия в составе СУБД единой утилиты администрирования, обеспечивающей управление всеми ресурсами ИВС на основе
149
СУБД из одной точки сети. Такая утилита должна обеспечивать выполнение всех основных функций администрирования СУБД (см. далее). Открытая архитектура. Современные ИВС не являются однородными, поэтому современная СУБД должна поддерживать, помимо фирменных интерфейсов, универсальные интерфейсы доступа к данным (ODBC, JDBC). Кроме того, СУБД должна обеспечивать возможность расширения стандартного набора поддерживаемых типов данных за счет подключения пользовательских типов (см. также раздел «Перспективы развития»). Поддержка многоуровневой распределенной архитектуры. Современная СУБД должна поддерживать механизмы и стандарты распределенных вычислений, обеспечивающие максимально эффективное использование вычислительных ресурсов ИВС (мониторы транзакций, распределенные запросы и т. п.). 3.1.3. Функции администратора СУБД
1. Установка и настройка серверной и клиентской частей СУБД. Включает: а) Установку программных файлов на ВУ ИВС. б) Создание БД. в) Планирование и настройка рабочей среды пользователей. г) Настройка рабочих параметров СУБД. 2. Сопровождение. Включает: а) Оптимизацию рабочих параметров для увеличения вычислительной мощности СУБД. б) Контроль активных подключений и общей загруженности сервера, заполненности элементов БД и размеров файлов БД. в) Обеспечение надежности хранимой информации путем ведения журнала транзакций, выполнения резервного копирования. г) Обеспечение безопасного хранения информации за счет разграничения и контроля доступа пользователей к элементам БД. Рассмотрим далее основные понятия, связанные с выполнением функций администратора клиент-серверной реляционной СУБД.
150
3.1.4. Основные понятия
База данных – это массив связанной информации. Для хранения данных в БД используются таблицы. Таблица характеризуется конечным числом столбцов или полей, определяющих, информация какого типа может храниться в таблице. Таблица может содержать переменное число строк или записей, представляющих собой кортежи – элементарные единицы хранимой информации для реляционной модели. Каждая запись таблицы идентифицируется уникальным образом по значению первичного ключа, создающегося на основе одного и более полей таблицы. В реляционной модели данных каждая таблица представляет какуюто сущность предметной области задачи (термин ER-модели), которая использует СУБД для хранения информации. Для представления связей между сущностями предметной области в реляционной модели используются вторичные или внешние ключи. Внешний ключ находится в зависящей таблице и ссылается на родительский ключ, являющийся первичным ключом основной таблицы. Индекс – специальная структура, служащая для обеспечения эффективного выполнения операций над таблицами. Индекс создается автоматически при определении первичного или вторичного ключей, а также может создаваться вручную. Представление – это виртуальная таблица, данные которой получаются путем выдачи запроса к одной и более базовым таблицам. Представление еще называют хранимым запросом. Представления имеют определенные ограничения (определяется выполняемыми над представлениями операциями). Например, нельзя использовать некоторые представления для внесения изменений в БД. Хранимая процедура – специальная подпрограмма на языке СУБД (например, PL/SQL) для обработки информации в БД. Хранимые процедуры размещаются и выполняются на сервере БД по запросу клиентской части СУБД. Триггер – хранимая процедура, которая автоматически выполняется СУБД при определенных условиях (например, при удалении записи из таблицы). Запрос на языке SQL – непроцедурная последовательность команд языка SQL для создания/чтения/модификации/удаления информации из БД.
151
Транзакция – последовательность команд SQL, рассматриваемая как единое целое (выполняются либо все команды транзакции, либо ни одна из них). Распределенный запрос – в рамках распределенной СУБД запрос на языке SQL может содержать обращение к БД, лежащей на разных серверах, или к нескольким БД. Для обеспечения целостности и непротиворечивости данных требуется выполнение распределенной транзакции. Распределенная транзакция – транзакция, в рамках которой обеспечивается выполнение распределенного запроса. Двухфазное подтверждение – особый способ уведомления участников распределенной транзакции об успешном завершении всех операций. На первом шаге инициирующий узел раздает подзапросы в рамках распределенного запроса на несколько узлов и получает результаты подзапросов, а на втором шаге выдает узлам команду commit. Только после получения подтверждения о том, что на всех узлах команда commit выполнена, распределенная транзация считается завершенной. Сервер – часть СУБД, отвечающая за хранение данных и обработку SQL-запросов. Клиент – часть СУБД, выдающая SQL-запросы серверу для доступа к БД. ПО промежуточного уровня – архитектура распределенного ПО (в том числе и распределенной СУБД) предполагает наличие нескольких компонентов, взаимодействие которых происходит с использованием специального протокола, поддерживаемого этим ПО (например, SQL*Net). Пользователь – физическое лицо, работающее с СУБД посредством клиентского ПО, имеющее учетную запись пользователя и права доступа к объектам схемы БД. Схема пользователя – набор таблиц, индексов и других объектов БД, закрепленный за определенным пользователем, имеющим полные права доступа к этому набору и являющимся владельцем набора. Объекты схемы того или иного пользователя могут предоставляться для совместного использования другим пользователям БД. Права доступа – обеспечивают пользователю определенную степень свободы при работе с объектами БД (создание, просмотр, модификация таблиц и т.д.) или БД в целом (прежде всего, изменение физической структуры БД).
152
3.1.5. Перспективы развития СУБД
На сегодняшний день данные настолько разнообразны, что представление данных с использованием стандартных типов – целое число, вещественное число, дата, строка и т.п. – просто невозможно. Это привело к созданию СУБД с возможностью добавления пользовательских типов данных. Например, в СУБД Informix используется такое понятие, как картриджи. Картриджи обеспечивают поддержку дополнительных типов данных: графические изображения, видео-данные, гипер-тексты и т.п. Дальнейшим развитием идеи пользовательских типов данных явилось создание объектно-реляционных СУБД. Такие СУБД позволяют использовать преимущества объектно-ориентированной парадигмы для хранения и обработки данных, хранящихся в реляционных СУБД. Примером объектно-реляционной СУБД является СУБД Oracle 8. В следующем разделе будет рассмотрена реляционная СУБД в архитектуре «клиент-сервер» и вопросы ее администрирования на примере СУБД Oracle.
153
3.2. СУБД Oracle СУБД Oracle является признанным лидером на рынке реляционных СУБД. Многие новшества в области реляционных СУБД впервые появились и стали стандартом де-факто благодаря продуктам компании Oracle. Поддержка многоплатформенности (существуют версии данной СУБД для различных реализаций UNIX, Windows NT, Netware, OS/2, AS/400, MVS) позволяет сохранить существующие БД, продолжить использование уже имеющихся программных разработок, обеспечивая их масштабируемость, и приобретенный опыт администрирования при переходе с одной платформы на другую (например, при увеличении объемов хранимой и обрабатываемой информации). СУБД Oracle будет рассмотрена на примере Oracle версии 7.3 для ОС Windows NT, которая появилась в 1996 г. 3.2.1. Составные части СУБД Oracle
Рассматривая составные части СУБД Oracle, отдельно будем выделять программные компоненты для выполнения операций по извлечению и обработке информации и структуры данных для хранения информации (собственно, база данных). Программные компоненты в составе СУБД Oracle На верхнем уровне рассмотрения все программные компоненты можно отнести к одной из следующих частей: 1) Серверная часть СУБД (далее «сервер») – ведет обработку запросов и управляет файлами БД. 2) Клиентская часть СУБД (далее «клиент») – выдает запросы серверу, используя язык SQL. 3) ПО промежуточного уровня – осуществляет взаимодействие клиента и сервера.
154
Сервер Программные компоненты серверной части СУБД Oracle называются экземпляром БД. Экземпляр БД обслуживает одну связанную с ним БД Oracle. Экземпляр БД характеризуется уникальным идентификатором (System IDentifier / SID) и состоит из следующих процессов и связанных с ними структур данных в памяти ВУ: Процессы переднего плана (Foreground Processes) – непосредственно занимаются обработкой клиентских запросов, находящихся в очереди запросов. Результаты обработки запросов размещаются в очереди ответов. Количество процессов переднего плана регулируется системой автоматически в зависимости от размера очереди запросов. Теневые процессы (Background Processes). Каждый теневой процесс обслуживает определенный набор задач: 1) Процесс записи в базу данных (DBWR) – отвечает за запись модифицированных данных из буферов данных в файлы данных. Периодически активизирует процесс CKPT. 2) Процесс контрольной точки (CKPT) – обеспечивает явное сохранение данных из кэш-буферов в файлы данных. Регистрирует событие контрольной точки в журнале транзакций, которая указывает, сколько данных журнала транзакций нужно применить для восстановления при сбоях. 3) Процесс записи в журнал транзакций (LGWR) – отвечает за запись информации из буферов журнальных файлов в файлы журналирования транзакций. 4) Процесс оперативного архивирования (ARCH) – необязательный процесс (выполняется, если параметр ARCHIVELOG экземпляра БД имеет значение TRUE), который отвечает за своевременное создание резервных копий файлов журнальных групп. 5) Системный монитор (SMON) – управляет распределением памяти на диске при выполнении транзакций. 6) Монитор процессов (PMON) – обеспечивает корректное завершение «зависших» диспетчеров сессий: освобождает память, отменяет незавершенную транзакцию и связанные с ней блокировки. 7) Диспетчеры сессий (Dnnn, где nnn – целое число) – обеспечивают управление информацией, связанной с конкретным сеансом работы пользователя, в том числе постановка клиентских запросов в
155
очередь для обработки и возвращение результатов клиентам из очереди ответов. 8) Глобальная системная область (System Global Area / SGA) – область кэш-буферов для работы экземпляра БД. В SGA размещаются следующие кэш-буферы: а) кэш-буферы данных – в них размещаются данные из файлов данных и происходит предварительное изменение этих данных в ходе выполнения транзакций; б) разделяемый пул (Shared Pool) – содержат элементы словаря БД, а также планы выполнения процедур и запросов (сценарии выполнения, созданные оптимизатором запросов); в) кэш-буферы журнальных файлов – накапливают информацию о происходящих в системе транзакциях для записи в журнал транзакций. Клиент Клиентом СУБД Oracle является любое программное обеспечение, взаимодействующее с сервером Oracle посредством выдачи запросов на языке SQL (например, ПО SQL*Plus), передаваемых по сети с помощью ПО SQL*Net. Клиентское ПО состоит из набора программных файлов (для платформы Windows 9x/NT это файлы с расширением EXE и DLL). ПО промежуточного уровня ПО промежуточного уровня в составе СУБД Oracle называется SQL*Net (для Oracle 7.3 версии 2.x). ПО SQL*Net обеспечивает прозрачный, т. е. не зависящий от типа протокола транспортного уровня, доступ клиентской части СУБД к услугам транспортного протокола, установленного на ВУ, а также возможность предоставлять серверную часть СУБД Oracle для совместного использования с рабочих станций с установленной клиентской частью. На сервере ПО SQL*Net представлено прослушивающим сеть процессом LISTENER, а на клиенте – набором программным файлов ПО SQL*NET Client (файлы с расширением DLL для Windows 9x/NT, загружаемые в память по запросу клиентского ПО). В состав SQL*Net входят также адаптеры протоколов транспортного уровня,
156
обеспечивающие упаковку запросов в сообщения соответствующего протокола транспортного уровня. Для взаимодействия клиента и сервера используется спецификация для прозрачного именования ресурсов (Transparent Network Specification / TNS) сети на основе СУБД Oracle. TNSидентификация ресурсов сети обеспечивается либо с помощью конфигурационных файлов ПО SQL*Net, либо с помощью сервера имен (Oracle Names Server). Клиент знает только TNS-имя сервера Oracle, за которым скрыто физическое местоположение сервера и прослушивающего процесса Listener на компьютере-сервере в терминах того или иного транспортного протокола. Например, для протокола TCP возможно следующее описание TNS-имени сервера: ORAMX.world = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (COMMUNITY = TCP_COM.world) (PROTOCOL = TCP) (Host = 212.192.96.98) (Port = 1526) ) ) (CONNECT_DATA = (SID = TSU) (GLOBAL_NAME = ORAMX.world) ) ) При работе клиента через универсальные интерфейсы доступа к БД (такие, как ODBC, IDAPI, JDBC), вызовы универсального интерфейса транслируются в вызовы ПО SQL*NET. Рассмотрим далее логическую и физическую структуру БД под управлением СУБД Oracle. Логическая структура БД Oracle На верхнем уровне логической организации БД Oracle находится пространство таблиц. Пространство таблиц (Tablespace) служит
157
базовым пространством для размещения объектов схемы (таблиц и т. д.). Пространство таблиц может находиться либо в доступном режиме (online), либо в автономном (offline). Пространство таблиц можно сравнить с томом файловой системы. Рекомендуется создавать отдельные пространства таблиц для каждого приложения, работающего с СУБД (это обеспечивает определенный уровень независимости приложений друг от друга), а также для целей повышения производительности, так как если файлы разных пространств таблиц размещаются на разных физических дисках, то доступ к информации осуществляется быстрее. Каждый создаваемый в БД объект (таблица, индекс, хранимая процедура) принадлежит определенной схеме. Схема неявно создается при регистрации пользователя и выполняет функции контейнера для объектов, создаваемых пользователем. При регистрации пользователя указывается, в границах какого пространства таблиц будут создаваться объекты его схемы. Схему можно сравнить с каталогом файловой системы. К объектам схемы (Schema Objects) относятся: 1) Таблицы (Tables) – основная единица хранения данных в Oracle. Данные хранятся в записях или строках. Все строки таблицы при создании имеют одинаковый формат, определяющийся таблицы. 2) Представления (Views) – задаваемый пользователем вид данных. Представляет собой хранимый запрос к одной и более таблицам. С видом, в общем случае, можно работать как с обычной таблицей, т. е. выполнять операции select, insert, update и т. п. При этом изменения в виде приводят к изменениям со связанными таблицами. 3) Индексы (Indexes) – служебные структуры, которые используются для оптимизации работы системы по обработке запросов. Создаются неявно при определении полей таблиц как ключевых или явно. Все изменения в таблицах мгновенно отражаются в индексах, этот процесс прозрачен для пользователей. 4) Кластеры (Clusters) – структуры для оптимизации доступа к нескольким связанным таблицам, часто использующимся совместно в запросах. 5) Последовательности (Sequences) – для автоматической генерации значений ключевых полей.
158
6) Хранимые процедуры (Stored Procedures), Пакеты (Packages), Триггеры (Triggers) – программные элементы БД, обеспечивающие обработку данных на сервере. 7) Синонимы (Synonyms) – альтернативные названия таблиц, видов, последовательностей и программных объектов для обеспечения прозрачного управляемого доступа к объектам различных схем (ср. Объекты типа Синоним в NDS). 8) Связи с БД (Database Links) – описывают пути к другим БД, используются для выполнения распределенных транзакций. Дополнительными объектами схемы являются сегменты отката (Rollback Segments) транзакций. Сегменты отката используются для временного хранения старых значений данных, обновляемых транзакцией, включающей операции удаления или обновления строк. Если пользователь отменяет транзакцию, то Oracle считывает присвоенный транзакции сегмент отката и возвращает измененные транзакцией строки в исходное состояние. Сегменты отката могут храниться как в обычном пространстве таблиц, так и в специально выделенном для этих целей пространстве. Переведение пространства таблиц в активное состояние Чтобы перевести пространство таблиц в активное состояние, необходимо выполнить команду ALTER TABLESPACE ONLINE. Переведение пространства таблиц в автономное состояние Чтобы перевести пространство таблиц в автономное состояние, необходимо выполнить команду ALTER TABLESPACE OFFLINE. (!)
Чтобы перевести пространство таблиц в автономное состояние, необходимо предварительно перевести в автономное состояние все сегменты отката, хранящиеся в данном пространстве таблиц.
Создание дополнительных пространств таблиц Чтобы создать новое пространство таблиц, необходимо выполнить команду CREATE TABLESPACE <имя пространства> DATAFILE «< имя файла данных>’ <размер файла> [, …]. Увеличение размера существующего пространства таблиц Чтобы увеличить размер пространства таблиц, необходимо выполнить команду
159
ALTER TABLESPACE <имя пространства> ADD DATAFILE «< имя файла данных>’ <размер файла>. Физическая структура БД Oracle СУБД Oracle не использует напрямую дисковое пространство для хранения данных. Вместо этого система использует файлы, внутри которых и размещаются все данные. Oracle использует несколько типов файлов для хранения собственно данных и служебной информации: – Файлы данных (Data Files). В таких файлах размещаются пространства таблиц (пространство таблиц размещается в одном и более файлах). По мере надобности пространству таблиц могут быть выделены (в том числе и автоматически) дополнительные файлы на диске. Однако изменить размер уже существующего файла невозможно. – Управляющие файлы (Control Files) – служат для хранения информации о физической структуре БД (имя БД, имена и расположение файлов данных и журнальных файлов). Все изменения в физической структуре (например, добавление нового пространства таблиц и связанного с ним файла) автоматически отражаются в управляющем файле. Допускается создание зеркальных управляющих файлов (см. далее) – Журнальные файлы (Redo Log Files) – служат для хранения информации о происходящих в системе изменениях (транзакциях). Допускается создание зеркальных журнальных файлов. Пространство таблиц, размещаемое в одном и более файлах данных, хранит объекты схемы в блоках данных (Data Blocks). Несколько подряд идущих блоков объединяются в отрезки (Extents), которые используются для резервирования места в пространстве таблиц под определенный объект схемы (с возможностью увеличения занимаемого объема путем выделения новых отрезков для хранения объектов схемы). Все отрезки некоторого объекта объединяются в сегмент хранения объекта (Object Storage Segment). Размер сегмента динамически меняется по мере надобности и управляется параметрами инициализации сегмента при создании объекта. При создании элементов логической структуры БД можно явно управлять параметрами физической организации БД. Например, при создании объекта Таблица можно указать:
160
– пространство таблиц для размещения таблицы; – начальный размер сегмента хранения таблицы; – размер отрезков (в блоках данных), выделяемых при увеличении размеров таблицы; – максимальное количество отрезков в сегменте хранения. Запуск БД в обычном режиме Запуск БД Oracle в обычном режиме выполняется в три этапа: 1. Запуск экземпляра БД. В процессе запуска экземпляра Oracle основной процесс читает файл параметров INIT%SID%.ORA (здесь и далее %SID% – значение системного идентификатора экземпляра БД, например TSU). Далее, на основе значений параметров происходит выделение места под SGA и выполняется запуск теневых процессов. 2. Монтирование БД – это процесс связывания запущенного экземпляра с конкретной БД. После выполнения монтирования доступ к БД уже возможен, но только пользователю с правами администратора (с ролью DBA). В процессе монтирования экземпляр БД открывает указанный в файле параметров файл управления (параметр CONTROL_FILES). На основе информации в этом файле выполняется проверка файлов данных. Затем открываются журнальные файлы, и, если необходимо, выполняется откат или обратное восстановление транзакций. 3. Открытие БД. Заключается в предоставлении БД для совместного использования. Открываются для доступа файлы данных, точнее становятся доступными (on-line) пространства таблиц, размещенные в этих файлах, и журнальные файлы. Табличные пространства, файлы которых недоступны, остаются неактивными (offline). (!)
Чтобы к БД могли обращаться клиенты с других ВУ, необходимо также, чтобы был запущен процесс Listener.
Запуск БД
161
Для запуска БД в обычном режиме необходимо запустить утилиту Server Manager, подключиться как пользователь INTERNAL (см. далее) и выполнить команду STARTUP. Завершение работы с БД Завершение работы с БД выполняется также в три этапа: 1. Закрытие БД – предполагает, прежде всего, сброс всех изменений в кэш-памяти на диск, а также закрытие всех активных соединений с сервером и закрытие активных табличных пространств. 2. Размонтирование БД – предполагает закрытие файлов управления. 3. Выгрузка из памяти экземпляра БД – заключается в освобождении памяти от SGA и теневых процессов и последующей выгрузке основного процесса. Завершение работы БД Для завершения работы БД в обычном режиме необходимо запустить утилиту Server Manager, подключиться как пользователь INTERNAL (см. далее) и выполнить команду SHUTDOWN. 3.2.2. Установка и настройка
Перед началом установки необходимо решить, какой транспортный протокол и какая версия SQL*NET будут использоваться для взаимодействия клиентов с сервером (1.x или 2.x), а также будет ли создаваться начальная БД (Initial Database) – БД с учебными примерами. Установка на сервере Для установки серверной части СУБД Oracle (на примере Oracle for Windows NT) необходимо запустить программу установки ORAINST.EXE. После ввода информации об используемом языке (English, Russian и т. д.) и указания каталога для установки (например, C:\ORANT) появится диалоговое окно Software Manager. Для работы серверной части СУБД Oracle необходимо выбрать следующие программные компоненты: Oracle Server – собственно сервер Oracle, включаящая программные файлы для создания основного и теневых процессов;
162
SQL*Net Server – серверная часть ПО SQL*Net; Адаптер транспортного протокола (например, TCP/IP Protocol Adapter) – драйвер для упаковки TNS-запросов в сообщения протокола транспортного уровня; System Support Files – файлы для взаимодействия СУБД с ОС; Oracle Server Manager – утилита администрирования, прежде всего предназначенная для запуска и завершения работы экземпляра БД. Кроме того, можно выбрать дополнительные программные компоненты: Oracle Names Server – сервер TNS-именования ресурсов; Oracle Utilities (IMP,EXP,LOADER) – дополнительные утилиты для выполнения операций импорта, экспорта и пакетной загрузки информации в БД; Oracle WebServer – ПО для развертывания Web-сервера, интегрирующегося с СУБД Oracle; Replication Option, Distributed Option, Parallel Query Option – файлы поддержки дополнительных возможностей СУБД Oracle по распределенной обработке; ConText Option, SpacialData Option – файлы поддержки дополнительных типов данных СУБД Oracle. После нажатия кнопки Install программа установки начнет копировать выбранные компоненты на ВУ. При установке компонентов на сервере выберите нужный тип протокола (будет установлен нужный адаптер SQL*NET). Если вы решили использовать в работе начальную БД, укажите это при установке. При этом будет создан экземпляр БД и файлы начальной БД. Следующим этапом установки является создание файла конфигурации серверной части ПО SQL*Net (файл LISTENER.ORA). Для этого можно использовать утилиты SQL*Net Easy Configuration, Oracle Network Manager или обычный текстовый редактор. Пример файла LISTENER.ORA ################ # Filename......: listener.o # Name..........: MX.world # Date..........: 10-L¦T-98 12:20:07 ################ SQLNET.AUTHENTICATION_SERVICES = (NONE)
163
USE_PLUG_AND_PLAY_LISTENER = OFF USE_CKPFILE_LISTENER = OFF LISTENER = (ADDRESS_LIST = (ADDRESS= (PROTOCOL=IPC) (KEY= ORAMX.world) ) (ADDRESS= (PROTOCOL=IPC) (KEY= TSU) ) (ADDRESS = (COMMUNITY = TCP.world) (PROTOCOL = TCP) (Host = 212.192.96.98) (Port = 1526) ) ) STARTUP_WAIT_TIME_LISTENER = 0 CONNECT_TIMEOUT_LISTENER = 10 LOG_DIRECTORY_LISTENER = D:\ORANT\NETWORK\LOG LOG_FILE_LISTENER = logtsu.log TRACE_LEVEL_LISTENER = ADMIN TRACE_DIRECTORY_LISTENER = D:\ORANT\NETWORK\ TRACE TRACE_FILE_LISTENER = tracetsu.trc SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = ORAMX.world) (SID_NAME = TSU) (PRESPAWN_MAX = 10) ) ) PASSWORDS_LISTENER = (DE78D6871581F9B7г})
164
Создание новой БД Если в процессе установки начальная БД не была создана, то после установки программных компонент необходимо создать БД и связанный с ней экземпляр БД. Для этого выполняются следующие действия: Создание файла параметров инициализации экземпляра БД. Обычно это файл INIT%SID%.ORA, где %SID% – это SID экземпляра БД. Создание экземпляра БД и его запуск (с ключом NOMOUNT). Запуск сценария для создания БД, включающего команду Create Database (см. далее). Запуск сценария CATALOG.SQL – в результате будут созданы таблицы и представления словаря БД. Запуск сценария CATPROC.SQL – в результате будут созданы дополнительные таблицы и представления для обеспечения возможности создания хранимых процедур и триггеров. (!)
В составе СУБД Oracle для платформы Windows NT имеется утилита NT Instance Manager, которая упрощает процесс создания БД и экземпляра БД, запускающегося как сетевая служба ОС Windows NT (что обеспечивает автоматический запуск БД при загрузке ОС на ВУ).
Команда создания БД Для создания БД используется команда CREATE DATABASE <название БД> [параметры]. Основные параметры этой команды: – MAXDATAFILES – максимальное число файлов данных, которые могут выделяться для данной БД. – MAXLOGFILES – максимальное число групп регистрации в журнале транзакций для данной БД. – MAXLOGMEMBERS – максимальное число файлов в журнальных группах, которые могут выделяться для данной БД. – DATAFILE – задает начальные файлы данных для пространства таблиц SYSTEM. – LOGFILE – задает начальные группы журнала транзакций и их члены. Пример команды создания БД
165
CREATE DATABASE tsu-ora DATAFILE «c:\orant\database\tsusys1.ora’ SIZE 10M LOGFILE GROUP 1 («c:\orant\database\tsuora1.log’, «d:\mirror\orant\database\tsuora1.log’) SIZE 500K, GROUP 2 («c:\orant\database\tsuora2.log’, «d:\mirror\orant\database\tsuora2.log’) SIZE 500K MAXLOGFILES 10 CHARACTER SET CL8MSWIN1251 Стандартные элементы логической и физической структуры новой БД При создании БД в обязательном порядке распределяется место под пространство таблиц SYSTEM. В этом пространстве создаются и хранятся объекты, формирующие словарь БД (данные о логической структуре БД – пространствах таблиц, таблицах и т.п.), а также все программные объекты PL/SQL (хранимые процедуры, пакеты и т.д.). Это необходимо учитывать при создании БД (в команде создания БД нужно указать файл данных для пространства SYSTEM соответствующего размера). Пространство SYSTEM является активным после монтирования БД и не может быть переведено в неактивное состояние без размонтирования БД. В пространстве SYSTEM создается сегмент отката SYSTEM. Он обеспечивает работу системы транзакций для новой БД. Установка клиентской части Для установки клиентской части СУБД Oracle (на примере Oracle for Windows NT) необходимо запустить программу установки ORAINST.EXE. После ввода информации об используемом языке (English, Russian и т. д.) и указания каталога для установки (например, C:\ORANT) появится диалоговое окно Software Manager. Для работы клиентской части необходимо выбрать следующие компоненты: 1) SQL*NET Client – клиентская часть ПО SQL*Net; 2) Адаптер транспортного протокола (например, TCP/IP Protocol Adapter) – драйвер для упаковки TNS-запросов в сообщения протокола транспортного уровня; а также 3) SQL* Plus – простейшее приложение для формирования и выдачи SQL-запросов;
166
4) Oracle Enterprise Manager – единая утилита управления ресурсами распределенной сети на базе СУБД Oracle. Следующим этапом установки является создание файлов конфигурации ПО SQL*Net (файлы TNSNAMES.ORA, SQLNET.ORA и, если необходимо, TNSNAV.ORA). Для этого можно использовать утилиты SQL*Net Easy Configuration, Oracle Network Manager или обычный текстовый редактор. Пример файла TNSNAMES.ORA ################ # Filename......: tnsnames.ora # Name..........: LOCAL_REGION.world # Date..........: 10-L¦T-98 12:20:07 ################ ORAMX.world = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (COMMUNITY = TCP.world) (PROTOCOL = TCP) (Host = 212.192.96.98) (Port = 1526) ) ) (CONNECT_DATA = (SID = TSU) (GLOBAL_NAME = ORAMX.world) ) ) Пример файла SQLNET.ORA ################ # Filename......: sqlnet.ora # Name..........: TCP.world # Date..........: 10-L¦T-98 12:20:07 ################ AUTOMATIC_IPC = ON TRACE_LEVEL_CLIENT = OFF
167
SQLNET.EXPIRE_TIME = 0 NAMES.DEFAULT_DOMAIN = world NAME.DEFAULT_ZONE = world SQLNET.CRYPTO_SEED = "-184546838-184472507" Параметры экземпляра БД Oracle Все настраиваемые параметры экземпляра БД располагаются в файле параметров INIT%SID%.ORA. Этот файл создается перед созданием БД и содержит следующие параметры: – DB_NAME – название БД, например, tsu-ora. Имя БД в файле параметров и управляющем файле должны совпадать. – DB_DOMAIN – название домена, которому принадлежит БД (важно для распределенных БД), например, world. – CONTROL_FILES – список файлов управления. Если файл используется для создания новой БД, то данные файлы создаются в процессе обработки команды создания БД. – DB_BLOCK_SIZE – размер блоков данных БД (влияет на эффективность операций ввода/вывода). – DB_BLOCK_BUFFERS – количество кэш-буферов для операций записи в файлы данных. Общий объем памяти, занимаемый кэш-буферами, равен DB_BLOCK_BUFFERS*DB_BLOCK_SIZE. – SHARED_POOL_SIZE – размер памяти для разделяемого пула под кэш-буфера словаря БД и библиотечные кэш-буфера. – PROCESSES – число одновременно запускаемых процессов (потоков) для обработки удаленных сеансов связи + 5 процессов для локального подключения. – ROLLBACK_SEGMENTS – список сегментов отката (не являющихся Public-сегментами), которые нужно перевести в доступное состояние при открытии БД. Если сегмент отката не указан в этом списке и он не является Public, то его необходимо будет явно перевести в доступное состояние командой alter rollback segment. – LICENSE_MAX_WARNING – порог максимального количества сеансов связи, после которого система начинает предупреждать о достижении максимума лицензий. – LICENSE_MAX_SESSIONS – максимальное количество сеансов связи, допускаемых лицензионным соглашением. – LICENSE_MAX_USERS – максимально допустимое количество пользователей в системе, ограничиваемое лицензионным соглашением.
168
3.2.3. Служба безопасности и аутентификации
В составе СУБД Oracle присутствует служба безопасности и аутентификации, которая обеспечивает управляемый доступ пользователей к самой СУБД и объектам, хранящимся в БД. Идентификация и аутентификация пользователей в Oracle Чтобы пользователь имел возможность работать с СУБД Oracle, его необходимо зарегистрировать в системе. Для каждого пользователя можно выбрать способ аутентификации – с использованием имени и пароля, хранящихся непосредственно в БД, либо с использованием учетных данных, хранящихся в БД службы справочника ОС. Регистрация пользователя Для регистрации пользователя используется команда: CREATE USER <имя учетной записи> IDENTIFIED {BY <пароль>| EXTERNALLY} [DEFAULT TABLESPACE <имя пространства таблиц для размещения объектов схемы>] [QUOTA <размер квоты> | UNLIMITED ON <имя пространства таблиц> ] [PROFILE <имя профиля>]. Если указан параметр BY <пароль>, то при подключении к СУБД Oracle пользователь должен ввести пароль, хранящийся в БД, в противном случае – указать пароль доступа к учетной записи ОС. Кроме того, должны быть указаны следующие значения параметров файла настроек INIT%SID%.ORA: REMOTE_OS_AUTHENT=TRUE (FALSE – по умолчанию) – использовать учетную информацию службы безопасности в составе ОС. OS_AUTHENT_PREFIX = <prefix> (OPS$ – по умолчанию) – префикс в имени учетной записи пользователя, аутентифицируемого средствами ОС, который необходимо использовать при создании соответствующей учетной записи средствами СУБД.
169
Смена пароля учетной записи Для смены пароля пользователя необходимо выполнить команду ALTER USER <имя учетной записи> IDENTIFIED BY <новый пароль>. Удаление учетной записи Удаление учетной записи пользователя осуществляется командой DROP USER <имя учетной записи>. Стандартные учетные записи После установки Oracle и создания БД, в ней регистрируются следующие учетные записи для выполнения задач администрирования СУБД: INTERNAL – служит для запуска и завершения работы БД. SYS – является владельцем схемы SYS (см. далее). Данную учетную запись необходимо использовать, если: требуется добавить/удалить таблицы словаря БД (в том числе с помощью сценариев CATALOG.SQL, CATPROC.SQL и т.п.); требуется установить новое приложение для СУБД Oracle. SYSTEM – используется для выполнения всех остальных административных функций. Полномочия доступа к БД Для того чтобы пользователь мог работать с СУБД, ему требуется назначить определенные права доступа или полномочия. Существует два типа полномочий: Системные – дают пользователю права на выполнение определенных операций с любыми объектами БД и самой БД. Примеры: – ALTER DATABASE – право на модификацию физической структуры БД, т.е. возможность определять новые файлы данных, журнальные файлы и т.д.; – CREATE USER – право на создание учетных записей пользователей в системе; – DROP ANY USER – право на удаление учетных записей; – DROP ANY TABLE – право на удаление таблиц, созданных в любой схеме БД.
170
(!)
Неумелое пользование такими мощными системными полномочиями, как alter database, alter tablespace, а также grant any privilege, может привести к непоправимым изменениям в базе данных. Поэтому администратор Oracle обязан распределять полномочия только в том объеме, в каком это требуется.
Объектные – дают пользователю права доступа к какому-либо объекту или атрибуту объекта БД. Примеры: – Select – право на извлечение информации из конкретной таблицы; – Insert – право на добавление записей в таблицу; – Update – право на внесение изменений в существующие записи в таблице; – Delete – право на удаление записей из таблицы. Всего в Oracle насчитывается около 60 системных и объектных полномочий. Предоставление системных полномочий Системные привилегии назначаются командой: GRANT {список системных полномочий} TO {список пользователей или ролей} [WITH ADMIN OPTION] (!)
Пользователь, обладающий конкретным видом системных полномочий, может предоставить другому пользователю такие же полномочия, если ему предоставлены эти полномочия с опцией ADMIN.
Отмена системных полномочий Чтобы отменить предоставленные пользователю системные полномочия, используется команда: REVOKE {список системных полномочий} FROM {список пользователей или ролей}
171
Предоставление объектных полномочий Объектные привилегии назначаются командой: GRANT {список объектных привилегий (список атрибутов объекта)} | ALL PRIVILEGES ON {объект схемы} TO {список пользователей или ролей} [WITH GRANT OPTION] (!)
Пользователь, обладающий конкретным видом объектных полномочий, может предоставить другому пользователю такие же полномочия, если ему предоставлены эти полномочия с опцией GRANT.
Отмена объектных полномочий Чтобы отменить предоставленные пользователю объектные полномочия, используется команда: REVOKE {список объектных полномочий} | ALL PRIVILEGES ON {объект схемы} FROM {список пользователей или ролей} Схема пользователя После создания учетной записи пользователя и назначения ей определенных полномочий, последний может подключаться к СУБД и выполнять соответствующие полномочиям команды на языке SQL. Если у пользователя есть полномочия на создание объектов БД, то вновь созданные объекты, по умолчанию, будут помещаться в схему пользователя. Схема пользователя – это набор объектов, находящихся во владении данного пользователя. Каждый пользователь обладает полными объектными привилегиями в своей схеме. Для доступа пользователя к объектам схемы другого пользователя требуется назначить полномочия доступа, и, возможно, создать синоним данного объекта в личной схеме пользователя либо создать PUBLICсиноним, т.е. синоним, расположенный в схеме PUBLIC. Схема PUBLIC Схема PUBLIC существует с момента создания БД. Объекты этой схемы доступны всем пользователям БД. Кроме того, в этой схеме пользователи могут создавать синонимы для обращения к объектам своих схем. Для создания объекта в схеме PUBLIC необходимо это явно указывать в команде создания объекта.
172
Схема SYS Схема SYS существует с момента создания БД. Объекты этой схемы доступны только администраторам БД (роль DBA) и, частично, разработчикам СУБД. В этой схеме хранятся все таблицы словаря БД, а также все программные элементы. Роли Роль – это логическая структура, которая может содержать в себе другие роли, а также системные и объектные привилегии. Роли облегчают управление полномочиями групп пользователей (ср. с объектами-группами службы справочника ОС). Кроме того, роли позволяют динамически менять домен (текущий набор) полномочий пользователей. Пространство системных полномочий роли не распростра(!) няется на хранимые процедуры, триггеры, процедуры и функции. Это необходимо учитывать при разработке приложений. Создание роли Для создания роли используется команда: CREATE ROLE <имя> {NOT IDENTIFIED | IDENTIFIED {BY <пароль>| EXTERNALLY}}. Изменение пароля для роли Для модификации роли используется команда ALTER ROLE <имя> {NOT IDENTIFIED | IDENTIFIED {BY <пароль> | EXTERNALLY}}. Предоставление полномочий через назначение роли Для предоставления полномочий через установление эквивалентности с ролями существует команда GRANT {список ролей} TO <имя пользователя или роли> [WITH GRANT OPTION]. Лишение полномочий, предоставленных через роли Для лишения полномочий пользователя или роли используется команда REVOKE {список ролей} FROM {<список пользователей или ролей}.
173
Установка активной роли Чтобы активизировать определенную роль для всех пользователей приложения, используется команда SET ROLE <имя роли>. Пользователь, запустивший приложение, получит права в строгом соответствии с ролью, назначенной на сеанс работы приложения. Стандартные роли После установки Oracle и создания БД автоматически создаются следующие роли: 1. DBA – обладает полными правами на БД, 2. CONNECT – позволяет подключиться к БД и создавать объекты (таблица, представление и т.п.) в своей схеме БД, 3. IMP_FULL_DATABASE – обладает правом на импорт всей БД, 4. EXP_FULL_DATABASE – обладает правом на экспорт всей БД, 5. RESOURCE – предоставлены права на разработку серверной части приложения, т.е. создание программных объектов типа хранимая процедура, пакет и т.п. Профили Для ограничения возможности пользователей использовать вычислительные ресурсы ВУ в Oracle используются профили. Профили обеспечивают управление: 1) использованием ЦП и дискового ввода-вывода по операторам и сеансам; 2) числом сеансов на каждого пользователя; 3) максимальным временем подключения и временем простоя для каждого сеанса; 4) объемом оперативной памяти, используемой сеансом работы пользователя.
(!)
Дополнительно при создании пользователя можно задать ограничения на использование дискового пространства пользователем, пространства таблиц для схемы пользователя (параметр QUOTA команды создания пользователя).
174
Создание профиля Для создания профиля используется команда CREATE PROFILE <имя > [параметры]. Назначение профиля пользователю Для назначения профиля пользователю используется параметр PROFILE команды создания пользователя (см. ранее). Профиль DEFAULT Создается автоматически после установки Oracle и создания БД. Этот профиль назначается пользователям, которым не присвоен явно профиль. Сразу после установки профиль DEFAULT не имеет никаких ограничений на использование ресурсов. 3.2.4. Обеспечение надежности
Для обеспечения надежности хранимой информации и возможности восстановления при сбоях в СУБД Oracle имеются следующие встроенные механизмы: резервное копирование БД и журналирование транзакций. Резервное копирование БД В СУБД Oracle cуществует несколько типов операции резервного копирования: – для всей БД – обеспечивает создание архивных копий всех файлов СУБД (полное копирование); – для пространства таблиц – обеспечивает создание архивных копий всех файлов, относящихся к конкретному пространству таблиц; – для отдельного файла данных – обеспечивает создание архивной копии отдельного файла данных; – для управляющего файла – позволяет создать резервную копию управляющего файла без выгрузки экземпляра БД; – для журнальных файлов – обеспечивает создание резервных копий журнальных файлов. Может выполняться вручную, либо автоматически процессом ARCH (см. далее).
175
Резервное копирование БД может выполняться в одном из двух режимов: 1) Автономный – для выполнения резервного копирования необходимо предварительно завершить работу экземпляра БД. Это единственный режим, доступный для БД с параметром NOARCHIVELOG. 2) Оперативный – резервное копирование выполняется при запущенном экземпляре БД. Используется, если требуется постоянная доступность БД. Резервное копирование БД в автономном режиме Для выполнения резервного копирования в автономном режиме: 1. Завершите работу экземпляра БД. 2. Средствами ОС или с помощью ПО резервного копирования создайте резервные копии файлов данных, управляющего файла и файла параметров INIT%SID%.ORA. 3. Если выключен режим создания архивных копий журнала (NOARCHIVELOG), то создайте копии журнальных файлов. 4. Запустите экземпляр БД в обычном режиме. Резервное копирование БД в оперативном режиме Для выполнения резервного копирования в оперативном режиме: 1. Выполнить резервное копирование файлов данных всех табличных пространств. Для этого необходимо выполнить следующий порядок действий для каждого оперативного пространства таблиц: 2. Выполнить команду ALTER TABLESPACE <имя пространства> BEGIN BACKUP. 3. Используя команды ОС, создать резервные копии файлов данных. 4. Выполнить команду ALTER TABLESPACE <имя пространства> END BACKUP. (!)
Для автономных пространств таблиц достаточно просто создать резервные копии файлов данных средствами ОС или ПО резервного копирования.
176
5. Выполнить резервное копирование управляющего файла. Для этого необходимо выполнить команду ALTER DATABASE BACKUP CONTROLFILE TO «<имя резервной копии файла>». 6. Создать резервную копию файла параметров. (!)
В составе СУБД Oracle для платформы Windows NT есть утилита Backup Manager, с помощью которой операция резервного копирования БД в оперативном режиме выполняется предельно просто. Журналирование транзакций
В СУБД Oracle журналирование транзакций ведется с использованием журнальных файлов (redo log files). Перечислим типичные ситуации, при которых возникает необходимость ведения журналирования: 1) Неосторожная работа пользователя, при которой последний удаляет важные данные из таблицы и транзакция уже завершена. 2) Сбои по причине разрыва связи между клиентом и сервером. 3) Сбои при работе экземпляра БД вследствие физических или логических сбоев. 4) Сбои аппаратуры, которая обеспечивает хранение базы данных. Структуры данных для журналирования транзакций При создании БД необходимо определить журнальные группы. Изначально таких групп должно быть не менее двух. Каждая журнальная группа может объединять один и более журнальных файлов. Если в группе несколько файлов, то они являются зеркальными копиями и обеспечивают дополнительную надежность хранения журнала транзакций. Позже можно создавать новые журнальные группы, а также дополнительные файлы в существующих группах. Максимальное количество журнальных групп и журнальных файлов определяется параметрами команды создания БД (см. ранее). Каждый журнальный файл состоит из последовательностей регистрации транзакций. Последовательность регистраций состоит из записей отката (Redo Records) – группы векторов, определяющей
177
одно атомарное изменение (чаще всего, одна «простая» команда на языке SQL). Механизм журналирования Механизм журналирования включается автоматически после создания и первого обращения к БД. При завершении транзакции процесс LGWR записывает измененные данные из кэш-буфера журнальных файлов в журнальные файлы текущей группы журналирования. При заполнении файла(-ов) журналирования текущей группы производится смена текущей группы, при этом заполненная группа помечается как требующая архивирования. Операция архивирования производится теневым процессом ARCH и может происходить как в ручном, так и в автоматическом режиме. При автоматическом режиме заполнение группы сразу вызывает теневую операцию архивирования файлов заполненной группы (работа с БД не прерывается, так как есть еще незаполненные группы). При ручном режиме файлы журнальной группы архивируются администратором БД вручную. Если при таком режиме работы не окажется свободных групп, то процесс LGWR приостановит работу пользователей с БД и не сможет ее продолжить, пока не будет выполнена операция архивирования. Параметры управления журналированием Для сохранения накопившихся в журнальных файлах серий транзакций имеется возможность создавать архивы журнальных файлов. Для этого для базы данных необходимо установить значение TRUE параметра ARCHIVELOG. По умолчанию этот параметр имеет значение FALSE, т.е. СУБД работает в режиме NOARCHIVELOG (при заполнении всех групп журнальные файлы начинают использоваться снова, при этом ранее сохраненная информация о происходивших в системе транзакциях просто будет затираться). (!)
Режим ARCHIVELOG не рекомендуется устанавливать сразу при создании БД, так как это может вызвать замедление в работе СУБД из-за необходимости журналирования всех транзакций, происходящих при создании БД.
Для возможности архивирования в автоматическом режиме предусмотрены следующие параметры в файле INIT%SID%.ORA:
178
– LOG_ARCHIVE_START – значение TRUE обеспечивает автоматическое создание резервных копий журнальных файлов, а значение FALSE требует выполнения ручного архивирования. – LOG_ARCHIVE_DEST – определяет место (каталог файловой системы), где будут создаваться резервные копии журнальных файлов. Восстановление данных в СУБД Oracle Для восстановления информации в БД система Oracle выполняет повторное выполнение транзакций, записанных в журнальные файлы и, возможно, резервные копии журнальных файлов. Существует два типа отказов, которые могут повлечь выполнение операции восстановления: 1) Аварийный отказ системы. Такие отказы могут быть вызваны программным или аппаратным сбоем (например, сбоем электропитания или ошибкой в ОЗУ). При этом некоторые транзакции могли остаться незавершенными, а другие транзакции были завершены, но данные из кэш-буферов не успели попасть в файлы на диске. Файлы данных при этом остаются в непротиворечивом состоянии. 2) Отказ дисковой подсистемы. Отказы такого типа обусловлены механическими сбоями в дисковой подсистеме ВУ. При этом возможно нарушение целостности хранящихся на дисках ВУ файлов БД. Восстановление БД после аварийного отказа системы После восстановления электропитания и запуска сервера СУБД Oracle выполняет восстановление БД автоматически. При этом к файлам данных будут применены все необходимые изменения, занесенные в журнал транзакций. Также будут повторно выполнены завершенные в памяти транзакции, занесенные в журнал. Результаты незавершенных транзакций будут утеряны. Восстановление БД после отказа дисковой подсистемы Восстановление после отказа дисковой подсистемы требует помощи со стороны администратора БД и включает следующие шаги: 1. Устранение всех аппаратных проблем. Включает, в общем случае, замену запорченного диска, его форматирование и воссоздание структуры каталогов файловой системы.
179
2. Восстановление запорченных файлов данных. Заключается в размещении на месте запорченных файлов данных последних резервных копий этих файлов. 3. Восстановление журнальных файлов, управляющего файла и файла параметров. Заключается в размещении на месте запорченных файлов последних резервных копий этих файлов или их зеркальных копий с других дисков (для управляющего файла и журнальных файлов). 4. Восстановление архива журнала транзакций. Заключается в размещении в каталоге архива журнала транзакций (параметр LOG_ARCHIVE_DEST) всех резервных копий журнальных файлов с момента выполнения последнего резервного копирования файлов данных (если использовался режим ARCHIVELOG). 5. Запуск процесса восстановления. Для запуска процесса восстановления необходимо: 6. Запустить утилиту Server Manager 7. Подключиться как пользователь INTERNAL 8. Запустить экземпляр БД без выполнения монтирования БД, выполнив команду STARTUP NOMOUNT 9. Выполнить команду RECOVER ALL. Вопросы и задания 1. Какое место в рамках ИВС отводится для СУБД? 2. Назовите основные объекты реляционной БД. 3. Дайте определения основных понятий, использующихся в реляционной СУБД в архитектуре «клиент-сервер». 4. Укажите составные части СУБД Oracle. 5. Опишите физическую структуру БД Oracle. 6. Укажите структуры в составе СУБД Oracle для обеспечения безопасности и аутентификации. 7. Для каких целей в СУБД Oracle используется журналирование транзакций? Опишите структуры данных для обеспечения журналирования и процедуру журналирования. 8. Какие возможны сбои при работе СУБД? Опишите порядок восстановления БД Oracle в случае сбоев.
180
Г л а в а 4 . ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ДЛЯ ГРУППОВОЙ РАБОТЫ 4.1. Общие вопросы Корпоративную ИВС невозможно представить без программных средств взаимодействия пользователей. Первоначально роль программного средства взаимодействия выполняла электронная почтовая система. Сегодня на смену обычной почтовой системе пришло программное обеспечение (ПО) для груповой работы. 4.1.1. Определение ПО для групповой работы
Большинство определений ПО для групповой работы (далее «GroupWare») принимает к рассмотрению только одну сторону проблемы. Разработчики ПО для взаимосвязи, нацеленного на «проталкивание» информации в организацию, считают передачу сообщений центральной технологией ПО для групповой работы. Поставщики ПО для совместной работы, включающее вопросы совме-
стного
Рис. 12. ПО групповой работы
181
использования информации, считают электронные конференции и совместно использующиеся БД центральным звеном GroupWare. Те же, кто работает с продуктами для координации работы коллективов над проектами, включая вопросы совместного расписания, полагают автоматизацию задач и упраление процессами основой GroupWare. На самом деле, GroupWare – это пересечение всех вышеперечисленных технологий (рис. 12): передача сообщений, разделяемые БД и управление процессами, и даже нечто большее, чем просто их сумма. 4.1.2. Функции ПО для групповой работы
GroupWare обеспечивает выполнение трех основных функций: 1) Взаимосвязь (Communication) – подразумевает передачу электронных сообщений. 2) Совместная работа (Collaboration) – подразумевает работу пользователей, происходящую в совместно используемом виртуальном пространстве. 3) Координация (Coordination) – предполагает добавление структуры деловых процессов к первым двум функциям с целью обеспечить политику функционирования предприятия. Для реализации перечисленных функций GroupWare интегрирует в себе три основные технологии: 1) Модель для распространения и доступа к информации, которая позволяет пользователям легко находить и перемещать информацию. 2) Модель объектного хранилища, в котором корпоративные знания (сообщения, документы, бланки, записки, отчеты) могут храниться и обрабатываться. 3) Структурированная среда для разработки приложений, которая позволяет активно использовать возможности модели объектного хранилища и модели доставки и доступа.
182
4.1.3. Требования к ПО групповой работы
Учитывая специфику GroupWare, представим основные требования к GroupWare: 1) Независимость от программно-аппаратной платформы. Подразумевает поддержку большого количества клиентов, сетей и сетевых ОС, а также независимость логической структуры GroupWare, принципы администрирования и программных средств разработки от программно-аппаратной платформы. 2) Поддержка удаленных и мобильных пользователей. Подразумевает возможность объединить географически разнесенных пользователей для взаимодействия и получения актуальной информации. 3) Поддержка бесшовного взаимодействия с информационными компонентами предприятия. Предполагает возможность тесной интеграции с внешними ресурсами и источниками информации: офисными приложениями, СУБД, а также внешними службами справочника, например в составе серверной ОС. 4.1.4. Составные части
Для рассмотрения составных частей предложены две шкалы измерений (рис. 13), характеризующих роль той или иной технологии, которую последняя играет в составе GroupWare:
Рис. 13. Составные части Groupware на шкалах структурированности и активности
183
Cтепень структурированности (низкая <-> высокая), заложенная в технологию. Например, свободное распространение электронных cообщений или жестко структурированный процесс прохождения некоторого заказа по определенному маршруту; Уровень активности (пассивность <-> активность) технологии в стимулировании GroupWare (как осуществляется взаимодействие компонентов технологии и пользователей – участников групповой работы). Пассивные приложения полностью полагаются на управляющую роль пользователя или группы пользователей, в то время как активные приложения сами могут направлять или управлять работой пользователя или группы. Например, электронные конференции, основанные на совместно используемых БД сообщений, позволяют пользователям самим формировать нить разговора (отвечать или игнорировать новые сообщения), в то время как системы отслеживания процессов активны и при наступлении определенного события сами оповещают пользователя). Рассмотрим далее основные технологии в составе GroupWare и их место на предложенных шкалах. Взаимосвязь Взаимосвязь – это, прежде всего, передача знаний. Роль системы связи состоит при этом в создании пассивной электронной среды для передачи информации. Электронная почта (E-mail) – это средство для пересылки сообщений в электронном виде. Электронная почта во многом похожа на обычную почту: в ней используются такие понятия, как почтовый ящик, отправитель и адрес отправителя, получатель и адрес получателя, сообщение (или письмо). Однако в отличие от обычной почты электронное письмо доходит до адресата намного быстрее, а пользователям электронной почты не нужно тратить деньги на конверты, марки и бумагу. Кроме того, просто указав в качестве получателя не одно лицо, а группу лиц, можно отправить электронное письмо сразу нескольким адресатам, не тратя при этом лишнего времени на дублирование сообщения. Являясь одной из технологий обеспечения взаимосвязи, электронная почта предполагает обязательную транспортировку электронных объектов по принципу «сохранил – передал дальше» между людьми, людьми и ПО, между разным ПО. Основная особенность
184
электронной почты: ее асинхронный характер передачи, а также принцип «выталкивания» информации (что говорит об активном характере системы по отношению к пользователю). Электронная почта изначально ориентирована на доставку сообщений и не предполагает управление потоками информации. Расширение функций электронной почты привело к иному пониманию и функционированию составной части почтовой службы – почтового ящика, который превратился в хранилище сообщений. Если раньше почтовый ящик был временным местом хранения сообщений, то теперь хранилище сообщений превратилось в универсальный контейнер для большого количества корпоративной информации (включая документы с «бесконечным временем жизни»). Изначально хранилище сообщений, как и его предшественник – обычный почтовый ящик, не было предназначено для постоянного хранения информации и тем более управления этой информацией. Однако с расширением роли хранилища сообщений появились приложения-расширения электронной почты для манипуляции над попадающими в хранилище информационными сообщениями (размещение по папкам, автоматическое преобразование, пересылка и т.п.), а также программные интерфейсы (Messaging API, например) для доступа к хранилищам сообщений из офисных и других приложений. Однако «историческое» отсутствие в технологии электронной почты средств анализа, структуризации (текст сообщения не формализуем, а только по полям «Тема сообщения» и «Автор» сложно отследить последовательность и взаимосвязь приходящих и отправляемых сообщений) и контроля потока сообщений не позволяет эффективно использовать эту технологию для работы в группе. Очень эффективно обеспечивая среду для связей типа 1–1 и 1–N, системы передачи сообщений сталкиваются с проблемой управления потоками сообщений при использовании электронной передачи сообщений в режиме N–N, и полезность такой системы снижается. Для эффективного управления потоками информации требуются другие технологии. Электронную почту можно считать основой систем групповой работы как в историческом плане, так и в плане информационном.
185
Поколения систем электронной почты 1. Передача простых текстовых сообщений. 2. Передача двоичных документов вместе с текстовыми сообщениями. 3. Передача сообщений в сложном формате (Rich Text) c цветом, оформленных различными шрифтами, а также с внедренными объектами в самом теле сообщения (а не в качестве подключения). 4. Передача сообщений, имеющих в теле сообщения гиперссылки на документы в БД и файлы. Вместо внедрения в тело сообщения объекта, указывается гиперссылка, позволяющая оперативно достигнуть объект, на который сделана ссылка. Теперь документы в совместно используемой БД не будут лежать мертвым грузом. Послав краткое уведомление с гиперссылкой, отправитель: – избавляет пользователя от необходимости самому выискивать документ, – не загромождает сеть передачей сообщений с большим количеством информации. Почтовые системы данного поколения будем называть интегрированными системами для отправки сообщений и групповой работы. Совместная работа Совместная работа опирается на разделяемое пространство. Это может быть реальное разделяемое пространство: комната, доска; либо виртуальное пространство, созданное посредством вычислительной техники (например, совместно использующаяся БД). Совместная работа может иметь как форму сотрудничества двух лиц, так и структуру связей N–N. Так же как и для электронной передачи сообщений, технология совместной работы свободна от ограничений во времени и пространстве. Вводя технологию электронной совместной работы, можно минимизировать количество очных встреч, оставляя на них заключительную часть совместной работы. Недостатком электронной почты была названа сложность процесса соотнесения информации с необходимой темой. При этом также достаточно сложно было проанализировать последовательность запросов и ответов на запрос в неупорядоченном потоке сообщений. Напрашивается идея расширить электронную почту возможностями поддержки разделяемой дискуссии в оперативном (online) режиме.
186
В электронной почте информация хранится по личным почтовым ящикам пользователей, в то время как при совместной работе вся информация хранится в общей БД. Совместно использующиеся (или разделяемые) БД реализуют возможности совместной работы, предоставляя виртуальное пространство с интерфейсом, ориентированным на группу лиц, совместно использующих информацию и идеи. В отличие от электронной почты разделяемые БД используют модель «вытягивания» информации. Пользователи сами решают – «забирать» (т.е. воспринимать) появляющуюся информацию или просто игнорировать ее. Для удобства совместной работы группы может быть предусмотрена возможность уникального для конкретного человека способа представления информации, а также средства для создания своих собственных представлений. Еще одной особенностью совместной работы является пассивный характер системы. При этом пользователь может получить интересующую его информацию, а может и не получить. Все зависит от степени активности пользователя. На базе электронных систем совместной работы родилась новая область жизнедеятельности – электронная коммерция (E-commerce). Несмотря на множество достоинств, данная технология не идеальна для реализации GroupWare, так как вовлечение пользователя в процесс работы в группе целиком зависит от поведения самого пользователя (пассивный характер информационного поля), кроме того, базы данных совместного доступа часто перегружены избыточной информацией. Результат поиска важной для пользователя информации целиком зависит от его личных качеств. Хорошим примером реализации технологии совместной работы являются электронные конференции (NEWS), а также служба WWW сети Internet. Координация Вышеперечисленные способы взаимодействия имеют неструктурированную природу. Например, посылая почту или обращаясь к разделяемым ресурсам, пользователи исходят, прежде всего, из своих личных побуждений. Но многие бизнес-процессы по своей природе структурированы. Например, получение отчета о деятельности финансовых органов очень сильно зависит от структуры организации и маршрутов, по которым ведется передача финансовых средств. Поэтому при такой форме работы для ее успешного завер-
187
шения требуется некоторая координация действий людей. Для решения проблемы координации были разработаны системы автоматизации делопроизводства. Там, где сотрудничество пассивно по своей природе (мы создаем разделяемое пространство, но не указываем, как его использовать), координация достаточно активна с точки зрения системы (явно указывается, каким образом действия совершаются). Когда мы выбираем координацию вместо сотрудничества, то хотим реализовать систему делопроизводства, которая включала бы: – определение форм; – указание операций над этими формами; – указание маршрута движения форм; – способ доступа к внешним данным; – способ реакции при наступлении определенных событий. Другими словами, мы хотели бы иметь возможность разрабатывать приложения для делопроизводства, а инструмент создания таких приложений обеспечивал бы нам необходимую координацию. Однако реальная работа включает порой как сильно структурированные процессы, так и размытые, неформализованные. Кроме того, правила и маршруты могут динамически меняться в процессе работы. Все это подводит к мысли о том, что только интегрированное решение, которое координирует использование как передачи сообщений для информирования, так и разделяемых БД для сотрудничества, является более сбалансированным и полноценным подходом к вопросу поддержки структурированных и неструктурированных процессов. 4.1.5. Выводы
Очевидно, что системы делопроизводства выросли на основе систем передачи электронных сообщений и систем на основе совместно используемого электронного хранилища информации. Система передачи сообщений обеспечивает базовые функции для транспортировки формализованного информационного сообщения по определенному маршруту (с целью оповещения и для визирования), а электронное хранилище служит для хранения, извлечения, просмотра и управления информационными документами, представляющими собой определенные продукты на разных стадиях делопроизводства.
188
Таким образом, интеграция нескольких информационных технологий позволяет создать ПО, обеспечивающее эффективную работу пользователей в группах. Подводя итоги, укажем основные элементы для реализации ПО для групповой работы: 1) Модель объектного хранилища. Включает: – сложные объекты различного типа; – иерархию документов; – поддержку версий документов; – гиперссылки; – единую и последовательную структуру базовых объектов, на которых строятся приложения пользователей (полнотекстовый поиск и возможности извлечения данных). 2) Модель для распространения и доступа. Включает: – механизм маршрутизации сообщений по принципу «сохрани– и–передай»; – механизмы тиражирования (репликации), включая: – механизмы по условной репликации (тиражирование набора документов/полей документов); – поддержку различных схем репликации (одно- и двусторонних), включая репликацию клиент-сервер и сервер–сервер; – обеспечение автоматического распределения приложений; – надежное взаимодействие точка–точка. 3) Структурированная среда для разработки. Предполагает: – наличие встроенного языка программирования и инструментальных средств для разработки приложений: – поддержку всех стандартных элементов языка программирования (переменные, массивы, операторы условия, цикла и т.д.); – наличие современной среды разработки (IDE) со встроенным редактором форм и обработчиков событий, средством просмотра библиотеки классов и встроенным отладчиком; – высокий уровень абстракции; – возможность создания современного GUI для приложений; – наличие независимого от программно-аппаратной платформы программного интерфейса, который обеспечивает: – прозрачный доступ к механизму клиент-серверного взаимодействия; – доступ к возможностям подсистем электронной почты и подсистемы совместного хранилища информации;
189
– поддержку многочисленных клиентских и серверных платформ и переносимость; – гибкую среду для конечного пользователя разработанных приложений; – настраиваемые представления для отображения информации в документах; – категоризацию документов (сортировка по типу); – автоматизацию процессов обработки документов с помощью настраиваемых агентов. 4) Встроенная система безопасности. Включает: – механизмы аутентификации; – контроль доступа к объектам и документам; – шифрование на уровне полей и документов; – электронная подпись. 5) Служба справочника. Включает: – элементы (объекты) службы справочника могут описываться в произвольной форме с использованием данных различного типа (текст, графика, аудио, видео); – определяемые пользователем системы поля (свойства) объектов справочника; – обеспечение в объектах ссылок на другие элементы справочника; – механизмы сертификации созданных объектов открытым ключом; – поддержку ролей – возможность соотнесения объектов с типовой ролью, для которой определяются права доступа, режим доступа и т.д.; – списки репликации и маршрутизации – для обеспечения эффективного механизма доставки информации. В следующих разделах будет рассмотрено ПО для групповой работы и почтовая система в его составе, а также принципы администрирования такого ПО на примере пакета групповой работы Lotus Domino/Notes.
190
4.2. Пакет групповой работы Lotus Domino/Notes Пакет групповой работы Lotus Domino/Notes (далее «Lotus Notes») является признанным лидером на рынке ПО групповой работы. Мы рассмотрим данный пакет на примере Lotus Domino/Notes версии 4.61. 4.2.1. История и версии пакета
Взаимное влияние технологий, использующихся в разнообразном ПО для групповой работы, привело к появлению пакета Lotus Notes – системы нового поколения, интегрирующей в себе возможности электронной почты, системы для совместного обсуждения проблем и средства планирования процессов. Этот пакет появился в 1989 г. и был ориентирован на поддержку архитектуры «клиентсервер». Изначально пакет был рассчитан на большие компании, поэтому при разработке основными требованиями были: масштабируемость, поддержка множественных платформ и переносимость. Рассмотрим далее основные версии Lotus Notes. Lotus Notes 3.x Появился в 1993 г. Была обеспечена поддержка еще значительно большего количества платформ: помимо версии для OS/2, появились серверные части пакета для ОС Windows 3.1 и Novell NetWare. Усовершенствованы механизмы двусторонней репликации. Появился новый программный интерфейс для разработчика (@-функции). Обеспечена поддержка иерархических имен для объектов службы справочника. Lotus Notes 4.x Появился в 1995 г. 1) Архитектурные изменения: новые схемы репликации, возможность репликации изменений на уровне полей документов. 2) Новая среда и возможности для разработки: папки, навигаторы; объектно-ориентированный язык LotusScript; агенты (на сервере и на клиенте). 3) Новые возможности для пользователя: интерфейс для пользователя в стиле cc:Mail (три области на экране – дерево папок/представлений, панель представления, панель документа); почтовый ящик с функциями органайзера (из пакета Lotus Organizer); закладка Replicator для прозрачного доступа к функциям репликации на клиенте.
191
4) Средство WebNavigator для просмотра ресурсов Интернет, не покидая клиента Notes (функция Proxy при запуске с сервера). Lotus Domino/Notes 4.x В июне 1996 г. компания Lotus представила революционный продукт Lotus Domino 1.0 (первоначально поставлялся как отдельный продукт для Lotus Notes 4.x), который интегрировал сервер Lotus Notes с сетью Internet (HTTP-сервер, SMTP/POP3-сервер, NNTP-сервер). После выхода версии Domino 1.5 (добавился IMAP4сервер, поддержка протокола LDAP), последний стал составной частью пакета Lotus Notes (новое название пакета Lotus Domino/Notes версии 4.5). Появились возможности по распределению нагрузки и обеспечению бесперебойной работы (Notes Clustering), начался процесс выделения средств разработки в отдельный продукт (Lotus Domino/Notes Designer). Интегрированы Java-технологии (Domino/Notes 4.6). Добавилась возможность интеграции адресных книг (поиск, управление доступом, централизованное внесение изменений в настройки) за счет Главной адресной книги – проще организовать взаимодействие и обмен информацией для двух и более организаций (доменов). Lotus Domino/Notes 5.x Появился в 1999 г. Новая среда для пользователя: интегрированный броузер Интернет в рабочий стол клиента Notes; настраиваемая стартовая страница HeadLines; переключение между документами, открытыми в окне клиента Notes; . Новая среда и возможности для разработки : табулированные закладки в документах, новые таблицы, инструментарий разработчика вынесен в Lotus Domino Designer. Архитектурные особенности: новый формат БД; новый формат универсального почтового ящика (хранение сообщений в формате HTML); журналирование транзакций при работе с данными – возможность инкрементного копирования, быстрый перезапуск после сбоев. Поставка сервера: c Lotus Domino 5 помимо ставших уже стандартными служб для работы в Internet (WWW, POP3, SMTP, IMAP4, LDAP) поставляется сервер DECS для связи с хранилищами данных в формате, отличном от Notes (реляционные СУБД), а также утилита администрирования Domino Administrator.
192
4.2.2. Основные компоненты и функциональные возможности, не зависящие от версии
Прежде чем представить программные компоненты в составе пакета, укажем основные понятия для пользователя. Основные понятия для пользователя Вся информация Lotus Notes представлена документами (Documents). Документ состоит из полей (Fields) или объектов всевозможных типов. Документ создается на основе формы или шаблона (Template) – документа специального формата. То есть с каждым документом связана форма, на основе которой он был создан. Документы хранятся в базах документов Notes. БД Notes представляют собой объектные хранилища и хранятся на диске как файлы с расширением .NSF. Файлы, содержащие только формы, имеют расширение .NTF. БД могут храниться как на сервере Notes, так и на рабочей станции Notes (см. далее «Построение сети Lotus Notes»). Для персонифицированного просмотра содержимого БД создаются представления (Views). С представлением связан индекс, обеспечивающий быструю выборку необходимого документа. Для обеспечения надежности хранения информации, а также оперативности доступа используется механизм тиражирования/репликации (Replication Mechanism) БД. Система безопасности обеспечивает контролируемый и авторизованный доступ к БД Notes и совместно используемым документам (см. далее «Система безопасности»). Для обработки информации в документах могут использоваться агенты, написанные с использованием языка сценариев LotusScript. Агенты могут выполняться как на рабочей станции, так и на сервере. Пакет Lotus Notes интегрирует в себе следующие элементы: Документ-ориентированная БД. БД Notes поддерживают хранение сложных типов объектов, иерархию документов, механизм версий, гипертекстовые ссылки и индексирование информации для обеспечения быстрого поиска. Средства разработки приложений в архитектуре «клиентсервер». Пакет Lotus Notes включает дизайнер форм, представле-
193
ний, агентов. На сервере обеспечивается запуск любого количества задач Notes и выполнение программных агентов. Средства тиражирования данных. Включают поддержку различных схем репликации c эффективными механизмами минимизации порождаемого сетевого трафика как между серверами Notes, так и между рабочей станцией и сервером. Cистема электронной почты. Включает передачу присоединенных файлов, поддержку сложных типов данных, поддержку активных гипертекстовых ссылок. Для доставки и получения почтовых сообщений в формате, отличном от Notes, используются почтовые агенты (Message Transfer Agents/MTAs), работающие на сервере и преобразующие перед отправкой сообщения в нужный формат. Имеются агенты для SMTP, POP3, IMAP4, cc:Mail, X.400. Средства защиты данных. Для обеспечения секретности хранимой информации в Notes интегрирована система безопасности на основе механизмов электронной подписи, шифрования открытым и закрытым ключом и технологии сертификатов. Доступ к ресурсам Notes через Internet. Обеспечивается встроенной в Notes (с версии 4.5х) службой Domino, являющейся средством для публикации документов Notes в HTML-формате. Бесшовный доступ к ресурсам Internet клиентов Notes (с версии 4.1х). Обеспечивается путем просмотра БД WebNavigator, в которую автоматически закачиваются документы из Internet. Фактически реализуется функция кэширования WWW-ресурсов (ср. Proxyсерверы). 4.2.3. Построение сети на основе Lotus Notes
Пакет Lotus Notes реализует архитектуру «клиент-сервер». При построении сети выделяются два типа узлов: Рабочая станция Notes (Notes Workstation) – это рабочая станция сети с установленной клиентской частью пакета Lotus Notes, которая представляет собой виртуальный рабочий стол пользователя. С рабочей станции пользователь может создавать, редактировать и удалять документы, просматривать с помощью различных представлений содержимое БД, хранящихся как локально, так и на серверах Notes. Сервер Domino/Notes (Domino/Notes Server) – это сервер сети с установленной серверной частью пакета Lotus Notes. Представлен
194
консолью и множеством задач Notes, функционирующих в рамках основного процесса сервера (на сервере Windows NT каждая задача реализуется отдельным процессом). Множество задач Notes (например, Replicator, Database Server, SMTP MTA и т.п.), запускаемых автоматически при старте сервера или вручную, определяют функциональные возможности сервера Notes. Серверы Notes предназначены прежде всего для хранения информации в БД, обработки запросов на получение информации из этих БД, а также выполнения обработки информации, хранящейся в БД. Серверы Notes объединяются в домены Notes. Домен Notes Домен Notes (Notes Domain)– это поименованная группа серверов Domino/Notes, использующих одну и ту же по содержанию БД «Общая адресная книга» (далее «Адресная книга»). При планировании структуры распределенной системы Lotus Notes в организации, необходимо решить, сколько доменов использовать. Следующая таблица поможет сделать правильный выбор: Один домен Много доменов (+) Проще адреса- Меньше времени уходит на поиск в адция почты ресной книге Проще управление всей сетью
(–)
Быстрая передача почты Увеличивается время поиска в адресной книге Менее надежно, так как есть зависимость от центра
Независимость управления – проще администрировать части (несколько администраторов) более эффективное использование памяти серверов и рабочих станций Необходимость указывать имя домена при адресации (см. поле Names файла инициализации) Труднее вести обслуживание всей системы
Медленнее происходит передача почты Адресная книга создается на первом сервере домена (организации) при установке сервера и реплицируется с него на другие серверы домена (ср. БД SAM и контроллеры домена Windows NT). С каждым доменом связан свой сертификат организации (файл CERT.ID). Информация из адресной книги полностью задает конфигурацию домена. Каждый сервер домена знает эту конфигура-
195
цию, но не знает конфигурации других доменов. В организации может существовать один или несколько доменов Notes. Сеть Notes Сеть Notes (Notes Named Network) – это поименованная группа серверов Domino/Notes из одного домена, использующих для постоянного взаимодействия один и тот же сетевой протокол (рис. 14). (Правило: серверы из одной поименованной сети могут в любое время напрямую соединяться между собой по этому протоколу.) Данное понятие используется для передачи почты (серверы из одной сети всегда могут обменяться почтой, при этом не используется информация о приоритете и расписании в документах типа Connection).
Рис. 14. Сеть на базе Lotus Notes
Правила для организации сетей Notes: 1) серверы с одним протоколом из одной ЛВС должны иметь одно и то же имя сети (серверы связаны мостами, концентраторами, коммутаторами, но не маршрутизаторами с портами ГВС/WAN);
196
2) серверы с разными сетевыми протоколами не могут принадлежать одной сети; 3) серверы с одним и тем же сетевым протоколом, но расположенные физически в разных ЛВС, должны принадлежать к разным сетям (например, связанные через невыделенную модемную линию, X.25, ISDN и т.п.); 4) серверы с несколькими протоколами должны принадлежать нескольким сетям Notes по одной на каждый протокол. Порт сети – это виртуальный объект, обеспечивающий подключение узла Notes (сервера или рабочей станции) к сети Notes. Количество портов зависит от установленных в ОС сетевых (транспортных) протоколов. Примеры: TCP – при наличии протокола TCP/IP, LAN0 – при наличии поддержки NetBIOS поверх какогонибудь транспортного протокола (например, наличие NetBT, т.е. NetBIOS поверх TCP/IP). 4.2.4. Служба справочника
В составе Lotus Notes есть своя служба справочника для идентификации ресурсов сети на основе Lotus Notes. Начиная с Lotus Notes версии 3.x, все объекты службы справочника Lotus Notes идентифицируются с использованием иерархической системы имен, предусмотренных стандартом X.500 (ср. c NDS). Служба справочника Notes основана на сертификатах и системе шифрования с открытыми ключами. Объекты службы справочника Объектами службы справочника Lotus Notes являются объекты типа Пользователь (User), Сервер (Server) и Заверитель (Certifier). Оконечным узлам дерева имен соответствуют пользователи и серверы. Неоконечным узлам соответствуют заверители, представляющие подразделения организации. Объект типа Пользователь – представляет пользователя пакета в системе. Объект типа Сервер – представляет один узел сети с установленной серверной частью пакета Lotus Notes.
197
Объект типа Заверитель – представляет в системе специальное должностное лицо, имеющее ID-файл заверителя и способное регистрировать новые уровни в дереве имен ниже себя. Также ID-файл заверителя используется при создании, сертификации и ресертификации ID-файлов пользователей и серверов соответствующего уровня в дереве имен. Объекты службы справочника (пользователи и серверы), по умолчанию, получают доступ ко всем серверам своей организации (домена). С каждым объектом службы справочника связан специальный документ в адресной книге (см. раздел «Основные БД для администрирования»), а также ID-файл (см. далее). Идентификация объектов службы справочника Объекты службы справочника идентифицируются с помощью простых и полных имен. Простое имя объекта, например Server1 или John B. Franklin, может использоваться в пределах одного домена Notes (в рамках адресной книги домена). Полное имя объекта складывается из полного имени заверителя (см. далее), создавшего данный объект, и простого имени объекта. Например, John B. Franklin/Austin/Acme Co./US. Полное имя объекта должно быть уникальным в рамках всего дерева имен. Полные имена объектов должны использоваться при междоменном взаимодействии. Полное имя заверителя может складываться из следующих простых имен: 1) имени страны (необязательная составляющая имени), например US. 2) имени организации (домена Notes для организации), например Acme Co. 3) имени организационной единицы (подразделения), например Austin. Всего допускается не более 4 уровней иерархии орагнизационных единиц в именах обектов.
198
ID-файлы ID-файлы используются, прежде всего, для доступа пользователей к ресурсам серверов Notes с рабочих станций и идентифицируют своих владельцев в контактах с серверами. Также используются в процессах шифрования, создания и проверки почты и т.п. При взаимодействии серверов между собой также используются IDфайлы, при этом сервер-инициатор выступает в роли клиента сети Notes. ID-файл пользователя или сервера создается заверителем организации или ее подразделения. Сразу после создания ID-файл включает: – имя владельца файла, – вид лицензии, – тип и номер лицензии, – один иерархический сертификат (и/или несколько простых сертификатов), – открытый ключ, – личный ключ, – пароль. Дополнительно могут создаваться и меняться: – пароль, – сертификаты, – ключи шифрования, – имя владельца, – открытый ключ. Возможно создание безопасной копии ID-файла для ресертификации или взаимной сертификации (см. далее). Эта копия не содержит секретного (личного) ключа владельца и ключей шифрования, поэтому с его помощью невозможно выполнять подключение к серверам сети для получения доступа к ресурсам. ID-файл сервера ID-файл сервера (файл SERVER.ID) не содержит пароля, создается при установке сервера Notes, хранится в каталоге с программными модулями на сервере и используется при запуске сервера, а также при взаимодействии серверов. ID-файл заверителя организации ID-файл заверителя организации (файл CERT.ID) создается в процессе установки первого сервера Notes в организации. Завери-
199
тель (чаще всего администратор) использует этот файл при регистрации (сертификации) новых пользователей и серверов, ресертификации и выпуске взаимных сертификатов, а также для регистрации заверителей подразделений/организационных единиц. Сертификаты Сертификат подтверждает, что данное имя пользователя (сервера) «правильно ассоциировано» с его открытым ключом. Сертификат «подписан» с использованием личного ключа заверителя, выдавшего сертификат. Для проверки «подписи» необходим открытый ключ выдавшего сертификат. Сертификат содержит: – имя и открытый ключ заверителя, выдавшего сертификат, – дату-время выдачи и дату-время окончания срока действия сертификата, – имя и открытый ключ пользователя (сервера), которому выдан сертификат, – вид лицензии Notes. Каждый пользователь для аутентификации на сервере Notes должен предъявить ID-файл, содержащий такой же сертификат, что и ID-файл на сервере. Каждый раз при отправке «подписанной» почты к документу присоединяются сертификаты отправителя из его ID-файла. Это позволяет получателю, имеющему такие же сертификаты, расшифровать и прочитать сообщение. В Lotus Notes используются сертификаты нескольких типов: 1) Простой сертификат – удостоверяет простое имя пользователя (ID-файл содержит сертификаты от разных заверителей). Простые сертификаты позволяют получить доступ к серверам, в IDфайлах которых есть хотя бы один сертификат, указанный в IDфайле пользователя. 2) Иерархический сертификат – удостоверяет иерархическое имя (хотя сам состоит из сертификатов-компонент, сертифицирующих каждый из уровней). 3) Перекрестный сертификат – сертификат, позволяющий объектам одного дерева имен Notes обращаться к серверам другого дерева имен (разные организации/домены). Появляется после выполнения взаимной сертификации. Взаимная сертификация – это двухсторонняя (чаще всего) сертификация, в процессе которой безопасная копия ID-файла объекта Notes (чаще всего сервера) одной орга-
200
низации (организация ORG1) передается в другую сеть Notes (организация ORG2) и заверяется заверителем этой организации. Затем безопасная копия ID-файла второй организации (организация ORG2) передается в сеть Notes первой организации и заверяется заверителем первой организации (организация ORG1). В результате в ID-файлах серверов обеих организаций появляются сертификаты других организаций, владельцам которых разрешен доступ к ресурсам этих серверов. 4.2.5. Основные БД для администрирования
Вся информация, в том числе и служебного характера, хранится в пакете Lotus Notes в виде документов в различных БД. Для работы службы справочника, службы безопасности и других компонентов в состве пакета используются специальные БД. БД «Общая адресная книга» Общая адресная книга (далее «ОАК») хранит документы, представляющие объекты справочника, а также: основные настройки серверов домена Notes; документы, представляющие группы пользователей и серверов и т.д. Эта БД создается при установке первого сервера организации, хранится в виде файла NAMES.NSF, автоматически реплицируется на вновь устанавливаемые серверы домена и служит основной рабочей БД для администрирования сети на базе пакета Lotus Domino/Notes. К числу основных документов адресной книги относятся документы типа: – сервер (Server Document), – соединение (Connection Document), – домен (Domain Document), – пользователь (Person Document), – группа (Group Document), – заверитель (Certifier Document), – перекрестный сертификат (Cross Certificate Document). Документ сервера Документ сервера (Server Document) создается автоматически при регистрации сервера и содержит информацию о сервере домена и его настройках, в частности:
201
1) Имя сервера (поле Server Name). Это имя, по которому другие серверы или пользователи могут идентифицировать сервер при подключении. Это имя используется в сетевом протоколе при установлении связи. Также это имя включается в список управления доступом (ACL) (например, в ACL баз данных других серверов). 2) Имя домена (поле Domain Name). Имя, с которым связана Общая Адресная Книга (Organization’s Name & Address Book). По имени домена осуществляется маршрутизация Notes-почты, а также определяется местонахождение домашнего сервера для пользователя. 3) Конфигурация сети (раздел Network Configuration) – набор имён портов, имён Notes-сетей и сетевых имён сервера. Имена портов должны соответствовать портам, установленным на сервере (меню File|Tools|User preferences, страница Ports). Для каждого порта указывается имя сети и сетевое имя сервера. Каждый порт сопровождается ключом: разрешен или запрещен порт на текущий момент времени. 4) Задания маршрутизации (поле Routing Tasks) – список задач, выполняемых сервером и участвующих в маршрутизации. Такими задачами могут быть маршрутизация почты Notes (Mail Routing), тиражирование баз данных (Replication), а также маршрутизация Internet-почты (SMTP Mail Routing). В поле заданий маршрутизации должны присутствовать все задачи, выполняемые сервером, для того, чтобы при загрузке сервер «знал», какие процессы ему загружать. Более тонкая настройка этих служб производится созданием или редактированием соответствующих документов, в частности документов Соединений (Connection Documents) и документов Домена (Domain Documents) 5) Группы доступа к серверу (поле Access Groups раздела Restrictions) – это список пользователей, серверов и групп, имеющих право доступа к конкретному серверу. Проверка этого права осуществляется после аутентификации и перед открытием списка баз данных, имеющихся на сервере. По умолчанию это поле пусто, т.е. к серверу допущены все. Если занести в это поле какое-либо значение (группу, сервер или пользователя), то доступ к серверу будет дан только тем объектам, которые присутствуют в списке. 6) Администраторы (поле Administrators) – список пользователей, обладающих специальными привилегиями на пользование сервером. Им разрешается запускать удалённую консоль, строить индексы в базах данных, сжимать базы и т .д.
202
В дополнительных разделах данного документа содержатся основные настройки различных задач Notes (помимо информации, содержащейся в специальных настроечных БД), запускаемых на сервере: Agent Manager, Administration Process, Web Retriever, HTTP Server и т.д. Документ соединения Документ соединения (Connection Document) используется для организации репликаций по расписанию и передачи почты между серверами. Этот документ содержит информацию о типе соединения, сервере-источнике и домене-источнике (т.е. домене, в котором находится сервер-источник), сервере назначения и домене назначения. Тип соединения представляет собой способ взаимодействия двух серверов. Это может быть локальная сеть (Local Area Network), либо связь по модему (Dial-Up Modem), либо что-то еще. Тип «локальная сеть» подразумевает, что оба сервера подключены к локальной сети и на них загружен один и тот же транспортный протокол. Поле Use the port(s) указывает, какой сетевой порт будет применяться при использовании соединения на основе данного документа. Здесь же можно указать и дополнительный сетевой адрес сервера на случай, если по основному имени вследствие сетевой ошибки или по иным причинам сервер не идентифицируется (например, при связи типа TCPIP можно указать доменное имя сервера или IPадрес). Также в документе соединения располагается информация о тех заданиях (Tasks), для которых создан этот документ. Если в поле Tasks присутствует значение Mail Routing, тогда в соответствующих полях для маршрутизации почты нужно произвести необходимые настройки (стоимость соединения, какое количество ожидающих передачи сообщений необходимо для установления соединения). Если в этом поле присутствует также значение Replication, то нужно указать, в какие моменты серверы должны выходить на сеанс тиражирования БД (расписание тиражирования), режим репликации, список реплицируемых БД. Документ домена Документ домена (Domain Document) используется для маршрутизации почты в домены, несмежные (Non-adjacent) c текущим (на-
203
пример, когда домен А маршрутизирует почту в домен С через домен В, не имея прямой связи с доменом С, домены А и С – несмежны), либо в домены, чужеродные для Notes (например, Foreign SMTP Domain для домена почты Internet). Более подробно о настройке документов данного типа будет указано при рассмотрении почтовой системы пакета Lotus Notes. Документ пользователя Документ пользователя (Person Document) используется для хранения следующей информации о зарегистрированном пользователе Notes: 1) Имена пользователя. Значения различных строковых полей, используемые по-разному в соответствующих случаях. Например, для подключения к серверу Notes и получения доступа используется Имя Пользователя (Username), для формирования полного имени в поле Reply-To почтового сообщения используется информация из полей Имя (First Name), Отчество (Middle Initial) и Фамилия (Last Name), для преобразования сообщений в формат Internet-почты, получения доступа к серверу по протоколам POP3 и HTTP извлекается Короткое имя (ShortName or Internet address). 2) Домашний сервер (Home Server). Cервер, на котором был зарегистрирован пользователь. Это первый сервер, к которому будет осуществлена попытка подключения при первом входе пользователя в систему Notes. 3) Тип почтовой системы (Mail system). Возможные варианты: Notes (для зарегистрированных пользователей Notes), либо POP3, если пользователь в Notes не регистрируется (точнее регистрируется, но как POP3-пользователь), но получает почту с сервера Notes по протоколу POP3. Также возможны и другие варианты, например когда клиент использует другую, отличную от Notes, почтовую систему. 4) Почтовый Файл (Mail file). В случае использования пользователем почты Notes или POP3 в этом поле должно находиться полное имя файла почтового ящика относительно каталога данных сервера Notes (например, сервер Test/EDU имеет каталогом данных c:\notes\data, а почтовый файл пользователя Guest/EDU находится в каталоге c:\notes\data\mail\guest.nsf. Тогда в поле Mail file документа пользователя Guest/EDU нужно указать mail\guest.nsf).
204
5) Дополнительная информация о пользователе не так важна для работы в Notes и вводится по желанию, либо по требованиям в конкретной организации. 6) Административная информация (Administration) включает данные о пользователе, используемые для разграничения доступа, проверки сервером пароля при аутентификации, периоды длительности использования одного и того же пароля, либо информацию о том, что данный пользователь отключён (LockOut). Также здесь указывается Владелец (Owner) и Администраторы (Аdministrators) данного документа. 7) User ID. После регистрации пользователя в службе справочника пакета с вариантом хранения ID-файла в ОАК, к документу Person прикрепляется файл UserID, содержащий ID-файл данного пользователя. Документ группы Документ группы (Group Document) применяется в тех случаях, когда либо пользователей, либо серверы, либо и тех, и других необходимо объединить с некоторой целью. Такой целью может быть более удобное и упорядоченное распределение прав доступа, рассылка почтовых сообщений сразу нескольким адресатам. Для формирования документа группы нужно при создании нового документа указать: 1) Имя группы (Group Name). Содержит имя группы, которое должно быть уникальным в пределах домена. 2) Тип группы (Group Type). Определяет, для каких целей может быть использована группа. Возможно одно из следующих значений: а) Mail-only – только для почтовых целей (когда нужно организовать группу рассылки). б) Access control list only – группа для включения в ACL, т.е. только для разграничения доступа. в) Deny-list only – группа для запрета доступа (используется, когда определённой группе необходимо запретить доступ). Такую группу можно поместить, например, в документ типа Сервер в поле Deny Access. г) Multi-Purpose – многоцелевая группа. Её следует использовать во всех остальных случаях. Этот тип присваивается группе по умолчанию.
205
3) Список группы (Group Members) – список членов группы, который может включать пользователей и/или серверы. Список группы можно заполнить, обратившись к адресной книге домена. 4) Комментарий (Description) – содержит описание, объясняющее назначение группы. Документ заверителя Документ заверителя (Certifier Document) является важным документом для выполнения процедуры аутентификации объектов Notes в системе. Он содержит имя заверителя, имя заверяемого и публичный заверенный ключ организации. Этот публичный ключ является как бы печатью заверителя, которой он будет заверять регистрируемых пользователей, серверы или дочерние организационные единицы. Другими словами, этот ключ оставит «оттиск» на ID-файлах создаваемых объектов. Заверяемым здесь может быть только какой-либо другой заверитель в иерархии. В частности, при инсталляции первого сервера в организации создаётся «корневой» заверитель, который может впоследствии порождать дочерние уровни заверителей, соответствующих, например, подразделениям в организации. Документ заверителя никогда не создаётся вручную из меню Create. Он создаётся автоматически в процессе регистрации нового подразделения/организационной единицы (Organization Unit). Документ перекрестного сертификата Документ перекрестного сертификата (Cross Certificate Document) – это документ для аутентификации объектов одного дерева имен Notes на узлах сети Notes другого дерева имен. Он содержит имя заверителя, имя заверяемого и публичный заверенный ключ другой организации. Заверителем может быть пользователь, сервер или его предок в дереве имен Notes, который заверяет пользователя, сервер или предка в дереве имен Notes другой организации. Документ заверителя никогда не создаётся вручную из меню Create, он создаётся автоматически в процессе перекрестной сертификации, либо при первом открытии БД, подписанной открытым ключом заверителя другой организации. Обычно создается пара документов данного типа – по одному на каждую организацию или подразделение, которые участвуют во взаимной сертификации.
206
БД «Журнал работы» БД «Журнал работы» хранится в файле LOG.NSF на узле сети Notes: сервере или рабочей станции. Эта БД создается автоматически при установке узла сети Notes. В нее автоматически записывается информация о событиях, происходящих при работе сервера/рабочей станции, а именно информация: – о состоявшихся сеансах работы; – выполненных репликациях и переданной почте; – «удаленных» соединениях; – исходящих и входящих телефонных звонках. БД «Каталог» БД «Каталог» хранится в файле CATALOG.NSF на одном или более серверах и содержит информацию о БД, для которых выбрана опция List in Database Catalog. БД создается автоматически при первом запуске задачи CATALOG на сервере. В зависимости от содержимого ACL, в этой БД отображается информация только о базах одного сервера, либо о базах серверов домена и т.п. Чтобы в БД «Каталог» присутствовала информация с нескольких серверов, необходимо создать реплику этой БД на соответствующих серверах и предоставить право менеджера к этой БД соответствующих серверов (обычно LocalDomainServers), а Default – право читателя. БД «Протокол сертификации» БД «Протокол сертификации» хранится в файле CERTLOG.NSF на серверах Notes и содержит информацию о зарегистрированных в службе справочника объектах: пользователях, серверах и заверителях. Эту БД необходимо создать вручную по шаблону CERTLOG.NTF на первом сервере Domino/Notes организации и обеспечить репликацию на все серверы домена. Документы в этой БД создаются автоматически при сертификации новых объектов (в процессе первичной регистрации или ресертификации). В ACL БД необходимо включить группу LocalDomainServers с правом менеджера, заверителей подразделений с правом автора и Default с запретом на доступ.
207
4.2.6. Система безопасности
Система безопасности пакета Lotus Notes является децентрализованной, ее элементы распределены по узлам сети Notes, а также различным компонентам пакета Lotus Notes. Она формировалась от версии к версии и последовательно расширялась для обеспечения большей гибкости в назначении прав доступа и обеспечении большего контроля за ресурсами. Основные элементы системы безопасности: – механизм сертификации зарегистрированных объектов в составе службы справочника; – процедура аутентификации с использованием сертификатов при доступе клиентов к серверу; – проверка полномочий доступа с помощью списка управления доступом (ACL) при попытках доступа к БД на узлах сети Notes; – ограничение доступа к локальным ресурсам рабочей станции программным агентам с помощью списка управления запуском (EСL); – механизм шифрования информации открытым ключом (алгоритм RSA) и закрытым (RC2) ключом; – механизм электронной подписи отправляемых почтовых сообщений (дайджест сообщения MD2). Обеспечение безопасности сервера Notes и его ресурсов При обращении пользователя или сервера Notes к ресурсам сервера Notes контроль доступа к этим ресурсам осуществляет подсистема безопасности пакета Lotus Notes. Любой запрос от пользователя или сервера последовательно проходит несколько «дверей», к которым у субъекта должен быть соответствующий уровень доступа, определенный администратором пакета. И только после успешного прохождения всех «дверей» субъект может получить запрошенный уровень доступа. Рассмотрим эти «двери» последовательно. Дверь 1: Доступ на уровне сервера Включает последовательное прохождение: – Процедуры аутентификации. Выполняется путем сравнения сертификатов, имеющихся в ID-файлах клиента и сервера Domino/Notes, подробно см. далее.
208
– Процедуры сравнения открытого ключа, предоставляемого при подключении к серверу со значением, хранящимся в ОАК, – при включенной опции «Compare public keys against those stored in Address Book» в разделе Security документа Server. – Процедуры сравнения пароля, хранящегося в АК и в ID-файле пользователя, с помощью которого осуществляется доступ – при включенной опции «Check passwords» в разделе Security документа Server. – Процедуры проверки списка доступа и списка запрета на доступ к серверу. Если поле Access server в разделе Restrictions документа Server пусто и в поле Not access server нет имени пользователя или группы, которой он принадлежит, доступ предоставляется; если поле Access server не пусто, делается проверка, указан ли пользователь или группа, которой принадлежит пользователь, в этом списке. Дверь 2: Доступ на уровне БД Включает последовательное прохождение: – Процедуры проверки списка доступа ссылки на БД/каталог БД (Link to DB/Catalog) – если клиент обращается к БД, расположенной по ссылке, то доступ предоставляется только в случае присутствия имени клиента (либо группы, в которую он входит) в списке разрешенных лиц (задается при создании ссылки). – Процедуры проверки списка управления доступа к БД и соответствия указанных в списке прав и запрашиваемых прав – при попытке доступа клиента к конкретной БД сравнивается запрашиваемый уровень доступа и содержимое ACL БД; при доступе через Web учитывается также значение опции «Maximum internet browser access». Дверь 3: Доступ на уровне форм и видов Доступ к форме и документам, созданным на основе формы, а также хранящейся в документах информации может быть ограничен: – свойствами Who can create document и Available for Public Access формы; – свойством формы или субформы; – обработчиком события QueryOpen формы; – свойствами May be used by и Available for Public Access представления;
209
– формулой отбора документов представления и формулой для отображения скрытых столбцов представления. Доступ контролируется либо явным назначением доступа конкретным субъектам, либо с помощью ролей. Дверь 4: Доступ на уровне документа Доступ к документу может быть ограничен: – на чтение – полями типа Readers документа; – на редактирование – полями типа Authors документа; – обработчиком события QueryOpen и QueryModeChange формы. Доступ контролируется либо явным назначением доступа конкретным субъектам, либо с помощью ролей. Дверь 5: Доступ на уровне полей документа Доступ к полям документа может быть ограничен: – шифрованием полей с использованием открытых и личных ключей; – указанием свойства User must have at least Editor access to update. Доступ контролируется либо явным назначением доступа конкретным субъектам, либо с помощью ролей. Дополнительно, доступ к ресурсам сервера и БД, хранящимся на сервере, можно ограничить: – установкой пароля на консоли сервера (SET SECURE); – специализированными настройками в файле notes.ini; – запретом на репликацию БД; – сбросом флага «Отображать БД в диалоговом окне Open database»; – установкой флага «Hide formulas and LotusScript». Аутентификация клиента в пакете Notes Процесс аутентификации, который имеет место при подключении клиента к серверу для выполнения репликации, маршрутизации почты или осуществления доступа к БД, включает: 1. Установление сервером доверия к открытому ключу клиента (пользователя или другого сервера). При этом: – имя и публичный ключ, содержащийся в ID-файле клиента, посылаются на сервер;
210
– далее, по запросу сервера посылается список сертификатов (в зашифрованном виде), которые будут использоваться для подтверждения ассоциации между именем клиента и публичным ключом (общий сертификат для клиента и для сервера, либо присутствует взаимный сертификат); – для подтверждения (расшифровки) каждого сертификата используется открытый ключ заверителя, который берется из сертификата в ID-файле сервера. 2. Проверка, знает ли клиент свой личный ключ. Для этого: – сервер генерирует случайное число и посылает его клиенту, тот шифрует его личным ключом и возвращает серверу; – сервер использует открытый ключ клиента (из ОАК) для декодирования числа. Если декодированное число совпадает с оригиналом, то клиент знает свой личный ключ (т.е. клиент подлинный). 3. Установление клиентом доверия к открытому ключу сервера. Выполняется зеркально пункту 1. 4. Проверка, знает ли сервер свой личный ключ. Выполняется зеркально пункту 2. Списки управления доступом Основную нагрузку по управлению доступом к информации на сервере несут списки управления доступом (далее «ACL») баз данных. ACL БД определяет, какие объекты службы справочника Domino/Notes имеют права доступа к этой БД и каковы эти права. ACL включает: Список элементов управления доступом (ACE), каждый из которых содержит имя субъекта, его уровень доступа к базе и дополнительные свойства. (!)
В ACL могут присутствовать элементы, содержащие не зарегистрированные в службе справочника объекты: –Default– (для назначения доступа по умолчанию), Anonymous (для назначения анонимного доступа через Internet), а также имена групп, определенных в ОАК с помощью документов типа Группа.
Список ролей вместе с назначением субъектов на роли
211
ACL ведется менеджером БД в диалоговом окне, получаемом из меню File->Database->Access control. Доступ к списку ACE для назначения субъекту (пользователю или группе) определенного уровня доступа, а также для назначения субъекту ролей доступа, можно получить с закладки Basics диалогового окна Access control БД. Доступ к списку ролей для редактирования этого списка можно получить с закладки Roles диалогового окна Access control БД. При управлении доступом к БД можно указать также (закладка Advanced): Административный сервер для данной БД. Сервер, через который будет происходить автоматическое внесение изменений в ACL БД (задачей Administration Process); Опцию «Enforce a consistent ACL across all replicas of this database» – использовать или нет единый список ACL для всех реплик БД. Опцию «Maximum Internet browser access» – предельный уровень доступа к БД через Internet. Действительные права При проверке прав доступа субъекта к БД действуют следующие правила: Если субъекту предоставлены права на БД явно, а также через группу(ы), то при проверке прав доступа используется только элемент ACL, явно описывающий права субъекта. Если субъекту права доступа не предоставлены явно либо через членство в группе, то на него распространяются права, предоставленные через –Default–, а также через Anonymous (при доступе через Web). Если субъекту предоставлены права через членство в нескольких группах с разным уровнем прав, его фактическими правами будут права группы с большим уровнем прав. Определить действительный уровень доступа к БД можно по пиктограмме уровня доступа в строке состояния в нижней части окна рабочей области. Нажав на эту пиктограмму, можно узнать, чем именно (каким субъектом или ролью в ACL) определился уровень доступа. Однако такая возможность работает только для БД, для которых выбрана опция «Enforce a consistent ACL across all replicas of this database».
212
Уровни доступа Уровни доступа (по возрастанию полномочий) к БД, которые можно назначить, используя ACL: No access – пользователь не может открыть БД; Depositor – пользователь может добавлять новые документы, но не может читать и редактировать существующие; Reader – пользователь может читать документы, но не может добавлять новые или редактировать существующие; Author – пользователь может читать существующие документы и создавать новые, но может редактировать и удалять только созданные им документы; Editor – пользователь может создавать, читать, редактировать и удалять любые документы в БД (в том числе и созданные другими); Designer – пользователь имеет права Editor, а также может создавать, редактировать и удалять элементы дизайна (поля, формы, представления, общих агентов), модифицировать репликационные формулы, создавать индекс полнотекстового поиска; Manager – пользователь имеет права Designer, а также может изменять ACL, настройки локального шифрования и удалять саму БД. Флаги управления доступом Кроме того, для каждого уровня можно индивидуально указать те или иные права доступа с помощью соответствующих флагов (в зависимости от уровня доступа некоторые флаги могут быть заблокированы на изменение). Ниже приведен список всех прав доступа, которые можно контролировать с помощью флагов: Create documents – дает право создавать документы в БД; Delete documents – дает право удалять документы из БД; Create personal agents – дает право создания личных агентов; Create personal folders/views – дает право создания личных папок и представлений; Create shared folders/views – дает право создания общих папок и представлений; Create LotusScript Agents – дает право создания агентов на LotusScript; Read public documents – дает право чтения общих документов; Write public documents – дает право изменять общие документы.
213
Рассмотрим пример влияния указанных флагов на уровень доступа. Пусть менеджер разрешил пользователю с уровнем доступа Reader создавать личных агентов. Этот пользователь может создать агента, который удаляет все документы в БД, он может даже его запустить. Но свое разрушительное действие агент выполнить не сможет, так как у пользователя нет права на удаление документов в БД (флаг Delete documents для Reader сброшен, и его изменить нельзя, не поменяв уровня доступа). Роли доступа Роли доступа используются для управления доступом пользователей или групп к определенным формам, представлениям или агентам в рамках одной БД. Список возможных ролей доступа должен подготовить разработчик (дизайнер) БД (на время разработки этому пользователю предоставляется уровень доступа Manager). Название роли ограничено 15 однобайтовыми символами. Пример списка ролей для БД «Общая адресная книга»: [GroupCreator], [GroupModifier], [NetCreator], [NetModifier], [ServerCreator], [ServerModifier], [UserCreator], [UserModifier]. После определения списка ролей (на основе изучения предметной области решаемой задачи) дизайнер использует названия ролей в подпрограммах на LotusScript (в проверках, назначен ли пользователь на определенную роль, по результату которой принимается решение выполнять или нет действие агента), а также в защищаемых разделах и полях формы, скрытых полях представлений и т.д. Использование ролей позволяет гибко управлять доступом к элементам и информации, хранящейся в БД. Обеспечение безопасности рабочей станции Система безопасности Lotus Notes обеспечивает не только защиту серверах Notes. Системой безопасности otus Notes поддерживаются механизмы для защиты локальных ресурсов рабочих станций Notes. Локальное шифрование БД Такое мощное средство пакета Lotus Notes, как репликация, в руках злоумышленника может принести большой вред. Дело в том, что после создания реплики БД на рабочей станции ACL БД перестает действовать. По этой причине может потребоваться выпол-
214
нение локального шифрования БД. Локальное шифрование выполняется менеджером БД или любым пользователем с использованием случайного сгенерированного пакетом ключа, а сам ключ шифруется открытым ключом, хранящимся в ID-файле. Доступ к функции локального шифрования обеспечивается через закладку Basics диалогового окна свойств БД. Список управления выполнением При использовании любой почтовой системы имеется риск получить присоединенный файл, содержащий выполняемую программу или интерпретируемый сценарий. Выполнение такого присоединенного файла может привести к заражению компьютера вирусами и причинению прямого ущерба. Похожая проблема может возникнуть при открытии БД, находящейся на удаленном сервере (например, не «своего» домена). Для ограничения доступа выполняемых под управлением Notes сценариев и программ в пакете Notes (с версии 4.5) используется список управления выполнением (Execution Control List / ECL). Окно для настройки списка управления выполнением может быть получено в меню File-Tools-User Preferences (Файл-Сервис-Параметры) c закладки Basics (Общие) нажатием кнопки Security Options (Параметры защиты). В левой части окна в поле When signed by («Наличие подписи») присутствует список субъектов, кем может быть «подписан» элемент дизайна или документ БД. В этот список можно включать любые объекты службы справочника Domino/Notes, а также шаблоны, например */EDU. Кроме того, в этом списке присутствуют элементы: Default – для задания степени свободы действия выполняемых программ, подписанных субъектом, не присутствующим в списке; No signature – для задания степени свободы действий выполняемых программ, которые вообще не подписаны. В правой части окна в поле Allow («Открывает») для каждого элемента из списка ECL перечисляются возможности, разрешенные (помечены флажком) и запрещенные (флажок сброшен) для сценариев и @-формул. Список возможных действий: Access to the file system – возможность присоединять и отсоединять файлы, возможность читать и записывать файлы в каталогах локального диска рабочей станции;
215
Access to current database – возможность читать и модифицировать содержимое текущей БД; Access to environment variables – возможность читать и модифицировать значения переменных из файла Notes.ini; Access to non-Notes databases – возможность читать и модифицировать информацию из БД не-Notes формата; Access to external code – возможность вызывать функции из DLL, не входящих в состав пакета Notes; Access to external programs – возможность запуска и работы с другими приложениями, включая активизацию любых OLEобъектов; Ability to send mail – способность отправлять почту; Ability to read other databases – способность читать информацию из БД Notes, отличных от текущей; Ability to modify other databases – способность изменять информацию в БД Notes, отличных от текущей; Ability to export data – способность выводить на принтер, копировать в буфер обмена, экспортировать и импортировать данные; Access to workstation security ECL – возможность изменять список управления выполнением станции. В общем случае управление ECL возлагается на пользователя рабочей станции. Однако есть возможность сформировать ECL централизованно и запретить пользователям менять ECL. Для этого после открытия ОАК администратор выбирает Action-Edit Administration ECL. В диалоговом окне ECL формируется аналогично случаю запуска с конкретной рабочей станции. Сбросом флага «Allow user to modify» устанавливается запрет на редактирование ECL пользователями с рабочих станций. ECL будет автоматически перенесен на рабочую станцию пользователя после установки клиентской части пакета Notes. Подписывание всей БД целиком или ее элементов осуществляется с рабочей станции в режиме Server Administration запуском утилиты подписывания БД (кнопка Database Tools – Sign a Database). БД и ее элементы подписываются открытым ключом из текущего ID-файла. Возможно подписывание только локально расположенных БД.
216
4.2.7. Репликация в Lotus Notes
Репликация в Lotus Notes – это процесс обмена изменениями в двух и более БД для поддержания согласованности данных. Репликация выполняется для резервирования данных, хранящихся в БД, а также для равномерного распределения нагрузки на серверы и каналы связи. Первая репликация БД заключается в создании на локальном диске сервера/рабочей станции реплики БД, находящейся на другом сервере или рабочей станции. Выборочная (условная) репликация – это репликация, которая охватывает не все документы БД, а только те, которые соответствуют условию репликации (например, все созданные позднее указанной даты). Выборочные репликации могут настраиваться индивидуально между каждой парой узлов сети Notes. Реплика БД – частичная или полная копия БД, созданная процессом Replicator и имеющая тот же идентификатор реплики БД, что и у оригинальной БД. В случайный момент времени содержимое реплик не обязательно должно быть идентичным. Совокупность расположенных на разных узлах сети Notes (серверах и рабочих станциях) реплик одной и той же БД называется распределенной БД Notes. В процессе репликации участвуют два процесса – задача Replicator (загружается командой LOAD REPLICA или автоматически) на стороне инициирующего репликацию сервера и задача Database Server на стороне удаленного сервера. Одна запущенная задача Replicator всегда взаимодействует только с одним сервером, тогда как задача Database Server запускается по одной на каждый удаленный сервер. Количество задач Replicator, запускаемых одновременно, задается переменной Replicators в файле инициализации NOTES.INI . Репликация выполняется вручную (команды Replicate, Pull, Push) или по расписанию, указанному в документе Connection. Схемы репликации В пакете Lotus Notes версии 4.х и выше используется 4 типа (схемы) репликаций:
217
Pull Only – сервер, инициирующий репликацию, забирает с другого сервера изменения, произошедшие в удаленных репликах БД. Push Only – cервер, инициирующий репликацию, копирует на другой сервер изменения, произошедшие в локальных репликах БД. Pull-Pull – сервер, инициирующий репликацию, забирает с другого сервера изменения, произошедшие в удаленных репликах БД, а затем то же самое выполняет удаленный сервер (забирает изменения). То есть после выполнения первой части процесса репликации (получены изменения из удаленных реплик) инициируется задача Replicator на удаленном сервере, который, в свою очередь, получает все обновления с вызвавшего его сервера (задействуя при этом задачу Database Server). Pull-Push – сервер, инициирующий репликацию, забирает с другого сервера изменения, произошедшие в удаленных репликах БД, а затем копирует на удаленный сервер изменения, сделанные в локальных репликах БД. Если используется схема Pull-Push, то процесс настройки репликации выполняется на удаленных серверах (в их АК) и репликации инициируются с этих удаленных серверов. При этом центральный сервер называется издателем (hub-сервер), а удаленный сервер (инициатор репликции) – подписчиком (spokeсервер). (!)
Репликация между сервером и рабочей станцией всегда выполняется по схеме Pull-Push и инициируется рабочей станцией, хотя на ней нет явного процесса Replicator. Сравнение схем репликации
Схема PullPush
Достоинства Сервер-издатель может одновременно обслуживать несколько удаленных узлов – инициаторов репликаций.
218
Недостатки Журнал работы сервера-издателя не будет содержать информацию о событиях репликации. Сложно составить равномерное (согласован-
PullPull
Репликация настраивается и инициируется на сервереиздателе, поэтому в его журнале будет информация о сеансах репликации. Так как управление репликацией централизовано, можно составить равномерное расписание.
ное) расписание репликаций (если серверы используют разные ОАК или узлыподписчики являются рабочими станциями). Схема является менее гибкой и требует обязательной доступности серверов-подписчиков.
Права доступа для выполнения репликации Для выполнения репликации необходимо наличие права создавать реплики БД на сервере (для репликации на сервер), а также права создавать реплики БД сервера (для репликации на сервер и на рабочую станцию). Список объектов, имеющих соответствующие права, указывается в разделе Restrictions документа типа Server. Дополнительно, чтобы создать реплику БД, необходимо иметь права доступа не ниже Reader к соответствующим БД, расположенным на сервере. Рассмотрим вариант репликации БД test.nsf между серверами A и B. Если сервер А является издателем информации, а B – подписчиком, то в ACL БД test.nsf на сервере A необходимо указать права Designer для A и права Reader для B. Если информация обновляется в обеих репликах (как на A, так и на B), то для серверов A и B необходимо указать права не ниже Designer. Версии документов Каждый документ LN имеет уникальный идентификатор документа (как и БД), который содержит:
219
Document Unique ID. Если документы из разных реплик одной БД имеют один и тот же Doc UID, то они называются версиями одного документа. При удалении документа создается так называемая заглушка (Stub) с тем же Doc UID, что и исходный документ. Document Version ID. Является идентификатором версии документа. Состоит из: SD – дата последней модификации; SN (SeqNum) – последовательный номер; DB – ID базы, где был создан документ; NT – ID местоположения документа в этой БД. При каждом сохранении документа его SN увеличивается на 1, а также обновляется его SD. Дополнительно, каждое поле документа (с версии 4.x) имеет свойство SeqNum, которое в точности равно SN документа, если это поле изменилось при редактировании документа (используется при выборочной репликации). Алгоритм репликации Репликация выполняется в несколько этапов: Установление соединения с сервером – в соответствии с расписанием или по команде с консоли инициирующий репликацию сервер соединяется с вызываемым сервером. Выполняется процедура аутентификации серверов и, возможно, дополнительные проверки для обеспечения безопасности. 1. Построение списка реплицируемых БД (по идентификатору реплики) – сравниваются списки БД у себя и на другом сервере, затем исключаются все, неуказанные в документе Connection. 2. Для каждой реплицируемой БД выполняется: – проверка, не запрещена ли операция репликации для данной реплики БД, – проверка, достаточно ли прав для открытия БД на удаленном сервере, – репликация ACL, если нет запрета, – репликация элементов дизайна, если нет запрета (сброшены опции репликации форм, представлений и агентов) и достаточно прав на доступ к удаленной реплике (права Designer и выше). Эле-
220
менты дизайна хранятся как скрытые документы и реплицируются аналогично документам (см. ниже), – репликация документов, – проверка, достаточно ли прав на доступ к удаленной реплике (права Editor и выше), – создается представление с документами, участвующими в репликации (по формуле репликации), при этом в представление не включаются документы с датой и временем модификации ранее даты и времени из поля Cutoff-Date/Only replicate documents saved or modified after (в настройках репликации), – на основе UNID и VeID (SN у измененной версии документа на 1 больше) определяются обновленные и удаленные версии документов в вызванной реплике и копируются в свою реплику (с затиранием устаревших версий документов), – документы с уникальным UNID (вновь созданные) добавляются в локальную реплику БД, (!) При копировании учитывается свойство SeqNum полей документов и, не изменившиеся с момента последней репликации, поля не передаются. – обновление записи в истории репликаций, При репликации учитывается история репликации, и доку(!) менты, созданные или измененные ранее даты последней репликации, не включаются в список для репликации. 3. Завершение репликационной сессии. Зависит от схемы репликации, например если используется репликация по схеме Pull-Pull, то при завершении сессии инициируется выполнение задачи Replicator на удаленном сервере. Создание реплик и настройка репликаций Для создания реплики БД необходимо, предварительно выбрав БД в рабочем пространстве, выполнить команду File-ReplicationNew Replica. Чтобы выполнить репликацию между существующими репликами БД, необходимо использовать закладку Replicator. Процесс выполнения репликаций настраивается выполнением команды File-Replication-Settings. При настройке можно задать следующие параметры:
221
– автоматическое удаление заглушек для давно не обновлявшихся документов; – критерий выбора документов для репликации (по формуле); – запрет на распространение удаленных документов на все реплики БД; – запрет на распространение изменений в ACL; – полный запрет репликации. Для осуществления автоматической репликации между двумя узлами сети Notes необходимо создать и должным образом настроить документ типа Connection (репликация сервер-сервер) или Location (репликация рабочая станция / сервер). После создания документа на рабочем листе с закладкой Replicator появятся строки, отражающие все БД, которые настроены для репликации. При настройке документа Connection/Location можно указать: – приоритет репликации (High, Medium, Low); – список БД, участвующих в репликации; – расписание репликации (время репликации и периодичность). Репликационные конфликты и их устранение Изменение документа сразу в двух и более репликах влечет за собой ситуацию, называемую репликационным конфликтом (не ясно, какую версию документа считать «допустимой»). В этом случае задача-репликатор считает самой свежей версией документ с максимальным SN и SD. Старая версия документа не затирается, а сохраняется с именем [Replication or Save conflict]. Для автоматического разрешения конфликтных ситуаций можно использовать опцию «Merge replication conflicts». При этом если возник конфликт версий, но изменены разные поля у документа, система при репликации создаст один документ вместо двух, где отразит внесенные изменения в разных версиях документа. Также, используя свойство Versioning формы, можно управлять поведением системы при обнаружении изменений сразу нескольких версий документа на основе данной формы (какую версию считать основной; сохранять документ, породивший репликационный конфликт, как ответ на доку-
222
мент). Дальнейшая судьба конфликтных версий документов определяется менеджером БД, в которой возник конфликт. 4.2.8. Электронная почта Lotus Notes
Электронная почта Lotus Notes – это встроенная в пакет Lotus Notes подсистема электронной почты. Особенность электронной почты Notes состоит в том, что работа с почтовым ящиком не отличается от работы с любой другой БД Notes. Каждый пользователь может иметь на сервере Notes свой почтовый ящик, который представляет собой стандартную БД Notes с документами, являющимися почтовыми сообщениями. Почтовое сообщение Notes – документ Notes, передаваемый почтовой системой Notes. Основные компоненты Почтовая система Notes включает следующие составные части (рис. 15): Mailer – выполняется на рабочей станции Notes и осуществляет поиск имен адресатов, помещает адреса в почтовую форму, отправляет почту на почтовый сервер (в БД MAIL.BOX). Router – отдельная задача на сервере Notes, которая создается при запуске программы Xrouter.exe (вместо «X» должна быть буква, обозначающая платформу, например, «nrouter.exe» – для Windows NT) и отвечает за доставку сообщений (в том числе и маршрутизацию). Для каждого сетевого порта сервера создается один и более подпроцессов (нитей), отвечающих за доставку почты. Механизм маршрутизации почты настраивается документами типа Connection и Domain (см. далее). Служба распознавания имен – отвечает за взаимодействие с АК, работает на сервере, а также на рабочей станции (при включенном режиме поиска полного имени адресата по сокращенному). Почтовые агенты (MTAs) – работают на серверах и служат для передачи почтовых сообщений между Notes и не-Notes почтовыми системами (cc:Mail, SMTP). Настраиваются специальными документами типа Connection и Domain (подтип SMTP Connection, Global Domain, Foreign SMTP Domain и т.п.). Кроме того, к почтовой системе можно отнести также и почтовые ящики пользователей, которые хранятся на почтовом сервере Notes в БД на основе шаблона Mail (Почта), а также специализированные БД для временного хранения сообщений.
223
В почтовых ящиках пользователи создают сообщения, выполняют отправку этих сообщений адресатам, читают приходящие сообщения. В специализированных БД (для почты Notes это БД MAIL.BOX) хранятся сообщения, предназначенные для отправки на другие почтовые серверы, а также для доставки в почтовые ящики пользователей на данном сервере. БД MAIL.BOX Служит для временного хранения почтовых сообщений. Создается автоматически на почтовом сервере при первом запуске задачи Router. Также автоматически создается на рабочей станции при выборе режима хранения почтового ящика пользователя «локально» (Local) в документе типа Location. БД MAIL.BOX на рабочей станции используется только в режиме хранения «локально». Именно в эту БД задача Mailer помещает сообщения, предназначенные для отправки. В режиме хранения почтового ящика «на сервере» (On Server) отправляемые пользователем сообщения записываются в БД MAIL.BOX на почтовом сервере. Кроме того, в БД MAIL.BOX сервера сообщения могут помещать задачи Router других почтовых серверов (при доставке почты). БД MAIL.BOX обслуживается задачей Router сервера.
224
Рис. 15. Общая схема взаимодействия компонентов почтовой системы
Маршрутизация почты Под маршрутизацией почты понимается процесс передачи поч тового сообщения на почтовый сервер получателя (возможно, через промежуточные почтовые серверы) для дальнейшей доставки сообщения в почтовый ящик получателя (рис. 16). Маршрутизация почты возможна только при правильной настройке маршрутной информации.
Рис. 16. Схема почтовой сети на основе пакета Lotus Notes
225
Маршрутная информация описывается документами типа Connection и Domain. Документ типа Connection позволяет описать один участок между двумя почтовыми серверами в маршруте до почтового сервера получателя и расписание для использования этого участка, а документ типа Domain – задать ограничения на использование домена для транзита почтовых сообщений. При настройке информации для маршрутизации почты используются следующие правила: Если два сервера принадлежат одной сети Notes (и следовательно одному домену), то документ типа Connection не требуется (доставка почты возможна в любой момент времени). В противном случае требуется два документа – для настройки канала доставки «туда» и канала доставки «обратно» (доставка почты осуществляется по расписанию, указанному в созданных документах типа Connection). Если два сервера принадлежат разным доменам, то также требуются два документа типа Connection. Для успешной доставки почтовых сообщений в сети серверов Notes, изображенной на рис. 16, потребуется 8 документов типа Connection: 6 для связи серверов внутри домена – два для С2-С4, два для С4-С8 и два для С3-С7; а также два для связи серверов С1А1 из разных доменов (один документ в адресной книге Домен 1 и один – в адресной книге Домен 2). При этом сообщение с сервера A2 для получателя на сервере С6 может быть доставлено по двум маршрутам: A2-A1-C1-C3-C7-C8C4-C6 или A2-A1-C1-C2-C4-C6. Скорее всего, доставка по второму маршруту будет выполняться быстрее, если только участок C2-C4 не является низкоскоростным (например, модемной линией).
226
Алгоритм маршрутизации Алгоритм работы задачи Router состоит из двух циклов – цикла доставки новых сообщений, и цикла доставки ранее не отправленных сообщений. Цикл доставки новых сообщений: При изменении даты модификации файла MAIL.BOX задача Router открывает БД MAIL.BOX для выявления новых сообщений. При обнаружении нового сообщения выполняется проверка: принадлежит адрес получателя сообщения текущему домену (домен сервера) или нет. А) Если адрес принадлежит текущему домену, то выполняется поиск имени почтового сервера и имени файла почтового ящика получателя в адресной книге. А1) Если почтовый сервер получателя – текущий сервер, то выполняется доставка сообщения (документ переписывается из MAIL.BOX в почтовый ящик получателя). А2) Если почтовый сервер получателя – другой сервер, то определяется маршрут наименьшей стоимости от текущего сервера до почтового сервера получателя (с использованием документов Connection адресной книги домена), затем выполняется передача сообщения с текущего сервера в MAIL.BOX на следующий сервер в маршруте. Б) Если адрес принадлежит другому домену, то определяется маршрут наименьшей стоимости от текущего сервера до любого доступного сервера в домене получателя (с использованием документов Connection и Domain адресной книги текущего домена), затем выполняется передача сообщения с текущего сервера в MAIL.BOX на следующий сервер в маршруте. Выполняется временная задержка (около 1 мин), затем выполняется повтор с шага 1. Цикл доставки ранее не отправленных сообщений: Задача Router открывает БД MAIL.BOX и выполняет поиск не доставленных сообщений. Выполняется попытка осуществить повторную доставку по алгоритму цикла доставки новых сообщений Выполняется временная задержка (10–30 мин), затем выполняется повтор с шага 1.
227
SMTP MTA SMTP MTA – это агент передачи почты по протоколу SMTP (стандарт для передачи почтовых сообщений в сети Internet). Агент для работы с SMTP-почтой позволяет пользователям Lotus Notes принимать и отправлять сообщения, используя протокол SMTP. SMTP MTA состоит из следующих компонент: Контроллер подзадач SMTPMTA – задача, загружаемая на сервере Notes. Этот контроллер запускает и контролирует выполнение других подзадач агента. Подзадачи: Конвертор исходящих сообщений (Outbound Msg Convertor, OMSGCNV) – преобразует сообщения Notes в формат SMTP/MIME; Контроллер исходящих сессий (Outbound Session Controller, OSESCTL) – управляет процессами передачи преобразованных сообщений по соответствующим SMTP-адресам. Он запускает очередной процесс и сообщает первому свободному из драйверов исходящих сессий, чтобы тот выполнил передачу одного или нескольких сообщений конкретному адресату; Драйвер исходящих сессий (Outbound Session Handler, OSESHLRn) – выполняет непосредственное соединение с почтовым сервером адресата и доставляет сообщение; Контроллер входящих сессий (Inbound Session Controller, ISESCTL) – управляет получением сообщений от других SMTPсистем. Он ожидает запроса на соединение по 25 порту TCP, а затем передает соединение первому свободному драйверу входящих сессий; Драйвер входящих сессий (Inbound Session Handler, ISESHLRn) – принимает сообщение и записывает его в очередь; Конвертор входящих сообщений (Inbound Msg Convertor, IMSGCNV) – преобразует сообщения, полученные драйверами входящих сессий, в формат Notes. Если сообщение предназначено не для Notes (транзитное), то оно помещается в очередь на отправку; Задача оповещения о доставке (Delivery Report Task, DRT) – обрабатывает сообщения в очередях в зависимости от их состояния (успешно посланные удаляются, при ошибке постороннего характера формируется отчет о недоставке).
228
Базы документов, использующиеся при работе SMTP MTA: SMTP.BOX – создается во время установки SMTP MTA (после первого запуска) по шаблону SMTPBOX.NTF и хранит сообщения для передачи; SMTPOBWQ.NSF – используется для временного хранения сообщений, находящихся в выходящей очереди; SMTPIBWQ.NSF – используется для временного хранения сообщений, находящихся во входящей очереди; MTATABLES.NSF – БД с таблицами для преобразования MIMEсообщений. Настройка SMTP MTA Для обеспечения работы SMTP MTA по отправке SMTPсообщений (MAIL.BOX->SMTP.BOX->Internet): Создать документ Connection c подтипом SMTP Connection. Этот документ позволяет SMTP MTA агенту устанавливать соединение с некоторым виртуальным доменом, понимающим SMTP, и передавать ему почту, например «CSDForeign». Другими словами, это модифицированный документ для маршрутизации почты. Необходимо заполнить следующие поля: Source Server – имя Notes-сервера c SMTP MTA для данного Notes-домена, например, «Главный/ФИнф/ТГУ/Томск»; Connect Via – способ связи SMTP MTA с внешним SMTPсервером, например «Direct Connection»; Destination Server – имя SMTP-хоста (точнее, название некоторого DNS-домена, для которого есть Mail eXchanger), с которым можно установить связь, используя этот документ, например «inf.tsu.ru». Если этот документ будет использоваться для связи со всеми возможными SMTP-хостами, указать «AllInternetHosts»; Destination Domain – имя виртуального домена, на который будет ссылаться документ Foreign SMTP Domain, например «CSDForeign». Relay Host – DNS-имя или IP-адрес SMTP-хоста, который будет выступать посредником при отправке SMTP-сообщений, например «212.192.100.1». Поля, относящиеся к расписанию работы SMTP MTA с удаленными SMTP-узлами, имеют значение при режиме связи, отличном от Direct Connection.
229
Создать документ Domain с подтипом Foreign SMTP Domain. Этот документ может создаваться в Notes-домене, имеющем свой SMTP MTA либо не имеющем такового. В первом случае заполняются следующие поля : Internet Domain – список DNS-доменов, в которые разрешена отправка сообщений через SMTP MTA, чаще всего указывается «*.*»; Allow Mail From – список разрешенных Notes-доменов, из которых принимается почта с SMTP- адресом получателя (пустое значение говорит о том, что почта принимается от любых доменов без ограничения), например «АДМ»; Domain Name – имя виртуального домена, указанного в документе Connection c подтипом SMTP Connection, например «CSDForeign». Во втором случае в поле Domain Name вместо имени виртуального домена (его не существует для домена без SMTP MTA) указывается имя Notes-домена, имеющего доступ к SMTP MTA, например «ФИНФ». (!)
Для отправки SMTP-сообщения из Notes-домена, не имеющего своего SMTP MTA, в адресе отправителя необходимо указывать, через какой (какие) Notes-домен (домены) потребуется маршрутизировать сообщение. Например «[email protected]@ФИНФ».
Для обеспечения работы SMTP MTA по приему SMTPсообщений и доставке их в почтовые ящики Notes-пользователей (Internet ->SMTP.BOX->MAIL.BOX) необходимо: – прописать сервер с SMTP MTA на DNS-сервере Internetдомена. Для этого, например, указываются следующие строки в файле настроек DNS-сервера: inf.tsu.ru IN MX 20 mx.csd.tsu.ru # SMTP-сервер для домена inf.tsu.ru csd.tsu.ru IN MX 20 mx.csd.tsu.ru # SMTP-сервер для домена Csd.tsu.ru; – создать документ Domain с подтипом Global Domain. Данный документ описывает, какие адреса допускаются во входящих SMTPсообщениях. Необходимо заполнить следующие поля: Domain Name – имя домена, например «CSDGlobal»;
230
Internet Suffixes – имена доменов Internet, которые обслуживает данный сервер, например «inf.tsu.ru; csd.tsu.ru»; Internet Address Lookup – указывает, выполнять ли поиск краткого Internet-имени пользователя в адресной книге Notes-домена. Значение «Enabled» позволяет использовать в адресах краткие имена, например «[email protected]». – в документе Server для Notes-сервера с SMTP MTA в разделе SMTP MTA заполнить следующие поля : Global Domain Name – имя домена из документа Domain с подтипом Global Domain, например «CSDGlobal»; Host Internet Name – полное DNS-имя хоста с SMTP MTA, например «mx.csd.tsu.ru»; – другие поля для тонкой настройки работы SMTP MTA. (!)
Если не используются краткие имена пользователей, то в адресе получателя перед суффиксом необходимо указывать имя пользователя в Notes c указанием имен доменов, через которые потребуется маршрутизация сообщения, например, «Васильев А. А.%Адм@csd.tsu.ru». 4.2.9. Установка пакета Lotus Notes
Пакет Lotus Notes реализован в архитектуре «клиент-сервер», поэтому установка пакета заключается в установке серверной части пакета Lotus Notes (сервера Domino/Notes) и клиентской части (рабочей станции Notes). Установка сервера Domino/Notes Установка сервера Domino/Notes (для ОС Windows 95/NT) состоит из трех этапов: копирование файлов или подготовительный этап, русификация среды, собственно установка или основной этап. В зависимости от того, устанавливается первый сервер в организации или очередной, последнему этапу предшествует этап сертификации.
231
I. Подготовительный этап (Копирование файлов) Выполняется с момента запуска программы Install.exe c дистрибутивного носителя. Во время выполнения этого этапа вы задаете: – каталог, куда будут скопированы программные файлы пакета, а также каталог, где будут размещаться файлы БД (рекомендуется разнести программы пакета и файлы БД); – компоненты пакета, которые будут установлены на локальный диск машины. Можно выбрать следующие компоненты: – Notes Workstation – если машина с сервером Lotus Domino будет также и рабочей станцией администратора; – Lotus Domino/Notes Server – собственно программные компоненты сервера, – Personal Data Files & Add Templates – личные файлы данных и дополнительные шаблоны; – Doc – файлы помощи; – Attach Viewers – средства просмотра внедренных в документы OLE-объектов; – Java support – поддержка среды Java; – Domino Templates – шаблоны Domino/Notes; – Single Password Login – средство синхронизации паролей Notes и Windows NT; – Notes Service Install – установка сервера в качестве сервиса Windows NT; – Notes Performance Monitor – средство анализа производительности (интегрируется с Windows NT Performance Monitor); – User Sync – синхронизация учетных записей Notes и Windows NT; – Advanced Services (Clustering support) – дополнительные возможности (кластеризация). После выполнения этапа на диске будут созданы каталоги X:\notes\ и Y:\data\, в которые будут скопированы файлы программ и файлы БД. Также в каталоге ОС (Windows или WINNT) будет создан «пустой» файл notes.ini, содержащий всего несколько строк. Например, такие: [Notes] Preferences=-2146808719 DominoResLang=ru KitType=2 Directory=c:\progra~1\notes\data WinNTIconPath=c:\progra~1\notes\data\W32
232
По содержимому файла notes.ini система определяет, выполнены все этапы установки, или нет. Таким образом, если вернуть файл notes.ini к состоянию после первого этапа, можно выполнить переустановку пакета, исключив этап копирования (чтобы избавиться от всех настроек, придется также удалить файлы Names.nsf, Log.nsf, Desktop.dsk, Cache.dsk, ADMIN4.NSF, CATALOG.NSF, *.ID, MAIL.BOX, расположенные в каталоге с файлами БД). II. Русификация среды Сначала нужно выполнить русификацию ОС. Для этого: – найти в реестре ключ LOCAL_MACHINE\CurrentControlSet\ Control\NLS и изменить значение параметра CL_1252 на CL_1251.NLS; – выбрать поддержку русского языка в апплете Local Settings (Start->Settings->Control Panel); – перезагрузить систему. Затем необходимо выполнить русификацию файлов пакета (в каталоге с программами): файл COLLCYR.CLS сохранить с именем COLLSTD.CLS; файл L_CP1251.CLS сохранить с именем L_CPWIN.CLS; файл L_CP1251.CLS сохранить с именем L_CP1252.CLS; файл L_CP866.CLS сохранить с именем L_CPDOS.CLS. III. Основной этап Включает также подэтап сертификации подразделения и /или сервера, если выполняется установка не первого (очередного) сервера организации. Подэтап сертификации заключается в создании и сертификации соответствующим заверителем ID-файла подразделения и/или ID-файла сервера. Выполняется с установленной рабочей станции Notes, подключенной к существующему серверу Lotus Domino/Notes. Например, если мы хотим установить сервер Главный в подразделении Бухгалтерия организации ЦентроБанк, то нужно создать новый уровень Бухгалтерия в дереве имен и получить ID-файл заверителя для данного подразделения. ID-файл сервера можно создавать сразу, а можно создать его в процессе установки сервера (рекомендуется). Предварительная операция регистрации сервера необходима, если позднее будет выполняться репликация БД с суще-
233
ствующих серверов Lotus Notes на вновь устанавливаемый сервер, так как при регистрации новый сервер будет внесен в группу OtherDomainServers с правом читателя (по умолчанию) всех БД на сервере регистрации. В случае установки еще одного сервера в уже зарегистрированном подразделении ограничиваются предварительным созданием ID-файла сервера и его заверением соответствующим ID-файлом заверителя. (!)
При регистрации сервера и создании ID-файла выберите пароль длины 0 и укажите «не сохранять ID-файл в АК, а только на диске».
Основной этап установки начинается после запуска программы Lotus Notes (файл notes.exe) с помощью созданной программой Install.exe пиктограммы Lotus Notes в папке Lotus Applications. В процессе установки используется БД setup.nsf (версия Domino 4.6x), что обеспечивает возможность временно отложить установку, сохранив параметры установки в БД. Состоит из нескольких подэтапов: Выбор, первый сервер в организации будет установлен или нет. Возможные варианты: – первый сервер в организации – выбрать «First Server»; – очередной сервер организации в новом домене (первый сервер в новом подразделении) – выбрать «First Server»; – очередной сервер организации в том же домене – выбрать «Another Server». Основные характеристики каждого варианта установки Первый сервер Очередной Очередной серв организации сервер орга- вер в домене Сервер низации в новом домене Что Создать Создать ад- Реплицировать должна CERT.ID, а ресную кни- адресную книгу сделать также адрес- гу, но не соз- домена, програмную книгу для давать CERT.ID не созма уста- домена CERT.ID давать новки
234
Выбор типа установки: Standard или Advanced – для очередного сервера организации в новом домене выбрать «Advanced»; (при выборе Advanced) Задание параметров установки – зависит от варианта установки: Очередной сервер Очередной сервер в Первый сервер организации в но- домене организации вом домене (подразделении) Выбор компонен- Выбор компонен- Выбор компонентов тов для работы в тов для работы в для работы в Internet Internet Internet Ввод данных о Указание пути к названии органи- ID-файлу заверинет зации, имени до- теля подразделемена Lotus Notes, ния пароля заверителя Ввод данных о Ввод данных о Указание пути к названии сервера названии сервера ID-файлу сервера Ввод данных об Ввод данных об Ввод данных об администраторе администраторе администраторе сервера и его па- сервера и его па- сервера и его пароле роле роле (для проверки в АК) После выполнения файлы на диске: Адресная книга организации Names.nsf Протокол работы Log.nsf Файл cert.id – заверителя организации
основного этапа будут созданы следующие Адресная книга подразделения (если выбрана установка как отдельной организации) Протокол работы Log.nsf нет
Адресная книга будет скопирована с ближайшего сервера домена организации Протокол работы Log.nsf нет
Файл server.id Файл user.id, если указано, что машина является также рабочей станцией администратора
235
Также на этом этапе установки выполняются следующие действия: – в адресной книге создается документ типа SERVER с информацией о созданном сервере, – в адресной книге создается документ типа GROUP с именем LocalDomainServers, – в адресной книге создается документ типа GROUP с именем OtherDomainServers, – в адресной книге создается документ типа CERTIFIER, – имя зарегистрированного администратора добавляется к ACL адресной книги с доступом «Менеджер», – в каталоге MAIL создается файл с почтовым ящиком администратора. Установка рабочей станции Notes Установка клиентской части пакета Lotus Notes (на ОС Windows 95/NT) также состоит из трех этапов: копирование файлов, русификация среды, собственно установка или основной этап. Если устанавливается русская версия клиента LN, то этап русификации опускается. Два первых этапа выполняются аналогично варианту установки сервера за исключением выбора опций установки (нет опций «сервер», «сервис NT» и т.п., но есть «Notes Designer»). Прежде чем выполнить основной этап установки рабочей станции, необходимо зарегистрировать в службе справочника LN пользователя(ей), для которого(ых) устанавливается рабочая станция. При регистрации указывается полное имя пользователя, пароль доступа к ID-файлу, указывается тип почтовой системы и местоположение почтового ящика, местоположение создаваемого ID-файла (в адресной книге и/или в файле на диске). После регистрации пользователя можно выполнить собственно установку. Для этого запускается программа notes.exe на рабочей станции пользователя (предполагается, что фазы копирования и русификации уже выполнены). При первом запуске программа notes.exe обнаруживает, что файл настроек notes.ini пуст и предлагает выполнить следующие действия:
236
Указать способ связи рабочей станции с сервером Notes (ЛВС, модем, ЛВС+модем, без связи с сервером), тип почтового сервера (Notes или POP3), способ представления ID-файла (с диска или из адресной книги). (!)
Если вы укажете, что ID-файл необходимо брать из ОАК, то после установки ID-файл исчезнет из документа типа Person адресной книги домена, однако будет скопирован на рабочую станцию пользователя.
Если выбран вариант с ID-файлом на диске, программа попросит указать путь к этому файлу, в противном случае вам нужно будет ввести имя пользователя, для которого устанавливается рабочая станция. Также нужно будет указать имя сервера, где хранится почтовый ящик пользователя и сетевой протокол, который будет использоваться при первом подключении к серверу. Если был выбран вариант подключения через модем, будет предложено указать номер телефона, номер последовательного порта и тип модема для подключения. После успешного подключения к серверу будет выполнена проверка на наличие пользователя в АК, запрошен пароль для ID-файла и при правильном вводе пароля установка продолжится. Перед самым завершением установки программа попросит указать часовой пояс, в котором устанавливается станция Notes (указать ZE7). После выполнения основного этапа будут созданы следующие файлы на диске: – user.id – ID-файл пользователя, для которого установлена рабочая станция; – личная адресная книга names.nsf (шаблон pernames.nsf); – файл с настройками рабочего стола desktop.dsk; – БД «Журнал» journal.nsf (шаблон journal.nsf); – БД «Избранное» favorite.nsf (шаблон prtfolio.nsf); – БД «Личный Web-Navigator» (шаблон perweb.nsf); – почтовый ящик пользователя mail.box (шаблон mail46.nsf), если при регистрации пользователя был выбран локальный способ хранения почтового ящика.
237
Установка пакетов обновления После установки пакета Lotus Notes может потребоваться обновление ПО сервера или рабочей станции для исправления ошибок, выявленных в ПО уже после выпуска коммерческой версии пакета, а также для расширения функциональности. Для внесения мелких исправлений в ПО пакета Lotus Notes (переход с версии 4.6.2a на 4.6.2b, например) компания Lotus выпускает пакеты инкрементного обновления (Quartery Maintainance Update / QMU), а для расширения функциональности (переход с версии 4.6.2b на 4.6.3, например) – пакеты инкрементных релизов (Quartery Maintainance Release/QMR). Для установки пакета обновлений необходимо: – завершить работу сервера или рабочей станции Notes. – запустить на выполнение файл с обновлением (например, w32intl.exe). Программа обновления проверяет установленные в системе файлы и, если обнаруживает необходимую версию пакета Lotus Notes, заменяет некоторые из установленных файлов пакета на новые, при этом версия сервера меняется (версия серверной части пакета отображается на консоли при запуске сервера). – запустить сервер или рабочую станцию и убедиться, что обновление прошло успешно. 4.2.10. Настройка пакета Lotus Notes
Настройка сервера Domino/Notes После установки сервера, особенно если был установлен не первый сервер организации, необходимо выполнить его настройку. Большая часть настроек сервера содержится в общей адресной книге (ОАК) домена, если не считать некоторых настроек в файле параметров notes.ini (см. далее). Кроме того, некоторые серверные задачи, например SMTP MTA или HTTP, используют настройки, хранящиеся в специальных БД (SMTPTbls.nsf и DomCfg.nsf соответственно).
238
Рассмотрим основные операции, которые могут понадобиться для настройки сервера: 1) Тонкая настройка ограничений на доступ к серверу. Ограничения на доступ задаются в разделе Restrictions документа типа Server (документ этого типа создается при регистрации каждого сервера). Для выполнения настройки: – Укажите в поле Can create databases on this server – группу создателей БД. – Укажите в поле Can create replicas on this server – группу репликаторов БД. – Укажите в поле Can access this server – группу лиц, имеющих доступ к серверу – чаще всего с помощью шаблонов, например */EDU. 2) Тонкая настройка сетевых портов на сервере. Настройки портов задаются в разделе Networks документа типа Server, а также в файле Notes.ini на сервере. Для выполнения настройки: – В разделе Networks документа типа Server укажите активные порты на сервере; сети Notes, которым принадлежат эти порты; имя сервера на каждом порту. Эти настройки используются серверами Domino/Notes для обнаружения, можно ли выполнить прямую репликацию или передачу почты, либо требуется использовать документ типа Connection. – Пользуясь меню, выберите File->Preferences->Ports и укажите порты и параметры настройки, перед этим необходимо выгрузить сервер Domino/Notes. 3) Тонкая настройка сервера для взаимодействия с серверами других именованных сетей Notes и/или серверами других доменов (для обмена почтой и репликами БД). Для этого создаются и настраиваются документы типа Connection. Для настройки создайте по одному документу данного типа на каждый сервер, с которым будет взаимодействовать настраиваемый сервер. Например, для связи сервера Test/EDU с сервером Main/INF/TSU/Tomsk/RU укажите: – тип соединения – Local Network; – в качестве исходного сервера Test/EDU из домена EDU; – в качестве сервера назначения Main/INF/TSU/Tomsk/RU из домена INF; – протокол взаимодействия, например TCPIP;
239
– если необходимо, расписание для взаимодействия и задачи, которые будут использовать этот документ, например Mail Routing, Replication. 4) Тонкая настройка сервера для успешной аутентификации с объектами Notes, принадлежащими другим деревьям имен. При взаимодействии объектов, принадлежащих разным деревьям имен Notes (например, серверов – для обмена почтовыми сообщениями), требуется перекрестная сертификация. Для выполнения перекрестной сертификации уровней EDU и TSU/Tomsk/RU двух деревьев имен: – создайте Safe-копию ID-файла сервера Test/EDU и отошлите ее в другую организацию (TSU), где будет создан парный перекрестный сертификат; – получите Safe-копию ID-файла сервера другой организации, например Main/INF/TSU/Tomsk/RU; – пользуясь меню, выберите File->Server Administration>Certifiers->Cross Certify; – в диалоговом окне выберите ID-файл заверителя вашей организации (CERT.ID для EDU), введите пароль; – выберите полученную Safe-копию ID-файла сервера другой организации (SafeMAIN.ID); – укажите тот уровень дерева имен другой организации, для которого вы создаете перекрестный сертификат (например, TSU/Tomsk/RU). После этого в ОАК будет создан документ типа Certifier, с помощью которого будет выполняться авторизация объекта дерева имен Notes другой организации. Настройка рабочей станции Notes После установки рабочей станции может потребоваться тонкая настройка клиентской части пакета Lotus Notes. Настройки рабочей станции хранятся в личной адресной книге пользователя (файл names.nsf), а также в файле параметров Notes.ini. Рассмотрим основные операции, которые могут понадобиться для настройки рабочей станции: 1) Тонкая настройка сетевых портов рабочей станции. Настройки портов хранятся в файле Notes.ini. Для выполнения настройки, пользуясь меню, выберите File->Preferences->Ports. Затем укажите порты и параметры настройки портов.
240
2) Тонкая настройка рабочей станции для взаимодействия с серверами (для обмена почтой и репликами БД). Для этого создаются и настраиваются документы типа Connection (Подключение). Для настройки создайте по одному документу данного типа на каждый сервер, с которым будет взаимодействовать рабочая станция. Например, для связи с сервером Test/EDU укажите: – тип соединения – Local Network; – в качестве сервера подключения – Test/EDU; – протокол взаимодействия, например TCPIP; – в разделе «Дополнительно» можно указать дополнительные параметры подключения, например, адрес сервера по указанному протоколу (test.inf.tsu.ru); список пользователей, которые могут использовать данное подключение и т.д. Чаще всего настраивать подключение к серверу требуется, если мы работаем с ним не по локальной сети, а по модему, либо через сервер-посредник. 3) Тонкая настройка местонахождения рабочей станции. Работая с пакетом Lotus Notes, мы можем гибко управлять способом подключения рабочей станции к сети. Для этого служат документы типа Location (Места вызова). В документе данного типа мы указываем порты, которые необходимо использовать для подключения; почтовый сервер; тип (Notes, POP3 и т.п.) и параметры почтовой системы; расписание для автоматической репликации и т.д. После установки рабочей станции в ЛАК уже находится несколько документов данного типа (Работа, Дом (модем), Интернет и т.д.). 4) Тонкая настройка рабочей станции для успешной аутентификации на серверах Notes, принадлежащих другим деревьям имен. Также обеспечивается документами типа Certifier (Заверитель). Настройка чаще всего выполняется автоматически при попытке доступа к БД, подписанной другим заверителем. Основные параметры файла Notes.ini Хотя большинство настроек компонентов пакета Notes содержится в специальных БД Notes (ОАК и т.п.), есть настройки, которые не могут быть перенесены в БД. Эти настройки являются платформо-зависимыми и/или используются в процессе запуска сервера Domino или рабочей станции Notes.
241
Список основных настроек (далеко не полный): KitType = 1| 2 – тип части пакета Lotus Notes (1 – рабочая станция, 2 – сервер). Domain = <имя> – на сервере – имя домена, к которому принадлежит сервер; на клиенте – имя домена, к которому принадлежит «домашний» сервер. KeyFilename=<путь и имя ID-файла пользователя>. ServerKeyFilename=<путь и имя ID-файла сервера> – необходимо только на сервере Domino/Notes. CertificateExpChecked=<дата последней проверки истечения срока действия сертификата>. CertifierIDFile=<путь и имя ID-файла заверителя> – необходим на первом сервере организации и рабочей станции администратора. Names=<список имен файлов адресных книг> – список ОАК, где будет осуществляться поиск имен адресатов при передаче почты, первым в списке должен быть NAMES.NSF. ServerTasks=<список задач, автоматически запускаемых на сервере при запуске>. ServerAtX =< список задач, автоматически запускаемых на сервере в X часов >. Ports= – рекомендуется изменять через графический интерфейс рабочей станции File-ToolsUser Preferences-Ports. DisabledPorts= – также через графический интерфейс. <имя сетевого порта>=<параметры порта> – также через графический интерфейс. Directory=<путь к каталогу с БД> – каталог, который будет корневым для узла сети Domino/Notes. XXXXXIconPath=<путь к каталогу с иконками для панели инструментов> – XXXXX определяет платформу, например WinNT. MailServer=<полное (иерархическое) имя «домашнего» сервера>. MailFile=<путь и имя файла с почтовым ящиком (относительно каталога с БД)>.
242
4.2.11. Функции администратора Lotus Notes. Основные инструменты для администрирования
Администратор пакета Lotus Notes должен выполнять следующие функции: Установку cерверов и рабочих станций Notes и контроль их работы. Обслуживание серверов Notes. Включает: – запуск и останов работы сервера, – настройку автоматического запуска задач, – настройку расписаний репликации БД и маршрутизации почты. Обслуживание службы справочника. Включает: – первичную регистрацию пользователей, серверов и заверителей, – добавление сертификата организации и подразделения (организационной единицы) к существующим ID-файлам и адресным книгам, – ресертификацию ID с использованием почты Notes и без использования почты Notes, – проверку, продление срока и удаление сертификатов, – редактирование документа с информацией о пользователе (Person), – выполнение запроса пользователя о новом открытом ключе, – восстановление испорченного ID-файла или пароля, – выполнение запроса о взаимном сертификате, – переключение ID на сервере, – ведение групп пользователей и серверов. Управление БД на серверах Notes. Включает: – создание и управление списками доступа к БД, – использование каталога БД CATALOG.NSF, – отслеживание размеров БД и их сжатие, – контроль за размещением БД – управление каталогами и ссылками на каталоги, – перемещение БД, – удаление устаревших документов из БД и удаление БД, – использование шаблонов БД, – обновление индексов полнотекстового поиска, – создание реплик БД, – устранение репликационных конфликтов.
243
Средства управления сетью на основе Lotus Notes Функции управления, возложенные на администратора пакета Lotus Notes, выполняются с использованием следующих средств: 1) Рабочая станция Lotus Notes – позволяет просматривать и редактировать любые БД на локальном и удаленном серверах, в том числе общую адресную книгу (ОАК) домена. 2) Рабочая станция Lotus Notes в режиме Server Administration (запуск Notes.exe с ключом ADMINONLY) – позволяет просматривать, редактировать существующие и регистрировать новые серверы и пользователей Notes, выполняя их сертификацию; просматривать и редактировать группы серверов и пользователей; выполнять операции сжатия, восстановления над БД; получать удаленный доступ к консоли любого из известных системе серверов Lotus Domino/Notes. С помощью графического интерфейса Server Administrator неявно выполняется работа с ОАК домена и другими БД, использующимися для управления сетью Notes. (!)
Доступ к удаленной консоли сервера могут получить только пользователи, занесенные в поле Administrators раздела Restrictions документа типа Server.
(!)
Все функции работы в режиме Server Administration можно также получить, выбрав в меню рабочей станции команду File-> Tools->Server Administration.
Список основных функций, выполняемых с рабочей станции в режиме Server Administration: – регистрация пользователей; – регистрация серверов; – управление каталогами и связями (Links)/виртуальными каталогами на серверах; – просмотр административных БД : ОАК, журнала работы, протокола сертификации и т.д; – выполнение команд в режиме удаленной консоли; – управление группами; – регистрация заверителей/организационных единиц; – сертификация/ресертификация/перекрестная сертификация; – контроль очереди исходящих сообщений и трассировка маршрутизации почты;
244
– управление БД, включая анализ, восстановление, индексирование, подпись, реплицирование, сжатие, установку управляющего сервера и т.д. Консоль сервера Lotus Notes – позволяет выполнять оперативные функции по загрузке и выгрузке задач сервера, получать статистику о параметрах сервера и его работе, выполнять завершение работы сервера, выполнять ручной запуск серверных задач и т.д. Основные команды консоли: – help – получить список команд консоли сервера; – show users – показать список активных сессий с сервером; – show task (сокращенно – sh ta) – получить информацию о запущенных на сервере задачах Notes; – show port <имя порта> – получить информацию о работе конкретного порта сети, например, show port lan0; – load <имя задачи> – запустить задачу, например, load replica; – tell <имя задачи> <команда> – выдача команды задаче, например, для завершения ее работы (tell <имя задачи> quit); – replicate <имя сервера> [список баз] – выполнить Pull-Push репликацию с указанным сервером; – pull <имя сервера> [список баз] – выполнить Pull-репликацию; – push <имя сервера> [список баз] – выполнить Pushрепликацию; – route <имя сервера> – выполнить «мгновенную» передачу почты на указанный сервер; – broadcast «<сообщение>» [«<список пользователей>«] – послать сообщение пользователям, подключенным к серверу; – quit/exit – завершить работу сервера.
245
Вопросы и задания Дайте определение ПО групповой работы. Укажите составные части GroupWare. Какие функции в составе ИВС выполняет GroupWare? Опишите, каким образом строится ИВС на основе Lotus Notes. Дайте определения понятиям «домен Notes» и «сеть Notes». Какие объекты могут присутствовать в службе справочника Lotus Notes и для каких целей они используются? Каков механизм идентификации объектов? Для чего необходимы сертификаты? Укажите основные механизмы для обеспечения безопасности в Lotus Notes? Сколько уровней доступа к БД Notes существуют? Укажите, каковы права пользователей на каждом уровне. Для каких целей используется ECL? Дайте определение понятия «репликация в Lotus Notes» и укажите, для каких целей используется репликация. Сколько схем или типов репликаций имеется в Lotus Notes? Охарактеризуйте каждую схему в отдельности. Какие компоненты в составе Lotus Notes отвечают за работу почтовой подсистемы? Как осуществляется передача сообщений в Lotus Notes?
246
ПОСЛЕСЛОВИЕ В книге рассмотрены составные части современных информационно-вычислительных сетей: аппаратное и программное обеспечение. На примере ОС Novell NetWare и ОС Microsoft Windows NT Server рассмотрена серверная ОС, ее организация, основные службы в составе серверной ОС. Рассмотрены следующие вопросы администрирования: установка серверной ОС, утилиты администрирования, подключение пользователей к серверной ОС. На примере ОС Microsoft Windows NT Workstation и ОС Microsoft Windows 95 рассмотрена клиентская ОС, архитектура сетевого ПО в составе клиенской ОС, порядок установки сетевого ПО и вопросы настройки рабочей среды пользователей. На примере СУБД Oracle рассмотрена современная реляционная СУБД в архитектуре «клиент-сервер», вопросы ее организации, порядок установки и настройки, вопросы обеспечения безопасности и надежности хранимой информации. На примере пакета Lotus Domino/Notes рассмотрено ПО для групповой работы и почтовая система в составе этого ПО, порядок установки и настройки, вопросы обеспечения безопасности и надежности хранимой информации. К сожалению, за рамками данной книги остались такие важные компоненты ИВС, как средства интеграции с Internet/Intranet, а также средства сетевого и системного управления распределенными ИВС масштаба предприятия. Не рассмотрено также и семейство ОС Unix, программные компоненты в составе которых используются прежде всего для организации взаимодействия с Internet/Intranet. Также большая часть ПО сетевого и системного управления разрабатывается именно для платформы Unix.
247
ЛИТЕРАТУРА 1. Бартон Д. Создание правильной кабельной системы // Сети и системы связи. 1996. № 9. С. 30–33. 2. Бобровски С. Oracle7 и вычисления клиент-сервер: Пер. с англ. М.: Изд-во «Лори». 1995. 650 с. 3. Брэднер С. Мосты, маршрутизаторы, коммутаторы: здравый смысл и «собака», которая не лаяла // Сети и системы связи. 1996. № 10. С. 36–41. Веттиг Д. Novell NetWare: Пер. с нем. К.: Торгово–издательское бюро BHV. 4. 1994. 480 с. 5. Гурвич М. МП–серверы в новом масштабе // LAN. 1998. № 4. С. 30–38. 6. Зельцер Л. NT5: предварительное знакомство // PC Magazine. 1999. № 1. С. 100– 113. 7. Зубанов Ф. Windows NT – выбор «профи». М.: Издательский отдел «Русская редакция» ТОО «Channel Trading Ltd.». 1996. 392 с. 8. Ионцев Н. Н. Администрирование Lotus Notes версий 4.1x и Lotus Domino версий 4.5x. М.: Издательская фирма «Светотон». 1997. 333 с. 9. Ионцев Н.Н., Панов В.А., Данилин А.В. Разработка приложений и администрирование в Lotus Notes. М.: ИнтерТраст Лтд.. 1995. 223 с. 10. Карр Э. Применение профилей пользователей в Windows 95 // Сети и системы связи. 1996. № 4. С. 111–113. 11. Карр Э. Системная политика – ключ к эффективному управлению // Сети и системы связи. 1996. № 4. С. 108–110. 12. Кастер Х. Основы Windows NT и NTFS: Пер. с англ. М.: Издательский отдел «Русская редакция» ТОО «Channel Trading Ltd.». 1996. 440 с. 13. Лоренс Б. Novell NetWare 4.1 в подлиннике: Пер. с англ. СПб.: BHV. 1996. 720 с. 14. Майоров А. П. ИБП для ПК и рабочих станций // Сети и системы связи. 1997. № 1. с. 118–126. 15. Мейсон. SMP–серверы // Сети и системы связи. 1997. № 10. С. 16–30. 16. Милн Д. Контроль за работой сервера // Сети и системы связи. 1996. № 7. С. 14–17. 17. Милн Д. Сетевые ОС: Кому принадлежит будущее? // Сети и системы связи. 1998. № 4. С. 24–45. 18. Милн Д. Системы RAID: решение проблемы хранения данных // Сети и системы связи. 1996. № 9. С. 10–17. 19. Олифер В.Г., Олифер Н.А. Безопасность: Windows NT и новые технологии Microsoft // Cети и системы связи. 1996. № 9. С. 124–131. 20. Орлов C. Oracle Universal Server // ComputerWeek. 1996. № 20. С. 24–27. 21. Пьянзин К. NetWare 5 – новая ставка Novell // LAN. 1998. № 12. С. 71–80. 22. Пьянзин К. ПО резервирования глазами администратора // LAN. 1998. № 7–8. С. 57–64. 23. Пьянзин К. Службы каталогов Novell и Microsoft // LAN. 1999. № 3. С. 81–91. 24. Рули Д. Windows NT 4.0: новые средства и возможности // Сети и системы связи. 1996. № 9. С. 54–63. 25. Снайдер Д. Как выбрать лучший сервер // LAN. 1998. № 7–8. С.109–116. 26. Ценк А. Novell NetWare 4.x.: Пер. с нем. Киев: Торгово–издательское бюро BHV. 1996. 786 с.
248
Кустов Николай Тимофеевич АДМИНИСТРИРОВАНИЕ ИНФОРМАЦИОННОВЫЧИСЛИТЕЛЬНЫХ СЕТЕЙ Учебное пособие Корректор К.В. Полькина Макет обложки В.Г. Караваева Лицензия ИД №00208 от 20.12.1999 г. Подписано к печати г. Формат 84/108/32 Бумага офсетная № 1. Гарнитура Times. Ризография. Печ. л. .Усл. печ. л. . Тираж экз. Заказ № Томский государственный университет 634050, г.Томск, пр. Ленина, 36 Участок оперативной ризографии Редакционно-издательского отдела ТГУ Лицензия ПД № 00455 от 15.11.1999 г.
249
