nfs server что это
Установка
Для установки и сервера, и клиента необходимы одни и те же пакеты nfs-kernel-server и nfs-common
Настройка сервера
и добавляем в конец файла строки вида (строк может быть произвольное количество):
/data –путь к папке, для которой раздается доступ;
192.168.1.1 –IP-адрес, которому раздается доступ к папке(можно указать всю сеть, тогда запись примет вид 192.168.1.0/24)
(rw,no_root_squash,sync) –набор опций, опции могут быть:
rw –чтение запись(может принимать значение ro-только чтение);
no_root_squash –по умолчанию пользователь root на клиентской машине не будет иметь доступа к разделяемой директории сервера. Этой опцией мы снимаем это ограничение. В целях безопасности этого лучше не делать;
noaccess – запрещает доступ к указанной директории. Может быть полезной, если перед этим вы задали доступ всем пользователям сети к определенной директории, и теперь хотите ограничить доступ в поддиректории лишь некоторым пользователям.
Необходимо добавить описание опций.
all_squash– подразумевает, что все подключения будут выполнятся от анонимного пользователя
subtree_check (no_subtree_check)- в некоторых случаях приходится экспортировать не весь раздел, а лишь его часть. При этом сервер NFS должен выполнять дополнительную проверку обращений клиентов, чтобы убедиться в том, что они предпринимают попытку доступа лишь к файлам, находящимся в соответствующих подкаталогах. Такой контроль поддерева (subtree checks) несколько замедляет взаимодействие с клиентами, но если отказаться от него, могут возникнуть проблемы с безопасностью системы. Отменить контроль поддерева можно с помощью опции no_subtree_check. Опция subtree_check, включающая такой контроль, предполагается по умолчанию. Контроль поддерева можно не выполнять в том случае, если экспортируемый каталог совпадает с разделом диска;
anonuid=1000– привязывает анонимного пользователя к «местному» пользователю;
anongid=1000– привязывает анонимного пользователя к группе «местного» пользователя.
В последствии после внесения изменений в файл /etc/exports не обязательно перезапускать сервер, достаточно выполнить:
Настройка клиента
Для монтирования сетевой папки необходимо создать папку на локальном компьютере:
Монтирование вручную
Для монтирования папки вручную необходимо выполнить в терминале команду:
Монтирование с записью в fstab
Для большего удобства можно добавить запись с сетевой папкой в fstab. Целесообразно создать точку монтирования сетевой папки в /media, потому что каталоги, созданные там, будут отображаться в Nautilus в левой колонке, монтировать их можно будет одним кликом.
В файл /etc/fstab добавляем подобную запись:
опция «noauto» запрещает автоматическое монтирование сетевого диска при старте системы.
Проблемы
Использование на ноутбуке
При монтировании удаленных папок NFS посредством fstab, в ситуации, когда сеть с сервером будет не доступна, ноутбук невозможно выключить или отправить в спящий режим. Для использования удаленных папок NFS на ноутбуке лучше воспользоваться монтированием при помощи autofs
Монтирование с помощью autofs
Данный способ монтирования позволяет автоматически монтировать папку после обращения к ней в наутилусе (к примеру, через закладки) или в терминале:
и автоматически отмонтировать при отсутствии активности.
Установка
Для реализации данного способа необходимо доустановить пакет autofs :
Настройка
Для настройки autofs в файле /etc/auto.master необходимо добавить строку
Здесь –timeout=60 указывает отмонтировать раздел при отсутствии активности на нём более чем 60 секунд. Создаем в корне файловой системы папку /nfs :
В файле /etc/auto.nfs добавляем строку
-rw,soft,intr,rsize=8192,wsize=8192 – параметры монтирования;
server – папка, которая будет создаваться в каталоге /nfs при монтировании удаленных папок;
192.168.1.2:/path_to_share– IP-адрес и общая папка сервера.
Перезапускаем службу autofs :
Проблемы
Недоступность удаленного сервера
Если сеть с сервером NFS недоступна, возможна большая задержка (по умолчанию 3 минуты) при открытии nautilus, в закладках которого находится примонтированная удаленная папка NFS.
Для решения этой проблемы необходимо уменьшить время ожидания монтирования autofs, для этого в файле /etc/default/autofs необходимо раскомментировать или добавить следующие строки:
#время ожидания ответа от mount
#время ожидания при неудачной попытке монтирования
После этого autofs будет пытаться примонтировать удаленную папку только 10 секунд.
Использование
Проблемы
Проблемы с гибернацией или выключением
После настройки автомонтирования сетевых папок NFS могут обнаружится некотрые проблемы с выключением или гибернацией системы. Чаще всего это проявляется как прерывающаяся гибернация (компьютер начинает уходить в гибернацию, гаснет экран, после чего экран опять загорается и работа продолжается, так же в этих случаях возможны проблемы с выключением и перезагрузкой системы. При последующих попытках отправить компьютер в гибернацию на черном экране вверрху можно наблюдать строку типа:
Для диагностирования смотрим лог dmesg, возможный вывод:
Пакет, являющийся причиной зависания указан в начале строки, следующей после сообщения об ошибке.
Причина №1: пакет NFS
Причиной данной проблемы является скрипт прерывания работы NetworkManager, необходимо запретить его выполнение переименовав его:
Причина №2: пакет updatedb.mloc
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
NFS (Network File System)
| Уровень (по модели OSI): | Прикладной |
|---|---|
| Семейство: | стек протоколов TCP/IP |
| Порт/ID: | 67, 68/UDP |
| Назначение протокола: | Получение сетевой конфигурации |
| Спецификация: | RFC 2131 |
| Основные реализации (серверы): | dhcpd, ISC DHCP Server, Infoblox |
| Вступил в силу с: | 1990 |
NFS (англ. Network File System ) — протокол сетевого доступа к файловым системам, первоначально разработан Sun Microsystems в 1984 году. Основан на протоколе вызова удалённых процедур (ONC RPC). Позволяет подключать (монтировать) удалённые файловые системы через сеть. [1]
NFS абстрагирован от типов файловых систем как сервера, так и клиента, существует множество реализаций NFS-серверов и клиентов для различных операционных систем и аппаратных архитектур. Наиболее зрелая версия NFS — v.4, поддерживающая различные средства аутентификации (в частности, Kerberos и LIPKEY с использованием протокола RPCSEC GSS) и списков контроля доступа (как POSIX, так и Windows-типов).
NFS предоставляет клиентам прозрачный доступ к файлам и файловой системе сервера. В отличие от FTP, протокол NFS осуществляет доступ только к тем частям файла, к которым обратился процесс, и основное достоинство его в том, что он делает этот доступ прозрачным. Это означает, что любое приложение клиента, которое может работать с локальным файлом, с таким же успехом может работать и с NFS файлом, без каких либо модификаций самой программы.
NFS-клиенты получают доступ к файлам на NFS-сервере путём отправки RPC-запросов на сервер. Это может быть реализовано с использованием обычных пользовательских процессов — а именно, NFS-клиент может быть пользовательским процессом, который осуществляет конкретные RPC-вызовы на сервер, который так же может быть пользовательским процессом.
Важной частью последней версии стандарта NFS (v4.1) стала спецификация pNFS, нацеленная на обеспечение распараллеленной реализации общего доступа к файлам, увеличивающая скорость передачи данных пропорционально размерам и степени параллелизма системы.
Содержание
История
Протокол NFS имеет в своей истории 4 версии.
Первая версия применялась только для внутреннего использования в Sun в экспериментальных целях. Версия 2 выпущена в марте 1989 года, первоначально полностью работала по протоколу UDP. Разработчики решили не хранить данных о внутреннем состоянии внутри протокола, как пример, блокировка, реализованная вне базового протокола. Люди, вовлечённые в создание NFS версии 2 — Расти Сэндберг (Rusty Sandberg,) Боб Лайон (Bob Lyon), Билл Джой и Стив Клейман (Steve Kleiman).
NFSv3 вышла в июне 1995 года, в ней добавлена поддержка дескрипторов файлов переменного размера до 64 байт (в версии 2 — массив фиксированного размера 32 байта), снято ограничение на 8192 байта в RPC-вызовах чтения и записи (тем самым, размер передаваемого блока в вызовах ограничен только пределом для UDP-датаграммы — 65535 байт), реализована поддержка файлов больших размеров, поддержаны асинхронные вызовы операций записи, к процедурам READ и WRITE добавлены вызовы ACCESS (проверка прав доступа к файлу), MKNOD (создание специального файла Unix), READDIRPLUS (возвращает имена файлов в директории вместе с их атрибутами), FSINFO (возвращает статистическую информацию о файловой системе), FSSTAT (возвращает динамическую информацию о файловой системе), PATHCONF (возвращает POSIX.1-информацию о файле) и COMMIT (передает ранее сделанные асинхронные записи на постоянное хранение). На момент введения версии 3 отмечен рост популярности в среде разработчиков протокола TCP. Некоторые независимые разработчики самостоятельно добавили поддержку протокола TCP для NFS версии 2 в качестве транспортного, Sun Microsystems добавили поддержку TCP в NFS в одном из дополнений к версии 3. С поддержкой TCP повысились практическая осуществимость использования NFS в глобальных сетях.
NFSv4 выпущена в декабре 2000 года под влиянием AFS и CIFS, в неё включены улучшения производительности и безопасности. Версия 4 стала первой версией, разработанной совместно с Internet Engineering Task Force (IETF). NFS версии v4.1 была одобрена IESG в январе 2010 года (новая спецификация, объёмом 612 страниц, стала известна как самый длинный документ, одобренный IETF). Важным нововведением версии 4.1 является спецификация pNFS — Parallel NFS, механизма параллельного доступа NFS-клиента к данным множества распределенных NFS-серверов. Наличие такого механизма в стандарте сетевой файловой системы поможет строить распределённые облачные хранилища и информационные системы.
Цели разработки
Изначальными требованиями при разработке NFS были:
Принцип работы NFS
NFS строится по крайней мере из двух основных частей: сервера и одного или большего количества клиентов. Клиент обращается к данным, находящимся на сервере, в режиме удалённого доступа. Для того, чтобы это нормально функционировало, нужно настроить и запустить несколько процессов. Реализация NFS состоит из нескольких компонентов. Некоторые из них локализованы либо на сервере, либо на клиенте, а некоторые используются и на обеих сторонах соединения. Некоторые компоненты не требуются для обеспечения основных функциональных возможностей, но составляют часть расширенного интерфейса NFS.
Протокол NFS определяет набор запросов (операций), которые могут быть направлены клиентом к серверу, а также набор аргументов и возвращаемые значения для каждого из этих запросов. Версия 1 этого протокола существовала только в недрах Sun Microsystems и никогда не была выпущена. Все реализации NFS (в том числе NFSv3) поддерживают версию 2 NFS (NFSv2), которая впервые была выпущена в 1985 году в SunOS 2.0. Версия 3 протокола была опубликована в 1993 году и реализована некоторыми фирмами-поставщиками.
Протокол удаленного вызова процедур (RPC) определяет формат всех взаимодействий между клиентом и сервером. Каждый запрос NFS посылается как пакет RPC. На сервере работают следующие даемоны [2] :
Клиент может запустить также даемон, называемый nfsiod. nfsiod обслуживает запросы, поступающие от сервера от сервера NFS. Он необязателен, увеличивает производительность, однако для нормальной и правильной работы не требуется. [3] В NFSv4 при использовании Kerberos дополнительно запускаются демоны:
Даемоны старых версий (NFS v.3 и ниже):
Кроме указанных выше пакетов, для корректной работы NFSv2 и v3 требуется дополнительный пакет portmap (в более новых дистрибутивах заменен на переименован в rpcbind). Sun RPC — это сервер, который преобразует номера программ RPC (Remote Procedure Call) в номера портов TCP/UDP.
portmap оперирует несколькими сущностями:
Даемон portmap запускается скриптом /etc/init.d/portmap до старта NFS-сервисов.
Работа сервера RPC (Remote Procedure Call) заключается в обработке RPC-вызовов (т.н. RPC-процедур) от локальных и удаленных процессов. Используя RPC-вызовы, сервисы регистрируют или удаляют себя в/из преобразователя портов ( portmap, portmapper, он же, в новых версиях, rpcbind), а клиенты с помощью RPC-вызовов направляя запросы к portmapper получают необходимую информацию.
Работу RPC-сервера можно представить следующими шагами:
NFS сервер (точнее даемон rpc.nfsd) получает запросы от клиента в виде UDP датаграмм на порт 2049. Несмотря на то, что NFS работает с преобразователем портов, что позволяет серверу использовать динамически назначаемые порты, UDP порт 2049 жестко закреплен за NFS в большинстве реализаций.
Описание процесса обращения к файлу, расположенному на сервере NFS:
Настройка сервера NFS
Настройка сервера в целом заключается в задании локальных каталогов, разрешенных для монтирования удаленными системами в файле /etc/exports. Это действие называется экспорт иерархии каталогов. Основными источниками информации об экспортированных каталогах служат следующие файлы:
В файле exports используются следующие общие опции: [4]
Управление сервером NFS осуществляется с помощью следующих утилит:
Утилита nfsstat позволяет посмотреть статистику RPC и NFS серверов.
showmount
Утилита showmount запрашивает демон rpc.mountd на удалённом хосте о смонтированных файловых системах. По умолчанию выдаётся отсортированный список клиентов. Команды:
При запуске showmount без аргументов, на консоль будет выведена информация о системах, которым разрешено монтировать локальные каталоги.
exportfs
Монтирование файловой системы Network Files System командой mount
Пример команды mount для монтирования файловой системы NFS в Debian:
Первая команда монтирует экспортированный каталог /archiv-small на сервере archiv в локальную точку монтирования /archivs/archiv-small с опциями по умолчанию (то есть для чтения и записи). Вторая команда монтирует экспортированный каталог /archiv-big на сервере archiv в локальный каталог /archivs/archiv-big с опцией только для чтения (ro). Команда mount без параметров наглядно отображает нам результат монтирования. Кроме опции только чтения (ro), возможно задать другие основные опции при монтировании NFS [5] :
Кэш атрибутов периодически обновляется в соответствии с заданными параметрами:
Опции обработки ошибок NFS
Следующие опции управляют действиями NFS при отсутствии ответа от сервера или в случае возникновения ошибок ввода/вывода:
Повышение производительности NFS
На производительность NFS могут влиять несколько параметров, особенно при работе через медленные соединения. При работе с медленными и высоконагруженными соединениями, желательно использовать параметр hard, чтобы таймауты не привели к прекращению работы программ. Но необходимо осознавать, что если смонтировать файловую систему через NFS с параметром hard через fstab, а удаленный хост окажется недоступен, то при загрузке системы произойдет зависание.
Так же, не стоит упускать из внимания и настройки тайм-аутов. NFS ожидает ответа на пересылку данных в течении промежутка времени, указанного в опции timeo, если ответ за это время не получен, то выполняется повторная пересылка. На загруженных и медленных соединениях это время может быть меньше времени реакции сервера и способности каналов связи, в результате чего могут быть излишние повторные пересылки, замедляющие работу.По умолчанию, timeo равно 0,7 сек (700 миллисекунд). после обнаружения факта обрыва связи в течении 700 мс сервер совершит повторную пересылку и удвоит время ожидания до 1,4 сек., увеличение timeo будет продолжаться до максимального значения в 60 сек.
Сетевая файловая служба
Система NFS предоставляет пользователям удобное средство доступа к удаленным файловым системам.
Протокол сетевой файловой службы (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 для обмена информацией использует вызовы удаленных процедур (Remote Procedure Calls, RPC). Обычно клиент устанавливает соединение с заранее известным портом и затем, в соответствии с особенностями протокола, посылает запрос на выполнение определенного действия. В случае вызова удаленных процедур клиент создает вызов процедуры и затем отправляет его на исполнение серверу. Подробное описание NFS будет представлено ниже.
В качестве примера предположим, что некий клиент смонтировал каталог usr2 в локальной корневой файловой системе:
Если клиентскому приложению необходимы ресурсы этого каталога, оно просто посылает запрос операционной системе на него и на имя файла, а та предоставляет доступ через клиента NFS. Для примера рассмотрим простую команду UNIX cd, которая «ничего не знает» о сетевых протоколах. Команда
разместит рабочий каталог на удаленной файловой системе, «даже не догадываясь» (пользователю тоже нет в этом необходимости), что файловая система является удаленной.
Получив запрос, сервер NFS проверит наличие у данного пользователя права на выполнение запрашиваемого действия и в случае положительного ответа осуществит его.
ПОЗНАКОМИМСЯ ПОБЛИЖЕ
С точки зрения клиента, процесс локального монтирования удаленной файловой системы средствами NFS состоит из нескольких шагов. Как уже упоминалось, клиент NFS подаст вызов удаленной процедуры для выполнения ее на сервере. Заметим, что в UNIX клиент представляет собой одну программу (команда mount), в то время как сервер на самом деле реализован в виде нескольких программ со следующим минимальным набором: служба преобразования портов (port mapper), демон монтирования (mount daemon) и сервер NFS.
Вначале клиентская команда mount взаимодействует со службой преобразования портов сервера, ожидающей запросы через порт 111. Большинство реализаций клиентской команды mount поддерживает несколько версий NFS, что повышает вероятность нахождения общей для клиента и сервера версии протокола. Поиск ведется, начиная с самой старшей версии, поэтому, когда общая будет найдена, она автоматически станет и самой новой версией из поддерживаемых клиентом и сервером.
(Излагаемый материал ориентирован на третью версию NFS, поскольку она наиболее распространена на данный момент. Четвертая версия большинством реализаций пока не поддерживается.)
 |
| Таблица 1. Удаленные процедуры для работы с файловой системой. |
Служба преобразования портов сервера откликается на запросы в соответствии с поддерживаемым протоколом и портом, на котором работает демон монтирования. Клиентская программа mount вначале устанавливает соединение с демоном монтирования сервера, а затем передает ему с помощью RPC команду mount. Если данная процедура выполнена успешно, то клиентское приложение соединяется с сервером NFS (порт 2049) и, используя одну из 20 удаленных процедур, которые определены в RFC 1813 и приводятся нами в Таблице 1, получает доступ к удаленной файловой системе.
Смысл большинства команд интуитивно понятен и не вызывает каких-либо затруднений у системных администраторов. Приведенный ниже листинг, полученный с помощью tcdump, иллюстрирует команду чтения, создаваемую командой UNIX cat для прочтения файла с именем test-file:
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 и Solaris 2.6.
NFS В СТИЛЕ «ПИНГВИН»
Относящийся к Linux излагаемый материал основывается на системе Red Hat 6.2 с ядром версии 2.4.9, которая поставляется с пакетом nfs-utils версии 0.1.6. Существуют и более новые версии: на момент написания этой статьи самое последнее обновление пакета nfs-utils имело номер 0.3.1. Его можно загрузить по адресу: http://sourceforge.net/project/shownotes. php?group_id=14&release_id=24211.
Пакет 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 будет соответствовать следующая запись:
Здесь нам необходимо сообщить системе, какие каталоги мы собираемся сделать доступными с помощью демона монтирования rpc.mountd:
При запуске команда exportfs выводит предупреждение о том, что /etc/ exports не ограничивает доступ к отдельному узлу, и создает соответствующую запись в /var/lib/nfs/etab из /etc/exports, сообщающую, какие ресурсы можно просмотреть с помощью cat:
Другие параметры, перечисленные в виде списка в etab, включают значения по умолчанию, используемые NFS. Детали будут описаны ниже. Чтобы предоставить доступ к каталогу /home, необходимо запустить соответствующие службы NFS:
В любой момент после запуска демона монтирования (rpc.mountd) cправиться об отдельных файлах, доступных для вывода, можно, просмотрев содержимое файла /proc/fs/nfs/exports:
Привередливым пользователям может показаться неудобным, что в 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 выполнена успешно, тогда команда mount без параметров выведет следующее:
Давайте проанализируем вывод tcpdump, полученный на узле Lefty, после того, как пользователь ввел команду ls /tmp/tmp2 на узле Sunny:
Мы видим, что узел Sunny запрашивает для ls описатель файла (fh), на что узел Lefty в ответ посылает OK и возвращает структуру каталога. Затем Sunny проверяет разрешение на право доступа к содержимому каталога (132 access fh) и получает ответ с разрешением от Lefty. После этого узел Sunny, используя процедуру readdirplus, считывает полное содержимое каталога. Вызовы удаленных процедур описаны в документе RFC 1813 и приведены нами в начале данной статьи.
Хотя последовательность команд для доступа к удаленным файловым системам очень проста, ряд обстоятельств может привести к некорректному монтированию системы. Перед монтированием каталога точка монтирования должна уже существовать, в противном случае ее необходимо создать с помощью команды mkdir. Обычно единственной причиной ошибок на клиентской стороне является отсутствие локального каталога для монтирования. Большинство же проблем, связанных с NFS, обязано своим происхождением несоответствию между клиентом и сервером или некорректной конфигурации сервера.
Другое полезное средство — команда nfsstat. С ее помощью можно узнать, обращаются ли в действительности клиенты к экспортируемой файловой системе, а также вывести статистическую информацию в соответствии с версией протокола.
Наконец, еще одним достаточно полезным инструментом определения причин сбоев системы является tcpdump:
Вышеприведенный листинг, полученный после выполнения инструкции 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 и экспортируются все файловые системы. Для запуска этих процессов вручную введите команду:
Для запуска демона монтирования и сервера NFS введите:
Начиная с версии 2.6 в Solaris для указания экспортируемых файловых систем больше не используется файл экспорта. Теперь файлы экспортируются с помощью команды share. Предположим, мы хотим позволить удаленным узлам смонтировать /export/home. Введем для этого следующую команду:
После выполнения команды share список экспортируемых файловых систем можно просмотреть с помощью той же команды без параметров:
Статус экспортирования для файловой системы отменяет команда unshare:
В Solaris информация, касающаяся NFS, хранится в каталоге /etc/dfs. Данные об экспортируемых файловых системах находятся в /etc/dfs/sharetab. Команда share без параметров пользуется именно этими данными.
В /etc/dfs/dfstab содержится список команд share, запускаемых при начальной загрузке ОС. Сделать /export/home автоматически экспортируемой можно, добавив вышеупомянутую команду
Еще одна полезная команда, используемая при экспортировании файловых систем, — shareall. Введенная без параметров, она запускает все команды share, указанные в /etc/dfs/dfstab. Команда unshareall отменяет статус экспортирования для всех экспортируемых файловых систем.
LINUX КАК КЛИЕНТ NFS
Применение Linux в качестве клиента NFS не было рассмотрено в посвященном ему разделе. Для полноты излагаемого материала опишем процедуру монтирования экспортируемой файловой системы Solaris.
После этого получить информацию о состоянии файловой системы можно с помощью команды mount:
СТАРТ ДАН
Сетевая файловая система NFS с успехом используется при работе на бездисковых рабочих станциях, для программных приложений или просто для хранения данных. Какова бы ни была область применения, данная статья, познакомив читателя с основами NFS, может стать той отправной точкой, с которой для него начнется самостоятельное изучение этого направления. Удачи!
Рональд Маккарти — старший системный инженер по телекоммуникационным системам в компании Sonus Networks, соавтор издания New Rider?s Linux Routing (http://www.linuxroutingbook.com). С ним можно связаться по адресу: ronald.mccarty@gte.net.
Мероприятия по обеспечению безопасности
БЕЗОПАСНОСТЬ В 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, который я использовал при написании данной статьи, содержал следующие строки:
При этом разрешается определенный вид доступа к узлам до того, как будет предоставлен доступ на уровне приложений. В Linux доступом на уровне приложений управляет файл /etc/exports. Он состоит из записей в следующем формате:
«Экспортируемый каталог» — это каталог, обработка запроса к которому разрешена демону nfsd. «Узел|сеть» — это узел или сеть, имеющие доступ к экспортируемой файловой системе, а «опции» определяют те ограничения, какие демон nfsd налагает на использование данного разделяемого ресурса, — доступ только для чтения или преобразование идентификатора пользователя (user id mapping).
В следующем примере всему домену mcwrite.net предоставлен доступ в режиме только для чтения к /home/mcwrite.net:
Другие примеры можно найти на справочной странице exports man.
БЕЗОПАСНОСТЬ NFS В SOLARIS
Справочная страница man для share_nfs подробно описывает предоставление доступа с помощью управляющих списков в Solaris.
Ресурсы Internet
В NFS и RPC не обошлось без «дыр». Вообще говоря, NFS не следует использовать при работе в Internet. Нельзя делать «дыры» в брандмауэрах, предоставляя какой бы то ни было доступ посредством NFS. Необходимо тщательно следить за всеми появляющимися заплатами для RPC и NFS, в чем могут помочь многочисленные источники информации по вопросам безопасности. Два наиболее популярных источника — Bugtraq и CERT:
Первый можно регулярно просматривать в поисках необходимой информации или воспользоваться подпиской на периодическую рассылку новостей. Второй предоставляет, может быть, не столь оперативную, по сравнению с другими, информацию, зато в достаточно полном объеме и без оттенка сенсационности, свойственной некоторым сайтам, посвященным информационной безопасности.
Поделитесь материалом с коллегами и друзьями