Глава 18. Сетевой протокол Network File System 737

циями, ошибки в программном обеспечении файловых систем и нерешенные вопросы, связанные с протоколами совместного использования файлов.

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

22. Серверная часть протокола nfs

Говорят, что сервер NFS “экспортирует” каталог, когда он делает этот каталог доступ­ ным для использования другими компьютерами. Системы Solaris и HP-UX вместо слова “экспорт” используют словосочетание “совместное использование”. Для того чтобы не создавать путаницы, мы будем на протяжении этой главы использовать термин “экспорт”.

В версии NFSv3 процесс, используемый клиентами для монтирования файловой си­ стемы (т.е. для того, чтобы узнать секретный ключ), отделен от процесса, используемого для доступа к файлам. Эти операции используют отдельные протоколы, а запросы обра­ батываются разными демонами: mountd — для запросов на монтирование и nfsd — для реальной файловой службы. В некоторых системах эти демоны называются rpc.nfsd и rpc.mountd, поскольку они основаны на протоколе RPC (а значит, для их запуска ну­ жен сервер postmap). В этой главе для простоты мы будем пропускать префикс rpc.

Версия NFSv4 не использует демон mountd вообще. Однако, если не все ваши кли­ енты используют версию NFSv4, демон mountd следует выполнять.

На сервере NFS демоны mountd и nfsd должны запускаться при загрузке системы и должны работать на протяжении всего времени ее функционирования. Сценарии за­ грузки системы обычно автоматически запускают этих демонов, если существует какая- либо конфигурация экспорта. Имена сценариев запуска сервера NFS для каждой из рас­ сматриваемых нами платформ перечислены в табл. 18.1.

Таблица 18.1. Сценарии запуска сервера NFS

Система Путь к сценарию



Ubuntu /etc/init.d/nfs-kernel-server /etc/init.d/nfs-common

SUSE /etc/init.d/nfs.servera

Red Hat /etc/rc.d/init.d/nfs

Solaris /etc/init.d/nfs.server

HP-UX /sbin/init.d/nfs.server

AIX /etc/rc.nfs

а /etc/init.d/nfs монтирует клиентскую файловую систему NFS.

Протокол NFS использует единую базу данных для управления доступом, которая определяет, какие файловые системы должны быть экспортированы и какие клиен­ ты должны их монтировать. Оперативная копия этой базы данных обычно хранится в файле xtab (sharetab — в системах Solaris и HP-UX), а также во внутренних табли­ цах ядра. Поскольку файлы xtab и sharetab не предназначены для чтения людьми,

для добавления и модификации записей в них используются вспомогательные команды exports или share. Для удаления записей из таблицы экспорта используются команды exportfs -u или unshare.

Монтирование бинарного файла вручную — неблагодарная задача, поэтому в большин­ стве систем предполагается, что пользователь монтирует текстовый файл, а не перечисля­ ет экспортируемые системные каталоги и их установки доступа. Система может прочитать этот текстовый файл при загрузке и автоматически создать файл xtab или shatretab.

В большинстве систем каталог /etc/exports является каноническим списком, до­ ступным для чтения экспортируемых каталогов. Его содержимое можно прочитать с помощью команды exportfs -а. В системах Solaris и HP-UX каноническим списком