Протокол сетевой файловой службы (Network File Server, NFS) - это открытый стандарт на предоставление пользователю удаленного доступа к файловым системам. Созданные на его основе централизованные файловые системы облегчают ежедневное выполнение таких задач, как резервное копирование или проверка на вирусы, а объединенные дисковые разделы проще обслуживать, чем множество небольших и распределенных.

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

Лучшее понимание как самого протокола, так и деталей его реализации позволит легче справиться с практическими задачами. Данная статья посвящена NFS и состоит из двух логических частей: вначале описывается сам протокол и цели, поставленные при его разработке, а затем реализации NFS в Solaris и UNIX.

С ЧЕГО ВСЕ НАЧИНАЛОСЬ...

Протокол NFS разработан компанией Sun Microsystems и в 1989 г. появился в Internet в виде документа RFC 1094 под следующим названием: «Спецификация протокола сетевой файловой системы» (Network File System Protocol Specification, NFS). Интересно отметить, что и стратегия компании Novell в то время была направлена на дальнейшее усовершенствование файловых служб. До недавнего времени, пока движение за открытые коды еще не набрало силу, Sun не стремилась раскрывать секреты своих сетевых решений, однако даже тогда в компании понимали всю важность обеспечения взаимодействия с другими системами.

В документе RFC 1094 содержались две первоначальные спецификации. К моменту его публикации Sun разрабатывала уже следующую, третью версию спецификации, которая изложена в RFC 1813 «Спецификация протокола NFS, версия 3» (NFS Version 3 Protocol Specification). Версия 4 данного протокола определена в RFC 3010 «Спецификация протокола NFS, версия 4» (NFS Version 4 Protocol).

NFS широко используется на всех типах узлов UNIX, в сетях Microsoft и Novell, а также в таких решениях компании IBM, как AS400 и OS/390. Будучи неизвестной за пределами сетевого «королевства», NFS, пожалуй, самая распространенная платформенно-независимая сетевая файловая система.

ПРАРОДИТЕЛЕМ БЫЛ UNIX

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

NFS

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

В отличие от многих клиент-серверных систем, NFS для обмена информацией использует вызовы удаленных процедур (Remote Procedure Calls, RPC). Обычно клиент устанавливает соединение с заранее известным портом и затем, в соответствии с особенностями протокола, посылает запрос на выполнение определенного действия. В случае вызова удаленных процедур клиент создает вызов процедуры и затем отправляет его на исполнение серверу. Подробное описание NFS будет представлено ниже.

В качестве примера предположим, что некий клиент смонтировал каталог usr2 в локальной корневой файловой системе:

/root/usr2/ -> remote:/root/usr/

Если клиентскому приложению необходимы ресурсы этого каталога, оно просто посылает запрос операционной системе на него и на имя файла, а та предоставляет доступ через клиента NFS. Для примера рассмотрим простую команду UNIX cd, которая «ничего не знает» о сетевых протоколах. Команда

Cd /root/usr2/

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

Получив запрос, сервер NFS проверит наличие у данного пользователя права на выполнение запрашиваемого действия и в случае положительного ответа осуществит его.

ПОЗНАКОМИМСЯ ПОБЛИЖЕ

С точки зрения клиента, процесс локального монтирования удаленной файловой системы средствами NFS состоит из нескольких шагов. Как уже упоминалось, клиент NFS подаст вызов удаленной процедуры для выполнения ее на сервере. Заметим, что в UNIX клиент представляет собой одну программу (команда mount), в то время как сервер на самом деле реализован в виде нескольких программ со следующим минимальным набором: служба преобразования портов (port mapper), демон монтирования (mount daemon) и сервер NFS.

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

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

Служба преобразования портов сервера откликается на запросы в соответствии с поддерживаемым протоколом и портом, на котором работает демон монтирования. Клиентская программа mount вначале устанавливает соединение с демоном монтирования сервера, а затем передает ему с помощью RPC команду mount. Если данная процедура выполнена успешно, то клиентское приложение соединяется с сервером NFS (порт 2049) и, используя одну из 20 удаленных процедур, которые определены в RFC 1813 и приводятся нами в Таблице 1, получает доступ к удаленной файловой системе.

Смысл большинства команд интуитивно понятен и не вызывает каких-либо затруднений у системных администраторов. Приведенный ниже листинг, полученный с помощью tcdump, иллюстрирует команду чтения, создаваемую командой UNIX cat для прочтения файла с именем test-file:

10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 lookup fh 32,0/ 224145 "test-file" 10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 lookup fh 32,0/ 224145 "test-file" 10:30:16.012729 eth0 192.168.1.254.3476097947: reply ok 128 lookup fh 32,0/224307 (DF) 10:30:16.012729 eth0 192.168.1.254.3476097947: reply ok 128 lookup fh 32,0/224307 (DF) 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 read fh 32,0/ 224307 4096 bytes @ 0 10:30:16.013124 eth0 > 192.168.1.254. 3492875163 > 192.168.1.252.2049: 140 read fh 32,0/ 224307 4096 bytes @ 0 10:30:16.013650 eth0 192.168.1.254.3492875163: reply ok 108 read (DF) 10:30:16.013650 eth0 192.168.1.254.3492875163: reply ok 108 read (DF)

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

ДОСТУП В NFS

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

Первый способ основывается на встроенной в UNIX системе прав доступа к файлам для индивидуального пользователя или группы. Для упрощения обслуживания идентификация пользователей и групп должна быть единообразной для всех клиентов и серверов NFS. Защиту следует тщательно продумать: в NFS можно по неосторожности предоставить такой доступ к файлам, который не планировался при их создании.

Доступ на уровне разделяемых ресурсов позволяет ограничивать права, разрешив только определенные действия, независимо от принадлежности файла или привилегий UNIX. Например, работу с файловой системой NFS можно ограничить только чтением. Большинство реализаций NFS позволяет дополнительно ограничить доступ на уровне разделяемых ресурсов конкретными пользователями и/или группами. Например, группе «Отдел кадров» разрешается просмотр информации и не более того.

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

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

NFS В СТИЛЕ «ПИНГВИН»

Относящийся к Linux излагаемый материал основывается на системе Red Hat 6.2 с ядром версии 2.4.9, которая поставляется с пакетом nfs-utils версии 0.1.6. Существуют и более новые версии: на момент написания этой статьи самое последнее обновление пакета nfs-utils имело номер 0.3.1. Его можно загрузить по адресу: .

Пакет nfs-utils содержит следующие исполняемые файлы: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount и statd.

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

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

Для дистрибутивов, поддерживающих linuxconf, легко сконфигурировать службы NFS как для клиентов, так и для серверов. Однако быстрый способ установки NFS с помощью linuxconf не дает информации о том, какие файлы были созданы или отредактированы, что очень важно знать администратору для понимания ситуации в случае сбоя системы. Архитектура NFS в Linux имеет слабую связь с версией BSD, поэтому необходимые файлы и программы поддержки легко найти администраторам, работающим с BSD, Sun OS 2.5 или более ранними версиями NFS.

Файл /etc/exports, как и в более ранних версиях BSD, определяет файловые системы, к которым разрешен доступ клиентам NFS. Кроме того, он содержит ряд дополнительных возможностей, относящихся к вопросам управления и безопасности, предоставляя администратору средство для тонкой настройки. Это текстовый файл, состоящий из записей, пустых или закомментированных строк (комментарии начинаются с символа #).

Предположим, что мы хотим предоставить клиентам доступ только для чтения к каталогу /home на узле Lefty. Этому в /etc/exports будет соответствовать следующая запись:

/home (ro)

Здесь нам необходимо сообщить системе, какие каталоги мы собираемся сделать доступными с помощью демона монтирования rpc.mountd:

# exportfs -r exportfs: В /home (ro) не указано имя узла, введите *(ro) чтобы избежать предупреждения #

При запуске команда exportfs выводит предупреждение о том, что /etc/ exports не ограничивает доступ к отдельному узлу, и создает соответствующую запись в /var/lib/nfs/etab из /etc/exports, сообщающую, какие ресурсы можно просмотреть с помощью cat:

# cat /var/lib/nfs/etab /home (ro,async,wdelay,hide,secure,root_ squash, no_all_squash,subtree_check, secure_locks, mapping=identity,anonuid= -2,anongid=-2)

Другие параметры, перечисленные в виде списка в etab, включают значения по умолчанию, используемые NFS. Детали будут описаны ниже. Чтобы предоставить доступ к каталогу /home, необходимо запустить соответствующие службы NFS:

# portmap # rpc.mountd # rpc.nfsd # rpc.statd # rpc.rquotad

В любой момент после запуска демона монтирования (rpc.mountd) cправиться об отдельных файлах, доступных для вывода, можно, просмотрев содержимое файла /proc/fs/nfs/exports:

# cat /proc/fs/nfs/exports # Version 1.0 # Path Client(Flags) # IPs /home 192.168.1.252(ro,root_squash,async, wdelay) # 192.168.1.252 #

То же самое можно просмотреть и с помощью команды showmount с параметром -e:

# showmount -e Export list for lefty: /home (everyone) #

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

# showmount -a All mount points on lefty: 192.168.1.252:/home #

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

# rpc.mountd -N 1 -N 2

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

«ЗАПЛЫВ С ПИНГВИНАМИ»

Доступ к сконфигурированной выше Lefty, экспортируемой файловой системе NFS на базе Linux, зависит от клиентской операционной системы. Стиль установок для большинства операционных систем семейства UNIX совпадает со стилем либо исходных систем Sun OS и BSD, либо более новой Solaris. Так как данная статья посвящена обеим системам, Linux и Solaris, давайте рассмотрим клиентскую конфигурацию Solaris 2.6 с точки зрения установления соединения с Linux-версией NFS, описанной нами выше.

Благодаря свойствам, унаследованным Solaris 2.6, ее легко сконфигурировать для работы в качестве клиента NFS. Для этого требуется лишь одна команда:

# mount -F nfs 192.168.1.254:/home /tmp/tmp2

Предположим, что предыдущая команда mount выполнена успешно, тогда команда mount без параметров выведет следующее:

# mount / on /dev/dsk/c0t0d0s0 read/write/setuid/ largefiles on Mon Sep 3 10:17:56 2001 ... ... /tmp/tmp2 on 192.168.1.254:/home read/ write/remote on Mon Sep 3 23:19:25 2001

Давайте проанализируем вывод tcpdump, полученный на узле Lefty, после того, как пользователь ввел команду ls /tmp/tmp2 на узле Sunny:

# tcpdump host lefty and host sunny -s512 06:07:43.490583 sunny.2191983953 > lefty.mcwrite.n.nfs: 128 getattr fh Unknown/1 (DF) 06:07:43.490678 lefty.mcwrite.n.nfs > sunny.2191983953: reply ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:07:43.491397 sunny.2191983954 > lefty.mcwrite.n.nfs: 132 access fh Unknown/10001 (DF) 06:07:43.491463 lefty.mcwrite.n.nfs > sunny.2191983954: reply ok 120 access c0001 (DF) 06:07:43.492296 sunny.2191983955 > lefty.mcwrite.n.nfs: 152 readdirplus fh 0,1/16777984 1048 bytes @ 0x000000000 (DF) 06:07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955: reply ok 1000 readdirplus (DF)

Мы видим, что узел Sunny запрашивает для ls описатель файла (fh), на что узел Lefty в ответ посылает OK и возвращает структуру каталога. Затем Sunny проверяет разрешение на право доступа к содержимому каталога (132 access fh) и получает ответ с разрешением от Lefty. После этого узел Sunny, используя процедуру readdirplus, считывает полное содержимое каталога. Вызовы удаленных процедур описаны в документе RFC 1813 и приведены нами в начале данной статьи.

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

Проще всего устранить проблемы на сервере с узла, на котором работает сервер. Однако, когда администрированием сервера занимается вместо вас кто-то другой, это не всегда возможно. Быстрый способ убедиться, что соответствующие службы сервера правильно сконфигурированы, - использовать команду rpcinfo с параметром -p. С узла Solaris Sunny можно определить, какие процессы RPC зарегистрированы на узле Linux:

# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 udp 692 status 100024 1 tcp 694 status 100005 3 udp 1024 mountd /100005 3 tcp 1024 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100021 1 udp 1026 nlockmgr 100021 3 udp 1026 nlockmgr 100021 4 udp 1026 nlockmgr #

Заметим, что здесь же приводится информация о версиях, что достаточно полезно, когда для работы системы требуется поддержка различных протоколов NFS. Если какая-либо служба не запущена на сервере, то такая ситуация должна быть исправлена. В случае неудачного монтирования приводимая ниже команда rpcinfo -p позволит выяснить, что служба mountd на сервере не работает:

# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind ... ... 100021 4 udp 1026 nlockmgr #

Команда rpcinfo очень полезна для выяснения, активен ли тот или иной удаленный процесс. Параметр -p - самый важный из ключей. Для ознакомления со всеми возможностями rpcinfo обратитесь к справочной странице man.

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

Наконец, еще одним достаточно полезным инструментом определения причин сбоев системы является tcpdump:

# tcpdump host lefty and host sunny -s512 tcpdump: listening on eth0 06:29:51.773646 sunny.2191984020 > lefty.mcwrite.n.nfs: 140 lookup fh Unknown/1"test.c" (DF) 06:29:51.773819 lefty.mcwrite.n.nfs > sunny.2191984020: reply ok 116 lookup ERROR: No such file or directory (DF) 06:29:51.774593 sunny.2191984021 > lefty.mcwrite.n.nfs: 128 getattr fh Unknown/1 (DF) 06:29:51.774670 lefty.mcwrite.n.nfs > sunny.2191984021: reply ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:29:51.775289 sunny.2191984022 > lefty.mcwrite.n.nfs: 140 lookup fh Unknown/1"test.c" (DF) 06:29:51.775357 lefty.mcwrite.n.nfs > sunny.2191984022: reply ok 116 lookup ERROR: No such file or directory (DF) 06:29:51.776029 sunny.2191984023 > lefty.mcwrite.n.nfs: 184 create fh Unknown/1 "test.c" (DF) 06:29:51.776169 lefty.mcwrite.n.nfs > sunny.2191984023: reply ok 120 create ERROR: Permission denied (DF)

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

Если файловая система смонтирована, то большинство типичных ошибок связано с обычными правами доступа UNIX. Использование uid или NIS+ в Sun помогает избежать глобального установления прав доступа на все файловые системы. Некоторые администраторы практикуют «открытые» каталоги, когда права доступа на их чтение даются «всему миру». Однако этого следует избегать по причинам безопасности. Даже отбросив в сторону проблемы защиты, все равно придется признать такой подход порочной практикой, поскольку пользователи редко создают данные с намерением сделать их доступными для чтения всем подряд.

Обращения привилегированного пользователя (root) к смонтированным файловым системам NFS трактуются по-особому. Чтобы избежать предоставления привилегированному пользователю неограниченного доступа, запросы от него трактуются так, как будто бы они поступают от пользователя nobody («никто»). Этот действенный механизм ограничивает доступ привилегированного пользователя глобально доступными для чтения и разрешенными для записи файлами.

СЕРВЕР NFS, ВЕРСИЯ SOLARIS

Конфигурирование Solaris для работы в качестве сервера NFS так же просто, как и в случае с Linux. Однако команды и местоположение файлов несколько отличаются. При начальной загрузке Solaris по достижении уровня загрузки 3 (run level 3) автоматически запускаются службы NFS и экспортируются все файловые системы. Для запуска этих процессов вручную введите команду:

#/usr/lib/nfs/mountd

Для запуска демона монтирования и сервера NFS введите:

#/usr/lib/nfs/nfsd

Начиная с версии 2.6 в Solaris для указания экспортируемых файловых систем больше не используется файл экспорта. Теперь файлы экспортируются с помощью команды share. Предположим, мы хотим позволить удаленным узлам смонтировать /export/home. Введем для этого следующую команду:

Share -F nfs /export/home

Мероприятия по обеспечению безопасности

БЕЗОПАСНОСТЬ В LINUX

Некоторые системные службы NFS на основе Linux имеют дополнительный механизм ограничения доступа посредством управляющих списков или таблиц. На внутреннем уровне этот механизм реализован с помощью библиотеки tcp_wrapper, которая для формирования списков контроля доступа использует два файла: /etc/hosts.allow и /etc/hosts/deny. Исчерпывающий обзор правил работы с tcp_wrapper выходит за рамки данной статьи, основной же принцип состоит в следующем: сопоставление вначале производится с etc/hosts.allow, а затем с /etc/hosts. deny. Если правило не найдено, то запрашиваемая системная служба не представляется. Чтобы обойти последнее требование и обеспечить очень высокий уровень безопасности, в конец /etc/hosts.deny можно добавить следующую запись:

ALL: All

После этого можно использовать /etc/ hosts.allow, чтобы установить тот или иной режим работы. Например, файл /etc/hosts. allow, который я использовал при написании данной статьи, содержал следующие строки:

Lockd:192.168.1.0/255.255.255.0 mountd:192.168.1.0/255.255.255.0 portmap:192.168.1.0/255.255.255.0 rquotad:192.168.1.0/255.255.255.0 statd:192.168.1.0/255.255.255.0

При этом разрешается определенный вид доступа к узлам до того, как будет предоставлен доступ на уровне приложений. В Linux доступом на уровне приложений управляет файл /etc/exports. Он состоит из записей в следующем формате:

Экспортируемый каталог {пробел} узел|сеть(опции)

«Экспортируемый каталог» - это каталог, обработка запроса к которому разрешена демону nfsd. «Узел|сеть» - это узел или сеть, имеющие доступ к экспортируемой файловой системе, а «опции» определяют те ограничения, какие демон nfsd налагает на использование данного разделяемого ресурса, - доступ только для чтения или преобразование идентификатора пользователя (user id mapping).

В следующем примере всему домену mcwrite.net предоставлен доступ в режиме только для чтения к /home/mcwrite.net:

/home/mcwrite.net *.mcwrite.net(ro)

Другие примеры можно найти на справочной странице exports man.

БЕЗОПАСНОСТЬ NFS В SOLARIS

В Solaris возможности по предоставлению доступа к NFS аналогичны Linux, однако в этом случае ограничения задаются с помощью определенных параметров в команде share с ключом -o. Следующий пример показывает, как разрешить монтирование в режиме только для чтения /export/mcwrite.net на любом узле домена mcwrite.net:

#share -F nfs -o ro=.mcwrite.net/ export/ mcwrite.net

Справочная страница man для share_nfs подробно описывает предоставление доступа с помощью управляющих списков в Solaris.

Ресурсы Internet

В NFS и RPC не обошлось без «дыр». Вообще говоря, NFS не следует использовать при работе в Internet. Нельзя делать «дыры» в брандмауэрах, предоставляя какой бы то ни было доступ посредством NFS. Необходимо тщательно следить за всеми появляющимися заплатами для RPC и NFS, в чем могут помочь многочисленные источники информации по вопросам безопасности. Два наиболее популярных источника - Bugtraq и CERT:

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

» и уже имеешь представление о «сетевой файловой системе», ее возможностях и степени защищенности. Однако в указанной статье все разбиралось в основном с точки зрения клиента… а вот как быть если тебе захотелось поиметь собственный NFS-сервер? (прим.: «поиметь» не значит «сломать», а значит «установить и настроить»).

Ну, а если желание такое у тебя появилось, то первый вопрос, который ты должен задать себе: «А нафига козе баян?». Ибо ставить NFS-сервер у себя дома
довольно бессмысленно — никто не оценит, а вот если тебе посчастливилось админить в конторе «людей в черном», или в новомодной «ДОМашней сети» — тогда совсем другое дело…

Запустить сам сервер дело довольно нехитрое, если ты читал предыдущую статью, то вполне с этим справишься. Итак, тебе понадобятся следующие демоны:

• nfsd — непосредственное обслуживание протокола
  NFS;
• mountd — обслуживание операций монтирования;
• rpc.portmap — демон портов RPC; нужен поскольку запросы к NFS-серверу передаются в виде пакетов
  RPC;

Как это сделать? Очень просто — сходи в файл «/etc/rc.d/rc.inet2» и раскомментируй соответствующие строки. Все можно считать, что первичный запуск произведен, немного сложнее будет все это настроить…
Первое, что нужно решить — это кто и какие права имеет относительно той или иной информации. Это настраивается посредством файла «/etc/exports». Разрешения бывают «на чтение» и «на чтение и запись». Как это настраивается, описано в «Основах
NFS».

Второе — это конечно же нагрузка на сервер, т.е. количество активных пользователей и их примерные запросы. Запросы к NFS-серверу обычно делят на два типа: первый — когда клиент работает с атрибутами, второй — когда клиент запрашивает непосредственно данные. Запросы первого типа — это поиск файла, считывание списка разрешений и т.д., конечно, ты понимаешь, что они слабо нагружают сеть. Запросы второго типа — это передача и прием от клиента непосредственно содержимого файлов; и именно здесь встает вопрос: «что и как часто будет передаваться?» Этот особенно актуален, если у тебя сеть в 10 Мбит/сек (ну проще говоря — стандартная российская сеть). Если ты знаешь, то 10 Мбит/сек — это чуть больше 1 Мбайта в секунду; естественно, если постоянно будут передаваться файлы размером в десятки мегабайт, то сеть попросту умрет. Если твоя ситуация именно такова, то тебе понадобится установит кэширование данных на клиентской машине (демон biod). Тогда, однажды затребовав какой либо файл и обратившись к нему повторно, клиент не будет «качать» его заново с сервера, а возьмет у себя из кэша; при этом будет регулярно проверяться не изменился ли файл на сервере, если же факт изменения будет выявлен, то файл в кэше будет заменен «свежей версией»
(как ты понимаешь, проверка «изменился ли файл» — это запрос «по атрибутам», который зачастую в сотни раз меньше, чем сам файл).

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

Вместо заключения:

Если перед тобой стоит вопрос организации обмена данными в сети, то не раздумывая выбирай NFS — NFS на три головы выше головы выше, чем
FTP и на голову выше виндовых «шаров», а в настройке не так уж и сложна…

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

Введение в NFS

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

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

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

История Network File System

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

NFS сервер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• nfsstat
• showmsecure (insecure)ount

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

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

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

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

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

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

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

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

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

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

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

Параметры exportfs:

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

Клиент NFS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждый знает, что в UNIX-системах файловая система логически представляет собой набор физических файловых систем, подключенных к одной точке. Одна из самых основных прелестей такой организации, на мой взгляд, состоит в возможности динамически модифицировать структуру существующей файловой системы. Также, благодаря усилиям разработчиков, мы на сегодняшний день имеем возможность подключить ФС практически любого типа и любым удобным способом. Говоря «способом», я прежде всего хочу подчеркнуть возможность работы ядра ОС с файловыми системами посредством сетевых соединений.

Множество сетевых протоколов предоставляют нам возможность работы с удаленными файлами, будь то FTP, SMB, Telnet или SSH. Благодаря способности ядра, в конечном итоге, не зависеть от типа подключаемой ФС, мы имеем возможность при помощи программы mount подключать что угодно и как угодно.

Сегодня мне хочется рассказать об NFS — Network File System. Эта технология позволяет подключать отдельные точки ФС на удаленном компьютере к файловой системе локального компьютера. Сам протокол NFS позволяет выполнять операции с файлами достаточно быстро, безопасно и надежно. А что нам еще нужно? :-)

Что необходимо для того, чтобы это работало

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

Установка

Для запуска сервера NFS в моей Ubuntu 7.10 — the Gutsy Gibbon понадобилось установить пакеты nfs-common и nfs-kernel-server. Если же нужен только клиент NFS, то nfs-kernel-server устанавливать не нужно.

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

После того, как все пакеты успешно установлены, необходимо проверить, запущен ли демон NFS:

/etc/init.d/nfs-kernel-server status

Если демон не запущен, его нужно запустить командой

/etc/init.d/nfs-kernel-server start

После того, как все успешно запустилось, можно приступать к экспорту файловой системы. Сам процесс очень прост и занимает минимум времени.

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

Directory machine1(option11,option12) machine2(option21,option22)

directory — абсолютный путь к каталогу ФС сервера, к которому нужно дать доступ

machineX — DNS-имя или IP-адрес клиентского компьютера, с которого разрешается доступ

optionXX — параметры экспорта ФС, наиболее часто используемые из них:

• ro — доступ к файлам разрешается только для чтения
• rw — доступ предоставляется на чтение/запись
• no_root_squash — по умолчанию, если вы подключаетесь к ресурсу NFS от имени root, сервер, безопасности ради, на своей стороне будет обращаться к файлам от имени пользователя nobody. Однако, если включить эту опцию, то обращение к файлам на стороне сервера будет будет производиться от имени root. Аккуратней с этой опцией.
• no_subtree_check — по умолчанию, если вы на сервере экспортируете не весь раздел, а только часть ФС, демон будет проверять, является ли запрошенный файл физически размещенным на том же разделе или нет. В случае, если вы экспортируете весь раздел или точка подключения экспортируемой ФС не затрагивает файлы с других физических томов, то можно включить эту опцию. Это даст вам увеличение скорости работы сервера.
• sync — включайте эту опцию, если есть вероятность внезапного обрыва связи или отключения питания сервера. Если эта опция не включена, то очень повышается риск потери данных при внезапной остановке сервера NFS.

Итак, допустим, нам нужно дать доступ компьютеру ashep-desktop к каталогу /var/backups компьютера ashep-laptop. Доступ к каталогу необходим для копирования резервных копий файлов с ashep-desktop. У меня файл получился следующим:

/var/backups ashep-desktop(rw,no_subtree_check,sync)

После добавления строки в /etc/exports необходимо перезапустить сервер NFS для вступления изменений в силу.

/etc/init.d/nfs-kernel-server restart

Вот и все. Можно приступать к подключению экспортированной ФС на клиентском компьютере.

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

На клиентской стороне удаленная файловая система монтируется так же, как и все остальные — командой mount. Также, никто не запрещает вам использовать /etc/fstab в случае, если подключать ФС нужно автоматически при загрузке ОС. Итак, вариант с mount будет выглядеть так:

Mount -t nfs ashep-laptop:/var/backups/ /mnt/ashep-laptop/backups/

Если все прошло успешно и вам необходимо выполнять подключение к удаленной ФС автоматически при загрузке — просто добавляем строку в /etc/fstab:

Ashep-laptop:/var/backups /mnt/ashep-laptop/backups nfs auto 0 0

Что еще

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

До того, как вы продолжите читать этот документ вам будет необходимо успешно выполнять операцию 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.