Общие принципы 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 есть много вариантов практического применения. Ниже приводится несколько наиболее широко распространённых способов её использования:
- Настройка несколько машин для совместного использования CDROM или других носителей. Это более дешёвый и зачастую более удобный способ установки программного обеспечения на несколько машин;
- В больших сетях может оказаться более удобным настроить центральный сервер NFS, на котором размещаются все домашние каталоги пользователей. Эти домашние каталоги могут затем экспортироваться в сеть так, что пользователи всегда будут иметь один и тот же домашний каталог вне зависимости от того, на какой рабочей станции они работают;
- Несколько машин могут иметь общий каталог, например, для бэкапинга или, скажем, - база дистрибутивов. Таким образом, когда нужно будет устнановить какую-то программу на несколько машин, это можно легко провести, не проводя сгрузки файлов на эти машины.
Вообщем-то основное преимущество NFS в том, что можно работать с удаленным каталогом/разделом так, будто он установлен на локальной машине, ограничивая себя лишь шириной канала локальной сети. Причем работа протокола проходит прозрачно для пользователя, а это значит, что протоколу все равно на то, какие файловые системы установлены на локальной машине и на удаленном компьютере, а приложение, которое работает с файлом на удаленном диске никаким образом не изменяет свою структуру и не требует дополнительных настроек.
NFS - клиент-серверная система. Сервер организует доступ к определенной папке в своем дереве для определенных IP-адресов сети в выставлением необходимых настроек для этой директории (чтение, запись и тд). Клиент, находясь на локальном компьютере, запрашивает данные по адресу, если все благополучно - происходит соединение.
Теперь поговорим более детально. На сервере NFS должны быть обязательно запущены следующие процессы:
- nfsd. Процесс, который принимает и обслуживает запросы от клиентов. Как правило, таких процессов запускается несколько дабы не ограничивать следующего клиента в обслуживании, пока обрабатывается запрос предыдущего клиента. Весьма полезно при больших нагрузках. Соответственно на компьютере клиента каждый раз запускается свой процесс для каждой сессии, с теми же целями;
- mountd. Демон монтирования. После благополучного завершения обработки nfsd, mountd связывывается с клиентским mount и образует сессию.
- rpc.portmap. Portmapper является обязательным процессом для функционирования NFS. Его роль, в данном случае, заключается в том, что он ставит в соотвествие номер порта к вызову удаленной процедуры (RPC). К примеру, какое-то клиентское приложние запрашивает тред на NFS разделе сервера, клиент NFS формирует удаленную процедуру и запрашивает ее на порту TCP 2049 у сервера. Portmapper, слушая этот порт, перенаправляет RPC к nfsd,а тот в свою очередь - адресату, процедура выполняется и сформированный ответ отправляется обратно по тому же пути, но с помощью portmappera на UDP 2049. Из чего, кстати, можно сделать вывод, что выполняются только вызываемые процедуры (треды), что положительно влияет на нагрузку и безопасность.
- nfsiod. Демон, запускающийся и у клиента и у сервера, который несколько корретирует и синхронизирует связку клиент-сервер, что ускоряет работу. Функционирование данного процесса не обязательно - система правильно и корректно работает и без него.
А теперь практика. За что я люблю SlackWare, так это за то, что около 80% необходимого сетевого софта уже корректно установлено и настроено. Остается только запустить и радоваться жизни. А если нужно провести какие-то дополнительные манипуляции - все достаточно подробно расписано понятным английским языком. NFS - не исключение, все необхоимое уже настроено, остается только изменить права на запуск для скрипта /etc/rc.d/rc.nfsd и записать в файл /etc/exports рашаренные папки и директивы доступа:
Самый простой вариант. Мы расшариваем папку /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, есть и другие директивы настройки шары:
- no_root_squash - Этой опцией мы снимаем ограничение в виде переводов всех гостей в nobody и если пользователь заходит как root, то и будет принят системой сервера аналогично;
- root_squash - очень рекомендуемая производителями опция. Она насильно включает режим перевода в nobody, хотя это и выставлено по умолчанию;
- anonuid и anongid. Позволяет авторизоваться на сервере NFS гостевому пользователю под своим ID (ID логина и ID группы, соответственно). Для этого нужно узнать на компе-клиенте оба ID и прописать их в директивах шары сервера. Все действия будут выполнятся от этого ID;
- no_subtree_check. Отключает проверку принадлежности файла к той части тома, которая была примонтирована. Если не указать явно - включается по умолчанию. Сильно ни на что не влияет, но скорость обработки заметно ниже;
- sync и async. Включает и , соответственно, выключает синхронизацию файлового дерева на сервере и клиенте.
Более подробно в man exports.
В качестве примера:
или так:
можно еще так:
После заполнения /etc/exports запускаем скрипт Slackware, который содержит все необходимое для запуска нужных NFS серверу процессов:
У меня, после запуска выкинул строчку:
На что влияет эта ошибка не понятно, все функционирует нормально, интернет тоже убеждает в том, что можно игнорировать данную ошибку - она ни что не влияет. Однако, если есть желание избавиться от этой ошибки, можно загрузиться с ядра 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 не требует никаких дополнительных настроек.
для автоматического монтирования в /etc/fstab:
Для Windows существуют соответственные NFS-клиенты.
Немного о безопасности. Использование NFS крайне не безопасно и рекомендуется только в локальных сетях. В качестве памятки:
- На стороне сервера. Разрешать доступ только для конкретных IP-адресов компьютеров. Обязательно использовать директивы root_squash. Стараться реже использовать режимы rw и для шареной папки - 777;
- На строне клиента. (Авто)Монтирование применять с директивами noexec,nosuid,nodev.
Помните - трафик NFS никак не шифруется.
* - верно на февраль 2010 года.
Автор: Tornado2k




