NFSv4
Сервер NFSv4 для NFSv[34] клиентов
Общая настройка сервера NFSv4
Задача — экспортировать часть ФС (/ftp/pub) с iso`шками и репозиториями (часть репозиториев — подмонтированные iso).
Применил лобовое решение, описанное в http://www.citi.umich.edu/projects/nfsv4/linux/using-nfsv4.html#exports, адаптираванно для моего случая:
mkdir -p /export/pub mount --rbind /ftp/pub /export/pub
Теперь в /export/pub доступно всё содержимое /ftp/pub, в том числе — и смонтированные туда /ftp/pub/foo* (содержимое соответствующего /ftp/pub/ISO/foo*.iso). Несмотря на это, в /etc/exports придётся упомянуть каждую из неявно (за счёт mount --rbind) подмонтированных в /export/pub/* ФС: иначе клиенты их видеть не будут.
В /etc/exports мне потребовалось примерно следующие (сильно упрощённо):
/export (ro,nohide,fsid=0) /export/pub (ro,nohide,fsid=1) /export/pub/foo1 (ro,nohide,fsid=2) /export/pub/foo2 (ro,nohide,fsid=3) /export/pub/foo<N> (ro,nohide,fsid=<N>)
При этом числа в параметре fsid должны различаться. При совпадении — видна только одна из ФС с совпадающими fsid (нарвался на такое при повторяющемся fsid=0, но детально вопрос не исследовал).
Поправка от ns@ (http://lists.altlinux.org/pipermail/sysadmins/2006-July/001723.html):
Насколько я помню, fsid надо указывать только у /export. То есть только там, где значение должно равняться "0". Эта точка станет корнем для NFSv4.
То есть код ниже, тоже работает:
/export (ro,nohide,fsid=0) /export/pub (ro,nohide) /export/pub/foo1 (ro,nohide) /export/pub/foo2 (ro,nohide) /export/pub/foo<N> (ro,nohide)
Если невдаваться в подробности (настройка firewall — ниже), то с сервером всё.
Монтирование клиентом
На клиенте всё монтируется в одной точке, но пути к ресурсу для NFSv4 и NFSv3 разлечаются:
mount -t nfs4 <сервер>:/ <точка монтирования> mount -t nfs <сервер>:/export <точка монтирования>
NFSv4 и NFSv3 через firewall
Так как для меня критична одновременная поддержка клиентов обоих версий NFS (v4 и v3), то фиксацию и открытие портов выполнял по рецептам для NFSv3, как для более гемаройного варианта. (Меня убеждают что NFSv4 требования мягче. Причин не верить у меня нет, но и специально не проверял.) Использовал http://ipesin.linux.kiev.ua/translations/rhm/tipstricks10.htm и http://nfs.sourceforge.net/nfs-howto/ar01s06.html
Фиксировал и открывал на серверном firewall следующие:
- nfs — работает по 2049 tcp/udp по умолчанию. Если требуется сдвинуть специально — см. altbug:9769
- mountd — параметром MOUNTD_PORT (в /etc/sysconfig/nfs)
- nlockmgr — параметрами nlm_tcpport и nlm_udpport модуля lockd (строка вида options lockd nlm_tcpport=N nlm_udpport=M в /etc/modules.conf)
- portmapper — стандартные 111 tcp/udp
С firewall на клиентах пока не экспериментировал. Есть подозрение, что там придётся фиксировать и открывать порт для status (см. altbug:9770 .
Частые проблемы
Stale NFS file handle
Бывает, что при перезагрузке NFS-сервера обращение к смонтированным ресурсам на NFS-клиентах выдаёт сообщение “Stale NFS file handle”. Обычно это происходит из-за смены идентификатора файловой системы при перезагрузке. Если для обычных устройств он может быть получен из номера устройства, то при использовании LVM он формируется более случайным образом. В man написано что нужно делать:
fsid=num
This option forces the filesystem identification portion of the file handle and file attributes used on the wire to be num instead of a number derived from the major and minor number of the block device on which the filesystem is mounted. Any 32 bit number can be used, but it must be unique amongst all the exported filesystems.
This can be useful for NFS failover, to ensure that both servers of the failover pair use the same NFS file handles for the shared filesystem thus avoiding stale file handles after failover.
Some Linux filesystems are not mounted on a block device; exporting these via NFS requires the use of the fsid option (although that may still not be enough).
Пример:
/nfs4exports 192.168.18.129/26(ro,sync,insecure,no_root_squash,no_subtree_check,fsid=2)