Страница:
использовал именованный сервер любой NIS области которой может быть. Если,
однако, Вы перемещаете вашу машину между различными NIS областями
часто, то Вы возможно захотите сохранить информацию для отдельных
областей в картотеке yp.conf. Вы можете иметь информацию относительно
серверов для различных NIS областей в Yp.conf, прибавляя NIS название
области к формулировке сервера. Для образца, Вы могли бы измен"типовой
файл для портативной ЭВМ, чтобы это выглядило подобно этому:
# yp.conf - YP configuration for NYS library.
#
server vbardolino winery
server vstout brewery
Это позволяет Вам выдать портативную ЭВМ в любой из двух областей,
просто при установке желательной NIS области при начальной загрузке
введите команду названия.
После создания этого базисного файла конфигурации, и уверенности
в том это - всемирно - читаемый, Вы запустить ваш первый критерий,
чтобы проверить, можете ли Вы подсоединиться к вашему серверу.
Удостоверитесь, что выбрано отображение вашего сервеа, подобно
- 186 -
hosts.byname, и испытанию, чтобы восстановить, используя ypcat утилиту.
Ypcat, подобно всем другим административным NIS инструментальным
средствам, должен жить в /usr/sbin.
# ypcat hosts.byname
191.72.2.2 vbeaujolais vbeaujolais.linus.lxnet.org
191.72.2.3 vbardolino vbardolino.linus.lxnet.org
191.72.1.1 vlager vlager.linus.lxnet.org
191.72.2.1 vlager vlager.linus.lxnet.org
191.72.1.2 vstout vstout.linus.lxnet.org
191.72.1.3 vale vale.linus.lxnet.org
191.72.2.4 vchianti vchianti.linus.lxnet.org
Вывод, который Вы получаете, должен быть на подобие вышепоказанного.
Если Вы получаете сообщение об ошибках взамен, которое говорит "Can't
bind to server which serves domain" или что-нибудь на подобие, затем
или NIS название области, которое не имеет сервер соответствия,
определенный в yp.conf, или сервер - unreachable по некоторым
причинам. В последнем случае, удостоверитесь в том, что ping множеству
производится положительный результат, и что это действительно запу Вы
можете проверить последний, используя rpcinfo, который должен произвести
следующий вывод:
# rpcinfo -u serverhost ypserv
program 100004 version 2 ready and waiting
11.6 Выбор правых отображений
Удостоверьтесь в том, что Вы можете достичь NIS сервера, Вы должны
решить который конфигурационный файл, чтобы заменить или увеличить с
NIS отображениями. Обычно, Вы захотите использовать NIS отображения
для множества и функций поиска пароля. Вышеупомяну тый особенно полезен,
если Вы не запускаете BIND. Последний разрешает всем
пользователям зарегестрироваться на их account из любой системы в NIS
области; это обычно требует разделения центрального /местного к Это
объяснено подробно в разделе 11.7 ниже. Другое отображение, подобно
services.byname, не такое драматическое увеличение, но сохраняют Вас
- 187 -
от некоторой работы редактирования, если Вы устанавливаете любые
сетевые приложения которые используют сервисное название, то это не в
стандартном файле услуг.
Вообще, Вы хотите иметь некоторую свободу выбора когда поиск-
функция использует локальные файлы, и когда это делает запрос NIS
сервера. NYS позволяет Вам сконфигурировать порядок, в котором функция
обращается к этим услугам. Это управляется через картотеку
/etc/nsswitch.conf, который замещает обслуживание названия, но
конечно не ограничивает название обслуживание. Для любой из функций
поиска данных это содержит линию, именующие услуги, чтобы использовать.
Правильный порядок услуг зависит от типа данных. Это вряд ли
то, что services.byname отображение будет содержать отличие входов
из тех в локальном файле услуг; это может только содержать больше. Так
хороший выбор может быть, чтобы сделать запрос локальных файлов сначала, и
проверять NIS только если сервисное название не было найдено. Hostname
информация, с другой стороны, может изменятся пченю часто, так, чтобы DNS
или NIS сервер всегда имел наиболее точный accoun файл сохран как
дублиррование, если DNS и NIS терпел неудачу. В этом случае, Вы захотели
бы проверить локальный последний файл.
Пример ниже показывает, как сконфигурировать gethostbyname
(2), gethostByaddr (2), и getservbyname функции (2) как описано выше. Они
будут перечисленны как услуги по очереди; если поиск идет хорошо, то
результат будет возвращен, иначе следующее обслуживание осуждено.
# small sample /etc/nsswitch.conf
#
hosts: nis dns files
services: files nis
Полный список услуг, которые могут использоваться с записью в
Nsswitch.conf файле показыны ниже. Фактические отображения, файлы,
серверы и вещи, которые делают запрос зависят от названия записи.
- 188 -
Nisplus или nis + использует NIS + сервер для этой области.
Локализация сервера получена из картотеки /etc/nis.conf.
Nis Использует текущий NIS сервер этой области. Локализация сервера
делал запрос, сконфигурированный в картотеке yp.conf как показано в
предыдущем разделе. Для записи множеств, отображения Hosts.byname и
hosts.byaddr делают запрос.
-176 -
dns использует DNS сервер. Этот служебный тип полезен только для
записи хоста. Сервера делающие запрос, все еще определяются в соответствии
cо стандартом resolv.conf файла.
files использует локальный файл, такой как /etc/hosts файл для хост
записи.
dbm ищет информацию из DBM файлов, размещенных в /var/dbm. Имя,
используемое для файла - соответствующего NIS отображение.
В настоящее время, NYS поддерживает следующие nsswitch.conf записи:
hosts,
networks, passwd, group, shadow, gshadow, services, protocols, rpc, и
др. Другие записи возможно могут быть добавленны.
Рисунок 11.6 показывает более полный пример, который демонстрирует
другую
&осогенность nsswitch.conf: ключевое слово [NOTFOUND=return] в записях
хостов сообщила бы NYS - вернуться, если желаемый пункт не был найден в NIS
или в DNS база данных. То есть NYS продолжит искать локальные файлы, только
если обращения к NIS и DNS серверам терпят неудачу по какой-либо другой
причине. Локальные файлы будут затем только использоваться при начальной
загрузке и как backup, когда NIS сервер выключен.
11.7 Использование passwd и группы Maps
Одно из главных приложений NIS находится в синхронизации пользователя
и account информации относительно всех множеств в NIS области. К концу, Вы
- 189 -
обычно хранит только малый локальный файл /etc/passwd, к которому
добавлена site-wide информация из NIS отображений. Однако, просто
предоставления возможности NIS поиска для этого обслуживания в
nsswitch.conf не вполне достаточно.
Полагаясь на информацию пароля, распределенную NIS, Вы сначала должны
удостовериться, что числовая идентичность пользователя всех пользователей,
которые у Вас есть в Вашем локальном passwd файлесоответствуют идеи NIS
сервера относительно идентичности пользователя. Вы возможно захотите
использовать это для других целей также, подобно установке NFS значений от
других хостов на вашей сети.
# /etc/nsswitch.conf
#
hosts: nis dns [NOTFOUND=return] files
networks: nis [NOTFOUND=return] files
services: files nis
protocols: files nis
rpc: files nis
Рисунок 17. Примерный nsswitch.conf файл.
Если любая из числовых идентичности в /etc/passwd или /etc/group
отклоняется от тех, которые в maps, то Вы должны скорректировать файл
ownerships для всех файлов, которые принадлежат этому пользователю. Сначала
Вы должны заменить все uids и gids в passwd и в группах новых значений;
затем найдите вуе фвйлы, которые принадлежат пользователям и былы только
что изменены, и в заключение замените их ownerships. Примите новости
используемые для того, чтобы иметь идентичность пользователя была бы 9, и
okir имел бы идентичность пользователя 103, которые были заменены на
некоторое другое значение; Вы могли бы затем выпорлнить следующие команды:
# find / -uid 9 -print >/tmp/uid.9
# find / -uid 103 -print >/tmp/uid.103
# cat /tmp/uid.9 | xargs chown news
- 190 -
# cat /tmp/uid.103 | xargs chown okir
Важно то, что Вы выполняете эти команды с новым, установленным passwd
файлом, и что Вы собираете все имена файлов прежде, чем Вы изменените
ownership любого из них. Для того, чтобы модифицировать ownerships группы
файлов, Вы должны использовать похожую команду.
Сделав это, численный uid's и gid's на вашей системе согласиться с
теми хостами, которые расположенны в Вашей NIS области. Следующий шаг будет
- прибавить линии конфигурации к nsswitch.conf, который включают NIS поиски
для пользователя и информации группы:
# /etc/nsswitch.conf - passwd and group treatment
passwd: nis files
group: nis files
Это заставляет команду входа в систему, и всех ее друзей сначала
сделать запрос NIS maps, когда пользователь пробует log in, и если этот
поиск терпит неудачу - обратно обращается к локальным файлам. Обычно, Вы
удалите почти всех пользователей из Вашего локального файла, и только
оставите записи для root и generic accounts подобно почте. Это потому, что
некоторые насущные задачи системы могут требовать к map uids имя
пользователя или наоборот. Например, административный cron job может
выполнить команду su, для того чтобы временно стать новостями, или UUCP
подсистема может отправлять по почте отчет состояния. Если новости и
uucp не имеют вход в локальный файл passwd, то эти jobs будут, к сожалению,
терпеть неудачу в течение&NIS"brownout.
Имеются две большие проблемы: с одной стороны, установка, как уже
было описано в начале, до сих пор работает только для наборов программ
входа в систему, которые не используют теневой пароль, подобно тем, что
включены в util-linux пакет. Путаница при использовании теневых паролей с
NIS будет объяснена ниже. С другой стороны, команды входа в систему - не
единственые, которые обращаются к passwd файлу - посмотрите на команду ls,
которую большинство людей использует почти постоянно.
- 191 -
При выполнении длинной распечатки, ls выделит символические имена для
пользователя и группу владельцев файла; то есть для каждого uid и gid это
представляет собой целую схватку, это должно сделать запрос на NIS сервер,
только один раз. Это ужасно замедлит выполнение, если ваша локальная сеть -
clogged, или, еще хуже, когда NIS сервер не на той же самой сети, для
этого датаграммы должны пройти через программу маршрутизации.
Но пока это еще не вся история. Вообразите, что случится если
пользователь захочет изменить свой пароль. Обычно, она вызовет passwd,
который считает новый пароль и модифицирует локальный файл passwd. Это
невозможно сделать с NIS, так как с тех пор файл локально больше не
доступен, но если пользователи подсоединились к NIS серверу, и вдруг
захотели изменить пароль, то дляч этого, к сожалению нет опции. Поэтому,
NIS обеспечивает отпуск в замене для passwd, называемого yppasswd, который
делает аналогичную вещь в присутствии NIS. Для изменения пароля на хост
сервере, но в контакт с yppasswdd daemon на том же самом хосте через RPC, и
обеспечивает его модифицируемой информацией пароля. Обычно, Вы
устанавливаете yppasswd для нормальной программы, делая что - нибудь вроде
этого:
# cd /bin
# mv passwd passwd.old
# ln yppasswd passwd
В то же самое время Вы должны установить rpc.yppasswdd на сервер и
запустить его из rc.inet2. Это эффективно слроет любые искожения NIS от
ваших пользователей.
11.8 Использование NIS с Shadow Support
Не имеется никакой NIS поддержки для мест, которые используют теневой
вход в систему набора программ. John F. Haugh, автор теневого набора
программ, недавно выпущенной версии теневых библиотечных функций, описанных
GNU библиотекой GPL к comp.sources.misc. Это уже имеет некоторую поддержку
- 192 -
для NIS, но она пока еще не полна, и файлы пока еще не добавлены к
стандарной библиотеке для C. С другой стороны, при публикации информации из
/etc/shadow через NIS вид поражения цели теневого набора программ.
Хотя NYS функции поиска пароля не используют shadow.byname map или
что - либо аналогичное, очевидно NYS поддерживает использование локального
/etc/shadow файла. Когда NYS реализация getpwnam обращается к просмотру
информации, связанной с данным login именем, средства, точно определенные
passwd записью в nsswitch.conf делают запрос. Nis обслуживание будет просто
искать имя в passwd.byname map на NIS сервере. Обслуживание файлов, однако,
проверит, существует ли /etc/shadow, и если существует, то попробует
открыть это. Если ни один из файлов не присутствует, или если пользователь
не имеет привилегию root, то происходит возвращение к обычной работе поиска
информации пользователя в /etc/passwd. Однако, если теневой файл существует
и может быть открыт, то NYS извлечет пароль пользователя из shadow.
Getpwuid функция соответственно выполняется. В этом режиме, binaries,
компилируемый с NYS, будет иметь дело с локальной установкой теневого
набора программ.
11.9 Использование традиционного NIS кода.
Если Вы используете код клиента, который находится в стандарте libc,
то конфигурация NIS клиента немного отлична. С одной стороны, это
использует ypbind daemon для того, чтобы передать информацию для активных
серверов скорее чем считывать эту информацию из файла конфигурации. Вы
следовательно должны удостоверится в том, что бужет запущен ypbind при
начальной загрузке. Он должен быть вызван после установленной NIS области,
и RPC portmapper тоже должен быть запущен. Вызов ypcat нужен для того,
чтобы проверить работает ли сервер так, как он должен (см. выше).
Недавно, имелось некоторое число bug reports, которые сообщают, что
NIS терпит неудачу, сообщая при этом: "clntudp create: RPC: portmapper
failure - RPC: unable to receive''.
Это все из-за несовместимого изменения в способе, как ypbind
связывается с библиотечными функциям. Получая последние источники для NIS
- 193 -
утилит и перетранслируя их, должна быть исправлена эта задача. (5)
Также, способ традиционного NIS решает это, как соединить NIS
информацию с этим из локальных файлов отклоняемую от используемого NYS.
Например, чтобы использовать NIS отображение пароля, Вы должны включить
следующую линию где-нибудь в Вашем /etc/passwd map:
+: *:0:0:::
Это маркирует место где функции поиска пароля "вставляют" NIS
отображения. Вставка подобной линии (минус последние два двоеточия) в
/etc/group делают тот же самое для group. * maps. Для того, чтобы
использовать hosts.* maps, распределенные NIS, измените order line в
host.conf файле. Например, если Вы хотите использовать NIS, DNS, и файл
/etc/hosts (в том порядке), то Вы должны изменить эту линию на:
order yp bind hosts
Традиционная NIS реализация не поддерживает никакие другие
отображения в настоящее время.
5. Источник для yp-linux может быть получен из ftp.uniрaderborn.de в
каталоге /pub/Linux/LOCAL.
12. Сетевая файловая система (NFS)
NFS, the network file system, является возможно наиболее видной
сетью услуг, использующей RPC. Это позволяет обращаться к файлам на
отдаленных хостах точно
тем же самым способом, как пользователь обратился бы к любым"
локальным файлам. Сделано возможным смешением kernel функциональных
возможностей на клиентской стороне (которая использует отдаленную файловую
систему) и NFS сервер на стороне сервера (который обеспечивает файл
данных). Этот доступ к файлу полностью очевиден клиенту, и работает через
все разнообразие серверов и архитектуры хостов.
- 194 -
NFS предлагает ряд преимуществ:
+ Данные, к которым обращаются все пользователи, могут быть сохранены
на центральном хосте, с клиенами устанавливающими этот каталог при
начальной загрузке. Например, Вы можете сохранить все accounts
пользователей на одном хосте, и иметь все хосты на Вашем сетевом mount
/home от того хоста. Если оно установлено бок о бок с NIS, то пользователи
могут затем войти в любую систему, и все еще работать на одном множестве
файлов.
+ Данные, потребляющие большие количества дискового пространства
могут быть сохранены в единственном хосте. Например, все файлы и программы
относящиеся к LaTeX и METAFONT могут быть сохранены и поддерживаться в
одном месте.
+ Административно-управленческая информация может быть сохранена в
адинственном хосте. Нет нужды использовать rcp для того, чтобы установить
тот же самый глупый файл на 20 различных машин.
Linux NFS - в значительной степени работа Rick Sladkey, (1), кто
написал NFS
kernel код и большие части NFS сервера. Последний, выводил из unfsd
пространства пользователя NFS сервер, первоначально написанный Mark Shand,
и hnfs Harris NFS сервер, написанный Donald Becker.
Давайте теперь посмотрим том, как NFS работает: клиент может
запросить установить каталог от отдаленного хоста на локальном каталоге тем
же способом, и он может установить физическое устройство. Однако,
синтаксис, используемый для того, чтобы точно определить отличен ли
отдаленный каталог. Например, чтобы mount /home хост vlager к /users на
vale, администратор выпустил бы следующую команду на vale: (2)
"
1. Rick может быть найден в jrs@world.std.com.
# mount -t nfs vlager:/home /users
- 195 -
mount затем попробует соединиться с mountd, устанавленный с daemon на
vlager через RPC. Сервер проверит, разрешается ли vale повысить каталог, и
если так, вернет это к file handle. Этот handle файл будет использоваться
во всех последовательных запросах к картотекам ниже /users.
Когда кто -то обращается к файлу над NFS, kernel места RPC вызовут
nfsd (NFS daemon) на машине сервера. Это обращение берет handle файл, имя
файла, к которому обращаются, и user's user и идентичность группы как
параметры. Они используются в определении прав доступа к точно
определенному файлу. Чтобы предотвратить от несанкционированного чтения или
модифицирования файла, пользователь и идентичность группы должны быть теме
же самыми на обоих хостах.
На большинстве Un*x реализаций, NFS функциональные возможности обоих
клиентов и сервер выполнены как kernel уровень daemons, которые начаты из
пространства пользователя при начальной загрузке системы. Они - NFS daemon
(nfsd) на хосте сервера, и блок ввода - вывода Daemon (biod) выполняющийся
на клиентском хосте. Чтобы улучшить производительность, biod выполняет
асинхронный ввод - вывод, используя чтение - вперед и запись-назад; также,
несколько nfsd daemons обычно запускается совместно.
NFS реализация Linux, немного отлична в этом самом клиентском коде,
крепко объединена в файловой системе (VFS) уровень ядра и не требует
дополнительного управления через biod. С другой стороны код сервера
запускается полностью в пространстве пользователя, так, чтобы при запуске
нескольких копий сервера в одно и то же время было бы почти невозможным из-
за синхронизации. Linux NFS, в настоящее время также существует отсутствие
чтения - вперед и записи-назад, но Rick Sladkey планирует исправит этот
недостатолк в ближайшее время. (3)
Самая гольъая проблема с Linux NFS кодом - то, что Linux kernel
версии 1.0 не способен распределить память в кусках больших чем 4k; как
следствие, сетевой код не может обрабатывать датаграммы большие чем
приблизительно 3500 байтов после вычитания размера заголовка и т.д. Это
значит, что передача к и из NFS daemons выполняющейся на системах, которые
используют большие UDP датаграммы по умолчанию (например 8k на SunOS)
- 196 -
должны быть уменьшенны в размере искуственно. Этот причиняет вред
характеристике под влиянием некоторых обстоятельств. (4) Этот предел входит
в поздние Linux-1.1 ядра, и клиентский код был
модифицирован для того, чтобы пользоваться этим преимуществом.
2. Заметьте, что Вы можете опустить -t nfs аргумент, потому что mount
видит из двоеточия то, что это определяет NFS объем.
3. Задача с write-behind - то, что kernel буфер кэша индексирован
парами device/inode, и следовательно не может использоваться для nfs-
установленных файловых систем.
12.1 Подготовка NFS
Прежде, чем Вы можете использовать NFS, будь это сервер или клиент,
Вы должны удостовериться, что Ваше ядро имеет NFS поддержку, компилируемую
в. Более новые ядра для этого имеют простой интерфейс на proc файловой
системе, файл /proc/filesystems, который Вы можете отобразить используя
cat:
$ cat /proc/filesystems
minix
ext2
msdos
nodev proc
nodev nfs
Если nfs отсутствует из этого списка, то Вы должны скомпилировать
Ваше собственное ядро с включенным NFS. Конфигурирование kernel сетевых
опций объяснено в разделе " Kernel конфигурация " главы 4 ..
Для более старых ядер до 1.1 Linux, самый простой способ выяснять
имеет ли ваше ядро включенную NFS поддержку - фактически попробовать
установить NFS файловую систему. Для этого, Вы могли бы создать каталог
ниже /tmp, и&поптобовать установить локальный каталог на нем:
- 197 -
# mkdir /tmp/test
# mount localhost:/etc /tmp/test
Если эта попытка установки выдает сообщениее об ошибках выводя, "fs
type nfs no supported by kernel'', то Вы не должны делать новое ядро с
включенной NFS. Любые другие сообщения об ошибках полностью безобидны, так
как Вы пока еще не сконфигурировали NFS daemons на вашем множестве.
12.2 Установка NFS значения
4. Как мне объяснил Alan Cox: NFS спецификация требует сервер к
потоку при каждой записи на диск прежде, чем он успевает вернуть
подтверждение. Так как BSD ядра только способны к, установленным по размеру
страницей, записям (4K), записанным по 4 куска по 1k каждый в bsd-based
NFS, серверу получает в результате 4 операции записи по 4k каждый.
NFS значения (5) установлены таким же способом, как и обычные
файловые системы
установленны. Вы вызываете mount, используя следующий синтаксис:
# mount -t nfs nfs volume local dir options
Nfs значение дано как отдаленный хост: отдаленная директория. С тех
пор как эта совокупность условных знаков является уникальной в NFS файловых
системах, то Вы можете не учитывать nfs опцию -t.
Имеется ряд дополнительных опций, которые Вы можете точно определить
установив над mounting NFS значение. Они могут также быть даны -o
переключателем в командной строке, или в области опций /etc/fstab записей
для значения. В обоих случаях, составные опции отделены друг от друга
запятыми. Опции, точно определенные на командной строке всегда отменяют те,
что были даны в файле fstab.
Типовая запись в /etc/fstab могла бы быть такой:
- 198 -
# volume mount point type options
news:/usr/spool/news /usr/spool/news nfs timeo=14,intr
Этот значение может затем быть установлено при использовании
# mount news:/usr/spool/news
В отсутствии fstab записи, NFS устанавливает просмотр вызовов
большинства uglier. Например, предположим, что Вы устанавливаете home
каталоги Ваших пользователей
из машины, называемой moonshot, которая использует заданный по
умолчанию размер блока равный 4k для операции чтения - записи. Вы могли бы
уменьшить размер блока до 2k, чтобы подойти под размер Linux(овских)
датаграмм введя следующую команду:
# mount moonshot:/home /home -o rsize=2048,wsize=2048
5. Никто не говорит "файловая система", потому что здесь не
существует подходящей файловой системы.
Список всех допустимых опций полностью описан в руководстве по
Nfs(5), которая идет вместе с Rick Sladkey's NFS-aware mount tool,
который может быть найден в Util-linux пакете Rik Faith). Следующее -
незавершенный список тех, которые Вы возможно захотели бы использовать:
rsize=n и wsize=n - они точно определяют датаграмный размер,
используемый NFS
клиентурой при чтении и записи запросов, соответственно. В
настоящее время они определенны по умолчанию - 1024 байтам,
из-за предела на UDP размере датаграммы, описанном выше.
timeo=n - это устанавливает время (в десятках секунд), сколько NFS
клиент будет ждать запрос,
чтобы завершить работу. Значения по умолчанию - 0.7 секунды.
hard - точно маркирует этот объем как hard-mounted. Это включено по
- 199 -
умолчанию.
soft - soft-mount драйвер ( противоположный hard-mounted).
intr - позволяет сигнализировать о том, что надо прервать NFS вызов.
Полезно для прерывания выполнения, когда сервер не
отвечает.
Кроме rsize и wsize, все эти опции обращаются к клиенту, если сервер
стал временно недостижим. Они работают вместе следующим способом: всякий
раз, когда клиент ппсылвет запрос к NFS серверу, он ожидает, что операция
закончится после данного интервала (точно установленным в опции блокировки
по времени). Если никакого подтверждения не получено внутри этого
промежутка времени, то появится так называемая minor timeout
(незначительная остановка по времени), и операция повторится, но уже с
интервалом блокировки по времени вдвое большим. После достижения
максимальной блокировки по времени - 60 секунд, происходит глобальная
блокировка по времени.
По умолчанию, глобальная блокировка по времени заставит клиента
напечатать сообщение на консоль и начинать все снова. В принципе это может
продолжаться вечно. Значения, которые упрямо повторяют операцию до тех пор
пока сервер не становится доступным, называются hard-mounted. В
противоположность им, soft-mounted значения генерируют ошибку ввода -
вывода для вызова процесс всякий раз, когда происходит глобальная
блокировка по времени. Из-за того, что write-behind вводится буферным
кэшем, то это условие ошибки не распространяется непосредственно на процесс
прежде, чем это вызовет функцию записи 2 в следующий раз, так как программа
никогда не сможет убедиться в том что операция записи к soft-mounted
значению имела место вообще.
Поставили ли Вы hard- или soft-mount значение - это не только вопрос
вкуса, но также и то, что Вы должны сделать с тем сортом информации,
которую Вы хотите получить от этого значения. Например, если Вы
устанавливаете ваши Х программы NFS, Вы конечно не хотели бы, чтобы ваш X
сеанс шел бы "бешено" только потому, что кто -то привел сеть к останову,
- 200 -
запустив семь копий xv в одно и тоже время, или скажем, вытащив Ethernet
разъем на некоторый момент. Используя hard-mounting, Вы удостоверяетесь в
том, что ваш компьютер будет ждать, пока не появится возможность заново
восстановить контакт с вашим nfs-сервером. С другой стороны, non-critical
данные, типа nfs-mounted news partititons или FTP врхив может быть также
soft-mounted, так что это не повесит ваш сеанс в случае, если отдаленная
машина должна стать временно "недостигаемой", или просто быть выключенной.
Если ваша сетевая связь с сервером - flakey или проходит через программу
маршрутизации, то Вы может также увеличивать начальную блокировку по
времени, используя опцию timeo, или hard-mount значение, но позволяйте
сигнализировать прерывание вызова NFS, так чтобы Вы могли прервать любой
hanging file access.
Обычно, mountd daemon будет иным способом следить, которые каталоги
были установлены, и какими хостами. Эта информация может быть отображена
при использовании программы showmount, которая также включена в NFS пакет
однако, Вы перемещаете вашу машину между различными NIS областями
часто, то Вы возможно захотите сохранить информацию для отдельных
областей в картотеке yp.conf. Вы можете иметь информацию относительно
серверов для различных NIS областей в Yp.conf, прибавляя NIS название
области к формулировке сервера. Для образца, Вы могли бы измен"типовой
файл для портативной ЭВМ, чтобы это выглядило подобно этому:
# yp.conf - YP configuration for NYS library.
#
server vbardolino winery
server vstout brewery
Это позволяет Вам выдать портативную ЭВМ в любой из двух областей,
просто при установке желательной NIS области при начальной загрузке
введите команду названия.
После создания этого базисного файла конфигурации, и уверенности
в том это - всемирно - читаемый, Вы запустить ваш первый критерий,
чтобы проверить, можете ли Вы подсоединиться к вашему серверу.
Удостоверитесь, что выбрано отображение вашего сервеа, подобно
- 186 -
hosts.byname, и испытанию, чтобы восстановить, используя ypcat утилиту.
Ypcat, подобно всем другим административным NIS инструментальным
средствам, должен жить в /usr/sbin.
# ypcat hosts.byname
191.72.2.2 vbeaujolais vbeaujolais.linus.lxnet.org
191.72.2.3 vbardolino vbardolino.linus.lxnet.org
191.72.1.1 vlager vlager.linus.lxnet.org
191.72.2.1 vlager vlager.linus.lxnet.org
191.72.1.2 vstout vstout.linus.lxnet.org
191.72.1.3 vale vale.linus.lxnet.org
191.72.2.4 vchianti vchianti.linus.lxnet.org
Вывод, который Вы получаете, должен быть на подобие вышепоказанного.
Если Вы получаете сообщение об ошибках взамен, которое говорит "Can't
bind to server which serves domain" или что-нибудь на подобие, затем
или NIS название области, которое не имеет сервер соответствия,
определенный в yp.conf, или сервер - unreachable по некоторым
причинам. В последнем случае, удостоверитесь в том, что ping множеству
производится положительный результат, и что это действительно запу Вы
можете проверить последний, используя rpcinfo, который должен произвести
следующий вывод:
# rpcinfo -u serverhost ypserv
program 100004 version 2 ready and waiting
11.6 Выбор правых отображений
Удостоверьтесь в том, что Вы можете достичь NIS сервера, Вы должны
решить который конфигурационный файл, чтобы заменить или увеличить с
NIS отображениями. Обычно, Вы захотите использовать NIS отображения
для множества и функций поиска пароля. Вышеупомяну тый особенно полезен,
если Вы не запускаете BIND. Последний разрешает всем
пользователям зарегестрироваться на их account из любой системы в NIS
области; это обычно требует разделения центрального /местного к Это
объяснено подробно в разделе 11.7 ниже. Другое отображение, подобно
services.byname, не такое драматическое увеличение, но сохраняют Вас
- 187 -
от некоторой работы редактирования, если Вы устанавливаете любые
сетевые приложения которые используют сервисное название, то это не в
стандартном файле услуг.
Вообще, Вы хотите иметь некоторую свободу выбора когда поиск-
функция использует локальные файлы, и когда это делает запрос NIS
сервера. NYS позволяет Вам сконфигурировать порядок, в котором функция
обращается к этим услугам. Это управляется через картотеку
/etc/nsswitch.conf, который замещает обслуживание названия, но
конечно не ограничивает название обслуживание. Для любой из функций
поиска данных это содержит линию, именующие услуги, чтобы использовать.
Правильный порядок услуг зависит от типа данных. Это вряд ли
то, что services.byname отображение будет содержать отличие входов
из тех в локальном файле услуг; это может только содержать больше. Так
хороший выбор может быть, чтобы сделать запрос локальных файлов сначала, и
проверять NIS только если сервисное название не было найдено. Hostname
информация, с другой стороны, может изменятся пченю часто, так, чтобы DNS
или NIS сервер всегда имел наиболее точный accoun файл сохран как
дублиррование, если DNS и NIS терпел неудачу. В этом случае, Вы захотели
бы проверить локальный последний файл.
Пример ниже показывает, как сконфигурировать gethostbyname
(2), gethostByaddr (2), и getservbyname функции (2) как описано выше. Они
будут перечисленны как услуги по очереди; если поиск идет хорошо, то
результат будет возвращен, иначе следующее обслуживание осуждено.
# small sample /etc/nsswitch.conf
#
hosts: nis dns files
services: files nis
Полный список услуг, которые могут использоваться с записью в
Nsswitch.conf файле показыны ниже. Фактические отображения, файлы,
серверы и вещи, которые делают запрос зависят от названия записи.
- 188 -
Nisplus или nis + использует NIS + сервер для этой области.
Локализация сервера получена из картотеки /etc/nis.conf.
Nis Использует текущий NIS сервер этой области. Локализация сервера
делал запрос, сконфигурированный в картотеке yp.conf как показано в
предыдущем разделе. Для записи множеств, отображения Hosts.byname и
hosts.byaddr делают запрос.
-176 -
dns использует DNS сервер. Этот служебный тип полезен только для
записи хоста. Сервера делающие запрос, все еще определяются в соответствии
cо стандартом resolv.conf файла.
files использует локальный файл, такой как /etc/hosts файл для хост
записи.
dbm ищет информацию из DBM файлов, размещенных в /var/dbm. Имя,
используемое для файла - соответствующего NIS отображение.
В настоящее время, NYS поддерживает следующие nsswitch.conf записи:
hosts,
networks, passwd, group, shadow, gshadow, services, protocols, rpc, и
др. Другие записи возможно могут быть добавленны.
Рисунок 11.6 показывает более полный пример, который демонстрирует
другую
&осогенность nsswitch.conf: ключевое слово [NOTFOUND=return] в записях
хостов сообщила бы NYS - вернуться, если желаемый пункт не был найден в NIS
или в DNS база данных. То есть NYS продолжит искать локальные файлы, только
если обращения к NIS и DNS серверам терпят неудачу по какой-либо другой
причине. Локальные файлы будут затем только использоваться при начальной
загрузке и как backup, когда NIS сервер выключен.
11.7 Использование passwd и группы Maps
Одно из главных приложений NIS находится в синхронизации пользователя
и account информации относительно всех множеств в NIS области. К концу, Вы
- 189 -
обычно хранит только малый локальный файл /etc/passwd, к которому
добавлена site-wide информация из NIS отображений. Однако, просто
предоставления возможности NIS поиска для этого обслуживания в
nsswitch.conf не вполне достаточно.
Полагаясь на информацию пароля, распределенную NIS, Вы сначала должны
удостовериться, что числовая идентичность пользователя всех пользователей,
которые у Вас есть в Вашем локальном passwd файлесоответствуют идеи NIS
сервера относительно идентичности пользователя. Вы возможно захотите
использовать это для других целей также, подобно установке NFS значений от
других хостов на вашей сети.
# /etc/nsswitch.conf
#
hosts: nis dns [NOTFOUND=return] files
networks: nis [NOTFOUND=return] files
services: files nis
protocols: files nis
rpc: files nis
Рисунок 17. Примерный nsswitch.conf файл.
Если любая из числовых идентичности в /etc/passwd или /etc/group
отклоняется от тех, которые в maps, то Вы должны скорректировать файл
ownerships для всех файлов, которые принадлежат этому пользователю. Сначала
Вы должны заменить все uids и gids в passwd и в группах новых значений;
затем найдите вуе фвйлы, которые принадлежат пользователям и былы только
что изменены, и в заключение замените их ownerships. Примите новости
используемые для того, чтобы иметь идентичность пользователя была бы 9, и
okir имел бы идентичность пользователя 103, которые были заменены на
некоторое другое значение; Вы могли бы затем выпорлнить следующие команды:
# find / -uid 9 -print >/tmp/uid.9
# find / -uid 103 -print >/tmp/uid.103
# cat /tmp/uid.9 | xargs chown news
- 190 -
# cat /tmp/uid.103 | xargs chown okir
Важно то, что Вы выполняете эти команды с новым, установленным passwd
файлом, и что Вы собираете все имена файлов прежде, чем Вы изменените
ownership любого из них. Для того, чтобы модифицировать ownerships группы
файлов, Вы должны использовать похожую команду.
Сделав это, численный uid's и gid's на вашей системе согласиться с
теми хостами, которые расположенны в Вашей NIS области. Следующий шаг будет
- прибавить линии конфигурации к nsswitch.conf, который включают NIS поиски
для пользователя и информации группы:
# /etc/nsswitch.conf - passwd and group treatment
passwd: nis files
group: nis files
Это заставляет команду входа в систему, и всех ее друзей сначала
сделать запрос NIS maps, когда пользователь пробует log in, и если этот
поиск терпит неудачу - обратно обращается к локальным файлам. Обычно, Вы
удалите почти всех пользователей из Вашего локального файла, и только
оставите записи для root и generic accounts подобно почте. Это потому, что
некоторые насущные задачи системы могут требовать к map uids имя
пользователя или наоборот. Например, административный cron job может
выполнить команду su, для того чтобы временно стать новостями, или UUCP
подсистема может отправлять по почте отчет состояния. Если новости и
uucp не имеют вход в локальный файл passwd, то эти jobs будут, к сожалению,
терпеть неудачу в течение&NIS"brownout.
Имеются две большие проблемы: с одной стороны, установка, как уже
было описано в начале, до сих пор работает только для наборов программ
входа в систему, которые не используют теневой пароль, подобно тем, что
включены в util-linux пакет. Путаница при использовании теневых паролей с
NIS будет объяснена ниже. С другой стороны, команды входа в систему - не
единственые, которые обращаются к passwd файлу - посмотрите на команду ls,
которую большинство людей использует почти постоянно.
- 191 -
При выполнении длинной распечатки, ls выделит символические имена для
пользователя и группу владельцев файла; то есть для каждого uid и gid это
представляет собой целую схватку, это должно сделать запрос на NIS сервер,
только один раз. Это ужасно замедлит выполнение, если ваша локальная сеть -
clogged, или, еще хуже, когда NIS сервер не на той же самой сети, для
этого датаграммы должны пройти через программу маршрутизации.
Но пока это еще не вся история. Вообразите, что случится если
пользователь захочет изменить свой пароль. Обычно, она вызовет passwd,
который считает новый пароль и модифицирует локальный файл passwd. Это
невозможно сделать с NIS, так как с тех пор файл локально больше не
доступен, но если пользователи подсоединились к NIS серверу, и вдруг
захотели изменить пароль, то дляч этого, к сожалению нет опции. Поэтому,
NIS обеспечивает отпуск в замене для passwd, называемого yppasswd, который
делает аналогичную вещь в присутствии NIS. Для изменения пароля на хост
сервере, но в контакт с yppasswdd daemon на том же самом хосте через RPC, и
обеспечивает его модифицируемой информацией пароля. Обычно, Вы
устанавливаете yppasswd для нормальной программы, делая что - нибудь вроде
этого:
# cd /bin
# mv passwd passwd.old
# ln yppasswd passwd
В то же самое время Вы должны установить rpc.yppasswdd на сервер и
запустить его из rc.inet2. Это эффективно слроет любые искожения NIS от
ваших пользователей.
11.8 Использование NIS с Shadow Support
Не имеется никакой NIS поддержки для мест, которые используют теневой
вход в систему набора программ. John F. Haugh, автор теневого набора
программ, недавно выпущенной версии теневых библиотечных функций, описанных
GNU библиотекой GPL к comp.sources.misc. Это уже имеет некоторую поддержку
- 192 -
для NIS, но она пока еще не полна, и файлы пока еще не добавлены к
стандарной библиотеке для C. С другой стороны, при публикации информации из
/etc/shadow через NIS вид поражения цели теневого набора программ.
Хотя NYS функции поиска пароля не используют shadow.byname map или
что - либо аналогичное, очевидно NYS поддерживает использование локального
/etc/shadow файла. Когда NYS реализация getpwnam обращается к просмотру
информации, связанной с данным login именем, средства, точно определенные
passwd записью в nsswitch.conf делают запрос. Nis обслуживание будет просто
искать имя в passwd.byname map на NIS сервере. Обслуживание файлов, однако,
проверит, существует ли /etc/shadow, и если существует, то попробует
открыть это. Если ни один из файлов не присутствует, или если пользователь
не имеет привилегию root, то происходит возвращение к обычной работе поиска
информации пользователя в /etc/passwd. Однако, если теневой файл существует
и может быть открыт, то NYS извлечет пароль пользователя из shadow.
Getpwuid функция соответственно выполняется. В этом режиме, binaries,
компилируемый с NYS, будет иметь дело с локальной установкой теневого
набора программ.
11.9 Использование традиционного NIS кода.
Если Вы используете код клиента, который находится в стандарте libc,
то конфигурация NIS клиента немного отлична. С одной стороны, это
использует ypbind daemon для того, чтобы передать информацию для активных
серверов скорее чем считывать эту информацию из файла конфигурации. Вы
следовательно должны удостоверится в том, что бужет запущен ypbind при
начальной загрузке. Он должен быть вызван после установленной NIS области,
и RPC portmapper тоже должен быть запущен. Вызов ypcat нужен для того,
чтобы проверить работает ли сервер так, как он должен (см. выше).
Недавно, имелось некоторое число bug reports, которые сообщают, что
NIS терпит неудачу, сообщая при этом: "clntudp create: RPC: portmapper
failure - RPC: unable to receive''.
Это все из-за несовместимого изменения в способе, как ypbind
связывается с библиотечными функциям. Получая последние источники для NIS
- 193 -
утилит и перетранслируя их, должна быть исправлена эта задача. (5)
Также, способ традиционного NIS решает это, как соединить NIS
информацию с этим из локальных файлов отклоняемую от используемого NYS.
Например, чтобы использовать NIS отображение пароля, Вы должны включить
следующую линию где-нибудь в Вашем /etc/passwd map:
+: *:0:0:::
Это маркирует место где функции поиска пароля "вставляют" NIS
отображения. Вставка подобной линии (минус последние два двоеточия) в
/etc/group делают тот же самое для group. * maps. Для того, чтобы
использовать hosts.* maps, распределенные NIS, измените order line в
host.conf файле. Например, если Вы хотите использовать NIS, DNS, и файл
/etc/hosts (в том порядке), то Вы должны изменить эту линию на:
order yp bind hosts
Традиционная NIS реализация не поддерживает никакие другие
отображения в настоящее время.
5. Источник для yp-linux может быть получен из ftp.uniрaderborn.de в
каталоге /pub/Linux/LOCAL.
12. Сетевая файловая система (NFS)
NFS, the network file system, является возможно наиболее видной
сетью услуг, использующей RPC. Это позволяет обращаться к файлам на
отдаленных хостах точно
тем же самым способом, как пользователь обратился бы к любым"
локальным файлам. Сделано возможным смешением kernel функциональных
возможностей на клиентской стороне (которая использует отдаленную файловую
систему) и NFS сервер на стороне сервера (который обеспечивает файл
данных). Этот доступ к файлу полностью очевиден клиенту, и работает через
все разнообразие серверов и архитектуры хостов.
- 194 -
NFS предлагает ряд преимуществ:
+ Данные, к которым обращаются все пользователи, могут быть сохранены
на центральном хосте, с клиенами устанавливающими этот каталог при
начальной загрузке. Например, Вы можете сохранить все accounts
пользователей на одном хосте, и иметь все хосты на Вашем сетевом mount
/home от того хоста. Если оно установлено бок о бок с NIS, то пользователи
могут затем войти в любую систему, и все еще работать на одном множестве
файлов.
+ Данные, потребляющие большие количества дискового пространства
могут быть сохранены в единственном хосте. Например, все файлы и программы
относящиеся к LaTeX и METAFONT могут быть сохранены и поддерживаться в
одном месте.
+ Административно-управленческая информация может быть сохранена в
адинственном хосте. Нет нужды использовать rcp для того, чтобы установить
тот же самый глупый файл на 20 различных машин.
Linux NFS - в значительной степени работа Rick Sladkey, (1), кто
написал NFS
kernel код и большие части NFS сервера. Последний, выводил из unfsd
пространства пользователя NFS сервер, первоначально написанный Mark Shand,
и hnfs Harris NFS сервер, написанный Donald Becker.
Давайте теперь посмотрим том, как NFS работает: клиент может
запросить установить каталог от отдаленного хоста на локальном каталоге тем
же способом, и он может установить физическое устройство. Однако,
синтаксис, используемый для того, чтобы точно определить отличен ли
отдаленный каталог. Например, чтобы mount /home хост vlager к /users на
vale, администратор выпустил бы следующую команду на vale: (2)
"
1. Rick может быть найден в jrs@world.std.com.
# mount -t nfs vlager:/home /users
- 195 -
mount затем попробует соединиться с mountd, устанавленный с daemon на
vlager через RPC. Сервер проверит, разрешается ли vale повысить каталог, и
если так, вернет это к file handle. Этот handle файл будет использоваться
во всех последовательных запросах к картотекам ниже /users.
Когда кто -то обращается к файлу над NFS, kernel места RPC вызовут
nfsd (NFS daemon) на машине сервера. Это обращение берет handle файл, имя
файла, к которому обращаются, и user's user и идентичность группы как
параметры. Они используются в определении прав доступа к точно
определенному файлу. Чтобы предотвратить от несанкционированного чтения или
модифицирования файла, пользователь и идентичность группы должны быть теме
же самыми на обоих хостах.
На большинстве Un*x реализаций, NFS функциональные возможности обоих
клиентов и сервер выполнены как kernel уровень daemons, которые начаты из
пространства пользователя при начальной загрузке системы. Они - NFS daemon
(nfsd) на хосте сервера, и блок ввода - вывода Daemon (biod) выполняющийся
на клиентском хосте. Чтобы улучшить производительность, biod выполняет
асинхронный ввод - вывод, используя чтение - вперед и запись-назад; также,
несколько nfsd daemons обычно запускается совместно.
NFS реализация Linux, немного отлична в этом самом клиентском коде,
крепко объединена в файловой системе (VFS) уровень ядра и не требует
дополнительного управления через biod. С другой стороны код сервера
запускается полностью в пространстве пользователя, так, чтобы при запуске
нескольких копий сервера в одно и то же время было бы почти невозможным из-
за синхронизации. Linux NFS, в настоящее время также существует отсутствие
чтения - вперед и записи-назад, но Rick Sladkey планирует исправит этот
недостатолк в ближайшее время. (3)
Самая гольъая проблема с Linux NFS кодом - то, что Linux kernel
версии 1.0 не способен распределить память в кусках больших чем 4k; как
следствие, сетевой код не может обрабатывать датаграммы большие чем
приблизительно 3500 байтов после вычитания размера заголовка и т.д. Это
значит, что передача к и из NFS daemons выполняющейся на системах, которые
используют большие UDP датаграммы по умолчанию (например 8k на SunOS)
- 196 -
должны быть уменьшенны в размере искуственно. Этот причиняет вред
характеристике под влиянием некоторых обстоятельств. (4) Этот предел входит
в поздние Linux-1.1 ядра, и клиентский код был
модифицирован для того, чтобы пользоваться этим преимуществом.
2. Заметьте, что Вы можете опустить -t nfs аргумент, потому что mount
видит из двоеточия то, что это определяет NFS объем.
3. Задача с write-behind - то, что kernel буфер кэша индексирован
парами device/inode, и следовательно не может использоваться для nfs-
установленных файловых систем.
12.1 Подготовка NFS
Прежде, чем Вы можете использовать NFS, будь это сервер или клиент,
Вы должны удостовериться, что Ваше ядро имеет NFS поддержку, компилируемую
в. Более новые ядра для этого имеют простой интерфейс на proc файловой
системе, файл /proc/filesystems, который Вы можете отобразить используя
cat:
$ cat /proc/filesystems
minix
ext2
msdos
nodev proc
nodev nfs
Если nfs отсутствует из этого списка, то Вы должны скомпилировать
Ваше собственное ядро с включенным NFS. Конфигурирование kernel сетевых
опций объяснено в разделе " Kernel конфигурация " главы 4 ..
Для более старых ядер до 1.1 Linux, самый простой способ выяснять
имеет ли ваше ядро включенную NFS поддержку - фактически попробовать
установить NFS файловую систему. Для этого, Вы могли бы создать каталог
ниже /tmp, и&поптобовать установить локальный каталог на нем:
- 197 -
# mkdir /tmp/test
# mount localhost:/etc /tmp/test
Если эта попытка установки выдает сообщениее об ошибках выводя, "fs
type nfs no supported by kernel'', то Вы не должны делать новое ядро с
включенной NFS. Любые другие сообщения об ошибках полностью безобидны, так
как Вы пока еще не сконфигурировали NFS daemons на вашем множестве.
12.2 Установка NFS значения
4. Как мне объяснил Alan Cox: NFS спецификация требует сервер к
потоку при каждой записи на диск прежде, чем он успевает вернуть
подтверждение. Так как BSD ядра только способны к, установленным по размеру
страницей, записям (4K), записанным по 4 куска по 1k каждый в bsd-based
NFS, серверу получает в результате 4 операции записи по 4k каждый.
NFS значения (5) установлены таким же способом, как и обычные
файловые системы
установленны. Вы вызываете mount, используя следующий синтаксис:
# mount -t nfs nfs volume local dir options
Nfs значение дано как отдаленный хост: отдаленная директория. С тех
пор как эта совокупность условных знаков является уникальной в NFS файловых
системах, то Вы можете не учитывать nfs опцию -t.
Имеется ряд дополнительных опций, которые Вы можете точно определить
установив над mounting NFS значение. Они могут также быть даны -o
переключателем в командной строке, или в области опций /etc/fstab записей
для значения. В обоих случаях, составные опции отделены друг от друга
запятыми. Опции, точно определенные на командной строке всегда отменяют те,
что были даны в файле fstab.
Типовая запись в /etc/fstab могла бы быть такой:
- 198 -
# volume mount point type options
news:/usr/spool/news /usr/spool/news nfs timeo=14,intr
Этот значение может затем быть установлено при использовании
# mount news:/usr/spool/news
В отсутствии fstab записи, NFS устанавливает просмотр вызовов
большинства uglier. Например, предположим, что Вы устанавливаете home
каталоги Ваших пользователей
из машины, называемой moonshot, которая использует заданный по
умолчанию размер блока равный 4k для операции чтения - записи. Вы могли бы
уменьшить размер блока до 2k, чтобы подойти под размер Linux(овских)
датаграмм введя следующую команду:
# mount moonshot:/home /home -o rsize=2048,wsize=2048
5. Никто не говорит "файловая система", потому что здесь не
существует подходящей файловой системы.
Список всех допустимых опций полностью описан в руководстве по
Nfs(5), которая идет вместе с Rick Sladkey's NFS-aware mount tool,
который может быть найден в Util-linux пакете Rik Faith). Следующее -
незавершенный список тех, которые Вы возможно захотели бы использовать:
rsize=n и wsize=n - они точно определяют датаграмный размер,
используемый NFS
клиентурой при чтении и записи запросов, соответственно. В
настоящее время они определенны по умолчанию - 1024 байтам,
из-за предела на UDP размере датаграммы, описанном выше.
timeo=n - это устанавливает время (в десятках секунд), сколько NFS
клиент будет ждать запрос,
чтобы завершить работу. Значения по умолчанию - 0.7 секунды.
hard - точно маркирует этот объем как hard-mounted. Это включено по
- 199 -
умолчанию.
soft - soft-mount драйвер ( противоположный hard-mounted).
intr - позволяет сигнализировать о том, что надо прервать NFS вызов.
Полезно для прерывания выполнения, когда сервер не
отвечает.
Кроме rsize и wsize, все эти опции обращаются к клиенту, если сервер
стал временно недостижим. Они работают вместе следующим способом: всякий
раз, когда клиент ппсылвет запрос к NFS серверу, он ожидает, что операция
закончится после данного интервала (точно установленным в опции блокировки
по времени). Если никакого подтверждения не получено внутри этого
промежутка времени, то появится так называемая minor timeout
(незначительная остановка по времени), и операция повторится, но уже с
интервалом блокировки по времени вдвое большим. После достижения
максимальной блокировки по времени - 60 секунд, происходит глобальная
блокировка по времени.
По умолчанию, глобальная блокировка по времени заставит клиента
напечатать сообщение на консоль и начинать все снова. В принципе это может
продолжаться вечно. Значения, которые упрямо повторяют операцию до тех пор
пока сервер не становится доступным, называются hard-mounted. В
противоположность им, soft-mounted значения генерируют ошибку ввода -
вывода для вызова процесс всякий раз, когда происходит глобальная
блокировка по времени. Из-за того, что write-behind вводится буферным
кэшем, то это условие ошибки не распространяется непосредственно на процесс
прежде, чем это вызовет функцию записи 2 в следующий раз, так как программа
никогда не сможет убедиться в том что операция записи к soft-mounted
значению имела место вообще.
Поставили ли Вы hard- или soft-mount значение - это не только вопрос
вкуса, но также и то, что Вы должны сделать с тем сортом информации,
которую Вы хотите получить от этого значения. Например, если Вы
устанавливаете ваши Х программы NFS, Вы конечно не хотели бы, чтобы ваш X
сеанс шел бы "бешено" только потому, что кто -то привел сеть к останову,
- 200 -
запустив семь копий xv в одно и тоже время, или скажем, вытащив Ethernet
разъем на некоторый момент. Используя hard-mounting, Вы удостоверяетесь в
том, что ваш компьютер будет ждать, пока не появится возможность заново
восстановить контакт с вашим nfs-сервером. С другой стороны, non-critical
данные, типа nfs-mounted news partititons или FTP врхив может быть также
soft-mounted, так что это не повесит ваш сеанс в случае, если отдаленная
машина должна стать временно "недостигаемой", или просто быть выключенной.
Если ваша сетевая связь с сервером - flakey или проходит через программу
маршрутизации, то Вы может также увеличивать начальную блокировку по
времени, используя опцию timeo, или hard-mount значение, но позволяйте
сигнализировать прерывание вызова NFS, так чтобы Вы могли прервать любой
hanging file access.
Обычно, mountd daemon будет иным способом следить, которые каталоги
были установлены, и какими хостами. Эта информация может быть отображена
при использовании программы showmount, которая также включена в NFS пакет