Общие принципы NFS

Материал из Энциклопедия Хаб.ру
Перейти к: навигация, поиск

Система: SlackWare 13.1 x64 Используемые пакеты: nfs-utils-1.2.2


Немного теории. Итак, сетевая файловая система (NFS), банальное название, говорящее само за себя и такие же простые настройки. Исторически протокол NFS является одним из первых возможностей монтирования удаленных разделов на локальный компьютер. Первая версия NFS v.1 организована в 1984 году, последняя, и самая продвинутая - в 2000 (v. 4)* Первоначально разработана и существовала только для Unix систем, однако последняя версия полностью удовлетворяет одной из основных директив протокола - не должно быть никаких ограничений по использованию как NFS-сервера, так и NFS-клиента в плане кроссплатформенности, что успешно и реализовалось. Стандартным портом поднятой сессии NFS является UDP 2049, запрос же от клиентв принимается на TCP 2049. Работа протокола основана на вызове удаленных процедур (RPC). Подробнее - ниже.

У NFS есть много вариантов практического применения. Ниже приводится несколько наиболее широко распространённых способов её использования:

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

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

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

Теперь поговорим более детально. На сервере NFS должны быть обязательно запущены следующие процессы:

  1. nfsd. Процесс, который принимает и обслуживает запросы от клиентов. Как правило, таких процессов запускается несколько дабы не ограничивать следующего клиента в обслуживании, пока обрабатывается запрос предыдущего клиента. Весьма полезно при больших нагрузках. Соответственно на компьютере клиента каждый раз запускается свой процесс для каждой сессии, с теми же целями;
  2. mountd. Демон монтирования. После благополучного завершения обработки nfsd, mountd связывывается с клиентским mount и образует сессию.
  3. rpc.portmap. Portmapper является обязательным процессом для функционирования NFS. Его роль, в данном случае, заключается в том, что он ставит в соотвествие номер порта к вызову удаленной процедуры (RPC). К примеру, какое-то клиентское приложние запрашивает тред на NFS разделе сервера, клиент NFS формирует удаленную процедуру и запрашивает ее на порту TCP 2049 у сервера. Portmapper, слушая этот порт, перенаправляет RPC к nfsd,а тот в свою очередь - адресату, процедура выполняется и сформированный ответ отправляется обратно по тому же пути, но с помощью portmappera на UDP 2049. Из чего, кстати, можно сделать вывод, что выполняются только вызываемые процедуры (треды), что положительно влияет на нагрузку и безопасность.
  4. nfsiod. Демон, запускающийся и у клиента и у сервера, который несколько корретирует и синхронизирует связку клиент-сервер, что ускоряет работу. Функционирование данного процесса не обязательно - система правильно и корректно работает и без него.

А теперь практика. За что я люблю SlackWare, так это за то, что около 80% необходимого сетевого софта уже корректно установлено и настроено. Остается только запустить и радоваться жизни. А если нужно провести какие-то дополнительные манипуляции - все достаточно подробно расписано понятным английским языком. NFS - не исключение, все необхоимое уже настроено, остается только изменить права на запуск для скрипта /etc/rc.d/rc.nfsd и записать в файл /etc/exports рашаренные папки и директивы доступа:

/home/sharanfs/papka 192.168.1.95(rw)

Самый простой вариант. Мы расшариваем папку /home/sharanfs/papka для компа 192.168.1.95 с правами на чтение/запись. Следует помнить о том, что самой папке /home/sharanfs/papka необходимо выставить соотвествующие права, обычно это 777, но можно и другие, по своему усмотрению. Причем локальные права перешибают права, выставляемые для клиента NFS. То есть, если на шаренную папку выставлены права 755, а выставлен режим rw, то пользователь не сможет провести операцию записи в папку. Причем для локальной настройки прав доступа расшаренной папки играет роль именно последняя триада (rwx), потому вариантов настройки немного: например, 777 - полный доступ, 775 - доступ только для чтения, 750 - запрет на вход. Причем первые две триады (для овнера и группы) могут принимать абсолютно любые значения. Например, 007 равнозначны 407 или 777 и тд. Собственно как и для "только для чтения": 005 = 045 = 215. Обясняется это просто - все удаленные пользователи NFS клиентов переводятся по умолчанию в режим nobody:nobody, то есть не имеют практически никакой группы и никакого имени, конечно, если пользователя nobody не считать пользователем, хотя так оно и есть. Сделано это в целях безопасности, естественно.

Кроме rw и ro, есть и другие директивы настройки шары:

  1. no_root_squash - Этой опцией мы снимаем ограничение в виде переводов всех гостей в nobody и если пользователь заходит как root, то и будет принят системой сервера аналогично;
  2. root_squash - очень рекомендуемая производителями опция. Она насильно включает режим перевода в nobody, хотя это и выставлено по умолчанию;
  3. anonuid и anongid. Позволяет авторизоваться на сервере NFS гостевому пользователю под своим ID (ID логина и ID группы, соответственно). Для этого нужно узнать на компе-клиенте оба ID и прописать их в директивах шары сервера. Все действия будут выполнятся от этого ID;
  4. no_subtree_check. Отключает проверку принадлежности файла к той части тома, которая была примонтирована. Если не указать явно - включается по умолчанию. Сильно ни на что не влияет, но скорость обработки заметно ниже;
  5. sync и async. Включает и , соответственно, выключает синхронизацию файлового дерева на сервере и клиенте.

Более подробно в man exports.

В качестве примера:

/home/sharanfs/papka 192.168.1.95(rw,root_squash,no_subtree_check)

или так:

/home/sharanfs/papka 192.168.1.95(rw,root_squash,no_subtree_check) 192.168.3.119(rw,no_root_squash,no_subtree_check)

можно еще так:

/home/sharanfs/papka *(rw,root_squash,no_subtree_check)

После заполнения /etc/exports запускаем скрипт Slackware, который содержит все необходимое для запуска нужных NFS серверу процессов:

/etc/rc.d/rc.nfsd start

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

FATAL: Error inserting nfsd (/lib/modules/2.6.33.4-smp/kernel/fs/nfsd/nfsd.ko): Invalid module format

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

http://www.linuxquestions.org/questions/slackware-14/slack13-1-nfsd-fatal-error-816627/

http://binshi.typepad.com/blog/2010/08/nfs-server-on-slackware-131.html

Итак, сервер подняли, теперь настройки клиента. NFS клиент, так же как и CIFS клиент в Slackware не требует никаких дополнительных настроек.

mount -t nfs -o nolock 192.168.0.123:/home/sharanfs/papka /mnt/nfsshar

для автоматического монтирования в /etc/fstab:

192.168.0.123:/home/sharanfs/papka /mnt/nfsshara nfs rw,hard,intr 0 0

Для Windows существуют соответственные NFS-клиенты.

Немного о безопасности. Использование NFS крайне не безопасно и рекомендуется только в локальных сетях. В качестве памятки:

  1. На стороне сервера. Разрешать доступ только для конкретных IP-адресов компьютеров. Обязательно использовать директивы root_squash. Стараться реже использовать режимы rw и для шареной папки - 777;
  2. На строне клиента. (Авто)Монтирование применять с директивами noexec,nosuid,nodev.
192.168.0.123:/home/sharanfs/papka /mnt/nfsshara nfs rw,noexec,nosuid,nodev 0 0

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



* - верно на февраль 2010 года.

Автор: Tornado2k

Личные инструменты
Пространства имён
Варианты
Действия
Навигация
Инструменты