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

NIS хранит информацию баз данных, находящихся в так называемых отображениях, содержащих keyvalue pairs. Отображения сохранены на центральном хосте, выполняющем NIS сервер, из которого клиентура может отыскивать информацию через различные RPC вызовы. Совершенно часто, отображения сохранены в файлах DBM. (4)

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

4. DBM - простая библиотека управления базой данных которая использует метод хеширования, чтобы ускорить операцию исследования. Имеется свободная DBM реализация из GNU проектируемая вызываемой Gdbm, который является частью большинства Linux распространен ия.

Таблица 1. Некоторый стандарт NIS отображения и соответствующие чайлы.

Имеются другие файлы и отображения, которые Вы можете найти в любом NIS пакете или другом. Они могут содержать информацию для приложений не обсуждаемых в этой книге, типа bootparams отображения, которое может использоваться некоторыми BOOTP серверами, или подобно которому в настоящее время не имеют любую функцию в Linux (Ethers.byname и ethers.byaddr отображения).

Для некоторых отображений, люди обычно используют прозвища, которые являются короткими следовательно проще. Получать полный список прозвищ понимаемый вашими 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 область. К сожалению, 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

Запрос, любое приложение, сначала выясняти от ypbind который сервер используется.

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

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

Содержание раздела