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

Общая организация NFS

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

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

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

История

Протокол NFS имеет в своей истории 4 версии.

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

NFSv3 вышла в июне 1995 года, в ней добавлена поддержка дескрипторов файлов переменного размера до 64 байт (в версии 2 - массив фиксированного размера 32 байта), снято ограничение на 8192 байта в RPC-вызовах чтения и записи (тем самым, размер передаваемого блока в вызовах ограничен только пределом для UDP-датаграммы - 65535 байт), реализована поддержка файлов больших размеров, поддержаны асинхронные вызовы операций записи, к процедурам READ и WRITE добавлены вызовы ACCESS (проверка прав доступа к файлу), MKNOD (создание специального файла Unix), READDIRPLUS (возвращает имена файлов в директории вместе с их атрибутами), FSINFO (возвращает статистическую информацию о файловой системе), FSSTAT (возвращает динамическую информацию о файловой системе), PATHCONF (возвращает POSIX.1-информацию о файле) и COMMIT (передает ранее сделанные асинхронные записи на постоянное хранение). На момент введения версии 3 отмечен рост популярности в среде разработчиков протокола TCP. Некоторые независимые разработчики самостоятельно добавили поддержку протокола TCP для NFS версии 2 в качестве транспортного, Sun Microsystems добавили поддержку TCP в NFS в одном из дополнений к версии 3. С поддержкой TCP повысились практическая осуществимость использования NFS в глобальных сетях.

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

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

Изначальными требованиями при разработке NFS были:

• потенциальная поддержка различных операционных систем (не только UNIX), чтобы серверы и клиенты NFS возможно было бы реализовать в разных операционных системах;
• протокол не должен зависеть от каких-либо определённых аппаратных средств;
• должны быть реализованы простые механизмы восстановления в случае отказов сервера или клиента;
• приложения должны иметь прозрачный доступ к удаленным файлам без использования специальных путевых имен или библиотек и без перекомпиляции;
• для UNIX-клиентов должна поддерживаться семантика UNIX;
• производительность NFS должна быть сравнима с производительностью локальных дисков;
• реализация не должна быть зависимой от транспортных средств.

Принцип работы NFS

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

Протокол NFS определяет набор запросов (операций), которые могут быть направлены клиентом к серверу, а также набор аргументов и возвращаемые значения для каждого из этих запросов. Версия 1 этого протокола существовала только в недрах Sun Microsystems и никогда не была выпущена. Все реализации NFS (в том числе NFSv3) поддерживают версию 2 NFS (NFSv2), которая впервые была выпущена в 1985 году в SunOS 2.0. Версия 3 протокола была опубликована в 1993 году и реализована некоторыми фирмами-поставщиками.

Протокол удаленного вызова процедур (RPC) определяет формат всех взаимодействий между клиентом и сервером. Каждый запрос NFS посылается как пакет RPC. На сервере работают следующие даемоны :

• rpc.nfsd - Основной даемон сервера NFS - nfsd (в новых версиях иногда называется nfsd4). Этот демон обслуживает запросы клиентов NFS. Параметр RPCNFSDCOUNT в файле /etc/default/nfs-kernel-server в Debian и NFSDCOUNT в файле /etc/sysconfig/nfs в RedHat определяет число запускаемых демонов (по-умолчанию - 8). (RPC программа 100003)
• rpc.mountd - Даемон монтирования NFS mountd обрабатывает запросы клиентов на монтирование каталогов. Демон mountd работает на серверах NFS. (RPC программа 100005)
• rpc.statd - Даемон наблюдения за сетевым состоянием (он же Network Status Monitor, он же NSM). Он позволяет корректно отменять блокировку после сбоя/перезагрузки. Для уведомления о сбое использует программу /usr/sbin/sm-notify. Демон statd работает как на серверах, так и на клиентах. Ранее данный сервер был необходим для работы rpc.lockd, но за блокировки сейчас отвечает ядро. (RPC программа 100021 и 100024 - в новых версиях)
• rpc.lockd - Даемон блокировки lockd (он же NFS lock manager (NLM)) обрабатывает запросы на блокировку файлов. Демон блокировки работает как на серверах, так и на клиентах. Клиенты запрашивают блокировку файлов, а серверы ее разрешают. (устарел и в новых дистрибутивах не используется как демон. Его функции в современных дистрибутивах (с ядром старше 2.2.18) выполняются ядра (lockd). (RPC программа 100024)
• rpc.idmapd - Даемон idmapd для NFSv4 на сервере преобразует локальные uid/gid пользователей в формат вида имя@домен, а сервис на клиенте преобразует имена пользователей/групп вида имя@домен в локальные идентификаторы пользователя и группы (согласно конфигурационному файлу /etc/idmapd.conf).

Клиент может запустить также даемон, называемый nfsiod. nfsiod обслуживает запросы, поступающие от сервера от сервера NFS. Он необязателен, увеличивает производительность, однако для нормальной и правильной работы не требуется. В NFSv4 при использовании Kerberos дополнительно запускаются демоны:

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

Даемоны старых версий (NFS v.3 и ниже):

• nfslogd - даемон журналов NFS фиксирует активность для экспортированных файловых систем, работает на серверах NFS
• rpc.rquotad - сервер удаленных квот предоставляет информацию о квотах пользователей в удаленных файловых системах, может работать как на серверах, так и на клиентах.

Кроме указанных выше пакетов, для корректной работы NFSv2 и v3 требуется дополнительный пакет portmap (в более новых дистрибутивах заменен на переименован в rpcbind). Sun 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 получают необходимую информацию.

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

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

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

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

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

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

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

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

Структура папки Root

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

В файле 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

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

• nfsstat
• showmsecure (insecure)ount
• exportfs

Утилита nfsstat позволяет посмотреть статистику RPC и NFS серверов.

showmount

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

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

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

exportfs

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

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

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

Пример команды mount для монтирования файловой системы NFS в Debian:

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

• nosuid - Данная опция запрещает исполнять setuid программы из смонтированного каталога.
• 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
• Атрибуты файлов, хранящиеся в inod (индексных дескрипторах), такие как время модификации, размер, жесткие ссылки, владелец, обычно изменяются не часто для обычных файлов и еще реже - для каталогов. Ядро использует время модификации файла, чтобы определить устарел ли кэш, сравнивая время модификации в кэше и время модификации самого файла.

Кэш атрибутов периодически обновляется в соответствии с заданными параметрами:

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

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

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

• fg (bg) (foreground - передний план, background - задний план) - Производить попытки монтирования отказавшей NFS на переднем плане/в фоне.
• hard (soft) - выводит на консоль сообщение "server not responding" при достижении таймаута и продолжает попытки монтирования. При заданной опции 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

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

Одним из способов повышения производительности NFS - увеличение количества байтов, передаваемых за один раз. Размер в 4096 байт слишком мал для современных быстрых соединений, увеличивая это значение до 8192 и более можно экспериментальным путем найти оптимальную скорость.

Так же, не стоит упускать из внимания и настройки тайм-аутов. NFS ожидает ответа на пересылку данных в течении промежутка времени, указанного в опции timeo, если ответ за это время не получен, то выполняется повторная пересылка. На загруженных и медленных соединениях это время может быть меньше времени реакции сервера и способности каналов связи, в результате чего могут быть излишние повторные пересылки, замедляющие работу.По умолчанию, timeo равно 0,7 сек (700 миллисекунд). после обнаружения факта обрыва связи в течении 700 мс сервер совершит повторную пересылку и удвоит время ожидания до 1,4 сек., увеличение timeo будет продолжаться до максимального значения в 60 сек.

Для раздачи файлов внутри локальной сети можно выделить такие технологии (рассматриваются системы на базе Linux):

• Network File System (NFS) - протокол сетевого доступа к файловым системам;
• Files transferred over Shell protocol (FISH) - сетевой протокол, который использует или RSH для передачи файлов между компьютерами;
• Secure SHell FileSystem (SSHFS) - клиент файловой системы для монтирования дисковых устройств на удаленных системах, для взаимодействия с удаленной системой используется SFTP ;
• Samba - пакет программ, которые позволяют обращаться к сетевым дискам и принтерам на различных операционных системах по протоколу SMB/CIFS;

В данной заметке речь пойдет про NFS .

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

К преимуществам NFS можно отнести:

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

Схема работы NFS протокола.

Установка и настройка NFS-сервер под Linux

Проверим поддерживает ли система NFS

Cat /proc/filesystems | grep nfs

Под Arch Linux сервер и клиент находиться в одном пакете

Yaourt -S nfs-utils

Для установки сервера (nfs-kernel-server ) и клиента (nfs-common ) под Ubuntu необходимы пакеты

Sudo apt-get install nfs-kernel-server nfs-common portmap

Дальше в заметке для сервера будет использоваться IP 192.168.1.100 . Для того что бы за сервером всегда был закреплен один и тот же IP необходимо в DHCP-сервере (чаще всего роутер) указать раздачу конкретного IP конкретному MAC-адресу. Или поднять свой локальный DNS-сервер. Например или .

MAC-адрес можно узнать с помощью ifconfig (поле ether в Arch Linux ).

NFSv4 предполагает что есть корневая директория, внутри которой уже расположены файлы для раздачи. Например, /srv/nfs - корень, /srv/nfs/audio - директория для раздачи музыки. Если не следовать этому новому указанию в версии 4 , то можно получить ошибку при подключении клиентом:

Mount.nfs: access denied by server while mounting 192.168.1.100:/home/proft/torrents

Если все же хочется использовать на сервере подход без корневой-директории для NFS , то при монтировании клиентом надо явно указать версию 3

# для команды mount mount -o "vers=3" 192.168.1.100:/home/proft/torrents /home/proft/nfs/torrents # для fstab 192.168.1.100:/home/proft/torrents /home/proft/nfs/torrents nfs soft,nfsvers=3 0 0

Я буду использовать NFSv4 с root-директорией в /srv/nfs/ и монтированием вложенных директорий с помощью mount --bind .

Предположим, что мы хотим

• раздавать директорию ~/torrents с rw доступом для всех внутри локальной сети;
• раздавать директорию ~/photos с ro доступом для хоста с IP 192.168.1.101 ;

Для начала создадим корневую директорию и необходимые вложенные.

Sudo mkdir -p /srv/nfs/{torrents,photos}

Примонтируем существующие директории torrents, photos в /srv/nfs .

# sudo vim /etc/fstab /home/proft/torrents /srv/nfs/torrents none bind 0 0 /home/proft/photos /srv/nfs/photos none bind 0 0

Отредактируем /etc/exports , в котором описываются все директории для совместного доступа

# sudo vim /etc/exports # формат файла: directory allowed-hosts(options) /srv/nfs/torrents 192.168.1.1/24(rw,async) /srv/nfs/photos 192.168.1.101(ro,async)

Обратите внимание на отсутствие пробела между allowed-hosts и (options) . Наличие пробела вводит другую трактовку правил.

Доступные опции:

• ro (rw) - разрешить доступ только на чтение (чтение/запись);
• subtree_check (no_subtree_check) - в некоторых случаях приходится экспортировать не весь раздел, а лишь его часть. При этом сервер NFS должен выполнять дополнительную проверку обращений клиентов, чтобы убедиться в том, что они предпринимают попытку доступа лишь к файлам, находящимся в соответствующих подкаталогах. Такой контроль поддерева (subtree checks ) несколько замедляет взаимодействие с клиентами, но если отказаться от него, могут возникнуть проблемы с безопасностью системы. Отменить контроль поддерева можно с помощью опции no_subtree_check . Опция subtree_check , включающая такой контроль, предполагается по умолчанию. Контроль поддерева можно не выполнять в том случае, если экспортируемый каталог совпадает с разделом диска;
• sync (async) - указывает, что сервер должен отвечать на запросы только после записи на диск изменений, выполненных этими запросами. Опция async указывает серверу не ждать записи информации на диск, что повышает производительность, но понижает надежность, т.к. в случае обрыва соединения или отказа оборудования возможна потеря данных;
• noaccess - запрещает доступ к указанной директории. Может быть полезной, если перед этим был задан доступ всем пользователям сети к определенной директории, и теперь хотите ограничить доступ в поддиректории лишь некоторым пользователям;
• no_root_squash – по умолчанию пользователь root на клиентской машине не будет обладать теми же правами к директории на сервера. Эта опция снимает это ограничение;
• nohide - NFS автоматически не показывает нелокальные ресурсы (например, примонтированые с помощью mount --bind), эта опция включает отображение таких ресурсов;
• insecure - использование непривилегированных портов (> 1024);

Запускаем NFS-сервер

# под archlinux sudo systemctl start rpc-idmapd.service rpc-mountd.service # под ubuntu sudo /etc/init.d/nfs-kernel-server start

В дальнейшем при изменении конфигурационного файла достаточно его перечитать командой:

Sudo exportfs -rav

Команда rpcinfo -p | grep nfs позволяет проверить успешность запуска сервера.

Клиент под Linux

Установка

# под archlinux yaourt -S nfs-utils # под ubuntu sudo apt-get install portmap nfs-common

Создадим директории для монтирования сетевых ресурсов torrents и photos

Mkdir -p ~/nfs/{torrents,photos}

Для ручного монтирования выполним

Sudo mount -t nfs -o rw,soft 192.168.1.100:/srv/nfs/torrents /home/proft/nfs/torrents sudo mount -t nfs -o rw,soft 192.168.1.100:/srv/nfs/photos /home/proft/nfs/photos

Опция soft указывает тихо отменить попытки подключить шару после определенного количества времени (время задается опцией retrans ). Подробнее в man nfs .

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

Для автоматического монтирования редактируем файл /etc/fstab

# sudo vim /etc/fstab 192.168.1.100:/srv/nfs/torrents /home/proft/net/torrents nfs rw,soft 0 0 192.168.1.100:/srv/nfs/photos /home/proft/net/photos nfs ro,soft 0 0

Но и у этого способа есть свои недостатки, например, если сервер не доступен то загрузка клиента может подвиснуть из-за попыток подключиться к NFS-серверу. Для исправления этого см. ниже про AutoFS .

AutoFS - автоматическое подключение сетевых ресурсов

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

AutoFS использует для настройки шаблоны, расположенные в /etc/autofs . Основной шаблон называется auto.master , он может указывать на один или несколько других шаблонов для конкретных типов носителей.

Установка

# под archlinux yaourt -S autofs # под ubuntu sudo apt-get install autofs

Существует несколько способов указать способы автомонтирования. Я использую такой: в /home/proft/nfs автоматически создается директория с именем NFS-сервера, в которой автоматически создаются доступные директории на сервере.

# sudo vim /etc/autofs/auto.master /home/proft/nfs /etc/autofs/auto.nfs --timeout=60

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

Опишем в /etc/autofs/auto.nfs NFS-сервер и root-директорию.

# sudo vim /etc/autofs/auto.nfs nfsserver 192.168.1.100:/srv/nfs

Теперь при первом обращении /home/proft/nfs/torrents произойдет автоматическое монтирование NFS-ресурса.

Перезапустим службу autofs:

# под archlinux sudo systemctl restart autofs # под ubuntu sudo /etc/init.d/autofs restart

Еще можно указать время ожидания доступности NFS-ресурса. Для этого необходимо изменить значения MOUNT_WAIT .

# под archlinux # sudo vim /etc/conf.d/autofs MOUNT_WAIT=5 # под ubuntu sudo /etc/default/autofs MOUNT_WAIT=5

Форсирование использования NFS v3

В некоторых случаях NFSv4 может работать медленно. Для исправления этого можно принудительно указать использовать третью версию.

Доброго времени, читатели и гости . Очень большой перерыв между постами был, но я снова в бою). В сегодняшней статье рассмотрю работу протокола 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 (Network File System). NFS – это сетевая файловая система, с помощью которой можно обращаться к файлам и каталогам удалённого компьютера (сервера), как будто эти файлы и каталоги были локальными. Главным преимуществом такой системы является то, что отдельно взятые рабочие станции могут использовать меньше собственного дискового пространства, так как совместно используемые данные хранятся на отдельной машине (хранилище данных) и доступны для других машин в сети. NFS – это клиент-серверное приложение, где роль хранилища возлагается на сервер. Каждый участник сети – это NFS-клиент, который монтирует сетевой диск сервера у себя в файловой системе.

В роли сервера возьмем Ubuntu 12.04.
В качестве клиентов будем использовать и тестировать Centos и Winows 7.

Master server: 192.168.2.213 (Ubuntu)

Clients: 192.168.2.72 (Centos), 192.168.2.180 (Windows)

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

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

Root@ubuntu:~# apt-get install nfs-kernel-server

После установки нужного пакеты у нас создались два файла конфигураций. Из лога установки:

… Creating config file /etc/idmapd.conf with new version Creating config file /etc/default/nfs-common with new version …

В первом файле описан user (созданный при установке пакета) и group , для участия в mapping-e (идентификации пользователей).

Root@ubuntu:~# cat /etc/idmapd.conf Verbosity = 0 Pipefs-Directory = /run/rpc_pipefs # set your own domain here, if id differs from FQDN minus hostname # Domain = localdomain Nobody-User = nobody Nobody-Group = nogroup

Как мы знаем, в Linux каждый файл принадлежит конкретному пользователю, у которого есть свой (UID,GID), но у Windows системах схема немного другая. И в связи с этим был придуман механизм mapping, который делает трансляцию разных пользователей с различных ОС в понятный для файловой системы Linux вид.
Второй файл нужен для настройки идентификации Kerberos и настройке нестандартного порта, на котором будет слушаться демон. Он пока нам не нужен. Об настройке Kerberos речь пойдет в следующей статье.

Root@ubuntu:~# cat /etc/default/nfs-common # If you do not set values for the NEED_ options, they will be attempted # autodetected; this should be sufficient for most people. Valid alternatives # for the NEED_ options are "yes" and "no". # Do you want to start the statd daemon? It is not needed for NFSv4. NEED_STATD= # Options for rpc.statd. # Should rpc.statd listen on a specific port? This is especially useful # when you have a port-based firewall. To use a fixed port, set this # this variable to a statd argument like: "--port 4000 --outgoing-port 4001". # For more information, see rpc.statd(8) or http://wiki.debian.org/SecuringNFS STATDOPTS= # Do you want to start the gssd daemon? It is required for Kerberos mounts. NEED_GSSD=

Теперь продолжим настройку.
Все директории для шаринга нужно прописывать в файле /etc/exports. Для начала создадим 2 папки в домашней директории и закинем в них файлы. Дерево каталогов и файлов для экспорта:

Root@ubuntu:~# tree /home/alex/ /home/alex/ ├── nfs_dir1 │ ├── file1_dir1 │ ├── file2_dir1 │ └── file3_dir1 ├── nfs_dir2 ├── file1_dir2 ├── file2_dir2 └── file3_dir2

Теперь нужно присвоит юзера и группу для этих каталогов (берем с файла /etc/idmapd.conf).

Root@ubuntu:~# chown –R nobody:nogroup nfs_dir1/ root@ubuntu:~# chown –R nobody:nogroup nfs_dir2/

Для начала сделаем экспорт директории nfs_dir1 для конкретного IP. Редактируем файл /etc/exprots.

Root@ubuntu:~# vim /etc/exports # Для конкретного хоста (Windows) /home/alex/nfs_dir1 192.168.2.180(rw,sync,all_squash,no_subtree_check,insecure) # Для любого хоста подсети /home/alex/nfs_dir2 192.168.2.0/24(rw,no_root_squash,sync,no_subtree_check)

Здесь наведен минимальный набор опций для корректной работы хранилища с ОС Windows.

• /home/alex/nfs_dir1 – путь к папке, для которой раздается доступ;
• 192.168.2.180 – IP-адрес, которому раздается доступ к папке(можно указать всю сеть, тогда запись примет вид 192.168.2.0/24)
• (rw,sync,all_squash,no_subtree_check) – набор опций.

Популярные опции:

• rw –чтение/запись(может принимать значение ro-только чтение);
• no_root_squash – по умолчанию пользователь root на клиентской машине не будет иметь доступа к разделяемой директории сервера. Этой опцией мы снимаем это ограничение. В целях безопасности этого лучше не делать;
• sync – синхронный режим доступа(может принимать обратное значение — async );
• noaccess – запрещает доступ к указанной директории. Может быть полезной, если перед этим вы задали доступ всем пользователям сети к определенной директории, и теперь хотите ограничить доступ в поддиректории лишь некоторым пользователям.
• all_squash – подразумевает, что все подключения будут выполнятся от анонимного пользователя (нужно для Windows клиента)
• anonuid= 1000 – привязывает анонимного пользователя к «местному» пользователю;
• anongid= 1000 – привязывает анонимного пользователя к группе «местного» пользователя.
• no_subtree_check(subtree_check) –если экспортируется подкаталог файловой системы, но не вся файловая система, сервер проверяет, находится ли запрошенный файл в экспортированном подкаталоге. Отключение проверки уменьшает безопасность, но увеличивает скорость передачи данных.
• Обычно, Linux (и другие Unix-подобные операционные системы) резервируют TCP и UDP порты от 1-1023 (так называемые безопасные порты) для использования процессами пользователя root. Чтобы удостовериться, что именно root инициировал удаленное подключение NFS, сервер NFS обычно требует, чтобы удаленные клиенты использовали безопасные порты. Это соглашение, однако, не соблюдается некоторыми операционными системами (например Windows). В таких случаях опция insecure позволяет клиенту NFS использовать любой порт TCP/UDP. Обычно она требуется при обслуживании клиентов Windows.

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

Root@ubuntu:~# exportfs –a

Теперь проверяем что у нас экспортировалось.

Root@ubuntu:~# exportfs -v /home/alex/nfs_dir1 192.168.2.180(rw,wdelay,all_squash,no_subtree_check,insecure) /home/alex/nfs_dir2 192.168.2.0/24(rw,wdelay,no_root_squash,no_subtree_check)

Сервер настроен.

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

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

Если не было сообщений об ошибке. Можно приступить к монтирование на клиентской стороне.
Для начала, нужно добавить сервис (службу-клиента) NFS. Для этого переходив в Пуск —> Панель управления —> Программы и компоненты и нажимаем на пункт меню слева Включение или отключение компонентов Windows . В появившимся окне выбираем Клиент для NFS и жмем ОК (рис. 1).

Рисунок 1

Далее нужно смонтировать диск. Для этого можно использовать командную строку или же просто щелкнуть правой кнопкой мыши на Мой компьютер и выбрать Подключение сетевого диска . И ввести строку \\192.168.2.213\home\alex\nfs_dir1 . Это IP сервера и путь к папке (рис. 2).

Рисунок 2

Если все ок, мы увидим диск (рис. 3).

Рисунок 3

То же можно проделать, используя командную строку (рис. 4).

Рисунок 4

Возможные ошибки:

Вы не сможете подключить сетевой NFS диск к Windows OS (рис. 5), если
1. Не установлен клиент NFS
2. Включен (не настроен) фаэрвол
3. Нет сетевого доступа к серверу
4. Неверно введены параметры монтирования
5. Не настроен (не применены настройки) экспорт на сервере.
6. Добавить опцию insecure в настройках экспорта

Рисунок 5 – Ошибка подключения сетевого NFS диска

Вы не сможете добавить файл в смонтированную файловую систему (рис. 6) , если:
1. На сервере не выставлены права на папку (nobody:nogroup)
2. Не выставлена опция all_squash в настройках экспорта
3. Не выставлена опция rw в настройках экспорта

Рисунок 6 – Ошибка при добавлении файла на NFS диска

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

Настройка линукс систем довольно проста и безболезненна. Нужно просто установить нужные пакеты и смонтировать диск. Для Centos нужны следующие пакеты

# yum install nfs-utils nfs-utils-lib

# mkdir -p /mnt/nfs # mount 192.168.2.213:/home/alex/nfs_dir1 /mnt/nfs # mount /dev/mapper/vg_slave-lv_root on / type ext4 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0") /dev/sda1 on /boot type ext4 (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) 192.168.2.213:/home/alex/nfs_dir1 on /mnt/nfs type nfs (rw,vers=4,addr=192.168.2.213,clientaddr=192.168.2.72)

В данном случае мы можем добавлять любой файл и директорию в смонтированную nfs_dir1 папку от имени любого пользователя системы (all_squash ). Но если мы смонтируем вторую папку nfs_dir2, то в нее может записывать ТОЛЬКО root, так как там стоит опция no_root_squash . Проверяем.

# mkdir /mnt/dir1 # mkdir /mnt/dir2 # mount 192.168.2.213:/home/alex/nfs_dir1 /mnt/dir1 # mount 192.168.2.213:/home/alex/nfs_dir2 /mnt/dir2 или # mount -t nfs4 -o rw,hard,intr,bg 192.168.2.213:/home/alex/nfs_dir2 /mnt/dir2 # echo "Hello" > /mnt/dir1/file1 # echo "Hello" > /mnt/dir2/file1 # su alex $ echo "Hello" > /mnt/dir1/file1 $ echo "Hello" > /mnt/dir2/file1 bash: /mnt/dir2/file1: Permission denied

Возможные флаги монтирования.

Так же можно проверить с консоли, правильно ли сервер экспортировал файловую систему.

Root@centos ~# showmount -e 192.168.2.213 Export list for 192.168.2.213: /home/alex/nfs_dir2 192.168.2.0/24 /home/alex/nfs_dir1 192.168.2.180

Добавляем монтирование в автозагрузку

# cat /etc/fstab ... 192.168.2.213:/home/alex/nfs_dir2 /mnt/dir2 nfs4 rw,bg,intr,hard,nodev,nosuid 0 0

Root@centos ~# mount -a -t nfs4

Возможные ошибки.

Root@centos ~# mount -a -t nfs4 mount.nfs4: mount point /mnt/dir2 does not exist root@centos ~# mount -a -t nfs4 mount.nfs4: remote share not in "host:dir" format

В первом случаи нужно создать папку. Во втором — синтаксические ошибки в fstab.
Если возникли ошибки при монтировании NFS разделов – пройдитесь по списку Возможные ошибки из предыдущего раздела.
Для монтирования NFS разделов можно также использовать autofs. О чем пойдет речь в .

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

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

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

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

Во многом обмен данными является не более чем копированием информации на большие расстояния. Сетевые протоколы были не единственным средством, благодаря которому стал возможен всеобщий обмен данными. В конце концов, каждая компьютерная система должна преобразовывать датаграммы в что-либо понятное для операционной системы на другом конце. 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 и опишите файловую систему (с параметрами) в следующем общем формате:

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

Для настройки вашей 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. Третья запись указывает хост 192.168.0.125 и предоставляет доступ по чтению/записи к файлам с правами пользователя, имеющего user id=210 и group id=100 . Последняя запись используется для общедоступного каталога и разрешает доступ только по чтению и только под учетной записью анонимного пользователя.

NFS-клиент

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

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

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

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

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

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

Примечание: Дополнительная информация по записям /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 облегчает работу с различными операционными системами без необходимости слишком беспокоиться о семантике файловых систем и характеристиках их производительности.