Протокол сетевой файловой службы (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 или Network File System, это популярный протокол сетевой файловой системы, который позволяет пользователям подключать удаленные сетевые каталоги на своей машине и передавать файлы между серверами. Вы можете использовать дисковое пространство на другой машине для своих файлов и работать с файлами, расположенными на других серверах. По сути, это альтернатива общего доступа Windows для Linux, в отличие от Samba реализована на уровне ядра и работает более стабильно.
В этой статье будет рассмотрена установка nfs в Ubuntu 16.04. Мы разберем установку всех необходимых компонентов, настройку общей папки, а также подключение сетевых папок.
Как уже было сказано, NFS, это сетевая файловая система. Для работы необходим сервер, на котором будет размещена общая папка и клиенты, которые могут монтировать сетевую папку как обычный диск в системе. В отличие от других протоколов NFS предоставляет прозрачный доступ к удаленным файлам. Программы будут видеть файлы как в обычной файловой системе и работать с ними как с локальными файлами, nfs возвращает только запрашиваемую часть файла, вместо файла целиком, поэтому эта файловая система будет отлично работать в системах с быстрым интернетом или в локальной сети.
Установка компонентов NFS
Перед тем как мы сможем работать с NFS, нам придется установить несколько программ. На машину, которая будет сервером нужно установить пакет nfs-kernel-server, с помощью которого будет выполнено открытие шары nfs в ubuntu 16.04. Для этого выполните:
sudo apt install nfs-kernel-server
Теперь давайте проверим правильно ли установился сервер. Сервис NFS слушает соединения как для TCP, так и для UDP на порту 2049. Посмотреть действительно ли сейчас используются эти порты можно командой:
rpcinfo -p | grep nfs
Также важно проверить поддерживается ли NFS на уровне ядра:
cat /proc/filesystems | grep nfs
Видим, что работает, но если нет, нужно вручную загрузить модуль ядра nfs:
Давайте еще добавим nfs в автозагрузку:
sudo systemctl enable nfs
На клиентском компьютере вам нужно установить пакет nfs-common, чтобы иметь возможность работать с этой файловой системой. Вам необязательно устанавливать компоненты сервера, достаточно будет только этого пакета:
sudo apt install nfs-common
Настройка сервера NFS в Ubuntu
Мы можем открыть NFS доступ к любой папке, но давайте создадим для этих целей новую:
адрес_папки клиент (опции)
Адрес папки - это та папка, которую нужно сделать доступной по сети. Клиент - ip адрес или адрес сети, из которой могут получить доступ к этой папке. А вот с опциями немного сложнее. Рассмотрим некоторые из них:
- rw - разрешить чтение и запись в этой папке
- ro - разрешить только чтение
- sync - отвечать на следующие запросы только тогда, когда данные будут сохранены на диск (по умолчанию)
- async - не блокировать подключения пока данные записываются на диск
- secure - использовать для соединения только порты ниже 1024
- insecure - использовать любые порты
- nohide - не скрывать поддиректории при, открытии доступа к нескольким директориям
- root_squash - подменять запросы от root на анонимные
- all_squash - превращать все запросы в анонимные
- anonuid и anongid - указывает uid и gid для анонимного пользователя.
Например, для нашей папки эта строка может выглядеть вот так:
/var/nfs 127.0.0.1(rw,sync,no_subtree_check)
Когда все было настроено, осталось обновить таблицу экспорта NFS:
sudo exportfs -a
Вот и все, открытие шары nfs в ubuntu 16.04 завершено. Теперь попытаемся настроем клиента и попытаемся ее примонтировать.
Подключение NFS
Мы не будем подробно останавливаться на этом вопросе в сегодняшней статье. Это довольно большая тема, заслуживающая отдельной статьи. Но пару слов я все же скажу.
Чтобы подключить сетевую папку вам не нужен никакой nfs клиент ubuntu, достаточно использовать команду mount:
sudo mount 127.0.0.1:/var/nfs/ /mnt/
Теперь вы можете попытаться создать файл в подключенной директории:
Также мы посмотрите подключенные файловые системы с помощью df:
127.0.0.1:/var/nfs 30G 6,7G 22G 24% /mnt
Чтобы отключить эту файловую систему достаточно использовать стандартный umount:
sudo umount /mnt/
Выводы
В этой статье была рассмотрена настройка nfs ubuntu 16.04, как видите, все делается очень просто и прозрачно. Подключение NFS шары выполняется в несколько кликов, с помощью стандартных команд, а открытие шары nfs в ubuntu 16.04 ненамного сложнее подключения. Если у вас остались вопросы, пишите в комментариях!
Похожие записи:
Для раздачи файлов внутри локальной сети можно выделить такие технологии (рассматриваются системы на базе Linux):
- Network File System (NFS) - протокол сетевого доступа к файловым системам;
- Files transferred over Shell protocol (FISH) - сетевой протокол, который использует или RSH для передачи файлов между компьютерами;
- Secure SHell FileSystem (SSHFS) - клиент файловой системы для монтирования дисковых устройств на удаленных системах, для взаимодействия с удаленной системой используется SFTP ;
- Samba - пакет программ, которые позволяют обращаться к сетевым дискам и принтерам на различных операционных системах по протоколу SMB/CIFS;
В данной заметке речь пойдет про NFS .
NFS (Network File System) полезна когда нужно раздать файлы/директории всем внутри сети. Прозрачность доступа с помощью NFS позволяет клиентам подключить удаленную файловую систему как локальную директорию, причем файловые системы могут быть разных типов. Это означает, что любое приложение клиента, которое может работать с локальным файлом, с таким же успехом может работать и с файлом подключенным по NFS , без каких либо модификаций самой программы.
К преимуществам NFS можно отнести:
На данный момент доступна NFS v4.1 , в которой ввели новую возможность pNFS позволяющей распараллелить реализацию общего доступа к файлам. Также есть расширение для NFS 2 и 3 - WebNFS , которое позволяют легче интегрироваться в веб-браузеры и дает возможность работать через брандмауэр.
Схема работы NFS протокола.
Установка и настройка NFS-сервер под Linux
Проверим поддерживает ли система NFS
Cat /proc/filesystems | grep nfs
Под Arch Linux сервер и клиент находиться в одном пакете
Yaourt -S nfs-utils
Для установки сервера (nfs-kernel-server ) и клиента (nfs-common ) под Ubuntu необходимы пакеты
Sudo apt-get install nfs-kernel-server nfs-common portmap
Дальше в заметке для сервера будет использоваться IP 192.168.1.100 . Для того что бы за сервером всегда был закреплен один и тот же IP необходимо в DHCP-сервере (чаще всего роутер) указать раздачу конкретного IP конкретному MAC-адресу. Или поднять свой локальный DNS-сервер. Например или .
MAC-адрес можно узнать с помощью ifconfig (поле ether в Arch Linux ).
NFSv4 предполагает что есть корневая директория, внутри которой уже расположены файлы для раздачи. Например, /srv/nfs - корень, /srv/nfs/audio - директория для раздачи музыки. Если не следовать этому новому указанию в версии 4 , то можно получить ошибку при подключении клиентом:
Mount.nfs: access denied by server while mounting 192.168.1.100:/home/proft/torrents
Если все же хочется использовать на сервере подход без корневой-директории для NFS , то при монтировании клиентом надо явно указать версию 3
# для команды mount mount -o "vers=3" 192.168.1.100:/home/proft/torrents /home/proft/nfs/torrents # для fstab 192.168.1.100:/home/proft/torrents /home/proft/nfs/torrents nfs soft,nfsvers=3 0 0
Я буду использовать NFSv4 с root-директорией в /srv/nfs/ и монтированием вложенных директорий с помощью mount --bind .
Предположим, что мы хотим
- раздавать директорию ~/torrents с rw доступом для всех внутри локальной сети;
- раздавать директорию ~/photos с ro доступом для хоста с IP 192.168.1.101 ;
Для начала создадим корневую директорию и необходимые вложенные.
Sudo mkdir -p /srv/nfs/{torrents,photos}
Примонтируем существующие директории torrents, photos в /srv/nfs .
# sudo vim /etc/fstab /home/proft/torrents /srv/nfs/torrents none bind 0 0 /home/proft/photos /srv/nfs/photos none bind 0 0
Отредактируем /etc/exports , в котором описываются все директории для совместного доступа
# sudo vim /etc/exports # формат файла: directory allowed-hosts(options) /srv/nfs/torrents 192.168.1.1/24(rw,async) /srv/nfs/photos 192.168.1.101(ro,async)
Обратите внимание на отсутствие пробела между allowed-hosts и (options) . Наличие пробела вводит другую трактовку правил.
Доступные опции:
- ro (rw) - разрешить доступ только на чтение (чтение/запись);
- subtree_check (no_subtree_check) - в некоторых случаях приходится экспортировать не весь раздел, а лишь его часть. При этом сервер NFS должен выполнять дополнительную проверку обращений клиентов, чтобы убедиться в том, что они предпринимают попытку доступа лишь к файлам, находящимся в соответствующих подкаталогах. Такой контроль поддерева (subtree checks ) несколько замедляет взаимодействие с клиентами, но если отказаться от него, могут возникнуть проблемы с безопасностью системы. Отменить контроль поддерева можно с помощью опции no_subtree_check . Опция subtree_check , включающая такой контроль, предполагается по умолчанию. Контроль поддерева можно не выполнять в том случае, если экспортируемый каталог совпадает с разделом диска;
- sync (async) - указывает, что сервер должен отвечать на запросы только после записи на диск изменений, выполненных этими запросами. Опция async указывает серверу не ждать записи информации на диск, что повышает производительность, но понижает надежность, т.к. в случае обрыва соединения или отказа оборудования возможна потеря данных;
- noaccess - запрещает доступ к указанной директории. Может быть полезной, если перед этим был задан доступ всем пользователям сети к определенной директории, и теперь хотите ограничить доступ в поддиректории лишь некоторым пользователям;
- no_root_squash – по умолчанию пользователь root на клиентской машине не будет обладать теми же правами к директории на сервера. Эта опция снимает это ограничение;
- nohide - NFS автоматически не показывает нелокальные ресурсы (например, примонтированые с помощью mount --bind), эта опция включает отображение таких ресурсов;
- insecure - использование непривилегированных портов (> 1024);
Запускаем NFS-сервер
# под archlinux sudo systemctl start rpc-idmapd.service rpc-mountd.service # под ubuntu sudo /etc/init.d/nfs-kernel-server start
В дальнейшем при изменении конфигурационного файла достаточно его перечитать командой:
Sudo exportfs -rav
Команда rpcinfo -p | grep nfs позволяет проверить успешность запуска сервера.
Клиент под Linux
Установка
# под archlinux yaourt -S nfs-utils # под ubuntu sudo apt-get install portmap nfs-common
Создадим директории для монтирования сетевых ресурсов torrents и photos
Mkdir -p ~/nfs/{torrents,photos}
Для ручного монтирования выполним
Sudo mount -t nfs -o rw,soft 192.168.1.100:/srv/nfs/torrents /home/proft/nfs/torrents sudo mount -t nfs -o rw,soft 192.168.1.100:/srv/nfs/photos /home/proft/nfs/photos
Опция soft указывает тихо отменить попытки подключить шару после определенного количества времени (время задается опцией retrans ). Подробнее в man nfs .
Данный способ не очень удобен, так как каждый раз после перезагрузки придется выполнять эти команды. Сделаем монтирование автоматическим.
Для автоматического монтирования редактируем файл /etc/fstab
# sudo vim /etc/fstab 192.168.1.100:/srv/nfs/torrents /home/proft/net/torrents nfs rw,soft 0 0 192.168.1.100:/srv/nfs/photos /home/proft/net/photos nfs ro,soft 0 0
Но и у этого способа есть свои недостатки, например, если сервер не доступен то загрузка клиента может подвиснуть из-за попыток подключиться к NFS-серверу. Для исправления этого см. ниже про AutoFS .
AutoFS - автоматическое подключение сетевых ресурсов
Есть возможность монтировать удаленный ресурс с помощью AutoFS при первом обращении и автоматически отмонтировать при отсутствии активности.
AutoFS использует для настройки шаблоны, расположенные в /etc/autofs . Основной шаблон называется auto.master , он может указывать на один или несколько других шаблонов для конкретных типов носителей.
Установка
# под archlinux yaourt -S autofs # под ubuntu sudo apt-get install autofs
Существует несколько способов указать способы автомонтирования. Я использую такой: в /home/proft/nfs автоматически создается директория с именем NFS-сервера, в которой автоматически создаются доступные директории на сервере.
# sudo vim /etc/autofs/auto.master /home/proft/nfs /etc/autofs/auto.nfs --timeout=60
Дополнительный параметр timeout устанавливает количество секунд после которых устройство будет размонтировано. Параметр ghost указывает что сконфигурированные ресурсы будут отображаться всегда, а не только тогда, когда они доступны (эта опция включена по умолчанию в AutoFS 5 )
Опишем в /etc/autofs/auto.nfs NFS-сервер и root-директорию.
# sudo vim /etc/autofs/auto.nfs nfsserver 192.168.1.100:/srv/nfs
Теперь при первом обращении /home/proft/nfs/torrents произойдет автоматическое монтирование NFS-ресурса.
Перезапустим службу autofs:
# под archlinux sudo systemctl restart autofs # под ubuntu sudo /etc/init.d/autofs restart
Еще можно указать время ожидания доступности NFS-ресурса. Для этого необходимо изменить значения MOUNT_WAIT .
# под archlinux # sudo vim /etc/conf.d/autofs MOUNT_WAIT=5 # под ubuntu sudo /etc/default/autofs MOUNT_WAIT=5
Форсирование использования NFS v3
В некоторых случаях NFSv4 может работать медленно. Для исправления этого можно принудительно указать использовать третью версию.
Вот , а что дальше? Как посмотреть фильмы и прослушать музыкальные файлы, которые скачались? Неужели нужно записывать их на диски и переносить их таким образом на компьютер с GUI? Или придётся копировать их по медленному SFTP? Нет! На помощь приходит NFS! Нет, это не серия гоночных игр, а Network File System (Сетевая Файловая Система).
Network File System (NFS) - это сетевая файловая система, позволяющая пользователям обращаться к файлам и каталогам, расположенным на удалённых компьютерах, как если бы эти файлы и каталоги были локальными. Главным преимуществом такой системы является то, что отдельно взятые рабочие станции могут использовать меньше собственного дискового пространства, так как совместно используемые данные хранятся на отдельной машине и доступны для других машин в сети. NFS — это клиент-серверное приложение. То есть в системе пользователя должен быть установлен NFS-клиент, а на компьютерах, которые предоставляют свое дисковое пространство - NFS-сервер.
Установка и настройка NFS-сервера
(192.168.1.2)
1. Устанавливаем. Соединившись по SSH с компьютером сервером или же просто в его консоли вводим:
Sudo apt-get install nfs-kernel-server nfs-common portmap
Это установит NFS-сервер, а также необходимый пакет portmap.
2. Настраиваем. Для настройки списка дирректорий которые мы хотим открыть и списка кому мы хотим их открыть отредактируем файл /etc/exports :
Sudo nano /etc/exports /data 192.168.1.1/24(rw,no_root_squash,async)
В указанном выше примере мы открыли на сервере директорию /data и её поддиректории в совместное пользование всем компьютерам с IP: 192.168.1.1 - 192.168.1.255 с правами чтения и записи.
Ещё пример:
/home/serg/ 192.168.1.34(ro,async)
Этот пример делает доступной домашнюю директорию пользователя serg в режиме только чтение для компьютера с IP 192.168.1.34. Все остальные компьютеры сети к этой директории доступа иметь не будут.
Доступные опции:
- ro — права только на чтение. Можно и не указывать, так как она установлена по умолчанию;
- rw — дает клиентам право на запись;
- no_root_squash — по-умолчанию пользователь root на клиентской машине не будет иметь доступа к открытым директориям на сервере. Этой опцией мы снимаем это ограничение. В целях безопасности этого лучше не делать;
- noaccess — запрещает доступ к указанной директории. Может быть полезной, если перед этим вы задали доступ всем пользователям сети к определенной директории, и теперь хотите ограничить доступ в поддиректории лишь некоторым пользователям.
Теперь нужно перезапустить nfs-kernel-server:
Sudo /etc/init.d/nfs-kernel-server restart
Если после этого вы захотите поменять что-нибудь в файле /etc/exports , то для того, чтобы изменения вступили в силу, достаточно выполнить следующую команду:
Sudo exportfs -a
Всё. NFS-сервер установлен и настроен. Можно переходить к NFS клиенту.
Установка и настройка NFS-клиент
1. Установка. Выполняем в терминале компьютера, который будет подключаться следующее:
Sudo apt-get install portmap nfs-common
2. Настройка. Для начала создадим директорию в которую будет монтироваться удалённая папка:
Cd ~ mkdir data
Монтировать можно двумя способами — каждый раз вручную или прописав опции монтирования в файл /etc/fstab .
Способ 1. Монтирование вручную
Создаём на рабочем столе или в какой-либо другой папке текстовый файл:
Nano ~/Рабочий\ стол/nfs-server-connect
Пишем в него:
#! /bin/bash sudo mount -t nfs -o ro,soft,intr 192.168.1.2:/data ~/data
Делаем его исполняемым:
Chmod +x ~/Рабочий\ стол/nfs-server-connect
Теперь когда необходимо присоединиться к серверу я выполняю этот сценарий в терминале для того чтобы можно было ввести пароль для sudo.
Способ 2. Добавление в /etc/fstab
Открываем /etc/fstab:
Sudo nano /etc/fstab
И дописываем строчку в конце файла:
192.168.1.2:/data ~/data nfs rw,hard,intr 0 0
Внимание! Вместо 192.168.1.2:/data впишите IP или имя сервера и путь к директории совместного пользования. Опции монтирования можно изменить.
Опция hard жёстко привязывает дирректорию на клиенте к серверу и если сервер отвалится, то может зависнуть и ваш компьютер. Опция soft , как понятно из её названия, не такая категоричная.
После сохранения файла можно монтировать удалённую папку.
