Home Map Index Search News Archives Links About LF
[Top bar]
[Bottom bar]
Эта заметка доступна на: English  Castellano  Deutsch  Francais  Nederlands  Portugues  Russian  Turkce  

[Фотография автора]
автор Frédéric Raynal

Об авторе:
Frédéric Raynal пишет диссертацию по информатике в INRIA. Он любит читать (Толкиена равно как и Бальзака) и слушать музыку (от Моцарта до Филипа Гласса и от Led Zeppelin до Massive Attack через Björk и Boris Vian, но старательно обходя рэп, техно и некоторые другие разновидности шума ;-)
Содержание:

Yellow Pages, часть 1

[Иллюстрация]

Резюме:

Сетевой информационный сервис (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. Следовательно, для каждого ключа будет создаваться новая карта, а это значит, что данные должны будут передаваться дважды в случае их изменения.

Чтобы найти нужную информацию в базе данных, клиенту нужны три параметра :

  1. имя домена - это имя базы данных на сервере YP
  2. имя карты
  3. имя ключа
Итак, для того чтобы клиент нашел пароль пользователя Toto в домене titi, он будет читать файл /var/yp/titi/passwd.byname на сервере YP в поисках пользователя Toto.

Таким образом, получается очень гибкая система, так как процесс создания нового домена сводится к созданию дериктории /var/yp/new_domain, копированию Makefile и выполнению его с нужными параметрами.

Удаленные вызовы процедуры (Remote Procedure Calls, RPC)

Работа YP коренным образом основана на механизме Удаленных Вызовов Процедуры (RPCs), который принимает запросы между сервером и его клиентами.

RPC portmapper (portmap) - программа, которая преобразует номера программ RPC в номера портов. При запуске, RPC сервер сообщает portmap, какой порт он будет использовать и какие номера программ RPC обслуживать. Когда клиент хочет сделать RPC запрос для заданного номера программы, он сначала свяжется с сервером portmap, чтобы узнать номер порта, на котором работает программа. После получения этого номера, клиент отправляет RPC пакеты на соответствующий порт. Клиент/серверная модель YP не более чем частный случай клиент/серверной модели RPC.

Файл yp_prot.h содержит структуры и прототипы 11 функций, определяющие протокол RPC между клиентами и сервером YP.

Заключение

Теперь, когда мы знаем основные принципы, следующая статья будет посвящена клиентской стороне желтых страниц : как она работает, как ее настроить, утилиты, которыми она пользуется и т.д. Также мы рассмотрим утилиты необходимые, чтобы правильно настроить как RPCs так и YP на стороне клиента.  

Страница отзывов

У каждой заметки есть страница отзывов. На этой странице вы можете оставить свой комментарий или просмотреть комментарии других читателей.
 talkback page 

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:
fr -> -- Frédéric Raynal
fr -> en Johan Decock
en -> ru Kolobynin Alexey

2001-07-03, generated by lfparser version 2.8