Знакомство с NIS

NIS хранит информацию базы данных в файлах карт (maps), которые содержат пары ключ=значение. Примером такой пары является имя пользователя и зашифрованная форма его пароля для входа в систему. Карты хранятся на центральном главном компьютере, управляющем сервером NIS, откуда клиенты могут брать информацию через различные обращения RPC. Часто карты хранятся в DBM-файлах. DBM это простая библиотека управления базами данных, которая использует методы хеширования, чтобы ускорить операции поиска. Имеется свободная реализация DBM из проекта GNU, названная gdbm, которая является частью большинства дистрибутивов Linux.

Карты обычно генерируются из текстовых файлов типа /etc/hosts или /etc/passwd . Для некоторых файлов будет создано несколько карт, по одной для каждого типа ключа поиска. Например, Вы можете искать в файле hosts имя машины или ее IP-адрес. Соответственно, из этого файла будут получены две NIS-карты hosts.byname и hosts.byaddr . Таблица 13-1 перечисляет наиболее распространенные карты и файлы, из которых они сгенерированы.

Вы можете найти поддержку иных файлов и карт в других NIS пакетах. Они обычно содержат информацию для прикладных программ, не обсуждаемых в этой книге, типа карты bootparams, которая используется сервером Sun bootparamd.

Для некоторых карт обычно используют прозвища (nicknames), которые короче и, следовательно, их проще напечатать. Обратите внимание, что эти прозвища понятны только ypcat и ypmatch, двум инструментальным средствам для проверки Вашей конфигурации NIS. Чтобы получить полный список прозвищ, понятных этим инструментальным средствам, выполните следующую команду:

$ ypcat -x
Use "passwd" for "passwd.byname"
Use "group" for "group.byname"
Use "networks" for "networks.byaddr"
Use "hosts" for "hosts.byaddr"
Use "protocols" for "protocols.bynumber"
Use "services" for "services.byname"
Use "aliases" for "mail.aliases"
Use "ethers" for "ethers.byname"

Сервер NIS традиционно назван ypserv. Для средней сети один сервер обычно достаточен, большие сети могут выполнить несколько серверов на различных машинах и в разных сегментах сети, чтобы уменьшить загрузку на серверы и маршрутизаторы. Эти серверы должны быть синхронизированы объявлением одного из них главным (master server), а остальных подчиненными (slave servers). Карты создаются только на главном. Оттуда они распределяются на все подчиненные.

До сих пор мы очень неопределенно говорили относительно "сети". Имеется в виду особый термин в NIS: все хосты, разделяющие часть системных настроек по NIS: так называемый домен NIS (NIS domain). К сожалению, домены NIS не имеют абсолютно ничего общего с доменами, с которыми мы столкнулись в DNS. Во избежание неоднозначности мы будем всегда определять, какой тип домена имеется в виду.

NIS-домены имеют административную функцию. Они обычно невидимы для пользователей, за исключением совместного использования паролей всеми машинами в домене. Следовательно, имя, данное NIS-домену, нужно только администраторам. Обычно любое имя несет определенную смысловую нагрузку в сети. Например, администратор Virtual Brewery может создать два домена NIS: один для Brewery, второй для сети Winery, с именами brewery и winery соответственно. Можно и просто использовать имя DNS-домена и для NIS.

Чтобы устанавливать и отображать имя домена NIS Вашей машины, используйте команду domainname. Когда она вызывается без параметров, отображает текущее имя. Чтобы задать имя домена, надо задать его в качестве параметра. Введите от имени администратора:

# domainname brewery

NIS-домены определяют, к какому серверу NIS сделает запрос прикладная программа. Например, программа login на хосте в сети Winery должна опрашивать только NIS-сервер Winery (или одни из них, если там есть несколько) для получения информации о пароле пользователя, в то время как прикладная программа на машине в сети Brewery должна обращаться к серверу Brewery.

Возникает вопрос: а как клиент найдет, к какому серверу обращаться? Самое простое решение сводится к файлу конфигурации с указанием в нем имени нужной машины. Такой подход пригоден в сетях с одним сервером, но если несколько, клиент не сможет динамически запрашивать разные серверы (понятно, из одного домена) в зависимости от их доступности. Следовательно, реализации NIS полагаются на специальный daemon по имени ypbind, чтобы обнаружить подходящий сервер NIS в своем домене. Перед выполнением любого NIS-запроса, прикладная программа сначала выясняет у ypbind, какой сервер использовать.

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

Динамическое связывание полезно только, когда сеть обеспечивает больше, чем один сервер NIS. Динамическое связывание также представляет проблему защиты: ypbind просто верит, кто бы не отвечал. Так что если вместо сервера NIS ответит хакер, его ответ будет воспринят без тени недоверия. Само собой разумеется, это становится особенно ненадежным, если Вы управляете базами данных паролей по NIS. Чтобы принимать меры против этого, Linux ypbind обеспечивает два способа работы: либо обычный опрос локальной сети в поисках сервера NIS, либо указание имен машин с серверами NIS в своем файле настроек.