 |
|
|
|
NFS: из прошлого в будущее
NFS: из прошлого в будущее Сетевая файловая система разработана уже давно, но её развитие продолжается, и для ряда задач способ предоставления файлов через сеть остается одним из самых эффективных. NFS (Network File System) была разработана компанией Sun Microsystems в начале 80-х годов прошлого века для решения задачи совместного сетевого доступа к файлам в системах UNIX. Благодаря открытости спецификации протокола и сравнительной простоте реализации NFS стала использоваться на многих UNIX-системах. Первоначальные версии NFS, получившие широкое распространение (известные как NFSv2 и NFSv3), «курировались» компанией Sun (см. RFC 1094, [1] и RFC 1813, [2]). Разработка нынешней спецификации (NFSv4, см. RFC 3530, [3]) отдана «на откуп» широкой общественности. Основные принципы протокола Поскольку 1-я версия протокола так и не была «материализована», то начнём наш краткий экскурс с версии 2. Описывающий её документ датирован мартом 1989 года (первые реализации появились ещё раньше). Уже в нём указано, что одним из центральных принципов, положенных в основу протокола, является его способность работать на различных платформах, обеспечиваемая использованием протокола удалённого вызова процедур – RPC (Remote Procedure Calls). Собственно говоря, NFS как раз и определяется как набор RPC‑процедур. RPC в свою очередь работает поверх XDR (eXternal Data Representation), обеспечивающем представление различных типов данных, передаваемых по сети. RPC предоставляет возможность выполнять определённые процедуры на хосте (RPC-сервере) по запросу удалённых пользователей (RPC-клиентов). То есть клиент формирует запрос на вызов той или иной процедуры и передаёт её RPC-серверу. Сервер обеспечивает локальное выполнение запроса и возвращает результат клиенту. Таким образом, удалённое приложение не должно заботиться о поддержке сетевого взаимодействия – для него работа с удалённым ресурсом остаётся полностью прозрачной. Для определения номеров портов, используемых RPC-клиентом и сервером в процессе работы, используется сервис трансляции портов (port mapper). Задача транслятора портов – зарегистрировать приложение, предоставляющее услуги RPC, и в дальнейшем сообщать клиентам, к каким портам следует подключаться для выполнения той или иной процедуры. Таким образом, NFS использует клиент-серверную модель взаимодействия. Принято говорить, что сервер экспортирует локальные файловые системы, а клиент импортирует их. В отличие от ряда других сетевых протоколов в NFS не реализованы средства «анонсирования» присутствия серверов в сети, так что клиент должен знать адрес нужного ему сервера. Благодаря этому использование NFS не ограничивается пределами локальной сети (правильнее, наверное, говорить «широковещательного домена»), и она может работать, в том числе, и в сети Интернет. Хотя сразу нужно отметить, что дизайн NFS предполагает работу через надёжное широкополосное соединение, поэтому работа в «глобальных» сетях будет не слишком эффективной. Важной особенностью NFS версий 2 и 3 является то, что этот протокол не использует состояния (имеется в виду состояние самого NFS-соединения, а не транспортного протокола). NFS-сервер не занимается отслеживанием клиентов: каждое обращение клиента должно нести в себе всю информацию, необходимую для выполнения запроса. Например, с каждым запросом на чтение фрагмента файла клиент должен сообщить свою аутентификационную информацию, дескриптор файла (file handler), начальную позицию указателя и количество байт, которые должны быть прочитаны. Сервер, получив запрос, проверяет права клиента на чтение, открывает указанный файл, считывает нужный фрагмент, закрывает файл и возвращает результат клиенту. На первый взгляд необходимость открывать и закрывать файл при каждом запросе выглядит не слишком рациональным решением. Однако сервер, как правило, эффективно кэширует единожды открытый файл, так что с высокой долей вероятности последующие запросы на чтение будут удовлетворяться из кэша, не требуя дополнительных дисковых операций. Кроме того, отсутствие состояния позволяет NFS-клиенту и серверу не беспокоиться о работоспособности друг друга – например, клиент вполне может ненадолго «пропасть» (скажем, из-за временных проблем с соединением), а затем продолжить свою работу; NFS-сервер этого даже не заметит. Аналогично, в случае сбоя на сервере после восстановления его работоспособности клиенты могут продолжить работу как ни в чём не бывало, без необходимости повторно устанавливать соединения, «откатывать» незавершённые транзакции и т. д. Конечно, здесь есть свои нюансы, которых мы коснёмся чуть позже. NFS предполагает, что файловая система имеет стандартную древовидную структуру. Причём NFS за одну операцию выполняет поиск лишь одного элемента в текущем каталоге. Объясняется такая «расточительность» желанием обеспечить независимость от символа, используемого в качестве разделителя каталогов, который может различаться в разных операционных системах. Впрочем, быстродействия такой подход явно не добавляет. Версия 2 предполагает, что все RPC-процедуры будут выполняться синхронно, т.е. клиентское приложение обязано дождаться подтверждения выполнения операции, прежде чем продолжит свою работу. А подтверждение в свою очередь может быть выдано лишь после действительного завершения запроса. (Анонсированная в v2 «для реализации в последующих ревизиях» процедура WRITECACHE в версии 3 была исключена, но возможность асинхронной записи была добавлена в процедуру WRITE). В третью версию протокола, датированную июнем 1995 года, были внесены некоторые изменения, в том числе:
Благодаря асинхронной записи клиент теперь может отправить на сервер сразу несколько последовательных запросов WRITE, не дожидаясь подтверждения каждого из них, а затем зафиксировать все изменения одним запросом COMMIT. Правда, это вынуждает клиента сохранять у себя все записываемые блоки, пока не последует подтверждение успешной фиксации, но в целом это новшество положительно сказывается на производительности. Новшества NFSv4 Четвёртая версия NFS кардинально отличается от предшественниц. Во-первых, здесь уже появилось отслеживание состояния клиента – так называемые «владения» (leases), что предоставляет гораздо больше возможностей реализации блокировок и более эффективного кэширования. Благодаря использованию так называемых компаундных операций (когда в одном запросе могут передаваться несколько RPC-вызовов) быстродействие должно значительно возрасти. Кроме того, в новой версии особое внимание уделено вопросам безопасности:
В 4-й версии все вспомогательные задачи (монтирование, блокировка и т. д.), в предыдущих версиях решаемые отдельными программами, теперь возлагаются на основной процесс, что положительно сказывается на эффективности использования firewall. Теперь требуется держать открытым один порт – 2049, да и необходимость в трансляторе портов тоже большей частью отпадает. Реализация во FreeBSD Во FreeBSD 6.2 поддерживаются реализации NFSv2 и v3. 4-я версия реализована лишь в клиенте и то частично (отсутствует поддержка RPCSEC_GSS, делегирование и многое другое). Поддержка NFS, как правило, «зашита» непосредственно в ядро операционной системы, благодаря чему пользовательские приложения могут работать с удалёнными файловыми системами совершенно таким же образом, как и с локальными – конкретная реализация «скрыта» за уровнем vnode и не требует от программ прикладного уровня каких-либо знаний об NFS. Первоначальные реализации работали преимущественно поверх протокола UDP, однако в NFSv3 поддержка TCP также получила широкое распространение, что дополнительно расширило возможности работы NFS в глобальных сетях. Однако не следует забывать, что спецификация не предусматривает шифрования или иной защиты передаваемых данных, поэтому передача файлов с использованием NFS по общедоступным сетям должна ограничиваться информацией, «утечка» которой не критична. Работа клиента Поскольку поддержка NFS по умолчанию включена в ядро системы (см. файл GENERIC, опции NFS*; впрочем, NFS неплохо работает и в виде модуля), то её использование возможно без каких-либо дополнительных – достаточно указать в /etc/rc.conf переменную «nfs_client_enable=YES», чтобы при загрузке системы были установлены некоторые sysctl-переменные, связанные с NFS. И можно монтировать удалённую файловую систему, предоставляемую сервером: mount_nfs 10.0.0.254:/var/downloads /mnt Здесь 10.0.0.254 – адрес NFS-сервера, /var/downloads – имя экспортируемого каталога (подробнее о сервере будет сказано чуть ниже), /mnt – точка монтирования в клиентской системе. Дополнительно могут быть указаны различные опции, такие как жёсткое указание используемой версии NFS и/или транспортного протокола (см. man mount_nfs). Особенно полезна опция -i, обеспечивающая возможность прервать в случае необходимости операцию с удалённой ФС с помощью <Ctrl+C> (по умолчанию операция будет выполняться «до победного конца», что в случае UDP и достаточно «щедрых» значениях тайм-аутов может вылиться в настоящее мучение при аварии на сервере или канале связи). В настоящее время команда mount_nfs работает только с версиями NFS 2 и 3, для NFSv4 следует использовать утилиту mount_nfs4. В 7.0-CURRENT (начиная с февральского снапшота) функциональность этих утилит объединена в mount_nfs. Некогда для повышения быстродействия (даже ценой потери надёжности) было принято запускать несколько демонов nfsiod. Это позволяло поднять скорость работы за счёт использования упреждающего чтения и отложенной записи. То есть клиентское приложение в этом случае фактически взаимодействует не с удалённым сервером, а с локальным демоном nfsiod, который берёт на себя обмен данными с сервером, выполняемый в фоновом режиме, что избавляет приложение от необходимости ждать завершения каждой операции. Во FreeBSD 6.2 и 7.0 по умолчанию sysctl-переменная vfs.nfs.iodmin установлена в 0, то есть процессы nfsiod не запускаются. При необходимости это можно изменить:
Для размонтирования удалённого ресурса используется обычная команда umount. Организация сервера Для организации NFS-сервера должны быть запущены как минимум три демона: mountd, nfsd и rpcbind. Рассмотрим, за что они отвечают. Первый отвечает за монтирование файловой системы при поступлении соответствующего запроса. Второй выполняет работу по протоколу NFS – обрабатывает конкретные запросы на чтение/запись, создание/удаление файлов и т. д. Причём о числе этих демонов следует позаботиться заранее (по умолчанию во FreeBSD запускается четыре демона nfsd). Демон rpcbind отвечает за предоставление клиентам информации о том, к какому порту следует подключаться. Ранее для этого использовался демон portmap. Хотя обычно процессы nfsd работают на стандартном порту – 2049 (TCP и/или UDP), и, казалось бы, уточнять это не требуется, но вот процессы mountd могут запускаться на произвольных номерах портов, так что rpcbind для работы необходим. Для автоматической загрузки этих демонов можно в /etc/rc.conf указать следующие строки: rpcbind_enable=YES nfs_server_enable=YES Демон mountd, определяя, какие ресурсы нужно предоставлять для доступа по сети, руководствуется файлом /etc/exports. Для успешного старта демона этот файл, как минимум, должен существовать. Содержимое его простое – в каждой строке указывается предоставляемый в общий доступ каталог с дополнительными опциями. В общем виде формат строки можно определить следующим образом: <ресурсы> <опции> <клиенты> Здесь <ресурсы> – путь к экспортируемым каталогам; <опции> – дополнительные параметры монтирования, такие как предоставление ресурса только для чтения (-ro); <клиенты> – имена или IP-адреса клиентских машин, которым позволено работать с ресурсом (поддерживаются также сетевые группы – см. man netgroup). Несколько примеров: $ cat /etc/exports # Доступ к домашнему каталогу и всем подкаталогам с двух указанных машин /usr/home/serg -alldirs 10.0.0.203 10.0.0.254 # Доступ на чтение со всей подсети 10.0.0.0/24 /var/downloads -ro -network 10.0.0.0 -mask 255.255.255.0 # Доступ с указанного хоста, причём пользователь с идентификатором 0 получит права пользователя admin /usr/src -maproot=admin admin.domain.ru Здесь есть одна особенность – для ресурсов, располагающихся на одном разделе, может быть только одна строка, описывающая доступ для конкретного «клиента». То есть если вы хотите предоставить доступ с машины admin к ресурсам /usr/ports и /usr/src (при условии, что они оба размещены на разделе /usr), то делать это нужно в одной строке: /usr/src /usr/ports admin Не забывайте после внесения изменений в /etc/exports перезапускать демон mountd:
Для использования блокировок файлов при совместном доступе требуется запуск ещё двух демонов – rpc.lockd и rpc.statd (второй демон обеспечивает предоставление информации о состоянии клиентов, необходимой для корректной работы блокировок, и, в частности, отвечает за снятие устаревших блокировок). Для их автоматического запуска в /etc/rc.conf следует указать строки: rpc_lockd_enable="YES" rpc_statd_enable="YES" Для правильной работы эти демоны должны запускаться как на клиенте, так и на сервере. Как проверить, что запущено Чтобы убедиться, что всё запущено должным образом, полезны две утилиты: showmount и rpcinfo. Первая, запущенная без параметров, покажет, для каких хостов в данный момент выполнено монтирование NFS-ресурсов:
С ключом -a будет выведено, какие именно каталоги какими хостами смонтированы:
Заметьте, что отображаются лишь ресурсы, смонтированные демоном mountd, т.е. те, к которым было обращение клиентов. Список каталогов, которые вообще могут быть экспортированы (но не факт, что востребованы кем-то в данный момент), позволяет получить ключ -e:
Вторая утилита – rpcinfo – выдаёт более общую информацию о работе RPC на локальном или удалённом хосте. Например, будучи запущенной с ключом -p, она выведет список всех зарегистрированных RPC-процедур с указанием порта, на котором они работают (см. рис. 1). Здесь, кстати, можно увидеть, что демон nfsd готов обслуживать запросы на портах 2049 согласно протоколам v2 и v3. В системах Linux с ядром 2.6 можно созерцать ещё одну строчку – для v4, но во FreeBSD разработчики с этим пока не спешат.
Рисунок 1. Пример вывода утилиты rpcinfo Дополнительный мониторинг работы NFS-сервера предлагает утилита nfsstat, которая позволяет увидеть, какие именно RPC-запросы наиболее часто выполняются, а также отследить некоторые ошибки (например, ошибки аутентификации). Практический пример Посмотрим на практике, какие шаги нужно выполнить, чтобы предоставить в общий доступ каталог веб-сервера /var/www. Предположим, что полный доступ (на чтение-запись) должен предоставляться хостам admin, webmaster и designer, причём с правами пользователя webmaster независимо от имени подключающегося пользователя, а также доступ на чтение хосту backup. Добавляем в /etc/rc.conf строки: rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r -p 700" rpc_lockd_enable="YES" rpc_statd_enable="YES" Третья строка используется, чтобы жёстко задать порт, на котором будет работать mountd (по умолчанию используется только флаг -r). Далее редактируем или создаём файл /etc/exports. Для нашей задачи он будет выглядеть так: /var/www -alldirs,mapall=webmaster admin webmaster designer /var/www -ro backup Опция alldirs в первой строке используется, чтобы пользователи могли при необходимости монтировать не только корень /var/www, а и произвольный подкаталог. Для пущей важности запрещаем доступ к rpcbind в файле /etc/hosts.allow (rpcbind собирается с поддержкой TCP-WRAPPER): rpcbind : admin webmaster designer : allow rpcbind : backup : allow rpcbind : ALL : deny Ну и открываем на межсетевом экране (если по умолчанию всё закрыто) доступ к 111-м, 700-м (именно для этого использовалась жёсткая привязка порта) и 2049-м портам с адресов, которым нужен доступ к этим службам. Теперь со спокойной совестью перегружаемся или вручную выполняем следующий сценарий инициализации: # /etc/rc.d/nfsd start Запустив rpcinfo и showmount -e:
/var/www admin webmaster designer backup убеждаемся, что всё готово к работе. Можно выполнять монтирование с клиентских машин: # mount -t nfs webserver:/var/www /mnt/www Реализация в Linux В Linux дела с NFS обстоят заметно лучше – NFSv4 реализована практически полностью как в сервере, так и в клиенте, и можно в значительном объёме пользоваться преимуществами нового протокола. По сравнению с FreeBSD основное отличие, помимо немного других имён основных программ, – в формате файла /etc/export: <ресурс> <клиент>(<опции>) <клиент>(<опции>) . . . То есть в одной строке ресурса вы можете задать различные опции для различных клиентов (во FreeBSD это приходится указывать отдельными строками).
Здесь к указанному каталогу предоставляется доступ на чтение/запись (синхронную) с хоста 10.0.0.203, и только на чтение, но без подавления доступа с правами суперпользователя, с хоста 10.0.0.254. Для работы с таблицей экспорта (и для её перезагрузки в частности) используется утилита exportfs: $ sudo exportfs -ua $ sudo exportfs -a Первой командой таблица полностью очищается, второй – строится заново согласно /etc/exports. Вопросы безопасности Если говорить о NFSv2 и v3, то здесь вопросы безопасности приобретают особенно серьёзное значение, поскольку сам протокол не слишком об этом заботится. Целиком полагаясь на семантику файловых систем в UNIX, NFS слепо доверяет идентификаторам пользователя и группы, поступающим с каждым запросом, и принимает решение о доступе, основываясь исключительно на них. Во-первых, это предполагает идентичность баз пользователей на сервере и клиенте, т.е. один и тот же пользователь и там, и там должен бы иметь один и тот же UID. Во-вторых, здесь возникает проблема «локального суперпользователя» – если пользователь на своей рабочей станции располагает правами root (либо может их получить, например, загрузившись с LiveCD), то и на NFS-сервер он будет «стучаться» с идентификатором 0, соответствующим правам суперпользователя, но уже серверного, и может получить доступ к той информации, к которой по идее доступа у пользователя быть не должно. Для решения этих проблем используют отображение имён (mapping). Во FreeBSD существуют две опции: -maproot=<user>, позволяющая указать пользователя, чьи права будут задействованы при обращении к ресурсу пользователя с идентификатором 0 (по умолчанию используется nobody), и -mapall=<user>, с помощью которой можно предоставлять ресурс всем удалённым пользователям с правами конкретного локального пользователя. В Linux аналогичные задачи решаются с помощью опций root_squash и all_squash. Имя пользователя, на которого отображаются подключения соответственно суперпользователя и всех пользователей, может быть задано с помощью опций anonuid и anongid (по умолчанию – nobody). Также настоятельно рекомендуется ограничивать из внешних сетей доступ к открытым RPC-портам с помощью межсетевого экрана (эта задача усложняется тем, что демон mountd может выбирать рабочий порт произвольным образом). Кроме того, рекомендуется задать ограничительные правила в /etc/hosts.allow. Несмотря на это, защищённость протоколов NFS 2-й и 3-й версий остаётся довольно низкой. Некоторые тесты (ни на что не претендующие) Итак, что из себя представляет NFS, мы увидели. Теперь хорошо было бы посмотреть, какова же она в работе. Например, попробуем выполнить копирование сравнительно большого файла размером 188 Мб (первая команда – непосредственное копирование, вторая – копирование через NFS, смонтированную локально):
От FTP, как видите, NFS не отстала ни на секунду и даже по сравнению с локальным копированием была не так уж плоха, во всяком случае различие в затраченном времени было не в разы – примерно 65%. Примерно такое же соотношение было и при копировании множества небольших файлов. При работе по сети (сервер – nfsAxe на Windows XP, клиент – FreeBSD) на копирование с клиента на сервер каталога со множеством файлов различного размера общим объёмом 83 Мб потребовалось 25 минут при использовании 3-й версии и 30 минут для NFSv2. Чтение с сервера 952-х файлов общим размером 31,3 Мб (сервер на FreeBSD, клиент – nfsAxe на Windows) заняло примерно 1,5 минуты. На ту же работу по протоколу FTP (клиент в FAR) потребовалось 7,5 минуты – в 5 раз больше. Проверка взаимодействия FreeBSD (сервер, Celeron 433 МГц) и Linux (клиент, Pentium IV 2.4 ГГц) показала вполне ожидаемые результаты: 3-я версия была процентов на 20-30 быстрее, чем 2-я; на операциях чтения UDP показал почти в 5 раз лучшие результаты, чем TCP (тестирование проводилось в надёжной ненагруженной локальной сети). На операциях записи работа по TCP оказалась ненамного быстрее, чем по UDP. Так, при работе по NFSv3 чтение с сервера каталога /usr/ports/ftp (общим объёмом 8,7 Мб) заняло 1 минуту 7 секунд по TCP и всего 10 секунд по UDP. Запись этого же каталога обратно на сервер заняла 20 и 25 секунд соответственно. На чтение по протоколу FTP (использовался wget с опцией -r) потребовалось 2 минуты. Запуск сервера на Linux и клиента на FreeBSD на протоколах NFSv2 и v3 показал аналогичное соотношение производительности. А вот использование NFSv4 несколько удивило – при записи на сервер по UDP был показан самый лучший результат (29 секунд), а вот по TCP работа потребовала почти 7 минут против полутора для v2 и v3. Таким образом, на операциях чтения UDP показывает несколько лучшие результаты, TCP же работает быстрее на запись. NFSv4 на FreeBSD, к сожалению, пока ведёт себя иногда несколько странно. Вместо заключения Как видите, NFS является простым способом объединить файловые системы нескольких машин с UNIX-подобными ОС (да и не только UNIX). Несмотря на некоторые претензии к ней в плане защищённости и быстродействия, она весьма эффективна для предоставления пользователям доступа к их домашним каталогам с любого компьютера в сети, для распространения «массивных» данных (например, исходных кодов системы или дерева коллекции Портов), да просто для быстрой переброски каких-нибудь файлов с одной машины на другую. Во всяком случае это будет быстрее, чем заниматься настройками Samba или «поднимать» целый FTP-сервер для разовой операции. Ну а с повсеместным распространением NFSv4 можно надеяться, что этот протокол ждёт достаточно светлое будущее. Приложение NFS и Windows Не нужно думать, что NFS – это удел только UNIX-систем с чёрной и страшной консолью. Реализации этого протокола есть и для Windows, и неплохо, нужно сказать, взаимодействуют с UNIX-серверами. Можно указать такие пакеты, как DiskAccess, nfsAxe, которые помимо инструментов работы с NFS и реализации NFS-серверов включают ряд дополнительных инструментов – FTP- и Telnet-клиенты, средства работы с DNS и т. д. В качестве примера коротко рассмотрим работу NFS-клиента nfsAxe. Его отличает множество инструментов, делающих работу с NFS весьма комфортной. Например, с помощью NFSProbe вы можете просмотреть, какие ресурсы доступны на том или ином сервере или в вашей сети. То есть вы получаете в своё распоряжение аналог rpcinfo с графическим интерфейсом (см. рис. 2).
Рисунок 2. Не знаю, намного ли это удобнее консоли, но тоже вся нужная информация как на ладони Если всё в порядке и вы видите именно то, что ожидали увидеть, то следующий шаг – монтирование нужного ресурса. С помощью NFS Map Drive tool укажите букву диска, которая будет присвоена NFS-каталогу, и либо укажите нужный ресурс вручную, либо, нажав на «Browse...», выберите ресурс из определённых автоматически. Теперь с этим новым диском можно работать, как с локальным (см. рис. 3).
Рисунок 3. Дот-файлы начинаются с подчёркивания, а не с точки. В остальном – вполне пригодный для работы каталог Отключение сетевого диска выполняется, как это принято в Windows, – с помощью команды «net use N: /delete» (где N – буква смонтированного диска) либо через графический интерфейс (щелчок правой кнопкой на значке «Мой компьютер > Отключить сетевой диск...»). NFS уровня пользователя В коллекции Портов FreeBSD есть реализация NFS-сервера уровня пользователя – unfs3. Поддерживается третья версия протокола, и, учитывая, что «ядерная» реализация по определению будет быстрее, чем сервер, работающий на уровне пользователя, то сейчас польза от UNFS3 немного сомнительна. Разработчики декларируют максимально полную реализацию стандарта, а также высокую переносимость между различными системами. Здесь используется exports-файл формата, принятого в Linux, так что данную программу можно рассматривать как один из способов унифицировать использование NFS на различных системах в вашей сети, если это необходимо. «Не совсем NFS» FreeBSD, помимо версий NFSv2 и v3, поддерживает также расширенную реализацию NQNFS (Not Quite NFS – «не вполне NFS»). NQNFS разрабатывалась в первую очередь для поддержания согласованности кэша. В условиях отсутствия состояния согласование кэша является весьма сложной задачей – как клиент сможет узнать, что исходный файл изменился и его кэш, следовательно, устарел? NQNFS решает эту задачу с помощью так называемых владений (аналогичное решение появилось в NFSv4), которые сервер передаёт клиентам на определённое время, отслеживая тем самым их состояние и получая возможность уведомить клиента об изменениях открытого ими файла. NQNFS обратно совместима с NFS, т.е. сервер, поддерживающий NQNFS, будет работать с обычным NFS-клиентом по стандартному протоколу, не используя никаких расширений. NFS за пару «кликов»? Разработчики большинства современных Linux-дистрибутивов стремится предоставить своим пользователям максимум удобных графических средств для работы. Однако протокол NFS не часто получает достаточное внимание разработчиков. Тем не менее, и обычным пользователям NFS мог бы сослужить хорошую службу. Например, перекинуть содержимое своего домашнего каталога с настольного компьютера на ноутбук... Казалось бы, это должно быть не намного сложнее, чем «расшарить» папку в Windows. В Ubuntu, в меню «Администрирование», есть пункт «Опубликованные папки», вызывающий инструмент shares-admin, – пара щелчков мышью, и каталог добавлен в /etc/exports. Правда, из опций здесь можно поставить лишь признак «Только чтение», да и то не стоит слишком ему доверять – исходя из показанного на рис. 4 можно предположить, что каталог доступен для чтения-записи всей сети, а 23-й хост чем-то провинился и получил ограничение.
Рисунок 4. Инструмент shares-admin из Ubuntu собственной персоной На самом же деле всё с точностью до наоборот, в чём можно убедиться, заглянув в /etc/exports: /home/amsand 172.20.0.23(rw) 172.20.0.0/255.255.255.0 А вот смонтировать NFS-каталог мышкой, как ни странно, не получится. «Подключение к серверу» предложит вам подключиться к чему угодно – FTP, SSH, WebDAV, Windows-ресурсу... Но только не к NFS-серверу. Так что всё равно придётся открывать консоль. Автомонтирование каталогов UNIX-системы, как правило, имеют в своём составе средства автоматического монтирования каталогов. Хотя к теме данной статьи это непосредственного отношения не имеет, но всё же автомонтирование чаще всего применяется именно для работы с NFS-каталогами, поэтому коротко осветим и эту тему. Во FreeBSD в состав системы включён демон amd. Настройки по умолчанию позволяют сразу же после активации (что достигается добавлением строки «amd_enable=YES» в /etc/rc.conf и либо перезагрузкой, либо запуском демона командой «/etc/rc.d/amd start») монтировать NFS-ресурсы простым обращением к каталогу, соответствующему имени хоста: достаточно перейти в /net/<имя_хоста> (хотя по ls /net вы никаких подкаталогов в нём не найдёте), и вы увидите там содержимое удалённого каталога:
Спустя некоторое время смонтированный каталог, если не будет использоваться, так же автоматически будет размонтирован, высвобождая занятые ресурсы. Если необходима тонкая настройка способа монтирования, это можно выполнить в конфигурационном файле (по умолчанию /etc/amd.map). Подробности ищите на страницах справки. NFSv4 и FreeBSD FreeBSD довольно хорошо поддерживает 2-ю и 3-ю версии NFS, однако с 4-й пока как-то не ладится. Клиент уже может (хотя и с некоторыми ограничениями) взаимодействовать с серверами, поддерживающими NFSv4. А вот реализация сервера пока лишь обещается – теперь в одном из релизов 7-й ветки. На момент подготовки статьи в мартовском снапшоте 7.0-CURRENT-200703 использовалась прежняя реализация, и надо полагать, что и в 7.0-RELEASE поддержки сервера NFSv4 ещё не будет. Можно отыскать некоторые сторонние патчи, реализующие сервер 4-й версии (например, на ftp://ftp.cis.uoguelph.ca/pub/nfsv4, есть патчи для FreeBSD 4.11 и 6.1), однако пока что их использование на промышленных серверах не рекомендуется.
|
Сергей Супрунов
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
