Руководство FreeBSD
Пред. | Глава 26. Сетевые серверы | След.

# 26.4. Network Information System (NIS/YP)

Текст создал Bill Swingle. Внёс добавления Eric Ogren, Udo Erdelhoff.

## 26.4.1. Что это такое?

NIS, что является сокращением от Network Information Services (Сетевые Информационные Службы), которые были разработаны компанией Sun Microsystems для централизованного администрирования систем UNIX╝ (изначально SunOS"). В настоящее время эти службы практически стали промышленным стандартом; все основные UNIX-подобные системы (Solaris", HP-UX, AIX╝, Linux, NetBSD, OpenBSD, FreeBSD и так далее) поддерживают NIS.

NIS первоначально назывались Yellow Pages (или yp), но из-за проблем с торговым знаком Sun изменила это название. Старое название (и yp) всё ещё часто употребляется.

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

Это похоже на систему доменов Windows═NT╝; хотя их внутренние реализации не так уж и похожи, основные функции сравнимы.

## 26.4.2. Термины/программы, о которых вы должны знать

Существует несколько терминов и некоторое количество пользовательских программ, которые будут нужны, когда вы будете пытаться сделать NIS во FreeBSD, и в случае создания сервера, и в случае работы в качестве клиента NIS:

Термин | Описание
--- | ---
Имя домена NIS | Главный сервер NIS и все его клиенты (включая вторичные серверы), имеют доменное имя NIS. Как и в случае с именем домена Windows═NT, имя домена NIS не имеет ничего общего с DNS.
rpcbind | Для обеспечения работы RPC (Remote Procedure Call, Удалённого Вызова Процедур, сетевого протокола, используемого NIS), должен быть запущен даемон rpcbind. Если даемон rpcbind не запущен, невозможно будет запустить сервер NIS, или работать как NIS-клиент.
ypbind | ''Связывает'' NIS-клиента с его NIS-сервером. Он определяет имя NIS-домена системы, и при помощи RPC подключается к серверу. ypbind является основой клиент-серверного взаимодействия в среде NIS; если на клиентской машине программа ypbind перестанет работать, то эта машина не сможет получить доступ к серверу NIS.
ypserv | Программа `ypserv`, которая должна запускаться только на серверах NIS: это и есть сервер NIS. Если ypserv(8) перестанет работать, то сервер не сможет отвечать на запросы NIS (к счастью, на этот случай предусмотрен вторичный сервер). Есть несколько реализаций NIS (к FreeBSD это не относится), в которых не производится попыток подключиться к другому серверу, если ранее используемый сервер перестал работать. Зачастую единственным средством, помогающим в этой ситуации, является перезапуск серверного процесса (или сервера полностью) или процесса ypbind на клиентской машине.
rpc.yppasswdd | Программа `rpc.yppasswdd`, другой процесс, который запускается только на главных NIS-серверах: это даемон, позволяющий клиентам NIS изменять свои пароли NIS. Если этот даемон не запущен, то пользователи должны будут входить на основной сервер NIS и там менять свои пароли.

## 26.4.3. Как это работает?

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

Информация во многих файлах может совместно использоваться следующим образом. Файлы `master.passwd`, `group` и `hosts` используются совместно через NIS. Когда процессу, работающему на клиентской машине, требуется информация, как правило, находящаяся в этих файлах локально, то он делает запрос к серверу NIS, с которым связан.

### 26.4.3.1. Типы машин

- Основной сервер NIS. Такой сервер, по аналогии с первичным контроллером домена Windows═NT, хранит файлы, используемые всеми клиентами NIS. Файлы `passwd`, `group` и различные другие файлы, используемые клиентами NIS, находятся на основном сервере.

  > Замечание: Возможно использование одной машины в качестве сервера для более чем одного домена NIS. Однако, в этом введении такая ситуация не рассматривается, и предполагается менее масштабное использование NIS.

- Вторичные серверы NIS. Похожие на вторичные контроллеры доменов Windows═NT, вторичные серверы NIS содержат копии оригинальных файлов данных NIS. Вторичные серверы NIS обеспечивают избыточность, что нужно в критичных приложениях. Они также помогают распределять нагрузку на основной сервер: клиенты NIS всегда подключаются к тому серверу NIS, который ответил первым, в том числе и к вторичным серверам.

- Клиенты NIS. Клиенты NIS, как и большинство рабочих станций Windows═NT, аутентифицируются на сервере NIS (или на контроллере домена Windows═NT для рабочих станций Windows═NT) во время входа в систему.

## 26.4.4. Использование NIS/YP

В этом разделе приводится пример настройки NIS.

### 26.4.4.1. Планирование

Давайте предположим, что вы являетесь администратором в маленькой университетской лаборатории. В настоящий момент в этой лаборатории с 15 машинами отсутствует единая точка администрирования; на каждой машине имеются собственные файлы `/etc/passwd` и `/etc/master.passwd`. Эти файлы синхронизируются друг с другом только вручную; сейчас, когда вы добавляете пользователя в лаборатории, вы должны выполнить команду `adduser` на всех 15 машинах. Понятно, что такое положение вещей нужно исправлять, так что вы решили перевести сеть на использование NIS, используя две машины в качестве серверов.

Итак, конфигурация лаборатории сейчас выглядит примерно так:

Имя машины | IP-адрес | Роль машины
--- | --- | ---
`ellington` | `10.0.0.2` | Основной сервер NIS
`coltrane` | `10.0.0.3` | Вторичный сервер NIS
`basie` | `10.0.0.4` | Факультетская рабочая станция
`bird` | `10.0.0.5` | Клиентская машина
`cli[1-11]` | `10.0.0.[6-17]` | Другие клиентские машины

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

#### 26.4.4.1.1. Выбор имени домена NIS

Это имя не должно быть ''именем домена'', которое вы использовали. Более точно это имя называется ''именем домена NIS''. Когда клиент рассылает запросы на получение информации, он включает в них имя домена NIS, частью которого является. Таким способом многие сервера в сети могут указать, какой сервер на какой запрос должен отвечать. Думайте о домене NIS как об имени группы хостов, которые каким-то образом связаны.

Некоторые организации в качестве имени домена NIS используют свой домен Интернет. Это не рекомендуется, так как может вызвать проблемы в процессе решения сетевых проблем. Имя домена NIS должно быть уникальным в пределах вашей сети и хорошо, если оно будет описывать группу машин, которые представляет. Например, художественный отдел в компании Acme Inc. может находиться в домене NIS с именем ''acme-art''. В нашем примере положим, что мы выбрали имя `test-domain`.

Несмотря на это, некоторые операционные системы (в частности, SunOS) используют свое имя домена NIS в качестве имени домена Интернет. Если одна или более машин в вашей сети имеют такие ограничения, вы обязаны использовать имя домена Интернет в качестве имени домена NIS.

#### 26.4.4.1.2. Требования к серверу

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

### 26.4.4.2. Серверы NIS

Оригинальные копии всей информации NIS хранится на единственной машине, которая называется главным сервером NIS. Базы данных, которые используются для хранения информации, называются картами NIS. Во FreeBSD эти карты хранятся в `/var/yp/[domainname]`, где `[domainname]` является именем обслуживаемого домена NIS. Один сервер NIS может поддерживать одновременно несколько доменов, так что есть возможность иметь несколько таких каталогов, по одному на каждый обслуживаемый домен. Каждый домен будет иметь свой собственный независимый от других набор карт.

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

#### 26.4.4.2.1. Настройка основного сервера NIS

Настройка основного сервера NIS может оказаться сравнительно простой, в зависимости от ваших потребностей. В поставку FreeBSD сразу включена поддержка NIS. Все, что вам нужно, это добавить следующие строки в файл `/etc/rc.conf`, а FreeBSD сделает за вас всё остальное..

1.     nisdomainname="test-domain"

   В этой строке задается имя домена NIS, которое будет `test-domain`, еще до настройки сети (например, после перезагрузки).

2.     nis_server_enable="YES"

   Здесь указывается FreeBSD на запуск процессов серверов NIS, когда дело доходит до сетевых настроек.

3.     nis_yppasswdd_enable="YES"

   Здесь указывается на запуск даемона `rpc.yppasswdd`, который, как это отмечено выше, позволит пользователям менять свой пароль NIS с клиентской машины.

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

После добавления вышеприведенных строк, запустите команду `/etc/netstart`, работая как администратор. По ней произойдет настройка всего, при этом будут использоваться значения, заданные в файле `/etc/rc.conf`. И наконец, перед инициализацией карт NIS, запустите вручную демон ypserv:

    # /etc/rc.d/ypserv start

#### 26.4.4.2.2. Инициализация карт NIS

Карты NIS являются файлами баз данных, которые хранятся в каталоге `/var/yp`. Они генерируются из конфигурационных файлов, находящихся в каталоге `/etc` основного сервера NIS, за одним исключением: файл `/etc/master.passwd`. На это есть весомая причина, вам не нужно распространять пароли пользователя `root` и других административных пользователей на все серверы в домене NIS. По этой причине, прежде чем инициализировать карты NIS, вы должны сделать вот что:

    # cp /etc/master.passwd /var/yp/master.passwd
    # cd /var/yp
    # vi master.passwd

Вы должны удалить все записи, касающиеся системных пользователей (`bin`, `tty`, `kmem`, `games` и так далее), а также записи, которые вы не хотите распространять клиентам NIS (например, `root` и другие пользователи с UID, равным 0 (администраторы)).

> Замечание: Проверьте, чтобы файл `/var/yp/master.passwd` был недоступен для записи ни для группы, ни для остальных пользователей (режим доступа 600)! Воспользуйтесь командой `chmod`, если это нужно.

Когда с этим будет покончено, самое время инициализировать карты NIS! В поставку FreeBSD включен скрипт с именем `ypinit`, который делает это (обратитесь к его справочной странице за дополнительной информацией). Отметьте, что этот скрипт имеется в большинстве операционных систем UNIX, но не во всех. В системе Digital Unix/Compaq Tru64 UNIX он называется `ypsetup`. Так как мы генерируем карты для главного сервера NIS, то при вызове программы `ypinit` мы передаем ей параметр `-m`. Для генерации карт NIS в предположении, что вы уже сделали шаги, описанные выше, выполните следующее:

    ellington# ypinit -m test-domain
    Server Type: MASTER Domain: test-domain
    Creating an YP server will require that you answer a few questions.
    Questions will all be asked at the beginning of the procedure.
    Do you want this procedure to quit on non-fatal errors? [y/n: n] n
    Ok, please remember to go back and redo manually whatever fails.
    If you don't, something might not work.
    At this point, we have to construct a list of this domains YP servers.
    rod.darktech.org is already known as master server.
    Please continue to add any slave servers, one per line. When you are
    done with the list, type a <control D>.
    master server	:  ellington
    next host to add:  coltrane
    next host to add:  ^D
    The current list of NIS servers looks like this:
    ellington
    coltrane
    Is this correct?  [y/n: y] y

    [..вывод при генерации карт..]

    NIS Map update completed.
    ellington has been setup as an YP master server without any errors.

Программа `ypinit` должна была создать файл `/var/yp/Makefile` из `/var/yp/Makefile.dist`. При создании этого файла предполагается, что вы работаете в окружении с единственным сервером NIS и только с машинами FreeBSD. Так как в домене `test-domain` имеется также и вторичный сервер, то вы должны отредактировать файл `/var/yp/Makefile`:

    ellington# vi /var/yp/Makefile

Вы должны закомментировать строку, в которой указано

    NOPUSH = "True"

(она уже не раскомментирована).

#### 26.4.4.2.3. Настройка вторичного сервера NIS

Настройка вторичного сервера NIS осуществляется ещё проще, чем настройка главного сервера. Войдите на вторичный сервер и отредактируйте файл `/etc/rc.conf` точно также, как вы делали это ранее. Единственным отличием является то, что при запуске программы `ypinit` мы теперь должны использовать опцию `-s`. Применение опции `-s` требует также указание имени главного сервера NIS, так что наша команда должна выглядеть так:

    coltrane# ypinit -s ellington test-domain

    Server Type: SLAVE Domain: test-domain Master: ellington

    Creating an YP server will require that you answer a few questions.
    Questions will all be asked at the beginning of the procedure.

    Do you want this procedure to quit on non-fatal errors? [y/n: n]  n

    Ok, please remember to go back and redo manually whatever fails.
    If you don't, something might not work.
    There will be no further questions. The remainder of the procedure
    should take a few minutes, to copy the databases from ellington.
    Transferring netgroup...
    ypxfr: Exiting: Map successfully transferred
    Transferring netgroup.byuser...
    ypxfr: Exiting: Map successfully transferred
    Transferring netgroup.byhost...
    ypxfr: Exiting: Map successfully transferred
    Transferring master.passwd.byuid...
    ypxfr: Exiting: Map successfully transferred
    Transferring passwd.byuid...
    ypxfr: Exiting: Map successfully transferred
    Transferring passwd.byname...
    ypxfr: Exiting: Map successfully transferred
    Transferring group.bygid...
    ypxfr: Exiting: Map successfully transferred
    Transferring group.byname...
    ypxfr: Exiting: Map successfully transferred
    Transferring services.byname...
    ypxfr: Exiting: Map successfully transferred
    Transferring rpc.bynumber...
    ypxfr: Exiting: Map successfully transferred
    Transferring rpc.byname...
    ypxfr: Exiting: Map successfully transferred
    Transferring protocols.byname...
    ypxfr: Exiting: Map successfully transferred
    Transferring master.passwd.byname...
    ypxfr: Exiting: Map successfully transferred
    Transferring networks.byname...
    ypxfr: Exiting: Map successfully transferred
    Transferring networks.byaddr...
    ypxfr: Exiting: Map successfully transferred
    Transferring netid.byname...
    ypxfr: Exiting: Map successfully transferred
    Transferring hosts.byaddr...
    ypxfr: Exiting: Map successfully transferred
    Transferring protocols.bynumber...
    ypxfr: Exiting: Map successfully transferred
    Transferring ypservers...
    ypxfr: Exiting: Map successfully transferred
    Transferring hosts.byname...
    ypxfr: Exiting: Map successfully transferred

    coltrane has been setup as an YP slave server without any errors.
    Don't forget to update map ypservers on ellington.

Теперь у вас должен быть каталог с именем `/var/yp/test-domain`. Копии карт главного сервера NIS должны быть в этом каталоге. Вы должны удостовериться, что этот каталог обновляется. Следующие строки в `/etc/crontab` вашего вторичного сервера должны это делать:

    20	*	*	*	*	root   /usr/libexec/ypxfr passwd.byname
    21	*	*	*	*	root   /usr/libexec/ypxfr passwd.byuid

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

А теперь точно также запустите команду `/etc/netstart` на вторичном сервере, по которой снова выполнится запуск сервера NIS.

### 26.4.4.3. Клиенты NIS

Клиент NIS выполняет так называемую привязку к конкретному серверу NIS при помощи даемона `ypbind`. `ypbind` определяет домен, используемый в системе по умолчанию (тот, который устанавливается по команде `domainname`), и начинает широковещательную рассылку запросов RPC в локальной сети. В этих запросах указано имя домена, к серверу которого `ypbind` пытается осуществить привязку. Если сервер, который был настроен для обслуживания запрашиваемого домена, получит широковещательный запрос, он ответит `ypbind`, который, в свою очередь запомнит адрес сервера. Если имеется несколько серверов (например, главный и несколько вторичных), то `ypbind` будет использовать адрес первого ответившего. С этого момента клиентская система будет направлять все свои запросы NIS на этот сервер. Время от времени `ypbind` будет ''пинать'' сервер для проверки его работоспособности. Если на один из тестовых пакетов не удастся получить ответа за разумное время, то `ypbind` пометит этот домен как домен, с которым связка разорвана, и снова начнет процесс посылки широковещательных запросов в надежде найти другой сервер.

#### 26.4.4.3.1. Настройка клиента NIS

Настройка машины с FreeBSD в качестве клиента NIS достаточно проста.

1. Отредактируйте файл `/etc/rc.conf`, добавив туда следующие строки для того, чтобы задать имя домена NIS и запустить `ypbind` во время запуска сетевых служб:

       nisdomainname="test-domain"
       nis_client_enable="YES"

2. Для импортирования всех возможных учётных записей от сервера NIS, удалите все записи пользователей из вашего файла `/etc/master.passwd` и воспользуйтесь командой `vipw` для добавления следующей строки в конец файла:

       +:::::::::

   > Замечание: Эта строчка даст всем пользователям с корректной учетной записью в картах учетных баз пользователей доступ к этой системе. Есть множество способов настроить ваш клиент NIS, изменив эту строку. Посмотрите ниже текст, касающийся сетевых групп, чтобы получить более подробную информацию. Дополнительная информация для изучения находится в книге издательства O'Reilly под названием `Managing NFS and NIS`.

   > Замечание: Вы должны оставить хотя бы одну локальную запись (то есть не импортировать ее через NIS) в вашем `/etc/master.passwd` и эта запись должна быть также членом группы `wheel`. Если с NIS что-то случится, эта запись может использоваться для удаленного входа в систему, перехода в режим администратора и исправления неисправностей.

3. Для импортирования всех возможных записей о группах с сервера NIS, добавьте в ваш файл `/etc/group` такую строчку:

       +:*::

Для немедленного запуска клиента NIS выполните следующую команду с правами пользователя `root`:

    # /etc/netstart
    # /etc/rc.d/ypbind start

После завершения выполнения этих шагов у вас должно получиться запустить команду `ypcat passwd` и увидеть карту учетных записей сервера NIS.

## 26.4.5. Безопасность NIS

В общем-то любой пользователь, зная имя вашего домена, может выполнить запрос RPC к ypserv(8) и получить содержимое ваших карт NIS. Для предотвращения такого неавторизованного обмена ypserv(8) поддерживает так называемую систему ''securenets'', которая может использоваться для ограничения доступа к некоторой группе хостов. При запуске ypserv(8) будет пытаться загрузить информацию, касающуюся securenets, из файла `/var/yp/securenets`.

> Замечание: Имя каталога зависит от параметра, указанного вместе с опцией `-p`. Этот файл содержит записи, состоящие из указания сети и сетевой маски, разделенных пробелом. Строчки, начинающиеся со знака ''#'', считаются комментариями. Примерный файл securenets может иметь примерно такой вид:

    # allow connections from local host -- mandatory
    127.0.0.1     255.255.255.255
    # allow connections from any host
    # on the 192.168.128.0 network
    192.168.128.0 255.255.255.0
    # allow connections from any host
    # between 10.0.0.0 to 10.0.15.255
    # this includes the machines in the testlab
    10.0.0.0      255.255.240.0

Если ypserv(8) получает запрос от адреса, который соответствует одному из этих правил, он будет отрабатывать запрос обычным образом. Если же адрес не подпадает ни под одно правило, запрос будет проигнорирован и в журнал будет записано предупреждающее сообщение. Если файл `/var/yp/securenets` не существует, `ypserv` будет обслуживать соединения от любого хоста.

Программа `ypserv` также поддерживает пакет программ TCP Wrapper от Wietse Venema. Это позволяет администратору для ограничения доступа вместо `/var/yp/securenets` использовать конфигурационные файлы TCP Wrapper.

> Замечание: Хотя оба этих метода управления доступом обеспечивают некоторую безопасность, они, как основанные на проверке привилегированного порта, оба подвержены атакам типа ''IP spoofing''. Весь сетевой трафик, связанный с работой NIS, должен блокироваться вашим брандмауэром.

> Серверы, использующие файл `/var/yp/securenets`, могут быть не в состоянии обслуживать старых клиентов NIS с древней реализацией протокола TCP/IP. Некоторые из этих реализаций при рассылке широковещательных запросов устанавливают все биты машинной части адреса в ноль и/или не в состоянии определить маску подсети при вычислении адреса широковещательной рассылки. Хотя некоторые из этих проблем могут быть решены изменением конфигурации клиента, другие могут привести к отказу от использования `/var/yp/securenets`.

> Использование `/var/yp/securenets` на сервере с такой архаичной реализацией TCP/IP является весьма плохой идеей, и приведёт к потере работоспособности NIS в большой части вашей сети.

> Использование пакета TCP Wrapper увеличит время отклика вашего сервера NIS. Дополнительной задержки может оказаться достаточно для возникновения тайм-аутов в клиентских программах, особенно в загруженных сетях или с медленными серверами NIS. Если одна или более ваших клиентских систем страдают от таких проблем, вы должны преобразовать такие клиентские системы во вторичные серверы NIS и сделать принудительную их привязку к самим себе.

## 26.4.6. Запрет входа некоторых пользователей

В нашей лаборатории есть машина `basie`, о которой предполагается, что она является исключительно факультетской рабочей станцией. Мы не хотим исключать эту машину из домена NIS, однако файл `passwd` на главном сервере NIS содержит учетные записи как для работников факультета, так и студентов. Что мы можем сделать?

Есть способ ограничить вход некоторых пользователей на этой машине, даже если они присутствуют в базе данных NIS. Чтобы это сделать, вам достаточно добавить `-`username`` в конец файла `/etc/master.passwd` на клиентской машине, где `username` является именем пользователя, которому вы хотите запретить вход. Рекомендуется сделать это с помощью утилиты `vipw`, так как `vipw` проверит ваши изменения в `/etc/master.passwd`, а также автоматически перестроит базу данных паролей по окончании редактирования. Например, если мы хотим запретить пользователю `bill` осуществлять вход на машине `basie`, то мы сделаем следующее:

    basie# vipw
    [add -bill to the end, exit]
    vipw: rebuilding the database...
    vipw: done

    basie# cat /etc/master.passwd

    root:[password]:0:0::0:0:The super-user:/root:/bin/csh
    toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh
    daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin
    operator:*:2:5::0:0:System &:/:/sbin/nologin
    bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin
    tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin
    kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin
    games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin
    news:*:8:8::0:0:News Subsystem:/:/sbin/nologin
    man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin
    bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin
    uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
    xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin
    pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin
    nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin
    +:::::::::
    -bill

    basie#

## 26.4.7. Использование сетевых групп

Текст предоставил Udo Erdelhoff.

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

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

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

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

Имена пользователей | Описание
--- | ---
`alpha`, `beta` | Обычные служащие IT-департамента
`charlie`, `delta` | Практиканты IT-департамента
`echo`, `foxtrott`, `golf`, ... | Обычные сотрудники
`able`, `baker`, ... | Проходящие интернатуру

Имена машин | Описание
--- | ---
`war`, `death`, `famine`, `pollution` | Ваши самые важные серверы. Только служащим IT позволяется входить на эти машины.
`pride`, `greed`, `envy`, `wrath`, `lust`, `sloth` | Менее важные серверы. Все сотрудники департамента IT могут входить на эти машины.
`one`, `two`, `three`, `four`, ... | Обычные рабочие станции. Только реально нанятым служащим позволяется использовать эти машины.
`trashcan` | Очень старая машина без каких-либо критичных данных. Даже проходящим интернатуру разрешено ее использовать.

Если вы попытаетесь реализовать эти требования, ограничивая каждого пользователя по отдельности, то вам придется добавить на каждой машине в файл `passwd` по одной строчке `-`user`` для каждого пользователя, которому запрещено входить на эту систему. Если вы забудете даже одну строчку, у вас могут начаться проблемы. Гораздо проще делать это правильно во время начальной установки, однако вы постепенно будете забывать добавлять строчки для новых пользователей во время повседневной работы. В конце концов, Мерфи был оптимистом.

Использование в этой ситуации сетевых групп дает несколько преимуществ. Нет необходимости описывать по отдельности каждого пользователя; вы ставите в соответствие пользователю одну или несколько сетевых групп и разрешаете или запрещаете вход всем членам сетевой группы. Если вы добавляете новую машину, вам достаточно определить ограничения на вход для сетевых групп. Если добавляется новый пользователь, вам достаточно добавить его к одной или большему числу сетевых групп. Эти изменения независимы друг от друга: нет больше комбинаций ''для каждого пользователя и машины''. Если настройка вашей системы NIS тщательно спланирована, то для разрешения или запрещения доступа к машинам вам нужно будет модифицировать единственный конфигурационный файл.

Первым шагом является инициализация карты NIS по имени netgroup. Программа ypinit(8) во FreeBSD по умолчанию этой карты не создаёт, хотя реализация NIS будет её поддерживает, как только она будет создана. Чтобы создать пустую карту, просто наберите

    ellington# vi /var/yp/netgroup

и начните добавлять содержимое. Например, нам нужно по крайней мере четыре сетевых группы: сотрудники IT, практиканты IT, обычные сотрудники и интернатура.

    IT_EMP	(,alpha,test-domain)	(,beta,test-domain)
    IT_APP	(,charlie,test-domain)	(,delta,test-domain)
    USERS	(,echo,test-domain)	(,foxtrott,test-domain) \
    	(,golf,test-domain)
    INTERNS (,able,test-domain)	(,baker,test-domain)

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

1. Имя хоста или хостов, к которым применимы последующие записи. Если имя хоста не указано, то запись применяется ко всем хостам. Если же указывается имя хоста, то вы получите мир темноты, ужаса и страшной путаницы.

2. Имя учетной записи, которая принадлежит этой сетевой группе.

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

Каждое из этих полей может содержать шаблоны, подробности даны в странице справочника по netgroup(5).

> Замечание: Не нужно использовать имена сетевых групп длиннее 8 символов, особенно если в вашем домене NIS имеются машины, работающие под управлением других операционных систем. Имена чувствительны к регистру; использование заглавных букв для имен сетевых групп облегчает распознавание пользователей, имен машин и сетевых групп.

> Некоторые клиенты NIS (отличные от FreeBSD) не могут работать с сетевыми группами, включающими большое количество записей. Например, в некоторых старых версиях SunOS возникают проблемы, если сетевая группа содержит более 15 записей. Вы можете обойти это ограничение, создав несколько подгрупп с 15 или меньшим количеством пользователей и настоящую сетевую группу, состоящую из подгрупп:

>     BIGGRP1  (,joe1,domain)  (,joe2,domain)  (,joe3,domain) [...]
>     BIGGRP2  (,joe16,domain)  (,joe17,domain) [...]
>     BIGGRP3  (,joe31,domain)  (,joe32,domain)
>     BIGGROUP  BIGGRP1 BIGGRP2 BIGGRP3

> Вы можете повторить этот процесс, если вам нужно иметь более 225 пользователей в одной сетевой группе.

Активация и распространение вашей карты NIS проста:

    ellington# cd /var/yp
    ellington# make

Это приведет к созданию трех карт NIS `netgroup`, `netgroup.byhost` и `netgroup.byuser`. Воспользуйтесь утилитой ypcat(1) для проверки доступности ваших новых карт NIS:

    ellington% ypcat -k netgroup
    ellington% ypcat -k netgroup.byhost
    ellington% ypcat -k netgroup.byuser

Вывод первой команды должен соответствовать содержимому файла `/var/yp/netgroup`. Вторая команда не выведет ничего, если вы не зададите сетевые группы, специфичные для хоста. Третья команда может использоваться пользователем для получения списка сетевых групп.

Настройка клиента достаточно проста. Чтобы настроить сервер `war`, вам достаточно запустить vipw(8) и заменить строку

    +:::::::::

на

    +@IT_EMP:::::::::

Теперь только данные, касающиеся пользователей, определенных в сетевой группе `IT_EMP`, импортируются в базу паролей машины `war` и только этим пользователям будет разрешен вход.

К сожалению, это ограничение также касается и функции `~` командного процессора и всех подпрограмм, выполняющих преобразование между именами пользователей и их числовыми ID. Другими словами, команда `cd ~`user`` работать не будет, команда `ls -l` будет выдавать числовые идентификаторы вместо имён пользователей, а `find . -user joe -print` работать откажется, выдавая сообщение `No such user`. Чтобы это исправить, вам нужно будет выполнить импорт всех записей о пользователях без разрешения на вход на ваши серверы.

Это можно сделать, добавив еще одну строку в файл `/etc/master.passwd`. Эта строка должна содержать:

`+:::::::::/sbin/nologin`, что означает ''Произвести импортирование всех записей с заменой командного процессора на `/sbin/nologin` в импортируемых записях''. Вы можете заменить любое поле в строке с паролем, указав значение по умолчанию в вашем `/etc/master.passwd`.

> Внимание: Проверьте, что строка `+:::::::::/sbin/nologin` помещена после `+@IT_EMP:::::::::`. В противном случае все пользовательские записи, импортированные из NIS, будут иметь `/sbin/nologin` в качестве оболочки.

После этого изменения при появлении нового сотрудника IT вам будет достаточно изменять только одну карту NIS. Вы можете применить подобный метод для менее важных серверов, заменяя старую строку `+:::::::::` в их файлах `/etc/master.passwd` на нечто, подобное следующему:

    +@IT_EMP:::::::::
    +@IT_APP:::::::::
    +:::::::::/sbin/nologin

Соответствующие строки для обычных рабочих станций могут иметь такой вид:

    +@IT_EMP:::::::::
    +@USERS:::::::::
    +:::::::::/sbin/nologin

И все было прекрасно до того момента, когда через несколько недель изменилась политика: Департамент IT начал нанимать интернатуру. Интернатуре в IT позволили использовать обычные рабочие станции и менее важные серверы; практикантам позволили входить на главные серверы. Вы создали новую сетевую группу `IT_INTERN`, добавили в нее новую интернатуру и начали изменять настройки на всех и каждой машине... Как говорит старая мудрость: ''Ошибки в централизованном планировании приводят к глобальному хаосу''.

Возможность в NIS создавать сетевые группы из других сетевых групп может использоваться для предотвращения подобных ситуаций. Одним из вариантов является создание сетевых групп на основе ролей. Например, вы можете создать сетевую группу с именем `BIGSRV` для задания ограничений на вход на важные серверы, другую сетевую группу с именем `SMALLSRV` для менее важных серверов и третью сетевую группу под названием `USERBOX` для обычных рабочих станций. Каждая из этих сетевых групп содержит сетевые группы, которым позволено входить на эти машины. Новые записи для вашей карты NIS сетевой группы должны выглядеть таким образом:

    BIGSRV	  IT_EMP  IT_APP
    SMALLSRV  IT_EMP  IT_APP  ITINTERN
    USERBOX   IT_EMP  ITINTERN USERS

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

Задание сетевых групп в зависимости от машин является другой возможностью, которой можно воспользоваться при изменении политики, описанной выше. При таком развитии событий файл `/etc/master.passwd` на каждой машине содержит две строки, начинающиеся с ''+''. Первая из них добавляет сетевую группу с учётными записями, которым разрешено входить на эту машину, а вторая добавляет все оставшиеся учетные записи с `/sbin/nologin` в качестве командного процессора. Хорошей идеей является использование ''ИМЕНИ МАШИНЫ'' заглавными буквами для имени сетевой группы. Другими словами, строки должны иметь такой вид:

    +@BOXNAME:::::::::
    +:::::::::/sbin/nologin

Как только вы завершите эту работу для всех ваших машин, вам не нужно будет снова модифицировать локальные версии `/etc/master.passwd`. Все будущие изменения могут быть выполнены изменением карты NIS. Вот пример возможной карты сетевой группы для этого случая с некоторыми полезными дополнениями:

    # Сначала определяем группы пользователей
    IT_EMP	  (,alpha,test-domain)	  (,beta,test-domain)
    IT_APP	  (,charlie,test-domain)  (,delta,test-domain)
    DEPT1	  (,echo,test-domain)	  (,foxtrott,test-domain)
    DEPT2	  (,golf,test-domain)	  (,hotel,test-domain)
    DEPT3	  (,india,test-domain)	  (,juliet,test-domain)
    ITINTERN  (,kilo,test-domain)	  (,lima,test-domain)
    D_INTERNS (,able,test-domain)	  (,baker,test-domain)
    #
    # Теперь задаем несколько групп на основе ролей
    USERS	  DEPT1   DEPT2     DEPT3
    BIGSRV	  IT_EMP  IT_APP
    SMALLSRV  IT_EMP  IT_APP    ITINTERN
    USERBOX   IT_EMP  ITINTERN  USERS
    #
    # И группы для специальных задач
    # Открыть пользователям echo и golf доступ к антивирусной машине
    SECURITY  IT_EMP  (,echo,test-domain)  (,golf,test-domain)
    #
    # Сетевые группы, специфичные для машин
    # Наши главные серверы
    WAR	  BIGSRV
    FAMINE	  BIGSRV
    # Пользователю india необходим доступ к этому серверу
    POLLUTION  BIGSRV  (,india,test-domain)
    #
    # Этот очень важен и ему требуются большие ограничения доступа
    DEATH	  IT_EMP
    #
    # Антивирусная машина, упомянутая выше
    ONE	  SECURITY
    #
    # Ограничить машину единственным пользователем
    TWO	  (,hotel,test-domain)
    # [...далее следуют другие группы]

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

И последнее замечание: Не всегда бывает разумно использовать сетевые группы на основе машин. Если в студенческих лабораториях вы используете несколько десятков или даже сотен одинаковых машин, то вам нужно использовать сетевые группы на основе ролей, а не основе машин, для того, чтобы размеры карты NIS оставались в разумных пределах.

## 26.4.8. Важные замечания

Есть некоторые действия, которые нужно будет выполнять по-другому, если вы работаете с NIS.

- Каждый раз, когда вы собираетесь добавить пользователя в лаборатории, вы должны добавить его только на главном сервере NIS и обязательно перестроить карты NIS. Если вы забудете сделать это, то новый пользователь не сможет нигде войти, кроме как на главном сервере NIS. Например, если в лаборатории нам нужно добавить нового пользователя `jsmith`, мы делаем вот что:

      # pw useradd jsmith
      # cd /var/yp
      # make test-domain

  Вместо `pw useradd jsmith` вы можете также запустить команду `adduser jsmith`.

- Не помещайте административные учетные записи в карты NIS. Вам не нужно распространять административных пользователей и их пароли на машины, которые не должны иметь доступ к таким учётным записям.

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

  Это основное уязвимое место в любой централизованно администрируемой системе. Если вы не защищаете ваши серверы NIS, вы будете иметь дело с толпой разозлённых пользователей!

## 26.4.9. Совместимость с NIS v1

ypserv из поставки FreeBSD имеет встроенную поддержку для обслуживания клиентов NIS v1. Реализация NIS во FreeBSD использует только протокол NIS v2, хотя другие реализации имеют поддержку протокола v1 для совместимости со старыми системами. Даемоны ypbind, поставляемые с такими системами, будут пытаться осуществить привязку к серверу NIS v1, даже если это им не нужно (и они будут постоянно рассылать широковещательные запросы в поиске такого сервера даже после получения ответа от сервера v2). Отметьте, что хотя имеется поддержка обычных клиентских вызовов, эта версия ypserv не отрабатывает запросы на передачу карт v1; следовательно, она не может использоваться в качестве главного или вторичного серверов вместе с другими серверами NIS, поддерживающими только протокол v1. К счастью, скорее всего, в настоящий момент такие серверы практически не используются.

## 26.4.10. Серверы NIS, которые также являются клиентами NIS

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

Вы можете заставить хост выполнить привязку к конкретному серверу, запустив команду `ypbind` с флагом `-S`. Если вы не хотите делать это вручную каждый раз при перезагрузке вашего сервера NIS, то можете добавить в файл `/etc/rc.conf` такие строки:

    nis_client_enable="YES"   # run client stuff as well
    nis_client_flags="-S NIS domain,server"

Дополнительную информацию можно найти на странице справки по ypbind(8).

## 26.4.11. Форматы паролей

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

Чтобы понять, какой формат используют ваши серверы и клиенты, загляните в файл `/etc/login.conf`. Если хост настроен на использование паролей, зашифрованных по алгоритму DES, то класс `default` будет содержать запись вроде следующей:

    default:\
    	:passwd_format=des:\
    	:copyright=/etc/COPYRIGHT:\
    	[Последующие строки опущены]

Другими возможными значениями для `passwd_format` являются `blf` и `md5` (для паролей, шифруемых по стандартам Blowfish и MD5 соответственно).

Если вы внесли изменения в файл `/etc/login.conf`, то вам также нужно перестроить базу данных параметров входа в систему, что достигается запуском следующей команды пользователем `root`:

    # cap_mkdb /etc/login.conf

> Замечание: Формат паролей, которые уже находятся в файле `/etc/master.passwd`, не будет изменён до тех пор, пока пользователь не сменит свой пароль после перестроения базы данных параметров входа в систему.

После этого, чтобы удостовериться в том, что пароли зашифрованы в том формате, который выбран вами, нужно проверить, что строка `crypt_default` в `/etc/auth.conf` указывает предпочтение выбранного вами формата паролей. Для этого поместите выбранный формат первым в списке. Например, при использовании DES-шифрования паролей строка будет выглядеть так:

    crypt_default	=	des blf md5

Выполнив вышеперечисленные шаги на каждом из серверов и клиентов NIS, работающих на FreeBSD, вы можете обеспечить их согласованность относительно используемого в вашей сети формата паролей. Если у вас возникли проблемы с аутентификацией клиента NIS, начать её решать определённо стоит отсюда. Запомните: если вы хотите использовать сервер NIS в гетерогенной сети, вам, наверное, нужно будет использовать DES на всех системах в силу того, что это минимальный общий стандарт.

Пред. | Начало | След.
Network File System (NFS) | Уровень выше | Автоматическая настройка сети (DHCP)

Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.