NFSv4 обеспечивает унифицированный сетевой доступ. Сетевая файловая служба

Удобное решение для доступа к распределенной файловой системе

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

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

Сетевые файловые системы и другие священнодействия

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

Распределенные вычисления против сетевых

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

Одним из звеньев головоломки является способ организации доступа к файлам в компьютерной системе. Сейчас для системы, осуществляющей доступ к файлам, является несущественным, доступны ли необходимые файлы на одном компьютере, или они расположены по каким-либо причинам на нескольких компьютерах. В настоящее время семантика файловой системы и структуры данных файловой системы являются двумя очень разными темами. Семантика файловой системы Plan 9 или распределенной файловой системы AFS-стиля (Andrew File System) скрывает способ организации файлов или способ отображения файловой системы на аппаратное и сетевое обеспечение. NFS не обязательно скрывает способ хранения файлов и каталогов на удаленных файловых системах, но она также не раскрывает действительный аппаратный способ хранения файловых систем, каталогов и файлов.

NFS: Решение UNIX-проблемы

Доступ к распределенной файловой системе, тем не менее, требует несколько больше пары команд, разрешающих пользователям монтировать каталог, который расположен на другом компьютере в сети. Sun Microsystems столкнулась с этой проблемой несколько лет назад, когда начинала распространять нечто, названное Remote Procedure Calls (RPCs), и NFS.

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

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

NFS - это RPC

NFS традиционно определяется как RPC-приложение, требующее наличия TCP для NFS-сервера, а также либо TCP, либо другого не перегружающего сеть протокола для NFS-клиента. Организация Internet Engineering Task Force (IETF) опубликовала Request for Comments (RFC) для RPC в RFC 1832. Другой жизненно важный для функционирования NFS-реализации стандарт описывает форматы данных, используемые NFS; он был опубликован в RFC 1831 как документ "External Data Representation" (XDR).

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

Этот RFC описывает, какие протоколы обеспечивают функционирование NFS, но в нем не описывается, как NFS функционирует в настоящее время . Вы уже узнали кое-что важное, а именно - NFS-протоколы задокументированы в виде IETF-стандартов. После того, как последняя версия NFS застряла на цифре 3, RPC-протоколы не развивались дальше информационной фазы RFC и воспринимались, в основном, как не выходящие за пределы интересов (предположительно) огромной инженерной рабочей группы Sun Microsystems и патентованных разновидностей UNIX. С 1985 года Sun выпустила несколько версий NFS, на несколько лет предвосхитившей большинство современных разновидностей файловых систем. Sun Microsystems передала контроль над NFS организации IETF в 1998 году, и большая часть работы над NSF версии 4 (NFSv4) проводилась под эгидой IETF.

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

NFS версии 3

NFS в своем воплощении в виде версии 3 (NFSv3) не сохраняет свое состояние (не является stateful), а NFSv4 сохраняет. Это фундаментальное выражение сегодня едва ли кого-то удивляет, хотя мир TCP/IP, на котором построена NFS, по большей части не сохраняет своего состояния (stateless) - факт, который помогает компаниям, производящим программное обеспечение для анализа трафика и системы защиты, чувствовать себя довольно хорошо.

Протокол NFSv3 должен был полагаться на несколько дополнительных протоколов для прозрачного монтирования каталогов на удаленных компьютерах, чтобы не зависеть от используемых на них механизмов файловых систем. NFS не всегда преуспевала в этом. Хороший пример - протокол Mount вызывал начальный идентификатор файла, в то время как протокол Network Lock Manager занимался блокировкой файла. Обе операции нуждались в текущем состоянии, которое протокол NFSv3 не предоставлял. Следовательно, имели место сложные взаимодействия между уровнями протоколов, которые не отражали аналогичные механизмы потоков данных. Кроме того, если добавить тот факт, что создание файла и каталога в Microsoft® Windows® осуществляется совершенно не так, как в UNIX, ситуация еще более усложнится.

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

Протокол NFSv3 был также готов для работы с файловыми системами, поддерживающими Unicode - преимущество, которое до конца 1990-х годов оставалось в некоторой степени чисто теоретическим. Он хорошо соответствовал семантике файловой системы UNIX и явился причиной создания конкурирующих реализаций файловых систем, таких как AFS и Samba. Не удивительно, что Windows-поддержка была бедной, но файловые серверы Samba обеспечивали общий доступ к файлам для систем UNIX и Windows.

NFS версии 4

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

Все NFS-версии определяли каждую единицу работы в понятиях операций RPC-клиента и сервера. Каждый NFSv3-запрос требовал довольно значительного количества RPC-вызовов и вызовов операций открытия портов для выдачи результата. Версия 4 упростила это, введя понятие так называемой составной (compound) операции, к которой относится большое количество операций над объектами файловой системы. Прямым эффектом, разумеется, стало значительно меньшее количество RPC-вызовов и меньший объем данных, которые нужно передавать по сети, даже при том, что каждый RPC-вызов нес, по сути, больше данных, выполняя значительно больший объем работы. Было приблизительно подсчитано, что RPC-вызовы в NFSv3 требовали в пять раз большее количество клиент-серверных взаимодействий по сравнению с составными RPC-процедурами.

RPC, на самом деле, больше не имеет такой важности и, по существу, служит оболочкой (wrapper) над несколькими операциями, инкапсулированными в NFSv4-стеке. Также это изменение сделало стек протокола намного менее зависимым от семантики используемой файловой системы. Но это не означает, что операции файловой системы других операционных систем были проигнорированы: например, для совместного использования Windows-ресурсов требуется сохранение состояния при вызовах открытия ресурса. Сохранение состояния не только облегчает анализ трафика, но при реализации на уровне семантики файловой системы делает операции файловой системы значительно более доступными для контроля. Вызовы открытия ресурсов с сохранением состояния позволяют клиентам кэшировать файловые данные и состояние - то, что в противном случае происходило бы на сервере. В реальной жизни (в которой Windows-клиенты распространены повсеместно) организация прозрачной и унифицированной работы NFS-серверов с разделяемыми Windows-ресурсами стоит потраченного вами времени на настройку NFS-конфигурации.

Использование NFS

Установка NFS, в общем, аналогична установке Samba. На стороне сервера вы определяете файловые системы или каталоги для экспорта или совместного использования ; клиентская сторона монтирует эти каталоги. После монтирования удаленным клиентом NFS-каталога этот каталог становится доступен так же, как любой другой каталог локальной файловой системы. Настройка NFS на сервере - это простой процесс. Как минимум, вы должны создать или отредактировать файл /etc/exports и запустить NFS-демон. Для настройки более защищенной NFS-службы вы должны также отредактировать файлы /etc/hosts.allow и /etc/hosts.deny. NFS-клиент требует выполнения только команды mount . Дополнительная информация и параметры описаны в оперативной документации по Linux® (man page).

NFS-сервер

Записи в файле /etc/exports имеют понятный формат. Для организации совместного доступа к файловой системе измените файл /etc/exports и опишите файловую систему (с параметрами) в следующем общем формате:

каталог (или файловая система) client1 (option1, option2) client2 (option1, option2)

Общие параметры

Для настройки вашей NFS-реализации доступно несколько общих параметров. К ним относятся:

• secure: Этот параметр (по умолчанию) использует для NFS-соединения доступный порт TCP/IP, меньший 1024. Указание insecure запрещает это.
• rw: Этот параметр разрешает NFS-клиентам доступ для чтения/записи. Доступ по умолчанию - только для чтения.
• async: Этот параметр может повысить производительность, но он может также вызвать потерю данных при перезапуске NFS-сервера без предварительной процедуры остановки NFS-демона. Настройка по умолчанию - sync .
• no_wdelay: Этот параметр отключает задержку при записи. Если установлен режим async , NFS игнорирует этот параметр.
• nohide: Если вы монтируете один каталог поверх другого, старый каталог обычно скрывается или выглядит пустым. Для запрета такого поведения разрешите параметр hide .
• no_subtree_check: Этот параметр отключает контроль подкаталогов, выполняющийся для некоторых проверок системой защиты, которые вы, возможно, не хотите игнорировать. Параметр по умолчанию - разрешить контроль подкаталогов.
• no_auth_nlm: Этот параметр при значении insecure_locks указывает NFS-демону не проводить аутентификацию во время запросов на блокировку. Параметр по умолчанию - auth_nlm или secure_locks .
• mp (mountpoint=path) : При явном объявлении этого параметра NSF требует монтирования экспортируемого каталога.
• fsid=num: Этот параметр обычно используется при организации системы восстановления после сбоя NFS. Если вы хотите реализовать восстановление после сбоя для NFS, обратитесь к документации по NFS.

Отображение пользователей

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

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

К параметрам отображения пользователей относятся:

• root_squash: Этот параметр не позволяет пользователю root обращаться к смонтированному NFS-тому.
• no_root_squash: Этот параметр позволяет пользователю root обращаться к смонтированному NFS-тому.
• all_squash: Этот параметр, полезный для NFS-томов с открытым доступом, подавляет все UID и GID и использует только учетную запись анонимного пользователя. Установка по умолчанию - no_all_squash .
• anonuid и anongid: Эти параметры меняют UID и GID анонимного пользователя на указанную учетную запись.

В листинге 1 приведены примеры записей /etc/exports.

Листинг 1. Примеры записей /etc/exports

/opt/files 192.168.0.* /opt/files 192.168.0.120 /opt/files 192.168.0.125(rw, all_squash, anonuid=210, anongid=100) /opt/files *(ro, insecure, all_squash)

Первая запись экспортирует каталог /opt/files для всех хостов сети 192.168.0. Следующая запись экспортирует /opt/files для одного хоста: 192.168.0.120. Третья запись указывает хост 192.168.0.125 и предоставляет доступ по чтению/записи к файлам с правами пользователя, имеющего user id=210 и group id=100 . Последняя запись используется для общедоступного каталога и разрешает доступ только по чтению и только под учетной записью анонимного пользователя.

NFS-клиент

Предостережения

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

Для использования NFS в роли клиента на клиентском компьютере должен выполняться rpc.statd и portmap. Вы можете выполнить команду ps -ef для проверки присутствия двух этих демонов. Если они работают (как и должны), вы можете монтировать экспортируемый сервером каталог при помощи следующей общей команды:

mount server:directory local mount point

Вообще говоря, при монтировании файловой системы вы должны работать как пользователь root. На удаленном компьютере вы можете использовать следующую команду (в предположении, что NFS-сервер имеет IP-адрес 192.168.0.100):

mount 192.168.0.100:/opt/files /mnt

Ваш дистрибутив системы может потребовать указания типа файловой системы при ее монтировании. Если это так, используйте команду:

mount -t nfs 192.168.0.100:/opt/files /mnt

Удаленный каталог должен монтироваться безо всяких проблем, если вы корректно настроили сервер. Теперь выполните команду cd для перехода в каталог /mnt, затем команду ls для просмотра файлов. Для того чтобы сделать такое монтирование постоянным, вы должны изменить файл /etc/fstab и создать запись, аналогичную следующей:

192.168.0.100:/opt/files /mnt nfs rw 0 0

Примечание: Дополнительная информация по записям /etc/fstab приведена в оперативной справке по fstab.

Критика NFS

Критика способствует улучшению

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

Для понимания модели системы защиты вы должны ознакомиться с интерфейсом прикладного программирования Generic Security Services (GSS-API) версии 2, редакции 1. GSS-API полностью описан в RFC 2743, который, к сожалению, является одним из наиболее сложных для понимания RFC-документов.

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

Соединения между NFS-клиентами и серверами защищаются посредством так называемой (довольно поверхностно) системы защиты strong RPC. NFSv4 использует стандарт Open Network Computing Remote Procedure Call (ONCRPC), определенный в RFC 1831. Система защиты должна была быть усилена, поэтому вместо простой аутентификации (известной как AUTH_SYS ) как обязательная часть протокола NFSv4 была определена и реализована разновидность основанной на GSS-API системы защиты, известная под названием RPCSEC_GSS . К наиболее важным доступным в NFSv4 механизмам защиты относятся Kerberos версии 5 и LIPKEY.

Если Kerberos имеет ограничения при использовании в Интернет, то у LIPKEY есть приятное преимущество - работая как Secure Sockets Layer (SSL), он запрашивает у пользователей их имена и пароли, избегая, в то же время, TCP-зависимости от SSL - зависимости, которую NFSv4 не разделяет. Вы можете настроить NFS на реализацию разновидностей системы защиты, если RPCSEC_GSS не требуется. Предыдущие версии NFS не имели такой возможности и, следовательно, не могли обеспечить качественную защиту, целостность данных, требования по аутентификации или типы шифрования.

Протокол NFSv3 подвергся существенной критике в области защищенности. Если NFSv3-серверы работали по TCP, было абсолютно реально запускать NFSv3-сети по Интернет. К сожалению, нужно было также открывать несколько портов, что приводило к появлению нескольких хорошо разрекламированных дыр в системе защиты. Сделав порт 2049 обязательным для NFS, стало возможным использование NFSv4 с брандмауэрами (firewall) без необходимости уделять слишком большое внимание тому, какие порты прослушивали другие протоколы, например, протокол Mount. Таким образом, исключение протокола Mount имело несколько положительных эффектов:

• Обязательные механизмы строгой аутентификации: NFSv4 сделал механизмы строгой аутентификации обязательными. Разновидности Kerberos довольно распространены. Также должен поддерживаться Lower Infrastructure Public Key Mechanism (LIPKEY). NFSv3 никогда не поддерживал что-то большее, чем стандартное UNIX-шифрование для аутентификации доступа - это порождало основные проблемы защиты в больших сетях.
• Обязательные схемы списков контроля доступа (access control list - ACL) в стиле Microsoft Windows NT : Хотя NFSv3 позволял реализовать строгое шифрование для аутентификации, он не использовал схемы ACL-доступа в стиле Windows NT. Списки ACL в стиле Portable Operating System Interface (POSIX) иногда реализовывались, но никогда не были общепринятыми. NFSv4 сделал ACL-схемы в стиле Windows NT обязательными.
• Договорные механизмы и стили аутентификации : NFSv4 предоставил возможность договариваться о механизмах и стилях аутентификации. В NSFv3 было невозможно сделать что-то большее, чем ручное определение используемого стиля шифрования. Системный администратор должен был затем согласовывать протоколы шифрования и защиты.

До сих пор ли NFS вне конкуренции?

NFSv4 заменяет NFSv3 на большинстве систем UNIX и Linux. Как сетевая файловая система NSFv4 имеет мало конкурентов. Жизнеспособным конкурентом могла бы считаться Common Internet File System (CIFS)/Server Message Block (SMB), исходя из того, что она присутствует во всех разновидностях Windows и (в настоящее время) в Linux. AFS никогда не имела большого коммерческого влияния; в ней придавалось особое значение элементам распределенных файловых систем, которые облегчали миграцию и репликацию данных.

Готовые к использованию Linux-версии NFS были выпущены после достижения ядром версии 2.2, но одной из наиболее общих неудач версий ядра Linux было то, что Linux принял NFSv3 довольно поздно. Фактически, прошло много времени до того, когда Linux стал полностью поддерживать NSFv3. С появлением NSFv4 этот недостаток был быстро устранен и полную поддержку NSFv4 реализовали не только в Solaris, AIX и FreeBSD.

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

Network file system (NFS) - протокол сетевого доступа к файловым системам, позволяет подключать удалённые файловые системы.
Первоначально разработан Sun Microsystems в 1984 г. Основой является Sun RPC: вызов удаленной процедуры (Remote Procedure Call). NFS независим от типов файловых систем сервера и клиента. Существует множество реализаций NFS-серверов и клиентов для различных ОС. В настоящее время используется версия NFS v.4, поддерживающая различные средства аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов).
NFS предоставляет клиентам прозрачный доступ к файлам и файловой системе сервера. В отличие от FTP, протокол NFS осуществляет доступ только к тем частям файла, к которым обратился процесс, и основное достоинство его в том, что он делает этот доступ прозрачным. Благодаря этому любое приложение клиента, которое может работать с локальным файлом, с таким же успехом может работать и с NFS файлом, без изменений самой программы.
NFS клиенты получают доступ к файлам на NFS сервере путем отправки RPC-запросов на сервер. Это может быть реализовано с использованием обычных пользовательских процессов - а именно, NFS клиент может быть пользовательским процессом, который осуществляет конкретные RPC вызовы на сервер, который так же может быть пользовательским процессом.

Версии
NFSv1 была только для внутреннего пользования в экспериментальных целях. Детали реализации определены в RFC 1094.
NFSv2 (RFC 1094, март 1989 года) первоначально полностью работала по протоколу UDP.
NFSv3 (RFC 1813, июнь 1995 года). Описатели файлов в версии 2 - это массив фиксированного размера - 32 байта. В версии 3 - это массив переменного размера с размером до 64 байт. Массив переменной длины в XDR определяется 4-байтным счётчиком, за которым следуют реальные байты. Это уменьшает размер описателя файла в таких реализациях, как, например, UNIX, где требуется всего около 12 байт, однако позволяет не-Unix реализациям обмениваться дополнительной информацией.
Версия 2 ограничивает количество байт на процедуры READ или WRITE RPC размером 8192 байта. Это ограничение не действует в версии 3, что, в свою очередь, означает, что с использованием UDP ограничение будет только в размере IP датаграммы (65535 байт). Это позволяет использовать большие пакеты при чтении и записи в быстрых сетях.
Размеры файлов и начальное смещение в байтах для процедур READ и WRITE стали использовать 64-битную адресацию вместо 32-битной, что позволяет работать с файлами большего размера.
Атрибуты файла возвращаются в каждом вызове, который может повлиять на атрибуты.
Записи (WRITE) могут быть асинхронными, тогда как в версии 2 они должны были быть синхронными.
Одна процедура была удалена (STATFS) и семь были добавлены: ACCESS (проверка прав доступа к файлу), MKNOD (создание специального файла Unix), READDIRPLUS (возвращает имена файлов в директории вместе с их атрибутами), FSINFO (возвращает статистическую информацию о файловой системе), FSSTAT (возвращает динамическую информацию о файловой системе), PATHCONF (возвращает POSIX.1 информацию о файле) и COMMIT (передает ранее сделанные асинхронные записи на постоянное хранение).
На момент введения версии 3, разработчики стали больше использовать TCP как транспортный протокол. Хотя некоторые разработчики уже Использовали протокол TCP для NFSv2, Sun Microsystems добавили поддержку TCP в NFS версии 3. Это сделало использование NFS через Интернет более осуществимым.
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. Важным нововведением версии 4.1 является спецификация pNFS - Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в стандарте сетевой файловой системы поможет строить распределённые "облачные" ("cloud") хранилища и информационные системы.

Структура NFS
Структура NFS включает три компонента разного уровня:
Прикладной уровень (собственно NFS) - это вызовы удаленных процедур (rpc), которые и выполняют необходимые операции с файлами и каталогами на стороне сервера.
Функции уровня представления выполняет протокол XDR (eXternal Data Representation), который является межплатформенным стандартом абстракции данных. Протокол XDR описывает унифицированную, каноническую, форму представления данных, не зависящую от архитектуры вычислительной системы. При передаче пакетов RPC-клиент переводит локальные данные в каноническую форму, а сервер проделывает обратную операцию.
Сервис RPC (Remote Procedure Call), обеспечивающий запрос удаленных процедур клиентом и их выполнение на сервере, представляет функции сеансового уровня.Подключение сетевых ресурсов
Процедура подключения сетевого ресурса средствами NFS называется "экспортированием". Клиент может запросить у сервера список представляемых им экспортируемых ресурсов. Сам сервер NFS не занимается широковещательной рассылкой списка своих экспортируемых ресурсов.
В зависимости от заданных опций, экспортируемый ресурс может быть смонтирован (присоединён) "только для чтения", можно определить список хостов, которым разрешено монтирование, указать использование защищенного RPC (secureRPC) и пр. Одна из опций определяет способ монтирования: "жесткое" (hard) или "мягкое" (soft).
При "жестком" монтировании клиент будет пытаться смонтировать файловую систему во что бы то ни стало. Если сервер не работает, это приведет к тому, что весь сервис NFS как бы зависнет: процессы, обращающиеся к файловой системе, перейдут в состояние ожидания окончания выполнения запросов RPC. С точки зрения пользовательских процессов файловая система будет выглядеть как очень медленный локальный диск. При возврате сервера в рабочее состояние сервис NFS продолжит функционирование.
При "мягком" монтировании клиент NFS сделает несколько попыток подключиться к серверу. Если сервер не откликается, то система выдает сообщение об ошибке и прекращает попытки произвести монтирование. С точки зрения логики файловых операций при отказе сервера "мягкое" монтирование эмулирует сбой локального диска.
Выбор режима зависит от ситуации. Если данные на клиенте и сервере должны быть синхронизированы при временном отказе сервиса, то "жесткое" монтирование оказывается предпочтительнее. Этот режим незаменим также в случаях, когда монтируемые файловые системы содержат в своем составе программы и файлы, жизненно важные для работы клиента, в частности для бездисковых машин. В других случаях, особенно когда речь идет о системах "только для чтения", режим "мягкого" монтирования представляется более удобным.

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

Стандарты
RFC 1094 NFS: Network File System Protocol Specification] (March 1989)
RFC 1813 NFS Version 3 Protocol Specification] (June 1995)
RFC 2224 NFS URL Scheme
RFC 2339 An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc. in the matter of NFS V.4 Protocols
RFC 2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol’s Use of RPCSEC_GSS and Kerberos V5
RFC 2624 NFS Version 4 Design Considerations
RFC 3010 NFS version 4 Protocol
RFC 3530 Network File System (NFS) version 4 Protocol
RFC 5661 Network File System (NFS) Version 4 Minor Version 1 Protocol

Используемые источники
1. ru.wikipedia.org
2. ru.science.wikia.com
3. phone16.ru
4. 4stud.info
5. yandex.ru
6. gogle.com

Файловая система NFS (Network File System) создана компанией Sun Microsystems. В настоящее время это стандартная сетевая файловая система для ОС семейства UNIX, кроме того, клиенты и серверы NFS реализованы для многих других ОС. Принципы ее организации на сегодня стандартизованы сообществом Интернета, последняя версия NFS v.4 описывается спецификацией RFC ЗОЮ, выпущенной в декабре 2000 года.

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

Одной из целей разработчиков NFS была поддержка неоднородных систем с клиентами и серверами, работающими под управлением различных ОС на различной аппаратной платформе. Этой цели способствует реализация NFS на основе механизма Sun RFC, поддерживающего по умолчанию средства XDR для унифицированного представления аргументов удаленных процедур.

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

Основная идея NFS - позволить произвольной группе пользователей разделять общую файловую систему. Чаще всего все пользователи принадлежат одной локальной сети, но не обязательно. Можно выполнять NFS и на глобальной сети. Каждый NFS-сервер предоставляет один или более своих каталогов для доступа удаленным клиентам. Каталог объявляется достудным со всеми своими подкаталогами. Список каталогов, которые сервер передает, содержится в файле /etc/exports, так что эти каталоги экспортируются сразу автоматически при загрузке сервера. Клиенты получают доступ к экспортируемым каталогам путем монтирования. Многие рабочие станции Sun бездисковые, но и в этом случае можно монтировать удаленную файловую систему к корневому каталогу, при этом вся файловая система целиком располагается на сервере. Выполнение программ почти не зависит от того, где расположен файл: локально или на удаленном диске. Если два или более клиента одновременно смонтировали один и тот же каталог, то они могут связываться путем разделения файла.

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

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

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

Второй NFS-протокол используется для доступа к удаленным файлам и каталогам. Клиенты могут послать запрос серверу для выполнения какого-либо действия над каталогом или операции чтения или записи файла. Кроме того, они могут запросить атрибуты файла, такие как тип, размер, время создания и модификации. NFS поддерживается большая часть системных вызовов UNIX, за исключением open и close. Исключение open и close не случайно. Вместо операции открытия удаленного файла клиент посылает серверу сообщение, содержащее имя файла, с запросом отыскать его (lookup) и вернуть дескриптор файла. В отличие от вызова open вызов lookup не копирует никакой информации во внутренние системные таблицы. Вызов read содержит дескриптор того файла, который нужно читать, смещение в уже читаемом файле и количество байт, которые нужно прочитать. Преимуществом такой схемы является то, что сервер не запоминает ничего об открытых файлах. Таким образом, если сервер откажет, а затем будет восстановлен, информация об открытых файлах не потеряется, потому что она не поддерживается.

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

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

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

Репликация в NFS не поддерживается.

Служба каталогов

Назначение и принципы организации

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

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

• Одной из наиболее часто выполняемых в системе задач, опирающихся на справочную информацию о пользователях, является их аутентификация, на основе которой затем выполняется авторизация доступа. В сети должны каким-то образом централизованно храниться учетные записи пользователей, содержащие имена и пароли.
• Наличия некоторой централизованной базы данных требует поддержка прозрачности доступа ко многим сетевым ресурсам. В такой базе должны храниться имена этих ресурсов и отображения имен на числовые идентификаторы (например, IP-адреса), позволяющие найти этот ресурс в сети. Прозрачность может обеспечиваться при доступе к серверам, томам файловой системы, интерфейсам процедур RPC, программным объектам распределенных приложений и многим другим сетевым ресурсам.
• Электронная почта является еще одним популярным примером службы, для которой желательна единая для сети справочная служба, хранящая данные о почтовых именах пользователей.
• В последнее время в сетях все чаще стали применяться средства управления качеством обслуживания трафика (Quality of Service, QoS), которые также требуют наличия сведений обо всех пользователях и приложениях системы, их требованиях к параметрам качества обслуживания трафика, а также обо всех сетевых устройствах, с помощью которых можно управлять трафиком (маршрутизаторах, коммутаторах, шлюзах и т. п.).
• Организация распределенных приложений может существенно упроститься, если в сети имеется база, хранящая информацию об имеющихся программных модулях-объектах и их расположении на серверах сети. Приложение, которому необходимо выполнить некоторое стандартное действие, обращается с запросом к такой базе и получает адрес программного объекта, имеющего возможность выполнить требуемое действие.
• Система управления сетью должна располагать базой для хранения информации о топологии сети и характеристиках всех сетевых элементов, таких как маршрутизаторы, коммутаторы, серверы и клиентские компьютеры. Наличие полной информации о составе сети и ее связях позволяет системе автоматизированного управления сетью правильно идентифицировать сообщения об аварийных событиях и находить их первопричину. Упорядоченная по подразделениям предприятия информация об имеющемся сетевом оборудовании и установленном программном обеспечении полезна сама по себе, так как помогает администраторам составить достоверную картину состояния сети и разработать планы по ее развитию.

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

Однако это возражение справедливо только для сетей небольших и средних размеров, в крупных сетях отдельные локальные базы справочной информации теряют свою эффективность. Хорошим примером, подтверждающим неприменимость локальных решений для крупных сетей, является служба имен DNS, работающая в Интернете. Как только размеры Интернета превысили определенный предел, хранить информацию о соответствии имен и IP-адресов компьютеров сети в локальных текстовых файлах стало неэффективно. Потребовалось создать распределенную базу данных, поддерживаемую иерархически связанными серверами имен, и централизованную службу над этой базой, чтобы процедуры разрешения символьных имен в Интернете стали работать быстро и эффективно.

Для крупной сети неэффективным является также применение большого числа справочных служб узкого назначения: одной для аутентификации, другой - для управления сетью, третей - для разрешения имен компьютеров и т. д. Даже если каждая из таких служб хорошо организована и сочетает централизованный интерфейс с распределенной базой данных, большое число справочных служб приводит к дублированию больших объемов информации и усложняет администрирование и управление сетью. Например, в Windows NT имеется по крайней мере пять различных типов справочных баз данных. Главный справочник домена (NT Domain Directory Service) хранит информацию о пользователях, которая требуется при организации их логического входа в сеть. Данные о тех же пользователях могут содержаться и в другом справочнике, используемом электронной почтой Microsoft Mail. Еще три базы данных поддерживают разрешение адресов: WINS устанавливает соответствие Netbios-имен IP-адресам, справочник DNS (сервер имен домена) оказывается полезным при подключении NT-сети к Интернету, и наконец, справочник протокола DHCP используется для автоматического назначения IP-адресов компьютерам сети. Очевидно, что такое разнообразие справочных служб усложняет жизнь администратора и приводит к дополнительным ошибкам, когда учетные данные одного и того же пользователя нужно ввести в несколько баз данных. Поэтому в новой версии Windows 2000 большая часть справочной информации о системе может храниться службой Active Directory - единой централизованной справочной службой, использующей распределенную базу данных и интегрированной со службой имен DNS.

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

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

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

Существуют два популярных стандарта для служб каталогов. Во-первых, это стандарт Х.500, разработанный ITU-T (во время разработки стандарта эта организация носила имя CCITT). Этот стандарт определяет функции, организацию справочной службы и протокол доступа к ней. Разработанный в первую очередь для использования вместе с почтовой службой Х.400 стандарт Х.500 позволяет эффективно организовать хранение любой справочной информации и служит хорошей основой для универсальной службы каталогов сети.

Другим стандартом является стандарт LDAP (Light-weight Directory Access Protocol), разработанный сообществом Интернета. Этот стандарт определяет упрощенный протокол доступа к службе каталогов, так как службы, построенные на основе стандарта Х.500, оказались чересчур громоздкими. Протокол LDAP получил широкое распространение и стал стандартом де-факто в качестве протокола доступа клиентов к ресурсам справочной службы.

Существует также несколько практических реализаций служб каталогов для сетевых ОС. Наибольшее распространение получила служба NDS компании Novell, разработанная в 1993 году для сетевой ОС NetWare 4.0, а сегодня реализованная также и для Windows NT/2000. Большой интерес вызывает служба каталогов Active Directory, разработанная компанией Microsoft для Windows 2000. Обе эти службы поддерживают протокол доступа LDAP и могут работать в очень крупных сетях благодаря своей распределенности.

Служба каталогов NDS

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

База данных NDS заменила в свое время справочник bindery предыдущих версий NetWare. Справочник bindery - это «плоская», или одноуровневая база данных, разработанная для поддержки одного сервера. В ней также использовалось понятие «объект» для сетевого ресурса, но трактовка этого термина отличалась от общепринятой. Объекты bindery идентифицировались простыми числовыми значениями и имели определенные атрибуты. Однако для этих объектов не определялись явные взаимоотношения наследования классов объектов, поэтому взаимоотношения между объектами bindery устанавливались администратором произвольно, что часто приводило к нарушению целостности данных.

База данных службы NDS представляет собой многоуровневую базу данных, поддерживающую информацию о ресурсах всех серверов сети. Для совместимости с предыдущими версиями NetWare в службе NDS предусмотрен механизм эмуляции базы bindery.

Служба NDS - это значительный шаг вперед по сравнению с предыдущими версиями за счет:

• распределенности;
• реплицируемости;
• прозрачности;
• глобальности.

Распределенность заключается в том, что информация не хранится на одном сервере, а разделена на части, называемые разделами (partitions). NetWare хранит эти разделы на нескольких серверах сети (рис. 10.8). Это свойство значительно упрощает администрирование и управление большой сетью, так как она представляется администратору единой системой. Кроме того, обеспечивается более быстрый доступ к базе данных сетевых ресурсов за счет обращения к ближайшему серверу.

Рис. 10.8. Разделы базы данных NDS

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

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

Глобальность NDS заключается в том, что после входа вы получаете доступ к ресурсам всей сети, а не только одного сервера, как было в предыдущих версиях. Это достигается за счет процедуры глобального логического входа (global login). Вместо входа в отдельный сервер пользователь NDS входит в сеть, после чего он получает доступ к разрешенным для него ресурсам сети. Информация, предоставляемая во время логического входа, используется для идентификации пользователя. Позже, при попытке пользователя получить доступ к ресурсам, таким как серверы, тома или принтеры, фоновый процесс идентификации проверяет, имеет ли пользователь право на данный ресурс.

Доброго времени, читатели и гости . Очень большой перерыв между постами был, но я снова в бою). В сегодняшней статье рассмотрю работу протокола NFS , а так же настройку сервера NFS и клиента NFS на Linux .

Введение в NFS

NFS (Network File System - сетевая файловая система ) по моему мнению - идеальное решение в локальной сети, где необходим быстрый (более быстрый по сравнению с SAMBA и менее ресурсоемкий по сравнению с удаленными файловыми системами с шифрованием - sshfs, SFTP, etc...) обмен данными и во главе угла не стоит безопасность передаваемой информации. Протокол NFS позволяет монтировать удалённые файловые системы через сеть в локальное дерево каталогов , как если бы это была примонтирована дисковая файловая система. Тем самым локальные приложения могут работать с удаленной файловой системой, как с локальной. Но нужно быть осторожным (!) с настройкой NFS , ибо при определенной конфигурации можно подвесить операционную систему клиента в ожидании бесконечного ввода/вывода. Протокол NFS основан на работе протокола RPC , который пока не поддается моему пониманию)) поэтому материал в статье будет немного расплывчат... Прежде, чем Вы сможете использовать NFS, будь это сервер или клиент, Вы должны удостовериться, что Ваше ядро имеет поддержку файловой системы NFS. Проверить поддерживает ли ядро файловую систему NFS можно, просмотрев наличие соответствующих строк в файле /proc/filesystems :

ARCHIV ~ # grep nfs /proc/filesystems nodev nfs nodev nfs4 nodev nfsd

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

История Network File System

Протокол NFS разработан компанией Sun Microsystems и имеет в своей истории 4 версии. NFSv1 была разработана в 1989 и являлась экспериментальной, работала на протоколе UDP. Версия 1 описана в . NFSv2 была выпущена в том же 1989 г., описывалась тем же RFC1094 и так же базировалась на протоколе UDP, при этом позволяла читать не более 2Гб из файла. NFSv3 доработана в 1995 г. и описана в . Основными нововведениями третьей версии стало поддержка файлов большого размера, добавлена поддержка протокола TCP и TCP-пакетов большого размера, что существенно ускорило работоспосбоность технологии. NFSv4 доработана в 2000 г. и описана в RFC 3010, в 2003 г. пересмотрена и описана в . Четвертая версия включила в себя улучшение производительности, поддержку различных средств аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов). NFS версии v4.1 была одобрена IESG в 2010 г., и получила номер . Важным нововведением версии 4.1, является спецификация pNFS - Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в стандарте сетевой файловой системы поможет строить распределённые «облачные» («cloud») хранилища и информационные системы.

NFS сервер

Так как у нас NFS - это сетевая файловая система, то необходимо . (Так же можно почитать статью ). Далее необходимо . В Debian это пакет nfs-kernel-server и nfs-common , в RedHat это пакет nfs-utils . А так же, необходимо разрешить запуск демона на необходимых уровнях выполнения ОС (команда в RedHat - /sbin/chkconfig nfs on , в Debian - /usr/sbin/update-rc.d nfs-kernel-server defaults ).

Установленные пакеты в Debian запускается в следующем порядке:

ARCHIV ~ # ls -la /etc/rc2.d/ | grep nfs lrwxrwxrwx 1 root root 20 Окт 18 15:02 S15nfs-common -> ../init.d/nfs-common lrwxrwxrwx 1 root root 27 Окт 22 01:23 S16nfs-kernel-server -> ../init.d/nfs-kernel-server

То есть, сначала запускается nfs-common , затем сам сервер nfs-kernel-server . В RedHat ситуация аналогичная, за тем лишь исключением, что первый скрипт называется nfslock , а сервер называется просто nfs . Про nfs-common нам сайт debian дословно говорит следующее: общие файлы для клиента и сервера NFS, этот пакет нужно устанавливать на машину, которая будет работать в качестве клиента или сервера NFS. В пакет включены программы: lockd, statd, showmount, nfsstat, gssd и idmapd . Просмотрев содержимое скрипта запуска /etc/init.d/nfs-common можно отследить следующую последовательность работы: скрипт проверяет наличие исполняемого бинарного файла /sbin/rpc.statd , проверяет наличие в файлах /etc/default/nfs-common , /etc/fstab и /etc/exports параметров, требующих запуск демонов idmapd и gssd , запускает демона /sbin/rpc.statd , далее перед запуском /usr/sbin/rpc.idmapd и /usr/sbin/rpc.gssd проверяет наличие этих исполняемых бинарных файлов, далее для демона /usr/sbin/rpc.idmapd проверяет наличие sunrpc, nfs и nfsd , а так же поддержку файловой системы rpc_pipefs в ядре (то есть наличие ее в файле /proc/filesystems ), если все удачно, то запускает /usr/sbin/rpc.idmapd . Дополнительно, для демона /usr/sbin/rpc.gssd проверяет модуль ядра rpcsec_gss_krb5 и запускает демон.

Если просмотреть содержимое скрипта запуска NFS-сервера на Debian (/etc/init.d/nfs-kernel-server ), то можно проследить следующую последовательность: при старте, скрипт проверяет существование файла /etc/exports , наличие nfsd , наличие поддержки файловой системы NFS в (то есть в файле /proc/filesystems ), если все на месте, то запускается демон /usr/sbin/rpc.nfsd , далее проверяет задан ли параметр NEED_SVCGSSD (задается в файле настроек сервера /etc/default/nfs-kernel-server ) и, если задан - запускает демона /usr/sbin/rpc.svcgssd , последним запускает демона /usr/sbin/rpc.mountd . Из данного скрипта видно, что работа сервера NFS состоит из демонов rpc.nfsd, rpc.mountd и если используется Kerberos-аутентификация, то и демон rcp.svcgssd. В краснойшляпе еще запускается демон rpc.rquotad и nfslogd (В Debian я почему-то не нашел информации об этом демоне и о причинах его отсутствия, видимо удален...).

Из этого становиться понятно, что сервер Network File System состоит из следующих процессов (читай - демонов) , расположенных в каталогах /sbin и /usr/sbin:

В NFSv4 при использовании Kerberos дополнительно запускаются демоны:

• rpc.gssd - Демон NFSv4 обеспечивает методы аутентификации через GSS-API (Kerberos-аутентификация). Работает на клиенте и сервере.
• rpc.svcgssd - Демон сервера NFSv4, который обеспечивает проверку подлинности клиента на стороне сервера.

portmap и протокол RPC (Sun RPC)

Кроме указанных выше пакетов, для корректной работы NFSv2 и v3 требуется дополнительный пакет portmap (в более новых дистрибутивах заменен на переименован в rpcbind ). Данный пакет обычно устанавливается автоматически с NFS как зависимый и реализует работу сервера RPС, то есть отвечает за динамическое назначение портов для некоторых служб, зарегистрированных в RPC сервере. Дословно, согласно документации - это сервер, который преобразует номера программ RPC (Remote Procedure Call) в номера портов TCP/UDP. portmap оперирует несколькими сущностями: RPC-вызовами или запросами , TCP/UDP портами , версией протокола (tcp или udp), номерами программ и версиями программ . Демон portmap запускается скриптом /etc/init.d/portmap до старта NFS-сервисов.

Коротко говоря, работа сервера RPC (Remote Procedure Call) заключается в обработке RPC-вызовов (т.н. RPC-процедур) от локальных и удаленных процессов. Используя RPC-вызовы, сервисы регистрируют или удаляют себя в/из преобразователя портов (он же отображатель портов, он же portmap, он же portmapper, он же, в новых версиях, rpcbind), а клиенты с помощью RPC-вызовов направляя запросы к portmapper получают необходимую информацию. Юзер-френдли названия сервисов программ и соответствующие им номера определены в файле /etc/rpc. Как только какой-либо сервис отправил соответствующий запрос и зарегистрировал себя на сервере RPC в отображателе портов, RPC-сервер присваивает сопоставляет сервису TCP и UDP порты на которых запустился сервис и хранит в себе ядре соответствующую информацию о работающем сервисе (о имени), уникальном номере сервиса (в соответствии с /etc/rpc) , о протоколе и порте на котором работает сервис и о версии сервиса и предоставляет указанную информацию клиентам по запросу. Сам преобразователь портов имеет номер программы (100000), номер версии - 2, TCP порт 111 и UDP порт 111. Выше, при указании состава демонов сервера NFS я указал основные RPC номера программ. Я, наверно, немного запутал Вас данным абзацем, поэтому произнесу основную фразу, которая должна внести ясность: основная функция отображателя портов заключается в том, чтобы по запросу клиента, который предоставил номер RPC-программы (или RPC-номер программы) и версию, вернуть ему (клиенту) порт, на котором работает запрошенная программа . Соответственно, если клиенту нужно обратиться к RPC с конкретным номером программы, он сначала должен войти в контакт с процессом portmap на серверной машине и определить номер порта связи с необходимым ему сервисом RPC.

Работу RPC-сервера можно представить следующими шагами:

1. Преобразователь портов должен стартовать первым, обычно при загрузке системы. При этом создается конечная точка TCP и осуществляется открытие TCP порта 111. Также создается конечная точка UDP, которая находится в ожидании, когда на UDP порт 111 прибудет UDP датаграмма.
2. При старте программа, работающая через сервер RPC создает конечную точку TCP и конечную точку UDP для каждой поддерживаемой версии программы. (Сервер RPC может поддерживать несколько версий. Клиент указывает требуемую версию при посылке RPC-вызова.) Динамически назначаемый номер порта закрепляется за каждой версией сервиса. Сервер регистрирует каждую программу, версию, протокол и номер порта, осуществляя соответствуюoий RPC-вызов.
3. Когда программе клиента RPC необходимо получить необходимую информацию, она вызывает вызов процедуру преобразователя портов, чтобы получить динамически назначаемый номер порта для заданной программы, версии и протокола.
4. В ответ на этот запрос север возвращает номер порта.
5. Клиент отправляет сообщение RPC-запрос на номер порта, полученный в пункте 4. Если используется UDP, клиент просто посылает UDP датаграмму, содержащую сообщение RPC-вызова, на номер UDP порта, на котором работает запрошенный сервис. В ответ сервис отправляет UDP датаграмму, содержащую сообщение RPC отклика. Если используется TCP, клиент осуществляет активное открытие на номер TCP порта требуемого сервиса и затем посылает сообщение вызова RPC по установленному соединению. Сервер отвечает сообщением отклика RPC по соединению.

Для получения информации от RPC-сервера используется утилита rpcinfo . При указании параметров -p host программа выводит список всех зарегистрированных RPC программ на хосте host. Без указания хоста программа выведет сервисы на localhost. Пример:

ARCHIV ~ # rpcinfo -p прог-ма верс прото порт 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 59451 status 100024 1 tcp 60872 status 100021 1 udp 44310 nlockmgr 100021 3 udp 44310 nlockmgr 100021 4 udp 44310 nlockmgr 100021 1 tcp 44851 nlockmgr 100021 3 tcp 44851 nlockmgr 100021 4 tcp 44851 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100005 1 udp 51306 mountd 100005 1 tcp 41405 mountd 100005 2 udp 51306 mountd 100005 2 tcp 41405 mountd 100005 3 udp 51306 mountd 100005 3 tcp 41405 mountd

Как видно, rpcinfo отображает (в столбиках слева направо) номер зарегистрированной программы, версию, протокол, порт и название. С помощью rpcinfo можно удалить регистрацию программы или получить информацию об отдельном сервисе RPC (больше опций в man rpcinfo). Как видно, зарегистрированы демоны portmapper версии 2 на udp и tcp портах, rpc.statd версии 1 на udp и tcp портах, NFS lock manager версий 1,3,4, демон nfs сервера версии 2,3,4, а так же демон монтирования версий 1,2,3.

NFS сервер (точнее демон rpc.nfsd) получает запросы от клиента в виде UDP датаграмм на порт 2049. Несмотря на то, что NFS работает с преобразователем портов, что позволяет серверу использовать динамически назначаемые порты, UDP порт 2049 жестко закреплен за NFS в большинстве реализаций.

Работа протокола Network File System

Монтирование удаленной NFS

Процесс монтирования удаленной файловой системы NFS можно представить следующей схемой:

Описание протокола NFS при монтировании удаленного каталога:

1. На сервере и клиенте запускается RPC сервер (обычно при загрузке), обслуживанием которого занимается процесс portmapper и регистрируется на порту tcp/111 и udp/111.
2. Запускаются сервисы (rpc.nfsd,rpc.statd и др.), которые регистрируются на RPC сервере и регистрируются на произвольных сетевых портах (если в настройках сервиса не задан статичный порт).
3. команда mount на компьютере клиента отправляет ядру запрос на монтирование сетевого каталога с указанием типа файловой системы, хоста и собственно - каталога, ядро отправляет формирует RPC-запрос процессу portmap на NFS сервере на порт udp/111 (если на клиенте не задана опция работать через tcp)
4. Ядро сервера NFS опрашивает RPC о наличии демона rpc.mountd и возвращает ядру клиента сетевой порт, на котором работает демон.
5. mount отправляет RPC запрос на порт, на котором работает rpc.mountd. Теперь NFS сервер может проверить достоверность клиента основываясь на его IP адресе и номере порта, чтобы убедиться, можно ли этому клиенту смонтировать указанную файловую систему.
6. Демон монтирования возвращает описание запрошенной файловой системы.
7. Команда mount клиента выдает системный вызов mount, чтобы связать описатель файла, полученный в шаге 5, с локальной точкой монтирования на хосте клиента. Описатель файла хранится в коде NFS клиента, и с этого момента любое обращение пользовательских процессов к файлам на файловой системе сервера будет использовать описатель файла как стартовую точку.

Обмен данными между клиентом и сервером NFS

Типичный доступ к удаленной файловой системе можно описать следующей схемой:

Описание процесса обращения к файлу, расположенному на сервере NFS:

1. Клиенту (пользовательскому процессу) безразлично, получает ли он доступ к локальному файлу или к NFS файлу. Ядро занимается взаимодействием с железом через модули ядра или встроенные системные вызовы.
2. Модуль ядра kernel/fs/nfs/nfs.ko, который выполняет функции NFS клиента отправляет RPC запросы NFS серверу через модуль TCP/IP. NFS обычно использует UDP, однако более новые реализации могут использовать TCP.
3. NFS сервер получает запросы от клиента в виде UDP датаграмм на порт 2049. Несмотря на то, что NFS может работать с преобразователем портов, что позволяет серверу использовать динамически назначаемые порты, UDP порт 2049 жестко закреплен за NFS в большинстве реализаций.
4. Когда NFS сервер получает запрос от клиента, он передаётся локальной подпрограмме доступа к файлу, которая обеспечивает доступ к локальному диску на сервере.
5. Результат обращения диску возвращается клиенту.

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

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

• /etc/exports - основной конфигурационный файл, хранящий в себе конфигурацию экспортированных каталогов. Используется при запуске NFS и утилитой exportfs.
• /var/lib/nfs/xtab - содержит список каталогов, монтированных удаленными клиентами. Используется демоном rpc.mountd, когда клиент пытается смонтировать иерархию (создается запись о монтировании).
• /var/lib/nfs/etab - список каталогов, которые могут быть смонтированы удаленными системами с указанием всех параметров экспортированных каталогов.
• /var/lib/nfs/rmtab - список каталогов, которые не разэкспортированы в данный момент.
• /proc/fs/nfsd - специальная файловая система (ядро 2.6) для управления NFS сервером.
  • exports - список активных экспортированных иерархий и клиентов, которым их экспортировали, а также параметры. Ядро получает данную информацию из /var/lib/nfs/xtab.
  • threads - содержит число потоков (также можно изменять)
  • с помощью filehandle можно получить указатель на файл
  • и др...
• /proc/net/rpc - содержит "сырую" (raw) статистику, которую можно получить с помощью nfsstat, а также различные кеши.
• /var/run/portmap_mapping - информация о зарегистрированных в RPC сервисах

Прим: вообще, в интернете куча трактовок и формулировок назначения файлов xtab, etab, rmtab, кому верить - не знаю Даже на http://nfs.sourceforge.net/ трактовка не однозначна.

Настройка файла /etc/exports

В простейшем случае, файл /etc/exports является единственным файлом, требующим редактирования для настройки NFS-сервера. Данный файл управляет следующими аспектами:

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

Каждая строка файла exports имеет следующий формат:

точка_экспорта клиент1 (опции ) [клиент2(опции) ...]

Где точка_экспорта абсолютный путь экспортируемой иерархии каталогов, клиент1 - n имя одного или более клиентов или IP-адресов, разделенные пробелами, которым разрешено монтировать точку_экспорта . Опции описывают правила монтирования для клиента , указанного перед опциями .

Вот типичный пример конфигурации файла exports:

ARCHIV ~ # cat /etc/exports /archiv1 files(rw,sync) 10.0.0.1(ro,sync) 10.0.230.1/24(ro,sync)

В данном примере компьютерам files и 10.0.0.1 разрешен доступ к точке экспорта /archiv1, при этом, хосту files на чтение/запись, а для хоста 10.0.0.1 и подсети 10.0.230.1/24 доступ только на чтение.

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

• Имена отдельных узлов описываются, как files или files.DOMAIN.local.
• Описание маски доменов производится в следующем формате: *DOMAIN.local включает все узлы домена DOMAIN.local.
• Подсети задаются в виде пар адрес IP/маска. Например: 10.0.0.0/255.255.255.0 включает все узлы, адреса которых начинаются с 10.0.0.
• Задание имени сетевой группы @myclients имеющей доступ к ресурсу (при использовании сервера NIS)

Общие опции экспорта иерархий каталогов

В файле exports используются следующие общие опции (сначала указаны опции применяемые по-умолчанию в большинстве систем, в скобках - не по-умолчанию):

• auth_nlm (no_auth_nlm) или secure_locks (insecure_locks) - указывает, что сервер должен требовать аутентификацию запросов на блокировку (с помощью протокола NFS Lock Manager (диспетчер блокировок NFS)).
• nohide (hide) - если сервер экспортирует две иерархии каталогов, при этом одна вложенна (примонтированна) в другую. Клиенту необходимо явно смонтировать вторую (дочернюю) иерархию, иначе точка монтирования дочерней иерархии будет выглядеть как пустой каталог. Опция nohide приводит к появлению второй иерархии каталогов без явного монтирования. (прим: я данную опцию так и не смог заставить работать...)
• ro (rw) - Разрешает только запросы на чтение (запись). (в конечном счете - возможно прочитать/записать или нет определяется на основании прав файловой системы, при этом сервер не способен отличить запрос на чтение файла от запроса на исполнение, поэтому разрешает чтение, если у пользователя есть права на чтение или исполнение.)
• secure (insecure) - требует, чтобы запросы NFS поступали с защищенных портов (< 1024), чтобы программа без прав root не могла монтировать иерархию каталогов.
• subtree_check (no_subtree_check) - Если экспортируется подкаталог фаловой системы, но не вся файловая система, сервер проверяет, находится ли запрошенный файл в экспортированном подкаталоге. Отключение проверки уменьшает безопасность, но увеличивает скорость передачи данных.
• sync (async) - указывает, что сервер должен отвечать на запросы только после записи на диск изменений, выполненных этими запросами. Опция async указывает серверу не ждать записи информации на диск, что повышает производительность, но понижает надежность, т.к. в случае обрыва соединения или отказа оборудования возможна потеря информации.
• wdelay (no_wdelay) - указывает серверу задерживать выполнение запросов на запись, если ожидается последующий запрос на запись, записывая данные более большими блоками. Это повышает производительность при отправке больших очередей команд на запись. no_wdelay указывает не откладывать выполнение команды на запись, что может быть полезно, если сервер получает большое количество команд не связанных друг с другом.

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

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

Опции по умолчанию в разных системах могут различаться, их можно посмотреть в файле /var/lib/nfs/etab. После описания экспортированного каталога в /etc/exports и перезапуска сервера NFS все недостающие опции (читай: опции по-умолчанию) будут отражены в файле /var/lib/nfs/etab.

Опции отображения (соответствия) идентификаторов пользователей

Для большего понимания нижесказанного я бы посоветовал ознакомиться со статьей . Каждый пользователь Linux имеет свои UID и главный GID, которые описаны в файлах /etc/passwd и /etc/group . Сервер NFS считает, что операционная система удаленного узла выполнила проверку подлинности пользователей и назначила им корректные идентификаторы UID и GID. Экспортирование файлов дает пользователям системы клиента такой же доступ к этим файлам, как если бы они регистрировались напрямую на сервере. Соответственно, когда клиент NFS посылает запрос серверу, сервер использует UID и GID для идентификации пользователя в локальной системе, что может приводить к некоторым проблемам:

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

Следующие опции задают правила отображения удаленных пользователей в локальных:

• root_squash (no_root_squash) - При заданной опции root_squash , запросы от пользователя root отображаются на анонимного uid/gid, либо на пользователя, заданного в параметре anonuid/anongid.
• no_all_squash (all_squash) - Не изменяет UID/GID подключающегося пользователя. Опция all_squash задает отображение ВСЕХ пользователей (не только root), как анонимных или заданных в параметре anonuid/anongid.
• anonuid=UID и anongid=GID - Явно задает UID/GID для анонимного пользователя.
• map_static=/etc/file_maps_users - Задает файл, в котором можно задать сопоставление удаленных UID/GID - локальным UID/GID.

Пример использования файла маппинга пользователей:

ARCHIV ~ # cat /etc/file_maps_users # Маппинг пользователей # remote local comment uid 0-50 1002 # сопоставление пользователей с удаленным UID 0-50 к локальному UID 1002 gid 0-50 1002 # сопоставление пользователей с/span удаленным GID 0-50 к локальному GID 1002

Управление сервером NFS

Управление сервером NFS осуществляется с помощью следующих утилит:

• nfsstat
• showmsecure (insecure)ount

nfsstat: статистика NFS и RPC

Утилита nfsstat позволяет посмотреть статистику RPC и NFS серверов. Опции команды можно посмотреть в man nfsstat .

showmount: вывод информации о состоянии NFS

Утилита showmount запрашивает демон rpc.mountd на удалённом хосте о смонтированных файловых системах. По умолчанию выдаётся отсортированный список клиентов. Ключи:

• --all - выдаётся список клиентов и точек монтирования с указанием куда клиент примонтировал каталог. Эта информация может быть не надежной.
• --directories - выдаётся список точек монтирования
• --exports - выдаётся список экспортируемых файловых систем с точки зрения nfsd

При запуске showmount без аргументов, на консоль будет выведена информация о системах, которым разрешено монтировать локальные каталоги. Например, хост ARCHIV нам предоставляет список экспортированных каталогов с IP адресами хостов, которым разрешено монтировать указанные каталоги:

FILES ~ # showmount --exports archiv Export list for archiv: /archiv-big 10.0.0.2 /archiv-small 10.0.0.2

Если указать в аргументе имя хоста/IP, то будет выведена информация о данном хосте:

ARCHIV ~ # showmount files clnt_create: RPC: Program not registered # данное сообщение говорит нам, что на хосте FILES демон NFSd не запущен

exportfs: управление экспортированными каталогами

Данная команда обслуживает экспортированные каталоги, заданные в файле /etc/exports , точнее будет написать не обслуживает, а синхронизирует с файлом /var/lib/nfs/xtab и удаляет из xtab несуществующие. exportfs выполняется при запуске демона nfsd с аргументом -r. Утилита exportfs в режиме ядра 2.6 общается с демоном rpc.mountd через файлы каталога /var/lib/nfs/ и не общается с ядром напрямую. Без параметров выдаёт список текущих экспортируемых файловых систем.

Параметры exportfs:

• [клиент:имя-каталога] - добавить или удалить указанную файловую систему для указанного клиента)
• -v - выводить больше информации
• -r - переэкспортировать все каталоги (синхронизировать /etc/exports и /var/lib/nfs/xtab)
• -u - удалить из списка экспортируемых
• -a - добавить или удалить все файловые системы
• -o - опции через запятую (аналогичен опциям применяемым в /etc/exports; т.о. можно изменять опции уже смонтированных файловых систем)
• -i - не использовать /etc/exports при добавлении, только параметры текущей командной строки
• -f - сбросить список экспортируемых систем в ядре 2.6;

Клиент NFS

Прежде чем обратиться к файлу на удалённой файловой системе клиент (ОС клиента) должен смонтировать её и получить от сервера указатель на неё . Монтирование NFS может производиться с помощью или с помощью одного из расплодившихся автоматических монтировщиков (amd, autofs, automount, supermount, superpupermount). Процесс монтирования хорошо продемонстрирована выше на иллюстрации.

На клиентах NFS никаких демонов запускать не нужно, функции клиента выполняет модуль ядра kernel/fs/nfs/nfs.ko , который используется при монтировании удаленной файловой системы. Экспортированные каталоги с сервера могут монтироваться на клиенте следующими способами:

• вручную, с помощью команды mount
• автоматически при загрузке, при монтировании файловых систем, описанных в /etc/fstab
• автоматически с помощью демона autofs

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

Монтирование файловой системы Network Files System командой mount

Пример использования команды mount представлен в посте . Тут я рассмотрю пример команды mount для монтирования файловой системы NFS:

FILES ~ # mount -t nfs archiv:/archiv-small /archivs/archiv-small FILES ~ # mount -t nfs -o ro archiv:/archiv-big /archivs/archiv-big FILES ~ # mount ....... archiv:/archiv-small on /archivs/archiv-small type nfs (rw,addr=10.0.0.6) archiv:/archiv-big on /archivs/archiv-big type nfs (ro,addr=10.0.0.6)

Первая команда монтирует экспортированный каталог /archiv-small на сервере archiv в локальную точку монтирования /archivs/archiv-small с опциями по умолчанию (то есть для чтения и записи). Хотя команда mount в последних дистрибутивах умеет понимать какой тип файловой системы используется и без указания типа, все же указывать параметр -t nfs желательно. Вторая команда монтирует экспортированный каталог /archiv-big на сервере archiv в локальный каталог /archivs/archiv-big с опцией только для чтения (ro ). Команда mount без параметров наглядно отображает нам результат монтирования. Кроме опции только чтения (ro), возможно задать другие основные опции при монтировании NFS :

• nosuid - Данная опция запрещает исполнять программы из смонтированного каталога.
• nodev (no device - не устройство) - Данная опция запрещает использовать в качестве устройств символьные и блочные специальные файлы.
• lock (nolock) - Разрешает блокировку NFS (по умолчанию). nolock отключает блокировку NFS (не запускает демон lockd) и удобна при работе со старыми серверами, не поддерживающими блокировку NFS.
• mounthost=имя - Имя хоста, на котором запущен демон монтирования NFS - mountd.
• mountport=n - Порт, используемый демоном mountd.
• port=n - порт, используемый для подключения к NFS серверу (по умолчанию 2049, если демон rpc.nfsd не зарегистрирован на RPC-сервере). Если n=0 (по умолчанию), то NFS посылает запрос к portmap на сервере, чтобы определить порт.
• rsize=n (read block size - размер блока чтения) - Количество байтов, читаемых за один раз с NFS-сервера. Стандартно - 4096.
• wsize=n (write block size - размер блока записи) - Количество байтов, записываемых за один раз на NFS-сервер. Стандартно - 4096.
• tcp или udp - Для монтирования NFS использовать протокол TCP или UDP соответственно.
• bg - При потери доступа к серверу, повторять попытки в фоновом режиме, чтобы не блокировать процесс загрузки системы.
• fg - При потери доступа к серверу, повторять попытки в приоритетном режиме. Данный параметр может заблокировать процесс загрузки системы повторениями попыток монтирования. По этой причине параметр fg используется преимущественно при отладке.

Опции, влияющие на кэширование атрибутов при монтировании NFS

Атрибуты файлов , хранящиеся в (индексных дескрипторах), такие как время модификации, размер, жесткие ссылки, владелец, обычно изменяются не часто для обычных файлов и еще реже - для каталогов. Многи программы, например ls, обращаются к файлам только для чтения и не меняют атрибуты файлов или содержимое, но затрачивают ресурсы системы на дорогостоящие сетевые операции. Чтобы избежать ненужных затрат ресурсов, можно кэшировать данные атрибуты . Ядро использует время модификации файла, чтобы определить устарел ли кэш, сравнивая время модификации в кэше и время модификации самого файла. Кэш атрибутов периодически обновляется в соответствии с заданными параметрами:

• ac (noac) (attrebute cache - кэширование атрибутов) - Разрешает кэширование атрибутов (по-умолчанию). Хотя опция noac замедляет работу сервера, она позволяет избежать устаревания атрибутов, когда несколько клиентов активно записывают информацию в общию иерархию.
• acdirmax=n (attribute cache directory file maximum - кэширование атрибута максимум для файла каталога) - Максимальное количество секунд, которое NFS ожидает до обновления атрибутов каталога (по-умолчанию 60 сек.)
• acdirmin=n (attribute cache directory file minimum - кэширование атрибута минимум для файла каталога) - Минимальное количество секунд, которое NFS ожидает до обновления атрибутов каталога (по-умолчанию 30 сек.)
• acregmax=n (attribute cache regular file maximum - кэширование атрибута максимум для обычного файла) - Максимаьное количество секунд, которое NFS ожидает до обновления атрибутов обычного файла (по-умолчанию 60 сек.)
• acregmin=n (attribute cache regular file minimum - кэширование атрибута минимум для обычного файла) - Минимальное количество секунд, которое NFS ожидает до обновления атрибутов обычного файла (по-умолчанию 3 сек.)
• actimeo=n (attribute cache timeout - таймаут кэширования атрибутов) - Заменяет значения для всех вышуказаных опций. Если actimeo не задан, то вышеуказанные значения принимают значения по умолчанию.

Опции обработки ошибок NFS

Следующие опции управляют действиями NFS при отсутствии ответа от сервера или в случае возникновения ошибок ввода/вывода:

• fg (bg) (foreground - передний план, background - задний план) - Производить попытки монтирования отказавшей NFS на переднем плане/в фоне.
• hard (soft) - выводит на консоль сообщение "server not responding" при достижении таймаута и продолжает попытки монтирования. При заданной опции soft - при таймауте сообщает вызвавшей операцию программе об ошибке ввода/вывода. (опцию soft советуют не использовать)
• nointr (intr) (no interrupt - не прерывать) - Не разрешает сигналам прерывать файловые операции в жестко смонтированной иерархии каталогов при достижении большого таймаута. intr - разрешает прерывание.
• retrans=n (retransmission value - значение повторной передачи) - После n малых таймаутов NFS генерирует большой таймаут (по-умолчанию 3). Большой таймаут прекращает выполнение операций или выводит на консоль сообщение "server not responding", в зависимости от указания опции hard/soft.
• retry=n (retry value - значение повторно попытки) - Количество минут повторений службы NFS операций монтирования, прежде чем сдаться (по-умолчанию 10000).
• timeo=n (timeout value - значение таймаута) - Количество десятых долей секунды ожидания службой NFS до повторной передачи в случае RPC или малого таймаута (по-умолчанию 7). Это значение увеличивается при каждом таймауте до максимального значения 60 секунд или до наступления большого таймаута. В случае занятой сети, медленного сервера или при прохождении запроса через несколько маршрутизаторов или шлюзов увеличение этого значения может повысить производительность.

Автоматическое монтирование NFS при загрузке (описание файловых систем в /etc/fstab)

Подобрать оптимальный timeo для определенного значения передаваемого пакета (значений rsize/wsize), можно с помощью команды ping:

FILES ~ # ping -s 32768 archiv PING archiv.DOMAIN.local (10.0.0.6) 32768(32796) bytes of data. 32776 bytes from archiv.domain.local (10.0.0.6): icmp_req=1 ttl=64 time=0.931 ms 32776 bytes from archiv.domain.local (10.0.0.6): icmp_req=2 ttl=64 time=0.958 ms 32776 bytes from archiv.domain.local (10.0.0.6): icmp_req=3 ttl=64 time=1.03 ms 32776 bytes from archiv.domain.local (10.0.0.6): icmp_req=4 ttl=64 time=1.00 ms 32776 bytes from archiv.domain.local (10.0.0.6): icmp_req=5 ttl=64 time=1.08 ms ^C --- archiv.DOMAIN.local ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 0.931/1.002/1.083/0.061 ms

Как видно, при отправке пакета размером 32768 (32Kb) время его путешествия от клиента до сервера и обратно плавает в районе 1 миллисекунды. Если данное время будет зашкаливать за 200 мс, то стоит задуматься о повышении значения timeo, чтобы оно превышало значение обмена в три-четыре раза. Соответственно, данный тест желательно делать во время сильной загрузки сети

Запуск NFS и настройка Firewall

Заметка скопипсчена с блога http://bog.pp.ru/work/NFS.html, за что ему огромное спасибо!!!

Запуск сервера NFS, монтирования, блокировки, квотирования и статуса с "правильными" портами (для сетевого экрана)

• желательно предварительно размонтировать все ресурсы на клиентах
• остановить и запретить запуск rpcidmapd, если не планируется использование NFSv4: chkconfig --level 345 rpcidmapd off service rpcidmapd stop
• если нужно, то разрешить запуск сервисов portmap, nfs и nfslock: chkconfig --levels 345 portmap/rpcbind on chkconfig --levels 345 nfs on chkconfig --levels 345 nfslock on
• если нужно, то остановить сервисы nfslock и nfs, запустить portmap/rpcbind, выгрузить модули service nfslock stop service nfs stop service portmap start # service rpcbind start umount /proc/fs/nfsd service rpcidmapd stop rmmod nfsd service autofs stop # где-то потом его надо запустить rmmod nfs rmmod nfs_acl rmmod lockd
• открыть порты в
  • для RPC: UDP/111, TCP/111
  • для NFS: UDP/2049, TCP/2049
  • для rpc.statd: UDP/4000, TCP/4000
  • для lockd: UDP/4001, TCP/4001
  • для mountd: UDP/4002, TCP/4002
  • для rpc.rquota: UDP/4003, TCP/4003
• для сервера rpc.nfsd добавить в /etc/sysconfig/nfs строку RPCNFSDARGS="--port 2049"
• для сервера монтирования добавить в /etc/sysconfig/nfs строку MOUNTD_PORT=4002
• для настройки rpc.rquota для новых версий необходимо добавить в /etc/sysconfig/nfs строку RQUOTAD_PORT=4003
• для настройки rpc.rquota необходимо для старых версий (тем не менее, надо иметь пакет quota 3.08 или свежее) добавить в /etc/services rquotad 4003/tcp rquotad 4003/udp
• проверит адекватность /etc/exports
• запустить сервисы rpc.nfsd, mountd и rpc.rquota (заодно запускаются rpcsvcgssd и rpc.idmapd, если не забыли их удалить) service nfsd start или в новых версиях service nfs start
• для сервера блокировки для новых систем добавить в /etc/sysconfig/nfs строки LOCKD_TCPPORT=4001 LOCKD_UDPPORT=4001
• для сервера блокировки для старых систем добавить непосредственно в /etc/modprobe[.conf]: options lockd nlm_udpport=4001 nlm_tcpport=4001
• привязать сервер статуса rpc.statd к порту 4000 (для старых систем в /etc/init.d/nfslock запускать rpc.statd с ключом -p 4000) STATD_PORT=4000
• запустить сервисы lockd и rpc.statd service nfslock start
• убедиться, что все порты привязались нормально с помощью "lsof -i -n -P" и "netstat -a -n" (часть портов используется модулями ядра, которые lsof не видит)
• если перед "перестройкой" сервером пользовались клиенты и их не удалось размонтировать, то придётся перезапустить на клиентах сервисы автоматического монтирования (am-utils , autofs)

Пример конфигурации NFS сервера и клиента

Конфигурация сервера

Если вы хотите сделать ваш разделённый NFS каталог открытым и с правом записи, вы можете использовать опцию all_squash в комбинации с опциями anonuid и anongid . Например, чтобы установить права для пользователя "nobody" в группе "nobody", вы можете сделать следующее:

ARCHIV ~ # cat /etc/exports # Доступ на чтение и запись для клиента на 192.168.0.100, с доступом rw для пользователя 99 с gid 99 /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99)) # Доступ на чтение и запись для клиента на 192.168.0.100, с доступом rw для пользователя 99 с gid 99 /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99))

Это также означает, что если вы хотите разрешить доступ к указанной директории, nobody.nobody должен быть владельцем разделённой директории:

man mount
man exports
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/nfs_perf.htm - производительность NFS от IBM.

С Уважением, Mc.Sim!

NFS позволяет предоставить общий доступ к каталогам Unix-машины. Небезопасность NFS, и в частности NIS, связана с RPC - по количеству всевозможных эксплоитов RPC представляется негласным лидером (если не считать Sendmail). Так как эти протоколы предназначены для внутренних сетей, защищать их придется от «своих» пользователей. Хотя перед их применением нужно решить, действительно ли они нужны.

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

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

Сетевая файловая система (Network File System, NFS) была разработана компанией Sun как средство доступа к файлам, размещенным на прочих Unix-машинах в пределах локальной сети. При разработке NFS безопасность вообще не учитывалась, что с годами стало причиной многих уязвимостей.

NFS может работать по протоколу TCP или UDP, она использует систему RPC, а это означает, что должны быть запущены следующие часто уязвимые приложения: portmapper, nfs, nlockmgr (lockd), rquotad, statd и mountd.

Не надо запускать NFS - нужно найти альтернативное решение. Если же NFS все-таки нужна, здесь будет рассказано о том, как нужно минимизировать риск ее использования.

/etc/exports

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

Каталоги «на экспорт» определяются в файле /etc/exports. Формат каждой записи прост: имя каталога, список пользователей, которым разрешен доступ и режим доступа. К примеру:

Полный доступ (чтение/запись) к каталогу /home/user разрешен машине с IP-адресом 10.0.0.6. Самое лучшее - это не давать полный доступ, а ограничиться доступом «только чтение» (rо). Кроме данного, можно также указать следующие опции:

• Secure - запрос на монтирование (mount) должен исходить из привилегированного порта (с номером до 1024). Это означает, что команду на монтирование ввел пользователь с привилегиями root.
• Root_squash - запрос пользователя root будет расцениваться как запрос анонимного пользователя. Это позволяет причинить наименьший вред системе. Эта опция должна быть включена.
• All_squash - все запросы (не только от пользователя root) будут расцениваться как исходящие от анонимного пользователя. Полезно применять для публично экспортируемых каталогов.

Если крекер с правами root получит доступ к машине, которой дан rw-доступ к каталогу, указанному в /etc/exports, он получит полный контроль над файловой системой, поэтому нельзя экспортировать корневой каталог (/), и системно-важные каталоги, к примеру /usr, /bin, /sbin, /lib, /opt и /etc. Хорошо для экспорта подходят домашние каталоги пользователей.

Со стороны клиента монтирование общей файловой системы нужно выполнять указанием опции -о nosuid:

# mount -t nfs -о nosuid 10.0.0.3:/home/user/files /mnt/home/frank

Это не даст крекеру, получившему доступ к NFS-серверу, получить root-доступ к клиентам.

Ограничение доступа .

Независимо от сервиса для ограничения доступа к машине нужно применять IPTables. В случае с NFS-сервером это особенно важно. При применении IPTables надо помнить, что NFS-демон использует порт 2049/TCP/UDP.

Некоторые RPC-сервисы, к примеру portmapper и NFS, используют постоянные порты (113 и 2049/tcp/udp соответственно), но у остальных RPC-сервисов порты не постоянны, что затрудняет фильтрацию пакетов с помощью IPTables. Единственное, что известно, - это то, что RPC используют порты в диапазоне 32768-65535.

Если используется ядро 2.4.13 или более новое, то с помощью опции -р <порт> можно точно указать порт для каждого RPC-сервиса.

Рассмотрим функцию start() из файла /etc/rc.d/init.d/nfslock, используемую для запуска nsflock:

start () {

#. Start daemons .

if [ "$USERLAND_LOCKD" ]; then

echo -n $"Starting NFS locking: "

daemon rpc.lockd

echo -n $"Starting NFS statd: "

daemon rpc.statd

echo [ $RETVAL -eq 0 ] && touch /var/touch/lock/subsys/nfslock

return $RETVAL }

Для того, чтобы заставить демон statd употреблять конкретный порт, можно употреблять опцию -р, к примеру daemon rpc.statd -p 32800 (или какой угодно другой - какой больше нравится). Точно так же нужно установить порт для mountd, nfsd, rquotad - все они запускаются из сценария /etc/rc.d/init.d/nfs:

start () {

# Start daemons.

action -n $"Starting NFS services: " /usr/sbin/exportfs -r

if t _x /usr/sbin/rpc.quotad ] ; then echo -n $"Starting NFS quotas: " daemon rpc.rquotad echo

fi echo -n $"Starting NFS mountd: "

daemon rpc.mountd 3RPCMOUNTDOPTS

echo -n $"Starting NFS daemon: " daemon rpc.nfsd $RPCNFSDOPTS echo touch /var/lock/subsys/nfs

Технология изменения порта для lockd (nlockmgr) отличается от вышеприведенной (не надо пытаться изменить файл /etc/rc.d/init.d/nfslock - ничего не выйдет).

Lockd исполнен или как модуль ядра, или вкомпилирован в ядро статически. Для изменения номера порта надо открыть файл /etc/modules и найти опции, передаваемые модулю:

options lockd nlm_udpport=33000 nlm_tcpport=33000

Теперь, когда RPC-сервисы используют статические порты, которые известны, надо применять IPTables. В следующем наборе правил предполагается, что NFS - единственный запущенный на машине сервер, доступ к которому разрешен только машинам, перечисленным в файле /usr/local/etc/nfsexports.hosts:

IPX = "/usr/sbin/iptables"

# Очищаем все цепочки

$IPT --flush

$IPT -t nat --flush $IPT -t mangle --flush $IPT -X

# Разрешаем loopback-трафик $IPT -A INPUT -i lo -j ACCEPT $IPT -A OUTPUT -o lo -j ACCEPT

# Правила по умолчанию $IPT -P INPUT DROP $IPT -P OUTPUT DROP $IPT -P FORWARD DROP

$IPT -A INPUT -m state -state ESTABLISHED,RELATED -j ACCEPT $IPT -A OUTPUT -m state -state NEW,ESTABLISHED,RELATED -j ACCEPT

# Разрешаем доступ каждому компьютеру,

# указанному в /usr/local/etc/nfsexports.hosts

for host in "cat /usr/local/etc/nfsexports.hosts"; do $IPT -I INPUT -s $host -p tcp -dport 111 -j ACCEPT

$IPT -I INPUT -s $host -p udp -dport 111 -j ACCEPT

$IPT -I INPUT -s $host -p udp -dport 2049 -j ACCEPT

$IPT -I INPUT -s $host -p tcp --dport 32800 -j ACCEPT

$IPT -I INPUT -s $host -p tcp --dport 32900 -j ACCEPT

$IPT -I INPUT -s $host -p tcp -dport 33000 -j ACCEPT

$IPT -I INPUT -s $host -p tcp --dport 33100 -j ACCEPT

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

Туннелирование NFS через SSH .

Аббревиатура NFS иногда расшифровывается как «No File Security» - данные три слова говорят сами за себя. Поэтому очень важно обеспечить защиту NFS-трафика. Это легко сделать с помощью ssh.

Начально можно изменить файл /etc/exports на NFS-сервере так, чтобы файловые системы экспортировались локальному узлу:

Затем надо применять SSH для форвардинга портов NFS и mountd. NFS использует порт 2049/udp, a mountd, как было указано, порт с номером 33000:

# ssh [email protected] -L 200: localhost:2049 -f sleep 120m

# ssh [email protected] -L 200: localhost:33000 -f sleep 120m

Данные две команды предоставляют пользователю интерактивную оболочку, но, так как она не нужна, SSH выполняет команду sleep 120: возвращаемся обратно в командную строку, но форвардинг портов будет длиться еще 2 часа.

Монтирование файловой системы со стороны клиента выглядит очень необычно:

mount -t nfs -о nosuid port=200 mountport=210 nfsserver.test.net:/home/user /mnt/another

Если трюки с ssh-тунпелированием слишком сложны, можно применять проект SHFS (Shell Filesystem) (http: //shfs.sourceforge.net/ ), который дает возможность автоматизировать всю эту процедуру.

После установки получить доступ к SHFS надо или с помощью команды mount -t shfs, или с помощью новой команду shfsmount. Синтаксис данной команды похож на предыдущий:

shfsmount [email protected]:/home/user /mnt/user

CFS и TCFS

Криптографическая файловая система (Cryptographic File System) использует прозрачное кодирование и дешифрование NFS-трафика с помощью алгоритма DES. Кроме данного, она поддерживает автоматическое управление ключами, что делает процесс максимально «прозрачным» для пользователя.

Хотя CFS разработана для SunOS и BSD, она порядком интересна, потому что представляется первой попыткой «прозрачного» кодирования общих файлов. Прозрачная криптографическая файловая система (Transparent Cryptographic File System, TCFS) предоставляет еще более прозрачный способ кодирования NFS-трафика.

Кроме кодирования данных, данная файловая система поддерживает проверку целостности данных.