Сетевые файловые системы. Протокол NFS

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

Это протокол распределенной файловой системы, первоначально разработанный компанией Sun Microsystems в 1984 году, позволяющий пользователю на клиентском компьютере получать доступ к файлам через сеть, подобно доступу к локальному хранилищу. NFS, как и многие другие протоколы, основывается на системе Open Network Computing Remote Procedure Call (ONC RPC).

Другими словами, что такое NFS? Это открытый стандарт, определенный в Request for Comments (RFC), позволяющий любому реализовать протокол.

Версии и вариации

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

NFS v2

Версия 2 первоначально работала только по протоколу User Datagram Protocol (UDP). Ее разработчики хотели сохранить серверную сторону без блокировки, реализованной за пределами основного протокола.

Интерфейс виртуальной файловой системы позволяет выполнять модульную реализацию, отраженную в простом протоколе. К февралю 1986 года были продемонстрированы решения для таких операционных систем, как System V release 2, DOS и VAX/VMS с использованием Eunice. NFS v2 позволял считывать только первые 2 ГБ файла из-за 32-разрядных ограничений.

NFS v3

Первое предложение по разработке NFS версии 3 в Sun Microsystems было озвучено вскоре после выпуска второго дистрибутива. Главной мотивацией была попытка смягчить проблему производительности синхронной записи. К июлю 1992 года практические доработки позволили решить многие недостатки NFS версии 2, оставив при этом лишь недостаточную поддержку файлов (64-разрядные размеры и смещения файлов).

• поддержку 64-битных размеров и смещений файлов для обработки данных размером более 2 гигабайт (ГБ);
• поддержку асинхронной записи на сервере для повышения производительности;
• дополнительные атрибуты файлов во многих ответах, позволяющие избежать необходимости их повторного извлечения;
• операцию READDIRPLUS для получения данных и атрибутов вместе с именами файлов при сканировании каталога;
• многие другие улучшения.

Во время введения версии 3 поддержка TCP как протокола транспортного уровня начала увеличиваться. Использование TCP в качестве средства передачи данных, выполненного с использованием NFS через WAN, стало позволять передавать большие размеры файлов для просмотра и записи. Благодаря этому разработчики смогли преодолеть пределы ограничений в 8 КБ, налагаемые протоколом пользовательских дейтаграмм (UDP).

Что такое NFS v4?

Версия 4, разработанная под влиянием Эндрской файловой системы (AFS) и блока сообщений сервера (SMB, также называемая CIFS), включает в себя повышение производительности, обеспечивает лучшую безопасность и вводит протокол с соблюдением установленных условий.

Версия 4 стала первым дистрибутивом, разработанным в Целевой группе Internet Engineering Task Force (IETF) после того, как Sun Microsystems передала разработку протоколов сторонним специалистам.

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

Новейший протокол файловой системы - NFS 4.2 (RFC 7862) - был официально выпущен в ноябре 2016 года.

Другие расширения

С развитием стандарта появились и соответствующие инструменты для работы с ним. Так, WebNFS, расширение для версий 2 и 3, позволяет протоколу сетевого доступа к файловым системам легче интегрироваться в веб-браузеры и активировать работу через брандмауэры.

Различные протоколы сторонних групп стали также ассоциироваться с NFS. Из них наиболее известными выступают:

• Network Lock Manager (NLM) с поддержкой протокола байтов (добавлен для поддержки API-блокировки файлов UNIX System V);
• удаленной квоты (RQUOTAD), который позволяет пользователям NFS просматривать квоты на хранение данных на серверах NFS;
• NFS через RDMA - адаптация NFS, которая использует дистанционный прямой доступ к памяти (RDMA) в качестве средства передачи;
• NFS-Ganesha - сервер NFS, работающий в пользовательском пространстве и поддерживающий CephFS FSAL (уровень абстракции файловой системы) с использованием libcephfs.

Платформы

Network File System часто используется с операционными системами Unix (такими как Solaris, AIX, HP-UX), MacOS от Apple и Unix-подобными ОС (такими как Linux и FreeBSD).

Он также доступен для таких платформ, как Acorn RISC OS, OpenVMS, MS-DOS, Microsoft Windows, Novell NetWare и IBM AS/400.

Альтернативные протоколы удаленного доступа к файлам включают в себя блок сообщений сервера (SMB, также называемый CIFS), протокол передачи Apple (AFP), базовый протокол NetWare (NCP) и файловую систему сервера OS/400 (QFileSvr.400).

Это связано с требованиями NFS, которые ориентированы по большей части на Unix-подобные «оболочки».

При этом протоколы SMB и NetWare (NCP) применяются чаще, чем NFS, в системах под управлением Microsoft Windows. AFP наиболее широко распространен в платформах Apple Macintosh, а QFileSvr.400 наиболее часто встречается в OS/400.

Типичная реализация

Предполагая типичный сценарий в стиле Unix, в котором одному компьютеру (клиенту) нужен доступ к данным, хранящимся на другом (сервер NFS):

• Сервер реализует процессы Network File System, запущенные по умолчанию как nfsd, чтобы сделать свои данные общедоступными для клиентов. Администратор сервера определяет, как экспортировать имена и параметры каталогов, обычно используя файл конфигурации/etc/exports и команду exportfs.
• Администрирование безопасности сервера гарантирует, что он сможет распознавать и утверждать проверенного клиента. Конфигурация его сети гарантирует, что соответствующие клиенты могут вести переговоры с ним через любую систему брандмауэра.
• Клиентская машина запрашивает доступ к экспортированным данным, как правило, путем выдачи соответствующей команды. Она запрашивает сервер (rpcbind), который использует порт NFS, и впоследствии подключается к нему.
• Если все происходит без ошибок, пользователи на клиентской машине смогут просматривать и взаимодействовать с установленными файловыми системами на сервере в пределах разрешенных параметров.

Следует обратить внимание и на то, что автоматизация процесса Network File System также может иметь место - возможно, с использованием etc/fstab и/или иных подобных средств.

Развитие на сегодняшний день

К 21-му столетию протоколы-конкуренты DFS и AFS не достигли какого-либо крупного коммерческого успеха по сравнению с Network File System. Компания IBM, которая ранее приобрела все коммерческие права на вышеуказанные технологии, безвозмездно передала большую часть исходного кода AFS сообществу свободных разработчиков программного обеспечения в 2000 году. Проект Open AFS существует и в наши дни. В начале 2005 года IBM объявила о завершении продаж AFS и DFS.

В свою очередь, в январе 2010 года компания Panasas предложила NFS v 4.1 на основе технологии, позволяющей улучшить возможности параллельного доступа к данным. Протокол Network File System v 4.1 определяет метод разделения метаданных файловой системы из местоположения определенных файлов. Таким образом, он выходит за рамки простого разделения имен/данных.

Что такое NFS этой версии на практике? Вышеуказанная особенность отличает его от традиционного протокола, который содержит имена файлов и их данных под одной привязкой к серверу. При реализации Network File System v 4.1 некоторые файлы могут распределяться между многоузловыми серверами, однако участие клиента в разделении метаданных и данных ограничено.

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

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

Основные особенности работы файловой системы 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.

На данный момент в вашем распоряжении должно быть работающее 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 вы найдёте в странице руководства.

1.4 Сетевая файловая система

Файловая система CIFS доминирует на рынке сетевых файловых систем для платформы Windows. На платформе UNIX основной является сетевая файловая система (Network File System - NFS). Кроме того, NFS считается первой широко распространенной файловой системой, что произошло еще в середине 1980-х годов. Однако, несмотря на некоторые общие функциональные возможности CIFS и NFS (это сетевые файловые системы, позволяющие клиентам получать доступ к ресурсам серверов), эти системы имеют совершенно различные архитектурные особенности. С выходом NFS версии 4 некоторые различия были пересмотрены.
Протокол CIFS сохраняет сервисные данные, относящиеся к каждому клиенту. До версии 3 файловая система NFS не сохраняла статус клиента, что изменилось в версии 4.
Клиент NFS не "договаривается" с сервером NFS об установлении сеанса. Меры безопасности предпринимаются для всего сеанса или каждой операции обмена данными между клиентом и сервером. Реализация последнего варианта чрезмерно дорогостоящая, поэтому NFS возлагает задачу обеспечения безопасности на клиента. Сервер "предполагает", что идентификаторы поль¬зователя на клиентских и серверной системах совпадают (а клиент проверил личность пользователя перед тем, как дать ему зарегистрироваться под указанным идентификатором). Кроме того, NFS обеспечивает определенный уровень безопасности, контролируя список файловых систем, которые может монтировать клиент. Каждый раз, когда клиент CIFS открывает файл, получает дескриптор файла (т.е. сервисные данные, которые должен сохранять сервер) и использует его для проведения операций чтения или записи на стороне клиента, сервер NFS запрашивает сервер, который возвращает дескриптор файла. Этот дескриптор файла обрабатывается клиентами, поддерживающими стандарты NFS 3 и NFS 2. Клиент кэширует полученный дескриптор файла и ожидает, что дескриптор всегда будет указывать на один и тот же файл.
Для тех, кто знаком с UNIX, можно отметить, что дескриптор файла обычно состоит из номера inode (inode number), счетчика поколения inode (inode generation count) и идентификатора файла, который связан с разделом диска. Достаточно сказать, что inode представляет собой исключительно важную структуру данных, которая используется в файловых системах UNIX. Для удаления дескрипторов, кэшированных клиентами, хранится достаточный объем информации, необходимой, если соответствующий дескриптору файл изменился и дескриптор должен указывать на другой файл. Например, если файл удален и на его место скопирован файл с таким же именем, счетчик поколения inode будет изменен и кэшированный клиентом дескриптор файла окажется недействительным. Файловая система NFS 4 имеет отличия в реализации.
Некоторые клиенты NFS проводят кэширование на стороне клиента, храня данные на дисках, что напоминает кэширование в CIFS. Также некоторые клиенты NFS меняют значение тайм-аутов в зависимости от времени отклика сервера. Чем медленнее отзывается сервер, тем больше значение тайм-аута, и наоборот.
Файловая система NFS проектировалась, как независящая от транспорта и изначально использовала транспортный протокол UDP. Различные типы NFS могут использовать протокол TCP и другие протоколы.

1.4.1 Сетевая файловая система, версия 3

Файловая система NFS 3 позволяет увеличить быстродействие, особенно для больших файлов, разрешая клиенту и серверу динамически выбирать максимальный объем данных, которые передаются в одном логическом элементе пакета при записи или чтении. В файловой системе NFS 2 на размер пакета накладывалось ограничение в 8 Кбайт. Другими словами, клиент мог отправить максимум 8 Кбайт в запросе на запись, а сервер - максимум 8 Кбайт в ответе на запрос чтения. Кроме того, в NFS 3 переопределены смещения в файлах и размеры данных. Теперь это 64-разрядные значения, вместо 32-разрядных в NFS 2.
Далее представлены некоторые особенности NFS 3.
■ В дескрипторах файлов в NFS 3 указан переменный размер; их максимальных размер составляет 64 бит.
■ Файловая система NFS 3 позволяет клиентам и серверам выбирать максимальный размер имен файлов и каталогов.
■ В NFS 3 определяется список ошибок, которые сервер может возвращать клиентам. Сервер должен вернуть одну из определенных ошибок или не возвращать ошибку вообще.
■ В NFS 3 серверу разрешено кэшировать данные, которые клиент отправил вместе с запросом на запись. Сервер может кэшировать данные и отправлять клиенту ответ на запрос еще до того, как данные будут записаны на диск. Также добавлена команда COMMIT, которая позволяет клиенту убедиться, что все отправленные данные были записаны на диск. Это дает возможность соблюсти баланс между повышением производительности и сохранением целостности данных.
■ В NFS 3 сокращено количество операций запрос/ответ между клиентом и сервером. Для этого данные об атрибутах файла отправляются вместе с первоначальным запросом. В NFS 2 от клиента требовалось получение имен файлов и дескриптора для каждого файла, только после этого передавались атрибуты файла.

1.4.2 Сетевая файловая система, версия 4

В NFS 4 полностью пересмотрены основополагающие принципы и реализовано много функций, характерных для CIFS, что весьма расстроило некоторых апологетов NFS. Если посмотреть на историю сетевых файловых систем, то можно увидеть, что NFS получила широкое распространение. Файловая система SMB разрабатывалась с учетом сильных и слабых сторон NFS и теперь, по крайней мере в среде клиентов, CIFS/SMB распространены больше, a NFS развивается, учитывая все недостатки и преимущества CIFS/SMB. Ниже рассматриваются возможности, которые были добавлены в NFS 4 для повышения быстродействия и безопасности, а также для улучшения взаимодействия с CIFS.
■ В NFS 4 появился запрос COMPOUND, который позволяет запаковывать несколько запросов в один запрос и несколько ответов в один ответ. Это нововведение предназначено для повышения производительности за счет снижения нагрузки на сеть и сокращения задержек при передаче запросов и ответов по сети. Если это несколько напоминает функцию CIFS AndX SMB (см. раздел 3.3.5.1), то, возможно, дело не в обычном совпадении.
■ Сетевая файловая система версии 4 заимствовала некоторые возможности у WebNFS, созданной компанией Sun. В частности, в NFS 4 некоторые вторичные протоколы поддерживаются в базовой спецификации, что делает NFS более подходящей для применения вместе с брандмауэрами. В NFS 3 и более ранних версиях использовался специальный протокол для монтирования общего ресурса сервера в дерево локальной файловой системы. Поскольку служба протокола монтирования не имела назначенного порта TCP или UDP, клиент сначала отправлял запрос службе отображения портов (portmapper daemon), предоставляющей номер порта, посредством которого ожидает запросов служба монтирования. Таким образом, кроме NFS, в процессе принимали участие протоколы монтирования и отображения портов. Более того, так как служба монтирования могла использовать произвольный порт, настройка брандмауэра весьма усложнялась. В NFS 4 протоколы монтирования и отображения портов были исключены. Кроме того, блокирование было включено в базовую спецификацию протокола NFS, а протокол NLM (Network Lock Manager), который применялся в более ранних версиях NFS, окончательно устарел.
■ Файловая система NFS 4 требует использования транспортного протокола, который предоставляет возможность обнаружения "заторов" в сети. Это значит, что клиенты и серверы NFS постепенно будут переходить к протоколу TCP вместо UDP, который обычно используется вместе с NFS 3.
■ В NFS 2 и NFS 3 допускалось использование набора символов U.S. ASCII или ISO Latin 1. Это приводило к возникновению проблем, когда клиент, использующий один набор символов, создавал файл и к этому файлу получал доступ клиент с другим набором символов. В NFS 4 используется набор символов UTF-8, который поддерживает компактное сжатие 16- и 32-разрядных символов для их передачи по сети. Кроме того, набор символов UTF-8 содержит достаточный объем информации, чтобы избежать проблем при создании файла посредством одного набора символов и получении доступа к файлу с другим набором.
■ Файловая система NFS 4 требует от клиента отдельной обработки дескрипторов файлов. В NFS 3 клиент мог кэшировать дескриптор в качестве объекта, в то время как сервер заботился о том, чтобы дескриптор всегда указывал на файл. В NFS 4 определены два типа файловых дескрипторов. Один называется постоянные дескрипторы файлов и обладает возможностями дескрипторов файлов из NFS 3. Второй - временные дескрипторы файлов - предполагает истечение срока действия дескриптора после определенного промежутка времени или события. Это функция для серверов, файловые системы которых (например, NTFS) не могут обеспечить постоянного соответствия между отображаемыми файлами и дескрипторами.
■ В NFS 4 добавлена поддержка операций OPEN и CLOSE, семантика которых допускает взаимодействие с клиентами CIFS. Команда OPEN создает данные состояния на сервере.
■ Поддержка запроса OPEN в NFS 4 позволяет клиенту осуществлять запрос на открытие файла, структура которого будет аналогична запросам на открытие приложений Windows. Также поддерживается выбор совместного использования файла с другими клиентами или эксклюзивный доступ к файлу.

1.4.2.1 Безопасность NFS 4

Файловая система NFS 4 позволяет усилить безопасность хранимых данных. В частности, в NFS 4 добавлена поддержка большего количества атрибутов файла. К одному из этих атрибутов относится список управления доступом (ACL) в стиле Windows NT. Это позволяет улучшить взаимодей¬ствие между файловыми системами и укрепить структуру безопасности.
В то время как в NFS 2 и NFS 3 использование возможностей системы безопасности только рекомендовалось, в NFS 4 это стало обязательным. Файловая система NFS 4 требует реализации механизма безопасности с помощью интерфейса RPCSEC_GSS (Generic Security Services) в общем и протоколов Kerberos 5/LIPKEY в частности. Обратите внимание, что RPCSEC_GSS просто выполняет роль интерфейса API и транспортного механизма для меток и данных, связанных с безопасностью. Файловая система NFS 4 позволяет использовать несколько, схем аутентификации и обеспечения безопасности, а также дает возможность выбрать подходящую схему для клиентов и серверов.
Уделим некоторое внимание изучению технологии LIPKEY, использующей комбинацию симметричного и асимметричного шифрования. Клиент шифрует данные о пользователе и пароль, применяя случайно сгенерированный ключ размером 128 бит. Шифрование выполняется с помощью симметричного алгоритма, т.е. для дешифрации должен использоваться тот же ключ. Поскольку серверу необходим этот ключ для дешифрации сообщений, случайно сгенерированный ключ должен быть отправлен серверу. Клиент шифрует ключ (который генерируется случайно) с помощью открытого ключа сервера. Сервер дешифрует данные своим закрытым ключом, извлекает симметричный ключ и дешифрует данные о пользователе и пароль.
Клиенты могут аутентифицировать серверы по серверному сертификату, а для проверки сертификата используются службы сертификационного центра. Одним из популярных методов взлома является перехват "чужих" пакетов данных с их последующей отправкой через некоторый временной промежуток. При использовании Kerberos файловая система NFS добавляет в каждый пакет временную метку. Сервер записывает недавно полученные временные метки и сравнивает их с временными метками новых пакетов RPC. Если временные метки пакетов старше, чем полученные сервером ранее, сервер игнорирует полученные пакеты

1.5 Проблемы доступа при использовании нескольких протоколов

Несколько компаний стали предлагать системы, в которых одновременно реализована поддержка CIFS, NFS и других клиентов сетевых файловых систем. Поставщики проделали немалую работу, пытаясь преодолеть технические проблемы, которые возникают из-за потенциального использования клиентами различных операционных и файловых систем. Обратите внимание, что проблемы возникают не с самими данными, а с метаданными файлов. Простым тестом на наличие подобных проблем будет копирование фай¬ла с сервера на клиент и обратно на сервер (или наоборот). После размещения файла в первоначальном ресурсе метаданные должны содержать базовые значения, т.е. права доступа к файлу и временные метки не должны измениться. Если это не соответствует истине, то проблема обнаружена.
Далее представлены примеры некоторых возможных технических проблем.
■ В различных операционных системах используются разные методы для отслеживания разрешений доступа пользователей и групп.
■ В различных операционных и файловых системах существует разная семантика открытия и блокировки файлов.
■ Соглашения по именованию файлов обрабатываются разными способами. Различные файловые системы по-разному представляют максимальный размер имени файла, значение регистра в имени файла и набор символов, допустимый в именах.
■ Данные и их структура различаются в различных файловых системах; например, одни файловые системы отслеживают две временные метки, в то время как другие - три метки (время последнего доступа к файлу, последней модификации и создания файла). Даже если обе файловые системы отслеживают две временные метки, единицы измерения могут отличаться. Еще одним примером служат единицы измерения смещений в файлах. В некоторых файловых системах поддерживаются 32-разрядные смещения, а в некоторых - 16- или 64-разрядные.
■ Проблемы с адресацией отображаемых блокировок. Сервер CIFS принудительно поддерживает блокировку: если один клиент заблокировал область файла, то любая операция записи в эту область файла со стороны другого клиента приведет к возникновению ошибки. Однако принудительная блокировка не поддерживается серверами NFS. Поэтому необходимо выбрать, будет ли блокировка поддерживаться принудительно, что приведет к отправке сообщения об ошибке клиенту NFS.

Сетевые службы

Лекция 10

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

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

Ключевым компонентом распределенной ОС является сетевая файловая система. Сетевая файловая система поддерживается одним или несколькими компьютерами, хранящими файлы (файловые сервера)

Клиентские компьютеры подсоединяются или монтируют эти файловые системы к своим локальным файловым системам

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

Файловые службы включает собственно файловую службу (файловые операции) и службу каталогов (управление каталогами)

Модель сетевой файловой службы включает следующие элементы:

Локальная файловая система (FAT, NTFS)

Интерфейс локальной файловой системы (системные вызовы)

Сервер сетевой файловой системы

Клиент сетевой файловой системы (Windows Explorer, UNIX shell и пр.)

Интерфейс сетевой файловой системы(повторяет системные вызовы локальной файловой системы)

Протокол клиент-сервер сетевой файловой системы (SMB-Server Message Block для Windows, NFS (Network File System) и FTP (File Transfer Protocol) для UNIX)

Интерфейс сетевой файловой системы

Существуют несколько типов интерфейсов, которые характеризуются:

Структура файлов . Большинство сетевых ФС поддерживают неструктурированные файлы

Модифицируемость файлов . В большинстве сетевых ФС имеется возможность модифицировать файл. Некоторые распределенные ФС запрещают операции модификации. Возможны лишь create и read. Для таких файлов легче организовать кэширование и тиражирование.

Семантика разделения файлов:

Семантика UNIX (централизованная). Если чтение следует за несколькими операциями записи, то читается последнее обновление. Этот принцип возможен и в распределенной файловой системе, при условии одного файлового сервера и отсутствия кэширование файлов у клиента.

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

Механизм транзакций. Это способ работы с разделяемыми файлами с помощью механизма транзакций (неделимых операций)

Контроль доступа . Например для Windows NT/2000 существует два механизма: на уровне каталогов (для FAT) и на уровне файлов (NTFS)

Единица доступа. Модель загрузки-выгрузки файла целиком (FTP). Вторая модель - использование операций над файлами.