Страница:
преобразованны к так называемому Внешнему Представлению Данных
(XDR) отправителю, и преобразованны обратно к машинно - локальному
Иногда, уточнения к RPC приложению вводят несовместимые
изменения в процедуре call interface. Конечно, при простом изменение
сервер разрушил бы все приложение, которые все еще ожидают original
behavior. Следовательно, RPC программы имеют номера версии, приписываемые
к ним, обычно начинающийся с 1, и с каждой новой версией RPC свяжит с
помощью интерфейса этот счетчик. Часто, сервер может предлагать несколько
версий одновременно; клиентура затем указывает номером версии версии они
хотят использовать.
Сетевая связь между RPC серверами и клиентурой - особая. RPC
сервер предлагает один или более системных процедур; каждое множество
называется программой, и однозначно идентифицировано номером
программы. Имена обслуживания отбора списка существуют для того,
чтобы запрограммировать числа обычно сохраняемые в /etc/rpc, выборка
которого воспроизведена ниже ра рисунке 10.4
В TCP/IP сетях, перед авторами RPC стояла задача программирования
чисел к обобщенным сетевым услугам. Они выбрали - иметь каждый
сервер, обеспечивающий, и TCP и UDP порт для каждой программы и каждой
версии. Вообще, RPC приложения используют UDP посылку данных, и
возвращаются обратно к TCP тогда, когда данные, которые будут переданы не
впишутся в единственную UDP датаграмму.
Конечно, клиентские программы должны иметь способ выяснить который
из них порт отображения номера программы. Использование файла
конфигурации для этого, был бы слишком негибки; с тех пор RPC
приложения не используют зарезервированные порты, не имеется никакой
гарантии, что порт первоначально подразумевал использоваться наше
приложепие "баз данных. Следовательно, RPC приложения выбирают любой
порт который, они могут получить, и зарегистрировать это с так
называемым por действия - как обслуживание broker для всех RPC
серверов, выполняющиеся на машине: клиент, который хочет войти в контакт с
обслуживанием с данным номером программы сначала сделает запрос
- 172 -
portmapper на числа порта обслуживание, которые могут быть достигнуты.
Этот метод имеет частичный недостаток, что это вводит единственную
точку отказа, очень похожую на inetd daemon. Однако, этот случай немного
хуже, потому что когда portmapper умирает, вся RPC информация порта
теряется; это обычно значит, что Вы должны перезапустить все RPC серверы
вручную, или перезагрузить целую машину.
На Linux, portmapper называется rpc.portmap и постоянно
находится в /usr/sbin. Кроме уверения того, что это начато из rc.inet2,
рortmapper не требует любой работы по конфигурации.
10.5 Конфигурирование r команд
Имеется ряд команд для выполнения команд на remote хосте. Они -
rlogin, rsh, rcp и rcmd. Они все порождают оболочку на remote хосте и
позволяют пользователю выполнять команды. Конечно, клиент должен иметь
account на хосте, где команда должна быть выполнена. Таким образом все
эти команды выполняют процедуру разрешения. Обычно, клиент сообщяет
название входа в систему пользователя на сервер, который
#
# /etc/rpc - miscellaenous RPC-based services
#
portmapper 100000 portmap sunrpc
rstatd 100001 rstat rstat svc rup perfmeter
rusersd 100002 rusers
nfs 100003 nfsprog
ypserv 100004 ypprog
mountd 100005 mount showmount
ypbind 100007
walld 100008 rwall shutdown
yppasswdd 100009 yppasswd
bootparam 100026
" ypupdated 100028 ypupdate
- 173 -
Рис. 16. A sample /etc/rpc file.
по очереди запрашивает пароль, который утвержден обычным способом.
Иногда, однако, желательно ослабить проверки разрешения для
некоторых пользователей. Например, если Вы часто должны регистрироваться
в других машинах на вашей локальной вычислительной сети, Вы могли бы
захотеть быть признанным без ввода пароля каждый раз.
Отключение разрешения желательно только на малом числе хостов, чьи
базы данных паролей синхронизированы, или для малого числа из
привилегированных пользователей, которые должны обращаться к
многим машинам для административной причины. Всякий раз, когда Вы
хотите позволять людям регестрироваться на вашем хосте при
необходимости точно определить идентичность входа в систему или пароль,
удостоверитесь, что Вы не делаете ошибку предоставляя доступ кому-нибудь
еще.
Имеются два способа блокировать разрешение, для того чтобы проверить
r команды. Каждый - для супер пользователя, чтобы позволить
некоторым или всем пользователям зарегестрироваться без пароля. Этот
доступ управляется картотекой вызываемой /etc/hosts.equiv. Это содержит
список множеств и имен пользователя, которые рассматриваются
эквивалентными пользователям на локальном хосте. Альтернативная опция -
для пользователя - предоставление другим пользователям на некоторых х
быть перечислены в файле.rhosts в директории пользователя. Для
соображений безопасности, эта картотека должна принадлежать пользователю
или супер пользователю, и не должна быть symbolic link, иначе это будет
игнорирован
Когда клиент запрашивает r обслуживание, ее хост и название
пользователя ищются в файле /etc/hosts.equiv, и затем в файле.rhosts
пользователя. Как - пример, предположим, что janet работает "
гауссе и пытается зарегестрироваться в joe's account на euler. Следуя
далее, мы обратимся к Janet как клиентскому пользователю, и к Joe как к
Локальному пользователю.
- 174 -
Теперь, когда типы Janet
$ Rlogin -l joe euler
на гауссе, сервер сначала проверил бы hosts.equiv (4),
предоставлен ли Janet свободный доступ, и если нет, то он попробует
просмотреть.Rhosts в исходном каталоге joe's.
Файл hosts.equiv на euler походит на это:
gauss
euler
-public
quark.physics.groucho.edu andres
Запись состоит из названия хоста, необязательно сопровождаемого
именем пользователем. Если название множества появляется везде, то
все пользователи от того множества будут допущены к их локальным acount
без любых проверок. В вышеизложенном примере, Janet позволили
бы зарегестрироваться в ее account janet когда выходит из гаусса, и тот
же самый применяется любому другому пользователю за исключением root
Однако, если Janet захочет зарегестрироваться как joe , пароля как обычно.
Если название хоста сопровождается названием пользователя, как
и в последней линии вышеупомянутой типовой картотеки, то этому
пользователю будет дан пароль-свободный доступ ко всем accont за
исключением accony\t root.
Имени хоста может также предшествовать знак "минус", как на
записи "-общий". Это требует разрешения на все account на общем,
независимо от того, что пользователи единичного права предоставляют в их
картотеке.rhosts.
3. В NFS среде окружения, Вы были бы должны дать этому защиту 444,
потому что супер пользователь часто ограничивает в доступе к файлам на
дисках, установленных через NFS.
4. Заметить, что файл hosts.equiv не обыскан когда кто -то делает
попытку к регистрации как root.
- 175 -
" / 165 -
Форматфайла.rhosts идентичен таковому hosts.equiv, но значение
немного отлично. Рассмотрите Joe's.rhosts файл на Euler:
chomp.cs.groucho.edu
gauss janet
Первая запись допускает, что joe освобождают acess при
регистрации из Chomp.cs.groucho.edu, но не воздействуют на права любого
другого account на euler или chomp. Вторая запись - небольшое изменение
этого, в котором предоставляется janet свободный доступ к account Joe
при регистрации из гаусса.
Заметьте, что название хоста клиента получено обратным отбором.
Адрес вызывающего оператора к названию, так, чтобы эта особенность
failed с хостами к решающему устройству. Имя хоста клиента
рассматривается в соответствии с названим в хостах зарегистри рованных в
одном из следующих случаев:
+ Каноническиое имя хоста клиента (не псевдоним) буквально
соответствует имени хоста в файле.
+ Если имя хоста клиента - полностью квалифицированно, то название
области (типа возвращенного решающим устройством, когда Вы имеете
выполняющую DNS), не соответствует имени хоста в множествах файлов, это
сравнивается с тем именем хоста, расширенным с локальным названием
области.
11. Сетевая информационная система
Когда Вы запускаете локальную вычислительную сеть, ваша цель -
обеспечить среду окружения вашим пользователям, которая делает сеть
очевидной. Важен stepping stone к этому концу должен хранить
насущными данные типа пользователя синхронизированные между всеми
- 176 -
множествами. Мы видели перед этим, что для решенияимени хоста, мощное и
сложное обслуживание существует, являющееся DNS. Для других задачи, имеется
нет такого специализированного обслуживания. Кроме того, если В малой
локальной вычислительной сетью с no Internet activity, устанавливая DNS
может показаться утояыим затруднение для многих администраторов.
Это - то, почему Sun разрабатывало NIS, Сетевую Информационную
Систему. NIS обеспечивает обобщенные средства доступа к базе данных,
которые могут использоваться для дизинформации данных типа этого,
содержали в passwd и группах файлах всех множествах на вашей сети. Это
заставит сеть появиться только как единственная система, с теми
же самыми account на всех множествах. В подобном режиме, Вы может
использовать NIS, чтобы распределить hostname информационную форму
/etc/hos сети.
NIS основан на RPC, и включает сервер, client-side библиотеку, и
несколько административных инструментальных средств. Первоначально, NIS
назывался Желтые Страницы, или YP, который все еще широко
используется, чтобы неофициально обратиться к этой услуге. С другой
стороны, Желтые Страницы - марка изготовителя Британской Телесвязи,
которая требует от Sun убрать то название. Поскольку вещи идут, некоторый
стержень имен с людьми, и так YP живет на префиксе к именам больш команд
типа ypserv, ypbind, и т.д. Сегодня, NIS доступны для виртуально всего
Un*ces и там даже свободно реализуется. Каждый - из BSD разъединения
Сеть -2 выпуск, и был получен из общей пожертвованной реализации сноски
области Sun. Библиотечная клиентская цифра из этого разъединения была в GNU
Libc в течение длительного времени, в то время как административные
программы только недавно пренесенные к Linux Swen Thmmler. (1) NIS
сервер - отсутствуетиз реализации сноски. Tobias Reber написал другой
NIS пакет, е средства и сервер; это называется yps. (2)
В настоящее время(постоянно), полная перезапись цифры NIS, называемой
NYS, сделанная Peter Eriksson, (3), который поддерживает оба, и plain
NIS и Sun's much пересмотренным NIS.
1. swen@uni-paderborn.de. NIS клиентура доступнаы как yp-
linux.tar.gz из sunsite.unc.edu в СИСТЕМА / СЕТЬ. 2. Текущая верчия *от
этой записи) - yps-0.21 и может быть получена из ftp.lysator.liu.se в
- 177 -
/pub/NYS каталоге. 3. pen@lysator.liu.se.
+. NYS не только обеспечивает множество NIS инструментальных
средств и сервера, но и также прибавляет новое множество
библиотечных функций, которые будут наиболее возможными для того, чтобы
попасть в стандарт libc в конечном счете. Это включает новую
конфигурационную схему порции hostname решения, которое заменяет
текущую схему использованную host.conf. Особенности этих функций
будут обсуждены ниже.
Эта глава сосредоточится на NYS скорее чем на двух других
пакетах, к которому я буду относить как " традиционную " NIS цифру. Если
Вы хотите запустить этих пакетов, то команд, описанных в этой главе
может быть не достаточно. Чтобы получать дополнительн ую информацию,
пожалуйста найдите стандартную книгу по NIS, типа NFS Hal Stern's и NIS
(см. [GETST "строгий - nfs"]).
В настоящее время, NYS - все еще развивается, и следовательно
стандартные Linux утилиты типа сетевых программ или входа в систему
программ, еще не знает NYS схему конфигурации. Пока NYS соединяется в
mainstream libc Вы должны перетранслировать все эти binaries, если Вы
хотите заставить их использовать NYS. В любом из этих приложений
формирования файла, точно определите -lnsl как последнюю опция libc к
компоновщику. Это связывается на релевантных функциях из libnsl, NYS
стандарной библиотекы для C.
11.1 Знакомство с NIS
NIS хранит информацию баз данных, находящихся в так
называемых отображениях, содержащих keyvalue pairs. Отображения
сохранены на центральном хосте, выполняющем NIS сервер, из которого
клиентура может отыскивать информацию через различные RPC вызовы.
Совершенно часто, отображения сохранены в файлах DBM. (4)
Отпбражения сами по себе обычно генерируются из текстовых файлов
типа /etc/hosts или /etc/passwd. Для некоторых файлов, отдельные
- 178 -
отображения - созданы, один для каждого типа клавиши. Например, Вы
можете искать хост файл для имени хоста также как для адреса IP.
Соответственно, два NIS отображения получены из файла, вызываемый
hosts.byname и hosts.byaddr, соответственно. Таблица 11.1 списков общих
отображений и файлов из кооторых они сгенерированны.
4. DBM - простая библиотека управления базой данных которая
использует метод хеширования, чтобы ускорить операцию исследования. Имеется
свободная DBM реализация из GNU проектируемая вызываемой Gdbm, который
является частью большинства Linux распространен ия.
-----------------------------------------------------------
+-----------------+---------------------------------------+
|Master File | Map(s) |
+-----------------+---------------------------------------+
+-----------------+---------------------------------------+
|/etc/hosts | hosts.byname hosts.byaddr |
|/etc/networks | networks.byname networks.byaddr |
|/etc/passwd | passwd.byname passwd.byuid |
|/etc/group | group.byname group.bygid |
|/etc/services | services.byname services.bynumber |
|/etc/rpc | rpc.byname rpc.bynumber |
|/etc/protocols | protocols.byname protocols.bynumber |
|/usr/lib/aliases | mail.aliases |
+-----------------+---------------------------------------+
+-----------------+---------------------------------------+
Таблица 1. Некоторый стандарт NIS отображения и соответствующие
чайлы.
Имеются другие файлы и отображения, которые Вы можете найти в
любом NIS пакете или другом. Они могут содержать информацию для
приложений не обсуждаемых в этой книге, типа bootparams отображения,
которое может использоваться некоторыми BOOTP серверами, или подобно
которому в настоящее время не имеют любую функцию в Linux
(Ethers.byname и ethers.byaddr отображения).
- 179 -
Для некоторых отображений, люди обычно используют прозвища,
которые являются короткими следовательно проще. Получать полный список
прозвищ понимаемый вашими NIS инструментальными средствами, запустите
следующую команду:
$ ypcat -x
NIS map nickname translation table:
"passwd" -> "passwd.byname"
"group" -> "group.byname"
"networks" -> "networks.byaddr"
"hosts" -> "hosts.byname"
"protocols" -> "protocols.bynumber"
"services" -> "services.byname"
"aliases" -> "mail.aliases"
"ethers" -> "ethers.byname"
"rpc" -> "rpc.bynumber"
"netmasks" -> "netmasks.byaddr"
"publickey" -> "publickey.byname"
"netid" -> "netid.byname"
"passwd.adjunct" -> "passwd.adjunct.byname"
"group.adjunct" -> "group.adjunct.byname"
"timezone" -> "timezone.byname"
NIS сервер традиционно называется ypserv. Для средней сети
единственного сервера обычно хватает; большие сети могут выбирать несколько
серверов на различных машинах и различных сегментах сети, чтобы уменьшить
загрузку на машинах сервера и программах маршрутизации. Они
синхронизированы, делая один из них главным сервером, к другие
подчиненными серверами. Отображения будут созданы только на master
server's host. Оттуда, они распределены всем slaves/
Вы отметили, что мы говорили относительно " сети " очень
неопределенно все время; конечно имеется отличительное понятие в NIS,
которое относится к такой сети, и которая является системой всех хостов
та часть их данных конфигурации системы сделанны через NIS: NIS
- 180 -
область. К сожалению, NIS области не имеют абсолютно ничего общего с
областями, с которыми мы столкнулись в DNS. Избегая любой
неоднозначности через эту главу, я буду всегда точно определять который
тип области
NIS области имеют совершенно административную функцию только. Они
обычно невидимы для пользователей, кроме разделения паролей между всеми
машинами в области. Следовательно, название, данное NIS области
релевантно только администраторам. Обычно, любое название будет как
длинный поскольку это отлично от любого другого NIS названия области на
вашей локальной сети. апример, администратор в Virtual Brewery может
создайть две NIS области, одну для Brewery непосредственно, и о
которыу она называет brewery и winery, соответственно. Другая
совершенно общая схема для того, чтобы просто использовать DNS
название области для NIS. Чтобы установить и показать NIS название
области вашего множества, domainname. Когда она вызывается без любого
аргумента, это печатает текущее NIS название области; к множеству названия
области, Вы должны стать супер пользователеми ввести:
# domainname brewery
NIS области определяют, какой NIS сервер-приложение сделает
запрос. Например, программа входа в систему на множестве в Winery должна,
сделать запрос NIS сервера Winery (или один из них, если они там были
отделены) для информации пароля пользователя; в то время как приложение на
Brewery host должно приклеится к серверу Brewery'.
Одна тайна, которая пстазтся все еще не решенной, а именно, как
клиент узнает с каким сервером он соединен. Самое простое приближение
было бы иметь файл конфигурации, который называет хост, чтобы найти
сервер. Однако, это приближение было бы довольно негибко, потому что
это не позволяет клиентуре использовать различные серверы (из той
же самой области, конечно), в зависимости от их доступности.
Следовательно, традиционный NIS implementations полагаются на специальный
d чтобы обнаружить подходящий NIS сервер в их NIS области. Перед
способностью выполнить любой NIS
- 181 -
Запрос, любое приложение, сначала выясняти от ypbind который
сервер используется.
Ypbind исследует серверы, передавая к локальной IP сети; сначало
первый ответ принят, чтобы быть потенциально самым быстрым и будет
использоваться во всех последовательных запросах NIS. После того, как
некоторый интервал истек, или если сервер становится недоступным, ypbind,
исследует активные серверы снова.
Теперь, спорная точка относительно динамического связывания - то,
что Вы редко нуждайтесь в этом, и что это вводит задачу защиты:
ypbind слепо верит, кто бы ни отвечаел, который мог бы быть NIS сервером
также как и "злоумышленник". Само собой разумеется это становится
затруднением - если Вы управляете вашими базами данных паролей над NIS.
Для принятия мер против этого, NYS не использует ypbind по умолчанию, но
подбирает сервер для имени хостаиз файла конфигурации.
11.2 NIS против NIS +
NIS и NIS + принимают участие немногим больше чем их название и общая
цель. NIS + структуирован полностью различным способом. Вместо плоского
названия пространство с разделенными NIS областями, это использует
иерархическое название, оставляют промежутки подобные к таковому DNS.
Вместо отображений, так называемых таблиц используются то, что составлено
из строк и столбцов, где лаждая строка представляет предмет в NIS + базе
данных, в то время как столбцы покрывают те реквизит + знает и заботится
относительно них. Каждая таблица для данный NIS + - область
включающяя таковых родительских областей. Кроме того, запись в таблице
может содержать связь с другой таблице. Эти особенности делают его
возможным к получении информации многими способами.
Традиционный NIS имеет RPC номер версии 2, в то время как NIS + -
версию - 3.
NIS + не кажется, очень широко используемым однако, и я
действительно не знаю многого относительно этого. (Хорошо, почти ничего).
По этой причине, мы не будет связываться с этим здесь. Если Вы
- 182 -
заинтересованы в изучении большего, пожалуйста обратитесь к NIS Sun +
справочника администратора ([GETST "nisplus"]).
11.3 Клиентская Сторона NIS
Если Вы знакомы с записью или перенесением приложений сети, Вы
обязательно заметите, что большинство NIS отображений, перечисленных выше
соответствуют библиотеке функций в библиотеке C. Например, чтобы
получить passwd информацию, Вы используете getpwnam (3) и getpwuid
функции (3) которая возвращает информацию счета, связанная с данным
именем пользователя или численной идентичностью пользователя. При
нормальных обстоятельствах, эти функции будут выполнены при запросе
по на стандартном файле, типа /etc/passwd.
Nis-знающяя реализация этих функций, однако, будет модифицированна, и
место обращения RPC для того, чтобы иметь NIS сервер для поиска имен
пользователя или идентичность. Это случается полностью с приложением.
Функция может также "конкатенировать " NIS отображение или " заменить "
первоначальную картотеку с этим. Конечно, это не относится к реальной
модификации файла, это только означает то, что он появляется к приложению
как если бы файл был бы заменен или конкатенирован.
Для ттадиционных NIS реализаций, там использовались общие
условия, относительно которых замененные отображения, и которые были
конкатенированы к исходной информации. Некоторые, подобно passwd
отображениям, требуемым kludgy modifications картотеки passwd, который,
когда выполнен неправильно, обнаружил бы защиту. Чтобы избежать этого
pitfalls, NYS использует общую схему конфигурации это определяет,
использует ли частное множество клиентских функций первоначальную
карто и в каком порядке. Это будет описанный позже.
11.4 Запуск NIS Сервера
После такого многого теоретического techno-babble, это - время,
чтобы очитстить наши руки от грязной работы с конфигурации. В этом
разделе, мы опишем конфигурацию NIS сервера. Если имеется уже NIS запуск
- 183 -
сервера на вашей сети, Вы не должны будете установить ваш собственный
сервер; в этом случае, то Вы можете безопасно пропускать этот раздел.
<> Note that if you are just going to experiment with the
server, make sure you don't set it up for a NIS domain
name that is already in use on your network. This may
disrupt the entire network service and make a lot of peo-
ple very unhappy, and very angry.
В настоящее время используются два NIS сервера, свободно
доступные для Linux, один содержится в yps пакете Tobias Reber's, и
другой в Peter Erikson's ypserv package. Это не должно иметь
значение, который Вы запускаете, независимо
от того, используете ли Вы NYS или NIS клиентский код, который
находится в libc в настоящее время. Во время этой записи, цифра для
обработки NIS подчиненных серверов, кажется, более полной в yps. Так что,
если Вы должны иметь дело с подчиненными серверами, yps мог бы быть лучшим
выбором.
После установки программы сервера (ypserv) в /usr/sbkn, Вы должны
создать каталог, который будет проводить отображение, регистрируемо
на Вашем сервере. При установке NIS области для brewery domain,
отображения шло бы к /var/yp/brewery. Сервер определяет обслуживало ли это
частную NIS область, проверяя есть ли каталог отображений. Если Вы
блокируете обслуживание для некоторой NIS области, удостоверитесь удален
ли каталог также.
Отображения обычно сохраняются в картотеках DBM, чтобы ускорить
поиски. Они создаются от главы, регистрирующей использование программ,
называемой makedbm (для Tobias' сервер) или dbmload (для сервера
Peter's). Они не могут быть изменчивыми. Преобразовани е главы
регистрирует в форму parseable dbmload обычно требуя некоторого awk
или sed, которые имеют тенденцию, чтобы быть немного утомительными к
типу. Следовательно, Peter Eriksson's Ypserv пакет содержит Формирование
который делает всю работу за Вас. Вы должны установить это как
- 184 -
Формирование файла в вашем отображении, и отредактировать это, чтобы
отразить отображения которые Вы хотите распределить. В вершине
файла Вы наход услуги Ypserv. По умолчанию, просмотры линии что -
нибудь вроде этого:
all: ethers hosts networks protocols rpc services passwd group netid
Если Вы не хотите производить ethers.byname и ethers.byaddr
отображения, например, просто удалите предпосылку эфиров из этого
правила.Чтобы проверить вашу установку, это может удовлетворять тому,
чтобы начать с только одного или двух отображении, подобно услугам. *
Отображения.
После редактирования Формирования файла, в то время как Вы
находитесь в каталоге отображений, набирите "make". Это автоматически
генерирует и устанавливать отображения. Вы должны удостовериться, чтобы
модифицировать отображения всякий раз, когда Вы изменяете главный файл,
иначе изменения останутся невидимыми для сети.
Следующий раздел объясняет, кгк конфигурировать NIS клиентский код.
Если ваша установка не работает, Вы должны пробовать выяснить или любые
запросы достигнут вашего сервера или нет. Если Вы точно определяете
команду -D, флажок линии к NYS серверу, то это печатает сообщения отладки
на консоли относительно всех входящих запросов NIS, и возвращенных
результатов. Они должны дать Вам подсказку относительно того, где задача
находится. Tobias' сервер не имеет никакой такой опци
11.5 Установка NIS Клиента с NYS
Через остаток от этой главы, мы опишем конфигурацию NIS клиента.
Ваш первый шаг должен быть - сообщить NYS который сервер
использован для NIS обслуживания, устанавливая это в файле конфигурации
/etc/yp.conf. Очень прост типовой файл для множества сети Winery's может
выглядеть следующим образом:
- 185 -
# yp.conf - YP configuration for NYS library.
#
domainname winery
server vbardolino
Первая формулировка сообщает всей NIS клиентуре, что они
принадлежат к Winery NIS области. Если Вы упускаете эту линию, NYS
использует название области, которой Вы приписывали вашу систему через
команду domainname. Сервер формулировки называется NIS сервером. Конечно,
IP адреса адресуются к vbardolino, и должны быть хостом в файле хоста; в
качестве альтернативы, Вы можете использовать адрес IP непосредственно с
формулировкой сервера.
В форме, показанной выше, команда сервера сообщает, чтобы NYS
(XDR) отправителю, и преобразованны обратно к машинно - локальному
Иногда, уточнения к RPC приложению вводят несовместимые
изменения в процедуре call interface. Конечно, при простом изменение
сервер разрушил бы все приложение, которые все еще ожидают original
behavior. Следовательно, RPC программы имеют номера версии, приписываемые
к ним, обычно начинающийся с 1, и с каждой новой версией RPC свяжит с
помощью интерфейса этот счетчик. Часто, сервер может предлагать несколько
версий одновременно; клиентура затем указывает номером версии версии они
хотят использовать.
Сетевая связь между RPC серверами и клиентурой - особая. RPC
сервер предлагает один или более системных процедур; каждое множество
называется программой, и однозначно идентифицировано номером
программы. Имена обслуживания отбора списка существуют для того,
чтобы запрограммировать числа обычно сохраняемые в /etc/rpc, выборка
которого воспроизведена ниже ра рисунке 10.4
В TCP/IP сетях, перед авторами RPC стояла задача программирования
чисел к обобщенным сетевым услугам. Они выбрали - иметь каждый
сервер, обеспечивающий, и TCP и UDP порт для каждой программы и каждой
версии. Вообще, RPC приложения используют UDP посылку данных, и
возвращаются обратно к TCP тогда, когда данные, которые будут переданы не
впишутся в единственную UDP датаграмму.
Конечно, клиентские программы должны иметь способ выяснить который
из них порт отображения номера программы. Использование файла
конфигурации для этого, был бы слишком негибки; с тех пор RPC
приложения не используют зарезервированные порты, не имеется никакой
гарантии, что порт первоначально подразумевал использоваться наше
приложепие "баз данных. Следовательно, RPC приложения выбирают любой
порт который, они могут получить, и зарегистрировать это с так
называемым por действия - как обслуживание broker для всех RPC
серверов, выполняющиеся на машине: клиент, который хочет войти в контакт с
обслуживанием с данным номером программы сначала сделает запрос
- 172 -
portmapper на числа порта обслуживание, которые могут быть достигнуты.
Этот метод имеет частичный недостаток, что это вводит единственную
точку отказа, очень похожую на inetd daemon. Однако, этот случай немного
хуже, потому что когда portmapper умирает, вся RPC информация порта
теряется; это обычно значит, что Вы должны перезапустить все RPC серверы
вручную, или перезагрузить целую машину.
На Linux, portmapper называется rpc.portmap и постоянно
находится в /usr/sbin. Кроме уверения того, что это начато из rc.inet2,
рortmapper не требует любой работы по конфигурации.
10.5 Конфигурирование r команд
Имеется ряд команд для выполнения команд на remote хосте. Они -
rlogin, rsh, rcp и rcmd. Они все порождают оболочку на remote хосте и
позволяют пользователю выполнять команды. Конечно, клиент должен иметь
account на хосте, где команда должна быть выполнена. Таким образом все
эти команды выполняют процедуру разрешения. Обычно, клиент сообщяет
название входа в систему пользователя на сервер, который
#
# /etc/rpc - miscellaenous RPC-based services
#
portmapper 100000 portmap sunrpc
rstatd 100001 rstat rstat svc rup perfmeter
rusersd 100002 rusers
nfs 100003 nfsprog
ypserv 100004 ypprog
mountd 100005 mount showmount
ypbind 100007
walld 100008 rwall shutdown
yppasswdd 100009 yppasswd
bootparam 100026
" ypupdated 100028 ypupdate
- 173 -
Рис. 16. A sample /etc/rpc file.
по очереди запрашивает пароль, который утвержден обычным способом.
Иногда, однако, желательно ослабить проверки разрешения для
некоторых пользователей. Например, если Вы часто должны регистрироваться
в других машинах на вашей локальной вычислительной сети, Вы могли бы
захотеть быть признанным без ввода пароля каждый раз.
Отключение разрешения желательно только на малом числе хостов, чьи
базы данных паролей синхронизированы, или для малого числа из
привилегированных пользователей, которые должны обращаться к
многим машинам для административной причины. Всякий раз, когда Вы
хотите позволять людям регестрироваться на вашем хосте при
необходимости точно определить идентичность входа в систему или пароль,
удостоверитесь, что Вы не делаете ошибку предоставляя доступ кому-нибудь
еще.
Имеются два способа блокировать разрешение, для того чтобы проверить
r команды. Каждый - для супер пользователя, чтобы позволить
некоторым или всем пользователям зарегестрироваться без пароля. Этот
доступ управляется картотекой вызываемой /etc/hosts.equiv. Это содержит
список множеств и имен пользователя, которые рассматриваются
эквивалентными пользователям на локальном хосте. Альтернативная опция -
для пользователя - предоставление другим пользователям на некоторых х
быть перечислены в файле.rhosts в директории пользователя. Для
соображений безопасности, эта картотека должна принадлежать пользователю
или супер пользователю, и не должна быть symbolic link, иначе это будет
игнорирован
Когда клиент запрашивает r обслуживание, ее хост и название
пользователя ищются в файле /etc/hosts.equiv, и затем в файле.rhosts
пользователя. Как - пример, предположим, что janet работает "
гауссе и пытается зарегестрироваться в joe's account на euler. Следуя
далее, мы обратимся к Janet как клиентскому пользователю, и к Joe как к
Локальному пользователю.
- 174 -
Теперь, когда типы Janet
$ Rlogin -l joe euler
на гауссе, сервер сначала проверил бы hosts.equiv (4),
предоставлен ли Janet свободный доступ, и если нет, то он попробует
просмотреть.Rhosts в исходном каталоге joe's.
Файл hosts.equiv на euler походит на это:
gauss
euler
-public
quark.physics.groucho.edu andres
Запись состоит из названия хоста, необязательно сопровождаемого
именем пользователем. Если название множества появляется везде, то
все пользователи от того множества будут допущены к их локальным acount
без любых проверок. В вышеизложенном примере, Janet позволили
бы зарегестрироваться в ее account janet когда выходит из гаусса, и тот
же самый применяется любому другому пользователю за исключением root
Однако, если Janet захочет зарегестрироваться как joe , пароля как обычно.
Если название хоста сопровождается названием пользователя, как
и в последней линии вышеупомянутой типовой картотеки, то этому
пользователю будет дан пароль-свободный доступ ко всем accont за
исключением accony\t root.
Имени хоста может также предшествовать знак "минус", как на
записи "-общий". Это требует разрешения на все account на общем,
независимо от того, что пользователи единичного права предоставляют в их
картотеке.rhosts.
3. В NFS среде окружения, Вы были бы должны дать этому защиту 444,
потому что супер пользователь часто ограничивает в доступе к файлам на
дисках, установленных через NFS.
4. Заметить, что файл hosts.equiv не обыскан когда кто -то делает
попытку к регистрации как root.
- 175 -
" / 165 -
Форматфайла.rhosts идентичен таковому hosts.equiv, но значение
немного отлично. Рассмотрите Joe's.rhosts файл на Euler:
chomp.cs.groucho.edu
gauss janet
Первая запись допускает, что joe освобождают acess при
регистрации из Chomp.cs.groucho.edu, но не воздействуют на права любого
другого account на euler или chomp. Вторая запись - небольшое изменение
этого, в котором предоставляется janet свободный доступ к account Joe
при регистрации из гаусса.
Заметьте, что название хоста клиента получено обратным отбором.
Адрес вызывающего оператора к названию, так, чтобы эта особенность
failed с хостами к решающему устройству. Имя хоста клиента
рассматривается в соответствии с названим в хостах зарегистри рованных в
одном из следующих случаев:
+ Каноническиое имя хоста клиента (не псевдоним) буквально
соответствует имени хоста в файле.
+ Если имя хоста клиента - полностью квалифицированно, то название
области (типа возвращенного решающим устройством, когда Вы имеете
выполняющую DNS), не соответствует имени хоста в множествах файлов, это
сравнивается с тем именем хоста, расширенным с локальным названием
области.
11. Сетевая информационная система
Когда Вы запускаете локальную вычислительную сеть, ваша цель -
обеспечить среду окружения вашим пользователям, которая делает сеть
очевидной. Важен stepping stone к этому концу должен хранить
насущными данные типа пользователя синхронизированные между всеми
- 176 -
множествами. Мы видели перед этим, что для решенияимени хоста, мощное и
сложное обслуживание существует, являющееся DNS. Для других задачи, имеется
нет такого специализированного обслуживания. Кроме того, если В малой
локальной вычислительной сетью с no Internet activity, устанавливая DNS
может показаться утояыим затруднение для многих администраторов.
Это - то, почему Sun разрабатывало NIS, Сетевую Информационную
Систему. NIS обеспечивает обобщенные средства доступа к базе данных,
которые могут использоваться для дизинформации данных типа этого,
содержали в passwd и группах файлах всех множествах на вашей сети. Это
заставит сеть появиться только как единственная система, с теми
же самыми account на всех множествах. В подобном режиме, Вы может
использовать NIS, чтобы распределить hostname информационную форму
/etc/hos сети.
NIS основан на RPC, и включает сервер, client-side библиотеку, и
несколько административных инструментальных средств. Первоначально, NIS
назывался Желтые Страницы, или YP, который все еще широко
используется, чтобы неофициально обратиться к этой услуге. С другой
стороны, Желтые Страницы - марка изготовителя Британской Телесвязи,
которая требует от Sun убрать то название. Поскольку вещи идут, некоторый
стержень имен с людьми, и так YP живет на префиксе к именам больш команд
типа ypserv, ypbind, и т.д. Сегодня, NIS доступны для виртуально всего
Un*ces и там даже свободно реализуется. Каждый - из BSD разъединения
Сеть -2 выпуск, и был получен из общей пожертвованной реализации сноски
области Sun. Библиотечная клиентская цифра из этого разъединения была в GNU
Libc в течение длительного времени, в то время как административные
программы только недавно пренесенные к Linux Swen Thmmler. (1) NIS
сервер - отсутствуетиз реализации сноски. Tobias Reber написал другой
NIS пакет, е средства и сервер; это называется yps. (2)
В настоящее время(постоянно), полная перезапись цифры NIS, называемой
NYS, сделанная Peter Eriksson, (3), который поддерживает оба, и plain
NIS и Sun's much пересмотренным NIS.
1. swen@uni-paderborn.de. NIS клиентура доступнаы как yp-
linux.tar.gz из sunsite.unc.edu в СИСТЕМА / СЕТЬ. 2. Текущая верчия *от
этой записи) - yps-0.21 и может быть получена из ftp.lysator.liu.se в
- 177 -
/pub/NYS каталоге. 3. pen@lysator.liu.se.
+. NYS не только обеспечивает множество NIS инструментальных
средств и сервера, но и также прибавляет новое множество
библиотечных функций, которые будут наиболее возможными для того, чтобы
попасть в стандарт libc в конечном счете. Это включает новую
конфигурационную схему порции hostname решения, которое заменяет
текущую схему использованную host.conf. Особенности этих функций
будут обсуждены ниже.
Эта глава сосредоточится на NYS скорее чем на двух других
пакетах, к которому я буду относить как " традиционную " NIS цифру. Если
Вы хотите запустить этих пакетов, то команд, описанных в этой главе
может быть не достаточно. Чтобы получать дополнительн ую информацию,
пожалуйста найдите стандартную книгу по NIS, типа NFS Hal Stern's и NIS
(см. [GETST "строгий - nfs"]).
В настоящее время, NYS - все еще развивается, и следовательно
стандартные Linux утилиты типа сетевых программ или входа в систему
программ, еще не знает NYS схему конфигурации. Пока NYS соединяется в
mainstream libc Вы должны перетранслировать все эти binaries, если Вы
хотите заставить их использовать NYS. В любом из этих приложений
формирования файла, точно определите -lnsl как последнюю опция libc к
компоновщику. Это связывается на релевантных функциях из libnsl, NYS
стандарной библиотекы для C.
11.1 Знакомство с NIS
NIS хранит информацию баз данных, находящихся в так
называемых отображениях, содержащих keyvalue pairs. Отображения
сохранены на центральном хосте, выполняющем NIS сервер, из которого
клиентура может отыскивать информацию через различные RPC вызовы.
Совершенно часто, отображения сохранены в файлах DBM. (4)
Отпбражения сами по себе обычно генерируются из текстовых файлов
типа /etc/hosts или /etc/passwd. Для некоторых файлов, отдельные
- 178 -
отображения - созданы, один для каждого типа клавиши. Например, Вы
можете искать хост файл для имени хоста также как для адреса IP.
Соответственно, два NIS отображения получены из файла, вызываемый
hosts.byname и hosts.byaddr, соответственно. Таблица 11.1 списков общих
отображений и файлов из кооторых они сгенерированны.
4. DBM - простая библиотека управления базой данных которая
использует метод хеширования, чтобы ускорить операцию исследования. Имеется
свободная DBM реализация из GNU проектируемая вызываемой Gdbm, который
является частью большинства Linux распространен ия.
-----------------------------------------------------------
+-----------------+---------------------------------------+
|Master File | Map(s) |
+-----------------+---------------------------------------+
+-----------------+---------------------------------------+
|/etc/hosts | hosts.byname hosts.byaddr |
|/etc/networks | networks.byname networks.byaddr |
|/etc/passwd | passwd.byname passwd.byuid |
|/etc/group | group.byname group.bygid |
|/etc/services | services.byname services.bynumber |
|/etc/rpc | rpc.byname rpc.bynumber |
|/etc/protocols | protocols.byname protocols.bynumber |
|/usr/lib/aliases | mail.aliases |
+-----------------+---------------------------------------+
+-----------------+---------------------------------------+
Таблица 1. Некоторый стандарт NIS отображения и соответствующие
чайлы.
Имеются другие файлы и отображения, которые Вы можете найти в
любом NIS пакете или другом. Они могут содержать информацию для
приложений не обсуждаемых в этой книге, типа bootparams отображения,
которое может использоваться некоторыми BOOTP серверами, или подобно
которому в настоящее время не имеют любую функцию в Linux
(Ethers.byname и ethers.byaddr отображения).
- 179 -
Для некоторых отображений, люди обычно используют прозвища,
которые являются короткими следовательно проще. Получать полный список
прозвищ понимаемый вашими NIS инструментальными средствами, запустите
следующую команду:
$ ypcat -x
NIS map nickname translation table:
"passwd" -> "passwd.byname"
"group" -> "group.byname"
"networks" -> "networks.byaddr"
"hosts" -> "hosts.byname"
"protocols" -> "protocols.bynumber"
"services" -> "services.byname"
"aliases" -> "mail.aliases"
"ethers" -> "ethers.byname"
"rpc" -> "rpc.bynumber"
"netmasks" -> "netmasks.byaddr"
"publickey" -> "publickey.byname"
"netid" -> "netid.byname"
"passwd.adjunct" -> "passwd.adjunct.byname"
"group.adjunct" -> "group.adjunct.byname"
"timezone" -> "timezone.byname"
NIS сервер традиционно называется ypserv. Для средней сети
единственного сервера обычно хватает; большие сети могут выбирать несколько
серверов на различных машинах и различных сегментах сети, чтобы уменьшить
загрузку на машинах сервера и программах маршрутизации. Они
синхронизированы, делая один из них главным сервером, к другие
подчиненными серверами. Отображения будут созданы только на master
server's host. Оттуда, они распределены всем slaves/
Вы отметили, что мы говорили относительно " сети " очень
неопределенно все время; конечно имеется отличительное понятие в NIS,
которое относится к такой сети, и которая является системой всех хостов
та часть их данных конфигурации системы сделанны через NIS: NIS
- 180 -
область. К сожалению, NIS области не имеют абсолютно ничего общего с
областями, с которыми мы столкнулись в DNS. Избегая любой
неоднозначности через эту главу, я буду всегда точно определять который
тип области
NIS области имеют совершенно административную функцию только. Они
обычно невидимы для пользователей, кроме разделения паролей между всеми
машинами в области. Следовательно, название, данное NIS области
релевантно только администраторам. Обычно, любое название будет как
длинный поскольку это отлично от любого другого NIS названия области на
вашей локальной сети. апример, администратор в Virtual Brewery может
создайть две NIS области, одну для Brewery непосредственно, и о
которыу она называет brewery и winery, соответственно. Другая
совершенно общая схема для того, чтобы просто использовать DNS
название области для NIS. Чтобы установить и показать NIS название
области вашего множества, domainname. Когда она вызывается без любого
аргумента, это печатает текущее NIS название области; к множеству названия
области, Вы должны стать супер пользователеми ввести:
# domainname brewery
NIS области определяют, какой NIS сервер-приложение сделает
запрос. Например, программа входа в систему на множестве в Winery должна,
сделать запрос NIS сервера Winery (или один из них, если они там были
отделены) для информации пароля пользователя; в то время как приложение на
Brewery host должно приклеится к серверу Brewery'.
Одна тайна, которая пстазтся все еще не решенной, а именно, как
клиент узнает с каким сервером он соединен. Самое простое приближение
было бы иметь файл конфигурации, который называет хост, чтобы найти
сервер. Однако, это приближение было бы довольно негибко, потому что
это не позволяет клиентуре использовать различные серверы (из той
же самой области, конечно), в зависимости от их доступности.
Следовательно, традиционный NIS implementations полагаются на специальный
d чтобы обнаружить подходящий NIS сервер в их NIS области. Перед
способностью выполнить любой NIS
- 181 -
Запрос, любое приложение, сначала выясняти от ypbind который
сервер используется.
Ypbind исследует серверы, передавая к локальной IP сети; сначало
первый ответ принят, чтобы быть потенциально самым быстрым и будет
использоваться во всех последовательных запросах NIS. После того, как
некоторый интервал истек, или если сервер становится недоступным, ypbind,
исследует активные серверы снова.
Теперь, спорная точка относительно динамического связывания - то,
что Вы редко нуждайтесь в этом, и что это вводит задачу защиты:
ypbind слепо верит, кто бы ни отвечаел, который мог бы быть NIS сервером
также как и "злоумышленник". Само собой разумеется это становится
затруднением - если Вы управляете вашими базами данных паролей над NIS.
Для принятия мер против этого, NYS не использует ypbind по умолчанию, но
подбирает сервер для имени хостаиз файла конфигурации.
11.2 NIS против NIS +
NIS и NIS + принимают участие немногим больше чем их название и общая
цель. NIS + структуирован полностью различным способом. Вместо плоского
названия пространство с разделенными NIS областями, это использует
иерархическое название, оставляют промежутки подобные к таковому DNS.
Вместо отображений, так называемых таблиц используются то, что составлено
из строк и столбцов, где лаждая строка представляет предмет в NIS + базе
данных, в то время как столбцы покрывают те реквизит + знает и заботится
относительно них. Каждая таблица для данный NIS + - область
включающяя таковых родительских областей. Кроме того, запись в таблице
может содержать связь с другой таблице. Эти особенности делают его
возможным к получении информации многими способами.
Традиционный NIS имеет RPC номер версии 2, в то время как NIS + -
версию - 3.
NIS + не кажется, очень широко используемым однако, и я
действительно не знаю многого относительно этого. (Хорошо, почти ничего).
По этой причине, мы не будет связываться с этим здесь. Если Вы
- 182 -
заинтересованы в изучении большего, пожалуйста обратитесь к NIS Sun +
справочника администратора ([GETST "nisplus"]).
11.3 Клиентская Сторона NIS
Если Вы знакомы с записью или перенесением приложений сети, Вы
обязательно заметите, что большинство NIS отображений, перечисленных выше
соответствуют библиотеке функций в библиотеке C. Например, чтобы
получить passwd информацию, Вы используете getpwnam (3) и getpwuid
функции (3) которая возвращает информацию счета, связанная с данным
именем пользователя или численной идентичностью пользователя. При
нормальных обстоятельствах, эти функции будут выполнены при запросе
по на стандартном файле, типа /etc/passwd.
Nis-знающяя реализация этих функций, однако, будет модифицированна, и
место обращения RPC для того, чтобы иметь NIS сервер для поиска имен
пользователя или идентичность. Это случается полностью с приложением.
Функция может также "конкатенировать " NIS отображение или " заменить "
первоначальную картотеку с этим. Конечно, это не относится к реальной
модификации файла, это только означает то, что он появляется к приложению
как если бы файл был бы заменен или конкатенирован.
Для ттадиционных NIS реализаций, там использовались общие
условия, относительно которых замененные отображения, и которые были
конкатенированы к исходной информации. Некоторые, подобно passwd
отображениям, требуемым kludgy modifications картотеки passwd, который,
когда выполнен неправильно, обнаружил бы защиту. Чтобы избежать этого
pitfalls, NYS использует общую схему конфигурации это определяет,
использует ли частное множество клиентских функций первоначальную
карто и в каком порядке. Это будет описанный позже.
11.4 Запуск NIS Сервера
После такого многого теоретического techno-babble, это - время,
чтобы очитстить наши руки от грязной работы с конфигурации. В этом
разделе, мы опишем конфигурацию NIS сервера. Если имеется уже NIS запуск
- 183 -
сервера на вашей сети, Вы не должны будете установить ваш собственный
сервер; в этом случае, то Вы можете безопасно пропускать этот раздел.
<> Note that if you are just going to experiment with the
server, make sure you don't set it up for a NIS domain
name that is already in use on your network. This may
disrupt the entire network service and make a lot of peo-
ple very unhappy, and very angry.
В настоящее время используются два NIS сервера, свободно
доступные для Linux, один содержится в yps пакете Tobias Reber's, и
другой в Peter Erikson's ypserv package. Это не должно иметь
значение, который Вы запускаете, независимо
от того, используете ли Вы NYS или NIS клиентский код, который
находится в libc в настоящее время. Во время этой записи, цифра для
обработки NIS подчиненных серверов, кажется, более полной в yps. Так что,
если Вы должны иметь дело с подчиненными серверами, yps мог бы быть лучшим
выбором.
После установки программы сервера (ypserv) в /usr/sbkn, Вы должны
создать каталог, который будет проводить отображение, регистрируемо
на Вашем сервере. При установке NIS области для brewery domain,
отображения шло бы к /var/yp/brewery. Сервер определяет обслуживало ли это
частную NIS область, проверяя есть ли каталог отображений. Если Вы
блокируете обслуживание для некоторой NIS области, удостоверитесь удален
ли каталог также.
Отображения обычно сохраняются в картотеках DBM, чтобы ускорить
поиски. Они создаются от главы, регистрирующей использование программ,
называемой makedbm (для Tobias' сервер) или dbmload (для сервера
Peter's). Они не могут быть изменчивыми. Преобразовани е главы
регистрирует в форму parseable dbmload обычно требуя некоторого awk
или sed, которые имеют тенденцию, чтобы быть немного утомительными к
типу. Следовательно, Peter Eriksson's Ypserv пакет содержит Формирование
который делает всю работу за Вас. Вы должны установить это как
- 184 -
Формирование файла в вашем отображении, и отредактировать это, чтобы
отразить отображения которые Вы хотите распределить. В вершине
файла Вы наход услуги Ypserv. По умолчанию, просмотры линии что -
нибудь вроде этого:
all: ethers hosts networks protocols rpc services passwd group netid
Если Вы не хотите производить ethers.byname и ethers.byaddr
отображения, например, просто удалите предпосылку эфиров из этого
правила.Чтобы проверить вашу установку, это может удовлетворять тому,
чтобы начать с только одного или двух отображении, подобно услугам. *
Отображения.
После редактирования Формирования файла, в то время как Вы
находитесь в каталоге отображений, набирите "make". Это автоматически
генерирует и устанавливать отображения. Вы должны удостовериться, чтобы
модифицировать отображения всякий раз, когда Вы изменяете главный файл,
иначе изменения останутся невидимыми для сети.
Следующий раздел объясняет, кгк конфигурировать NIS клиентский код.
Если ваша установка не работает, Вы должны пробовать выяснить или любые
запросы достигнут вашего сервера или нет. Если Вы точно определяете
команду -D, флажок линии к NYS серверу, то это печатает сообщения отладки
на консоли относительно всех входящих запросов NIS, и возвращенных
результатов. Они должны дать Вам подсказку относительно того, где задача
находится. Tobias' сервер не имеет никакой такой опци
11.5 Установка NIS Клиента с NYS
Через остаток от этой главы, мы опишем конфигурацию NIS клиента.
Ваш первый шаг должен быть - сообщить NYS который сервер
использован для NIS обслуживания, устанавливая это в файле конфигурации
/etc/yp.conf. Очень прост типовой файл для множества сети Winery's может
выглядеть следующим образом:
- 185 -
# yp.conf - YP configuration for NYS library.
#
domainname winery
server vbardolino
Первая формулировка сообщает всей NIS клиентуре, что они
принадлежат к Winery NIS области. Если Вы упускаете эту линию, NYS
использует название области, которой Вы приписывали вашу систему через
команду domainname. Сервер формулировки называется NIS сервером. Конечно,
IP адреса адресуются к vbardolino, и должны быть хостом в файле хоста; в
качестве альтернативы, Вы можете использовать адрес IP непосредственно с
формулировкой сервера.
В форме, показанной выше, команда сервера сообщает, чтобы NYS