Сетевая файловая система (Network File System – NFS) служит для обеспечения доступа компьютерам сети к общим каталогам на сервере. Централизованное хранение файлов на сервере облегчает организацию работы в большой сети, особенно там, где один и тот же пользователь может работать в разное время на разных компьютерах. С помощью файлового сервера решается сразу несколько задач:
Служба NFS позволяет серверу обеспечить разделяемый доступ к указанным каталогам его локальной файловой системы, а клиенту – монтировать эти каталоги так же, как если бы они были локальными каталогами клиента.
NFS была разработана компанией Sun Microsystems и оказалась настолько удачной, что ее реализации были воплощены разными компаниями почти для всех операционных систем. Существует несколько принципиально разных реализаций NFS. Достаточно распространена версия NFS 2.0, хотя уже в Solaris 2.5 была введена NFS 3.0. В последующих версиях Solaris, включая Solaris 9, в NFS были внесены существенные дополнения, но сам протокол остался совместимым с реализацияим NFS 3.0 в других системах. Начиная с NFS 3.0, поддерживается передача пакетов посредством TCP и UDP, ранее поддерживался только UDP.
Будьте внимательны! В сети следует использовать клиентов и серверы NFS одной и той же версии. NFS 2.0 можно встретить в старых системах, например, в HP-UX 10.0. Совместная работа систем, использующих разные версии NFS, нежелательна.
NFS по смыслу и по организации работы похожа на
Служба NFS предполагает работу модели клиент-сервер, причем на компьютерах-клиентах и компьютерах-серверах запускаются разные программы для обеспечения доступа к общим каталогам на сервере.
Поскольку компьютеры на рабочих местах сотрудников в России обычно управляются Windows-системами, в качестве файловых серверов часто используются также Windows-системы. Однако, нередко возникает желание установить UNIX на файл-сервер, чтобы повысить надежность, сократить затраты на оборудование или использовать этот же сервер для ряда других корпоративных нужд: веб-сервера, сервера баз данных и т.п. Чтобы не устанавливать дополнительное ПО для поддержки NFS в таком случае, достаточно установить пакет samba на UNIX-машину. Он позволит ей "прикинуться" Windows NT сервером так, чтобы все клиентские компьютеры воспринимали его как самый обычный файл-сервер или принт-сервер Windows-сети. Пакет samba умеет обеспечивает поддержку "родного" для Windows-сетей протокола SMB.
В тех случаях, когда в сети работают несколько UNIX-компьютеров и им нужно обращаться к одному файл-серверу, имеет смысл использовать механизм NFS (network file system).
NFS не очень устойчив к сбоям сети, он требует ее бесперебойной работы и предполагает быстрое соединение между клиентом и сервером. Применение NFS для монтирования файловых систем вне локальной сети, например, через Интернет, технически осуществимо, но не очень рационально и небезопасно.
После настройки /etc/exports, но в Solaris он находится в другом файле – /etc/dfs/dfstab.
NFS работает посредством механизма удаленного вызова процедур (RPC – Remote Procedure Call).
Идеология RPC очень проста и привлекательна для программиста. Как обычно работает сетевое приложение? Оно следует некоему протоколу (например, HTTP): формирует пакет с запросом, вызывает системную функцию установления соединения, затем функцию отправки пакета, затем ждет ответного пакета и вызывает функцию закрытия соединения. Это значит, что вся работа с сетью является заботой программиста, который пишет приложение: он должен помнить о вызове функций сетевого API системы, думать о действиях в случае сбоев сети.
RPC предполагает иной способ обмена данными между клиентом и сервером. С точки зрения программиста, приложение клиента, работающее с помощью RPC, вызывает функцию на сервере, она выполняется и возвращает результат. Пересылка запроса на выполнение функции через сеть и возврат результатов от сервера клиенту происходит незаметно для приложения, поэтому последнее не должно беспокоиться ни о сбоях сети, ни о деталях реализации транспортного протокола.
Для того, чтобы обеспечить прозрачность пересылки данных через сеть, придумана двухступенчатая процедура. На сервере любое приложение, которое хочет предоставлять свой сервис через RPC, регистрируется в программе, которая называется транслятором портов (port mapper). Функция этой программы – устанавливать соответствие между номером процедуры RPC, которую запросил клиент, и номером TCP или UDP порта, на котором приложение сервера ждет запросов. Вообще говоря, RPC может работать не только с TCP или UDP, в Solaris как раз реализована работа на базе механизма TI (Transport-Independent), поэтому в Solaris транслятор портов называется rpcbind, а не portmap, как в Linux или FreeBSD.
Приложение, которое регистрируется у транслятора портов, сообщает ему номер программы, номер версии и номера процедур, которые могут обрабатываться данной программой. Эти процедуры будут впоследствии вызываться клиентом по номеру. Кроме этого, приложение сообщает номера портов TCP и UDP, которые будут использоваться для приема запросов на выполнение процедур.
Клиент, желающий вызвать выполнение процедуры на сервер, сначала отправляет запрос транслятору портов на сервер, чтобы узнать, на какой TCP или UDP порт надо отправить запрос. Транслятор портов запускается при старте системы и всегда работает на стандартном порте 111. Получив ответ от него, клиент отправляет запрос на тот порт, который соответствует требуемому приложению. Например, сервер NFS работает на порту 2049.
Прежде чем мы перейдем к описанию настроек сервера и клиентов NFS, следует понять, как осуществляется монтирование удаленных файловых систем в принципе.
Клиент NFS посылает запрос на монтирование удаленному компьютеру, который предоставляет свою файловую систему (обычно – некоторую ее часть) для общего пользователя. При этом говорят, что сервер NFS "экспортирует" тот или иной каталог (подразумевается – с подкаталогами). Запрос от клиента NFS попадает на обработку демону mountd. Тот выдает клиенту NFS специальный ключ. Этот ключ является идентификатором, который однозначно идентифицирует каталог, смонтированный по сети.
По NFS можно смонтировать как целые файловые системы, так и отдельные каталоги. Из соображений безопасности запрещено монтировать каталоги "через раздел". Это означает, что если каталог /var расположен на одном разделе диска, а каталог /var/adm – на другом, то при монтировании каталога /var каталог /var/adm не будет автоматически смонтирован. Если требуется монтировать те подкаталоги экспортируемого каталога, которые расположены в другой файловой системе (на другом разделе), следует экспортировать их отдельно и указывать в /etc/dfs/dfstab еще один разделяемый каталог – тот самый подкаталог с другого раздела.
Ключ, выданный клиенту при монтировании и идентифицирующий сеанс работы с данным удаленным каталогом, сохраняется при перезагрузке
После nfsd.
Демонтирование файловой системы выполняется также, как и демонтирование любой другой файловой системы – командой umount.
Ниже будут обсуждены следующие аспекты настройки службы клиент-сервер в сети:
Для настройки NFS сервера нам потребуется выполнить настройку как минимум трех приложений: rpcbind, mountd и nfsd. Прежде всего, создадим файл /etc/dfs/dfstab, в котором опишем экспортируемые каталоги; в отличие от других систем UNIX, Solaris требует указать здесь не просто список каталогов с параметрами монтирования, а набор команд share, которые фактически и запускают экспорт каталогов. Таким образом, получается, что /etc/dfs/dfstab – это скрипт, который выполняется для того, чтобы сделать общие каталоги доступными для монтирования через сеть.
Для начала следует запустить программу rpcbind, если она еще не запущена. Скорее всего, она запускается при старте вашей системы, если это действительно Solaris. Эта программа, как мы помним, преобразует номера вызовов процедур RPC в номера портов TCP и UDP. При запуске любого RPC-сервера, т.е. программы, работающей с протоколом RPC, программа rpcbind получает от этого RPC-сервера информацию о том, какие номера процедур RPC он намерен обслуживать и через какой порт TCP (UDP) ему следует направлять запросы.
Когда клиент деалет RPC-вызов, сперва происходит выяснение требуемого номера порта на машине сервера у rpcbind.
Поэтому rpcbind должен быть запущен до того, как будет запущен любой из RPC-серверов. При аварийном завершении rpcbind необходимо вначале перезапустить rpcbind, и затем перезапустить все RPC-серверы.
Для проверки готовности всех служб NFS к работе через rpcbind используется команда rpcinfo -p:
rpcinfo -p program vers proto port service 100000 4 tcp 111 rpcbind 100000 3 tcp 111 rpcbind 100000 2 tcp 111 rpcbind 100000 4 udp 111 rpcbind 100000 3 udp 111 rpcbind 100000 2 udp 111 rpcbind 100232 10 udp 32772 sadmind 100083 1 tcp 32771 100221 1 tcp 32772 100068 2 udp 32773 100068 3 udp 32773 100068 4 udp 32773 100068 5 udp 32773 100229 1 tcp 32773 metad 100230 1 tcp 32774 metamhd 100242 1 tcp 32775 metamedd 100001 2 udp 32774 rstatd 100001 3 udp 32774 rstatd 100001 4 udp 32774 rstatd 100002 2 udp 32775 rusersd 100002 3 udp 32775 rusersd 100002 2 tcp 32776 rusersd 100002 3 tcp 32776 rusersd 100008 1 udp 32776 walld 100012 1 udp 32777 sprayd 100011 1 udp 32778 rquotad 100024 1 udp 32779 status 100024 1 tcp 32777 status 100133 1 udp 32779 100133 1 tcp 32777 100021 1 udp 4045 nlockmgr 100021 2 udp 4045 nlockmgr 100021 3 udp 4045 nlockmgr 100021 4 udp 4045 nlockmgr 100021 1 tcp 4045 nlockmgr 100021 2 tcp 4045 nlockmgr 100021 3 tcp 4045 nlockmgr 100021 4 tcp 4045 nlockmgr 300598 1 udp 32784 300598 1 tcp 32781 805306368 1 udp 32784 805306368 1 tcp 32781 100249 1 udp 32785 100249 1 tcp 32782 1289637086 5 tcp 32787 1289637086 1 tcp 32787 100005 1 udp 32814 mountd 100005 2 udp 32814 mountd 100005 3 udp 32814 mountd 100005 1 tcp 33201 mountd 100005 2 tcp 33201 mountd 100005 3 tcp 33201 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100227 2 udp 2049 nfs_acl 100227 3 udp 2049 nfs_acl 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100227 2 tcp 2049 nfs_acl 100227 3 tcp 2049 nfs_acl
При запуске системы в многопользовательском режиме 3 rpcbind запускается автоматически, а службы NFS – в случае, если существует файл /etc/dfs/dfstab.
Сервис NFS предоставляется двумя программами, которые обрабатывают соответствующие RPC-запросы. Это программы mountd и nfsd.
Программа mountd обрабатывает запросы на удаленное монтирование файловых систем. Для получения списка экспортируемых каталогов применяют команду showmount –e, которая обращается к mountd за информацией:
showmount -e export list for sunny: /nfst (everyone)
Для того, чтобы на сервере NFS узнать, какие системы подсоединили к себе showmount без параметров:
showmount www.eu.spb.ru
Программа nfsd – это обработчик файлового
Параметры службы NFS настраиваются в файле /etc/default/nfs, а запуск и остановка службы осуществляется, соответственно, командами
/etc/init.d/nfs.server start
и
/etc/init.d/nfs.server stop
В Solaris 10 служба NFS запускается и останавливается также, как и другие службы – командой svcadm enable nfs/server и svcadm disable nfs/server соответственно. О новом механизме работы со службами, появившемся в Solaris 10, более подробно рассказано в лекции 13.
В файле /etc/default/nfs следует указать достаточное количество потоков, которые можно параллельно запускать для обслуживания одновременных запросов к файлам через NFS. За это отвечает параметр NFSD_SERVERS.
Значение этого параметра не должно быть меньшим максимального количества одновременных обращений к разделяемым файловым системам NFS на сервере. Слишком маленькое число потоков вызовет задержки в работе клиентов, поскольку им придется становиться в очередь на обработку запросов. В то же время, излишне большое число приведет к нерациональному расходу памяти
Если из-за слишком большого количества потоков nfsd загрузка процессора возрастет до 100%, имеет смысл уменьшить число этих потоков. С одной стороны, идеально иметь 2 потока на каждого активного клиента, постоянно обращающегося к ресурсам NFS, с другой – на один процессор рекомендуется запускать не более 16 потоков, если это достаточно медленный процессор типа тех, что установлены в системах SPARCstation 5, и не более.
В моей тестовой системе Solaris на компьютере x86 монтирование каталога сервера одним клиентом NFS привело к увеличению занимаемой nfsd памяти всего на 8 Кб, так что в современных системах имеет смысл ожидать скорее некоторого снижения производительности за счет нагрузки на процессор или кэширования больших файлов экспортируемых каталогов, чем нехватки памяти из-за слишком большого количества потоков nfsd.
Перед запуском mountd и nfsd следует убедиться, что в /etc/dfs/dfstab указаны все каталоги, которые вы собираетесь экспортировать, а также разумно настроены параметры безопасности.
Работа с общим диском, разделяемым между многими пользователями сети, предполагает, что в пределах сети существует общее пространство имен пользователей, т.е. пользователь gregory на любом клиентском (в терминах NFS) компьютере имеет то же реальное имя и (что важнее) тот же идентификатор, что и пользователь gregory на сервере NFS. Это достигается использованием централизованной аутентификации (например, с помощью PAM и сервера аутентификации или с помощью NIS+). Кроме этого, важно ограничить права пользователя root при доступе через NFS, т.к. пользователь root на любом компьютере в любой системе UNIX имеет идентификатор 0, но от имени пользователя root на разных компьютерах могут работать разные люди.
Для ограничения доступа пользователя root на сервере NFS любые файловые запросы от имени пользователей root клиентских компьютеров выполняются от имени nobody. Можно указать, пользователям root каких компьютеров мы предоставляем привилегированный доступ от имени root и через NFS.
По умолчанию файловая система экспортируется с правами чтения и записи для тех, кто ее смонтирует. Однако, права доступа к конкретным каталогам могут запрещать запись в них; фактически права доступа к
Рассмотрим для примера файл /etc/dfs/dfstab системы Solaris:
share -F nfs -o rw=@212.231.110, ro=@192.168.4 /home share -F nfs -o ro=212.231.110@,root=212.231.110.112 /usr/share/man
Файловая система /home экспортируется с возможностью чтения и записи для компьютеров сети 212.231.110, и только чтения – для компьютеров сети 192.168.4. Файловая система /usr/share/man экспортируется для чтения для компьютеров сети 212.231.110. Пользователю root с компьютера 212.231.110.112 разрешен доступ с правами суперпользователя к этой файловой системе.
Полный список доступных режимов и настроек при указании экспортируемой файловой системы доступен в man share и man share_nfs, а некоторые из них обсуждаются ниже, в разделе "параметры экспорта в /etc/dfs/dfstab ".
Для бездисковых станций через сеть с помощью NFS экспортируются все файловые системы, которые им нужны, и даже область свопинга. Поэтому, настраивая экспорт файловой системы для бездисковых станций следует убедиться, что для них экспортируется корневая файловая система и область свопинга.
Под "корневой файловой системой" мы здесь понимаем определенный заранее каталог на сервере NFS, играющий роль корневой файловой системы для бездисковой станции. Собственный корневой каталог сервера не следует экспортировать вообще.
Файловые системы бездисковых рабочих станций монтируются из отдельного каталога сервера (в наших примерах мы будем использовать каталог /exports, но можно задействовать и любой другой каталог) и по составу файлов аналогичны файловым системам автономных компьютеров, оснащенных дисками.
Табл. 7.1 демонстрирует соответствие экспортируемых на
Обычным пользователям сервера доступ к каталогу /export, как правило, запрещают, ибо этот каталог предназначен только для монтирования его клиентами, и управление этим каталогом осуществляет администратор, работая от имени root.
Каталог /export/root следует экспортировать с правами пользователей на чтение и запись.
Параметр nosuid запрещает клиентам устанавливать бит root клиента или пользователю, чей uid совпадает с uid наделенного большими правами пользователя в какой-либо из систем сети (особенно – сервера NFS).
Вместо того, чтобы использовать при монтировании каталога /export/root параметр nosuid, может быть достаточно запретить пользователям сервера NFS доступ к этому каталогу.
Параметр ro обеспечивает монтирование каталога только для чтения для всех клиентов. Например, каталог с системными исполняемыми файлами пользователям менять незачем, и его рекомендуется экспортировать только для чтения.
| Экспортируемые каталоги на сервере | Импортируемые каталоги на бездисковом компьютере | Пояснение | Параметры монтирования |
|---|---|---|---|
| /export/root/<hostname> | / | Корневой каталог | -o nosuid |
| /export/exec/<platformname> | /usr | Каталог выполняемых файлов (Shared Product Object Tree – SPOT) Содержимое этого каталога зависит от аппаратной платформы, разным платформам должны монтироваться разные каталоги | -o ro |
| /export/home/<hostname> | /home | возможно, потребуется -o nosuid |
|
| /export/share | /usr/share | -o ro |
|
| /export/swap/<hostname> | Применяется на бездисковых клиентах в качестве удаленного пространства подкачки |
При экспорте каталога /export/home можно пойти двумя путями:
/home сервера, так, чтобы дать возможность пользователям работать на сервере интерактивно в своем домашнем каталоге и монтировать этот же каталог по сети при работе на других компьютерах;/export/home сервера с тем, чтобы пользователи на сервере не имели домашних каталогов (или же, что менее удобно, имели разные домашние каталоги при работе на сервере и при работе на остальных компьютерах сети).В первом случае следует обязательно указать параметр nosuid для монтирования этого каталога через NFS.
Теперь вы должны проверить, что mountd и nfsd запущены правильно. Сначала это делается с помощью команды rpcinfo -p. Вывод программы должен показать что-то похожее на следующее:
100000 4 tcp 111 rpcbind 100000 3 tcp 111 rpcbind 100000 2 tcp 111 rpcbind 100000 4 udp 111 rpcbind 100000 3 udp 111 rpcbind 100000 2 udp 111 rpcbind 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100005 3 udp 1023 mountd 100005 3 tcp 1023 mountd 100005 1 udp 1023 mountd 100005 1 tcp 1023 mountd
Как видно, rpcbind успешно анонсирует службы.
Если в ответ на rpcinfo -p мы получили сообщение
rpcinfo: can't contact rpcbind: RPC: Remote system error - Connection refused
или
RPC_PROG_NOT_REGISTERED
или нечто похожее вместо ожидаемого – стало быть, rpcbind не доступен (отключен). Возможно, в файлах /etc/hosts.allow или /etc/hosts.deny есть настройки, запрещающие программе rpcbind отвечать нам.
Для перезапуска служб NFS можно завершить выполнение демонов nfsd, mountd и rpcbind, запустить их вновь в следующем порядке: rpcbind, затем mountd и следом nfsd. Программе nfsd может быть передан числовой аргумент – число потоков, которые следует запустить при старте. Программа "распараллелится" в указанном количестве потоков.
Более стандартным выходом является запуск скрипта /etc/init.d/nfs.server вначале с параметром stop, затем с параметром start.
При штатной работе mountd и nfsd запускаются на сервере NFS при старте системы из стартовых скриптов. Это можно проверить командами
ps -ef | grep mountd ps -ef | grep nfsd
Программа rpcbind объявляет свои службы независимо от того, продолжают ли работать программы, ранее зарегистрировавшиеся и (возможно) прекратившие работу вследствие аварии.
Следовательно, вышеприведенная проверка с помощью ps обязательна, если служба NFS перестала работать.
Не забудьте перед настройкой сервера NFS изучить страницы руководства, рассказывающие о rpcbind, mountd, nfsd, dfstab.
Для того, чтобы несколько процессов не конфликтовали при доступе к одному и тому же файлу, обычно используется механизм блокировки файла. Подробнее о блокировках следует читать в документации по системным фукнциям lockf() и flock(). В NFS механизм блокировки реализован посредством двух демонов: lockd и statd.
Оба демона запускаются на сервере NFS после mountd и nfsd.
Программа lockd устанавливает и снимает блокировку файлов по запросу, а демон statd следит за состоянием блокировок и работоспособностью
В сети демон statd сервера NFS обменивается информацией с демонами statd на других компьютерах. Демон lockd посылает запросы демону statd для установления статуса компьютеров. взаимодействующих с ним.
Если компьютер, за которым следит statd, перестает отвечать и перезапускается, удаленный statd сообщает об этом локальному, следящему за ним, и локальный демон информирует об этом программы, которые работали через это соединение. Если прекращает работу локальный сервис и затем следует его перезапуск, то statd информирует об этом другие компьютеры.
Если на сервере NFS установлены дисковые квоты для отдельных пользователей, то для того, чтобы пользователь "издалека" мог узнать свою дисковую квоту, запускается демон rquotad.
Вообще говоря, установка дисковых квот (независимо от NFS) выполняется следующим образом:
/etc/vfstab для файловой системы, для которой будет применяться квотирование, устанавливается параметр монтирования quota. Не забудьте демонтировать и снова смонтировать соответствующую файловую систему, если хотите, чтобы параметр оказал воздействие на работу файловой системы немедленно!quotas в корне этой файловой системы (например, если речь идет о файловой системе /export/home, то файл будет называться /export/home/quotas );edquota устанавливаются квоты для каждого из пользователей в отдельности;quotaon.Для выключения поддержки квот достаточно выполнить команду
quotaoff
Для проверки квот в файловых системах надо выполнить команду
quota username
В Solaris NFS организован иначе, нежели в других системах UNIX, и это следует иметь в виду при настройке систем в гетерогенных сетях:
/etc/dfs/dfstab в других системах называется /etc/exports ;/etc/exports является файлом конфигурации, а не скриптом, вызывающим программу share ;/etc/dfs/dfstab нужно дать команду shareall для вступления изменений в силу; в других системах следует перезапустить mountd и nfsd, обычно для этого можно использовать сценарий, как и в Solaris;/etc/dfs/dfstab указаны экспортированнные каталоги.Помните, что команда shareall просто выполняет подряд все команды share, содержащиеся в файле /etc/dfs/dfstab. Если этот файл был модифицирован и некоторые команды экспорта каких-то файловых систем были удалены, действие старых команд share, запущенных до модификации файла, продолжится и после выполнения shareall.
Поэтому следует перезапустить mountd для того, чтобы изменения возымели эффект. Внимание: нельзя перезапускать mountd, когда пользователи работают с файловой системой сервера NFS: это может вызвать потери данных и зависание систем – клиентов NFS.
Если требуется ограничить доступ к разделяемой файловой системе только определенной группой машин, следует указать их список команде share:
share -F nfs -o rw=host1:host2 /home/host12
При экспорте файловых систем можно передавать командам share ряд параметров, указывающих, в каком режиме следует экспортировать те или иные каталоги. Наиболее важные параметры сведены в табл. 7.2:
Например, файл /etc/dfs/dfstab может иметь такой вид для экспорта двух файловых систем:
share -F nfs -o rw=@212.231.110, ro=@192.168.4 /home share -F nfs -o ro=212.231.110@,root=212.231.110.112 /usr/share/man
| Параметр | Значение |
|---|---|
ro |
только для чтения – для всех |
ro=host1, host2 |
только для чтения и только указанным компьютерам |
rw |
для чтения и записи – для всех |
rw=host1, host2 |
для чтения и записи, но только указанным компьютерам |
root=host1, host2 |
с указанных компьютеров пользователь root получает доступ к файлам на сервере NFS от имени root (иначе – от имени nobody или указанного в параметре anon) |
anon=uid |
идентификатор пользователя, от имени которого сможет работать с файлами на сервере NFS пользователь root удаленного (клиентского) компьютера, по умолчанию – nobody |
nosub |
запрещается монтировать подкаталоги экспортируемого каталога |
nosuid |
запрещается создавать в экспортируемой файловой системе файлы с установленными битами suid и sgid |
В Solaris 9 были добавлены некоторые расширения поддержки NFS, которые улучшили ее производительность:
forcedirectio при directio(). По умолчанию (без указания параметра при монтировании) запись в файл производится так же, как и раньшеДля получения статистики о работе сервера NFS следует использовать команду nfsstat на таком сервере:
nfsstat -s Server rpc: Connection oriented: calls badcalls nullrecv badlen xdrcall dupchecks 0 0 0 0 0 0 dupreqs 0 Connectionless: calls badcalls nullrecv badlen xdrcall dupchecks 33 0 0 0 0 3 dupreqs 0 Server nfs: calls badcalls 33 0 Version 2: (0 calls) null getattr setattr root lookup readlink 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% read wrcache write create remove rename 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% link symlink mkdir rmdir readdir statfs 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% Version 3: (33 calls) null getattr setattr lookup access readlink 0 0% 5 15% 1 3% 4 12% 13 39% 0 0% read write create mkdir symlink mknod 0 0% 1 3% 1 3% 0 0% 0 0% 0 0% remove rmdir rename link readdir readdirplus 0 0% 0 0% 0 0% 0 0% 1 3% 0 0% fsstat fsinfo pathconf commit 3 9% 3 9% 0 0% 1 3% Server nfs_acl: Version 2: (0 calls) null getacl setacl getattr access 0 0% 0 0% 0 0% 0 0% 0 0% Version 3: (0 calls) null getacl setacl 0 0% 0 0% 0 0%
Для ускорения доступа к любой медленной файловой системе, такой, как удаленная система NFS или файловая система привода CD-ROM, может быть применено создание файловой системы кэша. Проще говоря, содержимое медленной файловой системы может быть закэшировано на локальном диске. Управление такой файловой системой кэша (cachefs) осуществляется утилитой cfsadmin.
Монтирование файловых систем NFS осуществляется очень похоже на
root@pxy# mount -t nfs 192.168.5.33:/nfst ./nfst root@pxy# mount /dev/hda1 on / type ext2 (rw) none on /proc type proc (rw) none on /dev/pts type devpts (rw,mode=0620) /dev/hda3 on /usr type ext2 (rw) /dev/hda2 on /var type ext2 (rw) 192.168.5.33:/nfst on /usr/home/filip/nfst type nfs (rw,addr=192.168.5.33)
mount.
Попробуем осуществить копирование файла:
root@pxy# cp /etc/mail/aliases /usr/home/filip/nfst/ root@pxy# ls /usr/home/filip/nfst/ aliases root@pxy# ls -l /usr/home/filip/nfst/ total 1 -rw-r--r-- 1 root root 406 Jun 20 22:30 aliases
Файл был записан, как видите, от имени пользователя root и группы root. На самом деле, в выводе команды ls таится подвох. Ведь команда ls на локальной машине использует для получения соответствия между идентификатором в файловой системе и именем пользователя (группы) локальный файл /etc/passwd. Потенциальная опасность состоит в том, что на удаленном сервере и на локальной машине файлы /etc/passwd окажутся разными. В случае пользователя root это не важно, если только на сервере NFS пользователю root нашей машины разрешено монтировать файловую систему от имени root. В противном случае все файлы, которые локальный root будет записывать на удаленный сервер, будут записываться от имени nobody (или иного имени, если так определено конфигурацией сервера).
root@pxy# ls -ld /usr/home/filip/nfst/ drwxrwxr-x 2 root bin 512 Jun 20 22:30 /usr/home/filip/nfst/
Коль скоро в нашем примере файл был записан от имени root, следует предположить, что настройки сервера NFS это позволяют. Проверим это на компьютере 192.168.5.33:
192.168.5.33# cat /etc/dfs/dfstab # Place share(1M) commands here for automatic execution # on entering init state 3. # # Issue the command '/etc/init.d/nfs.server start' to run the NFS # daemon processes and the share commands, after adding the very # first entry to this file. # # share [-F fstype] [ -o options] [-d "<text>"] <pathname> [resource] # .e.g, # share -F nfs -o rw=engineering -d "home dirs" /export/home2 share -F nfs -o root=pxy.spb.ru /nfst
Здесь, на компьютере 192.168.5.33, управляемом Solaris, разделяется общий каталог /nfst, а с компьютера pxy.spb.ru разрешено работать с этим каталогом от имени root. Следует осторожно раздавать подобные права и в большинстве случаев избегать разделения в сети каталогов с настроечной или секретной информацией.
По команде showmount можно получить список компьютеров, подключенных к серверу NFS:
192.168.5.33# showmount pxy.spb.ru www.spb.ru
Как видно, на сервере NFS имя /etc/group на сервере и на клиенте значатся разные группы. На практике следует избегать подобных расхождений, чтобы не возникало ситуаций, компроментирующих безопасность системы файлов. Синхронизация файлов passwd и group на сервере и клиентах или использование общей базы NIS помогут миновать путаницу в именах групп и владельцев файлов на сервере и клиенте NFS.
192.168.5.33# pwd /nfst 192.168.5.33# ls -l total 2 -rw-r--r-- 1 root root 406 Июн 20 22:30 aliases
Обратите внимание на одинаковое время создания файла с точки зрения команды ls сервера и клиента. В поле времени указывается время создания, которое записывает туда сервер NFS. Следует синхронизировать не только файлы group и passwd, но и время на сервере NFS и его клиентах, чтобы не было расхождений между клиентом и сервером при выполнении резервного копирования или выяснения "свежести" файлов.
Для оптимизации производительности NFS используется несколько средств. Во-первых, чем быстрее работают диски сервера NFS, тем быстрее информация сможет быть переданной через сеть. Современные сети часто строятся на основе высокоскоростных (как минимум, 100-мегабитных) коммутаторов, поэтому диски даже чаще оказываются узким местом в производительности, чем сеть. Если говорить об архитектуре x86, то предпочтительнее использовать в серверах современные жесткие диски с поддержкой UltraDMA-100, которые позволяют отдавать данные приложению с диска со скоростью порядка 50 Мб/с.
Во-вторых, применяется кэширование файлов на стороне сервера (поскольку любые операции чтения и записи кэшируются, имеет смысл увеличить объем памяти сервера NFS для того, чтобы кэш мог занимать больше памяти). Старайтесь избегать совмещения функций сервера NFS и сервера приложений, требовательного к объему памяти, типа сервера баз данных, на одном и том же компьютере.
В-третьих, может использоваться локальное кэширование посредством создания кэширующей файловой системы cachefs, как рассказано выше.
В SunOS 4.x для кэширования запросов к biod, но в SunOS 5.x (т.е. с самых ранних версий Solaris) применяется кэширование автоматическое всех операций чтения и записи, в том числе и для файлов, расположенных на удаленных серврах NFS. Поэтому в специальном процессе biod (в некоторых системах UNIX аналогичный по смыслу процесс называется nfsiod ) нет необходимости в Solaris.
| Версия SunOS | Версия Solaris |
|---|---|
| 4.x | 1.x |
| 5.6 | 2.6 |
| 5.7 | 7 |
| 5.8 | 8 |
| 5.9 | 9 |
| 5.10 | 10 |
Выполним еще один эксперимент: сервером NFS будет компьютер pxy (Linux), клиентом – компьютер под управлением Solaris. Все команды даются на компьютере-клиенте:
showmount -e ixy export list for ixy: /usr/home/filip/nfst (everyone)
Посмотрим, где можно создать подходящий пустой каталог, чтобы в него смонтировать удаленную файловую систему. Создадим каталог nfsc в корневом каталоге:
cd / ls devices lost+found opt TT_DB bin etc mnt platform tuition boot export named.run proc usr cdrom home net sbin var core kernel nfst test vol dev lib nsmail tmp xfn mkdir nfsc mount ixy:/usr/home/filip/nfst /nfsc
Проверим, получилось ли:
mount / on /dev/dsk/c0d0s0 read/write/setuid/intr/largefiles/xattr/ onerror=panic/dev=1980000 on Сбт Июл 3 18:59:13 2004 /boot on /dev/dsk/c0d0p0:boot read/write/setuid/nohidden/nofoldcase/ dev=19a3010 on Сбт Июл 3 18:59:11 2004 /proc on /proc read/write/setuid/dev=2d80000 on Сбт Июл 3 18:59:12 2004 /etc/mnttab on mnttab read/write/setuid/dev=2e40000 on Сбт Июл 3 18:59:12 2004 /dev/fd on fd read/write/setuid/dev=2e80000 on Сбт Июл 3 18:59:14 2004 /var/run on swap read/write/setuid/xattr/dev=1 on Сбт Июл 3 18:59:17 2004 /tmp on swap read/write/setuid/xattr/dev=2 on Сбт Июл 3 18:59:18 2004 /export/home on /dev/dsk/c0d0s7 read/write/setuid/intr/largefiles/xattr/ onerror=panic/dev=1980007 on Сбт Июл 3 18:59:18 2004 /nfsc on ixy:/usr/home/filip/nfst remote/read/write/setuid/xattr/ dev=2fc0002 on Сбт Июл 3 21:23:45 2004
Последняя строка вывода mount говорит о нашем успехе.
Попобуем копировать файл на сервер NFS:
cp /etc/dfs/dfstab /nfsc cp: cannot create /nfsc/dfstab: Read-only file system
Это говорит о том, что данная файловая система экспортируется сервером NFS только для чтения. Демонтирование
umount /nfsc
При экспорте файловых систем, если экспорт осуществляется компьютером под управлением Solaris, могут быть использованы параметры, указывающие, в каком режиме экспортируется файловая система. Подробнее об этих параметрах рассказывает руководство по dfstab(4) – см. man dfstab.
При монтировании файловых систем с сервера NFS клиентом под управлением Solaris могут быть применены другие параметры монтирования, указывающие уже клиенту, как именно следует смонтировать удаленную файловую систему.
Основные параметры монтирования приведены в табл. 7.4. Их следует указывать в файле /etc/dfs/dfstab в поле параметров монтирования (последнее поле строки dfstab ). Пример /etc/dfs/dfstab приведен выше в этой лекции, в разделе "Параметры экспорта в /etc/dfs/dfstab ".
| Параметр | Значение |
|---|---|
rw |
смонтировать в режиме чтения и записи (действует только если сервер экспортирует указанный каталог в режиме чтения и записи) |
ro |
смонтировать только для чтения |
hard |
если сервер станет недоступен, повторять обращение к файлу на |
soft |
если сервер станет недоступен, повторять обращение к файлу на retrans ; обычно приводит к ошибке приложения, обращающегося к недоступной файловой системе (подобно тому, как будет вести себя приложение при попытке чтения с неисправного жесткого диска, например) |
retrans=n |
количество повторений запроса до принятии решения об ошибке, см. soft, тайм-аут задается параметром timeo |
timeo=n |
n – тайм-аут между запросами в десятых долях секунды |
|
позволяет прервать (послать сигнал |
nointr |
не позволяет прерывать обращения к недоступной файловой системе |
proto=(tcp|udp) |
выбор протокола, по умолчанию – первый доступный из /etc/netconfig |
rsize=n |
размер буфера чтения в байтах |
wsize=n |
размер буфера записи в байтах |
Пример файла /etc/vfstab:
#device device mount FS fsck mount mount #to mount to fsck point type pass at boot option /proc - /proc proc - no - fd - /dev/fd fd - no - swap - /tmp tmpfs - yes - pxy.gu.ru:/exprt - /home nfs - yes rw,noquota
Сетевая файловая система (Network File System – NFS) служит для обеспечения доступа компьютерам сети к общим каталогам на сервере. Централизованное хранение файлов на сервере облегчает организацию работы в большой сети, особенно там, где один и тот же пользователь может работать в разное время на разных компьютерах. С помощью файлового сервера решается сразу несколько задач:
Служба NFS позволяет серверу обеспечить разделяемый доступ к указанным каталогам его локальной файловой системы, а клиенту – монтировать эти каталоги так же, как если бы они были локальными каталогами клиента.
NFS была разработана компанией Sun Microsystems и оказалась настолько удачной, что ее реализации были воплощены разными компаниями почти для всех операционных систем. Существует несколько принципиально разных реализаций NFS. Достаточно распространена версия NFS 2.0, хотя уже в Solaris 2.5 была введена NFS 3.0. В последующих версиях Solaris, включая Solaris 9, в NFS были внесены существенные дополнения, но сам протокол остался совместимым с реализацияим NFS 3.0 в других системах. Начиная с NFS 3.0, поддерживается передача пакетов посредством TCP и UDP, ранее поддерживался только UDP.
Будьте внимательны! В сети следует использовать клиентов и серверы NFS одной и той же версии. NFS 2.0 можно встретить в старых системах, например, в HP-UX 10.0. Совместная работа систем, использующих разные версии NFS, нежелательна.
NFS по смыслу и по организации работы похожа на
Служба NFS предполагает работу модели клиент-сервер, причем на компьютерах-клиентах и компьютерах-серверах запускаются разные программы для обеспечения доступа к общим каталогам на сервере.
Поскольку компьютеры на рабочих местах сотрудников в России обычно управляются Windows-системами, в качестве файловых серверов часто используются также Windows-системы. Однако, нередко возникает желание установить UNIX на файл-сервер, чтобы повысить надежность, сократить затраты на оборудование или использовать этот же сервер для ряда других корпоративных нужд: веб-сервера, сервера баз данных и т.п. Чтобы не устанавливать дополнительное ПО для поддержки NFS в таком случае, достаточно установить пакет samba на UNIX-машину. Он позволит ей "прикинуться" Windows NT сервером так, чтобы все клиентские компьютеры воспринимали его как самый обычный файл-сервер или принт-сервер Windows-сети. Пакет samba умеет обеспечивает поддержку "родного" для Windows-сетей протокола SMB.
В тех случаях, когда в сети работают несколько UNIX-компьютеров и им нужно обращаться к одному файл-серверу, имеет смысл использовать механизм NFS (network file system).
NFS не очень устойчив к сбоям сети, он требует ее бесперебойной работы и предполагает быстрое соединение между клиентом и сервером. Применение NFS для монтирования файловых систем вне локальной сети, например, через Интернет, технически осуществимо, но не очень рационально и небезопасно.
После настройки /etc/exports, но в Solaris он находится в другом файле – /etc/dfs/dfstab.
NFS работает посредством механизма удаленного вызова процедур (RPC – Remote Procedure Call).
Идеология RPC очень проста и привлекательна для программиста. Как обычно работает сетевое приложение? Оно следует некоему протоколу (например, HTTP): формирует пакет с запросом, вызывает системную функцию установления соединения, затем функцию отправки пакета, затем ждет ответного пакета и вызывает функцию закрытия соединения. Это значит, что вся работа с сетью является заботой программиста, который пишет приложение: он должен помнить о вызове функций сетевого API системы, думать о действиях в случае сбоев сети.
RPC предполагает иной способ обмена данными между клиентом и сервером. С точки зрения программиста, приложение клиента, работающее с помощью RPC, вызывает функцию на сервере, она выполняется и возвращает результат. Пересылка запроса на выполнение функции через сеть и возврат результатов от сервера клиенту происходит незаметно для приложения, поэтому последнее не должно беспокоиться ни о сбоях сети, ни о деталях реализации транспортного протокола.
Для того, чтобы обеспечить прозрачность пересылки данных через сеть, придумана двухступенчатая процедура. На сервере любое приложение, которое хочет предоставлять свой сервис через RPC, регистрируется в программе, которая называется транслятором портов (port mapper). Функция этой программы – устанавливать соответствие между номером процедуры RPC, которую запросил клиент, и номером TCP или UDP порта, на котором приложение сервера ждет запросов. Вообще говоря, RPC может работать не только с TCP или UDP, в Solaris как раз реализована работа на базе механизма TI (Transport-Independent), поэтому в Solaris транслятор портов называется rpcbind, а не portmap, как в Linux или FreeBSD.
Приложение, которое регистрируется у транслятора портов, сообщает ему номер программы, номер версии и номера процедур, которые могут обрабатываться данной программой. Эти процедуры будут впоследствии вызываться клиентом по номеру. Кроме этого, приложение сообщает номера портов TCP и UDP, которые будут использоваться для приема запросов на выполнение процедур.
Клиент, желающий вызвать выполнение процедуры на сервер, сначала отправляет запрос транслятору портов на сервер, чтобы узнать, на какой TCP или UDP порт надо отправить запрос. Транслятор портов запускается при старте системы и всегда работает на стандартном порте 111. Получив ответ от него, клиент отправляет запрос на тот порт, который соответствует требуемому приложению. Например, сервер NFS работает на порту 2049.
Прежде чем мы перейдем к описанию настроек сервера и клиентов NFS, следует понять, как осуществляется монтирование удаленных файловых систем в принципе.
Клиент NFS посылает запрос на монтирование удаленному компьютеру, который предоставляет свою файловую систему (обычно – некоторую ее часть) для общего пользователя. При этом говорят, что сервер NFS "экспортирует" тот или иной каталог (подразумевается – с подкаталогами). Запрос от клиента NFS попадает на обработку демону mountd. Тот выдает клиенту NFS специальный ключ. Этот ключ является идентификатором, который однозначно идентифицирует каталог, смонтированный по сети.
По NFS можно смонтировать как целые файловые системы, так и отдельные каталоги. Из соображений безопасности запрещено монтировать каталоги "через раздел". Это означает, что если каталог /var расположен на одном разделе диска, а каталог /var/adm – на другом, то при монтировании каталога /var каталог /var/adm не будет автоматически смонтирован. Если требуется монтировать те подкаталоги экспортируемого каталога, которые расположены в другой файловой системе (на другом разделе), следует экспортировать их отдельно и указывать в /etc/dfs/dfstab еще один разделяемый каталог – тот самый подкаталог с другого раздела.
Ключ, выданный клиенту при монтировании и идентифицирующий сеанс работы с данным удаленным каталогом, сохраняется при перезагрузке
После nfsd.
Демонтирование файловой системы выполняется также, как и демонтирование любой другой файловой системы – командой umount.
Ниже будут обсуждены следующие аспекты настройки службы клиент-сервер в сети:
Для настройки NFS сервера нам потребуется выполнить настройку как минимум трех приложений: rpcbind, mountd и nfsd. Прежде всего, создадим файл /etc/dfs/dfstab, в котором опишем экспортируемые каталоги; в отличие от других систем UNIX, Solaris требует указать здесь не просто список каталогов с параметрами монтирования, а набор команд share, которые фактически и запускают экспорт каталогов. Таким образом, получается, что /etc/dfs/dfstab – это скрипт, который выполняется для того, чтобы сделать общие каталоги доступными для монтирования через сеть.
Для начала следует запустить программу rpcbind, если она еще не запущена. Скорее всего, она запускается при старте вашей системы, если это действительно Solaris. Эта программа, как мы помним, преобразует номера вызовов процедур RPC в номера портов TCP и UDP. При запуске любого RPC-сервера, т.е. программы, работающей с протоколом RPC, программа rpcbind получает от этого RPC-сервера информацию о том, какие номера процедур RPC он намерен обслуживать и через какой порт TCP (UDP) ему следует направлять запросы.
Когда клиент деалет RPC-вызов, сперва происходит выяснение требуемого номера порта на машине сервера у rpcbind.
Поэтому rpcbind должен быть запущен до того, как будет запущен любой из RPC-серверов. При аварийном завершении rpcbind необходимо вначале перезапустить rpcbind, и затем перезапустить все RPC-серверы.
Для проверки готовности всех служб NFS к работе через rpcbind используется команда rpcinfo -p:
rpcinfo -p program vers proto port service 100000 4 tcp 111 rpcbind 100000 3 tcp 111 rpcbind 100000 2 tcp 111 rpcbind 100000 4 udp 111 rpcbind 100000 3 udp 111 rpcbind 100000 2 udp 111 rpcbind 100232 10 udp 32772 sadmind 100083 1 tcp 32771 100221 1 tcp 32772 100068 2 udp 32773 100068 3 udp 32773 100068 4 udp 32773 100068 5 udp 32773 100229 1 tcp 32773 metad 100230 1 tcp 32774 metamhd 100242 1 tcp 32775 metamedd 100001 2 udp 32774 rstatd 100001 3 udp 32774 rstatd 100001 4 udp 32774 rstatd 100002 2 udp 32775 rusersd 100002 3 udp 32775 rusersd 100002 2 tcp 32776 rusersd 100002 3 tcp 32776 rusersd 100008 1 udp 32776 walld 100012 1 udp 32777 sprayd 100011 1 udp 32778 rquotad 100024 1 udp 32779 status 100024 1 tcp 32777 status 100133 1 udp 32779 100133 1 tcp 32777 100021 1 udp 4045 nlockmgr 100021 2 udp 4045 nlockmgr 100021 3 udp 4045 nlockmgr 100021 4 udp 4045 nlockmgr 100021 1 tcp 4045 nlockmgr 100021 2 tcp 4045 nlockmgr 100021 3 tcp 4045 nlockmgr 100021 4 tcp 4045 nlockmgr 300598 1 udp 32784 300598 1 tcp 32781 805306368 1 udp 32784 805306368 1 tcp 32781 100249 1 udp 32785 100249 1 tcp 32782 1289637086 5 tcp 32787 1289637086 1 tcp 32787 100005 1 udp 32814 mountd 100005 2 udp 32814 mountd 100005 3 udp 32814 mountd 100005 1 tcp 33201 mountd 100005 2 tcp 33201 mountd 100005 3 tcp 33201 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100227 2 udp 2049 nfs_acl 100227 3 udp 2049 nfs_acl 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100227 2 tcp 2049 nfs_acl 100227 3 tcp 2049 nfs_acl
При запуске системы в многопользовательском режиме 3 rpcbind запускается автоматически, а службы NFS – в случае, если существует файл /etc/dfs/dfstab.
Сервис NFS предоставляется двумя программами, которые обрабатывают соответствующие RPC-запросы. Это программы mountd и nfsd.
Программа mountd обрабатывает запросы на удаленное монтирование файловых систем. Для получения списка экспортируемых каталогов применяют команду showmount –e, которая обращается к mountd за информацией:
showmount -e export list for sunny: /nfst (everyone)
Для того, чтобы на сервере NFS узнать, какие системы подсоединили к себе showmount без параметров:
showmount www.eu.spb.ru
Программа nfsd – это обработчик файлового
Параметры службы NFS настраиваются в файле /etc/default/nfs, а запуск и остановка службы осуществляется, соответственно, командами
/etc/init.d/nfs.server start
и
/etc/init.d/nfs.server stop
В Solaris 10 служба NFS запускается и останавливается также, как и другие службы – командой svcadm enable nfs/server и svcadm disable nfs/server соответственно. О новом механизме работы со службами, появившемся в Solaris 10, более подробно рассказано в лекции 13.
В файле /etc/default/nfs следует указать достаточное количество потоков, которые можно параллельно запускать для обслуживания одновременных запросов к файлам через NFS. За это отвечает параметр NFSD_SERVERS.
Значение этого параметра не должно быть меньшим максимального количества одновременных обращений к разделяемым файловым системам NFS на сервере. Слишком маленькое число потоков вызовет задержки в работе клиентов, поскольку им придется становиться в очередь на обработку запросов. В то же время, излишне большое число приведет к нерациональному расходу памяти
Если из-за слишком большого количества потоков nfsd загрузка процессора возрастет до 100%, имеет смысл уменьшить число этих потоков. С одной стороны, идеально иметь 2 потока на каждого активного клиента, постоянно обращающегося к ресурсам NFS, с другой – на один процессор рекомендуется запускать не более 16 потоков, если это достаточно медленный процессор типа тех, что установлены в системах SPARCstation 5, и не более.
В моей тестовой системе Solaris на компьютере x86 монтирование каталога сервера одним клиентом NFS привело к увеличению занимаемой nfsd памяти всего на 8 Кб, так что в современных системах имеет смысл ожидать скорее некоторого снижения производительности за счет нагрузки на процессор или кэширования больших файлов экспортируемых каталогов, чем нехватки памяти из-за слишком большого количества потоков nfsd.
Перед запуском mountd и nfsd следует убедиться, что в /etc/dfs/dfstab указаны все каталоги, которые вы собираетесь экспортировать, а также разумно настроены параметры безопасности.
Работа с общим диском, разделяемым между многими пользователями сети, предполагает, что в пределах сети существует общее пространство имен пользователей, т.е. пользователь gregory на любом клиентском (в терминах NFS) компьютере имеет то же реальное имя и (что важнее) тот же идентификатор, что и пользователь gregory на сервере NFS. Это достигается использованием централизованной аутентификации (например, с помощью PAM и сервера аутентификации или с помощью NIS+). Кроме этого, важно ограничить права пользователя root при доступе через NFS, т.к. пользователь root на любом компьютере в любой системе UNIX имеет идентификатор 0, но от имени пользователя root на разных компьютерах могут работать разные люди.
Для ограничения доступа пользователя root на сервере NFS любые файловые запросы от имени пользователей root клиентских компьютеров выполняются от имени nobody. Можно указать, пользователям root каких компьютеров мы предоставляем привилегированный доступ от имени root и через NFS.
По умолчанию файловая система экспортируется с правами чтения и записи для тех, кто ее смонтирует. Однако, права доступа к конкретным каталогам могут запрещать запись в них; фактически права доступа к
Рассмотрим для примера файл /etc/dfs/dfstab системы Solaris:
share -F nfs -o rw=@212.231.110, ro=@192.168.4 /home share -F nfs -o ro=212.231.110@,root=212.231.110.112 /usr/share/man
Файловая система /home экспортируется с возможностью чтения и записи для компьютеров сети 212.231.110, и только чтения – для компьютеров сети 192.168.4. Файловая система /usr/share/man экспортируется для чтения для компьютеров сети 212.231.110. Пользователю root с компьютера 212.231.110.112 разрешен доступ с правами суперпользователя к этой файловой системе.
Полный список доступных режимов и настроек при указании экспортируемой файловой системы доступен в man share и man share_nfs, а некоторые из них обсуждаются ниже, в разделе "параметры экспорта в /etc/dfs/dfstab ".
Для бездисковых станций через сеть с помощью NFS экспортируются все файловые системы, которые им нужны, и даже область свопинга. Поэтому, настраивая экспорт файловой системы для бездисковых станций следует убедиться, что для них экспортируется корневая файловая система и область свопинга.
Под "корневой файловой системой" мы здесь понимаем определенный заранее каталог на сервере NFS, играющий роль корневой файловой системы для бездисковой станции. Собственный корневой каталог сервера не следует экспортировать вообще.
Файловые системы бездисковых рабочих станций монтируются из отдельного каталога сервера (в наших примерах мы будем использовать каталог /exports, но можно задействовать и любой другой каталог) и по составу файлов аналогичны файловым системам автономных компьютеров, оснащенных дисками.
Табл. 7.1 демонстрирует соответствие экспортируемых на
Обычным пользователям сервера доступ к каталогу /export, как правило, запрещают, ибо этот каталог предназначен только для монтирования его клиентами, и управление этим каталогом осуществляет администратор, работая от имени root.
Каталог /export/root следует экспортировать с правами пользователей на чтение и запись.
Параметр nosuid запрещает клиентам устанавливать бит root клиента или пользователю, чей uid совпадает с uid наделенного большими правами пользователя в какой-либо из систем сети (особенно – сервера NFS).
Вместо того, чтобы использовать при монтировании каталога /export/root параметр nosuid, может быть достаточно запретить пользователям сервера NFS доступ к этому каталогу.
Параметр ro обеспечивает монтирование каталога только для чтения для всех клиентов. Например, каталог с системными исполняемыми файлами пользователям менять незачем, и его рекомендуется экспортировать только для чтения.
| Экспортируемые каталоги на сервере | Импортируемые каталоги на бездисковом компьютере | Пояснение | Параметры монтирования |
|---|---|---|---|
| /export/root/<hostname> | / | Корневой каталог | -o nosuid |
| /export/exec/<platformname> | /usr | Каталог выполняемых файлов (Shared Product Object Tree – SPOT) Содержимое этого каталога зависит от аппаратной платформы, разным платформам должны монтироваться разные каталоги | -o ro |
| /export/home/<hostname> | /home | возможно, потребуется -o nosuid |
|
| /export/share | /usr/share | -o ro |
|
| /export/swap/<hostname> | Применяется на бездисковых клиентах в качестве удаленного пространства подкачки |
При экспорте каталога /export/home можно пойти двумя путями:
/home сервера, так, чтобы дать возможность пользователям работать на сервере интерактивно в своем домашнем каталоге и монтировать этот же каталог по сети при работе на других компьютерах;/export/home сервера с тем, чтобы пользователи на сервере не имели домашних каталогов (или же, что менее удобно, имели разные домашние каталоги при работе на сервере и при работе на остальных компьютерах сети).В первом случае следует обязательно указать параметр nosuid для монтирования этого каталога через NFS.
Теперь вы должны проверить, что mountd и nfsd запущены правильно. Сначала это делается с помощью команды rpcinfo -p. Вывод программы должен показать что-то похожее на следующее:
100000 4 tcp 111 rpcbind 100000 3 tcp 111 rpcbind 100000 2 tcp 111 rpcbind 100000 4 udp 111 rpcbind 100000 3 udp 111 rpcbind 100000 2 udp 111 rpcbind 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100005 3 udp 1023 mountd 100005 3 tcp 1023 mountd 100005 1 udp 1023 mountd 100005 1 tcp 1023 mountd
Как видно, rpcbind успешно анонсирует службы.
Если в ответ на rpcinfo -p мы получили сообщение
rpcinfo: can't contact rpcbind: RPC: Remote system error - Connection refused
или
RPC_PROG_NOT_REGISTERED
или нечто похожее вместо ожидаемого – стало быть, rpcbind не доступен (отключен). Возможно, в файлах /etc/hosts.allow или /etc/hosts.deny есть настройки, запрещающие программе rpcbind отвечать нам.
Для перезапуска служб NFS можно завершить выполнение демонов nfsd, mountd и rpcbind, запустить их вновь в следующем порядке: rpcbind, затем mountd и следом nfsd. Программе nfsd может быть передан числовой аргумент – число потоков, которые следует запустить при старте. Программа "распараллелится" в указанном количестве потоков.
Более стандартным выходом является запуск скрипта /etc/init.d/nfs.server вначале с параметром stop, затем с параметром start.
При штатной работе mountd и nfsd запускаются на сервере NFS при старте системы из стартовых скриптов. Это можно проверить командами
ps -ef | grep mountd ps -ef | grep nfsd
Программа rpcbind объявляет свои службы независимо от того, продолжают ли работать программы, ранее зарегистрировавшиеся и (возможно) прекратившие работу вследствие аварии.
Следовательно, вышеприведенная проверка с помощью ps обязательна, если служба NFS перестала работать.
Не забудьте перед настройкой сервера NFS изучить страницы руководства, рассказывающие о rpcbind, mountd, nfsd, dfstab.
Для того, чтобы несколько процессов не конфликтовали при доступе к одному и тому же файлу, обычно используется механизм блокировки файла. Подробнее о блокировках следует читать в документации по системным фукнциям lockf() и flock(). В NFS механизм блокировки реализован посредством двух демонов: lockd и statd.
Оба демона запускаются на сервере NFS после mountd и nfsd.
Программа lockd устанавливает и снимает блокировку файлов по запросу, а демон statd следит за состоянием блокировок и работоспособностью
В сети демон statd сервера NFS обменивается информацией с демонами statd на других компьютерах. Демон lockd посылает запросы демону statd для установления статуса компьютеров. взаимодействующих с ним.
Если компьютер, за которым следит statd, перестает отвечать и перезапускается, удаленный statd сообщает об этом локальному, следящему за ним, и локальный демон информирует об этом программы, которые работали через это соединение. Если прекращает работу локальный сервис и затем следует его перезапуск, то statd информирует об этом другие компьютеры.
Если на сервере NFS установлены дисковые квоты для отдельных пользователей, то для того, чтобы пользователь "издалека" мог узнать свою дисковую квоту, запускается демон rquotad.
Вообще говоря, установка дисковых квот (независимо от NFS) выполняется следующим образом:
/etc/vfstab для файловой системы, для которой будет применяться квотирование, устанавливается параметр монтирования quota. Не забудьте демонтировать и снова смонтировать соответствующую файловую систему, если хотите, чтобы параметр оказал воздействие на работу файловой системы немедленно!quotas в корне этой файловой системы (например, если речь идет о файловой системе /export/home, то файл будет называться /export/home/quotas );edquota устанавливаются квоты для каждого из пользователей в отдельности;quotaon.Для выключения поддержки квот достаточно выполнить команду
quotaoff
Для проверки квот в файловых системах надо выполнить команду
quota username
В Solaris NFS организован иначе, нежели в других системах UNIX, и это следует иметь в виду при настройке систем в гетерогенных сетях:
/etc/dfs/dfstab в других системах называется /etc/exports ;/etc/exports является файлом конфигурации, а не скриптом, вызывающим программу share ;/etc/dfs/dfstab нужно дать команду shareall для вступления изменений в силу; в других системах следует перезапустить mountd и nfsd, обычно для этого можно использовать сценарий, как и в Solaris;/etc/dfs/dfstab указаны экспортированнные каталоги.Помните, что команда shareall просто выполняет подряд все команды share, содержащиеся в файле /etc/dfs/dfstab. Если этот файл был модифицирован и некоторые команды экспорта каких-то файловых систем были удалены, действие старых команд share, запущенных до модификации файла, продолжится и после выполнения shareall.
Поэтому следует перезапустить mountd для того, чтобы изменения возымели эффект. Внимание: нельзя перезапускать mountd, когда пользователи работают с файловой системой сервера NFS: это может вызвать потери данных и зависание систем – клиентов NFS.
Если требуется ограничить доступ к разделяемой файловой системе только определенной группой машин, следует указать их список команде share:
share -F nfs -o rw=host1:host2 /home/host12
При экспорте файловых систем можно передавать командам share ряд параметров, указывающих, в каком режиме следует экспортировать те или иные каталоги. Наиболее важные параметры сведены в табл. 7.2:
Например, файл /etc/dfs/dfstab может иметь такой вид для экспорта двух файловых систем:
share -F nfs -o rw=@212.231.110, ro=@192.168.4 /home share -F nfs -o ro=212.231.110@,root=212.231.110.112 /usr/share/man
| Параметр | Значение |
|---|---|
ro |
только для чтения – для всех |
ro=host1, host2 |
только для чтения и только указанным компьютерам |
rw |
для чтения и записи – для всех |
rw=host1, host2 |
для чтения и записи, но только указанным компьютерам |
root=host1, host2 |
с указанных компьютеров пользователь root получает доступ к файлам на сервере NFS от имени root (иначе – от имени nobody или указанного в параметре anon) |
anon=uid |
идентификатор пользователя, от имени которого сможет работать с файлами на сервере NFS пользователь root удаленного (клиентского) компьютера, по умолчанию – nobody |
nosub |
запрещается монтировать подкаталоги экспортируемого каталога |
nosuid |
запрещается создавать в экспортируемой файловой системе файлы с установленными битами suid и sgid |
В Solaris 9 были добавлены некоторые расширения поддержки NFS, которые улучшили ее производительность:
forcedirectio при directio(). По умолчанию (без указания параметра при монтировании) запись в файл производится так же, как и раньшеДля получения статистики о работе сервера NFS следует использовать команду nfsstat на таком сервере:
nfsstat -s Server rpc: Connection oriented: calls badcalls nullrecv badlen xdrcall dupchecks 0 0 0 0 0 0 dupreqs 0 Connectionless: calls badcalls nullrecv badlen xdrcall dupchecks 33 0 0 0 0 3 dupreqs 0 Server nfs: calls badcalls 33 0 Version 2: (0 calls) null getattr setattr root lookup readlink 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% read wrcache write create remove rename 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% link symlink mkdir rmdir readdir statfs 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% Version 3: (33 calls) null getattr setattr lookup access readlink 0 0% 5 15% 1 3% 4 12% 13 39% 0 0% read write create mkdir symlink mknod 0 0% 1 3% 1 3% 0 0% 0 0% 0 0% remove rmdir rename link readdir readdirplus 0 0% 0 0% 0 0% 0 0% 1 3% 0 0% fsstat fsinfo pathconf commit 3 9% 3 9% 0 0% 1 3% Server nfs_acl: Version 2: (0 calls) null getacl setacl getattr access 0 0% 0 0% 0 0% 0 0% 0 0% Version 3: (0 calls) null getacl setacl 0 0% 0 0% 0 0%
Для ускорения доступа к любой медленной файловой системе, такой, как удаленная система NFS или файловая система привода CD-ROM, может быть применено создание файловой системы кэша. Проще говоря, содержимое медленной файловой системы может быть закэшировано на локальном диске. Управление такой файловой системой кэша (cachefs) осуществляется утилитой cfsadmin.
Монтирование файловых систем NFS осуществляется очень похоже на
root@pxy# mount -t nfs 192.168.5.33:/nfst ./nfst root@pxy# mount /dev/hda1 on / type ext2 (rw) none on /proc type proc (rw) none on /dev/pts type devpts (rw,mode=0620) /dev/hda3 on /usr type ext2 (rw) /dev/hda2 on /var type ext2 (rw) 192.168.5.33:/nfst on /usr/home/filip/nfst type nfs (rw,addr=192.168.5.33)
mount.
Попробуем осуществить копирование файла:
root@pxy# cp /etc/mail/aliases /usr/home/filip/nfst/ root@pxy# ls /usr/home/filip/nfst/ aliases root@pxy# ls -l /usr/home/filip/nfst/ total 1 -rw-r--r-- 1 root root 406 Jun 20 22:30 aliases
Файл был записан, как видите, от имени пользователя root и группы root. На самом деле, в выводе команды ls таится подвох. Ведь команда ls на локальной машине использует для получения соответствия между идентификатором в файловой системе и именем пользователя (группы) локальный файл /etc/passwd. Потенциальная опасность состоит в том, что на удаленном сервере и на локальной машине файлы /etc/passwd окажутся разными. В случае пользователя root это не важно, если только на сервере NFS пользователю root нашей машины разрешено монтировать файловую систему от имени root. В противном случае все файлы, которые локальный root будет записывать на удаленный сервер, будут записываться от имени nobody (или иного имени, если так определено конфигурацией сервера).
root@pxy# ls -ld /usr/home/filip/nfst/ drwxrwxr-x 2 root bin 512 Jun 20 22:30 /usr/home/filip/nfst/
Коль скоро в нашем примере файл был записан от имени root, следует предположить, что настройки сервера NFS это позволяют. Проверим это на компьютере 192.168.5.33:
192.168.5.33# cat /etc/dfs/dfstab # Place share(1M) commands here for automatic execution # on entering init state 3. # # Issue the command '/etc/init.d/nfs.server start' to run the NFS # daemon processes and the share commands, after adding the very # first entry to this file. # # share [-F fstype] [ -o options] [-d "<text>"] <pathname> [resource] # .e.g, # share -F nfs -o rw=engineering -d "home dirs" /export/home2 share -F nfs -o root=pxy.spb.ru /nfst
Здесь, на компьютере 192.168.5.33, управляемом Solaris, разделяется общий каталог /nfst, а с компьютера pxy.spb.ru разрешено работать с этим каталогом от имени root. Следует осторожно раздавать подобные права и в большинстве случаев избегать разделения в сети каталогов с настроечной или секретной информацией.
По команде showmount можно получить список компьютеров, подключенных к серверу NFS:
192.168.5.33# showmount pxy.spb.ru www.spb.ru
Как видно, на сервере NFS имя /etc/group на сервере и на клиенте значатся разные группы. На практике следует избегать подобных расхождений, чтобы не возникало ситуаций, компроментирующих безопасность системы файлов. Синхронизация файлов passwd и group на сервере и клиентах или использование общей базы NIS помогут миновать путаницу в именах групп и владельцев файлов на сервере и клиенте NFS.
192.168.5.33# pwd /nfst 192.168.5.33# ls -l total 2 -rw-r--r-- 1 root root 406 Июн 20 22:30 aliases
Обратите внимание на одинаковое время создания файла с точки зрения команды ls сервера и клиента. В поле времени указывается время создания, которое записывает туда сервер NFS. Следует синхронизировать не только файлы group и passwd, но и время на сервере NFS и его клиентах, чтобы не было расхождений между клиентом и сервером при выполнении резервного копирования или выяснения "свежести" файлов.
Для оптимизации производительности NFS используется несколько средств. Во-первых, чем быстрее работают диски сервера NFS, тем быстрее информация сможет быть переданной через сеть. Современные сети часто строятся на основе высокоскоростных (как минимум, 100-мегабитных) коммутаторов, поэтому диски даже чаще оказываются узким местом в производительности, чем сеть. Если говорить об архитектуре x86, то предпочтительнее использовать в серверах современные жесткие диски с поддержкой UltraDMA-100, которые позволяют отдавать данные приложению с диска со скоростью порядка 50 Мб/с.
Во-вторых, применяется кэширование файлов на стороне сервера (поскольку любые операции чтения и записи кэшируются, имеет смысл увеличить объем памяти сервера NFS для того, чтобы кэш мог занимать больше памяти). Старайтесь избегать совмещения функций сервера NFS и сервера приложений, требовательного к объему памяти, типа сервера баз данных, на одном и том же компьютере.
В-третьих, может использоваться локальное кэширование посредством создания кэширующей файловой системы cachefs, как рассказано выше.
В SunOS 4.x для кэширования запросов к biod, но в SunOS 5.x (т.е. с самых ранних версий Solaris) применяется кэширование автоматическое всех операций чтения и записи, в том числе и для файлов, расположенных на удаленных серврах NFS. Поэтому в специальном процессе biod (в некоторых системах UNIX аналогичный по смыслу процесс называется nfsiod ) нет необходимости в Solaris.
| Версия SunOS | Версия Solaris |
|---|---|
| 4.x | 1.x |
| 5.6 | 2.6 |
| 5.7 | 7 |
| 5.8 | 8 |
| 5.9 | 9 |
| 5.10 | 10 |
Выполним еще один эксперимент: сервером NFS будет компьютер pxy (Linux), клиентом – компьютер под управлением Solaris. Все команды даются на компьютере-клиенте:
showmount -e ixy export list for ixy: /usr/home/filip/nfst (everyone)
Посмотрим, где можно создать подходящий пустой каталог, чтобы в него смонтировать удаленную файловую систему. Создадим каталог nfsc в корневом каталоге:
cd / ls devices lost+found opt TT_DB bin etc mnt platform tuition boot export named.run proc usr cdrom home net sbin var core kernel nfst test vol dev lib nsmail tmp xfn mkdir nfsc mount ixy:/usr/home/filip/nfst /nfsc
Проверим, получилось ли:
mount / on /dev/dsk/c0d0s0 read/write/setuid/intr/largefiles/xattr/ onerror=panic/dev=1980000 on Сбт Июл 3 18:59:13 2004 /boot on /dev/dsk/c0d0p0:boot read/write/setuid/nohidden/nofoldcase/ dev=19a3010 on Сбт Июл 3 18:59:11 2004 /proc on /proc read/write/setuid/dev=2d80000 on Сбт Июл 3 18:59:12 2004 /etc/mnttab on mnttab read/write/setuid/dev=2e40000 on Сбт Июл 3 18:59:12 2004 /dev/fd on fd read/write/setuid/dev=2e80000 on Сбт Июл 3 18:59:14 2004 /var/run on swap read/write/setuid/xattr/dev=1 on Сбт Июл 3 18:59:17 2004 /tmp on swap read/write/setuid/xattr/dev=2 on Сбт Июл 3 18:59:18 2004 /export/home on /dev/dsk/c0d0s7 read/write/setuid/intr/largefiles/xattr/ onerror=panic/dev=1980007 on Сбт Июл 3 18:59:18 2004 /nfsc on ixy:/usr/home/filip/nfst remote/read/write/setuid/xattr/ dev=2fc0002 on Сбт Июл 3 21:23:45 2004
Последняя строка вывода mount говорит о нашем успехе.
Попобуем копировать файл на сервер NFS:
cp /etc/dfs/dfstab /nfsc cp: cannot create /nfsc/dfstab: Read-only file system
Это говорит о том, что данная файловая система экспортируется сервером NFS только для чтения. Демонтирование
umount /nfsc
При экспорте файловых систем, если экспорт осуществляется компьютером под управлением Solaris, могут быть использованы параметры, указывающие, в каком режиме экспортируется файловая система. Подробнее об этих параметрах рассказывает руководство по dfstab(4) – см. man dfstab.
При монтировании файловых систем с сервера NFS клиентом под управлением Solaris могут быть применены другие параметры монтирования, указывающие уже клиенту, как именно следует смонтировать удаленную файловую систему.
Основные параметры монтирования приведены в табл. 7.4. Их следует указывать в файле /etc/dfs/dfstab в поле параметров монтирования (последнее поле строки dfstab ). Пример /etc/dfs/dfstab приведен выше в этой лекции, в разделе "Параметры экспорта в /etc/dfs/dfstab ".
| Параметр | Значение |
|---|---|
rw |
смонтировать в режиме чтения и записи (действует только если сервер экспортирует указанный каталог в режиме чтения и записи) |
ro |
смонтировать только для чтения |
hard |
если сервер станет недоступен, повторять обращение к файлу на |
soft |
если сервер станет недоступен, повторять обращение к файлу на retrans ; обычно приводит к ошибке приложения, обращающегося к недоступной файловой системе (подобно тому, как будет вести себя приложение при попытке чтения с неисправного жесткого диска, например) |
retrans=n |
количество повторений запроса до принятии решения об ошибке, см. soft, тайм-аут задается параметром timeo |
timeo=n |
n – тайм-аут между запросами в десятых долях секунды |
|
позволяет прервать (послать сигнал |
nointr |
не позволяет прерывать обращения к недоступной файловой системе |
proto=(tcp|udp) |
выбор протокола, по умолчанию – первый доступный из /etc/netconfig |
rsize=n |
размер буфера чтения в байтах |
wsize=n |
размер буфера записи в байтах |
Пример файла /etc/vfstab:
#device device mount FS fsck mount mount #to mount to fsck point type pass at boot option /proc - /proc proc - no - fd - /dev/fd fd - no - swap - /tmp tmpfs - yes - pxy.gu.ru:/exprt - /home nfs - yes rw,noquota
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.