Протокол nfs что это

Обзор NFS

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

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

Описание компонента

с помощью протокола NFS можно передавать файлы между компьютерами, на которых выполняется Windows, и другими операционными системами, не являющимися Windows, такими как Linux или UNIX.

nfs в Windows server включает server для nfs и Client для nfs. компьютер, на котором работает Windows server, может использовать сервер для nfs в качестве файлового сервера nfs для других клиентских компьютеров, не являющихся Windows. клиент для NFS позволяет компьютеру с Windows, на котором работает Windows server, получать доступ к файлам, хранящимся на сервере NFS, отличном от Windows.

версии Windows и Windows Server

Windows поддерживает несколько версий клиента NFS и сервера в зависимости от версии операционной системы и семейства.

Практическое применение

Ниже приведены некоторые способы использования NFS.

Новые и измененные функции

Новые и измененные функциональные возможности в сетевой файловой системе включают поддержку NFS версии 4,1 и Улучшенное развертывание и управляемость. дополнительные сведения о новых или измененных функциональных возможностях Windows Server 2012 см. в следующей таблице.

NFS версии 4,1

NFS версии 4,1 реализует все необходимые аспекты в дополнение к некоторым дополнительным аспектам RFC 5661:

Инфраструктура NFS

улучшения в общей инфраструктуре NFS в Windows Server 2012 описаны ниже.

Постоянная доступность NFS версии 3

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

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

Улучшения развертывания и управляемости

Развертывание и управление NFS улучшены следующими способами.

Сведения о диспетчере сервера

в диспетчер сервера или более поздней версии центра администрирования Windows — используйте мастер добавления ролей и компонентов, чтобы добавить службу роли сервера для NFS (в файле и роли служб iSCSI). Общую информацию об установке компонентов см. в разделе Установка и удаление ролей, служб ролей или компонентов. Средства сервера для NFS включают оснастку «службы для сетевой файловой системы» MMC для управления сервером для NFS и клиентом для компонентов NFS. С помощью оснастки можно управлять компонентами сервера для NFS, установленными на компьютере. сервер для NFS также содержит несколько Windows средств администрирования командной строки:

nfs в Windows Server 2012 представляет модуль nfs для Windows PowerShell с несколькими новыми командлетами специально для NFS. Эти командлеты предоставляют простой способ автоматизации задач управления NFS. Дополнительные сведения см. в разделе командлеты NFS в Windows PowerShell.

Дополнительная информация

В следующей таблице приведены дополнительные ресурсы для оценки NFS.

Источник

Network File System

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

Содержание

Цели разработки

Первоначальная разработка NFS имела следующие цели:

Компоненты NFS

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

Версии

Версия 1

Детали реализации определены в RFC 1094. Версия 1 была только для внутреннего пользования в экспериментальных целях. Когда команда разработчиков добавила существенные изменения в NFS версии 1, была выпущена версия 2, которая уже использовалась за пределами компании.

Версия 2

Версии 3

NFSv3 (RFC 1813, июнь 1995 года). Добавлено:

На момент введения версии 3, использование разработчиками TCP как транспортного протокола начало расти. Хотя некоторые разработчики уже добавили поддержку протокола TCP для NFS версии 2 в качестве транспортного, Sun Microsystems добавили поддержку TCP в NFS версии 3. Использование TCP сделало использование NFS через глобальную сеть более осуществимым.

Версия 4

Другие модули

Менеджер блокировок сети (NLM — Network Lock Manager) и монитор состояния сети (NSM — Network Status Monitor) вместе обеспечивают средства для блокировки файлов в сети. Эти средства, хотя формально не связаны с NFS, можно найти в большинстве реализаций NFS. Они обеспечивают сервисы, не возможные в базовом протоколе. NLM и NSM реализуют функционирование сервера с помощью демонов lockd и statd, соответственно.

Протокол удалённой информации о квотах (RQUOTAD) (NFS позволяет пользователям просматривать дисковую квоту на удаленном NFS сервере).

Платформы

Типичные настройки NFS клиента и NFS сервера

Стандарты

См. также

Ссылки

Шаблон:URI scheme Шаблон:Стек ONC Шаблон:Файловые системы

Выделить Network File System и найти в:

Источник

Network File System

Network File System (NFS) — протокол сетевого доступа к файловым системам, первоначально разработан Sun Microsystems в 1984 году. Основан на протоколе вызова удалённых процедур (ONC RPC, Open Network Computing Remote Procedure Call, RFC 1057, RFC 1831). Позволяет подключать (монтировать) удалённые файловые системы через сеть, описан в RFC 1094, RFC 1813, RFC 3530 и RFC 5661.

NFS абстрагирована от типов файловых систем как сервера, так и клиента, существует множество реализаций NFS-серверов и клиентов для различных операционных систем и аппаратных архитектур. В настоящее время используется наиболее зрелая версия NFS v.4 (RFC 3010,RFC 3530), поддерживающая различные средства аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов).

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

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

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

Содержание

Цели разработки

Первоначальная разработка NFS имела следующие цели:

Компоненты NFS

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

Версии

Версия 1

Детали реализации определены в RFC 1094. Версия 1 была только для внутреннего пользования в экспериментальных целях. Когда команда разработчиков добавила существенные изменения в NFS версии 1, была выпущена версия 2, которая уже использовалась за пределами компании.

Версия 2

Версия 2 протокола NFS (RFC 1094, март 1989 года) первоначально полностью работала по протоколу UDP. Разработчики решили не хранить данных о внутреннем состоянии внутри протокола, как пример, блокировка, реализованная вне базового протокола. Люди, вовлечённые в создание NFS версии 2 — Расти Сендберг (Rusty Sandberg,) Боб Лайон (Bob Lyon), Билл Джой (Bill Joy) и Стив Клейман (Steve Kleiman).

Версии 3

NFSv3 (RFC 1813, июнь 1995 года). Добавлено:

На момент введения версии 3, использование разработчиками TCP как транспортного протокола начало расти. Хотя некоторые разработчики уже добавили поддержку протокола TCP для NFS версии 2 в качестве транспортного, Sun Microsystems добавили поддержку TCP в NFS версии 3. Использование TCP сделало использование NFS через глобальную сеть более осуществимым.

Версия 4

NFSv4 (RFC 3010, декабрь 2000 г., RFC 3530, пересмотренная в апреле 2003), под влиянием AFS и CIFS, включила в себя улучшение производительности, высокую безопасность, и предстала полноценным протоколом. Версия 4 стала первой версией, разработанной совместно с Internet Engineering Task Force (IETF), после того, как Sun Microsystems передала развитие протоколов NFS. NFS версии v4.1 была одобрена IESG в январе 2010 года, и получила номер RFC 5661 (новая спецификация, объёмом 612 страниц, стала известна как самый длинный документ, одобренный IETF). Важным нововведением версии 4.1 является спецификация pNFS — Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в стандарте сетевой файловой системы поможет строить распределённые «облачные» («cloud») хранилища и информационные системы.

Другие модули

WebNFS — это расширение для NFS версий 2 и 3, которое позволяют легче интегрироваться в веб-браузеры и дает возможность работы через брандмауэр. Различные сторонние протоколы стали ассоциироваться с NFS, в том числе:

Менеджер блокировок сети (NLM — Network Lock Manager) и монитор состояния сети (NSM — Network Status Monitor) вместе обеспечивают средства для блокировки файлов в сети. Эти средства, хотя формально не связаны с NFS, можно найти в большинстве реализаций NFS. Они обеспечивают сервисы, не возможные в базовом протоколе. NLM и NSM реализуют функционирование сервера с помощью демонов lockd и statd, соответственно.

Протокол удалённой информации о квотах (RQUOTAD) (NFS позволяет пользователям просматривать дисковую квоту на удаленном NFS сервере).

Платформы

Хотя NFS чаще всего используют в UNIX-подобных системах, данный протокол можно также использовать и на других операционных системах, таких, как Mac OS Classic, OpenVMS, Microsoft Windows, Novell NetWare, и IBM AS/400. В число альтернативных протоколов удаленного доступа к файлам входят Server Message Block (SMB, также известный как CIFS) протокол, Apple Filing Protocol (AFP), NetWare Core Protocol (NCP). Под операционной системой Microsoft Windows SMB и NetWare Core Protocol (NCP) используется чаще, чем NFS; В системах Macintosh AFP встречается чаще, чем NFS.

Источник

Network File System

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

Содержание

Цели разработки

Первоначальная разработка NFS имела следующие цели:

Компоненты NFS

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

Версии

Версия 1

Детали реализации определены в RFC 1094. Версия 1 была только для внутреннего пользования в экспериментальных целях. Когда команда разработчиков добавила существенные изменения в NFS версии 1, была выпущена версия 2, которая уже использовалась за пределами компании.

Версия 2

Версии 3

NFSv3 (RFC 1813, июнь 1995 года). Добавлено:

На момент введения версии 3, использование разработчиками TCP как транспортного протокола начало расти. Хотя некоторые разработчики уже добавили поддержку протокола TCP для NFS версии 2 в качестве транспортного, Sun Microsystems добавили поддержку TCP в NFS версии 3. Использование TCP сделало использование NFS через глобальную сеть более осуществимым.

Версия 4

Другие модули

Менеджер блокировок сети (NLM — Network Lock Manager) и монитор состояния сети (NSM — Network Status Monitor) вместе обеспечивают средства для блокировки файлов в сети. Эти средства, хотя формально не связаны с NFS, можно найти в большинстве реализаций NFS. Они обеспечивают сервисы, не возможные в базовом протоколе. NLM и NSM реализуют функционирование сервера с помощью демонов lockd и statd, соответственно.

Протокол удалённой информации о квотах (RQUOTAD) (NFS позволяет пользователям просматривать дисковую квоту на удаленном NFS сервере).

Платформы

Типичные настройки NFS клиента и NFS сервера

Стандарты

См. также

Ссылки

Шаблон:URI scheme Шаблон:Стек ONC Шаблон:Файловые системы

Выделить Network File System и найти в:

Источник

Сетевая файловая служба

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

Протокол сетевой файловой службы (Network File Server, NFS) — это открытый стандарт на предоставление пользователю удаленного доступа к файловым системам. Созданные на его основе централизованные файловые системы облегчают ежедневное выполнение таких задач, как резервное копирование или проверка на вирусы, а объединенные дисковые разделы проще обслуживать, чем множество небольших и распределенных.

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

Лучшее понимание как самого протокола, так и деталей его реализации позволит легче справиться с практическими задачами. Данная статья посвящена NFS и состоит из двух логических частей: вначале описывается сам протокол и цели, поставленные при его разработке, а затем реализации NFS в Solaris и UNIX.

С ЧЕГО ВСЕ НАЧИНАЛОСЬ.

Протокол NFS разработан компанией Sun Microsystems и в 1989 г. появился в Internet в виде документа RFC 1094 под следующим названием: «Спецификация протокола сетевой файловой системы» (Network File System Protocol Specification, NFS). Интересно отметить, что и стратегия компании Novell в то время была направлена на дальнейшее усовершенствование файловых служб. До недавнего времени, пока движение за открытые коды еще не набрало силу, Sun не стремилась раскрывать секреты своих сетевых решений, однако даже тогда в компании понимали всю важность обеспечения взаимодействия с другими системами.

В документе RFC 1094 содержались две первоначальные спецификации. К моменту его публикации Sun разрабатывала уже следующую, третью версию спецификации, которая изложена в RFC 1813 «Спецификация протокола NFS, версия 3» (NFS Version 3 Protocol Specification). Версия 4 данного протокола определена в RFC 3010 «Спецификация протокола NFS, версия 4» (NFS Version 4 Protocol).

NFS широко используется на всех типах узлов UNIX, в сетях Microsoft и Novell, а также в таких решениях компании IBM, как AS400 и OS/390. Будучи неизвестной за пределами сетевого «королевства», NFS, пожалуй, самая распространенная платформенно-независимая сетевая файловая система.

ПРАРОДИТЕЛЕМ БЫЛ UNIX

Хотя NFS — платформенно-независимая система, ее прародителем является UNIX. Другими словами, иерархичность архитектуры и методы доступа к файлам, включая структуру файловой системы, способы идентификации пользователей и групп и приемы работы с файлами — все это очень напоминает файловую систему UNIX. Например, файловая система NFS, будучи по структуре идентичной файловой системе UNIX, монтируется непосредственно в ней. При работе с NFS на других операционных системах идентификационные параметры пользователей и права доступа к файлам подвергаются преобразованию (mapping).

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

В отличие от многих клиент-серверных систем, NFS для обмена информацией использует вызовы удаленных процедур (Remote Procedure Calls, RPC). Обычно клиент устанавливает соединение с заранее известным портом и затем, в соответствии с особенностями протокола, посылает запрос на выполнение определенного действия. В случае вызова удаленных процедур клиент создает вызов процедуры и затем отправляет его на исполнение серверу. Подробное описание NFS будет представлено ниже.

В качестве примера предположим, что некий клиент смонтировал каталог usr2 в локальной корневой файловой системе:

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

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

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

ПОЗНАКОМИМСЯ ПОБЛИЖЕ

С точки зрения клиента, процесс локального монтирования удаленной файловой системы средствами NFS состоит из нескольких шагов. Как уже упоминалось, клиент NFS подаст вызов удаленной процедуры для выполнения ее на сервере. Заметим, что в UNIX клиент представляет собой одну программу (команда mount), в то время как сервер на самом деле реализован в виде нескольких программ со следующим минимальным набором: служба преобразования портов (port mapper), демон монтирования (mount daemon) и сервер NFS.

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

(Излагаемый материал ориентирован на третью версию NFS, поскольку она наиболее распространена на данный момент. Четвертая версия большинством реализаций пока не поддерживается.)

Таблица 1. Удаленные процедуры для работы с файловой системой.

Служба преобразования портов сервера откликается на запросы в соответствии с поддерживаемым протоколом и портом, на котором работает демон монтирования. Клиентская программа mount вначале устанавливает соединение с демоном монтирования сервера, а затем передает ему с помощью RPC команду mount. Если данная процедура выполнена успешно, то клиентское приложение соединяется с сервером NFS (порт 2049) и, используя одну из 20 удаленных процедур, которые определены в RFC 1813 и приводятся нами в Таблице 1, получает доступ к удаленной файловой системе.

Смысл большинства команд интуитивно понятен и не вызывает каких-либо затруднений у системных администраторов. Приведенный ниже листинг, полученный с помощью tcdump, иллюстрирует команду чтения, создаваемую командой UNIX cat для прочтения файла с именем test-file:

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

ДОСТУП В NFS

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

Первый способ основывается на встроенной в UNIX системе прав доступа к файлам для индивидуального пользователя или группы. Для упрощения обслуживания идентификация пользователей и групп должна быть единообразной для всех клиентов и серверов NFS. Защиту следует тщательно продумать: в NFS можно по неосторожности предоставить такой доступ к файлам, который не планировался при их создании.

Доступ на уровне разделяемых ресурсов позволяет ограничивать права, разрешив только определенные действия, независимо от принадлежности файла или привилегий UNIX. Например, работу с файловой системой NFS можно ограничить только чтением. Большинство реализаций NFS позволяет дополнительно ограничить доступ на уровне разделяемых ресурсов конкретными пользователями и/или группами. Например, группе «Отдел кадров» разрешается просмотр информации и не более того.

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

Комбинированный доступ просто объединяет вышеописанные виды (например, доступ на уровне разделяемых ресурсов с доступом, предоставляемым конкретному пользователю) или разрешает пользователям работу с NFS только с определенного узла.

Далее мы более детально рассмотрим протокол NFS и связанные с ним системные службы. Приводимые примеры относятся к Linux Red Hat 6.2 и Solaris 2.6.

NFS В СТИЛЕ «ПИНГВИН»

Относящийся к Linux излагаемый материал основывается на системе Red Hat 6.2 с ядром версии 2.4.9, которая поставляется с пакетом nfs-utils версии 0.1.6. Существуют и более новые версии: на момент написания этой статьи самое последнее обновление пакета nfs-utils имело номер 0.3.1. Его можно загрузить по адресу: http://sourceforge.net/project/shownotes. php?group_id=14&release_id=24211.

Пакет nfs-utils содержит следующие исполняемые файлы: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount и statd.

К сожалению, иногда поддержка NFS вызывает путаницу у администраторов Linux, поскольку наличие той или иной функциональной возможности напрямую зависит от номеров версий как ядра, так и пакета nfs-utils. К счастью, в настоящее время положение дел в этой области улучшается: последние дистрибутивные комплекты включают самые новые версии и того, и другого. Для предыдущих выпусков в разделе 2.4 документа NFS-HOWTO приводится полный список функциональных возможностей системы, имеющихся в наличии для каждой комбинации ядра и пакета nfs-utils. Разработчики поддерживают обратную совместимость пакета с более ранними версиями, уделяя много внимания обеспечению безопасности и устранению программных ошибок.

Поддержку NFS следует инициировать во время компиляции ядра. Если необходимо, в ядро нужно добавить и возможность работы с NFS версии 3.

Для дистрибутивов, поддерживающих linuxconf, легко сконфигурировать службы NFS как для клиентов, так и для серверов. Однако быстрый способ установки NFS с помощью linuxconf не дает информации о том, какие файлы были созданы или отредактированы, что очень важно знать администратору для понимания ситуации в случае сбоя системы. Архитектура NFS в Linux имеет слабую связь с версией BSD, поэтому необходимые файлы и программы поддержки легко найти администраторам, работающим с BSD, Sun OS 2.5 или более ранними версиями NFS.

Файл /etc/exports, как и в более ранних версиях BSD, определяет файловые системы, к которым разрешен доступ клиентам NFS. Кроме того, он содержит ряд дополнительных возможностей, относящихся к вопросам управления и безопасности, предоставляя администратору средство для тонкой настройки. Это текстовый файл, состоящий из записей, пустых или закомментированных строк (комментарии начинаются с символа #).

Предположим, что мы хотим предоставить клиентам доступ только для чтения к каталогу /home на узле Lefty. Этому в /etc/exports будет соответствовать следующая запись:

Здесь нам необходимо сообщить системе, какие каталоги мы собираемся сделать доступными с помощью демона монтирования rpc.mountd:

При запуске команда exportfs выводит предупреждение о том, что /etc/ exports не ограничивает доступ к отдельному узлу, и создает соответствующую запись в /var/lib/nfs/etab из /etc/exports, сообщающую, какие ресурсы можно просмотреть с помощью cat:

Другие параметры, перечисленные в виде списка в etab, включают значения по умолчанию, используемые NFS. Детали будут описаны ниже. Чтобы предоставить доступ к каталогу /home, необходимо запустить соответствующие службы NFS:

В любой момент после запуска демона монтирования (rpc.mountd) cправиться об отдельных файлах, доступных для вывода, можно, просмотрев содержимое файла /proc/fs/nfs/exports:

Привередливым пользователям может показаться неудобным, что в Linux демон NFS (rpc.nfsd) находится в режиме ожидания пакетов версий 1 и 2, хотя это и достигает желаемого эффекта отказа от поддержки соответствующего протокола. Будем надеяться, что разработчики следующих версий внесут необходимые исправления и сумеют добиться большей согласованности компонентов пакета в отношении различных версий протокола.

«ЗАПЛЫВ С ПИНГВИНАМИ»

Доступ к сконфигурированной выше Lefty, экспортируемой файловой системе NFS на базе Linux, зависит от клиентской операционной системы. Стиль установок для большинства операционных систем семейства UNIX совпадает со стилем либо исходных систем Sun OS и BSD, либо более новой Solaris. Так как данная статья посвящена обеим системам, Linux и Solaris, давайте рассмотрим клиентскую конфигурацию Solaris 2.6 с точки зрения установления соединения с Linux-версией NFS, описанной нами выше.

Благодаря свойствам, унаследованным Solaris 2.6, ее легко сконфигурировать для работы в качестве клиента NFS. Для этого требуется лишь одна команда:

Предположим, что предыдущая команда mount выполнена успешно, тогда команда mount без параметров выведет следующее:

Давайте проанализируем вывод tcpdump, полученный на узле Lefty, после того, как пользователь ввел команду ls /tmp/tmp2 на узле Sunny:

Мы видим, что узел Sunny запрашивает для ls описатель файла (fh), на что узел Lefty в ответ посылает OK и возвращает структуру каталога. Затем Sunny проверяет разрешение на право доступа к содержимому каталога (132 access fh) и получает ответ с разрешением от Lefty. После этого узел Sunny, используя процедуру readdirplus, считывает полное содержимое каталога. Вызовы удаленных процедур описаны в документе RFC 1813 и приведены нами в начале данной статьи.

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

Другое полезное средство — команда nfsstat. С ее помощью можно узнать, обращаются ли в действительности клиенты к экспортируемой файловой системе, а также вывести статистическую информацию в соответствии с версией протокола.

Наконец, еще одним достаточно полезным инструментом определения причин сбоев системы является tcpdump:

Вышеприведенный листинг, полученный после выполнения инструкции touch test.c, отражает следующую последовательность действий: сначала команда touch пытается получить доступ к файлу по имени test.c, затем она ищет каталог с этим же именем, а после неудачных попыток пытается создать файл test.c, что также не приводит к успеху.

Если файловая система смонтирована, то большинство типичных ошибок связано с обычными правами доступа UNIX. Использование uid или NIS+ в Sun помогает избежать глобального установления прав доступа на все файловые системы. Некоторые администраторы практикуют «открытые» каталоги, когда права доступа на их чтение даются «всему миру». Однако этого следует избегать по причинам безопасности. Даже отбросив в сторону проблемы защиты, все равно придется признать такой подход порочной практикой, поскольку пользователи редко создают данные с намерением сделать их доступными для чтения всем подряд.

Обращения привилегированного пользователя (root) к смонтированным файловым системам NFS трактуются по-особому. Чтобы избежать предоставления привилегированному пользователю неограниченного доступа, запросы от него трактуются так, как будто бы они поступают от пользователя nobody («никто»). Этот действенный механизм ограничивает доступ привилегированного пользователя глобально доступными для чтения и разрешенными для записи файлами.

СЕРВЕР NFS, ВЕРСИЯ SOLARIS

Конфигурирование Solaris для работы в качестве сервера NFS так же просто, как и в случае с Linux. Однако команды и местоположение файлов несколько отличаются. При начальной загрузке Solaris по достижении уровня загрузки 3 (run level 3) автоматически запускаются службы NFS и экспортируются все файловые системы. Для запуска этих процессов вручную введите команду:

Для запуска демона монтирования и сервера NFS введите:

Начиная с версии 2.6 в Solaris для указания экспортируемых файловых систем больше не используется файл экспорта. Теперь файлы экспортируются с помощью команды share. Предположим, мы хотим позволить удаленным узлам смонтировать /export/home. Введем для этого следующую команду:

После выполнения команды share список экспортируемых файловых систем можно просмотреть с помощью той же команды без параметров:

Статус экспортирования для файловой системы отменяет команда unshare:

В Solaris информация, касающаяся NFS, хранится в каталоге /etc/dfs. Данные об экспортируемых файловых системах находятся в /etc/dfs/sharetab. Команда share без параметров пользуется именно этими данными.

В /etc/dfs/dfstab содержится список команд share, запускаемых при начальной загрузке ОС. Сделать /export/home автоматически экспортируемой можно, добавив вышеупомянутую команду

Еще одна полезная команда, используемая при экспортировании файловых систем, — shareall. Введенная без параметров, она запускает все команды share, указанные в /etc/dfs/dfstab. Команда unshareall отменяет статус экспортирования для всех экспортируемых файловых систем.

LINUX КАК КЛИЕНТ NFS

Применение Linux в качестве клиента NFS не было рассмотрено в посвященном ему разделе. Для полноты излагаемого материала опишем процедуру монтирования экспортируемой файловой системы Solaris.

После этого получить информацию о состоянии файловой системы можно с помощью команды mount:

СТАРТ ДАН

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

Рональд Маккарти — старший системный инженер по телекоммуникационным системам в компании Sonus Networks, соавтор издания New Rider?s Linux Routing (http://www.linuxroutingbook.com). С ним можно связаться по адресу: ronald.mccarty@gte.net.

Мероприятия по обеспечению безопасности

БЕЗОПАСНОСТЬ В LINUX

Некоторые системные службы NFS на основе Linux имеют дополнительный механизм ограничения доступа посредством управляющих списков или таблиц. На внутреннем уровне этот механизм реализован с помощью библиотеки tcp_wrapper, которая для формирования списков контроля доступа использует два файла: /etc/hosts.allow и /etc/hosts/deny. Исчерпывающий обзор правил работы с tcp_wrapper выходит за рамки данной статьи, основной же принцип состоит в следующем: сопоставление вначале производится с etc/hosts.allow, а затем с /etc/hosts. deny. Если правило не найдено, то запрашиваемая системная служба не представляется. Чтобы обойти последнее требование и обеспечить очень высокий уровень безопасности, в конец /etc/hosts.deny можно добавить следующую запись:

ALL: All

После этого можно использовать /etc/ hosts.allow, чтобы установить тот или иной режим работы. Например, файл /etc/hosts. allow, который я использовал при написании данной статьи, содержал следующие строки:

При этом разрешается определенный вид доступа к узлам до того, как будет предоставлен доступ на уровне приложений. В Linux доступом на уровне приложений управляет файл /etc/exports. Он состоит из записей в следующем формате:

«Экспортируемый каталог» — это каталог, обработка запроса к которому разрешена демону nfsd. «Узел|сеть» — это узел или сеть, имеющие доступ к экспортируемой файловой системе, а «опции» определяют те ограничения, какие демон nfsd налагает на использование данного разделяемого ресурса, — доступ только для чтения или преобразование идентификатора пользователя (user id mapping).

В следующем примере всему домену mcwrite.net предоставлен доступ в режиме только для чтения к /home/mcwrite.net:

Другие примеры можно найти на справочной странице exports man.

БЕЗОПАСНОСТЬ NFS В SOLARIS

Справочная страница man для share_nfs подробно описывает предоставление доступа с помощью управляющих списков в Solaris.

Ресурсы Internet

В NFS и RPC не обошлось без «дыр». Вообще говоря, NFS не следует использовать при работе в Internet. Нельзя делать «дыры» в брандмауэрах, предоставляя какой бы то ни было доступ посредством NFS. Необходимо тщательно следить за всеми появляющимися заплатами для RPC и NFS, в чем могут помочь многочисленные источники информации по вопросам безопасности. Два наиболее популярных источника — Bugtraq и CERT:

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

Поделитесь материалом с коллегами и друзьями

Источник