Эта заметка доступна на: English Castellano Deutsch Francais Portugues Russian Turkce |
автор Об авторе: пишет диссертацию по информатике в INRIA. Он любит читать (Толкиена равно как и Бальзака) и слушать музыку (от Моцарта до Филипа Гласса и от Led Zeppelin до Massive Attack через Björk и Boris Vian, но старательно обходя рэп, техно и некоторые другие разновидности шума ;-) Содержание: |
Резюме:
Сетевой информационный сервис (Network Information Service, NIS) хранит на сервере базу данных. Любая машина в сети, на которой запущен клиент NIS, может делать запросы к серверу для получения информации типа: имя входа, пароль, информация о группах, ... . Это позволяет централизованно управлять большим количеством машин (особенно когда они используются вместе с распределенной сетевой файловой системой типа NFS), т.к. все изменения в этой информации будут переданы через сервер всем его клиентам.
Сетевой информационный сервис (NIS) первоночально был создан Sun и был известен под именем Желтые страницы Sun (Sun Yellow Pages) (часто его называют проще Желтые страницы (Yellow Pages) или YP). Однако, это имя - торговая марка British Telecom и поэтому не может использоваться без соответствующих прав. Желтые страницы British Telecom - то же самое, что мы используем для поиска телефонных номеров.
Серверы NIS хранят копии общих конфигурационных файлов нескольких сетевых машин в базе данных. Клиенты NIS направляют свои запросы к серверам вместо того, чтобы использовать собственные файлы конфигурации.
Давайте представим себя в роли пользователя сети, который хочет сменить свой пароль. Сначала предположим, что YP не установлены. Этому пользователю придется заходить на все машины в сети для смены своего пароля. Если установлены YP, появляется возможность сменить свой пароль с одной из машин, где запущен клиент NIS. Новый пароль буден передан на сервер, где он будет сменен в его базе данных. После этого, когда пользователь захочет подключиться с сетевой машины (на которой конечно же запущен клиент NIS ;-), пароль будет сверен с паролем записанным в базу данных на сервере.
Есть различные версии YP, но так как эта статья - введение, мы рассмотрим только основные принципы работы, не вникая в детали. Детали мы рассмотрим позже.
glibc 2.x (libc6) поддерживают использование NSS (сервис переключения имен - Name Switch Service), который определяет порядок поиска информации (см. файл /etc/nsswitch.conf). Он содержит карты aliases, ethers, group, hosts, netgroups, networks, protocols, publickey, passwd, rpc, services и shadow.В сети будет машина, служащая NIS сервером домена. Этот домен более или менее соответствует имени базы данных, которой будет управлять сервер. Это ключ, которым пользуются клиенты NIS, чтобы найти нужную информацию на сервере NIS. Этот домен не имеет абсолютно ничего общего с именем домена DNS. В одном домене может быть несколько NIS серверов. Каждый может управлять своим доменом (на уровне NIS), или же они могут управлять одним (в этом случае будут главный сервер и подчиненные сервера)
Подчиненные сервера содержат только копии базы данных главных серверов. Эти сервера подменяют главный сервер, когда он слишком медленно отвечает на запросы клиентов, или когда главный сервер недоступен.
Подчиненные сервера уведомляются о каждой смене в базе данных программой yppush, они обновляют свои базы, чтобы точно отражать состояние базы данных главного сервера.
Клиенты, со своей стороны, не требуют никакой "поддержки", т.к. они постоянно обращаются к серверу NIS для поиска информации в его базе.
Базы данных YP содержатся в формате GDBM, производном от фомата ASCII. Они создаются при установке сервера программой makedbm.
Эти карты устанавливают соответствие между ключом и его значением. Все карты YP основаны на этой модели. С точки зрения сервера, их содержание не имеет значения (ну кроме нескольких исключений, касающихся данных о главном сервере и временах). Это значит, что для сервера карта с паролями или группами или ... не более чем набор пар (ключ, значение). Только клиент YP знает, как вести поиск в этих картах, чтобы найти нужную информацию.
Такое представление данных имеет свои недостатки. Так как сервер не может прочитать значение ключа, а затем найти в этом значении значение второго ключа, необходимо дублировать информацию. Например, в случае паролей, кто-то может захотеть иметь возможность искать их используя имя входа или ID пользователя (UID - уникальный идентификатор каждого пользователя сети). Это приведет к избыточности информации, что можно заметить по наличию файлов passwd.byname и passwd.byuid. Следовательно, для каждого ключа будет создаваться новая карта, а это значит, что данные должны будут передаваться дважды в случае их изменения.
Чтобы найти нужную информацию в базе данных, клиенту нужны три параметра :
Таким образом, получается очень гибкая система, так как процесс создания нового домена сводится к созданию дериктории /var/yp/new_domain, копированию Makefile и выполнению его с нужными параметрами.
Работа YP коренным образом основана на механизме Удаленных Вызовов Процедуры (RPCs), который принимает запросы между сервером и его клиентами.
RPC portmapper (portmap) - программа, которая преобразует номера программ RPC в номера портов. При запуске, RPC сервер сообщает portmap, какой порт он будет использовать и какие номера программ RPC обслуживать. Когда клиент хочет сделать RPC запрос для заданного номера программы, он сначала свяжется с сервером portmap, чтобы узнать номер порта, на котором работает программа. После получения этого номера, клиент отправляет RPC пакеты на соответствующий порт. Клиент/серверная модель YP не более чем частный случай клиент/серверной модели RPC.
Файл yp_prot.h содержит структуры и прототипы 11 функций, определяющие протокол RPC между клиентами и сервером YP.
|
Webpages maintained by the LinuxFocus Editor team © Frédéric Raynal, FDL LinuxFocus.org Click here to report a fault or send a comment to LinuxFocus |
Translation information:
|
2001-07-03, generated by lfparser version 2.8