Файловая система NFS. Сетевые файловые системы

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ВОЗДУШНОГО ТРАНСПОРТА

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ

ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

ГРАЖДАНСКОЙ АВИАЦИИ»

____________________________________________________________________________________________________________________

Кафедра вычислительных машин, комплексов, систем и сетей

СЕТЕВЫЕ ОПЕРАЦИОННЫЕ СИСТЕМЫ.

СЕТЕВЫЕ ФАЙЛОВЫЕ СИСТЕМЫ

И СЛУЖБА КАТАЛОГОВ

Утверждено Редакционно-

издательским Советом МГТУ ГА

Москва - 2010

ББК 32.973.202-018.2я73-1+32.973.26-018.2я73-1

Печатается по решению редакционно-издательского совета

Московского государственного технического университета ГА

Рецензенты: канд. физ.-мат. наук, доц. ;

Ч48 Сетевые операционные системы. Сетевые файловые системы и служба каталогов: Учебное пособие. - М.: МГТУ ГА, 2010. –68 с. 10 ил., лит.: 4 наим.

Данное учебное пособие издается в соответствии с рабочей программой учебной дисциплины «Сетевые операционные системы» по Учебному плану специальности 230101 для студентов IV курса дневного обучения.

Рассмотрено и одобрено на заседаниях кафедры 11.05.10 г. и методического совета 14.05.10 г.

Ц33(03)-10 Св. тем. план 2010 г.

ЧЕРКАСОВА Наталья Ивановна

СЕТЕВЫЕ ОПЕРАЦИОННЫЕ СИСТЕМЫ.

СЕТЕВЫЕ ФАЙЛОВЫЕ СИСТЕМЫ И СЛУЖБА КАТАЛОГОВ

Учебное пособие

Редактор

Подписано в печать 11.10.10 г.

Печать офсетная Формат 60х84/16 4,0 уч.-изд. л.

3,95 усл. печ. л. Заказ № 000/ Тираж 100 экз.

Московский государственный технический университет ГА

125993 Москва, Кронштадтский бульвар, д. 20

Редакционно-издательский отдел

125493 Москва, ул. Пулковская, д.6а

© Московский государственный

технический университет ГА, 2010

Раздел 1. Состав сетевых операционных систем

1.1. Сетевые ОС. Определение, основные свойства

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

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

Рассматриваются две разновидности сетей: LAN (Local area network) – локальная сеть, набор компьютеров и устройств, объединенных в пределах одного здания, и WAN(Wide area network) – глобальная сеть совмещает в себе несколько географически разделенных локальных сетей, которые связаны посредством различных WAN - технологий.

Назначение сети зависит от потребностей человека или организации, но, в общем случае, можно перечислить следующие возможности использования сетей:

1) совместное использование файлов. Сеть позволяет использовать файлы данных как хранящиеся в компьютере конкретного пользователя, так и файлы, размещенные на специализированном файловом сервере;

2) совместное использование аппаратных средств;

3) совместное использование программного обеспечения ;

4) обмен информацией между пользователями;

5) сетевые игры.

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

Операционные системы для сетей во многом аналогичны ОС автономного компьютера. Однако если последняя представляет пользователю некую виртуальную вычислительную машину, то сетевая ОС, представляя пользователю некую виртуальную вычислительную систему, работать с которой гораздо проще, чем с реальной сетевой аппаратурой, не полностью скрывает распределенную природу своего реального прототипа. Можно сказать, что сетевая ОС предоставляет пользователю виртуальную сеть. В идеальном случае сетевая ОС должна представлять пользователю сетевые ресурсы в виде ресурсов единой централизованной виртуальной машины. Такие операционные системы называются распределенные ОС или истинно распределенные ОС.

Распределенные ОС, динамически и автоматически распределяя работы по различным машинам системы для обработки, заставляют работать набор сетевых машин как виртуальный унипроцессор. Распределенная ОС работает как единая операционная система в масштабах вычислительной системы.

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

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

1) средства управления локальными ресурсами, то есть все функции ОС автономного компьютера;

2) серверная часть ОС – средство предоставления локальных ресурсов и услуг в общее пользование;

3) клиентская часть ОС – средства доступа к удаленным ресурсам и услугам;

4) транспортные средства ОС, которые совместно с коммуникационной системой обеспечивают передачу сообщений между компьютерами сети.

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

Сетевые службы являются клиент – серверными системами, то есть содержит в своем составе клиентскую и серверную часть. Однако сетевая служба может быть представлена в ОС либо обеими частями, либо только одной из них.

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

Хотя один тип сервера может быть рассчитан на работу с клиентами разного типа, клиент и сервер должны поддерживать общий стандартный протокол взаимодействия.

Глубина внедрения сетевых служб в ОС определяет несколько подходов к построению сетевых ОС:

1) сетевые службы объединены в виде некоторого набора – оболочки;

2) сетевые службы поставляются и производятся в виде отдельного продукта;

3) сетевые службы внедрены в ОС.

Различные цели, преследуемые при создании различных сетей, предполагают наличие различных типов сетей. Одноранговая сеть (Peer-to-Peer Network) представляет собой простой способ объединения персональных компьютеров в тех случаях, когда необходимо совместное использование файлов и прочих ресурсов. В одноранговой сети нет сервера, и все компьютеры функционируют как равноправные узлы. Одноранговую сеть часто называют рабочей группой (Workgroup), так как этот термин ассоциируется с равноправным сотрудничеством без централизованного управления.

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

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

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

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

ОС DOS не поддерживала одноранговые сети, поэтому для совместного использования файлов или принтеров требовались дополнительные программные продукты, т. е. сетевые функции реализовывались сетевыми оболочками, работающими поверх ОС. Для поддержки рабочих групп использовались такие программные продукты, как Artisoft LANtastic, Novell NetWare Lite, Personal NetWare и Windows for Workgroup 3.11. Все последующие версии Windows поддерживают рабочие группы.

Дистрибутивы Linux также поддерживают создание рабочих групп из компьютеров, работающих под управлением Windows или Linux с помощью программы Samba.

Хотя к основным достоинствам одноранговых сетей относится, прежде всего, простота установки, имеется и ряд других преимуществ:

1) обычно все необходимое обеспечение уже включено в состав ОС;

2) не требуется системное администрирование, и отдельные пользователи сами могут управлять ресурсами;

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

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

Сети с выделенным сервером (или серверами) (Server – based network) могут быть очень крупными и предоставлять пользователям более широкий диапазон ресурсов по сравнению с одноранговыми сетями. Связано это, прежде всего, с тем, что в такой сети имеются различные специализированные серверы.

Кроме того, эти сети позволяют осуществлять централизованное управление ресурсами и добавлять в сеть новые компьютеры, пользователей и ресурсы. Такие сети являются масштабируемыми, то есть могут легко расширяться.

Единственным требованием к такой сети является наличие компьютера, на котором запущена сетевая операционная система, такой компьютер называется сервером.

Как и у одноранговой сети, сети с выделенным сервером имеют свои достоинства и недостатки. Прежде всего, перечислим достоинства:

1) для получения доступа к сетевым ресурсам пользователь вводит только одно регистрационное имя и пароль;

2) управление безопасностью в сети и сетевыми ресурсами осуществляется централизованно;

3) централизованное размещение позволяет выполнять резервное копирование каталогов и файлов;

4) специализированные серверы обеспечивают быстрый доступ к ресурсам;

5) подобные сети можно расширять.

Теперь отметим ряд недостатков:

1) необходимо осуществлять настройку и управление ресурсами в сети, то есть необходим системный администратор;

2) при сбое главного сервера доступ к сетевым ресурсам прекращается;

3) экономически сети с выделенным сервером выгодны только для достаточно крупных компаний.

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

1) компьютер в роли выделенного сервера сети, то есть только обслуживающий запросы других компьютеров;

2) компьютер, обращающийся с запросом к ресурсам другой машины, - клиентский узел;

3) компьютер, совмещающий функции клиента и сервера, - одноранговый узел.

Следовательно, можно определить различные схемы построения сети, как:

1) одноранговая сеть – сеть на основе одноранговых узлов;

2) сеть с выделенным сервером – сеть на основе клиентов и серверов.

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

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

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

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

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

Рассмотрим основные специализированные серверы.

Файловые серверы используются для хранения файлов, необходимых для пользователей сети. Серверы печати используются для управления сетевым принтером, по сути это управляющий канал связи с принтером.

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

Некоторые типы серверов используются не для получения доступа к ресурсам, а для повышения качества и эффективности работы в сети. Например, DNS - сервер (Domaine Name Service) – служба имен доменов выполняет преобразование дружественных имен в соответствующие адреса.

Теперь рассмотрим более подробно взаимодействие клиента и серверной ОС. Когда компьютер обращается к файлу на локальном диске или к принтеру, подключенному напрямую, запрос направляется процессору компьютера. Процессор выполняет запрос и все операции выполняются локально. При обращении к общим ресурсам файлового сервера или печати на удаленном принтере сетевое клиентское программное обеспечение выполнят специальную операцию, благодаря которой компьютер считает сетевые ресурсы локальными.

Этот процесс осуществляется компонентом клиентского программного обеспечения, который называют редиректор (REDIRECTOR). Он перехватывает любые запросы, выполненные на компьютере, и в зависимости от типа запроса передает его на сетевой сервер для обработки или определяет, что этот запрос будет выполняться локально.

1.2. Поддержка сетей на основе ОС Windows 2000. Уровни OSI и сетевые компоненты ОС Windows 2000. Сетевые API

Рассмотрим механизмы построения сетевой операционной системы на примере ОС Windows 2000.

Эталонная модель OSI (The OSI Reference Model)

Чтобы помочь поставщикам в стандартизации и интеграции сетевого программного обеспечения в 1974 the International Organization for Standardization (ISO) определила программную модель пересылки сообщений между компьютерами. Результатом явилась the Open Systems Interconnection (OSI) – эталонная модель. Модель определяет семь уровней программного обеспечения (Рис.1).

DIV_ADBLOCK93">

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

Сетевые компоненты Windows 2000 (Networking Components)

На рис. 2 представлена общая схема сетевых протоколов Windows 2000, их соответствие уровням эталонной модели, а также протоколы, используемые различными уровнями. Как видно, между уровнями модели и сетевыми компонентами нет точного соответствия. Некоторые компоненты охватывают несколько уровней. Далее приводится список и краткое описание:

1) Networking(Сетевые) API обеспечивают независимое от протоколов взаимодействие приложений через сеть. Networking API реализуются либо в режиме ядра и пользовательском режиме, либо только в пользовательском. Некоторые networking API являются оболочками других API и реализуют специфическую модель программирования или предоставляют дополнительные сервисы. (Термином networking API обозначаются любые программные интерфейсы, представляемые сетевым программным обеспечением);

2) клиенты TDI (Transport Driver Interface). Драйверы устройств режима ядра, обычно реализующие ту часть сетевого API, которая работает в режиме ядра. Клиенты TDI называются так из-за того, что I/O пакеты запросов ввода-вывода (IRP), которые они посылают драйверам протоколов Windows 2000, форматируются по стандарту Transport Driver Interface standard (документировано в DDK). Этот стандарт определяет общий интерфейс программирования драйверов устройств режима ядра;

3) транспорты TDI. Представляют собой драйверы протоколов режима ядра и часто называются транспортами, (Network Driver Interface Specification), NDIS-драйверами протоколов или драйверами протоколов. Они принимают IRP от клиентов TDI и обрабатывают запросы, представленные этими IRP. Обработка запросов может потребовать взаимодействия через сеть с другими равноправными компьютерами, в этом случае транспорт TDI добавляет к данным IRP заголовки, специфические для конкретного протокола (TCP, UDP, IPX), и взаимодействует с драйверами адаптеров через функции NDIS (also documented in the DDK). В общем, транспорты TDI связывают приложения через сеть, выполняя такие операции, как сегментация сообщений, их восстановление, упорядочение, подтверждение и повторная передача;

4) библиотека NDIS (Ndis. sys). Инкапсулирует функциональность для драйверов адаптеров, скрывая от них специфику среды Windows 2000, работающей в режиме ядра. NDIS library экспортирует функции для транспортов TDI, а также функции поддержки для драйверов адаптеров;

5) минипорт – драйверы NDIS. Драйверы режима ядра, отвечающие за организацию интерфейсов между TDI transports и конкретными сетевыми адаптерами. NDIS miniport drivers пишутся так, чтобы они были заключены в оболочку Windows 2000 NDIS library. Такая инкапсуляция обеспечивает межплатформенную совместимость с потребительскими версиями Windows. NDIS miniport drivers не обрабатывают process IRP; а регистрируют интерфейс таблицы вызовов NDIS library, которая содержит указатели на функции, соответствующие функциям, экспортируемым библиотекой NDIS для TDI transports. NDIS miniport drivers взаимодействуют с сетевыми адаптерами, используя функции NDIS library, которые вызывают соответствующие (HAL) функции.

Примечание: Диспетчер ввода-вывода (I/O manager) определяет модель доставки запросов на ввод-вывод драйверам устройств. Большинство запросов ввода-вывода представляется I/O пакетами запросов ввода-вывода (I/O request packets IRP), передаваемых от одного компонента подсистемы ввода-вывода другому. IRP – это структура данных, которая содержит информацию, полностью описывающую запрос ввода-вывода.

Фактически четыре нижних сетевых уровня часто обозначают собирательным термином «транспорт», а компоненты, расположенные на трех верхних уровнях – термином « пользователи транспорта».

DIV_ADBLOCK96">

Протокол SMB является протоколом прикладного уровня, включающим сетевой уровень и уровень представления.

SMB реализует:

1) установление сессии;

2) файловый сервис;

3) сервис печати;

4) сервис сообщений.

CIFS – открытый Microsoft стандарт (документированный в Platform SDK), который позволяет другим платформам взаимодействовать с Windows 2000 файловым сервером и с Windows 2000 файловым клиентом. Например, Samba позволяет UNIX системам выступать в роли файлового сервера для Windows 2000 клиента и UNIX приложениям получать доступ к файлам, хранящимся в системах под управлением Windows 2000 систем. Другие поддерживающие CIFS платформы включают DEC VMS и Apple Macintosh.

Совместное использование файлов в Windows 2000 основывается на редиректоре (redirector FSD - redirector, для краткости), который выполняется на клиентской машине и взаимодействует с FSD redirector сервера. FSD перехватывает запрос Win32 file I/O, направленный в файлы, расположенные на сервере, и передает CIFS messages файловой системе сервера. Сервер получает CIFS messages и преобразует их обратно в запросы на операцию ввода-вывода, которые он выдает локальным FSDs, таким как NTFS.

Поскольку они интегрированны с подсистемой ввода-вывода Windows 2000 (I/O system), redirector and server FSDs имеют некоторые преимущества перед альтернативной реализацией файловых серверов:

1) они могут напрямую взаимодействовать с TDI transports и локальными FSD;

2) они бесшовно интегрируются с диспетчером кеша, что позволяет кешировать данные с файл-сервера на клиентских системах.

Приложения могут использовать стандартные Win32 file I/O функции, такие как CreateFile, ReadFile, and WriteFile для доступа к удаленным файлам.

В Windows 2000 redirector server FSD используют стандартные правила именования сетевых ресурсов, применяемые всеми файл-серверами и клиентскими программами режима ядра. Если подключение к сетевому ресурсу производится по букве диска, имена сетевых файлов указываются также как локальные. Тем не менее, redirector также поддерживает UNC имена

Как server FSD, так и redirector имеют Win32 сервисы, Server and Workstation, выполняемые в процессе service control manager (SCM) и предоставляющие драйверам интерфейсы административного управления.

Примечание:

Можно реализовать серверное приложение как простую исполняемую программу, но можно использовать особый вид – служба (сервис). Служба – это приложение, содержащее дополнительную инфраструктуру, которая позволяет SCM управлять этим приложениям. Все серверные приложения, поставляемые с системой, работают как службы.

Интерфейс транспортных драйверов (TDI)

Открытая архитектура сетевых средств Windows NT обеспечивает работу своих рабочих станций (и серверов) в гетерогенных сетях не только путем предоставления возможности динамически загружать и выгружать сетевые средства, но и путем непосредственного переключения с программных сетевых средств, ориентированных на взаимодействие с одним типом сетей, на программные средства для другого типа сетей в ходе работы системы. Windows NT поддерживает переключение программных средств на трех уровнях:

1) на уровне редиректоров - каждый редиректор предназначен для своего протокола (SMP, NCP, NFS, VINES);

2) на уровне драйверов транспортных протоколов, предоставляя для них и для редиректоров стандартный интерфейс TDI;

3) на уровне драйверов сетевых адаптеров - со стандартным интерфейсом NDIS 3.0.

Для доступа к другим типам сетей в Windows NT, помимо встроенного, могут загружаться дополнительные редиректоры. Специальные компоненты Windows NT решают, какой редиректор должен быть вызван для обслуживания запроса на удаленный ввод-вывод. За последние десятилетия получили распространение различные протоколы передачи информации по сети. И хотя Windows NT поддерживает не все эти протоколы, она, по крайней мере, разрешает включать их поддержку.

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

TDI позволяет редиректорам оставаться независимым от транспорта. Таким образом, одна версия редиректора может пользоваться любым транспортным механизмом. TDI обеспечивает набор функций, которые редиректоры могут использовать для пересылки любых типов данных с помощью транспортного уровня. TDI поддерживает как связи с установлением соединения (виртуальные связи), так и связи без установления соединения (дейтаграммные связи). Хотя LAN Manager использует связи с установлением соединений, Novell IPX является примером сети, которая использует связь без установления соединения. Microsoft изначально обеспечивает транспорты - NetBEUI (NetBIOS Extended User Interface), TCP/IP, IPX/SPX, DECnet и AppleTalk.

Исходя из описанного выше, представим следующие выводы.

Интерфейс транспортных драйверов (TDI) - это общий интерфейс, позволяющий таким компонентам, как редиректор и сервер связываться с различными сетевыми транспортами, т. е. оставаться независимыми от транспорта. Отметим, что (TDI) – это не драйвер, а стандарт для передачи сообщений между уровнями сетевой архитектуры. Microsoft определила стандарт TDI, чтобы драйверам сетевых протоколов не приходилось использовать отдельные интерфейсы для каждого необходимого им транспортного протокола.

Как уже говорилось, Интерфейс транспортных драйверов (TDI) по сути представляет правила формирования сетевых запросов в IRP, а также выделения сетевых адресов и коммуникационных соединений. Транспортные протоколы, отвечающие данному стандарту, экспортируют интерфейс TDI своим клиентам, в число которых входят драйверы сетевых API и редиректор. Транспортный протокол, реализованный в виде драйвера устройства, называется транспортами TDI, а поскольку они есть драйверы, то преобразуют получаемые от клиентов запросы в IRP. Интерфейс транспортных драйверов (TDI образуют функции поддержки из библиотеки \ winnt\system32\drivers\tdi. sys.

Библиотека NDIS (Ndis . sys )

Введем также понятие граничного слоя. Граница – это унифицированный интерфейс между функциональными уровнями в модели сетевой архитектуры. Создание границ как разделов между сетевыми уровнями облегчает третьим фирмам разработку сетевых драйверов и сервисов в среде открытых систем.

Сетевые адаптеры поставляются вместе с сетевыми драйверами, которые раньше часто были рассчитаны на взаимодействие с определенным типом транспортного протокола. Так как Windows NT позволяет загружать драйверы различных транспортных протоколов, то производители сетевых адаптеров, использующие такой подход, должны были писать различные варианты одного и того же драйвера, рассчитанные на связь с разными протоколами транспортного уровня.

Чтобы помочь производителям избежать этого, Windows NT обеспечивает интерфейс и программную среду, называемые "спецификация интерфейса сетевого драйвера " (NDIS), которые экранируют сетевые драйверы от деталей различных транспортных протоколов. Самый верхний уровень драйвера сетевого адаптера должен быть написан в соответствии с рекомендациями NDIS. В этом случае пользователь может работать с сетью TCP/IP и сетью NetBEUI (или DECnet, NetWare, VINES и т. п.), используя один сетевой адаптер и один сетевой драйвер. Среда NDIS использовалась в сетях LAN Manager, но для Windows NT она была обновлена.

Через свою нижнюю границу драйвер сетевого адаптера обычно взаимодействует непосредственно с адаптером или адаптерами, которые он обслуживает. Драйвер сетевого адаптера, реализованный для среды NDIS, управляет адаптером не непосредственно, а использует для этого функции, предоставляемые NDIS (например, для запуска ввода-вывода или обработки прерываний). Таким образом, среда NDIS образует некую оболочку, которая позволяет достаточно просто переносить драйверы сетевых адаптеров из одной ОС в другую. NDIS позволяет сетевым драйверам не содержать встроенных знаний о процессоре или операционной системе, на которых он работает.

Безопасность в сети и доменная структура

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

Корпорация Microsoft включила требования безопасности в состав начальной спецификации для разработки Windows NT. Вопросы безопасности в Windows NT имеют первостепенное значение. Модель безопасности включает компоненты для контроля доступа к объектам (таким как файлы и разделяемые принтеры). Эти компоненты определяют, кто и к каким объектам может получить доступ, какое действие может быть произведено над объектом (например, запись в файл и т. д.), и какие события подлежат аудиту.

Безопасность сети Windows NT включает и доверительные отношения между доменами, что делает эту операционную систему защищенной наилучшим образом.

Архитектура модели безопасности

На рис. 3 показаны компоненты модели безопасности Windows NT, в число которых входят:

1) процессы входа в систему (Logon processes), которые получают от пользователей запросы на вход. Они включают интерактивный вход, который производится с помощью начального диалогового окна входа, и удаленные процессы входа, которые предоставляют удаленным пользователям доступ к процессам сервера Windows NT;

2) локальная служба безопасности (Local Security Authority, LSA), кото­рая следит за тем, чтобы пользователь имел право на доступ (permission) в систему. Этот компонент является центром подсистемы безопасности Windows NT. Он генерирует маркеры доступа (access tokens), управляет локальной политикой безопасности и обеспечивает интерактивную аутентификацию пользователя. Кроме того, LSA контролирует политику аудита и заносит в журнал аудиторские записи, генерируемые монитором безопасности;

3) диспетчер безопасности пользовательских учетных записей (Security Account Manager, SAM), поддерживающий базу данных учетных записей пользова­телей, также известную под названием базы данных каталога (directory database). Эта база данных содержит информацию по всем учетным записям пользователей и групп. SAM обеспечивает сервис проверки пользователей, который используется LSA;

4) монитор безопасности (Security Reference Monitor), который проверяет, имеет ли пользователь разрешение на доступ к объекту и право на операцию, которую он пытается выполнить. Этот компонент принудительным образом осуществляет проверку уровня доступа и проводит политику аудита, определенную LSA. Он обеспечивает сервис для режимов ядра и пользователя, выполняющий проверку наличия необходимого уровня доступа для всех пользователей и процессов, пытающихся получить доступ к объекту. В случае необходимости этот компонент также генерирует записи в файл аудита.

В совокупности все эти компоненты также известны, как подсистема безопасности. Эта подсистема, называемая интегральной подсистемой (integral subsystem), не является подсистемой среды (environmental subsystem), потому что она распространяет свое действие на всю операционную систему Windows NT.

Основные особенности работы файловой системы NFS на платформе UNIX.

Счастье - это когда наши желания совпадают с чужими возможностями.

"Времечко"

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

В настоящее время операционная система UNIX переживает своего рода ренессанс, и во многом она обязана таким подъемом интереса свободно распространяемой ОС Linux. Вместе с тем на настольных компьютерах используются различные варианты Windows, прежде всего, Windows 9x и Windows NT/2000, хотя и здесь постепенно получают гражданство свободно распространяемые разновидности UNIX.

Для многих организаций размещение сетевого файлового сервиса на компьютерах с UNIX является весьма привлекательным решением при условии, что такой сервис имеет достаточную производительность и надежность. Учитывая многочисленные различия в файловых системах UNIX и Windows, прежде всего в схемах именования файлов, особенностях прав доступа, блокировках и системных вызовах при обращении к файлам, особое значение приобретает обеспечение прозрачности доступа в гетерогенной среде UNIX/Windows. Кроме того, нередко файловые серверы UNIX устанавливаются в качестве дополнения к уже имеющимся серверам Windows NT и NetWare.

Для операционной системы UNIX имеются реализации всех более или менее популярных сетевых файловых систем, включая используемых в сетях Microsoft (SMB), NetWare (NCP), Macintosh (AFP). Разумеется, для сетей UNIX существуют свои собственные протоколы, прежде всего, NFS и DFS. Следует иметь в виду, что любой сервер UNIX может одновременно предоставлять услуги NFS и SMB (так же, как NCP и AFP) и таким образом обеспечивает дополнительную гибкость при создании сетевой инфраструктуры.

Несмотря на разнообразие сетевых файловых систем UNIX, безусловными лидерами являются системы NFS (Network File System, дословный перевод - сетевая файловая система) и SMB (Service Message Block). В данной статье речь пойдет о возможностях NFS. Вместе с тем в одном из ближайших номеров мы планируем рассмотреть характеристики работ SMB на платформе UNIX и, в первую очередь, продукт Samba, который хорошо зарекомендовал себя в сетях UNIX/Windows.

ВЕРСИИ NFS

Первая реализация сетевой файловой системы NFS была разработана компанией Sun Microsystems еще в 1985 году. С тех пор NFS получила широкое распространение в мире UNIX, и количество ее инсталляций исчисляется десятками миллионов. Кроме UNIX система NFS как серверная платформа нашла применение в операционных системах VMS, MVS и даже Windows.

NFS является "родной" файловой системой для UNIX и как никакая другая соответствует логике файловых операций UNIX. Это относится к пространству имен файлов и правам доступа. Более того, поддержка NFS изначально встроена в ядро всех популярных версий UNIX-подобных операционных систем.

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

Третья версия NFS была разработана в середине 90-х годов совместными усилиями Sun, IBM, Digital и других компаний с целью повышения производительности, безопасности и удобства администрирования сетевой файловой системы. NFS v3 обратно совместима с предыдущей спецификацией NFS, т. е. сервер NFS v3 может обслуживать не только клиентов NFS v3, но и клиентов NFS v2.

Несмотря на свое достаточно длительное присутствие на рынке, по количеству инсталляций NFS v3 до сих пор уступает NFS v2. Исходя из этих соображений, мы остановимся вначале на основных характеристиках NFS v2, а затем познакомимся с нововведениями в третьей версии NFS.

Следует иметь в виду, что конкретные реализации одной и той же версии NFS могут несколько отличаться друг от друга. Отличия касаются, прежде всего, состава демонов, их имен, местоположения и названия конфигурационных файлов NFS. Кроме того, реализации NFS зависят от возможностей и особенностей самой UNIX. Например, NFS v2 поддерживает списки контроля доступа ACL, но только в тех разновидностях UNIX, где такая поддержка встроена в ядро системы. Поэтому при описании NFS мы будем рассматривать наиболее общий случай.

ПРОТОКОЛЫ NFS V2

На Рисунке 1 представлена сетевая модель NFS v2 в соответствии с эталонной моделью OSI. В отличие от большинства сетевых служб TCP/IP система NFS явным образом использует протоколы презентационного и сеансового уровня. Работа NFS опирается на концепцию вызовов удаленных процедур (Remote Procedure Call, RPC). Согласно этой концепции, при доступе к удаленному ресурсу (например, к файлу) программа на локальном компьютере выполняет обычный системный вызов (предположим, вызов функции открытия файла), но на самом деле процедура выполняется удаленно - на сервере ресурсов. При этом пользовательский процесс не в состоянии определить, как выполняется вызов - локально или удаленно. Установив, что процесс обращается к ресурсу на удаленном компьютере, выступающем в качестве сервера, ядро или специальный демон системы упаковывает аргументы процедуры вместе с ее идентификатором в сетевой пакет, открывает сеанс связи с сервером и пересылает ему данный пакет. Сервер распаковывает полученный пакет, определяет запрашиваемую процедуру и аргументы, а затем выполняет процедуру. Далее сервер пересылает клиенту код возврата процедуры, а тот передает его пользовательскому процессу. Таким образом, RPC полностью соответствует сеансовому уровню модели OSI.

Возникает справедливый вопрос: зачем в сетевой модели NFS нужен специальный протокол презентационного уровня? Дело в том, что Sun благоразумно рассчитывала на применение NFS в гетерогенных сетях, где компьютеры имеют различную системную архитектуру, в том числе различный порядок представления байтов в машинном слове, различное представление чисел с плавающей точкой, несовместимые границы выравнивания структур и т. д. Поскольку протокол RPC предполагает пересылку аргументов процедур, т. е. структурированных данных, то наличие протокола презентационного уровня является насущной необходимостью в гетерогенной среде. В качестве такового выступает протокол внешнего представления данных (eXternal Data Representation, XDR). Он описывает так называемую каноническую форму представления данных, не зависящую от системной архитектуры процессора. При передаче пакетов RPC клиент переводит локальные данные в каноническую форму, а сервер проделывает обратную операцию. Следует иметь в виду, что каноническая форма XDR соответствует представлению данных, принятому для семейства процессоров SPARC и Motorola. В серверах, где реализована аналогичная форма представления данных, это позволяет добиться некоторого (правда, скорее всего, микроскопического) преимущества в производительности над конкурентами в случаях интенсивного обращения к файловому серверу.

В NFS v2 в качестве транспортного протокола был выбран UDP. Разработчики объясняют это тем, что сеанс RPC длится короткий промежуток времени. Более того, с точки зрения выполнения удаленных процедур каждый пакет RPC является самодостаточным, т. е. каждый пакет несет полную информацию о том, что необходимо выполнить на сервере, или о результатах выполнения процедуры. Сервисы RPC обычно не отслеживают состояние связи (connectionless), т. е. сервер не хранит информацию о том, какие запросы клиента обрабатывались в прошлом: например, с какого места файла клиент считывал данные последний раз. Для сетевой файловой системы это определенное преимущество с точки зрения надежности, так как клиент может продолжать файловые операции сразу же после перезагрузки сервера. Но такая схема чревата возникновением проблем при записи и блокировке файлов, и, чтобы их обойти, разработчики NFS были вынуждены применять разные обходные маневры (использование UDP порождает еще один ряд специфических проблем, но их мы коснемся позже).

Важное отличие сервисов RPC, входящих в состав NFS, от других сетевых серверных служб состоит в том, что они не используют супердемон inetd. Рядовые сетевые службы, наподобие telnet или rlogin, обычно не запускаются в виде демонов при старте системы, хотя это делать не возбраняется. Чаще всего они задействуют так называемый супердемон inetd, который "прослушивает" программные порты протоколов TCP и UDP. Службы задаются в конфигурационном файле супердемона (обычно /etc/inetd.conf). При поступлении запроса на программный порт со стороны клиента inetd запускает в качестве дочернего процесса соответствующую сетевую службу (например, in.rlogind), которая и обрабатывает запрос.

Службы RPC не пользуются супердемоном inetd, поскольку, как уже было сказано, сеанс RPC длится очень недолго, фактически лишь в течение обработки одного-единственного запроса. Т. е. для каждого запроса inetd был бы вынужден запускать новый дочерний процесс службы RPC, что весьма накладно для UNIX. По аналогичным соображениям процесс RPC не может порождать новые процессы и не может параллельно обслуживать сразу несколько запросов. Поэтому в целях повышения производительности сервисы RPC запускаются в виде нескольких одновременно работающих экземпляров демонов. При этом количество экземпляров конкретного демона напрямую не связано с количеством клиентов. Даже один демон может обслуживать множество клиентов, но за один раз он способен обрабатывать единственный запрос, остальные будут помещаться в очередь.

Еще одно важное отличие сервисов RPC от обычных сетевых служб состоит в том, что они не используют заранее заданных программных портов UDP. Вместо этого применяется так называемая система трансляции портов portmapper. Для ее поддержки при загрузке системы инициализируется специальный демон portmap. В рамках системы трансляции портов за каждым сервисом RPC закрепляется программный номер (program number), номер версии, номер процедуры (procedure number) и протокол (UDP или TCP). Программный номер однозначно идентифицирует конкретный сервис RPC. Взаимосвязь между именами сервисов RPC и программными номерами можно проследить на основании содержимого файла /etc/rpc. Каждая программа RPC поддерживает множество процедур, которые определяются по их номерам. Номера процедур можно узнать в соответствующих header-файлах: например, для сервиса NFS они задаются в файле /usr/include/nfs/nfs.h.

В частности, сервис NFS имеет программный номер 100003 и включает такие процедуры, как "открытие файла", "чтение блока", "создание файла" и т. д. При вызове удаленных процедур вместе с аргументами процедуры в пакете RPC передается программный номер сервиса, номер процедуры и номер версии. Номер версии служит для идентификации возможностей сервиса. Дело в том, что разработчики постоянно совершенствуют службу NFS, при этом каждая новая версия полностью обратно совместима с предыдущими.

Принцип работы транслятора portmap достаточно прост. При инициализации (в частности, в момент загрузки ОС) какого-либо сервиса RPC он регистрируется с помощью демона portmap. При запуске на сервере сервис RPC ищет незанятый программный порт, резервирует его за собой и сообщает номер порта демону portmap. Для того чтобы связаться с сервером, клиент RPC должен сначала обратиться к portmap сервера и узнать у него, какой программный порт занимает конкретный сервис RPC на сервере. Только затем клиент может непосредственно связаться с сервисом. В некоторых случаях клиент связывается с нужным сервисом косвенным образом, т. е. вначале он обращается к демону portmap, а тот запрашивает сервис RPC от лица клиента. В отличие от сервисов RPC, транслятор портов portmap всегда привязан к заранее заданному порту 111, так что клиент связывается с portmap стандартным способом.

СОСТАВ NFS V2

В общем случае помимо portmap сервер NFS включает демоны rpc.mountd, nfsd, rpc.lockd, rpc.statd. На клиентской машине NFS, функционирующей на платформе UNIX, должны быть запущены демоны biod (необязательно), rpc.lockd и rpc.statd.

Как уже было сказано ранее, поддержка NFS реализована в UNIX на уровне ядра, поэтому не все демоны необходимы, но они способны значительно повысить производительность файловых операций и позволяют осуществлять блокировку файлов при записи.

Демон rpc.mountd обслуживает запросы клиентов на монтирование файловых систем. Сервис монтирования реализован в виде отдельного демона, так как протокол монтирования не является частью NFS. Это вызвано тем, что операция монтирования тесно привязана к синтаксису имен файлов, а принципы именования файлов различаются для UNIX и, скажем, для VMS.

Демон nfsd принимает и обслуживает запросы NFS RPC. Обычно в целях повышения производительности на сервере запускают несколько экземпляров nfsd.

Демон rpc.lockd, функционирующий как на клиенте, так и на сервере, предназначен для блокировки файлов, тогда как демон rpc.statd (также исполняемый на сервере и клиенте) ведет статистику блокировок на случай необходимости их автоматического восстановления при крахе сервиса NFS.

Демон biod, запускаемый на клиенте, способен производить операции "чтение с опережением" и "отложенная запись", что серьезно повышает производительность. Однако наличие biod не является обязательным для работы клиента. Для еще большего повышения производительности на клиентской машине можно загрузить несколько демонов biod.

Еще один демон, выполняющийся на сервере, отвечает за аутентификацию и сервис печати для клиентов DOS/Windows, в некоторых системах он носит имя pcnfsd, в других - in.pcnfsd.

Кроме того, в комплект поставки NFS входят различные системные утилиты и программы диагностики (showmount, rpcinfo, exportfs, nfsstat).

ПРАВИЛА ЭКСПОРТИРОВАНИЯ

Файловые системы и каталоги, которые клиенты могут удаленно монтировать на сервере NFS, должны быть явно заданы. Данная процедура называется в NFS "экспортированием" ресурсов. В то же время сервер NFS, в отличие от, скажем, сервера SMB, не занимается широковещательной рассылкой списка своих экспортируемых ресурсов. Тем не менее клиент может запросить у сервера такой список. На стороне сервера за обслуживание запросов монтирования отвечает демон rpc.mountd.

Экспортирование файловых ресурсов NFS производится в соответствии с четырьмя основными правилами.

1. Файловую систему можно экспортировать как целиком, так и по частям, каковыми являются каталоги и файлы. При этом следует помнить, что самой крупной экспортируемой единицей является файловая система. Если на сервере некая файловая система (/usr/bin) смонтирована по иерархии ниже другой файловой системы (/usr), то экспортирование системы /usr систему /usr/bin не затронет.
2. Экспортировать можно только локальные файловые ресурсы, иными словами, если на сервере смонтирована чужая файловая система, т. е. находящаяся на другом сервере, то ее нельзя реэкспортировать.
3. Нельзя экспортировать подкаталоги уже экспортированной файловой системы, если только они не представляют собой самостоятельных файловых систем.
4. Нельзя экспортировать родительские каталоги уже экспортированного каталога, если только родительский каталог не представляет собой независимую файловую систему.

Любое нарушение этих правил приведет к ошибке в работе NFS.

Таблица экспортируемых ресурсов располагается в файле /etc/exports. К сожалению, синтаксис этого файла зависит от конкретных UNIX, поэтому в качестве примера мы возьмем Solaris. Файл /etc/exports состоит из текстовых строк, имеющих формат:

-,...

Некоторые наиболее популярные опции перечислены в Таблице 1. Фактически опции описывают права доступа к экспортируемым ресурсам со стороны клиентов. Важно помнить, что права доступа, перечисленные при экспортировании, никоим образом не отменяют права доступа, действующие непосредственно в файловой системе. Например, если файловая система экспортируется с возможностью записи, а конкретный файл имеет атрибут "только для чтения", то его изменение будет невозможно. Таким образом, при экспортировании права доступа выступают в качестве дополнительного фильтра. Более того, если, скажем, файловая система экспортируется с опцией ro (read only), то клиент имеет право смонтировать ее с опцией rw (read/write), однако при этом попытка произвести запись приведет к выдаче сообщения об ошибке.

Опция access позволяет указать хосты с правом монтирования ресурса. Соответственно, ни один другой хост, кроме упомянутых в ней, не имеет возможности монтировать, а значит, и проводить операции над ресурсом.

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

Опция root позволяет указать хосты, в которых локальные суперпользователи root получают права root сервера на экспортируемый ресурс. В противном случае, даже если хосту даны права rw, пользователь root на нем приравнивается к пользователю nobody (uid=-2), т. е. к пользователю с минимальными правами доступа. Вышесказанное относится именно к правам доступа к удаленному ресурсу и не влияет на права доступа к локальным ресурсам клиента.

Опции anon и secure будут рассмотрены при описании схемы аутентификации NFS.

ПРАВИЛА МОНТИРОВАНИЯ

Если для сервера экспортируемые ресурсы могут выступать в качестве файловой системы или отдельного каталога, то для клиента они всегда выглядят как файловые системы. Поскольку поддержка NFS встроена в ядро UNIX, то операция монтирования файловых систем NFS производится стандартной утилитой mount (отдельный демон для монтирования NFS не требуется), при этом необходимо лишь оговорить, что монтируемая файловая система - NFS. Еще один способ монтирования - с помощью файла /etc/fstab (/etc/filesystems в некоторых версиях UNIX). В данном случае удаленные системы NFS (так же, как и локальные) монтируются на стадии загрузки ОС. Точки монтирования могут быть любые, в том числе и в составе других файловых систем NFS, т. е. системы NFS можно "нанизывать" друг на друга.

Основные опции монтирования NFS перечислены в Таблице 2.

Опция bg позволяет производить монтирование в фоновом режиме, в этом случае можно запускать другие команды монтирования.

Весьма интересной представляется пара опций hard/soft. При "жестком" монтировании клиент будет пытаться смонтировать файловую систему во что бы то ни стало. Если сервер не работает, это приведет к тому, что весь сервис NFS как бы зависнет: процессы, обращающиеся к файловой системе, перейдут в состояние ожидания окончания выполнения запросов RPC. С точки зрения пользовательских процессов файловая система будет выглядеть как очень медленный локальный диск. При возврате сервера в рабочее состояние сервис NFS будет продолжать функционировать как ни в чем не бывало. Использование опции intr позволяет с помощью системного сигнала INTERRUPT прервать процесс "жесткого" монтирования.

При "мягком" монтировании клиент NFS сделает несколько попыток подключиться к серверу, как оговорено в опциях retans и timeo (некоторыми системами поддерживается также специальная опция retry). Если сервер не откликается, то система выдает сообщение об ошибке и прекращает попытки произвести монтирование. С точки зрения логики файловых операций при отказе сервера "мягкое" монтирование эмулирует сбой локального диска. Если опция retrans (retry) не задана, то количество попыток ограничено значением, принятым по умолчанию для данной системы UNIX. Параметры retrans и timeo относятся не только к монтированию, но и к любым операциям RPC, производимым с файловой системой NFS. Т. е. если клиент осуществляет операцию записи, а в это время в сети или на сервере происходит сбой, то клиент будет пытаться повторить запросы.

На вопрос, какой из режимов, "мягкий" или "жесткий", лучше, однозначно ответить невозможно. Если данные на сервере должны быть согласованы при его временном отказе, то "жесткое" монтирование оказывается предпочтительнее. Этот режим незаменим также в случаях, когда монтируемые файловые системы содержат в своем составе программы и файлы, жизненно важные для работы клиента, в частности для бездисковых машин. В других случаях, особенно когда речь идет о системах "только для чтения", режим "мягкого" монтирования представляется более предпочтительным.

АУТЕНТИФИКАЦИЯ И БЕЗОПАСНОСТЬ

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

В NFS аутентификация производится исключительно на этапе монтирования файловой системы и только на основании доменного имени (или IP-адреса) клиентской машины. Т. е. если клиент NFS (здесь подразумевается компьютер, а не пользователь компьютера) обращается к серверу с запросом на монтирование, то сервер определяет права доступа по таблице /etc/exports, при этом клиент идентифицируется по имени (IP-адресу) компьютера. Если клиенту разрешено производить те или иные операции над экспортируемым ресурсом, то ему сообщается некое "магическое число" (magic cookie). В дальнейшем для подтверждения своих полномочий клиент должен включать это число в каждый запрос RPC.

Вот, собственно, и весь нехитрый набор средств аутентификации клиентов, пользователи же никак не аутентифицируются. Тем не менее каждый запрос RPC содержит идентификатор пользователя uid, инициировавшего запрос, и список идентификаторов групп gid, куда входит пользователь. Но эти идентификаторы используются не для аутентификации, а для определения прав доступа конкретного пользователя к файлам и каталогам.

Обратите внимание, что uid и gid определяются на стороне клиента, а не сервера. Поэтому перед администраторами встает проблема согласования содержимого /etc/passwd (и /etc/group) между клиентами и серверами NFS, чтобы пользователю Васе на сервере не присвоили права пользователя Пети. Для больших сетей это представляет серьезные трудности. Обеспечить согласованность пользовательской базы данных, а также таких системных файлов, как /etc/hosts, /etc/rpc, /etc/services, /etc/protocols, /etc/aliases и др., можно с помощью сетевой информационной службы (Network Information System, NIS), разработанной компанией Sun еще в 1985 году и входящей в состав большинства версий UNIX (более продвинутая ее разновидность NIS+ не нашла широкого применения). NIS представляет собой информационную службу, в первом приближении напоминающую службу каталогов Windows NT, и позволяет централизованно хранить и обрабатывать системные файлы. Между прочим, NIS построена по тому же принципу, что и NFS, в частности она использует протоколы RPC и XDR.

Еще одна важная особенность NFS состоит в том, что в каждом запросе RPC передается список групп gid пользователя. Для ограничения размера пакета RFC в большинстве реализаций NFS количество групп не может превышать 8 или 16. Если пользователь входит в состав большего количества групп, то это может привести к ошибкам при определении прав доступа на сервере. Данная проблема весьма актуальна для корпоративных файловых серверов. Радикальным решением является использование списков контроля доступа ACL, но, к сожалению, далеко не все разновидности UNIX их поддерживают.

Принятая в NFS система аутентификации весьма убога и не обеспечивает надежной защиты. Любой, кто имел дело с NFS, знает, как просто обойти ее систему безопасности. Для этого даже не обязательно применять методы подделки IP-адресов (IP-spoofing) или имен (DNS-spoofing). Злоумышленнику достаточно перехватить "магическое число", и в дальнейшем он может проводить действия от имени клиента. К тому же "магическое число" не меняется до следующей перезагрузки сервера.

На многочисленных серверах Internet можно узнать и другие, в том числе весьма экзотические, способы взлома NFS. Количество обнаруженных "дыр" исчисляется тысячами. Поэтому NFS v.2 рекомендуется использовать только внутри защищенных сетей.

Исходя из этих соображений, Sun разработала протокол SecureRPC с использованием как несимметричных, так и симметричных ключей шифрования. При этом криптографические методы применяются для аутентификации не только хостов, но и пользователей. Однако сами данные не шифруются. К сожалению, из-за экспортных ограничений правительства США не все UNIX поставляются с поддержкой SecureRPC. Поэтому мы не будем останавливаться на возможностях этого протокола. Тем не менее если ваша версия UNIX поддерживает SecureRPC, то неоценимую помощь в его настройке окажет книга Хала Стейна "Managing NFS and NIS" издательства O"Reilly & Assоciates.

Еще одна проблема связана с клиентами NFS на платформах MS-DOS и Windows 3.x/9x. Эти системы являются однопользовательскими, и обычными средствами NFS идентифицировать пользователя невозможно. Для целей идентификации пользователей DOS/Windows на сервере запускается демон pcnfsd. При подключении (монтировании) дисков NFS на клиентской машине он запрашивает имя и пароль пользователя, что позволяет не только идентифицировать, но и аутентифицировать пользователей.

Хотя ОС Windows NT является многопользовательской, но ее пользовательская база данных и схема идентификации пользователей несовместимы с принятой в UNIX. Поэтому клиентские места NFS на базе Windows NT также вынуждены задействовать возможности pcnfsd.

Кроме аутентификации пользователей pcnfs позволяет осуществлять печать на UNIX с клиентских мест DOS/Windows. Правда, в состав Windows NT изначально входит программа LPR.EXE, также позволяющая осуществлять печать на серверах UNIX.

Для доступа к файловому сервису и сервису NFS на машинах DOS/Windows необходимо инсталлировать специальное клиентское ПО, причем цены на эти продукты весьма кусаются.

Вернемся, однако, к опциям экспортирования файлов NFS (см. Таблицу 1). Опция anon определяет идентификатор пользователя uid в том случае, когда пользователь DOS/Windows не мог себя аутентифицировать (задал неверный пароль) или когда пользователь хоста, подключенного по SecureRPC, не прошел аутентификацию. По умолчанию anon имеет uid=-2.

Опция secure применяется, когда используется протокол SecureRPC.

АРХИТЕКТУРНЫЕ ОСОБЕННОСТИ NFS V2

Файловые системы NFS должны подчиняться двум условиям (кстати, эти же требования относятся не только к NFS, но и к другим сетевым файловым системам).

1. С точки зрения клиентских пользовательских программ файловая система NFS располагается как бы на локальном диске. Программы не имеют возможности отличить файлы NFS от обычных файлов.
2. Клиент NFS не в состоянии определить, какая платформа используется в качестве сервера. Это может быть и UNIX, и MVS, и даже Windows NT. Различия в архитектуре серверов сказываются только на уровне конкретных операций, а не в отношении возможностей NFS. Для клиента файловая структура NFS аналогична локальной системе.

Первый уровень прозрачности достигается за счет использования в UNIX виртуальной файловой системы (Virtual File System, VFS). VFS отвечает за взаимодействие не только с NFS, но и с локальными системами наподобие UFS, ext2, VxFS и т. д.

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

Операции над файловыми системами NFS являются операциями VFS, тогда как взаимодействие с отдельными файлами и каталогами определяется операциями vnode. Протокол RPC из состава NFS v2 описывает 16 процедур, связанных с операциями не только над файлами и каталогами, но и над их атрибутами. Важно понимать, что вызовы RPC и интерфейс vnode - разные понятия. Интерфейсы vnode определяют сервисы ОС для доступа к файловым системам независимо от того, локальные они или удаленные. RPC же из состава NFS представляет собой специфическую реализацию одного из интерфейсов vnode.

Операции чтения/записи кэшируются на стороне клиента, т. е. клиент кэширует содержимое файлов и каталогов. Обычно размер буфера кэша NFS составляет 8 Кбайт. Если на клиенте запущены демоны biod, то чтение производится с опережением, а запись осуществляется в отложенном режиме. Например, если пользовательский процесс записывает информацию, то данные накапливаются в буфере кэша и лишь затем производится их пересылка, причем обычно в одном пакете RPC. В момент выполнения операции записи ядро сразу же возвращает управление процессу, а функции пересылки запросов RPC передаются biod. Если же демоны biod не запущены и ядро не поддерживает многопоточной обработки RPC, то пересылкой пакетов RPC в однопоточном режиме должно заниматься ядро, а пользовательский процесс переходит в состояние ожидания окончания пересылки. Но и в этом случае кэш NFS по-прежнему используется.

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

Для обслуживания запросов клиентов на сервере должны быть запущены демоны nfsd. При этом демоны осуществляют кэширование информации при чтении с дисков сервера. Все демоны обслуживают одну и ту же очередь запросов клиентов, что позволяет оптимально использовать ресурсы процессора.

К сожалению, определить оптимальное количество демонов biod и nfsd очень непросто. С одной стороны, чем больше количество работающих демонов, тем большее количество запросов может быть обработано одновременно; с другой стороны, увеличение количества демонов может неблагоприятно повлиять на производительность системы ввиду возрастания накладных расходов на переключение процессов. Тонкая настройка NFS представляет собой весьма утомительную процедуру и требует учета не только количества клиентов и пользовательских процессов, но и таких характеристик, как время переключения между контекстами процессов (т. е. особенности архитектуры процессора), размер оперативной памяти, загрузка системы и т. д. Такие настройки лучше определять экспериментальным путем, хотя в большинстве случаев подойдут и стандартные (обычно на сервере запускают 8 демонов nfsd, а на клиентах - 4 демона biod).

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

При работе в распределенных и глобальных сетях NFS v2 свойственен еще один недостаток вследствие выбора UDP в качестве транспортного протокола для сервиса. Как известно, UDP не гарантирует доставку пакетов, кроме того, порядок приема пакетов может не соответствовать порядку их отправки.

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

Ситуация задержки обработки запросов RPC ввиду, допустим, большой загрузки сервера или проблем в сети также достаточно неприятна. При превышении заданного лимита времени клиент будет считать, что пакет потерян и попытается повторить запрос. Для многих операций NFS это не страшно, так как даже операцию записи сервер может произвести повторно. Но что делать с такими операциями, как "удалить каталог" или "переименовать файл"? К счастью, большинство реализаций NFS поддерживает кэширование дублированных запросов на стороне сервера. Если сервер получил повторный запрос на какую-либо операцию в течение краткого промежутка времени, то такой запрос игнорируется.

Система RPC не отслеживает состояние соединения, что создает проблемы при одновременном обращении нескольких клиентов к одному и тому же файлу. Здесь возникают две сложности:

• как осуществить блокировку файла, в частности при записи в него;
• как гарантировать целостность блокировок в случае краха и перезагрузки сервера или клиента NFS?

Для этого в NFS применяются два специальных демона: rpc.lockd отвечает за блокировку файлов, а rpc.statd - за мониторинг состояния блокировок (см. Рисунок 3). Эти демоны запускаются как на стороне клиента, так и на стороне сервера. За демонами rpc.lockd и rpc.statd закреплены два специальных каталога (sm и sm.bak), где хранится информация по блокировкам.

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

ВОЗМОЖНОСТИ NFS V3

Третья версия NFS полностью обратно совместима со второй версией, т. е. сервер NFS v3 "понимает" клиентов NFS v2 и NFS v3. Аналогично, клиент NFS v3 может обращаться к серверу NFS v2.

Важным нововведением NFS v3 является поддержка транспортного протокола TCP. UDP прекрасно подходит для локальных сетей, но не годится для медленных и не всегда надежных глобальных линий связи. В NFS v3 весь клиентский трафик мультиплексируется в одно соединение TCP.

В NFS v3 размер буфера кэша увеличен до 64 Кбайт, что благотворно повлияло на производительность, особенно в свете активного использования высокоскоростных сетевых технологий Fast Ethernet, Gigabit Ethernet и ATM. Кроме того, NFS v3 позволяет хранить кэшируемую на клиенте информацию не только в оперативной памяти, но и на локальном диске клиента (справедливости ради, стоит отметить, что некоторые реализации NFS v2 тоже предусматривают такую возможность). Такая технология известна как CacheFS.

Но, пожалуй, еще более важным новшеством NFS v3 можно считать радикальное увеличение производительности на операциях записи. Теперь кэширование записываемой информации производится также на стороне сервера, при этом регистрация и подтверждение факта записи данных на диск осуществляются с помощью специального запроса commit (см. Рисунок 4). Эту технологию называют безопасной асинхронной записью. После того как данные пересланы в кэш сервера, клиент посылает ему запрос commit, инициирующий операцию записи на диск сервера. В свою очередь по окончании записи информации на диск сервер отправляет клиенту подтверждение ее успешного завершения.

Новым в NFS v3 является поддержка 64-разрядных файловых систем и улучшенная поддержка списков контроля доступа ACL.

Что касается перспектив, то сейчас Sun продвигает технологию WebNFS, использование которой позволяет получить доступ к файловым системам из любого браузера Web или через приложения, написанные на Java. При этом никакого клиентского ПО устанавливать не требуется. WebNFS (по утверждению Sun) дает выигрыш в производительности по сравнению с ftp или HTTP в три-пять раз.

ЗАКЛЮЧЕНИЕ

Зная принципы работы протоколов NFS, администратор может произвести оптимальную настройку сервиса. Сетевая файловая система NFS идеально подходит для сетей UNIX, так как поставляется практически со всеми версиями этой ОС. Более того, поддержка NFS реализована на уровне ядра UNIX. Поскольку Linux начинает постепенно набирать вес на уровне настольных компьютеров, то NFS имеет шансы завоевать признание и здесь. К сожалению, использование NFS на клиентских компьютерах с Windows создает определенные проблемы, связанные с необходимостью установки специализированного и довольно дорогого клиентского ПО. В таких сетях применение сервиса SMB, в частности ПО Samba, выглядит более предпочтительным. Впрочем, к продуктам SMB для UNIX мы вернемся в одном из ближайших номеров LAN.

В этой главе мы рассмотрим сетевую файловую систему ( NFS - Network File System), популярное приложение, которое предоставляет приложениям клиентов прозрачный доступ к файлам. Краеугольным камнем NFS является Sun RPC: вызов удаленной процедуры (Remote Procedure Call), что мы и опишем в первую очередь.

Программе клиента не требуется специальных средств, чтобы воспользоваться NFS. Ядро определяет что файл находится на NFS сервере и автоматически генерирует RPC вызов, для того чтобы получить доступ к файлу.

Мы не будем подробно рассматривать, как реализуется доступ к файлам, а рассмотрим, как при этом используются протоколы Internet, особенно UDP.

В большинстве случаев задачи сетевого программирования решаются путем написания программ приложений, которые вызывают функции, предоставляемые системой, чтобы осуществить конкретные сетевые операции. Например, одна функция осуществляет активное открытие TCP, другая пассивное открытие TCP, третья посылает данные по TCP соединению, четвертая устанавливает конкретные опции протокола (включает TCP таймер "оставайся в живых") и так далее. В разделе "Интерфейсы прикладного программирования" главы 1 мы упоминали, что существует два популярных набора функций для сетевого программирования (прикладной программный интерфейс, API), это сокеты и TLI. Программный интерфейс, используемый клиентом, и программный интерфейс, используемый сервером, могут отличаться, так же как и операционные системы, которые функционируют у клиента и сервера. Именно коммуникационный и прикладной протоколы определяют, сможет ли конкретный клиент общаться с сервером. Unix клиент, написанный на C, использующий сокеты в качестве программного интерфейса, и TCP - в качестве коммуникационного протокола, может общаться с сервером на мейнфрейме, написанным на COBOLе с использованием других API и TCP, если оба хоста подключены к сети и оба имеют реализацию TCP/IP.

Обычно клиент посылает серверу команды, а сервер отправляет клиенту отклики. Все рассмотренные нами приложения, - Ping, Traceroute, демоны маршрутизации, клиенты и сервера DNS, TFTP, BOOTP, SNMP, Telnet, FTP, SMTP - все построены именно таким образом.

RPC, вызов удаленной процедуры, реализует иной подход к сетевому программированию. Программа клиента просто вызывает функции в программе сервера. Так это решено с точки зрения программиста, однако в действительности имеет место следующая последовательность действий.

1. Когда клиент вызывает удаленную процедуру, вызывается функция на локальном хосте, которая сгенерирована пакетом RPC. Эта функция называется client stub. client stub упаковывает аргументы процедуры в сетевое сообщение и отправляет сообщение серверу.
2. server stub на хосте сервера получает сетевое сообщение. Аргументы извлекаются из сетевого сообщения, и осуществляется вызов процедуры сервера, написанной прикладным программистом.
3. Функция сервера возвращает управление server stubу, который, в свою очередь, принимает полученные значения, упаковывает их в сетевое сообщение и отправляет сообщение обратно к client stub.
4. client stub возвращает приложению клиента значения из сетевого сообщения.

Сетевое программирование, использующее stubы и библиотечные RPC подпрограммы использует интерфейсы прикладного программирования API (сокеты или TLI), однако пользовательские приложения (программа клиента и процедуры сервера, вызываемые клиентом) никогда не обращаются к API. Приложению клиента достаточно вызывать процедуру сервера, при этом все детали реализации спрятаны пакетом RPC, client stubом и server stubом.

Пакеты RPC имеют следующие положительные стороны.

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

Программирование RPC подробно описано в главе 18 . Два наиболее популярных RPC пакета это Sun RPC и RPC пакет в Open Software Foundation"s ( OSF) Distributed Computing Environment ( DCE). Мы рассмотрим, как осуществляется вызов процедуры, как выглядит возвращаемое сообщение и как это соотносится с пакетом Sun RPC, так как именно этот пакет используется в сетевой файловой системе. Версия 2 Sun RPC описана в RFC 1057 [ Sun Microsystems 1988a].

Существует два вида Sun RPC. Одна версия построена с использованием API сокет и работает с TCP и UDP. Другая называется TI-RPC (независимо от транспорта - transport independent), построена с использованием TLI API и работает с любыми транспортными уровнями, предоставляемыми ядром. С нашей точки зрения между ними нет никакой разницы, так как в этой главе мы рассматриваем только TCP и UDP.

На рисунке 29.1 показан формат сообщения вызова процедуры RPC, с использованием UDP.

На данный момент в вашем распоряжении должно быть работающее TCP/IP-подключение к вашей сети. Вы должны быть в состоянии пинговать другие компьютеры сети и, если вы соответствующим образом настроили шлюз, вы также должны быть в состоянии пинговать компьютеры в Интернете. Как известно, главной целью подключения компьютера к сети, является получение доступа к информации. Хотя некоторые люди могут подключать компьютер к сети просто так, большинство людей хотели бы предоставлять и получать доступ к файлам и принтерам. Они хотели бы получать доступ к документам в Интернете или играть в онлайновые игры. Установив в свою новую систему Slackware поддержку TCP/IP и необходимое программное обеспечение, вы всё это получите; однако, установив только поддержку TCP/IP, функциональность будет очень ограниченной. Чтобы предоставлять и получать общий доступ к файлам, нам потребуется переносить их туда и обратно, используя FTP или SCP. Мы не можем посматривать на нашем новой компьютере со Slackware дерево файлов через значки “Сетевое окружение” или “Вся сеть” с Windows-компьютеров. Мы хотели бы иметь возможность иметь постоянный доступ к файлам на других Unix-машинах.

В идеале мы хотели бы использовать сетевую файловую систему , позволяющую нам иметь прозрачный доступ к файлам на компьютерах. Программам, которые мы используем для работы с информацией, хранимой на компьютерах, на самом деле даже не надо знать на каком компьютере хранится нужный файл. Им нужно только знать, что этот файл существует, и способ для его получения. Дальнейшее уже является задачей операционной системы, обеспечивающей доступ к этому файлу с помощью доступных локальных и сетевых файловых систем. Две наиболее часто используемые сетевые файловые системы - это SMB (реализованная через Samba) и NFS.

5.6.1. SMB/Samba/CIFS

SMB (Server Message Block, блок серверных сообщений) - это потомок более старого протокола NetBIOS, изначально разработанного в IBM для их продукта LAN Manager. Компанию Microsoft в свою очередь всегда интересовал NetBIOS и его наследники (NetBEUI, SMB и CIFS). Проект Samba начал своё существование в 1991 году, когда он был написан для обеспечения связи между IBM PC и сервером Unix. Сегодня предоставление общего доступа к файлам и службам печати через сеть SMB является предпочитаемым методом практически для всего цивилизованного мира, поскольку его поддерживает и Windows.

Конфигурационный файл Samba /etc/samba/smb.conf является одним из самых хорошо документированных конфигурационных файлов, которые вы сможете найти. К вашим услугам уже готовые примеры с настройками общих ресурсов, так что вы можете просмотреть и изменить их согласно своим потребностям. Если же вам нужен ещё больший контроль, к вашим услугам страница руководства smb.conf. Поскольку Samba имеет такую хорошую документацию, мы не будем её здесь переписывать. Однако быстро остановимся на основных моментах.

smb.conf разбит на несколько разделов: по одному разделу на общий ресурс плюс один глобальный раздел для настройки параметров, которые используются везде. Некоторые параметры являются действительными только в глобальном разделе, а некоторые верны только за его пределами. Помните, что глобальный раздел может быть переопределён любым другим разделом. За дополнительной информацией обращайтесь к страницам руководства.

Вы скорее всего захотите отредактировать свой файл smb.conf, чтобы отразить в нём параметры своей локальной сети. Советуем вам изменить перечисленные ниже пункты:

Это будет описание вашего компьютера Slackware, показываемое в папке Сетевое окружение (или Вся сеть).

Вы почти наверняка захотите использовать в своей системе Slackware уровень безопасности user.

Если шифрование паролей не включено, вы не сможете использовать Samba с системами NT4.0, Win2k, WinXP и Win2003. Для предыдущих версий операционных систем Windows для предоставления доступа к общим ресурсам шифрование не требовалось.

SMB является протоколом с аутентификацией, т.е. вы можете указать имя пользователя и пароль, чтобы воспользоваться возможностями этой службы. Мы сообщаем серверу samba о том, что имена пользователей и пароли верны, посредством команды smbpasswd. smbpasswd допускает использование общих ключей для добавления как обычных пользователей, так и машин-пользователей (для SMB необходимо, чтобы вы добавили NETBIOS-имена компьютеров как машин-пользователей, ограничивая тем самым круг компьютеров, с которых может осуществляться аутентификация).

Важно учесть, что данное имя пользователя или имя машины должно уже существовать в файле /etc/passwd. Вы можете добиться этого с помощью команды adduser. Обратите внимание, что при использовании команды adduser для добавления имени компьютера к нему необходимо добавить знак доллара (“$”). Однако этого не нужно делать при работе с smbpasswd. Утилита smbpasswd самостоятельно добавляет знак доллара. Нарушение этого правила посредством adduser приведёт к ошибке при добавлении имени машины в samba.

5.6.2. Сетевая файловая система (NFS)

NFS (Network File System) изначально была написана компанией Sun для Solaris - их реализации системы Unix. И хотя её значительно легче поднять и настроить по сравнению с SMB, NFS гораздо менее безопасна. Главным слабым местом в безопасности является несложность подмены идентификаторов пользователя и группы одной машины на идентификаторы с другой машины. В протоколе NFS не реализована аутентификация. Было заявлено, что в будущих версиях протокола NFS безопасность будет повышена, однако на время написания этой книги это ещё не было сделано.

Настройка NFS осуществляется через файл /etc/exports. Когда вы загрузите стандартный файл /etc/exports в редактор, вы увидите пустой файл с комментарием вверху на две строки. Нам надо будет добавить строку в файл exports для каждого из каталогов, которые мы хотим экспортировать, с перечнем клиентских рабочих станций, которым будет разрешён доступ к этому каталогу. Например, если нам нужно экспортировать каталог /home/foo для рабочей станции Bar, нам надо будет добавить в наш файл /etc/exports такую строку:

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

NFS полагает, что заданный пользователь с одной из машин в сети имеет один и тот же идентификатор на всех остальных машинах. Когда NFS-клиент делает попытку чтения или записи на NFS-сервер, UID передаётся как часть запроса на чтение/запись. Этот UID считается таким же, как если бы запрос был выполнен с локальной машины. Как видите, если кто-то сможет произвольным образом указать заданный UID при обращении к ресурсам на удалённой машине, неприятности могут случиться и случаются. Средство, отчасти позволяющее избежать этого, заключается в монтировании всех каталогов с параметром root_squash . Это переопределяет UID любого пользователя, объявившего себя root"ом, на другой UID, предотвращая таким образом root"овый доступ к файлам и каталогам в экспортируемом каталоге. Похоже, что root_squash включается по умолчанию по соображениям безопасности, однако авторы всё равно рекомендуют явно указывать его в своём файле /etc/exports.

Вы также можете экспортировать каталог на сервере непосредственно из командной строки, воспользовавшись командой exportfs, как показано ниже:

Эта команда экспортирует каталог /home/foo для компьютера “Bar” и предоставляет ему доступ на чтение/запись. Кроме того на сервере NFS не включен параметр root_squash , означающий, что любой пользователь на Bar с UID “0” (UID root"а) будет иметь на сервере те же привилегии, что и root. Синтаксис выглядит довольно странно (обычно, когда вы указываете каталог в виде computer:/directory/file, вы ссылаетесь на файл в каталоге на заданном компьютере).

Дополнительную информацию о файле exports вы найдёте в странице руководства.

Каждый знает, что в UNIX-системах файловая система логически представляет собой набор физических файловых систем, подключенных к одной точке. Одна из самых основных прелестей такой организации, на мой взгляд, состоит в возможности динамически модифицировать структуру существующей файловой системы. Также, благодаря усилиям разработчиков, мы на сегодняшний день имеем возможность подключить ФС практически любого типа и любым удобным способом. Говоря «способом», я прежде всего хочу подчеркнуть возможность работы ядра ОС с файловыми системами посредством сетевых соединений.

Множество сетевых протоколов предоставляют нам возможность работы с удаленными файлами, будь то FTP, SMB, Telnet или SSH. Благодаря способности ядра, в конечном итоге, не зависеть от типа подключаемой ФС, мы имеем возможность при помощи программы mount подключать что угодно и как угодно.

Сегодня мне хочется рассказать об NFS — Network File System. Эта технология позволяет подключать отдельные точки ФС на удаленном компьютере к файловой системе локального компьютера. Сам протокол NFS позволяет выполнять операции с файлами достаточно быстро, безопасно и надежно. А что нам еще нужно? :-)

Что необходимо для того, чтобы это работало

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

Установка

Для запуска сервера NFS в моей Ubuntu 7.10 — the Gutsy Gibbon понадобилось установить пакеты nfs-common и nfs-kernel-server. Если же нужен только клиент NFS, то nfs-kernel-server устанавливать не нужно.

Настройка сервера

После того, как все пакеты успешно установлены, необходимо проверить, запущен ли демон NFS:

/etc/init.d/nfs-kernel-server status

Если демон не запущен, его нужно запустить командой

/etc/init.d/nfs-kernel-server start

После того, как все успешно запустилось, можно приступать к экспорту файловой системы. Сам процесс очень прост и занимает минимум времени.

Основной файл конфигурации NFS-сервера располагается в /etc/exports и имеет следующий формат:

Directory machine1(option11,option12) machine2(option21,option22)

directory — абсолютный путь к каталогу ФС сервера, к которому нужно дать доступ

machineX — DNS-имя или IP-адрес клиентского компьютера, с которого разрешается доступ

optionXX — параметры экспорта ФС, наиболее часто используемые из них:

• ro — доступ к файлам разрешается только для чтения
• rw — доступ предоставляется на чтение/запись
• no_root_squash — по умолчанию, если вы подключаетесь к ресурсу NFS от имени root, сервер, безопасности ради, на своей стороне будет обращаться к файлам от имени пользователя nobody. Однако, если включить эту опцию, то обращение к файлам на стороне сервера будет будет производиться от имени root. Аккуратней с этой опцией.
• no_subtree_check — по умолчанию, если вы на сервере экспортируете не весь раздел, а только часть ФС, демон будет проверять, является ли запрошенный файл физически размещенным на том же разделе или нет. В случае, если вы экспортируете весь раздел или точка подключения экспортируемой ФС не затрагивает файлы с других физических томов, то можно включить эту опцию. Это даст вам увеличение скорости работы сервера.
• sync — включайте эту опцию, если есть вероятность внезапного обрыва связи или отключения питания сервера. Если эта опция не включена, то очень повышается риск потери данных при внезапной остановке сервера NFS.

Итак, допустим, нам нужно дать доступ компьютеру ashep-desktop к каталогу /var/backups компьютера ashep-laptop. Доступ к каталогу необходим для копирования резервных копий файлов с ashep-desktop. У меня файл получился следующим:

/var/backups ashep-desktop(rw,no_subtree_check,sync)

После добавления строки в /etc/exports необходимо перезапустить сервер NFS для вступления изменений в силу.

/etc/init.d/nfs-kernel-server restart

Вот и все. Можно приступать к подключению экспортированной ФС на клиентском компьютере.

Настройка клиента

На клиентской стороне удаленная файловая система монтируется так же, как и все остальные — командой mount. Также, никто не запрещает вам использовать /etc/fstab в случае, если подключать ФС нужно автоматически при загрузке ОС. Итак, вариант с mount будет выглядеть так:

Mount -t nfs ashep-laptop:/var/backups/ /mnt/ashep-laptop/backups/

Если все прошло успешно и вам необходимо выполнять подключение к удаленной ФС автоматически при загрузке — просто добавляем строку в /etc/fstab:

Ashep-laptop:/var/backups /mnt/ashep-laptop/backups nfs auto 0 0

Что еще

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