Настройка NFS
Установка NFS
Debian
Перед тем, как приступить к установке сервера NFS, обновите индекс вашего системного репозитория, выполнив следующую команду в Терминале:
После обновления установите NFS. Сервер ядра, выполнив следующую команду в Терминале:
CentOS
или
После установки нужных пакетов, нужно запустить службы nfs-server и rpcbind, добавьте их в автозагрузку:
systemctl enable rpcbind
systemctl enable nfs-server
systemctl start rpcbind
systemctl start nfs-server
Настройка NFS сервера
Настройка сервера выполняется в два этапа: настройка файлов конфигурации для NFS, а затем запуск служб NFS.
Настройка файлов конфигурации
Есть три основных файла конфигурации, которые необходимо отредактировать для настройки сервера NFS:
/etc/exports, /etc/hosts.allow, и /etc/hosts.deny
Строго говоря, вам нужно только отредактировать /etc/exports, чтобы NFS заработала, но вы получите крайне небезопасную настройку. Вам также может понадобиться отредактировать сценарии запуска.
/etc/exports
Этот файл содержит список записей; каждая запись указывает на разделяемый том и способ его разделения. Полное описание всех возможностей настройки этого файла можно найти на страницах man (man exports), хотя приведенное здесь описание, вероятно, удовлетворит потребности большинства пользователей.
Запись в файле /etc/exports обычно выглядит следующим образом:
Где,
directory
Каталог, к которому необходимо предоставить общий доступ. Это может быть целый том, хотя и не обязательно. Если каталог является общим, то все каталоги входящие в него в той же файловой системе также будут общими.
machine1 и machine2
Клиентские машины, которые будут иметь доступ к каталогу. Машины могут быть перечислены по DNS-адресу или IP-адресу (например, machine.company.com или 192.168.0.8 ). Использование IP-адресов более надежно и безопасно.
optionXX
Список опций для каждой машины описывает, какой доступ будет иметь эта машина. Важными опциями являются:
ro: Каталог является общим только для чтения; клиентская машина не сможет в него записывать. Это значение используется по умолчанию.
rw: Клиентская машина будет иметь доступ к каталогу на чтение и запись.
root_squash/no_root_squash: По умолчанию любой файловый запрос, сделанный пользователем root на клиентской машине, рассматривается так, как будто он сделан пользователем nobody на сервере. (То, какому именно UID будет сопоставлен запрос, зависит от UID пользователя nobody на сервере, а не на клиенте). Если выбрана опция no_root_squash, то root на клиентской машине будет иметь такой же уровень доступа к файлам системы, как и root на сервере. Это может иметь серьезные последствия для безопасности, хотя может быть необходимо, если вы хотите выполнять на клиентской машине какую-либо административную работу, связанную с экспортированными каталогами. Не следует указывать эту опцию без веских причин.
subtree_check/no_subtree_check: Если экспортируется только часть тома, то процедура, называемая проверкой поддерева, проверяет, что файл, запрашиваемый клиентом, находится в соответствующей части тома. Если экспортируется весь том, то отключение этой проверки ускорит передачу.
async/sync: По умолчанию все команды exportfs, кроме самой последней версии (версия 1.11), используют асинхронное поведение, сообщая клиентской машине, что запись файла завершена, т.е. он записан в стабильное хранилище, когда NFS закончит передачу записи в файловую систему. Такое поведение может привести к повреждению данных при перезагрузке сервера, а опция sync предотвращает это.
Также есть некоторые другие параметры:
all_squash — делать все запросы анонимными.
anonuid — указывает uid анонимного пользователя.
anongid — указывает gid анонимного пользователя.
nohide — не скрывать поддиректории, если открыт доступ к нескольким каталогам.
crossmnt — эта опция аналогична nohide, но позволяет клиентам перемещаться с файловой системы, помеченной crossmnt, на смонтированные на ней экспортированные файловые системы. Таким образом, когда дочерняя файловая система «B» монтируется в родительской «A», установка crossmnt для «A» имеет тот же эффект, что и установка «nohide» для B.
secure / insecure — использовать для соединения только порты ниже 1024 или любые порты.
Предположим, у нас есть две клиентские машины, slave1 и slave2, имеющие IP-адреса 192.168.0.1 и 192.168.0.2 соответственно. Мы хотим предоставить этим машинам общий доступ к исполняемым файлам и домашним каталогам нашего программного обеспечения. Типичная настройка файла /etc/exports может выглядеть следующим образом:
Здесь мы передаем каталог /usr/local для slave1 и slave2 в формате readonly (ro), поскольку он, вероятно, содержит наше программное обеспечение и, возможно, не стоит разрешать slave1 и slave2 писать в него, в целях безопасности. С другой стороны, домашние каталоги должны экспортироваться в режиме read and write (rw), если пользователи хотят сохранять в них свои работы.
Если у вас большая сеть, то вы можете обнаружить, что в одной локальной сети находится множество компьютеров, которым требуется доступ к вашему серверу. Существует несколько способов упростить обращение к большому количеству машин. Во-первых, можно предоставить доступ сразу нескольким компьютерам, указав сеть и сетевую маску. Например, если нужно разрешить доступ ко всем машинам с IP-адресами от 192.168.0.0 до 192.168.0.255, то можно сделать такие записи:
Во-вторых, вы можете использовать в записи сетевые группы NIS. Чтобы указать сетевую группу в файле exportss, просто добавьте к имени сетевой группы символ "@". Подробнее о работе нетгрупп см. в NIS HOWTO.
В-третьих, вместо имен хостов можно использовать подстановочные знаки, такие как *.foo.com или 192.168. В ядрах серии 2.2 были проблемы с реализацией подстановочных знаков, которые были исправлены в ядре 2.2.19.
Однако следует помнить, что любое из этих упрощений может привести к риску безопасности, если в вашей группе или локальной сети есть машины, которым вы не доверяете полностью.
Следует сделать несколько предостережений относительно того, что не может (или не должно) экспортироваться.
Во-первых, если экспортируется каталог, то нельзя экспортировать его родительский и дочерний каталоги, если они находятся в одной файловой системе. Однако в экспорте обоих каталогов нет необходимости, поскольку включение родительского каталога в файл /etc/exports приведет к экспорту всех нижележащих каталогов в этой файловой системе.
Во-вторых, экспортировать файловую систему FAT или VFAT (т.е. MS-DOS или Windows 95/98) с помощью NFS - плохая идея. FAT не предназначена для использования на многопользовательской машине, и, как следствие, операции, зависящие от прав доступа, будут работать плохо. Более того, по имеющимся данным, некоторые из базовых конструкций файловых систем плохо согласуются с ожиданиями NFS.
В-третьих, файлы устройств и другие специальные файлы могут некорректно экспортироваться на не-Linux-клиенты.
/etc/hosts.allow and /etc/hosts.deny
Эти два файла определяют, какие компьютеры в сети могут использовать службы на вашем компьютере. Каждая строка файла содержит одну запись, перечисляющую службу и набор машин. Когда сервер получает запрос от компьютера, он выполняет следующее:
Сначала он проверяет hosts.allow, чтобы увидеть, соответствует ли компьютер правилу, перечисленному здесь. Если это произойдет, то доступ к машине разрешен. Если компьютер не соответствует записи в hosts.allow, сервер затем проверяет hosts.deny, чтобы проверить, соответствует ли клиент указанному там правилу. Если это произойдет, то машине будет отказано в доступе. Если клиент не соответствует ни одному из списков ни в одном из файлов, то доступ к нему разрешен.
В дополнение к управлению доступом к службам, обрабатываемым inetd (таким как telnet и FTP), этот файл также может управлять доступом к NFS, ограничивая подключения к демонам, которые предоставляют службы NFS. Ограничения вводятся для каждой отдельной услуги.
Первым демоном, к которому нужно ограничить доступ, является portmapper.
Этот демон, по сути, просто сообщает запрашивающим клиентам, как найти все службы NFS в системе. Ограничение доступа к portmapper - лучшая защита от того, что кто-то взломает вашу систему через NFS, потому что полностью неавторизованные клиенты не будут знать, где найти демонов NFS. Однако есть две вещи, на которые следует обратить внимание.
Во-первых, ограничения portmapper недостаточно, если злоумышленник по какой-то причине уже знает, как найти этих демонов.
И, во-вторых, если вы используете NIS, ограничение portmapper также ограничит запросы к NIS. Обычно это должно быть безвредно, поскольку вы обычно хотите ограничить NFS и NIS аналогичным образом, но просто будьте осторожны. (Запуск NIS, как правило, является хорошей идеей, если вы используете NFS, потому что клиентским компьютерам нужен способ узнать, кому принадлежат какие файлы на экспортируемых томах. Конечно, есть и другие способы сделать это, такие как синхронизация файлов паролей. Информацию о настройке NIS смотрите в руководстве по NIS.)
В целом, в NFS (как и в большинстве интернет-сервисов) хорошей идеей является явное запрещение доступа к IP-адресам, к которым вам не нужно разрешать доступ.
Первым шагом в этом является добавление следующей записи в /etc/hosts.deny:
Начиная с nfs-utils 0.2.0, вы можете быть немного осторожнее, контролируя доступ к отдельным демонам. Это хорошая мера предосторожности, поскольку злоумышленник часто сможет незаметно обойти portmapper. Если у вас более новая версия nfs-utils, добавьте записи для каждого из демонов NFS (О демонах поговорим далее; пока просто поместите записи для них в hosts.deny):
Даже если у вас более старая версия nfs-utils, добавление этих записей в худшем случае безвредно (поскольку они будут просто проигнорированы) и в лучшем случае избавит вас от некоторых проблем при обновлении. Некоторые системные администраторы предпочитают помещать запись ALL:ALL в файл /etc/hosts.deny, что приводит к тому, что любая служба, просматривающая эти файлы, запрещает доступ ко всем хостам, если это явно не разрешено. Хотя это более безопасное поведение, оно также может привести к неприятностям, например, когда вы устанавливаете новые службы, забываете, что установили их там, и ни за что на свете не можете понять, почему они не работают.
Далее нам нужно добавить запись в /etc/hosts.allow, чтобы предоставить доступ к любым хостам, к которым мы хотим иметь доступ. (Если мы просто оставим приведенные выше строки в /etc/hosts.deny, тогда никто не будет иметь доступа к NFS.) Записи в hosts.allow соответствуют формату:
Здесь host - это IP-адрес потенциального клиента; в некоторых версиях может быть возможно использовать DNS-имя хоста, но это настоятельно не рекомендуется.
Предположим, у нас есть настройки, описанные выше, и мы просто хотим разрешить доступ к slave1.foo.com и slave2.foo.com , и предположим, что IP-адреса этих машин равны 192.168.0.1 и 192.168.0.2 соответственно. Мы могли бы добавить следующую запись в /etc/hosts.allow:
Для последних версий nfs-utils мы бы также добавили следующее (опять же, эти записи безвредны, даже если они не поддерживаются):
Если вы собираетесь запускать NFS на большом количестве компьютеров в локальной сети, /etc/hosts.allow также допускает записи в стиле network/netmask таким же образом, как /etc/exports выше.
Настройка брандмауэра
Теперь важно убедиться, что сервер открыт для клиентов для доступа к общему контенту. Вам необходимо добавить правило, разрешающее трафик от указанных клиентов к порту NFS. Для этого используйте следующий синтаксис:
В нашем примере мы собираемся разрешить всю подсеть 192.168.0.0 для порта NF:
Теперь, чтобы проверить, успешно ли добавлено правило, выполните следующую команду в Терминале:
Теперь наш хост-сервер NFS настроен и готов к доступу указанным клиентам.
Если у вас в системе установлен firewalld откройте необходимые порты:
# firewall-cmd --permanent --add-port=111/tcp
# firewall-cmd --permanent --add-port=20048/tcp
# firewall-cmd --permanent --zone=public --add-service=nfs
# firewall-cmd --permanent --zone=public --add-service=mountd
# firewall-cmd --permanent --zone=public --add-service=rpc-bind
# firewall-cmd --reload
Применение настроек каталогов
Чтобы применить новые настройки NFS каталогов, выполните:
# exportfs -a
Если вы не можете найти команду exportfs , то вы можете убить nfsd с помощью флага -HUP (подробности см. в справочных страницах kill).
И перезапустите nfs-сервер:
# systemctl restart nfs-server
На этом установка и настройка nfs-сервера закончена и можно приступить к настройке клиента.
Настройка клиента NFS
Установка nfs на клиентской машине
Debian
Сначала обновите индекс репозитория клиентского компьютера, выполнив следующую команду в Терминале:
Затем установите клиентское приложение NFS, известное как NFS common, запустив следующую команду в Терминале:
CentOS
Для настройки NFS клиента, нужно также установить пакет nfs-utils. Для CentOS 7:
# yum install nfs-utils -y
Для CentOS 8:
# dnf install nfs-utils -y Добавляем сервисы в автозагрузку и включаем:
# systemctl enable rpcbind
# systemctl enable nfs-server
# systemctl start rpcbind
# systemctl start nfs-server
Монтирование удаленных каталогов
Прежде чем начать, вы должны перепроверить, чтобы убедиться, что ваша программа монтирования достаточно новая (версия 2.10m, если вы хотите использовать версию 3 NFS), и что клиентский компьютер поддерживает монтирование NFS, хотя большинство стандартных дистрибутивов поддерживают. Если вы используете ядро 2.2 или более позднюю версию с /procфайловой системой, вы можете проверить последнюю, прочитав файл /proc/filesystemsи убедившись, что в нем есть строка, содержащая nfs.
Если нет, то набрав insmod nfs, он может волшебным образом появиться, если NFS был скомпилирован как модуль; в противном случае вам нужно будет собрать (или загрузить) ядро со встроенной поддержкой NFS. Как правило, ядра, в которых не скомпилирована NFS, выдают очень конкретную ошибку при выполнении приведенной ниже команды монтирования.
Чтобы начать использовать машину в качестве клиента NFS, вам понадобится программа portmapper, работающая на этой машине, а для использования блокировки файлов NFS вам также понадобятся rpc.statd и rpc.lockd, работающие как на клиенте, так и на сервере. Самые последние дистрибутивы запускают эти службы по умолчанию во время загрузки.
Теперь, когда portmap, lockd и statd запущены, вы сможете монтировать удаленный каталог с вашего сервера так же, как вы монтируете локальный жесткий диск, с помощью команды mount. Продолжая наш пример, описанный выше, предположим, что наш указанный выше сервер называется master.foo.com , и мы хотим смонтировать каталог /home на slave1.foo.com . Все что нам нужно для этого сделать на клиенте slave1.foo.com это ввести от пользователя root следующее:
И каталог /home на master будет отображаться как каталог /mnt/home на slave1.
Обратите внимание, что это предполагает, что мы заранее создали каталог /mnt/homeкак пустую точку монтирования:
mkdir /mnt/home
Вы можете размонтировать файловую систему, набрав:
Так же, как и для локальной файловой системы.
Добавление файловой системы NFS в автозагрузку
Файловые системы NFS можно добавить в ваш /etc/fstab файл так же, как и локальные файловые системы, чтобы они монтировались при запуске вашей системы. Единственное отличие состоит в том, что тип файловой системы будет установлен на nfs , а порядок дампа и fsck (последние две записи) должен быть установлен на ноль. Итак, для нашего примера выше запись в /etc/fstab будет выглядеть так:
См. справочные страницы для fstab , если вы не знакомы с синтаксисом этого файла. Если вы используете автомонтирование, такое как amd или autofs , параметры в соответствующих полях ваших списков монтирования должны выглядеть очень похожими, если не идентичными.
Варианты монтирования
Мягкое и жесткое монтирование
Есть несколько опций, которые вы должны добавить сразу. Они управляют тем, как клиент NFS обрабатывает сбой сервера или сбой сети. Одна из замечательных особенностей NFS заключается в том, что она может изящно справиться с этим. Если вы правильно настроите клиентов. Существует два различных режима отказа:
soft
Если запрос файла завершается неудачей, клиент NFS сообщит об ошибке процессу на клиентском компьютере, запрашивающему доступ к файлу. Некоторые программы могут справиться с этим хладнокровно, большинство - нет. Не рекомендуется использовать этот параметр; это приведет к повреждению файлов и потере данных. Особенно вам не следует использовать это для почтовых дисков - если, конечно, вы дорожите своей почтой.
hard
Программа, получающая доступ к файлу в файловой системе, подключенной к NFS, зависнет при сбое сервера. Процесс не может быть прерван или уничтожен (за исключением "верного уничтожения"), если вы также не укажете intr. Когда сервер NFS снова подключится к сети, программа продолжит работу с того места, где она была. Рекомендуется использовать hard,intr во всех файловых системах, подключенных к NFS.
Исходя из предыдущего примера, fstab теперь это будет выглядеть так:
Параметры монтирования rsizeи wsizeопределяют размер фрагментов данных, которые клиент и сервер передают друг другу туда и обратно.
Значения по умолчанию могут быть слишком большими или слишком маленькими; нет размера, который хорошо работает на всех или большинстве настроек. С одной стороны, некоторые комбинации ядер Linux и сетевых карт (в основном на старых машинах) не могут обрабатывать блоки такого размера. С другой стороны, если они могут обрабатывать большие блоки, больший размер может быть быстрее.
Правильный выбор размера блока является важным фактором производительности и обязательным условием, если вы планируете использовать сервер NFS в производственной среде.
После сохранения файла fstab, можно применить его командой:
# mount -a
Итак, мы настроили и подключили удаленное NFS хранилище, которое можно использовать для прозрачного сетевого доступа к общему ресурсу с различных хостов. Можно складывать в NFS каталог бэкапы, хранить там файлы ISO образов и т.д.
Оптимизация NFS
Для изучения данной темы рекомендую ознакомиться с 5 разделом в "Linux NFS-HOWTO"
UID- и GID-ассоциирование
Идентификаторы пользователей и групп так же важны для NFS, как и для любой другой части файловой системы Linux. Но в отличие от UID и GID, которые вы назначаете при создании новых учетных записей пользователей, вы можете не иметь никакого контроля над UID и GID, назначаемыми клиентами вашего сервера NFS. NFS предоставляет несколько инструментов, которые помогут вам справиться с возможными проблемами, возникающими из-за этого.
Одной из наиболее очевидных проблем, связанных с моделью безопасности доверенного хоста, является работа с учетной записью root. Очень маловероятно, что вы хотите, чтобы люди, имеющие root-доступ к вашим клиентам, также имели root-доступ к вашему серверу. По умолчанию NFS предотвращает это с помощью параметра root_squash, который сопоставляет запросы, содержащие корневые UID и GID, с nobody UID и GID. Таким образом, если кто-то вошел в систему клиента как root, ему предоставляются только глобальные разрешения на сервере. Вы можете отменить это с помощью параметра no_root_squash, но делайте это с осторожностью. Параметр no_root_squash открывает больше дыр для использования злоумышленниками, что никогда не бывает хорошо.
Используйте all_squash , чтобы сопоставить каждого пользователя клиентской системы с пользователем nobody . Например, следующая запись экспортирует каталог /pub каждому клиенту:
Он предоставляет доступ только для чтения к каталогу каждому клиенту и ограничивает каждого пользователя этих клиентов глобальными разрешениями, предоставленными пользователю nobody. Таким образом, пользователи могут читать только те файлы, которые имеют глобальные разрешение на чтение.
Также возможно сопоставить каждого пользователя клиента с определенным идентификатором пользователя или идентификатором группы. Опции anonuid и anongid предоставляют эту возможность. Эти параметры наиболее полезны, когда у клиента есть только один пользователь, и клиент не назначает этому пользователю UID или GID-идентификатор.
Прекрасным примером этого является ПК с Microsoft Windows, на котором запущена NFS. У ПК обычно есть только один пользователь, и они не используют UID или GID. Чтобы сопоставить пользователя ПК с действительным идентификатором пользователя и идентификатором группы, введите такую строку в файл /etc/exports:
Здесь имя хоста компьютера Кристин — robin. Запись предоставляет этому клиенту доступ на чтение/запись к каталогу /home/kristin. Опция all_squash сопоставляет каждый запрос от этого клиента с определенным идентификатором пользователя; но на этот раз вместо «nobody» он сопоставляется с UID и GID, определенными параметрами anonuid и anongid. Конечно, чтобы это работало правильно, 1001:1001 должна быть парой UID и GID, назначенной Кристин в файле /etc/passwd на сервере.
Советую ознакомиться с ресурсами ниже, они позволят обрести полное понимание работы NFS, а также объяснят основы безопасного конфигурирования сетевой файловой системы. Ресурсы представлены на английском языке:
Last updated
