NIS: сетевая информационная служба
Категория: Совместное использование конфигов | Автор: admin | 15-05-2010, 22:27 | Просмотров: 4164

Административная база данных NIS (Network Information Service — сетевая информационная служба) была выпущена в свет компанией Sun в 80-х гг. Сначала она называлась Sun Yellow Pages (Желтые страницы Sun), но по причинам правового характера ее пришлось переименовать. Команды NIS до сих пор начинаются с префикса ур, поскольку имя, данное при рождении, забыть трудно. Многие фирмы купили у Sun лицензию на это программное обеспечение, что сделало NIS наиболее широко распространенной системой совместного использования файлов.

В начале 90-х компания Sun выпустила новую административную СУБД: NIS+. Невзирая на сходство названий, NIS и NIS+ не связаны друг с другом. Система NIS+ гораздо сложнее, чем NIS, и не столь популярна. Подробнее о ней рассказывается в параграфе 18.4. В табл. 18.2 отражены сведения о поддержке NIS и NIS+ в наших тестовых системах.

Таблица 18.2. Поддержка NIS и NIS+ в операционных системах

Система

ПоддерживаетNIS?

Поддерживает NIS+?

Solaris

Да

Да

HP-UX

Да

Да

Red Hat

Да

Нет

FreeBSD

Да

Нет

 

Единицей совместного использования в NIS является запись, а не файл. Запись обычно соответствует одной строке конфигурационного файла. Главный сервер хранит авторитетные копии системных файлов, которые находятся в своих исходных каталогах и имеют текстовый формат. Серверный процесс делает содержимое этих файлов доступным по сети. Сервер и его клиенты образуют домен NIS.

Для повышения эффективности поиска файлы подвергаются предварительной обработке подпрограммами хэширования (обычно это ndbm или ее GNU-эквивалент gdbm), превращаясь в файлы базы данных, называемые картами. После редактирования файлов на главном сервере необходимо попросить NIS преобразовать их в хэшированный формат либо с помощью программы make, либо посредством сценария ypmake (в зависимости от системы).

Базовые подпрограммы хэширования позволяют связывать с каждой записью всего один ключ, поэтому системный файл, возможно, придется транслировать в несколько карт NIS. Например, файл /etc/passwd преобразуется в две карты: passwd.byname и passwd.byuid. Первая применяется для поиска элементов по имени пользователя, а вторая — для поиска по идентификатору. Любую из них можно использовать для получения списка всех элементов файла passwd. Но хэширующие подпрограммы не сохраняют порядок записей, поэтому нельзя воссоздать точную копию исходного файла (если только он не был отсортирован).

Служба NIS позволяет тиражировать сетевые карты, размещая их на нескольких подчиненных серверах. Использование группы серверов помогает ослаблять нагрузку на главный сервер и поддерживать функционирование клиентов даже в том случае, когда некоторые серверы недоступны. Если на главном сервере файл изменился, необходимо разослать соответствующую NIS-карту на все подчиненные серверы, чтобы на всех серверах были одинаковые данные. Клиенты не различают главный и подчиненные серверы

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

Solaris и Red Hat позволяют избежать традиционного широковещательного способа обнаружения серверов NIS. Подробнее об этом рассказывается в конце данного параграфа.

 

Сетевые группы

 

Вместе с системой NIS появилось новое понятие, ставшее вскоре весьма популярным: так называемые сетевые группы. Это совокупности пользователей, компьютеров и сетей, на которые делается ссылка в системных файлах. Сетевые группы определяются в файле /etc/netgroup и становятся известными клиентам сети через NIS-карту.

Формат записи файла netgroup таков:

имя_группы список_членов

 

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

(имя_компьютера,  имя_полъзователя,  имя_домена_NIS)

 

Каждое пустое поле в триплете — это метасимвол. Так, элемент (boulder,,) ссылается на всех пользователей во всех доменах на компьютере boulder (или на сам компьютер boulder в зависимости от контекста, в котором, используется имя данной сетевой группы). Знак '-' в том или ином поле свидетельствует об отрицании. Например, элемент (boulder, -,) обозначает компьютер boulder и отсутствие пользователей. Определения групп могут быть вложенными друг в друга.

Вот простой пример файла /etc/netgroup:

 

bobcats          (snake,,)    (headrest,,)

servers          (anchor,,)   (moet,,)   (piper,,)   (kirk,,)

anchorclients    (xx,,)       (watneys,,)   (molson,,)

beers            (anchor,,)   (anchor-gateway,,)  anchorclients

allhosts         beers bobcats servers

 

 

Все эти сетевые группы определены в виде совокупностей компьютеров, что типично для реальных условий.

Сетевые группы можно использовать в различных файлах, определяющих права доступа. Например, в файле /etc/exports или в команде share (в Solaris) они указывают на то, какие компьютеры имеют право монтировать файловые системы. Это очень удобно, если файловая система экспортируется на множество компьютеров и необходимо указывать полностью определенные доменные имена, потому что длина записи в файле exports часто ограничена 1024 символами.

Вообще говоря, применение сетевых групп — прекрасная идея. Их использование помогает упростить системные файлы и сделать их более понятными. Они также дают возможность ввести дополнительный уровень абстракции, который позволяет для изменения статуса пользователя или компьютера вносить необходимые изменения в одном файле, а не в пятнадцати.

 

Задание приоритетов для источников административной информации

 

В большинстве систем информацию о конфигурации можно распространять несколькими способами. Обычные файлы способна обрабатывать любая система; кроме того, почти во всех системах реализована поддержка NIS и обеспечивается возможность поиска имен компьютеров и Internet-адресов средствами DNS. Поскольку для каждого элемента информации может существовать несколько потенциальных источников, поставщики систем обычно предусматривают способ задания источников и порядок их опроса.

В первоначальной реализации NIS некоторые конфигурационные файлы (в частности, /etc/passwd и /etc/group) должны были "втягивать" в себя содержимое соответствующих карт NIS. Для этого в сами файлы помешались особые обозначения. Одинокий символ '+' в начале строки означал включение всей карты NIS, выражение "+@сетевая_группа" задавало включение записей, относящихся только к указанной группе, а выражение "+имя" соответствовало отдельной записи.

У этого подхода никогда не было много сторонников, поэтому в большинстве систем был введен центральный конфигурационный файл /etc/nsswitch.conf, позволяющий для каждого типа административной информации указывать явный путь поиска. Типичный файл nsswitch.conf выглядит следующим образом:

 

passwd:   files nis

hosts:    files dns

group:    files

...

 

 

Каждая строка описывает отдельный тип информации (обычно это эквивалент одного текстового файла). Возможные константы источников таковы: nis, nisplus, files, dns и compat. Им соответствуют (в порядке перечисления) следующие источники: NIS, NIS+, обычные текстовые файлы (без учета специальных обозначений наподобие '+'), DNS и обычные файлы системы NIS. DNS предоставляет информацию только об узлах.

Источники просматриваются слева направо, пока один из них не выдаст ответ на запрос. В случае показанного выше примера функция gethostbyname() сначала проверит файл /etc/hosts, и если требуемый узел там не будет указан, обратится к DNS. В процессе обработки запросов, касающихся UNIX-групп, будет проверяться только файл /etc/group.

При необходимости можно явно указать, как следует поступать при получении отрицательного ответа на запрос от того или иного источника. Например, строка

hosts:      dns  [NOTFOUND=return]  nisplus

 

заставляет получать информацию только от DNS, если эта система доступна. Получение отрицательного ответа от сервера имен приведет к немедленному завершению запроса (с выдачей кода ошибки), и обращения к NIS+ не произойдет. Однако служба NIS+ будет задействована, если все серверы имен окажутся недоступными. В табл. 18.3 перечислены различные условия проверки ошибок. Каждое из них может быть задано равным return или continue, что означает соответственно прерывание запроса или переход к следующему источнику.

Таблица 18.3. Условия проверки ошибок в файле /etc/nsswftch.conf

Условие

Смысл

UNAVAIL

Источник не существует или недоступен

NOTFOUND

Источник существует, но не может ответить на запрос

TRYAGAIN

Источник существует, но занят

SUCCESS

Источник смог ответить на запрос

 

В каталоге /etc обычно содержится несколько образцов файла nsswitch.conf (ls /etc/nss*). Прежде чем создавать собственный файл, проверьте, не подойдет ли один из имеющихся вариантов.

FreeBSD еще не поддерживает концепцию центрального файла "переключения сервисов". Приоритет источников данных при поиске узлов может быть задан в файле /etc/host.conf, который является самодокументируемым. Специальные обозначения NIS должны включаться в файлы passwd и group для импорта удаленных карт. Дополнительную информацию можно получить в разделе 5 интерактивной документации по этим файлам.

 

Преимущества и недостатки NIS

 

У системы NIS есть одна хорошая черта: ее могут понять простые смертные. Работает она аналогично схеме копирования файлов. В большинстве случаев администраторам не нужно ничего знать о внутренних форматах данных NIS. Администрирование осуществляется с помощью привычных текстовых файлов, и дополнительно требуется изучить всего одну-две новые процедуры.

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

Если подчиненный сервер в момент изменения карты не работает или недоступен, находящаяся на нем копия откорректирована не будет. Подчиненные серверы должны периодически опрашивать главный сервер, чтобы иметь самую последнюю версию всех карт. Хотя в NIS есть базовые средства, позволяющие это делать, требуемую схему опроса нужно реализовывать с помощью демона cron. Но даже в этом случае существует вероятность того, что две разные версии одной карты в течение некоторого времени будут обслуживаться одновременно. При этом клиенты, получая доступ к различным подчиненным серверам, будут попеременно видеть то одну, то другую версию.

 

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

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

 

Схема работы NIS

 

Файлы данных NIS (а часто и некоторые команды этой системы) содержатся в одном каталоге, обычно /var/yp. Далее мы будем называть его "NIS-каталогом". Все NIS-карты хранятся в хэшированном виде в подкаталоге NIS-каталога, соответствующем домену NIS. Точные имена и число карт зависят от применяемой подпрограммы хэширования. Например, в домене cssuns могут быть следующие ndbm-файлы для карт файла /etc/passwd:

 

/var/yp/cssuns/passwd.byname.dir

/var/yp/cssuns/passwd.byname.pag

/var/yp/cssuns/passwd.byuid.dir

/var/yp/cssuns/passwd.byuid.pag

 

 

Помните, что для каждого поля, по которому можно произвести поиск в файле, должна быть создана отдельная карта. Поиск в файле passwd осуществляется по имени и по идентификатору, поэтому из него получаются две карты (четыре файла в случае программы ndbm).

Команда makedbm создает NIS-карты из обычных файлов. Ее никогда не нужно вызывать непосредственно. В большинстве систем файл Makefile в NIS-каталоге сконфигурирован так, чтобы автоматически генерировать все распространенные NIS-карты. После модификации системного файла перейдите в NIS-каталог и запустите программу make. Она сверит время модификации каждого файла с временем модификации карт, полученных из него, и выполнит команду makedbm для каждой карты, которую необходимо перестроить.

B HP-UX вместо программы make используется команда ypmake.

Копирование карт с главного сервера на подчиненные осуществляется с помощью команды ypxfr. Данная команда работает по принципу запроса; для того чтобы она импортировала карты, ее нужно запускать на каждом подчиненном сервере. Подчиненные серверы время от времени выполняют команду ypxfr, с тем чтобы проверить, последние ли версии карт находятся в их распоряжении. Посредством демона cron можно управлять периодичностью этих проверок.

Стандартная реализация механизма копирования карт не очень эффективна поэтому в большинстве систем существует демон ypxfrd, выполняющийся на главном сервере для ускорения ответов на запросы команды ypxfr. Этот демон работает в обход стандартного протокола NIS и просто рассылает копии файлов карт. К сожалению, в разных системах карты хранятся в разных форматах и имеют неодинаковый порядок следования байтов, поэтому применение демона ypxfrd чревато возникновением их несовместимости.

Команда yppush используется на главном сервере. Она, по сути, не пересылает никаких данных, а просто заставляет каждый подчиненный сервер выполнить команду ypxfr. Команда yppush задается в файле Makefile находящемся в NIS-каталоге, и обеспечивает принудительную рассылку откорректированных карт на подчиненные серверы.

Есть специальная карта ypservers, которая не соответствует ни одному обычному файлу. Она содержит список всех серверов данного домена и строится автоматически при его конфигурировании посредством программы ypinit (о ней будет рассказано далее). Содержимое этой карты изучается всякий раз, когда главному серверу нужно разослать карты на вспомогательные серверы.

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

Демон ypbind работает на всех компьютерах NIS-домена, включая серверы. Функции библиотеки языка С обращаются к локальному демону ypbind всякий раз, когда им нужно ответить на административный запрос (при условии, что это разрешено файлом /etc/nsswitch.conf). Демон ypbind находит в соответствующем домене демон ypserv и возвращает сведения о нем библиотечной функции, которая затем обращается непосредственно к серверу Механизм обработки запроса изображен на рис. А.

NIS: сетевая информационная служба 

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

При некоторых обстоятельствах (например, когда все серверы, кроме одного, одновременно перезагружаются) клиенты могут "закрепиться" на одном сервере и отказаться уйти с него даже после того, как станут доступны остальные серверы. Это значительно уменьшает быстродействие системы.

В NIS есть ряд вспомогательных команд, которые используются для изучения карт, определения версий карт, используемых каждым сервером, и управления привязкой клиентов к серверам. Полный перечень команд и демонов NIS дан в табл. 18.4.

Таблица 18.4. Команды и демоны системы NIS

Команда

Описание

ypserv

Демон сервера NIS, запускается во время начальной загрузки

ypbind

Демон клиента NIS, запускается во время начальной загрузки

domainname

Задаетдомен NIS, в который входитданный компьютер (выполняется во время начальной загрузки)

ypxfr

Загружает текущую версию карты с главного сервера

ypxfrd

Обслуживает запросы, поступающие от команды ypxfr (работает на главном сервере)

yppush

Заставляет подчиненный сервер обновить свою версию карты

makedbm

Создает хэшированную карту из обычного файла

ypmake'

Обновляет хэшированные карты для тех файлов, которые изменились

ypinit

Конфигурирует компьютер как главный или подчиненный сервер

ypset

Заставляет демон ypbind установить соединение с конкретным серве­ром

ypwhich

Определяет, с каким сервером работает текущий компьютер

yppoli

Определяет, какую версию карты использует сервер

ypcat

Выводит на экран значения, содержащиеся в NIS-карте

ypmatch

Выводит на экран элементы карты, соответствующие заданному ключу

yppasswd

Изменяет пароль на главном сервере NIS

ypchfn

Изменяет информацию GECOS на главном сервере NIS

ypchsh

Меняет регистрационный интерпретатор команд на главном сервере NIS

vppasswdd

Сервер для команд yppasswd, ypchsh и ypchfn

ypupdated1 

Сервер для обновления NIS-карт (им управляет демон inetd)

1   Используется не во всех системах.

 

Создание NIS-домена

 

Службу NIS следует инициализировать на главном сервере, на подчиненных серверах и на всех клиентах. Эта работа выполняется в два этапа. Во-первых, необходимо запустить программу ypinit на каждом сервере. Во-вторых, на каждом компьютере домена нужно задать доменное имя в одном из системных стартовых сценариев и сконфигурировать файл /etc/nsswitch.conf на импорт данных NIS.

 

Конфигурирование серверов NIS

 

Для инициализации главного и подчиненных серверов домена предназначена программа ypinit. На главном сервере используются следующие команды:

# cd /var/yp           /* NIS-каталог */

# domainname домен     /* имя нового домена */

# ypinit –m            /* инициализация главного сервера */

# ypserv               /* запуск сервера NIS */

 

 

Флаг -m указывает программе ypinit на то, что она конфигурирует главный сервер. Программа сама предложит ввести список подчиненных серверов. После запуска главного сервера необходимо инициализировать каждый подчиненный сервер, для чего запускается программа ypinit с флагом -s:

# cd /var/yp

# ypinit -s главный_сервер 

# ypserv

 

Команда ypinit -s создает локальную копию текущих данных главного сервера. Наличия файлов данных для какого-либо домена достаточно для того, чтобы демон ypserv знал о необходимости обслуживать этот домен.

На каждом подчиненном сервере нужно задать crontab-элементы, которые запрашивают свежие копии всех карт с главного сервера. Команда ypxfr карта (где карта — имя наподобие passwd.byuid) запрашивает указанную карту с главного сервера. Эта команда выполняется по одному разу для каждой карты. Карты, как правило, изменяются не одновременно, и если пропускная способность сети ограничена, одни карты потребуется пересылать чаще, чем другие. В большинстве случаев речь может идти о пересылке всех карт не более одого-двух раз в день (лучше поздно вечером).

Следующий сценарий организует пересылку всех карт:

 

#!/bin/csh -f

set mydomain - '/usr/bin/domainname'

cd /var/yp/$mydomain                    # NIS-каталог

foreach map ('/bin/ls')

     /usr/lib/yp/ypxfr $map

end

 

 

В некоторых системах используются готовые сценарии ypxfr_1perday; ypxfr_2perday и ypxfr_1perhour, которые пересылают NIS-карты с различной частотой.

Многие системы, поддерживающие службу NIS, на этапе начальной загрузки проверяют, является ли данный компьютер сервером NIS, и, если это так, автоматически запускают демон ypserv. В остальных системах демон нужно запускать вручную. Подробнее об этом мы расскажем далее.

Если нужно предоставить пользователям возможность изменять свои пароли посредством программы yppasswd, на главном сервере NIS следует запустить демон yppasswdd.

 

Конфигурирование клиентов NIS

 

После конфигурирования серверов необходимо проинформировать всех клиентов о том, что они стали членами нового домена. Серверы домена, как правило, являются одновременно и клиентами.

Команда domainname задает NIS-домен, которому принадлежит данный компьютер. Обычно ее выполняют в одном из стартовых сценариев на этапе начальной загрузки; детали подобного процесса зависят от системы (см. ниже).

 

Каждый клиент должен иметь, по крайней мере, личные версии файлов passwd, group и hosts в минимальной конфигурации. Первые два необходимы для того, чтобы суперпользователь мог войти в систему при отсутствии сервера NIS. Они должны содержать описания стандартных системных учетных записей и групп: root, bin, daemon, wheel и т.д. Файл hosts нужен как источник информации на этапе начальной загрузки, пока служба NIS не начала работать.

 

Особенности NIS в различных операционных системах

 

В Solaris имя домена NIS должно быть помещено в файл /etc/defaultdomain. Сценарий /etc/init.d/inetinit запрашивает этот файл при запуске системы и, если таковой существует, выполняет команду domainname, передавая ей содержимое файла в качестве единственного аргумента. В процессе начальной загрузки сценарий ypstart обнаруживает, что имя домена установлено, и запускает демоны ypbind и ypserv. На главном сервере автоматически запускаются также демоны yppasswdd и ypxfrd.

Чтобы запретить демону ypbind осуществлять широковещательный поиск серверов NIS, выполните на каждом клиентском компьютере команду ypinit -с и задайте имена серверов, с которыми должен работать каждый клиент. Для того чтобы изменения вступили в силу, нужно уничтожить демон ypbind и запустить его повторно без опции -broadcast (или перезагрузиться). Имена серверов должны присутствовать в файле /etc/hosts, лишь при этом условии они могут быть распознаны до того, как произойдет запуск NIS.

В HP-UX конфигурационная информация системы NIS хранится в файле /etc/rc.config.d/namesvrs. На клиентских компьютерах переменная NIS_DOMAIN должна содержать имя домена NIS, а переменная NIS_CLIENT должна равняться единице. На серверах нужно также переменную NIS_MASTER_SERVER или NIS_SLAVE_SERVER (но не обе) установить равной 1. Демоны yppasswdd и ypxfrd автоматически запускаются на главных серверах.

В Red Hat имя домена NIS задается в переменной NISDOMAIN в файле /etc/sysconfig/network. Запуск демонов ypbind, ypserv и yppasswdd включается и отключается с помощью команды chkconfig:

# chkconfig ypbind on

 

Демон ypbind можно заставить работать с конкретным сервером NIS (не используя широковещательный поиск), поместив следующую строку в файл /etc/yp.conf:

ypserver имя_сервера

 

Эта строка должна быть единственной в данном файле. Указанное имя сервера должно присутствовать в файле /etc/hosts.

Во FreeBSD имя домена NIS содержится в переменной nisdomainname в файле /etc/rc.conf. Например:

nisdomainname="cssuns"

 

Для запуска демонов ypbind, ypserv и yppasswdd необходимо задать значения переменных nis_client_enable, nis_server_enable и nis_yppasswdd_enable равными YES.

Файлы /etc/passwd и /etc/group должны содержать специальную метку ‘+’, если требуется использовать службу NIS в качестве источника информации.



 (голосов: 0)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page