Для раздачи файлов внутри локальной сети можно выделить такие технологии (рассматриваются системы на базе Linux):

• Network File System (NFS) - протокол сетевого доступа к файловым системам;
• Files transferred over Shell protocol (FISH) - сетевой протокол, который использует или RSH для передачи файлов между компьютерами;
• Secure SHell FileSystem (SSHFS) - клиент файловой системы для монтирования дисковых устройств на удаленных системах, для взаимодействия с удаленной системой используется SFTP ;
• Samba - пакет программ, которые позволяют обращаться к сетевым дискам и принтерам на различных операционных системах по протоколу SMB/CIFS;

В данной заметке речь пойдет про NFS .

NFS (Network File System) полезна когда нужно раздать файлы/директории всем внутри сети. Прозрачность доступа с помощью NFS позволяет клиентам подключить удаленную файловую систему как локальную директорию, причем файловые системы могут быть разных типов. Это означает, что любое приложение клиента, которое может работать с локальным файлом, с таким же успехом может работать и с файлом подключенным по NFS , без каких либо модификаций самой программы.

К преимуществам NFS можно отнести:

На данный момент доступна NFS v4.1 , в которой ввели новую возможность pNFS позволяющей распараллелить реализацию общего доступа к файлам. Также есть расширение для NFS 2 и 3 - WebNFS , которое позволяют легче интегрироваться в веб-браузеры и дает возможность работать через брандмауэр.

Схема работы NFS протокола.

Установка и настройка NFS-сервер под Linux

Проверим поддерживает ли система NFS

Cat /proc/filesystems | grep nfs

Под Arch Linux сервер и клиент находиться в одном пакете

Yaourt -S nfs-utils

Для установки сервера (nfs-kernel-server ) и клиента (nfs-common ) под Ubuntu необходимы пакеты

Sudo apt-get install nfs-kernel-server nfs-common portmap

Дальше в заметке для сервера будет использоваться IP 192.168.1.100 . Для того что бы за сервером всегда был закреплен один и тот же IP необходимо в DHCP-сервере (чаще всего роутер) указать раздачу конкретного IP конкретному MAC-адресу. Или поднять свой локальный DNS-сервер. Например или .

MAC-адрес можно узнать с помощью ifconfig (поле ether в Arch Linux ).

NFSv4 предполагает что есть корневая директория, внутри которой уже расположены файлы для раздачи. Например, /srv/nfs - корень, /srv/nfs/audio - директория для раздачи музыки. Если не следовать этому новому указанию в версии 4 , то можно получить ошибку при подключении клиентом:

Mount.nfs: access denied by server while mounting 192.168.1.100:/home/proft/torrents

Если все же хочется использовать на сервере подход без корневой-директории для NFS , то при монтировании клиентом надо явно указать версию 3

# для команды mount mount -o "vers=3" 192.168.1.100:/home/proft/torrents /home/proft/nfs/torrents # для fstab 192.168.1.100:/home/proft/torrents /home/proft/nfs/torrents nfs soft,nfsvers=3 0 0

Я буду использовать NFSv4 с root-директорией в /srv/nfs/ и монтированием вложенных директорий с помощью mount --bind .

Предположим, что мы хотим

• раздавать директорию ~/torrents с rw доступом для всех внутри локальной сети;
• раздавать директорию ~/photos с ro доступом для хоста с IP 192.168.1.101 ;

Для начала создадим корневую директорию и необходимые вложенные.

Sudo mkdir -p /srv/nfs/{torrents,photos}

Примонтируем существующие директории torrents, photos в /srv/nfs .

# sudo vim /etc/fstab /home/proft/torrents /srv/nfs/torrents none bind 0 0 /home/proft/photos /srv/nfs/photos none bind 0 0

Отредактируем /etc/exports , в котором описываются все директории для совместного доступа

# sudo vim /etc/exports # формат файла: directory allowed-hosts(options) /srv/nfs/torrents 192.168.1.1/24(rw,async) /srv/nfs/photos 192.168.1.101(ro,async)

Обратите внимание на отсутствие пробела между allowed-hosts и (options) . Наличие пробела вводит другую трактовку правил.

Доступные опции:

• ro (rw) - разрешить доступ только на чтение (чтение/запись);
• subtree_check (no_subtree_check) - в некоторых случаях приходится экспортировать не весь раздел, а лишь его часть. При этом сервер NFS должен выполнять дополнительную проверку обращений клиентов, чтобы убедиться в том, что они предпринимают попытку доступа лишь к файлам, находящимся в соответствующих подкаталогах. Такой контроль поддерева (subtree checks ) несколько замедляет взаимодействие с клиентами, но если отказаться от него, могут возникнуть проблемы с безопасностью системы. Отменить контроль поддерева можно с помощью опции no_subtree_check . Опция subtree_check , включающая такой контроль, предполагается по умолчанию. Контроль поддерева можно не выполнять в том случае, если экспортируемый каталог совпадает с разделом диска;
• sync (async) - указывает, что сервер должен отвечать на запросы только после записи на диск изменений, выполненных этими запросами. Опция async указывает серверу не ждать записи информации на диск, что повышает производительность, но понижает надежность, т.к. в случае обрыва соединения или отказа оборудования возможна потеря данных;
• noaccess - запрещает доступ к указанной директории. Может быть полезной, если перед этим был задан доступ всем пользователям сети к определенной директории, и теперь хотите ограничить доступ в поддиректории лишь некоторым пользователям;
• no_root_squash – по умолчанию пользователь root на клиентской машине не будет обладать теми же правами к директории на сервера. Эта опция снимает это ограничение;
• nohide - NFS автоматически не показывает нелокальные ресурсы (например, примонтированые с помощью mount --bind), эта опция включает отображение таких ресурсов;
• insecure - использование непривилегированных портов (> 1024);

Запускаем NFS-сервер

# под archlinux sudo systemctl start rpc-idmapd.service rpc-mountd.service # под ubuntu sudo /etc/init.d/nfs-kernel-server start

В дальнейшем при изменении конфигурационного файла достаточно его перечитать командой:

Sudo exportfs -rav

Команда rpcinfo -p | grep nfs позволяет проверить успешность запуска сервера.

Клиент под Linux

Установка

# под archlinux yaourt -S nfs-utils # под ubuntu sudo apt-get install portmap nfs-common

Создадим директории для монтирования сетевых ресурсов torrents и photos

Mkdir -p ~/nfs/{torrents,photos}

Для ручного монтирования выполним

Sudo mount -t nfs -o rw,soft 192.168.1.100:/srv/nfs/torrents /home/proft/nfs/torrents sudo mount -t nfs -o rw,soft 192.168.1.100:/srv/nfs/photos /home/proft/nfs/photos

Опция soft указывает тихо отменить попытки подключить шару после определенного количества времени (время задается опцией retrans ). Подробнее в man nfs .

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

Для автоматического монтирования редактируем файл /etc/fstab

# sudo vim /etc/fstab 192.168.1.100:/srv/nfs/torrents /home/proft/net/torrents nfs rw,soft 0 0 192.168.1.100:/srv/nfs/photos /home/proft/net/photos nfs ro,soft 0 0

Но и у этого способа есть свои недостатки, например, если сервер не доступен то загрузка клиента может подвиснуть из-за попыток подключиться к NFS-серверу. Для исправления этого см. ниже про AutoFS .

AutoFS - автоматическое подключение сетевых ресурсов

Есть возможность монтировать удаленный ресурс с помощью AutoFS при первом обращении и автоматически отмонтировать при отсутствии активности.

AutoFS использует для настройки шаблоны, расположенные в /etc/autofs . Основной шаблон называется auto.master , он может указывать на один или несколько других шаблонов для конкретных типов носителей.

Установка

# под archlinux yaourt -S autofs # под ubuntu sudo apt-get install autofs

Существует несколько способов указать способы автомонтирования. Я использую такой: в /home/proft/nfs автоматически создается директория с именем NFS-сервера, в которой автоматически создаются доступные директории на сервере.

# sudo vim /etc/autofs/auto.master /home/proft/nfs /etc/autofs/auto.nfs --timeout=60

Дополнительный параметр timeout устанавливает количество секунд после которых устройство будет размонтировано. Параметр ghost указывает что сконфигурированные ресурсы будут отображаться всегда, а не только тогда, когда они доступны (эта опция включена по умолчанию в AutoFS 5 )

Опишем в /etc/autofs/auto.nfs NFS-сервер и root-директорию.

# sudo vim /etc/autofs/auto.nfs nfsserver 192.168.1.100:/srv/nfs

Теперь при первом обращении /home/proft/nfs/torrents произойдет автоматическое монтирование NFS-ресурса.

Перезапустим службу autofs:

# под archlinux sudo systemctl restart autofs # под ubuntu sudo /etc/init.d/autofs restart

Еще можно указать время ожидания доступности NFS-ресурса. Для этого необходимо изменить значения MOUNT_WAIT .

# под archlinux # sudo vim /etc/conf.d/autofs MOUNT_WAIT=5 # под ubuntu sudo /etc/default/autofs MOUNT_WAIT=5

Форсирование использования NFS v3

В некоторых случаях NFSv4 может работать медленно. Для исправления этого можно принудительно указать использовать третью версию.

До того, как вы продолжите читать этот документ вам будет необходимо успешно выполнять операцию telnet между машинами, которые вы будете использовать как сервер и клиент. Если что-то не работает, вам нужно прочитать NET-3 HOWTO и правильно настроить работу сети.

Первый шаг

До того, как мы сможем сделать что-нибудь нам необходимо настроить сервер NFS. Если вы являетесь частью сети факультета или университета, то у вас вероятно есть несколько настроенных серверов NFS. Конечно, если они позволят вам получить доступ к ним и если вы читаете этот документ чтобы получить доступ к одному из них, то вам можно не читать это раздел и вы можете просто пропустить его до раздела Установка клиента NFS

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

Если вы торопитесь, то пожалуйста посмотрите раздел Linux 2.2 до того, как вы продолжите читать это.

То, о чем вы читали, потребует от вас настройки нескольких программ.

Portmapper

Portmapper на Linux называется либо portmap либо rpc.portmap. Справочная страница на моей системе говорит, что это "Преобразователь номеров портов DARPA в вызовы соответствующих программ RPC". Это первая дыра в безопасности, которую вы откроете читая этот документ. Описание того, как закрыть одну из таких дыр находится в разделе по безопасности, который я советую вам обязательно прочитать.

Запустите portmapper. Он называется либо portmap, либо rpc.portmap и должен находиться в директории /usr/sbin (на некоторых машинах он называется rpcbind). Вы можете запустить его сейчас вручную, но он должен запускаться при каждом запуске вашей машины, так что вам необходимо создать/отредактировать rc-скрипты. Содержание ваших rc-скриптов объясняется более подробно в справочной странице init. Они обычно находятся в директориях /etc/rc.d, /etc/init.d или /etc/rc.d/init.d. Если там есть скрипт, названный inet, то его мы и будем редактировать. Но то, что в нем необходимо написать или что необходимо сделать еще, находится вне области рассмотрения этого документа. Запустите portmap, и проверьте, что он запущен с помощью команды ps aux и затем rpcinfo -p. Это сделано? Хорошо.

Одна вещь. Удаленный доступ к вашей программе portmapper определяется содержимым ваших файлов /etc/hosts.allow и /etc/hosts.deny. Если rpcinfo -p не работает, но ваш portmapper запущен, то пожалуйста провереьте указанные файлы. Смотрите раздел о безопасности для детального описания этих файлов.

Mountd и nfsd

Следующие программы, которые нам нужно запустить далее;-- это mountd и nfsd. Но сначала мы отредактируем другой файл. Это файл /etc/exports. Допустим я хочу, чтобы файловая система /mn/eris/local, которая находится на машине eris была доступна для машины названной apollon. Тогда я должен поместить в файл /etc/exports на машине eris следующие строки:

/mn/eris/local apollon(rw)

Вышеприведенные строки дают машине apollon право на чтение/запись в каталог /mn/eris/local. Вместо rw мы можем сказать ro, что означает достп только для чтения (если вы ничего не поместите, то по умолчанию будет доступ только для чтения. Существуют другие опции, которые вы можете задать здесь, и я позже рассмотрю некоторые из них, относящиеся к проблеме к безопасности. Они все перечислены в справочной странице exports, которую вы должны прочитать по крайней мере раз в жизни. Существуют также лучшие способы, чем перечисление всех машин в файле exports. Вы например можете использовать сетевые группы, если у вас используется система NIS (или NYS) (NIS также известен как YP), и всегда использовать шаблоны (wild cards) доменов и подсетей IP как списки машин, которым разрешено что-то монтировать. Но вы должны учитывать, кто может получить доступ к серверу неавторизованным способом, если вы используете такую всеобъемлющую авторизацию.

Замечание: Этот файл exports не имеет такой же синтаксис, который используют другие системы Unix. В этом документе есть отдельный раздел о файлах exports других Unix-систем.

Сейчас мы готовы к запуску программ mountd (она также может называться rpc.mountd) и nfsd (который может назван rpc.nfsd). Обе эти программы читают данные из файла exports.

Если вы отредактировали файл /etc/exports, то вы должны быть уверены, что nfsd и mountd знают о том, что файл изменен. Традиционный способ сделать это;-- это запустить программу exportfs. Во многих дистрибутивах Linux программа exportfs отсутствует. Если это так, то вы можете создать такой скрипт на вашей машине:

#!/bin/sh
killall -HUP /usr/sbin/rpc.mountd
killall -HUP /usr/sbin/rpc.nfsd
echo re-exported file systems

Сохраните его в файле, скажем /usr/sbin/exportfs, и не забудьте выполнить над ним команду chmod a+rx. Сейчас, после того как, вы изменили ваш файл exports, вы должны запустить программу exportfs, имея права администратора.

Теперь вы должны проверить, что mountd и nfsd запущены правильно. Сначала это делается с помощью команды rpcinfo -p. Вывод программы должен показать что-то похожее на следующее:

program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 745 mountd
100005 1 tcp 747 mountd
100003 2 udp 2049 nfs
100003 2 tcp 2049 nfs

Как вы видите portmapper анонсировал свои сервисы, и что mountd и nfsd запущены.

Если вы получили сообщение rpcinfo: can"t contact portmapper: RPC: Remote system error - Connection refused, RPC_PROG_NOT_REGISTERED или что-то подобное вместо этого, то значит portmapper не запущен. Или у вас может быть что-то записано в файлах /etc/hosts.{allow,deny} что запрещает программе portmapper отвечать, пожалуйста посмотрите раздел о безопасности для подробного описания этих файлов. Если вы получили сообщение No remote programs registered., то либо portmapper не хочет говорить с вами, либо что-то не в порядке. Завершите выполнение nfsd, mountd и portmapper и попытайтесь выполнить заново стартовую последовательность.

После проверки того, что portmapper объявил сервисы, вы также можете выполнить проверку работы с помощью команды ps. Portmapper будет продолжать объявлять свои сервисы даже после того как программы расширяющие его возможности завершили работу. Так что проверка с помощью ps может быть необходимой, если вам кажется, что что-то не работает.

Конечно вам будет нужно исправить ваши системные rc-файлы для запуска mountd и nfsd при загрузке. Очень вероятно, что эти скрипты уже существуют на вашей машине, и вам будет нужно только раскомментировать нужный раздел или активизировать скрипт на нужном уровне запуска.

Справочные страницы, которые вы должны уже изучить: portmap, mountd, nfsd и exports.

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

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

Первым делом вам нужно ядро с поддержкой файловой системы NFS, либо вкомпилированной в ядро, либо доступной как модуль. Это настраивается до компиляции ядра. Если вы никогда не компилировали ядро, то вам может быть нужно прочитать Rernel HOWTO и выяснить как это делается. Если вы используете хороший дистрибутив (такой как RedHat) и вы никогда не экспериментировали с ядром или модулями (и таким образом разрушали его;-), то вероятно, что поддержка nfs уже есть в ядре.

Теперь вы можете, в командной строке администратора, ввести соответствующую команду монтирования и файловая система появится у вас. Продолжая пример из предыдущего раздела мы хотим смонтировать /mn/eris/local с машины eris. Это делается с помощью такой команды:

mount -o rsize=1024,wsize=1024 eris:/mn/eris/local /mnt

(Мы еще вернемся к опциям rsize и wsize). Файловая система сейчас доступна в /mnt и вы можете перейти туда и выполнить в ней команду ls, и посмотреть на индивидуальные файлы. Вы заметите, что эта операция выполняется не так быстро как над локальной файловой системой, но более удобно чем ftp. Если вместо монтирования файловой системы команда mount выдаст сообщение об ошибке mount: eris:/mn/eris/local failed, reason given by server: Permission denied, то файл exports является неправильным или вы забыли запустить exportfs после редактирования файла exports. Если команда сообщит mount clntudp_create: RPC: Program not registered это означает, что nfsd или mountd не запущены на сервере. Или у вас проблема с hosts.{allow,deny}, о которой упомянуто выше.

Чтобы прекратить пользоваться файловой системы вы можете выполнить:

Чтобы выполнялось автоматическое монтирование файловой системы nfs при загрузке, вам необходимо отредактировать файл /etc/fstab как обычно это делается. Для нашего примера требуется такая строка:

...
eris:/mn/eris/local /mnt nfs rsize=1024,wsize=1024 0 0
...

Это почти все, что необходимо. Читайте пожалуйста дальше.

Опции монтирования

Здесь перечислены некоторые опции, которые вы должны рассмотреть сразу, добавляя их в файл настроек. Они управляют способом, которым клиент NFS отрабатывает прекращение работы сервера или отключение сети. Одно из свойств NFS в том, что он может изящно обрабатывать эти неполадки, если вы правильно установите клиента. Существует два различающихся режима обработки ошибок:

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

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

Продолжая предыдущий пример, теперь в нашем файле fstab запись будет выглядеть так:

# device mountpoint fs-type options dump fsckorder
...
eris:/mn/eris/local /mnt nfs rsize=1024,wsize=1024,hard,intr 0 0
...

Оптимизация NFS

Обычно, если не заданы опции rsize и wsize, то NFS будет читать и писать блоками по 4096 или по 8192 байтов. Некоторые комбинации ядер Linux и сетевых карт не могут обрабатывать такие большие блоки, и это может быть не оптимально. Так что нам нужно поэкспериментировать и найти значения rsize и wsize, которые работают так быстр,о насколько это возможно. Вы можете протестировать скорость передачи при заданных опциях при помощи нескольких простых команд. Выполнив вышеприведенную команду монтирования и получив доступ с правом записи на диск, вы можете выполнить тестирование производительности последовательной записи:

time dd if=/dev/zero of=/mnt/testfile bs=16k count=4096

Эта команда создает 64Mb файл, заполненный нулевыми значениями (этот файл должен быть достаточно большим, настолько большим, чтобы кэширование не сыграло значительную роль в производительности, используйте больший размер файла, если у вас достаточно много памяти). Проделайте эту операцию несколько раз (5-10?) и усредните полученные результаты. Полученная величина;-- это время `прохода", т.е. величина наиболее интересующая нас в этом эксперименте. Затем вы можете измерить производительность чтения, прочитав файл обратно на свою машину:

time dd if=/mnt/testfile of=/dev/null bs=16k

выполните эту операцию несколько раз и усредните результат. Затем отмонтируйте файловую систему и примонтируйте ее заново, с увеличенными значениями rsize и wsize. Вероятно они должны быть кратными 1024, и не больше чем 16384 байтов, поскольку это максимальный размер блока данных в NFS версии 2. Прямо после монтирования с увеличенными значениями перейдите в смонтированную файловую систему и выполните команду подобную ls, исследуйте файловую систему, чтобы убедиться, что все в норме. Если значения rsize/wsize слишком большие, то симптомы очень необычные и не на 100% очевидные. Типичный симптом выражается в неполном списке файлов при выполнении команды "ls", и отсутствие сообщений об ошибках. Или чтение файлов загадочно срывается без сообщения об ошибке. После того, как вы установите, что заданные значения rsize/wsize работают, вы можете далее продолжать тестировать производительность. Различные серверные платформы вероятно имеют различные оптимальные размеры блоков. SunOS и Solaris по общему мнению, работают довольно быстрее при размере блока равном 4096 байт, чем при других значениях.

Новые ядра Linux (с версии 1.3) выполняют предваряющее чтение для значений rsize больших или равных размеру страницы машины. На процессорах Intel размер страницы равен 4096 байтам. Предваряющее чтение значительно увеличивает производительность NFS при чтении. Так что на машинах с процессором Intel вы можете захотеть использовать значение rsize равное 4096 байтам.

Помните, что вам нужно отредактировать /etc/fstab для использования найденных значений rsize/wsize.

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

/dir -async,access=linuxbox

или что-то подобное. Пожалуйста посмотрите справочную страницу exports на данной машине. Также запомните, что это увеличивает риск потери данных.

NFS через медленные линии

Медленные линии включают в себя модемы, ISDN и другие соединения на дальние расстояния.

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

Первая вещь которую вы должны помнить, что NFS;-- медленный протокол. Использование NFS в большинстве своем подобно использованию протокола kermit для переноса файлов. Это;-- медлено. Почти все быстрее чем NFS. FTP быстрее. HTTP быстрее. rcp быстрее. ssh быстрее.

Вы все еще хотите попробовать его в работе? Ok.

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

Первое, что вам необходимо сделать;-- это не использовать опцию монтирования soft. Это вызовет возвращение программному обеспечению сигналов об ошибках при таймаутах. В основном обычное программное обеспечение не слишком хорошо обрабатывает такие ошибки. Это хороший способ получить странные сбои. Вместо этого используйте опцию монтирования hard. Когда активна опция hard, то таймауты вызывают бесконечные попытки возобновления вместо прерывания работы ваших программ. Это то, что вам действительно нужно.

Следующая вещь, которую нужно сделать;-- это поэкспериментировать с опциями монтирования timeo и retrans. Они описаны в справочной странице nfs(5), здесь приводится выдержка из нее:

timeo=n Величина в десятых долях секунды до посылки
первой ретрансляции после таймаута RPC. По
умолчанию эта величина равна 7 десятых
секунды. После первого таймаута, время таймаута
удваивается после каждого таймаута, пока не
будет достигнута величина максимального таймаута
равна 60 секундам, или произойдет достаточно
ретрансляции, вызвав главный таймаут. Затем если
файловая система смонтирована с опцией hard, то
каждый новый таймаут каскадно запускается с
начальным значением в два раза больше, чем при
предыдущем каскаде, кроме того удваиваясь на
каждой ретрансляции. Максимальный таймаут всегда
равен 60 секундам. Наилучшая общая
производительность может быть достигнута
увеличением таймаута при монтировании на
загруженной сети, к медленному серверу, или
сквозь несколько маршрутизаторов.

retrans=n Эта величина задает количество неосновных
таймаутов и ретрансляций, которые должны
произойти до возникновения главного таймаута. По
умолчанию эта величина равна 3. Когда возникает
главный таймаут, то файловые операции либо
прерываются или на консоли печатается сообщение
"server not responding".

Другими словами: Если запрос не будет передан за таймаут равный 0.7 секунды (700ms), то клиент NFS повторит запрос и увеличит таймаут в два раза, до 1.4 секунды. Если ответ не придет в течении 1.4 секунды, то запрос повторится снова и таймаут будет увеличен до 2.8 секунды.

Скорость линии может быть измерена с помощью команды ping с размером пакета равным значению, установленному опциями rsize/wsize.

$ ping -s 8192 lugulbanda
PING lugulbanda.uio.no (129.240.222.99): 8192 data bytes
8200 bytes from 129.240.222.99: icmp_seq=0 ttl=64 time=15.2 ms
8200 bytes from 129.240.222.99: icmp_seq=1 ttl=64 time=15.9 ms
8200 bytes from 129.240.222.99: icmp_seq=2 ttl=64 time=14.9 ms
8200 bytes from 129.240.222.99: icmp_seq=3 ttl=64 time=14.9 ms
8200 bytes from 129.240.222.99: icmp_seq=4 ttl=64 time=15.0 ms

Lugulbanda.uio.no ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 14.9/15.1/15.9 ms

Здесь время показывает как долго пакет программы ping идет туда и обратно к машине lugulbanda. 15ms это довольно быстро. При работе через модем со скоростью 28.000 бод вы можете ожидать где-то 4000-5000ms, и если линия нагружена еще кем-то, то время будет даже выше, может быть раза в два. Когда это время высоко, мы говорим что это "высокое запаздывание". В общем для больших пакетов и для более загруженных линий запаздывание будет увеличиваться. Увеличьте timeo соответственно вашей линии и загрузке. И поскольку запаздывание увеличивается когда вы используете линию для других вещей: даже если вы хотите использовать FTP и NFS в одно и тоже время, то вы должны попытаться измерить timeo ping во время использования FTP для передачи файлов.

Безопасность и NFS

Я ни коим образом не являюсь экспертом в области компьютерной безопасности. Но у меня есть маленький совет для сознающих проблему безопасность. Но будьте предупреждены: этот список ни в коем случае не является полным списком проблем относящихся к NFS, и если вы думаете, что вы обезопасились один раз прочитав и выполнив, все что я даю здесь, то я хочу предупредить вас.

Этот раздел не должен беспокоить вас, если вы находитесь в закрытой сети, где вы доверяете всем пользователям, и никто из тех кому вы не доверяете ни может получить доступ к машинам в сети. Например, не должно быть dial-соединения в сеть, и не должно быть никакого способа подключиться к сети, в которой вы есть люди, которым вы не доверяете. Вы думаете я параноик? Я не параноик. Это базовый совет по безопасности. Безопасность требует наличия тщательного и знающего администратора, который знает где найти информацию о текущих и потенциальных проблемах безопасности.

Основная проблема NFS в том, что клиент, если не задано, будет доверять серверу и наоборот. Это может быть плохо. Это значит, что если запись администратора сервера NFS взломана, то также легко может быть взломана запись администратора клиентской машины. И наоборот. Существует набор полицейских стратегий для этого, мы к ним еще вернемся.

Что вам необходимо прочитать;-- это консультационные материалы CERT относящиеся к NFS. Большинство текстов приведенных ниже, связаны с советами, написанными в выпусках CERT. Смотрите ftp.cert.org/01-README для обновленного списка консультативных материалов CERT. Здесь приведены некоторые относящиеся к NFS консультативные материалы:

CA-91:21.SunOS.NFS.Jumbo.and.fsirand 12/06/91
Уязвимость в отношении сетевой файловой системы (NFS) Sun
Microsystems, Inc. (Sun) и программы fsirand. Эта уязвимость
возможна в версиях SunOS 4.1.1, 4.1, and 4.0.3 на всех
архитектурах. Заплатки (Patches) доступны для SunOS
4.1.1. Также доступна начальная заплатка для SunOS 4.1 NFS. Sun
будет обеспечит полные заплатки для SunOS 4.1 и SunOS 4.0.3 позже.

CA-94:15.NFS.Vulnerabilities 12/19/94
Этот консультационный материал обеспечивает измерение
безопасности для охраны против против некоторых дыр в безопасности
в сетевой файловой системе (NFS). Этот материал выпущен в связи с
увеличением случаев взлома машин, используя утилиты для
взлома через уязвимые точки.

CA-96.08.pcnfsd 04/18/96
Этот материал описывает проблемы с безопасностью в программе pcnfsd
(также известной как rpc.pcnfsd). Заплатка для исправления ошибки
прилагается.

Безопасность клиента

На клиентской стороне мы можем решить, что мы не хотим слишком сильно доверять серверу. Это делается несколькими способами, используя опции монтирования. Например, мы можем запретить выполнение программ с установленным битом suid в файловой системе NFS, это делается опцией монтирования nosuid. Это хорошая идея и вы должны рассмотреть ее, используя смонтированные через NFS файловые системы. Это означает, что администратор сервера не сможет сделать программы с установленным suid-администратора на файловой системе, затем войти на машину клиента как обычный пользователь и используя программу с suid-администратора приобрести также права администратора на машине клиента. Мы также можем запретить выполнение файлов на смонтированной файловой системе с помощью опции noexec. Но она применяется реже по сравнению с опцией nosuid, поскольку файловая система может содержать по крайней мере некоторые скрипты, или программы, которые необходимо выполнять. Вы можете ввести эти опции в колонке опций вместе с опциями rsize и wsize, разделяя их запятыми.

Безопасность сервера: nfsd

На стороне сервера мы можем решить, что мы не хотим доверять администратору клиента. Мы можем сделать это указав опцию root_squash в файле exports:

/mn/eris/local apollon(rw,root_squash)

Теперь, если пользователь с UID 0 на стороне клиента попытается получить доступ (чтение, запись, удаление), то файловый сервер выполнит подстановку UID пользователя `nobody" на сервере. Это означает, что администратор клиента не сможет получить доступ или изменять файлы, которые может изменять или иметь доступ к которым может только администратор сервера. Это хорошо и вы должны использовать опцию root_squash на всех экспортируемых файловых системах. Вы скажете, что "Администратор клиента все равно может выполняить команду "su", чтобы зайти как любой другой пользователь и получить доступ и изменить любые пользовательские файлы". На это есть ответ: "Да есть такой способ, и это работает в Unix и NFS. Это имеет одно важное заключение: Все важные файлы и программы должны иметь владельцем пользователя root, а не пользователя bin или другого пользователя не-администратора, поскольку только администратор клиента не может получить доступ как администратор сервера. С справочной странице NFSd есть несколько других подобных опций, так что вы можете решить, что вы (не) доверяете кому-либо со стороны клиента. У вас также имеются опции для осечения любых диапазонов UID и GID. Это описывается в справочной странице Linux NFSd.

Опция root_squash является установленной по умолчанию для NFSd в Linux, для передачи администраторских полномочий для доступа к файловой системе используйте опцию no_root_squash.

Другая важная вещь, которую необходимо сделать, это проверить, что nfsd проверяет, все ли запросы приходят с привелигированного порта. Если он принимает запросы с любого старого порта на клиенте, то пользователь без специальных привилегий может запустить программу, которую легко получить по Internet. Он умеет "говорить" на языке протокола nfs и будет притворяться, что пользователь является любым пользователем, которым он хочет быть. NFSD на Linux делает эту проверку по умолчанию, но для других операционных систем вы должны разрешить эту проверку сами. Это должно быть описано в справочной странице nfsd для вашей операционной системы.

Другая вещь. Никогда не экспортируйте файловую систему для машины с именем "localhost" или 127.0.0.1. Доверяйте мне.

Безопасность сервера: portmapper

Основа portmapper, в соединении с nfsd имеет проблему в проектировании, которая делает возможной получить файлы с серверов NFS без каких-либо привилегий. К счастью portmapper используемый в большинстве дистрибутивов Linux использует относительную безопасность против такой атаки, и может быть сделано более безопасной настройкой списка доступа в двух файлах.

Не все дистрибутивы Linux обладают равными возможностями. Некоторые дистрибутивы, которые кажутся современными, не включают в свой состав безопасный вариант программы portmapper, даже сейчас, через много лет после того как стало известно о ее уязвимостях. По крайней мере один дистрибутив даже содержит справочную страницу более безопасного portmapper, но на самом деле его portmapper не является безопасным. Самым легким способом проверить является ли ваш portmapper хорошим или нет, является запуск программы strings(1) и просмотр ее вывода на наличие файлов, /etc/hosts.deny и /etc/hosts.allow. Предполагая, что ваш portmapper находится /usr/sbin/portmap, вы можете проверить это выполнив следующую команду: strings /usr/sbin/portmap | grep hosts. на моей машине это выполнилось со следующими результатами:

/etc/hosts.allow
/etc/hosts.deny
@(#) hosts_ctl.c 1.4 94/12/28 17:42:27
@(#) hosts_access.c 1.20 96/02/11 17:01:27

Сначала мы отредактируем файл /etc/hosts.deny. Он должен содержать строку

которая запретит доступ всем. Поскольку это закрыло доступ всем, запустите rpcinfo -p просто для проверки того, что ваш portmapper читает этот файл и выполняет данные инструкции. Команда rpcinfo не должна ничего вывести или должна выдать сообщение об ошибке. Перезапуск portmapper не является необходимым.

Закрытие portmap для всех может быть слишком кардинальным, поэтому мы снова откроем доступ, изменив файл /etc/hosts.allow. Но сначала нам надо определить, что мы туда поместим. В этом файле перечисляются все машины, которые могут получить доступ к вашему portmapper. Среди множества работающих под Linux систем только некоторым машинам нужен полный доступ для любой работы. Portmapper обслуживает nfsd, mountd, ypbind/ypserv, pcnfsd, и "r" сервисы, такие как ruptime и rusers. Из них только nfsd, mountd, ypbind/ypserv и возможно pcnfsd имеют какое-либо важное значение. Всем машинам, которым необходим доступ к сервисам на вашей машине должно быть разрешено делать это. Скажем адрес машины равен 129.240.223.254 и она находится в подсети 129.240.223.0, и ей нужен доступ к сервисам на вашей машине (эти термины введены HOWTO по сетям, вернитесь к нему и освежите свои знания, если это необходимо). Для этого мы напишем в файле hosts.allow

portmap: 129.240.223.0/255.255.255.0

Это тоже самое, что и сетевой адрес, который вы даете командой route и маска подсети, которую вы передаете команде ifconfig. Для устройства eth0 на этой машине ifconfig должен показывать

...
eth0 Link encap:10Mbps Ethernet HWaddr 00:60:8C:96:D5:56
inet addr:129.240.223.254 Bcast:129.240.223.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:360315 errors:0 dropped:0 overruns:0
TX packets:179274 errors:0 dropped:0 overruns:0
Interrupt:10 Base address:0x320
...

а программа netstat -rn должна показывать

Kernel routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
...
129.240.223.0 0.0.0.0 255.255.255.0 U 0 0 174412 eth0
...

(Сетевой адрес находится в первой колонке).

Файлы hosts.deny и hosts.allow описаны в справочных страницах с теми же именами.

ВАЖНО: Не помещайте в этих файлах ничего, кроме IP НОМЕРОВ в строках для настройки portmap. Поиск имен машин может вызвать активность portmap, которая вызовет поиск имен машин, которое вызовет portmap, которое вызовет...

Вышеприведенные вещи должны вызвать переключение вашего сервера. Остающаяся проблема в том, что кто-то взломает администратора (или загрузит MS-DOS) на машине, которой доверяют и использует эти привилегии для посылки запросов на безопасный порт, как любой пользователь, которым он захочет быть.

NFS и firewall

Очень хорошая идея защитить порты nfs и portmap с помощью firewall на вашем маршрутизаторе. Nfsd работает на порту 2049, используя оба протокола;-- udp и tcp. Portmapper работает на порту 111, tcp и udp, а mountd работает на портах 745 и 747, tcp и udp. По умолчанию. Вы должны проверить номера используемых портов, используя команду rpcinfo -p.

Если вы хотите использовать NFS сквозь firewall, то есть опции для новых версий NFSd и mountd, для того, чтобы заставить их использовать нестандартные порты, которые могут быть открыты в firewall.

Резюме

Если вы используете hosts.allow/deny, root_squash, nosuid и привилегированные порты в программном обеспечении portmapper/nfs, то вы можете избежать известных ошибок в nfs и можете чувствовать себя почти в безопасности. Но все равно: когда взломщик имеет доступ к вашей сети, то он/она может добавить странные команды в ваш файл.forward или почтовый ящик, когда /home или /var/spool/mail смонтирован через NFS. По той же причине, вы никогда не должны осуществлять доступ к вашим личным ключам PGP через nfs. Или по крайней мере вы должны знать какой риск существует. И знать о нем хотя бы немного.

NFS и portmapper создают комплексную систему и поэтому не полностью невероятно,что новые ошибки будут найдены, либо в основе проекта, либо в реализации, которую мы используем. Также могут быть известные дыры, которые кто-нибудь использует. Но такова жизнь. Чтобы быть в курсе таких вещей, вы должны как минимум читать группы новостей comp.os.linux.announce и comp.security.announce.

Контрольный список разрешения проблем монтирования

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

Команда mount продолжает сообщать RPC: Program not registered Запущен ли portmapper?

Исправление: Запустите его.

Запущен ли mountd?

Исправление: Запустите его.

Запущен ли nfsd?

Исправление: Запустите его.

Не запрещено ли portmapper отвечать на ваши запросы файлом /etc/hosts.deny?

Исправление: Либо удалите правило из файла hosts.deny либо добавьте правило в файл hosts.allow, так что portmapper будет разрешено общаться с вами.

Файловая система не экспортируется, или не экспортируется при запросе клиента. Исправление: Экспортируйте ее

Система разрешения имен не выдает соответствия со списком машин в файле exports. Например: список экспортируемых ресурсов задает экспортирование johnmad, но имя johnmad разрешается как johnmad.austin.ibm.com и монтирование запрещается.

Исправление: Экспортируйте ресурс для обоих форм имени машины.

Это также случается, если клиент имеет 2 интерфейса с разными имена для каждого из них и файловая система экспортируется только для одного указанного имени.

Исправление: Экспортируйте оба интерфейса.

Это также может произойти, если сервер не может выполнить функции lookuphostbyname или lookuphostbyaddr (это библиотечные функции) на клиенте. Убедитесь, что клиент может выполнять команды host ; host ; и обе они указывают на одну и ту же машину.

Исправление: наладьте систему разрешения имен.

Файловая система была смонтирована, после того как NFS был запущен (на том сервере). В таком случае сервер экспортирует саму точку монтирования, а не смонтированную файловую систему. Исправление: Завершите NFSd и затем перезапустите его.

Заметчание: Клиенты, которые уже были примонтированы к точке монтирования файловой системы будут иметь проблемы с доступом к ней после перезапуска сервера.

Дата наобум изменяется на одной или обоих машинах (это может спутать make). Исправление: Установите правильную дату.

Автор HOWTO рекомендует использовать NTP для синхронизации часов. Поскольку существуют экспортные ограничения на NTP в US, то вы можете получить NTP для Debian, Red Hat или Slackware с ftp://ftp.hacktic.nl/pub/replay/pub/linux или с сервера-зеркала.

Сервер не допускает монтирования от пользователя, который находится больше чем в 8 группах. Исправление: уменьшите количество групп в которые входит пользователь или смонтируйте под именем другого пользователя.

Часто Задаваемые Вопросы (FAQ)

Это раздел часто задаваемых вопросов (FAQ). Большая часть его основана на старом FAQ, написанном Alan Cox.

Если у вас есть проблемы с монтированием файловой системы, то пожалуйста посмотрите, не описана ли она в разделе ``Список проверок при монтировании"".

Я получаю сообщения об ошибках ``stale nfs handle (устарелый дескриптор nfs)"" при использовании Linux как сервера nfs. Это вызывается ошибкой в одной из старых версий nfsd. Это исправлено в nfs-server2.2beta16 и более поздних.

Когда я пытаюсь примонтировать файловую систему я получаю сообщение
can"t register with portmap: system error on send
(не могу зарегистрироваться с помощью portmap: системная ошибка при посылке)

Вы вероятно используете систему Caldera. Это ошибка в скриптах rc. Пожалуйста свяжитесь с Caldera для получения исправления.

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

Мои файлы на NFS все считаются с правом только на чтение По умолчанию сервер NFS для Linux выдается все как только для чтения. Перечитайте разделы ``Mountd и nfsd"" и ``Экспортирование файловых систем"" данного документа, а также справочные страницы по ``exports"" и nfsd. Вам необходимо изменить файл /etc/exports.

Я монтирую файловую систему с сервера nfs под linux и пока работает команда ls я не могу читать или записывать файлы. На старых версиях Linux вы должны монтировать сервер NFS с опциями rsize=1024,wsize=1024.

Я монтирую файловую систему с сервера NFS под Linux с размером блока между 3500-4000 и это регулярно роняет машину с Linux Обычно не делайте так. Это не случается с ядрами версий 2.0 и 2.2. Также нет проблемы с ядрами серии 2.1.

Может Linux выполнять NFS по TCP Нет

Я получаю странные ошибки при монтировании машины с машины под Linux. Убедитесь, что ваш пользователь находится в 8 или меньшем количестве групп. Старые сервера требую этого.

Когда я перезагружаю свою машину она иногда вешается при попытке отмонтироваться от зависшего сервера NFS. Не отмонтируйтесь от серверов NFS при перезагрузке или выключении, просто проигнорируйте это, ничто не повредится, если вы не отмонтируетесь от него. Команда будет выглядеть следующим образом umount -avt nonfs.

Клиент NFS для Linux работает очень медленно при записи на системы Sun и BSD. Обычно NFS записывает в синхронном режиме (вы можете запретить это, если вы считаете, что вы не рискуете потерять данные). Хуже всего то, что ядра произошедшие от BSD не могут работать с маленькими блоками. Таким образом когда вы пишете 4K данных с машины под Linux в 1K пакетах, то BSD выполняет это следующим образом

прочитать страницу размером 4K
изменить 1K

прочитать страницу размером 4K
изменить 1K
записать страницу размером 4K обратно на диск
и т.д...

Когда я подключаю много клиентов к Linux NFS серверу, его производительность неожиданно падает. Протокол NFS использует использует фрагментированые UDP-пакеты. В ядре имеется предел на то, как много фрагментов или неполных пакетов прибудет до того, как оно начнет отбрасывать пакеты. В ядрах серии 2.2 это настраивается во время работы через файловую систему /proc: /proc/sys/net/ipv4/ipfrag_high_thresh и ipfrag_low_thresh. В ядрах серии 2.0 эти константы определяются во время компиляции и определены в файле.../linux/net/ipv4/ip_fragment.c, IPFRAG_HIGH_THRESH и IPFRAG_LOW_THRESH. Эти параметры означают, что когда потребление памяти не собранными фрагментами пакетов UDP достигает значения ``ipfrag_high_thresh"" в байтах (по умолчанию 256K в ядрах 2.2.3 и 2.0.36) оно уменьшится до значения ``ipfrag_low_tresh"". Это делается отбрасыванием фрагментов. Это будет выглядеть как почти полная потеря пакетов и если будет достигнута верхняя граница, то производительность вашего сервера сильно уменьшится.

256K достаточно для обслуживания до 30 клиентов. Если у вас 60 клиентов, то увеличьте это значение в 2 раза. И также увеличьте значение нижней границы.

Я использую Linux 2.2 (или более поздний) с knfsd и я не могу заставить мои машины с AIX, IRIX, Solaris, DEC-Unix, ... монтироваться к нему. Knfsd объявляет, что реализует NFS версии 3. Это не так. Существует опция, которая запрещает ему анонсировать это. Используйте ее. Или вы можете поместить параметр "vers=2" в список опций монтирования на клиенте.

Моя машина с AIX 4 не может произвести монтирование моего NFS сервера под Linux. Она сообщает
mount: 1831-011 access denied for server:/dir
mount: 1831-008 giving up on:
server:/dir
The file access permissions do not allow the specified action.

или что-то подобное. AIX 4.2 использует зарезервированные порты (<1024) для NFS. AIX 4.2.1 и 4.3 не ограничены резервированными портами. Также AIX 4.2.1 и 4.3 пытаются произвести монтирование используя версию NFS3, затем NFS/TCP, и только потом NFS/UDP.

Добавление строк

nfso -o nfs_use_reserved_ports=1

в конец файла rc.tcpip заставит его использовать резервированные порты. (Этот совет был послан Brian Gorka).

Экспортирование файловых систем

Способ экспортирования файловых систем с помощью NFS не является полностью совместимым между платформами. В этом случае отличаются Linux и Solaris 2. Этот раздел поверхностно перечисляет способы как выполнить эту операцию на большинстве систем. Если ваша система не была перечислена здесь, то посмотрите справочные страницы по вашей операционной системе. Ключевые слова следующие: nfsd, system administration tool (утилиты системного администрирования), rc scripts, boot scripts, boot sequence, /etc/exports, exportfs. Я буду использовать один пример для всего раздела: как экспортировать файловую систему /mn/eris/local для машины apollon с правами на чтение/запись.

IRIX, HP-UX, Digital-UNIX, Ultrix, SunOS 4 (Solaris 1), AIX

Эти операционные системы используют традиционный формат Sun для экспортирования. В файле /etc/exports напишите:

/mn/eris/local -rw=apollon

Полная документация находится в справочной странице exports. После редактирования файла запустите exportfs -av для экспортирования файловых систем.

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

/mn/eris/local apollon

или даже вот так:

Solaris 2

Sun полностью переизобрел колесо при разработке Solaris 2. Так что он полностью отличается от других операционных систем. То, что вам нужно сделать;-- это отредактировать файл /etc/dfs/dfstab. В нем вы должны поместить команды организации доступа так, как это описано в справочной странице share(1M). Примерно вот такие строки:

share -o rw=apollon -d "Eris Local" /mn/eris/local

После редактирования запустите программу shareall для экспортирования файловой системы.

NFS в Linux 2.2

Как я написал, Linux 2.2.12 является текущей версией ядра и для использования NFS в нем может быть нужно будет выполнить немного рутинной работы. Или не нужно.

Каким будет статус NFS в Linux 2.4 я не знаю.

Большим новшеством в Linux 2.2 является поддержка демона nfs в ядре, который называется knfsd. Этот способ реализации nfsd имеет некоторые преимущества, главный из которых;-- скорость работы. Машина с Linux 2.2 и knfsd является солидным сервером nfs. Вы все равно можете использовать старый nfsd с Linux 2.2, и также существует несколько преимуществ, в основном простота.

Если вы используете исходные тексты ядра или двоичные пакеты, созданные кем-то типа RedHat (6.0 и поздние), SuSE (6.1 или более поздние) или каким-то другим профессиональным системным интегратором, то скорее всего они будут поставляться с полной интеграцией "knfsd" в ядро и вы не должны будете беспокоится. В большинстве случаев. До тех пор пока вы не заходите скомпилировать ядро сами. Если вы используете обычное ядро Linux 2.2 (по крайней мере 2.2.12), то knfsd не будет работать.

Для того, чтобы самому заставить это работать вам необходимо взять пакет knfsd сделанный H.J. Lus. Этот пакет является набором заплаток и необходимых утилит для ядер серии 2.2, которые Lu сопровождает в свое свободное время. Вы можете взять его с вашего локального зеркала сервера ядра, или с основного сервера, по адресу ftp.kernel.org:/pub/linux/devel/gcc/. Он не предназначается для всеобщего использования. Если этот пакет вам непонятен, то не пытайтесь использовать его сами. Подождите пока пакеты с ядром не выпустит ваш любимый системный интегратор (например, Red Hat, SuSE или...).

Также, пожалуйста не посылайте мне вопросы об этом пакете, я не могу помочь вам. У меня нет ни одного сервера с работающим knfsd. Если вы нашли ошибку или пропуск в документации, то пожалуйста напишите мне, я исправлю этот документ и выпущу его снова.

Все еще читаете? Ok. H.J.Lu посылает сообщения о новых версиях своего пакета в список рассылки linux-kernel. Другие сообщения, относящиеся к NFS в версии ядра 2.2 также посылаются туда. Читайте их.

Существует одна интересная вещь, которую необходимо сказать о пакете knfsd. Он анонсирует, что использует NFS версии 3. Однако он не поддерживает эту версию. Существует опция, которую вы можете использовать для того, чтобы запретить пакету анонсирование NFS3, или на клиентах необходимо указать опцию "vers=2" среди других опций монтирования.

Клиент

Клиент очень прост. Для того, чтобы получить правильное блокирование вам необходимо иметь statd (из пакета knfsd) скомпилированным, установленным и запещуееным из загрузочных скриптов. Сделайте это. Для работы statd необходим каталог /var/lib/nfs, иначе он просто прекратит работу без каких либо сообщений об ошибках, так что необходимо создать каталог до запуска программы.

Когда statd уже запущен вы можете использовать программу testlk (в каталоге tools/locktest) для тестирования того, что блокировка файлов работает на файловых системах смонтированных по NFS. Она должна работать нормально. Если программа сообщает No locks available (Блокировки не доступны), то statd не работает.

В действительности вы также можете полностью избежать блокировок (заметьте, что я не рекомендую вам делать это), используя параметр "nolock" в списке опций монтирования.

Насколько я знаю--это все, что необходимо для работы клиентов.

Если у вас Sparc или Alpha NFS-сервер, то вы обнаружите, что nfs-клиент в Linux 2.2 совершенное не работает. Скорость передачи данных на и с сервера настолько плоха, что это трудно представить. Это хуже даже чем под Linux 2.0. Намного хуже. Но для этой проблемы существует исправление. Серия ядер 2.2 Alan Cox (которые являются более экспериментальными, чем нормальные ядра 2.2, сопровождаемые Linus) включают заплатку, которая позволяет Linux 2.2 увеличить производительность при работе с серверами Alpha и Sparc. Если вы хотите использовать ядра исправленные Alan Cox, то вы должны читать список рассылки linux-kernel, и вы должны узнать где можно найти необходимые заплатки. Основным сервером для этой заплатки является сервер http://www.uio.no/~trondmy/src/, в случае, если вы хотите попробовать применить его к нормальному ядру серии 2.2. Эта заплатка скорее всего не будет входит в состав Linux 2.4, поскольку требует сделать слишком много изменений в течении текущего цикла разработки. Ждите появления Linux 2.5.

trondmy также имеет заплатки для того, чтобы Linux использовал NFS версии 3, они также позволят вам использовать tcp как транспортный механизм, вместо UDP. NFSv3 очень хорош для сетей с большим количеством переходов, а также для сетей где потери пакетов не равны нулю или где время ожидание очень высокое.

Вы должны читать список рассылки linux-kernel, если вы собираетесь использовать эти заплатки, поскольку время от времени в них находят какую-нибудь неприятные ошибки. Ошибки, которые портят ваши файлы. Так что пожалуйста будьте осторожны.

Сервер

Демон nfs-сервера в Linux 2.2 и более поздних называется "knfsd". Он сложен в установке. Вы можете настроить его сами или поставить то, что вам предлагают SuSE, Red Hat и другие в виде пакетов ядра серии 2.2. Извините. Хотя вы все равно можете использовать старый nfsd в Linux 2.2. Он медленен, но легок в установке.

NFS-сервер на дискете

Этот раздел был написан Ron Peters, [email protected]. Он объясняет как настроить NFS-сервер при загрузке с дискеты. Сначала это было придумано для обеспечения доступа по NFS к cdrom на другой машине без Linux/UNIX для установки Linux на машину на которой нет cdrom.

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

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

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

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

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

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

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

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

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

NFS

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

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

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

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

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

Cd /root/usr2/

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

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

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

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

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

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

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

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

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

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

ДОСТУП В NFS

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

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

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

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

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

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

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

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

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

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

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

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

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

/home (ro)

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

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

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

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

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

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

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

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

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

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

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

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

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

# rpc.mountd -N 1 -N 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#/usr/lib/nfs/mountd

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

#/usr/lib/nfs/nfsd

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

Share -F nfs /export/home

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

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

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

ALL: All

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

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

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

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

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

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

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

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

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

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

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

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

Ресурсы Internet

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

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

Когда речь идет о компьютерных сетях, зачастую можно услышать упоминание NFS. Что такое означает эта аббревиатура?

Это протокол распределенной файловой системы, первоначально разработанный компанией Sun Microsystems в 1984 году, позволяющий пользователю на клиентском компьютере получать доступ к файлам через сеть, подобно доступу к локальному хранилищу. NFS, как и многие другие протоколы, основывается на системе Open Network Computing Remote Procedure Call (ONC RPC).

Другими словами, что такое NFS? Это открытый стандарт, определенный в Request for Comments (RFC), позволяющий любому реализовать протокол.

Версии и вариации

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

NFS v2

Версия 2 первоначально работала только по протоколу User Datagram Protocol (UDP). Ее разработчики хотели сохранить серверную сторону без блокировки, реализованной за пределами основного протокола.

Интерфейс виртуальной файловой системы позволяет выполнять модульную реализацию, отраженную в простом протоколе. К февралю 1986 года были продемонстрированы решения для таких операционных систем, как System V release 2, DOS и VAX/VMS с использованием Eunice. NFS v2 позволял считывать только первые 2 ГБ файла из-за 32-разрядных ограничений.

NFS v3

Первое предложение по разработке NFS версии 3 в Sun Microsystems было озвучено вскоре после выпуска второго дистрибутива. Главной мотивацией была попытка смягчить проблему производительности синхронной записи. К июлю 1992 года практические доработки позволили решить многие недостатки NFS версии 2, оставив при этом лишь недостаточную поддержку файлов (64-разрядные размеры и смещения файлов).

• поддержку 64-битных размеров и смещений файлов для обработки данных размером более 2 гигабайт (ГБ);
• поддержку асинхронной записи на сервере для повышения производительности;
• дополнительные атрибуты файлов во многих ответах, позволяющие избежать необходимости их повторного извлечения;
• операцию READDIRPLUS для получения данных и атрибутов вместе с именами файлов при сканировании каталога;
• многие другие улучшения.

Во время введения версии 3 поддержка TCP как протокола транспортного уровня начала увеличиваться. Использование TCP в качестве средства передачи данных, выполненного с использованием NFS через WAN, стало позволять передавать большие размеры файлов для просмотра и записи. Благодаря этому разработчики смогли преодолеть пределы ограничений в 8 КБ, налагаемые протоколом пользовательских дейтаграмм (UDP).

Что такое NFS v4?

Версия 4, разработанная под влиянием Эндрской файловой системы (AFS) и блока сообщений сервера (SMB, также называемая CIFS), включает в себя повышение производительности, обеспечивает лучшую безопасность и вводит протокол с соблюдением установленных условий.

Версия 4 стала первым дистрибутивом, разработанным в Целевой группе Internet Engineering Task Force (IETF) после того, как Sun Microsystems передала разработку протоколов сторонним специалистам.

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

Новейший протокол файловой системы - NFS 4.2 (RFC 7862) - был официально выпущен в ноябре 2016 года.

Другие расширения

С развитием стандарта появились и соответствующие инструменты для работы с ним. Так, WebNFS, расширение для версий 2 и 3, позволяет протоколу сетевого доступа к файловым системам легче интегрироваться в веб-браузеры и активировать работу через брандмауэры.

Различные протоколы сторонних групп стали также ассоциироваться с NFS. Из них наиболее известными выступают:

• Network Lock Manager (NLM) с поддержкой протокола байтов (добавлен для поддержки API-блокировки файлов UNIX System V);
• удаленной квоты (RQUOTAD), который позволяет пользователям NFS просматривать квоты на хранение данных на серверах NFS;
• NFS через RDMA - адаптация NFS, которая использует дистанционный прямой доступ к памяти (RDMA) в качестве средства передачи;
• NFS-Ganesha - сервер NFS, работающий в пользовательском пространстве и поддерживающий CephFS FSAL (уровень абстракции файловой системы) с использованием libcephfs.

Платформы

Network File System часто используется с операционными системами Unix (такими как Solaris, AIX, HP-UX), MacOS от Apple и Unix-подобными ОС (такими как Linux и FreeBSD).

Он также доступен для таких платформ, как Acorn RISC OS, OpenVMS, MS-DOS, Microsoft Windows, Novell NetWare и IBM AS/400.

Альтернативные протоколы удаленного доступа к файлам включают в себя блок сообщений сервера (SMB, также называемый CIFS), протокол передачи Apple (AFP), базовый протокол NetWare (NCP) и файловую систему сервера OS/400 (QFileSvr.400).

Это связано с требованиями NFS, которые ориентированы по большей части на Unix-подобные «оболочки».

При этом протоколы SMB и NetWare (NCP) применяются чаще, чем NFS, в системах под управлением Microsoft Windows. AFP наиболее широко распространен в платформах Apple Macintosh, а QFileSvr.400 наиболее часто встречается в OS/400.

Типичная реализация

Предполагая типичный сценарий в стиле Unix, в котором одному компьютеру (клиенту) нужен доступ к данным, хранящимся на другом (сервер NFS):

• Сервер реализует процессы Network File System, запущенные по умолчанию как nfsd, чтобы сделать свои данные общедоступными для клиентов. Администратор сервера определяет, как экспортировать имена и параметры каталогов, обычно используя файл конфигурации/etc/exports и команду exportfs.
• Администрирование безопасности сервера гарантирует, что он сможет распознавать и утверждать проверенного клиента. Конфигурация его сети гарантирует, что соответствующие клиенты могут вести переговоры с ним через любую систему брандмауэра.
• Клиентская машина запрашивает доступ к экспортированным данным, как правило, путем выдачи соответствующей команды. Она запрашивает сервер (rpcbind), который использует порт NFS, и впоследствии подключается к нему.
• Если все происходит без ошибок, пользователи на клиентской машине смогут просматривать и взаимодействовать с установленными файловыми системами на сервере в пределах разрешенных параметров.

Следует обратить внимание и на то, что автоматизация процесса Network File System также может иметь место - возможно, с использованием etc/fstab и/или иных подобных средств.

Развитие на сегодняшний день

К 21-му столетию протоколы-конкуренты DFS и AFS не достигли какого-либо крупного коммерческого успеха по сравнению с Network File System. Компания IBM, которая ранее приобрела все коммерческие права на вышеуказанные технологии, безвозмездно передала большую часть исходного кода AFS сообществу свободных разработчиков программного обеспечения в 2000 году. Проект Open AFS существует и в наши дни. В начале 2005 года IBM объявила о завершении продаж AFS и DFS.

В свою очередь, в январе 2010 года компания Panasas предложила NFS v 4.1 на основе технологии, позволяющей улучшить возможности параллельного доступа к данным. Протокол Network File System v 4.1 определяет метод разделения метаданных файловой системы из местоположения определенных файлов. Таким образом, он выходит за рамки простого разделения имен/данных.

Что такое NFS этой версии на практике? Вышеуказанная особенность отличает его от традиционного протокола, который содержит имена файлов и их данных под одной привязкой к серверу. При реализации Network File System v 4.1 некоторые файлы могут распределяться между многоузловыми серверами, однако участие клиента в разделении метаданных и данных ограничено.

При реализации четвертого дистрибутива протокола NFS-сервер представляет собой набор серверных ресурсов или компонентов; предполагается, что они контролируются сервером метаданных.

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

Вот , а что дальше? Как посмотреть фильмы и прослушать музыкальные файлы, которые скачались? Неужели нужно записывать их на диски и переносить их таким образом на компьютер с GUI? Или придётся копировать их по медленному SFTP? Нет! На помощь приходит NFS! Нет, это не серия гоночных игр, а Network File System (Сетевая Файловая Система).
Network File System (NFS) - это сетевая файловая система, позволяющая пользователям обращаться к файлам и каталогам, расположенным на удалённых компьютерах, как если бы эти файлы и каталоги были локальными. Главным преимуществом такой системы является то, что отдельно взятые рабочие станции могут использовать меньше собственного дискового пространства, так как совместно используемые данные хранятся на отдельной машине и доступны для других машин в сети. NFS — это клиент-серверное приложение. То есть в системе пользователя должен быть установлен NFS-клиент, а на компьютерах, которые предоставляют свое дисковое пространство - NFS-сервер.

Установка и настройка NFS-сервера (192.168.1.2)

1. Устанавливаем. Соединившись по SSH с компьютером сервером или же просто в его консоли вводим:

Sudo apt-get install nfs-kernel-server nfs-common portmap

Это установит NFS-сервер, а также необходимый пакет portmap.

2. Настраиваем. Для настройки списка дирректорий которые мы хотим открыть и списка кому мы хотим их открыть отредактируем файл /etc/exports :

Sudo nano /etc/exports /data 192.168.1.1/24(rw,no_root_squash,async)

В указанном выше примере мы открыли на сервере директорию /data и её поддиректории в совместное пользование всем компьютерам с IP: 192.168.1.1 - 192.168.1.255 с правами чтения и записи.

Ещё пример:

/home/serg/ 192.168.1.34(ro,async)

Этот пример делает доступной домашнюю директорию пользователя serg в режиме только чтение для компьютера с IP 192.168.1.34. Все остальные компьютеры сети к этой директории доступа иметь не будут.

Доступные опции:

• ro — права только на чтение. Можно и не указывать, так как она установлена по умолчанию;
• rw — дает клиентам право на запись;
• no_root_squash — по-умолчанию пользователь root на клиентской машине не будет иметь доступа к открытым директориям на сервере. Этой опцией мы снимаем это ограничение. В целях безопасности этого лучше не делать;
• noaccess — запрещает доступ к указанной директории. Может быть полезной, если перед этим вы задали доступ всем пользователям сети к определенной директории, и теперь хотите ограничить доступ в поддиректории лишь некоторым пользователям.

Теперь нужно перезапустить nfs-kernel-server:

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

Если после этого вы захотите поменять что-нибудь в файле /etc/exports , то для того, чтобы изменения вступили в силу, достаточно выполнить следующую команду:

Sudo exportfs -a

Всё. NFS-сервер установлен и настроен. Можно переходить к NFS клиенту.

Установка и настройка NFS-клиент

1. Установка. Выполняем в терминале компьютера, который будет подключаться следующее:

Sudo apt-get install portmap nfs-common

2. Настройка. Для начала создадим директорию в которую будет монтироваться удалённая папка:

Cd ~ mkdir data

Монтировать можно двумя способами — каждый раз вручную или прописав опции монтирования в файл /etc/fstab .

Способ 1. Монтирование вручную
Создаём на рабочем столе или в какой-либо другой папке текстовый файл:

Nano ~/Рабочий\ стол/nfs-server-connect

Пишем в него:

#! /bin/bash sudo mount -t nfs -o ro,soft,intr 192.168.1.2:/data ~/data

Делаем его исполняемым:

Chmod +x ~/Рабочий\ стол/nfs-server-connect

Теперь когда необходимо присоединиться к серверу я выполняю этот сценарий в терминале для того чтобы можно было ввести пароль для sudo.

Способ 2. Добавление в /etc/fstab
Открываем /etc/fstab:

Sudo nano /etc/fstab

И дописываем строчку в конце файла:

192.168.1.2:/data ~/data nfs rw,hard,intr 0 0

Внимание! Вместо 192.168.1.2:/data впишите IP или имя сервера и путь к директории совместного пользования. Опции монтирования можно изменить.

Опция hard жёстко привязывает дирректорию на клиенте к серверу и если сервер отвалится, то может зависнуть и ваш компьютер. Опция soft , как понятно из её названия, не такая категоричная.

После сохранения файла можно монтировать удалённую папку.