NFS. Настройка клиента. Аутентификация в сети. NIS и NIS+

Монтирование удаленных файловых систем

Монтирование файловых систем NFS осуществляется практически так же, как и монтирование файловой системы любого другого типа. Рассмотрим, как смонтировать файловую систему машины под управлением Linux, если роль файлового сервера выполняет Solaris (компьютер pxy работает под Linux, компьютер с адресом 192.168.5.33 под Solaris):

root@pxy# mount -t nfs 192.168.5.33:/nfst ./nfst
root@pxy# mount
/dev/hda1 on / type ext2 (rw)
none on /proc type proc (rw)
none on /dev/pts type devpts (rw,mode=0620)
/dev/hda3 on /usr type ext2 (rw)
/dev/hda2 on /var type ext2 (rw)
192.168.5.33:/nfst on /usr/home/filip/nfst type nfs
   (rw,addr=192.168.5.33)

Удаленная файловая система успешно смонтирована, о чем говорит последняя строка вывода mount.

Попробуем осуществить копирование файла:

root@pxy# cp /etc/mail/aliases /usr/home/filip/nfst/
root@pxy# ls /usr/home/filip/nfst/
aliases
root@pxy# ls -l /usr/home/filip/nfst/
total 1
-rw-r--r-- 1 root root 406 Jun 20 22:30 aliases

Файл был записан, как отсюда видно, от имени пользователя root и группы root. На самом деле, в выводе команды ls таится подвох. Ведь команда ls на локальной машине использует для получения соответствия между идентификатором в файловой системе и именем пользователя (группы) локальный файл /etc/passwd. Потенциальная опасность состоит в том, что на удаленном сервере и на локальной машине файлы /etc/passwd окажутся разными. В случае пользователя root это не важно, если только на сервере NFS пользователю root нашей машины разрешено монтировать файловую систему от имени root. В противном случае все файлы, которые локальный root будет записывать на удаленный сервер, будут записываться от имени nobody (или иного имени, если так определено конфигурацией сервера).

root@pxy# ls -ld /usr/home/filip/nfst/
drwxrwxr-x 2 root bin 512 Jun 20 22:30 /usr/home/filip/nfst/

Поскольку в нашем примере файл был записан от имени root, следует предположить, что настройки сервера NFS это позволяют. Проверим это на компьютере 192.168.5.33:

192.168.5.33# cat /etc/dfs/dfstab
# Place share(1M) commands here for automatic execution
# on entering init state 3.
#
# Issue the command '/etc/init.d/nfs.server start' to run
# the NFS daemon processes and the share commands, after
# adding the very first entry to this file.
#
# share [-F fstype] [ -o options] [-d "<text>"]
# <pathname> [resource]
# .e.g,
# share -F nfs -o rw=engineering -d "home dirs"
# /export/home2
share -F nfs -o root=pxy.spb.ru /nfst

Здесь, на компьютере 192.168.5.33, управляемом Solaris, разделяется общий каталог /nfst, а с компьютера pxy.spb.ru разрешено работать с этим каталогом от имени root. Следует осторожно раздавать подобные права и в большинстве случаев избегать разделения в сети каталогов с настроечной или секретной информацией.

По команде showmount можно получить список компьютеров, подключенных к серверу NFS:

192.168.5.33# showmount
pxy.spb.ru
www.spb.ru

Таким образом, на сервере NFS имя хозяина файла совпадает с тем, что мы видели с клиента NFS, а имя группы файла - нет, так как под одним и тем же идентификатором в файлах /etc/group на сервере и на клиенте значатся разные группы. На практике не следует допускать подобных расхождений, чтобы не возникало файлов, угрожающих безопасности системы. Синхронизация файлов passwd и group на сервере и клиентах или использование общей базы NIS помогут избежать путаницы в именах групп и владельцев файлов на сервере и клиенте NFS.

192.168.5.33# pwd
/nfst
192.168.5.33# ls -l
total 2
-rw-r--r-- 1 root root 406 Июн 20 22:30 aliases

Обратите внимание на одинаковое время создания файла с точки зрения команды ls сервера и клиента. В поле времени указывается время создания, которое записывает туда сервер NFS. Следует синхронизировать не только файлы group и passwd, но и время на сервере NFS и его клиентах, чтобы не было расхождений между клиентом и сервером при выполнении резервного копирования или выяснения "свежести" файлов.

Оптимизация производительности

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

Во-первых, чем быстрее работают диски сервера NFS, тем быстрее информация будет передана через сеть. Современные сети часто строятся на основе высокоскоростных (как минимум, 100-мегабитных) коммутаторов, поэтому диски даже чаще оказываются узким местом в производительности, чем сеть. Если говорить об архитектуре x86, то предпочтительнее использовать в серверах современные жесткие диски с поддержкой UltraDMA-100, которые позволяют отдавать данные приложению с диска со скоростью порядка 50 Мбайт/с.

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

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

В SunOS 4.x для кэширования запросов к удаленной файловой системе NFS использовался процесс biod, но в SunOS 5.x (т.е. с самых ранних версий Solaris - см. табл. 19.1) применяется автоматическое кэширование всех операций чтения и записи, в том числе и для файлов, расположенных на удаленных серверах NFS. Поэтому в специальном процессе biod (в некоторых системах UNIX аналогичный по смыслу процесс называется nfsiod ) нет необходимости в Solaris.

Выполним еще один эксперимент - сервером NFS будет компьютер ixy (Linux), а клиентом - компьютер под управлением Solaris. Все команды даются на компьютере- клиенте:

showmount -e ixy
export list for ixy:
/usr/home/filip/nfst (everyone)

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

cd /
ls
devices lost+found opt TT_DB
bin etc mnt platform tuition
boot export named.run proc usr
cdrom home net sbin var
core kernel nfst test vol
dev lib nsmail tmp xfn
mkdir nfsc
mount ixy:/usr/home/filip/nfst /nfsc

Проверим, получилось ли:

mount
/ on /dev/dsk/c0d0s0
read/write/setuid/intr/largefiles/xattr/onerror=panic/dev=
1980000 on Сбт Июл 3 18:59:13 2004
/boot on /dev/dsk/c0d0p0:boot
read/write/setuid/nohidden/nofoldcase/dev=19a3010 on Сбт
Июл 3 18:59:11 2004
/proc on /proc read/write/setuid/dev=2d80000 on Сбт Июл 3
18:59:12 2004
/etc/mnttab on mnttab read/write/setuid/dev=2e40000 on Сбт
Июл 3 18:59:12 2004
/dev/fd on fd read/write/setuid/dev=2e80000 on Сбт Июл 3
18:59:14 2004
/var/run on swap read/write/setuid/xattr/dev=1 on Сбт Июл
3 18:59:17 2004
/tmp on swap read/write/setuid/xattr/dev=2 on Сбт Июл 3
18:59:18 2004
/export/home on /dev/dsk/c0d0s7
read/write/setuid/intr/largefiles/xattr/onerror=panic/dev=
1980007 on Сбт Июл 3 18:59:18 2004
/nfsc on ixy:/usr/home/filip/nfst remote/read/write/setuid/
xattr/dev=2fc0002 on Сбт Июл 3 21:23:45 2004

Последняя строка вывода mount говорит о том, что все прошло успешно. Попробуем скопировать файл на сервер NFS:

cp /etc/dfs/dfstab /nfsc
cp: cannot create /nfsc/dfstab: Read-only file system

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

umount /nfsc

При экспорте файловых систем могут быть использованы параметры, указывающие, в каком режиме экспортируется файловая система. Они рассмотрены в лекции 18 в разделе "Параметры экспорта в /etc/dfs/dfstab".

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

Основные параметры для клиента NFS приведены в табл. 19.2. Их следует указывать в файле /etc/dfs/vfstab в поле параметров монтирования (последнее поле строки dfstab ). Пример /etc/dfs/vfstab приведен ниже.

Пример файла /etc/vfstab:

#device device mount FS fsck mount mount
#to mount to fsck point type pass at boot option
/proc - /proc proc - no -
fd - /dev/fd fd - no -
swap - /tmp tmpfs - yes -
pxy.gu.ru:/exprt - /home nfs - yes rw,noquota

Службы имен

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

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

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

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

В то же время в пределах домена NIS могут быть выделены так называемые сетевые группы, логически объединяющие некоторые компьютеры и пользователей. Сетевые группы описываются файлом /etc/netgroup. Этот файл, наряду с /etc/passwd и /etc/group, является одним из тех, что делаются общедоступными и централизованными в сети NIS.

Информация о компьютерах, пользователях, группах, сетевых группах и т.п. разделяется между компьютерами в сети посредством создания из текстовых файлов /etc/passwd, /etc/netgroup и ряда других так называемых карт NIS. Карта NIS - это хэшированная база данных, которую использует сервер NIS для ответа на запросы клиентов .

Для превращения файлов типа /etc/passwd в карту NIS требуется программа ypmake. Программы, связанные с NIS, имеют имена, начинающиеся с yp, поскольку в момент создания NIS носила название Sun Yellow Pages, но название пришлось изменить, поскольку словосочетание Yellow Pages оказалось зарегистрированной маркой другой компании. На именовании программ это не отразилось. Программа ypmake не изменяет исходный файл, она лишь генерирует на его основе новый файл - карту NIS.

На основе некоторых системных файлов из тех, что подлежат разделению через NIS, например, passwd, потребуется сгенерировать две карты, так как хэширование базы данных можно осуществить только по одному ключу, а искать в карте может понадобиться по нескольким ключам. В случае passwd это именно так - надо искать и UID по имени пользователя, и имя пользователя по UID. Поэтому генерируются две карты - passwd.byname и passwd.byuid.

Запуск сервисов NIS на компьютере осуществляется командой /usr/lib/netsvc/yp/ypstart, а их остановка - командой /usr/lib/netsvc/yp/ypstop.

Ниже рассказано, какие именно демоны запускаются на серверах и клиентах NIS, в том числе и при выполнении команды /usr/lib/netsvc/yp/ypstart.

Узнать о том, к какому домену причисляет себя компьютер, можно командой

domainname

Если эта команда сообщает, что компьютер не входит в домен NIS, ввести компьютер в домен можно командой domainname имя_домена_NIS, после чего следует проверить наличие и создать при необходимости файл /etc/defaultdomain и каталог /var/yp/binding/имя_домена_NIS.

В каталоге /etc/ могут быть заготовки файлов nsswitch.conf для разных конфигураций сети. Если вы просто копировали /etc/nsswitch.nis в /etc/nsswitch.conf, не забудьте о том, что при желании использовать DNS для поиска адресов компьютеров в сети, следует исправить строку, определяющую порядок использования служб имен для поиска адресов компьютеров так, чтобы dns предшествовало nis:

hosts: dns nis files

Для запрещения загрузки служб NIS при старте системы достаточно удалить файл /etc/defaultdomain.

В каталоге /var/yp может находиться файл makefile или Makefile для автоматизированной модификации настроек NIS и распространения карт по сети. Если он есть, имеет смысл изучить его и пользоваться, при необходимости, командой make для выполнения описанных в нем действий.

Еще немного о сетевых группах

Для удобства администрирования домена NIS следует применять сетевые группы. Формат записей в файле /etc/netgroup весьма прост:

имя_группы список_участников

В качестве списка участников принимаются имена членов группы, разделенные пробелами. Член группы - это либо имя другой сетевой группы, либо конструкция вида

(имя_компьютера, имя_пользователя, имя_домена_NIS)

Отсутствие любого из этих компонентов означает, что в соответствующей позиции подразумевается любой компонент. Например

(moon, ,columbia)

означает "любой пользователь компьютера moon в домене NIS columbia". Один компьютер может входить в несколько доменов NIS. Сетевые группы удобно использовать для назначения прав доступа к экспортируемым файловым системам NFS в командах share файла /etc/dfs/dfstab.

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

Сервер NIS хранит всю информацию о доменах NIS в подкаталогах каталога /var/yp. На главном сервере NIS должны быть запущены процессы ypserv (отвечает на запросы клиентов ), ypxfrd (обслуживает запросы от подчиненных серверов NIS для репликации информации), yppasswdd (демон изменения пароля пользователя).

Настройка главного сервера NIS

Для настройки необходимо выполнить следующие действия:

В Solaris компьютер автоматически настроится на работу с NIS, если будет найден файл /etc/defaultdomain. Эту работу выполнит программа ypstart, которая при старте системы проверяет, установлено ли имя домена в этом файле.

Демон ypserv запускается автоматически, если соблюдаются все следующие условия:

Демон ypbind запускается автоматически, если соблюдаются все следующие условия:

Серверы NIS одновременно являются и клиентами NIS, поэтому кроме серверных демонов, на них запускается и клиентский демон ypbind, который посылает запросы демону ypserv. По умолчанию демон ypbind пытается найти в сети сервер NIS своего домена, рассылая широковещательный запрос. Для того чтобы данный компьютер использовал строго определенный сервер NIS для получения информации с него, либо в случае, если сервер NIS находится в другом сегменте сети и широковещательный запрос до него не может дойти через маршрутизатор, следует запускать ypbind без ключа broadcast. Для настройки клиента для работы с определенным сервером NIS следует использовать команду ypset, а для настройки клиента NIS в целом используется ypinit с ключом с. Поэтому обе эти задачи вместе решаются так:

ypinit -c имя_сервера
ypset имя_сервера

Это настраивает запуск ypbind так, чтобы не происходило поиска сервера NIS в сети. В таком случае на клиенте NIS обязательно должен быть минимальный файл /etc/hosts, чтобы при запуске ypbind была возможность обратиться хотя бы к серверу NIS по имени.

Для изменения сценария запуска сервера NIS в Solaris следует модифицировать файл /etc/init.d/inetinit.

Настройка подчиненных серверов NIS

Настройка подчиненного сервера NIS всегда выполняется только после настройки главного. Отличие в этих настройках невелико, так как состоит только в том, что программе ypinit надо передать ключ -s (slave) вместо -m. Разумеется, инспектировать локальные копии файлов passwd и прочих на подчиненном сервере не требуется, ибо его задача - только принимать реплицированные карты NIS с главного сервера. Итак, для настройки подчиненного сервера следует:

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

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

Клиент не должен абсолютно во всем полагаться на сервер NIS. Следует иметь локальные файлы /etc/passwd, /etc/group и /etc/hosts. В файле passwd должны быть указаны основные предопределенные пользователи и, возможно, личная учетная запись системного администратора для экстренных случаев.

Помните о необходимости проверять порядок опроса служб имен (вначале NIS, затем локальные файлы) в /etc/nsswitch.conf. При переходе от аутентификации через локальные файлы к NIS или обратно не забывайте изменять файл /etc/nsswitch.conf в согласии с принятым решением о схеме аутентификации.

NIS: полезные программы

Некоторые утилиты помогают в администрировании NIS:

yppush - команда с главного сервера, требующая от всех подчиненных обновить свои копии карт NIS (дается при необходимости немедленного внесения изменений);

makedbm - создает хэшированную базу данных из текстового файла;

yppoll - выдает версию карты сервера;

yppasswd - меняет пароль пользователя.

ypcat ypservers - выводит список имен NIS -серверов домена;

ypcat -x - выводит карты NIS (аналогично ypwhich -x ).

База аутентификации NIS+

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

По сравнению с NIS, база NIS+ обладает лучшей безопасностью данных, более удобной системой хранения, и другим механизмом репликации баз данных по сети. Структуры баз данных, которые в NIS называются картами, в NIS+ называются таблицами.

Всего в NIS+ определено 16 таблиц:

Hosts, Bootparams, Password, Cred, Group, Netgroup, Aliases (псевдонимы компьютеров в домене, к почте не относятся), Timezone, Networks, Netmasks, Ethers, Services, Protocols, RPC, Auto_Home, Auto_master.

Для управления NIS+ следует использовать команды nisbladm (модификация таблиц NIS+), nisgrep (поиск в них), niscat (вывод таблицы NIS+).

Управление NIS+ доступно из Solaris Management Console.

В файле /etc/nsswitch.conf для указания того, что некую проверку следует производить в NIS+, служит ключевое слово nisplus.

Внимание! Нельзя в /etc/nsswitch.conf писать nis+ вместо nisplus!

Файл /etc/nsswitch.conf может выглядеть, например, так:

# /etc/nsswitch.conf
#
hosts: nis dns [NOTFOUND=return] files
networks: nis [NOTFOUND=return] files
services: files nis
protocols: files nis
rpc: files nis

Ключевая фраза [NOTFOUND=return] в записи hosts предписывает клиенту NIS прекратить поиск и вернуть ответ "не найдено", если нужный элемент не может быть найден в базе данных NIS или DNS. По умолчанию поиск производится во всех указанных источниках. Запись [NOTFOUND=return] имеет смысл для случая, когда серверы NIS и DNS недоступны, тогда поиск будет продолжен в файлах (источник информации - files ).

Работа над ошибками

Если при работе NIS возникают непредвиденные ошибки (например, не происходит передача карт NIS с главного сервера на подчиненные ), следует изучить файлы протоколов /var/yp/ypxfr.log на всех серверах. Если такого файла не существует, его надо создать и убедиться, что пользователь, от имени которого работают службы NIS, имеет право записи в этот файл.

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

ypwhich

Альтернатива NIS и NIS+ - LDAP. Подсистема PAM

Наиболее свежей тенденцией в мире UNIX и сетей вообще является использование протокола LDAP (Lightweight Directory Access Protocol - облегченный протокол доступа к каталогу, где каталог понимается как хранилище разнообразной информации, в том числе имен пользователей, паролей и т.п.) и соответствующих служб - демонов ldap для обеспечения доступа к информации о пользователях, компьютерах и их свойствах. В отличие от NIS, LDAP позволяет хранить информацию совершенно универсальным способом (в виде дерева объектов и атрибутов) и сейчас поддерживается основными игроками компьютерной индустрии.

Подробнее о протоколе LDAP можно узнать на web-сайте , откуда можно еще и загрузить свежую версию бесплатного ldap-сервера.

Таким образом, использование NIS и NIS+ не является сейчас повсеместным и не представляет собой наилучшую альтернативу простой синхронизации файлов из /etc на всех компьютерах сети с помощью rsync. Дело в том, что протокол NIS недостаточно защищен, а NIS+ - довольно сложен в настройке. Поэтому, если вы планируете использовать централизованную аутентификацию и авторизацию в сетях UNIX, имеет смысл обратить внимание на LDAP и, кроме того, не забывать о возможностях PAM: ведь с помощью этой подсистемы возможно производить аутентификацию и авторизацию с использованием любых источников - от файлов passwd до контроллеров домена Windows NT/2000.