До того, как вы продолжите читать этот документ вам будет необходимо успешно выполнять операцию telnet между машинами, которые вы будете использовать как сервер и клиент. Если что-то не работает, вам нужно прочитать NET-3 HOWTO и правильно настроить работу сети.

Первый шаг

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

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

Если вы торопитесь, то пожалуйста посмотрите раздел Linux 2.2 до того, как вы продолжите читать это.

То, о чем вы читали, потребует от вас настройки нескольких программ.

Portmapper

Portmapper на Linux называется либо portmap либо rpc.portmap. Справочная страница на моей системе говорит, что это "Преобразователь номеров портов DARPA в вызовы соответствующих программ RPC". Это первая дыра в безопасности, которую вы откроете читая этот документ. Описание того, как закрыть одну из таких дыр находится в разделе по безопасности, который я советую вам обязательно прочитать.

Запустите portmapper. Он называется либо portmap, либо rpc.portmap и должен находиться в директории /usr/sbin (на некоторых машинах он называется rpcbind). Вы можете запустить его сейчас вручную, но он должен запускаться при каждом запуске вашей машины, так что вам необходимо создать/отредактировать rc-скрипты. Содержание ваших rc-скриптов объясняется более подробно в справочной странице init. Они обычно находятся в директориях /etc/rc.d, /etc/init.d или /etc/rc.d/init.d. Если там есть скрипт, названный inet, то его мы и будем редактировать. Но то, что в нем необходимо написать или что необходимо сделать еще, находится вне области рассмотрения этого документа. Запустите portmap, и проверьте, что он запущен с помощью команды ps aux и затем rpcinfo -p. Это сделано? Хорошо.

Одна вещь. Удаленный доступ к вашей программе portmapper определяется содержимым ваших файлов /etc/hosts.allow и /etc/hosts.deny. Если rpcinfo -p не работает, но ваш portmapper запущен, то пожалуйста провереьте указанные файлы. Смотрите раздел о безопасности для детального описания этих файлов.

Mountd и nfsd

Следующие программы, которые нам нужно запустить далее;-- это mountd и nfsd. Но сначала мы отредактируем другой файл. Это файл /etc/exports. Допустим я хочу, чтобы файловая система /mn/eris/local, которая находится на машине eris была доступна для машины названной apollon. Тогда я должен поместить в файл /etc/exports на машине eris следующие строки:

/mn/eris/local apollon(rw)

Вышеприведенные строки дают машине apollon право на чтение/запись в каталог /mn/eris/local. Вместо rw мы можем сказать ro, что означает достп только для чтения (если вы ничего не поместите, то по умолчанию будет доступ только для чтения. Существуют другие опции, которые вы можете задать здесь, и я позже рассмотрю некоторые из них, относящиеся к проблеме к безопасности. Они все перечислены в справочной странице exports, которую вы должны прочитать по крайней мере раз в жизни. Существуют также лучшие способы, чем перечисление всех машин в файле exports. Вы например можете использовать сетевые группы, если у вас используется система NIS (или NYS) (NIS также известен как YP), и всегда использовать шаблоны (wild cards) доменов и подсетей IP как списки машин, которым разрешено что-то монтировать. Но вы должны учитывать, кто может получить доступ к серверу неавторизованным способом, если вы используете такую всеобъемлющую авторизацию.

Замечание: Этот файл exports не имеет такой же синтаксис, который используют другие системы Unix. В этом документе есть отдельный раздел о файлах exports других Unix-систем.

Сейчас мы готовы к запуску программ mountd (она также может называться rpc.mountd) и nfsd (который может назван rpc.nfsd). Обе эти программы читают данные из файла exports.

Если вы отредактировали файл /etc/exports, то вы должны быть уверены, что nfsd и mountd знают о том, что файл изменен. Традиционный способ сделать это;-- это запустить программу exportfs. Во многих дистрибутивах Linux программа exportfs отсутствует. Если это так, то вы можете создать такой скрипт на вашей машине:

#!/bin/sh
killall -HUP /usr/sbin/rpc.mountd
killall -HUP /usr/sbin/rpc.nfsd
echo re-exported file systems

Сохраните его в файле, скажем /usr/sbin/exportfs, и не забудьте выполнить над ним команду chmod a+rx. Сейчас, после того как, вы изменили ваш файл exports, вы должны запустить программу exportfs, имея права администратора.

Теперь вы должны проверить, что mountd и nfsd запущены правильно. Сначала это делается с помощью команды rpcinfo -p. Вывод программы должен показать что-то похожее на следующее:

program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 745 mountd
100005 1 tcp 747 mountd
100003 2 udp 2049 nfs
100003 2 tcp 2049 nfs

Как вы видите portmapper анонсировал свои сервисы, и что mountd и nfsd запущены.

Если вы получили сообщение rpcinfo: can"t contact portmapper: RPC: Remote system error - Connection refused, RPC_PROG_NOT_REGISTERED или что-то подобное вместо этого, то значит portmapper не запущен. Или у вас может быть что-то записано в файлах /etc/hosts.{allow,deny} что запрещает программе portmapper отвечать, пожалуйста посмотрите раздел о безопасности для подробного описания этих файлов. Если вы получили сообщение No remote programs registered., то либо portmapper не хочет говорить с вами, либо что-то не в порядке. Завершите выполнение nfsd, mountd и portmapper и попытайтесь выполнить заново стартовую последовательность.

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

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

Справочные страницы, которые вы должны уже изучить: portmap, mountd, nfsd и exports.

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

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

Первым делом вам нужно ядро с поддержкой файловой системы NFS, либо вкомпилированной в ядро, либо доступной как модуль. Это настраивается до компиляции ядра. Если вы никогда не компилировали ядро, то вам может быть нужно прочитать Rernel HOWTO и выяснить как это делается. Если вы используете хороший дистрибутив (такой как RedHat) и вы никогда не экспериментировали с ядром или модулями (и таким образом разрушали его;-), то вероятно, что поддержка nfs уже есть в ядре.

Теперь вы можете, в командной строке администратора, ввести соответствующую команду монтирования и файловая система появится у вас. Продолжая пример из предыдущего раздела мы хотим смонтировать /mn/eris/local с машины eris. Это делается с помощью такой команды:

mount -o rsize=1024,wsize=1024 eris:/mn/eris/local /mnt

(Мы еще вернемся к опциям rsize и wsize). Файловая система сейчас доступна в /mnt и вы можете перейти туда и выполнить в ней команду ls, и посмотреть на индивидуальные файлы. Вы заметите, что эта операция выполняется не так быстро как над локальной файловой системой, но более удобно чем ftp. Если вместо монтирования файловой системы команда mount выдаст сообщение об ошибке mount: eris:/mn/eris/local failed, reason given by server: Permission denied, то файл exports является неправильным или вы забыли запустить exportfs после редактирования файла exports. Если команда сообщит mount clntudp_create: RPC: Program not registered это означает, что nfsd или mountd не запущены на сервере. Или у вас проблема с hosts.{allow,deny}, о которой упомянуто выше.

Чтобы прекратить пользоваться файловой системы вы можете выполнить:

Чтобы выполнялось автоматическое монтирование файловой системы nfs при загрузке, вам необходимо отредактировать файл /etc/fstab как обычно это делается. Для нашего примера требуется такая строка:

...
eris:/mn/eris/local /mnt nfs rsize=1024,wsize=1024 0 0
...

Это почти все, что необходимо. Читайте пожалуйста дальше.

Опции монтирования

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

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

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

Продолжая предыдущий пример, теперь в нашем файле fstab запись будет выглядеть так:

# device mountpoint fs-type options dump fsckorder
...
eris:/mn/eris/local /mnt nfs rsize=1024,wsize=1024,hard,intr 0 0
...

Оптимизация NFS

Обычно, если не заданы опции rsize и wsize, то NFS будет читать и писать блоками по 4096 или по 8192 байтов. Некоторые комбинации ядер Linux и сетевых карт не могут обрабатывать такие большие блоки, и это может быть не оптимально. Так что нам нужно поэкспериментировать и найти значения rsize и wsize, которые работают так быстр,о насколько это возможно. Вы можете протестировать скорость передачи при заданных опциях при помощи нескольких простых команд. Выполнив вышеприведенную команду монтирования и получив доступ с правом записи на диск, вы можете выполнить тестирование производительности последовательной записи:

time dd if=/dev/zero of=/mnt/testfile bs=16k count=4096

Эта команда создает 64Mb файл, заполненный нулевыми значениями (этот файл должен быть достаточно большим, настолько большим, чтобы кэширование не сыграло значительную роль в производительности, используйте больший размер файла, если у вас достаточно много памяти). Проделайте эту операцию несколько раз (5-10?) и усредните полученные результаты. Полученная величина;-- это время `прохода", т.е. величина наиболее интересующая нас в этом эксперименте. Затем вы можете измерить производительность чтения, прочитав файл обратно на свою машину:

time dd if=/mnt/testfile of=/dev/null bs=16k

выполните эту операцию несколько раз и усредните результат. Затем отмонтируйте файловую систему и примонтируйте ее заново, с увеличенными значениями rsize и wsize. Вероятно они должны быть кратными 1024, и не больше чем 16384 байтов, поскольку это максимальный размер блока данных в NFS версии 2. Прямо после монтирования с увеличенными значениями перейдите в смонтированную файловую систему и выполните команду подобную ls, исследуйте файловую систему, чтобы убедиться, что все в норме. Если значения rsize/wsize слишком большие, то симптомы очень необычные и не на 100% очевидные. Типичный симптом выражается в неполном списке файлов при выполнении команды "ls", и отсутствие сообщений об ошибках. Или чтение файлов загадочно срывается без сообщения об ошибке. После того, как вы установите, что заданные значения rsize/wsize работают, вы можете далее продолжать тестировать производительность. Различные серверные платформы вероятно имеют различные оптимальные размеры блоков. SunOS и Solaris по общему мнению, работают довольно быстрее при размере блока равном 4096 байт, чем при других значениях.

Новые ядра Linux (с версии 1.3) выполняют предваряющее чтение для значений rsize больших или равных размеру страницы машины. На процессорах Intel размер страницы равен 4096 байтам. Предваряющее чтение значительно увеличивает производительность NFS при чтении. Так что на машинах с процессором Intel вы можете захотеть использовать значение rsize равное 4096 байтам.

Помните, что вам нужно отредактировать /etc/fstab для использования найденных значений rsize/wsize.

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

/dir -async,access=linuxbox

или что-то подобное. Пожалуйста посмотрите справочную страницу exports на данной машине. Также запомните, что это увеличивает риск потери данных.

NFS через медленные линии

Медленные линии включают в себя модемы, ISDN и другие соединения на дальние расстояния.

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

Первая вещь которую вы должны помнить, что NFS;-- медленный протокол. Использование NFS в большинстве своем подобно использованию протокола kermit для переноса файлов. Это;-- медлено. Почти все быстрее чем NFS. FTP быстрее. HTTP быстрее. rcp быстрее. ssh быстрее.

Вы все еще хотите попробовать его в работе? Ok.

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

Первое, что вам необходимо сделать;-- это не использовать опцию монтирования soft. Это вызовет возвращение программному обеспечению сигналов об ошибках при таймаутах. В основном обычное программное обеспечение не слишком хорошо обрабатывает такие ошибки. Это хороший способ получить странные сбои. Вместо этого используйте опцию монтирования hard. Когда активна опция hard, то таймауты вызывают бесконечные попытки возобновления вместо прерывания работы ваших программ. Это то, что вам действительно нужно.

Следующая вещь, которую нужно сделать;-- это поэкспериментировать с опциями монтирования timeo и retrans. Они описаны в справочной странице nfs(5), здесь приводится выдержка из нее:

timeo=n Величина в десятых долях секунды до посылки
первой ретрансляции после таймаута RPC. По
умолчанию эта величина равна 7 десятых
секунды. После первого таймаута, время таймаута
удваивается после каждого таймаута, пока не
будет достигнута величина максимального таймаута
равна 60 секундам, или произойдет достаточно
ретрансляции, вызвав главный таймаут. Затем если
файловая система смонтирована с опцией hard, то
каждый новый таймаут каскадно запускается с
начальным значением в два раза больше, чем при
предыдущем каскаде, кроме того удваиваясь на
каждой ретрансляции. Максимальный таймаут всегда
равен 60 секундам. Наилучшая общая
производительность может быть достигнута
увеличением таймаута при монтировании на
загруженной сети, к медленному серверу, или
сквозь несколько маршрутизаторов.

retrans=n Эта величина задает количество неосновных
таймаутов и ретрансляций, которые должны
произойти до возникновения главного таймаута. По
умолчанию эта величина равна 3. Когда возникает
главный таймаут, то файловые операции либо
прерываются или на консоли печатается сообщение
"server not responding".

Другими словами: Если запрос не будет передан за таймаут равный 0.7 секунды (700ms), то клиент NFS повторит запрос и увеличит таймаут в два раза, до 1.4 секунды. Если ответ не придет в течении 1.4 секунды, то запрос повторится снова и таймаут будет увеличен до 2.8 секунды.

Скорость линии может быть измерена с помощью команды ping с размером пакета равным значению, установленному опциями rsize/wsize.

$ ping -s 8192 lugulbanda
PING lugulbanda.uio.no (129.240.222.99): 8192 data bytes
8200 bytes from 129.240.222.99: icmp_seq=0 ttl=64 time=15.2 ms
8200 bytes from 129.240.222.99: icmp_seq=1 ttl=64 time=15.9 ms
8200 bytes from 129.240.222.99: icmp_seq=2 ttl=64 time=14.9 ms
8200 bytes from 129.240.222.99: icmp_seq=3 ttl=64 time=14.9 ms
8200 bytes from 129.240.222.99: icmp_seq=4 ttl=64 time=15.0 ms

Lugulbanda.uio.no ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 14.9/15.1/15.9 ms

Здесь время показывает как долго пакет программы ping идет туда и обратно к машине lugulbanda. 15ms это довольно быстро. При работе через модем со скоростью 28.000 бод вы можете ожидать где-то 4000-5000ms, и если линия нагружена еще кем-то, то время будет даже выше, может быть раза в два. Когда это время высоко, мы говорим что это "высокое запаздывание". В общем для больших пакетов и для более загруженных линий запаздывание будет увеличиваться. Увеличьте timeo соответственно вашей линии и загрузке. И поскольку запаздывание увеличивается когда вы используете линию для других вещей: даже если вы хотите использовать FTP и NFS в одно и тоже время, то вы должны попытаться измерить timeo ping во время использования FTP для передачи файлов.

Безопасность и NFS

Я ни коим образом не являюсь экспертом в области компьютерной безопасности. Но у меня есть маленький совет для сознающих проблему безопасность. Но будьте предупреждены: этот список ни в коем случае не является полным списком проблем относящихся к NFS, и если вы думаете, что вы обезопасились один раз прочитав и выполнив, все что я даю здесь, то я хочу предупредить вас.

Этот раздел не должен беспокоить вас, если вы находитесь в закрытой сети, где вы доверяете всем пользователям, и никто из тех кому вы не доверяете ни может получить доступ к машинам в сети. Например, не должно быть dial-соединения в сеть, и не должно быть никакого способа подключиться к сети, в которой вы есть люди, которым вы не доверяете. Вы думаете я параноик? Я не параноик. Это базовый совет по безопасности. Безопасность требует наличия тщательного и знающего администратора, который знает где найти информацию о текущих и потенциальных проблемах безопасности.

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

Что вам необходимо прочитать;-- это консультационные материалы CERT относящиеся к NFS. Большинство текстов приведенных ниже, связаны с советами, написанными в выпусках CERT. Смотрите ftp.cert.org/01-README для обновленного списка консультативных материалов CERT. Здесь приведены некоторые относящиеся к NFS консультативные материалы:

CA-91:21.SunOS.NFS.Jumbo.and.fsirand 12/06/91
Уязвимость в отношении сетевой файловой системы (NFS) Sun
Microsystems, Inc. (Sun) и программы fsirand. Эта уязвимость
возможна в версиях SunOS 4.1.1, 4.1, and 4.0.3 на всех
архитектурах. Заплатки (Patches) доступны для SunOS
4.1.1. Также доступна начальная заплатка для SunOS 4.1 NFS. Sun
будет обеспечит полные заплатки для SunOS 4.1 и SunOS 4.0.3 позже.

CA-94:15.NFS.Vulnerabilities 12/19/94
Этот консультационный материал обеспечивает измерение
безопасности для охраны против против некоторых дыр в безопасности
в сетевой файловой системе (NFS). Этот материал выпущен в связи с
увеличением случаев взлома машин, используя утилиты для
взлома через уязвимые точки.

CA-96.08.pcnfsd 04/18/96
Этот материал описывает проблемы с безопасностью в программе pcnfsd
(также известной как rpc.pcnfsd). Заплатка для исправления ошибки
прилагается.

Безопасность клиента

На клиентской стороне мы можем решить, что мы не хотим слишком сильно доверять серверу. Это делается несколькими способами, используя опции монтирования. Например, мы можем запретить выполнение программ с установленным битом suid в файловой системе NFS, это делается опцией монтирования nosuid. Это хорошая идея и вы должны рассмотреть ее, используя смонтированные через NFS файловые системы. Это означает, что администратор сервера не сможет сделать программы с установленным suid-администратора на файловой системе, затем войти на машину клиента как обычный пользователь и используя программу с suid-администратора приобрести также права администратора на машине клиента. Мы также можем запретить выполнение файлов на смонтированной файловой системе с помощью опции noexec. Но она применяется реже по сравнению с опцией nosuid, поскольку файловая система может содержать по крайней мере некоторые скрипты, или программы, которые необходимо выполнять. Вы можете ввести эти опции в колонке опций вместе с опциями rsize и wsize, разделяя их запятыми.

Безопасность сервера: nfsd

На стороне сервера мы можем решить, что мы не хотим доверять администратору клиента. Мы можем сделать это указав опцию root_squash в файле exports:

/mn/eris/local apollon(rw,root_squash)

Теперь, если пользователь с UID 0 на стороне клиента попытается получить доступ (чтение, запись, удаление), то файловый сервер выполнит подстановку UID пользователя `nobody" на сервере. Это означает, что администратор клиента не сможет получить доступ или изменять файлы, которые может изменять или иметь доступ к которым может только администратор сервера. Это хорошо и вы должны использовать опцию root_squash на всех экспортируемых файловых системах. Вы скажете, что "Администратор клиента все равно может выполняить команду "su", чтобы зайти как любой другой пользователь и получить доступ и изменить любые пользовательские файлы". На это есть ответ: "Да есть такой способ, и это работает в Unix и NFS. Это имеет одно важное заключение: Все важные файлы и программы должны иметь владельцем пользователя root, а не пользователя bin или другого пользователя не-администратора, поскольку только администратор клиента не может получить доступ как администратор сервера. С справочной странице NFSd есть несколько других подобных опций, так что вы можете решить, что вы (не) доверяете кому-либо со стороны клиента. У вас также имеются опции для осечения любых диапазонов UID и GID. Это описывается в справочной странице Linux NFSd.

Опция root_squash является установленной по умолчанию для NFSd в Linux, для передачи администраторских полномочий для доступа к файловой системе используйте опцию no_root_squash.

Другая важная вещь, которую необходимо сделать, это проверить, что nfsd проверяет, все ли запросы приходят с привелигированного порта. Если он принимает запросы с любого старого порта на клиенте, то пользователь без специальных привилегий может запустить программу, которую легко получить по Internet. Он умеет "говорить" на языке протокола nfs и будет притворяться, что пользователь является любым пользователем, которым он хочет быть. NFSD на Linux делает эту проверку по умолчанию, но для других операционных систем вы должны разрешить эту проверку сами. Это должно быть описано в справочной странице nfsd для вашей операционной системы.

Другая вещь. Никогда не экспортируйте файловую систему для машины с именем "localhost" или 127.0.0.1. Доверяйте мне.

Безопасность сервера: portmapper

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

Не все дистрибутивы Linux обладают равными возможностями. Некоторые дистрибутивы, которые кажутся современными, не включают в свой состав безопасный вариант программы portmapper, даже сейчас, через много лет после того как стало известно о ее уязвимостях. По крайней мере один дистрибутив даже содержит справочную страницу более безопасного portmapper, но на самом деле его portmapper не является безопасным. Самым легким способом проверить является ли ваш portmapper хорошим или нет, является запуск программы strings(1) и просмотр ее вывода на наличие файлов, /etc/hosts.deny и /etc/hosts.allow. Предполагая, что ваш portmapper находится /usr/sbin/portmap, вы можете проверить это выполнив следующую команду: strings /usr/sbin/portmap | grep hosts. на моей машине это выполнилось со следующими результатами:

/etc/hosts.allow
/etc/hosts.deny
@(#) hosts_ctl.c 1.4 94/12/28 17:42:27
@(#) hosts_access.c 1.20 96/02/11 17:01:27

Сначала мы отредактируем файл /etc/hosts.deny. Он должен содержать строку

которая запретит доступ всем. Поскольку это закрыло доступ всем, запустите rpcinfo -p просто для проверки того, что ваш portmapper читает этот файл и выполняет данные инструкции. Команда rpcinfo не должна ничего вывести или должна выдать сообщение об ошибке. Перезапуск portmapper не является необходимым.

Закрытие portmap для всех может быть слишком кардинальным, поэтому мы снова откроем доступ, изменив файл /etc/hosts.allow. Но сначала нам надо определить, что мы туда поместим. В этом файле перечисляются все машины, которые могут получить доступ к вашему portmapper. Среди множества работающих под Linux систем только некоторым машинам нужен полный доступ для любой работы. Portmapper обслуживает nfsd, mountd, ypbind/ypserv, pcnfsd, и "r" сервисы, такие как ruptime и rusers. Из них только nfsd, mountd, ypbind/ypserv и возможно pcnfsd имеют какое-либо важное значение. Всем машинам, которым необходим доступ к сервисам на вашей машине должно быть разрешено делать это. Скажем адрес машины равен 129.240.223.254 и она находится в подсети 129.240.223.0, и ей нужен доступ к сервисам на вашей машине (эти термины введены HOWTO по сетям, вернитесь к нему и освежите свои знания, если это необходимо). Для этого мы напишем в файле hosts.allow

portmap: 129.240.223.0/255.255.255.0

Это тоже самое, что и сетевой адрес, который вы даете командой route и маска подсети, которую вы передаете команде ifconfig. Для устройства eth0 на этой машине ifconfig должен показывать

...
eth0 Link encap:10Mbps Ethernet HWaddr 00:60:8C:96:D5:56
inet addr:129.240.223.254 Bcast:129.240.223.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:360315 errors:0 dropped:0 overruns:0
TX packets:179274 errors:0 dropped:0 overruns:0
Interrupt:10 Base address:0x320
...

а программа netstat -rn должна показывать

Kernel routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
...
129.240.223.0 0.0.0.0 255.255.255.0 U 0 0 174412 eth0
...

(Сетевой адрес находится в первой колонке).

Файлы hosts.deny и hosts.allow описаны в справочных страницах с теми же именами.

ВАЖНО: Не помещайте в этих файлах ничего, кроме IP НОМЕРОВ в строках для настройки portmap. Поиск имен машин может вызвать активность portmap, которая вызовет поиск имен машин, которое вызовет portmap, которое вызовет...

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

NFS и firewall

Очень хорошая идея защитить порты nfs и portmap с помощью firewall на вашем маршрутизаторе. Nfsd работает на порту 2049, используя оба протокола;-- udp и tcp. Portmapper работает на порту 111, tcp и udp, а mountd работает на портах 745 и 747, tcp и udp. По умолчанию. Вы должны проверить номера используемых портов, используя команду rpcinfo -p.

Если вы хотите использовать NFS сквозь firewall, то есть опции для новых версий NFSd и mountd, для того, чтобы заставить их использовать нестандартные порты, которые могут быть открыты в firewall.

Резюме

Если вы используете hosts.allow/deny, root_squash, nosuid и привилегированные порты в программном обеспечении portmapper/nfs, то вы можете избежать известных ошибок в nfs и можете чувствовать себя почти в безопасности. Но все равно: когда взломщик имеет доступ к вашей сети, то он/она может добавить странные команды в ваш файл.forward или почтовый ящик, когда /home или /var/spool/mail смонтирован через NFS. По той же причине, вы никогда не должны осуществлять доступ к вашим личным ключам PGP через nfs. Или по крайней мере вы должны знать какой риск существует. И знать о нем хотя бы немного.

NFS и portmapper создают комплексную систему и поэтому не полностью невероятно,что новые ошибки будут найдены, либо в основе проекта, либо в реализации, которую мы используем. Также могут быть известные дыры, которые кто-нибудь использует. Но такова жизнь. Чтобы быть в курсе таких вещей, вы должны как минимум читать группы новостей comp.os.linux.announce и comp.security.announce.

Контрольный список разрешения проблем монтирования

Это раздел основан на контрольном списке проблем монтирования, этот документ написан в IBM Corp. Я благодарен им за то, что они сделали его доступным для использования в этом документе. Если у вас есть проблема с монтированием файловой системы через NFS, то пожалуйста проверьте это список, до того как вы пошлете сообщение об ошибке. Каждый пункт описывает конкретную проблему и ее решение.

Команда mount продолжает сообщать RPC: Program not registered Запущен ли portmapper?

Исправление: Запустите его.

Запущен ли mountd?

Исправление: Запустите его.

Запущен ли nfsd?

Исправление: Запустите его.

Не запрещено ли portmapper отвечать на ваши запросы файлом /etc/hosts.deny?

Исправление: Либо удалите правило из файла hosts.deny либо добавьте правило в файл hosts.allow, так что portmapper будет разрешено общаться с вами.

Файловая система не экспортируется, или не экспортируется при запросе клиента. Исправление: Экспортируйте ее

Система разрешения имен не выдает соответствия со списком машин в файле exports. Например: список экспортируемых ресурсов задает экспортирование johnmad, но имя johnmad разрешается как johnmad.austin.ibm.com и монтирование запрещается.

Исправление: Экспортируйте ресурс для обоих форм имени машины.

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

Исправление: Экспортируйте оба интерфейса.

Это также может произойти, если сервер не может выполнить функции lookuphostbyname или lookuphostbyaddr (это библиотечные функции) на клиенте. Убедитесь, что клиент может выполнять команды host ; host ; и обе они указывают на одну и ту же машину.

Исправление: наладьте систему разрешения имен.

Файловая система была смонтирована, после того как NFS был запущен (на том сервере). В таком случае сервер экспортирует саму точку монтирования, а не смонтированную файловую систему. Исправление: Завершите NFSd и затем перезапустите его.

Заметчание: Клиенты, которые уже были примонтированы к точке монтирования файловой системы будут иметь проблемы с доступом к ней после перезапуска сервера.

Дата наобум изменяется на одной или обоих машинах (это может спутать make). Исправление: Установите правильную дату.

Автор HOWTO рекомендует использовать NTP для синхронизации часов. Поскольку существуют экспортные ограничения на NTP в US, то вы можете получить NTP для Debian, Red Hat или Slackware с ftp://ftp.hacktic.nl/pub/replay/pub/linux или с сервера-зеркала.

Сервер не допускает монтирования от пользователя, который находится больше чем в 8 группах. Исправление: уменьшите количество групп в которые входит пользователь или смонтируйте под именем другого пользователя.

Часто Задаваемые Вопросы (FAQ)

Это раздел часто задаваемых вопросов (FAQ). Большая часть его основана на старом FAQ, написанном Alan Cox.

Если у вас есть проблемы с монтированием файловой системы, то пожалуйста посмотрите, не описана ли она в разделе ``Список проверок при монтировании"".

Я получаю сообщения об ошибках ``stale nfs handle (устарелый дескриптор nfs)"" при использовании Linux как сервера nfs. Это вызывается ошибкой в одной из старых версий nfsd. Это исправлено в nfs-server2.2beta16 и более поздних.

Когда я пытаюсь примонтировать файловую систему я получаю сообщение
can"t register with portmap: system error on send
(не могу зарегистрироваться с помощью portmap: системная ошибка при посылке)

Вы вероятно используете систему Caldera. Это ошибка в скриптах rc. Пожалуйста свяжитесь с Caldera для получения исправления.

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

Мои файлы на NFS все считаются с правом только на чтение По умолчанию сервер NFS для Linux выдается все как только для чтения. Перечитайте разделы ``Mountd и nfsd"" и ``Экспортирование файловых систем"" данного документа, а также справочные страницы по ``exports"" и nfsd. Вам необходимо изменить файл /etc/exports.

Я монтирую файловую систему с сервера nfs под linux и пока работает команда ls я не могу читать или записывать файлы. На старых версиях Linux вы должны монтировать сервер NFS с опциями rsize=1024,wsize=1024.

Я монтирую файловую систему с сервера NFS под Linux с размером блока между 3500-4000 и это регулярно роняет машину с Linux Обычно не делайте так. Это не случается с ядрами версий 2.0 и 2.2. Также нет проблемы с ядрами серии 2.1.

Может Linux выполнять NFS по TCP Нет

Я получаю странные ошибки при монтировании машины с машины под Linux. Убедитесь, что ваш пользователь находится в 8 или меньшем количестве групп. Старые сервера требую этого.

Когда я перезагружаю свою машину она иногда вешается при попытке отмонтироваться от зависшего сервера NFS. Не отмонтируйтесь от серверов NFS при перезагрузке или выключении, просто проигнорируйте это, ничто не повредится, если вы не отмонтируетесь от него. Команда будет выглядеть следующим образом umount -avt nonfs.

Клиент NFS для Linux работает очень медленно при записи на системы Sun и BSD. Обычно NFS записывает в синхронном режиме (вы можете запретить это, если вы считаете, что вы не рискуете потерять данные). Хуже всего то, что ядра произошедшие от BSD не могут работать с маленькими блоками. Таким образом когда вы пишете 4K данных с машины под Linux в 1K пакетах, то BSD выполняет это следующим образом

прочитать страницу размером 4K
изменить 1K

прочитать страницу размером 4K
изменить 1K
записать страницу размером 4K обратно на диск
и т.д...

Когда я подключаю много клиентов к Linux NFS серверу, его производительность неожиданно падает. Протокол NFS использует использует фрагментированые UDP-пакеты. В ядре имеется предел на то, как много фрагментов или неполных пакетов прибудет до того, как оно начнет отбрасывать пакеты. В ядрах серии 2.2 это настраивается во время работы через файловую систему /proc: /proc/sys/net/ipv4/ipfrag_high_thresh и ipfrag_low_thresh. В ядрах серии 2.0 эти константы определяются во время компиляции и определены в файле.../linux/net/ipv4/ip_fragment.c, IPFRAG_HIGH_THRESH и IPFRAG_LOW_THRESH. Эти параметры означают, что когда потребление памяти не собранными фрагментами пакетов UDP достигает значения ``ipfrag_high_thresh"" в байтах (по умолчанию 256K в ядрах 2.2.3 и 2.0.36) оно уменьшится до значения ``ipfrag_low_tresh"". Это делается отбрасыванием фрагментов. Это будет выглядеть как почти полная потеря пакетов и если будет достигнута верхняя граница, то производительность вашего сервера сильно уменьшится.

256K достаточно для обслуживания до 30 клиентов. Если у вас 60 клиентов, то увеличьте это значение в 2 раза. И также увеличьте значение нижней границы.

Я использую Linux 2.2 (или более поздний) с knfsd и я не могу заставить мои машины с AIX, IRIX, Solaris, DEC-Unix, ... монтироваться к нему. Knfsd объявляет, что реализует NFS версии 3. Это не так. Существует опция, которая запрещает ему анонсировать это. Используйте ее. Или вы можете поместить параметр "vers=2" в список опций монтирования на клиенте.

Моя машина с AIX 4 не может произвести монтирование моего NFS сервера под Linux. Она сообщает
mount: 1831-011 access denied for server:/dir
mount: 1831-008 giving up on:
server:/dir
The file access permissions do not allow the specified action.

или что-то подобное. AIX 4.2 использует зарезервированные порты (<1024) для NFS. AIX 4.2.1 и 4.3 не ограничены резервированными портами. Также AIX 4.2.1 и 4.3 пытаются произвести монтирование используя версию NFS3, затем NFS/TCP, и только потом NFS/UDP.

Добавление строк

nfso -o nfs_use_reserved_ports=1

в конец файла rc.tcpip заставит его использовать резервированные порты. (Этот совет был послан Brian Gorka).

Экспортирование файловых систем

Способ экспортирования файловых систем с помощью NFS не является полностью совместимым между платформами. В этом случае отличаются Linux и Solaris 2. Этот раздел поверхностно перечисляет способы как выполнить эту операцию на большинстве систем. Если ваша система не была перечислена здесь, то посмотрите справочные страницы по вашей операционной системе. Ключевые слова следующие: nfsd, system administration tool (утилиты системного администрирования), rc scripts, boot scripts, boot sequence, /etc/exports, exportfs. Я буду использовать один пример для всего раздела: как экспортировать файловую систему /mn/eris/local для машины apollon с правами на чтение/запись.

IRIX, HP-UX, Digital-UNIX, Ultrix, SunOS 4 (Solaris 1), AIX

Эти операционные системы используют традиционный формат Sun для экспортирования. В файле /etc/exports напишите:

/mn/eris/local -rw=apollon

Полная документация находится в справочной странице exports. После редактирования файла запустите exportfs -av для экспортирования файловых систем.

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

/mn/eris/local apollon

или даже вот так:

Solaris 2

Sun полностью переизобрел колесо при разработке Solaris 2. Так что он полностью отличается от других операционных систем. То, что вам нужно сделать;-- это отредактировать файл /etc/dfs/dfstab. В нем вы должны поместить команды организации доступа так, как это описано в справочной странице share(1M). Примерно вот такие строки:

share -o rw=apollon -d "Eris Local" /mn/eris/local

После редактирования запустите программу shareall для экспортирования файловой системы.

NFS в Linux 2.2

Как я написал, Linux 2.2.12 является текущей версией ядра и для использования NFS в нем может быть нужно будет выполнить немного рутинной работы. Или не нужно.

Каким будет статус NFS в Linux 2.4 я не знаю.

Большим новшеством в Linux 2.2 является поддержка демона nfs в ядре, который называется knfsd. Этот способ реализации nfsd имеет некоторые преимущества, главный из которых;-- скорость работы. Машина с Linux 2.2 и knfsd является солидным сервером nfs. Вы все равно можете использовать старый nfsd с Linux 2.2, и также существует несколько преимуществ, в основном простота.

Если вы используете исходные тексты ядра или двоичные пакеты, созданные кем-то типа RedHat (6.0 и поздние), SuSE (6.1 или более поздние) или каким-то другим профессиональным системным интегратором, то скорее всего они будут поставляться с полной интеграцией "knfsd" в ядро и вы не должны будете беспокоится. В большинстве случаев. До тех пор пока вы не заходите скомпилировать ядро сами. Если вы используете обычное ядро Linux 2.2 (по крайней мере 2.2.12), то knfsd не будет работать.

Для того, чтобы самому заставить это работать вам необходимо взять пакет knfsd сделанный H.J. Lus. Этот пакет является набором заплаток и необходимых утилит для ядер серии 2.2, которые Lu сопровождает в свое свободное время. Вы можете взять его с вашего локального зеркала сервера ядра, или с основного сервера, по адресу ftp.kernel.org:/pub/linux/devel/gcc/. Он не предназначается для всеобщего использования. Если этот пакет вам непонятен, то не пытайтесь использовать его сами. Подождите пока пакеты с ядром не выпустит ваш любимый системный интегратор (например, Red Hat, SuSE или...).

Также, пожалуйста не посылайте мне вопросы об этом пакете, я не могу помочь вам. У меня нет ни одного сервера с работающим knfsd. Если вы нашли ошибку или пропуск в документации, то пожалуйста напишите мне, я исправлю этот документ и выпущу его снова.

Все еще читаете? Ok. H.J.Lu посылает сообщения о новых версиях своего пакета в список рассылки linux-kernel. Другие сообщения, относящиеся к NFS в версии ядра 2.2 также посылаются туда. Читайте их.

Существует одна интересная вещь, которую необходимо сказать о пакете knfsd. Он анонсирует, что использует NFS версии 3. Однако он не поддерживает эту версию. Существует опция, которую вы можете использовать для того, чтобы запретить пакету анонсирование NFS3, или на клиентах необходимо указать опцию "vers=2" среди других опций монтирования.

Клиент

Клиент очень прост. Для того, чтобы получить правильное блокирование вам необходимо иметь statd (из пакета knfsd) скомпилированным, установленным и запещуееным из загрузочных скриптов. Сделайте это. Для работы statd необходим каталог /var/lib/nfs, иначе он просто прекратит работу без каких либо сообщений об ошибках, так что необходимо создать каталог до запуска программы.

Когда statd уже запущен вы можете использовать программу testlk (в каталоге tools/locktest) для тестирования того, что блокировка файлов работает на файловых системах смонтированных по NFS. Она должна работать нормально. Если программа сообщает No locks available (Блокировки не доступны), то statd не работает.

В действительности вы также можете полностью избежать блокировок (заметьте, что я не рекомендую вам делать это), используя параметр "nolock" в списке опций монтирования.

Насколько я знаю--это все, что необходимо для работы клиентов.

Если у вас Sparc или Alpha NFS-сервер, то вы обнаружите, что nfs-клиент в Linux 2.2 совершенное не работает. Скорость передачи данных на и с сервера настолько плоха, что это трудно представить. Это хуже даже чем под Linux 2.0. Намного хуже. Но для этой проблемы существует исправление. Серия ядер 2.2 Alan Cox (которые являются более экспериментальными, чем нормальные ядра 2.2, сопровождаемые Linus) включают заплатку, которая позволяет Linux 2.2 увеличить производительность при работе с серверами Alpha и Sparc. Если вы хотите использовать ядра исправленные Alan Cox, то вы должны читать список рассылки linux-kernel, и вы должны узнать где можно найти необходимые заплатки. Основным сервером для этой заплатки является сервер http://www.uio.no/~trondmy/src/, в случае, если вы хотите попробовать применить его к нормальному ядру серии 2.2. Эта заплатка скорее всего не будет входит в состав Linux 2.4, поскольку требует сделать слишком много изменений в течении текущего цикла разработки. Ждите появления Linux 2.5.

trondmy также имеет заплатки для того, чтобы Linux использовал NFS версии 3, они также позволят вам использовать tcp как транспортный механизм, вместо UDP. NFSv3 очень хорош для сетей с большим количеством переходов, а также для сетей где потери пакетов не равны нулю или где время ожидание очень высокое.

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

Сервер

Демон nfs-сервера в Linux 2.2 и более поздних называется "knfsd". Он сложен в установке. Вы можете настроить его сами или поставить то, что вам предлагают SuSE, Red Hat и другие в виде пакетов ядра серии 2.2. Извините. Хотя вы все равно можете использовать старый nfsd в Linux 2.2. Он медленен, но легок в установке.

NFS-сервер на дискете

Этот раздел был написан Ron Peters, [email protected]. Он объясняет как настроить NFS-сервер при загрузке с дискеты. Сначала это было придумано для обеспечения доступа по NFS к cdrom на другой машине без Linux/UNIX для установки Linux на машину на которой нет cdrom.

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

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

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

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

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

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

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

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

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

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

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

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

NFS - это RPC

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

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

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

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

NFS версии 3

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

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

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

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

NFS версии 4

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

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

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

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

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

NFS-сервер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

NFS-клиент

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

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

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

mount server:directory local mount point

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

mount 192.168.0.100:/opt/files /mnt

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

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

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

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

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

Критика NFS

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

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

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

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

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

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

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

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

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

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

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

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

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

Правильно настроив NFS можно объединить в одну сеть компьютеры на разных ОС.

Network File System - протокол сетевого доступа к файлам. Как водится, состоит из двух частей. Одна - клиентская, которая расположена на компьютере, с которого просматривают удалённые данные. Другая - серверная - расположена на компьютере, где эти данные хранятся. Довольно удобно использовать дополнительное дисковое пространство, особенно в локальной сети . А если речь идёт о каких-то корпоративных ПК, то это просто необходимо.

Чем отличается?

Сегодня существует большое число протоколов и самого разного программного обеспечения, которое выполняет те же самые функции. Чем выделяется NFS?

• Возможность соединения в одну сеть компьютеров на разных операционных системах. Часто ОС Windows удобно соединить по NFS с Unix-системой , например, Ubuntu. Для этих же целей существует и применяется Samba, но NFS легче, проще и быстрее этой программы, поскольку реализован на уровне ядра. Поэтому настроить доступ через него, как правило, будет проще.
• NFS предоставляет прозрачный доступ к файлам. Это означает, что все удалённые файлы воспроизводятся точно так же, как и локальные. Программы не надо апгрейдить, чтобы воспроизвести любой файл, находящийся на сервере.
• NFS отправляет только запрашиваемую часть файла, а не весь файл.

Устанавливать Network File System для полноценной работы необходимо, как минимум, на два компьютера: сервер и клиент. Естественно, новичку больше всего попотеть придётся над серверной частью, поскольку именно там необходимо «расшаривать» (открывать доступ) папки. Однако всё это выполняется довольно легко.

Как и большинство протоколов передачи данных, NFS совсем не молод. Разработан он был в 1984 году и предназначался для UNIX-систем. Это и сейчас главная роль NFS, однако многие обнаружили, что при помощи его очень удобно соединять Windows-компьютеры с линуксовыми. Кроме того, NFS отлично подходит для воспроизведения мультимедийного контента по локальной домашней сети. Samba в этой роли часто подвисает и подтормаживает.

Установка серверной части NFS

Серверную часть протокола мы будем ставить на Ubuntu 16.04. Естественно, если у вас стоит редакция Server, то процесс никоим образом не отличается. Просто в традиционной версии Убунту некоторые действия можно выполнить при помощи графического интерфейса.

Устанавливаем программу. Для этого можно воспользоваться центром загрузки приложений , а можно просто ввести команду:

sudo apt install nfs-kernel-server

После этого нелишним будет проверить корректность установки. Делать это не обязательно, но мы всё же проверим. Вводим команду:

Порт везде должен быть 2049.

Теперь проверяем, поддерживает ли ядро NFS. Для этого вводим:

cat /proc/filesystems | grep nfs

Полученное значение должно выглядеть так: nodev nfsd

Это означает, что всё функционирует правильно. Если нет, то вводим команду:

При помощи её мы ставим модуль ядра самостоятельно.

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

sudo systemctl enable nfs

Итак, серверную часть мы установили, осталось правильно её настроить и перейти к клиентской.

Настройка

Настройка NFS в Ubuntu заключает в себе расшаривание определённых папок.

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

• rw - reading and writing этот параметр разрешает чтение и запись файлов в папке.
• ro - reading only - разрешает только чтение папки.
• sync (по умолчанию) - параметр обеспечивает надёжность передачи. Если включен он, то нельзя будет одновременно передавать несколько файлов или на разные компьютеры. Эта настройка не даст отвечать на другие запросы. Предотвращает утерю данных, но передача может идти медленнее.
• async - обратный предыдущему параметр. Передача идёт быстрее, но возникает риск потери информации.
• secure - опция разрешает использовать только порты, номер которых ниже 1024. Включена по умолчанию.
• insecure - разрешает использование любых портов.
• nohide - если вы монтируете несколько директорий, среди которых есть вложенные, то вложенные в отличие от родительской будут отображаться как пустые. Исправить это поможет параметр
• anonuid - указывает uid для анонимов. Это специальный идентификатор пользователя.
• anongid - указывает gid для анонимов. GID (Group ID) - ещё один идентификатор пользователя.
• no_subtree_check - функция отключает контроль поддерева. Дело в том, что без неё NFS дополнительно проверяет, что пользователи обращаются только в нужные разделы каталога. Это замедляет работу. Параметр позволяет ускорить её, но понижает безопасность.

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

Создадим новую папку. Можно использовать и новую. Наша папка будет /var/network.

Теперь необходимо добавить эту папку в файл /etc/exports. Там хранятся все файлы и папки с открытым сетевым доступом. Запись должна выглядеть так:

/var/network168.1.1(rw,async,no_subtree_check)

192.168.1.1 - это IP, по которому мы осуществляем передачу. Указывать его обязательно.

Обновляем таблицу экспорта:

Теперь попробуем получить доступ к папке со стороны клиента.

Установка и настройка клиентской части NFS

Ubuntu

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

Устанавливаем специальный клиентский пакет:

sudo apt install nfs-common

sudo mount 192.168.1.1:/var/network/ /mnt/

Сетевая папка подключена. С помощью df можно проверить все подключенные сетевые папки:

Также можно проверить свой уровень доступа специальной командой:

Отключаем файловую систему следующим образом:

Почти везде используется команда mount. Она отвечает за процесс монтирования, то есть, подготовки пространства на жёстком диске для использования его операционной системой. Звучит сложно, но если упростить, получится, что мы просто перекидываем сетевые файлы на наш компьютер в новоявленную папку. Здесь она называется /mnt/.

Windows

С Виндой, как правило, всё складывается куда сложнее. NFS клиент без проблем можно запустить на всех серверных Windows. Из стандартных он присутствует на:

• Windows 7 Ultimate/Enterprise
• Windows 8/8.1 Enterprise
• Windows 10 Enterprise

Больше нигде не найти. Если у вас одна из этих версий, делаем следующее:

1. Открываем меню «Программы и компоненты».
2. Жмём «Добавление компонентов».
3. Находим там NFS и ставим только «Клиент для NFS», другой компонент нам не нужен.

После подключения монтируется всё такой же командой:

mount 192.168.1.1:/var/network/ /mnt/

Размонтировать можно следующим образом:

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

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

Теперь у вас появились базовые представления о том, как можно использовать NFC и провести простейшую настройку. Этих знаний хватит, чтобы наладить доступ с одного компьютера к другому. Причём в роли клиента может выступить и ПК на Windows.

NFS (Network File System) — сетевой протокол доступа к доступ к файлам и файловой системе NFS-сервера, популярный в семейства ОС Linux/ UNIX, а также различных системах хранения. Microsoft также, не желая отставать от конкурентов, внедрила базовый функционал NFS сервера еще в Windows Server 2003 R2. В последующих версиях серверных платформ Microsoft возможности встроенного NFS Windows сервера расширялись, появлялся новый функционал и средства управления. NFS сервер в Windows Server 2012 – очередная веха в развитии данной технологии.

Что же нового предлагают нам разработчики Microsoft в данном продукте? Новые возможности NFS сервера в Windows Server 2012:

1. Поддержка стандарта NFS v4.1 . Поддержка последней версии NFS 4.1 – одно из основных новшеств Windows Server 2012. По сравнению с NFS v3 этот протокол обеспечивает повышенную безопасность, производительность и совместимость, полностью реализуя все аспекты RFC 5661.
2. Производительность «из коробки». Благодаря использованию новой транспортной инфраструктуры RPC-XDR, оптимальная производительность NFS сервера может быть достигнута сразу «из коробки» без необходимости тонкой настройки параметров системы. Оптимальная производительность достигается за счет автоматически настраивающегося кэша, разделения рабочих процессов на пулы и динамическое управление пулами, основанное на их нагрузке.
3. Упрощенное развертывание и управление . Данный факт достигнут за счет:
   • — более 40 командлетов PowerShell для настройки сервера NFS и управления общими папками
   • — простого графического интерфейса управления, позволяющего одновременно управлять как SMB, так и NFS шарами, а также настройками скрининга файлов и .
   • — фиксации RPC порта (порт 2049) для простоты настройки файерволов
   • — нового провайдера WMI v2
   • — упрощенной идентификации за счет плоского файла мапинга
4. Улучшения в NFSv3 . За счет быстрой отправки клиентам уведомлений о сбоях монитором NSM (Network Status Monitor), старые NFS клиенты лучше и быстрее обрабатывают процедуру failover, что означает меньшее время простоя.

Итак, NFS сервер в Windows Server 2012 значительно улучшен с точки зрения простоты развертывания, масштабируемость, стабильность, доступность, надежность, безопасности и совместимости. Общие папки могут быть одновременно доступны по протоколам SMB и NFS, что означает возможность использования Windows Server 2012 в качестве хранилища в гетерогенных сетях.

NFS сервер в Windows Server 2012 можно установить с помощью GUI и Powershell. Чтобы установить NFS сервер с помощью графического интерфейса, откройте и внутри роли файлового сервера (File and Storage Services) отметьте компонент Server for NFS .

После окончания установки компонента NFS, сервер необходимо перезагрузить.

Установка этой же роли с помощью Powershell также не вызывает затруднений, просто выполните команду:

Add-WindowsFeature "FS-NFS-Service"

Настройка общей папки NFS в Windows Server 2012

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

Создание общего каталога NFS с помощью консоли Server Manager

Откройте консоль Server Manager , перейдите в раздел Share management (находится внутри роли File and Storage Services ).
В контекстном меню запустите мастер создания нового общего каталога- New Share…

Выберите тип шары NFS Share — Quick

Затем необходимо задать тип аутентификации NFS клиентов: возможно, задействовать как Kerberos- аутентификацию, так и анонимную.

Предположим, в качестве потребителя создаваемого NFS ресурса будет выступать сервер виртуализации ESXi, в котором возможность аутентифицировать NFS соединения отсутствует (ESXi не поддерживает NFSv4). Поэтому тип аутентификации будет No Server Authentication , отметим также опции Enable unmapped user access и Allow unmapped user access by UID/GID .

Чтобы немного обезопасить создаваемую NFS шару от доступа сторонних лиц, ограничим доступ к NFS ресурсу по IP адресу клиента.

Host: 192.168.1.100
Language Encoding : BIG5
Share Permissions : Read/Write
Allow root access : Yes

Далее осталось проверить, что на уровне NTFS пользователь, в которого мапится подключающийся юзер, имеет доступ на чтение/запись (если решено задействовать анонимный доступ, придется для пользователя Everyone дать полные r/w права на уровне NTFS).

Как создать NFS шару с помощью Powershell

Создадим новую NFS шару:

New-NfsShare -Name "NFS " -Path "d:\shares\nfr" -AllowRootAccess $true -Permission Readwrite -Authentication sys

Разрешим доступ к шаре для IP адреса 192.168.1.100 и зададим кодировку BIG5 (возможность просмотра содержимого NFS шары для клиента ESXi).

Grant-NfsSharePermission -Name “NFS” -ClientName 192.168.1.100 -ClientType host -LanguageEncoding BIG5

Созданную NFS шару можно использовать, например, как NFS-datastore в среде виртуализации , или для доступа к данным с других Unix-like клиентов. Как смонтировать NFS шару в Windows — клиентах описано в статье.

#image.jpgНеплохого времени, читатели и гости моего блога. Очень большой перерыв меж постами был, но я снова в бою). В сегодняшней статье рассмотрю работу протокола 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 и имеет в своей истории Четыре версии. NFSv1 была разработана в Одна тыща девятьсот восемьдесят девять и являлась экспериментальной, работала на протоколе UDP. Версия Один описана в RFC 1094.

NFSv2 была выпущена в том же Одна тыща девятьсот восемьдесят девять г., описывалась тем же RFC1094 и так же базировалась на протоколе UDP, при всем этом позволяла читать наименее 2Гб из файла. NFSv3 доработана в Одна тыща девятьсот девяносто 5 г. и описана в RFC 1813.

Основными нововведениями третьей версии стало поддержка файлов большого размера, добавлена поддержка протокола TCP и TCP-пакетов большущего размера, что существенно ускорило работоспосбоность технологии. NFSv4 доработана в Две тыщи г. и описана в RFC 3010, в Две тыщи три г. пересмотрена и описана в RFC 3530.

4-ая версия включила в себя улучшение производительности, поддержку различных средств аутентификации (а конкретно, Kerberos и LIPKEY с внедрением протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов). NFS версии v4.1 была одобрена IESG в Две тыщи 10 г., и получила номер RFC 5661.

Принципным нововведением версии 4.1, является спецификация pNFS - Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в образце сетевой файловой системы поможет строить распределённые «облачные» («cloud») хранилища и информационные системы.

NFS сервер

Так как у нас NFS - это сетевая файловая система, то необходимо настроить сеть в Linux. (Так же можно почитать статью главные понятия сетей). Далее необходимо установить соответствующий пакет. В 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 Один root root 20 Окт Восемнадцать 15:02 S15nfs-common -> ../init.d/nfs-common lrwxrwxrwx Один root root 20 семь Окт 20 два 01:23 S16nfs-kernel-server -> ../init.d/nfs-kernel-server

Другими словами, сначала запускается nfs-common , позже сам сервер nfs-kernel-server .

В RedHat ситуация схожая, за тем только исключением, что 1-ый скрипт называется 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 в ядре Linux (другими словами в файле /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:

• rpc.statd - Бес наблюдения за сетевым состоянием (он же Network Status Monitor, он же NSM). Он позволяет корректно отменять блокировку после сбоя/перезагрузки. Для уведомления о нарушении употребляет программу /usr/sbin/sm-notify. Бес statd работает как на серверах, так и на клиентах. Ранее данный сервер был нужен для работы rpc.lockd, но за блокировки сейчас отвечает ядро (прим: если я не ошибаюсь #image.jpg). (RPC программа 100 тыщ 20 один и 100 тыщ 20 четыре - в новых версиях)
• rpc.lockd - Бес блокировки lockd (он же NFS lock manager (NLM)) обрабатывает запросы на блокировку файлов. Бес блокировки работает как на серверах, так и на клиентах. Клиенты запрашивают блокировку файлов, а серверы ее разрешают. (устарел и в новых дистрибутивах не употребляется как бес. Его функции в современных дистрибутивах (с ядром старше 2.2.18) выполняются ядром, точнее модулем ядра (lockd).) (RPC программа 100024)
• 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.idmapd - Бес idmapd для NFSv4 на сервере преобразует локальные uid/gid юзеров в формат вида имя@домен, а сервис на клиенте преобразует имена юзеров/групп вида имя@домен в локальные идентификаторы пользователя и группы (согласно конфигурационному файлу /etc/idmapd.conf, подробней в man idmapd.conf):.
• дополнительно, в старых версиях NFS использовались бесы: nfslogd - бес журналов NFS фиксирует активность для экспортированных файловых систем, работает на серверах NFS и rquotad - сервер удаленных квот предоставляет информацию о квотах юзеров в удаленных файловых системах, может работать как на серверах, так и на клиентах.(RPC программа 100011)

В 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 порт 100 одиннадцать и UDP порт 111.

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

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

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

ARCHIV ~ # rpcinfo -p прог-ма верс прото порт 100 тыщ Два tcp 100 одиннадцать portmapper 100 тыщ Два udp 100 одиннадцать portmapper 100 тыщ 20 четыре Один udp 50 девять тыщ четыреста 50 один status 100 тыщ 20 четыре Один tcp Шестьдесят тыщ восемьсот 70 два status 100 тыщ 20 один Один udp 40 четыре тыщи триста 10 nlockmgr 100 тыщ 20 один Три udp 40 четыре тыщи триста 10 nlockmgr 100 тыщ 20 один Четыре udp 40 четыре тыщи триста 10 nlockmgr 100 тыщ 20 один Один tcp 40 четыре тыщи восемьсот 50 один nlockmgr 100 тыщ 20 один Три tcp 40 четыре тыщи восемьсот 50 один nlockmgr 100 тыщ 20 один Четыре tcp 40 четыре тыщи восемьсот 50 один nlockmgr 100 тыщ три Два tcp Две тыщи 40 девять nfs 100 тыщ три Три tcp Две тыщи 40 девять nfs 100 тыщ три Четыре tcp Две тыщи 40 девять nfs 100 тыщ три Два udp Две тыщи 40 девять nfs 100 тыщ три Три udp Две тыщи 40 девять nfs 100 тыщ три Четыре udp Две тыщи 40 девять nfs 100 тыщ 5 Один udp 50 одна тыща триста 6 mountd 100 тыщ 5 Один tcp 40 одна тыща четыреста 5 mountd 100 тыщ 5 Два udp 50 одна тыща триста 6 mountd 100 тыщ 5 Два tcp 40 одна тыща четыреста 5 mountd 100 тыщ 5 Три udp 50 одна тыща триста 6 mountd 100 тыщ 5 Три tcp 40 одна тыща четыреста 5 mountd

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

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

NFS сервер (точнее бес rpc.nfsd) получает запросы от клиента в виде UDP датаграмм на порт 2049. Несмотря на то, что NFS работает с преобразователем портов, что позволяет серверу использовать динамически назначаемые порты, UDP порт Две тыщи 40 девять жестко закреплен за 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:

Настройка сервера 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, кому верить - не знаю #image.jpg Даже на http://nfs.sourceforge.net/ трактовка не однозначна.

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

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

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

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

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

Где точка_экспорта абсолютный путь экспортируемой иерархии каталогов, клиент1 - n имя 1-го или более клиентов или 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 приводит к появлению 2-ой иерархии каталогов без тривиального монтирования. (прим: я данную опцию так и не смог вынудить работать...)
• ro (rw) - Разрешает только запросы на чтение (запись). (в конечном счете - может быть прочитать/записать или нет определяется на основании прав файловой системы, при всем этом сервер не способен отличить запрос на чтение файла от запроса на выполнение, поэтому разрешает чтение, если у пользователя есть права на чтение или выполнение.)
• secure (insecure) - просит, чтобы запросы NFS поступали с защищенных портов (< 1024), чтобы программа без прав root не могла монтировать иерархию каталогов.
• subtree_check (no_subtree_check) - Если экспортируется подкаталог фаловой системы, но не вся файловая система, сервер проверяет, находится ли запрошенный файл в экспортированном подкаталоге. Отключение проверки уменьшает безопасность, но увеличивает скорость передачи данных.
• sync (async) - указывает, что сервер должен отвечать на запросы только после записи на диск конфигураций, выполненных этими запросами. Функция async указывает серверу не ждать записи инфы на диск, что наращивает производительность, но понижает надежность, т.к. в случае обрыва соединения или отказа оборудования возможна утрата инфы.
• wdelay (no_wdelay) - указывает серверу задерживать выполнение запросов на запись, если ожидается последующий запрос на запись, записывая данные более большими блоками. Это наращивает производительность при отправке больших очередей команд на запись. no_wdelay указывает не откладывать выполнение команды на запись, что может быть полезно, если сервер получает неограниченное количество команд не связанных совместно.

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

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

Файл устройства относится к интерфейсу ядра Linux. При экспорте файла устройства экспортируется этот интерфейс. Если клиентская система не имеет устройства такого же типа, то экспортированное устройство не будет работать.

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

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

Функции отображения (соответствия) идентификаторов юзеров

Для большего понимания нижесказанного я бы посоветовал ознакомиться со статьей Управление пользователями Linux. Каждый пользователь Linux имеет свои UID и главный GID, которые описаны в файлах /etc/passwd и /etc/group.

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

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

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

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

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

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

• nfsstat
• showmsecure (insecure)ount
• exportfs

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 может производиться с помощью команды mount или с помощью 1-го из расплодившихся автоматических монтировщиков (amd, autofs, automount, supermount, superpupermount). Процесс монтирования отлично продемонстрирована выше на иллюстрации.

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

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

3-ий способ с 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)

1-ая команда монтирует экспортированный каталог /archiv-small на сервере archiv в локальную точку монтирования /archivs/archiv-small с опциями по умолчанию (другими словами для чтения и записи).

Хотя команда mount в последних дистрибутивах умеет обдумывать какой тип файловой системы употребляется и без указания типа, все же указывать параметр -t nfs лучше. 2-ая команда монтирует экспортированный каталог /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 (индексных дескрипторах), такие как время модификации, размер, жесткие ссылки, владелец, обычно изменяются изредка для обыденных файлов и еще реже - для каталогов. Многи программы, например ls, обращаются к файлам только для чтения и не меняют атрибуты файлов или содержимое, но затрачивают ресурсы системы на дорогостоящие сетевые операции.

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

• ac (noac) (attrebute cache - кэширование атрибутов) - Разрешает кэширование атрибутов (по-умолчанию). Хотя функция noac замедляет работу сервера, она позволяет избежать устаревания атрибутов, когда несколько клиентов активно записывают информацию в общию иерархию.
• acdirmax=n (attribute cache directory file maximum - кэширование атрибута максимум для файла каталога) - Наибольшее количество секунд, которое NFS ожидает до обновления атрибутов каталога (по-умолчанию Шестьдесят сек.)
• acdirmin=n (attribute cache directory file minimum - кэширование атрибута минимум для файла каталога) - Маленькое количество секунд, которое NFS ожидает до обновления атрибутов каталога (по-умолчанию 30 сек.)
• acregmax=n (attribute cache regular file maximum - кэширование атрибута максимум для обыденного файла) - Максимаьное количество секунд, которое NFS ожидает до обновления атрибутов обыденного файла (по-умолчанию Шестьдесят сек.)
• acregmin=n (attribute cache regular file minimum- кэширование атрибута минимум для обыденного файла) - Маленькое количество секунд, которое NFS ожидает до обновления атрибутов обыденного файла (по-умолчанию Три сек.)
• 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 - значение таймаута) - Количество 10-х толикой секунды ожидания службой NFS до повторной передачи в случае RPC или малого таймаута (по-умолчанию 7). Это значение растет при каждом таймауте до большего значения Шестьдесят секунд или до пришествия большого таймаута. В случае занятой сети, медленного сервера или при прохождении запроса через несколько маршрутизаторов или шлюзов увеличение этого значения может повысить производительность.

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

Описание файла /etc/fstab я затрагивал в соответствующей статье. В текущем примере я рассмотрю несколько примеров монтирования файловых систем NFS с описанием опций:

FILES ~ # cat /etc/fstab | grep nfs archiv:/archiv-small /archivs/archiv-small nfs rw,timeo=4,rsize=16384,wsize=16384 Нуль Нуль nfs-server:/archiv-big /archivs/archiv-big nfs rw,timeo=50,hard,fg Нуль 0

1-ый пример монтирует файловую систему /archiv-small с хоста archiv в точку монтирования /archivs/archiv-small, тип файловой системы указан nfs (всегда необходимо указывать для данного типа), файловая система монтирована с опцией для чтения, записи (rw).

Хост archiv подключен по быстрому локальному каналу, поэтому для роста производительности параметр timeo уменьшен и существенно увеличены значения rsize и wsize. Поля для программ dump и fsck заданы в ноль, чтобы данные программы не использовали файловую систему, примонтированную по NFS.

2-ой пример монтирует файловую систему /archiv-big с хоста nfs-server. Т.к. к хосту nfs-server мы подключены по медленному соединению, параметр timeo увеличен до 5 сек (50 10-х толикой сек), а так же жестко задан параметр hard, чтобы NFS продолжала перемонтировать файловую систему после большого таймаута, так же задан параметр fg, чтобы при загрузке системы и недоступности хоста nfs-server не вышло зависания.

До того как сохранять конфигурации в /etc/fstab, обязательно попробуйте смонтировать вручную и убедитесь, что всё работает!!!

Повышение производительности NFS

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

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

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

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

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

FILES ~ # ping -s 30 две тыщи семьсот шестьдесят восемь archiv PING archiv.DOMAIN.local (10.0.0.6) 32768(32796) bytes of data. 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=1 ttl=64 time=0.931 ms 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=2 ttl=64 time=0.958 ms 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=3 ttl=64 time=1.03 ms 30 две тыщи семьсот 70 6 bytes from archiv.domain.local (10.0.0.6): icmp_req=4 ttl=64 time=1.00 ms 30 две тыщи семьсот 70 6 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

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

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

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

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

• лучше предварительно размонтировать все ресурсы на клиентах
• остановить и запретить запуск rpcidmapd, если не планируется внедрение NFSv4: chkconfig --level Триста 40 5 rpcidmapd off service rpcidmapd stop
• если нужно, то разрешить запуск сервисов portmap, nfs и nfslock: chkconfig --levels Триста 40 5 portmap/rpcbind on chkconfig --levels Триста 40 5 nfs on chkconfig --levels Триста 40 5 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
• открыть порты в iptables
  • для 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 к порту Четыре тыщи (для старых систем в /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 для пользователя Девяносто девять с gid Девяносто девять /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99)) # Доступ на чтение и запись для клиента на 192.168.0.100, с доступом rw для пользователя Девяносто девять с gid Девяносто девять /files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99))

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

# chown -R nobody.nobody /files

Конфигурация клиента

На клиенте необходимо примонтировать удаленный каталогудобным способом, например командой mount:

FILES ~ # mount -t nfs archiv:/files /archivs/files

Резюме

Фух... Статья завершена. На данный момент мы изучили что такое Network File System и с чем ее едят, в следующей статье попробую сделать HOWTO с аутентификацией Kerberos. Надеюсь материал вышел доходчивым и нужным.

Буду рад Вашим дополнениям и комментариям!

NFS HOWTO, nfs.sourceforge, man nfs? man mount, man exports

RFC Одна тыща девяносто четыре - NFSv1, v2
RFC Одна тыща восемьсот тринадцать - NFSv3
RFC Три тыщи 500 30 - NFSv4
RFC 5 тыщ 600 шестьдесят один - NFSv4.1
NFS HOWTO
nfs.sourceforge.net
man mount
man exports