Использование passwd и группы Maps

Одно из главных приложений NIS находится в синхронизации пользователя   и account информации относительно всех множеств в NIS области. К концу, Вы   обычно хранит только малый локальный файл /etc/passwd, к которому   добавлена site-wide информация из NIS отображений. Однако, просто   предоставления возможности NIS поиска для этого обслуживания в   nsswitch.conf не вполне достаточно.

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

  # /etc/nsswitch.conf
#
hosts:      nis dns [NOTFOUND=return] files
networks:   nis [NOTFOUND=return] files

services:   files nis
protocols:  files nis
rpc:        files nis

Примерный nsswitch.conf файл.

Если любая из числовых идентичности в /etc/passwd или /etc/group   отклоняется от тех, которые в maps, то Вы должны скорректировать файл   ownerships для всех файлов, которые принадлежат этому пользователю. Сначала   Вы должны заменить все uids и gids в passwd и в группах  новых значений;    затем найдите все файлы, которые принадлежат пользователям и были только   что изменены, и в заключение замените их ownerships. Примите новости   используемые для того, чтобы иметь идентичность пользователя была бы 9, и   okir имел бы идентичность пользователя 103, которые были заменены на   некоторое другое значение; Вы могли бы затем выполнить следующие команды:

# find / -uid   9 -print >/tmp/uid.9
# find / -uid 103 -print >/tmp/uid.103
# cat /tmp/uid.9   | xargs chown news

- 190 -

# cat /tmp/uid.103 | xargs chown okir

Важно то, что Вы выполняете эти команды с новым, установленным passwd   файлом, и что Вы собираете все имена файлов прежде, чем Вы измените   ownership любого из них. Для того, чтобы модифицировать ownerships группы   файлов, Вы должны использовать похожую команду.

Сделав это, численный uid's и gid's на вашей системе согласиться с   теми хостами, которые расположенны в Вашей NIS области. Следующий шаг будет   - прибавить линии конфигурации к nsswitch.conf, который включают NIS поиски   для пользователя и информации группы:


# /etc/nsswitch.conf - passwd and group treatment
passwd: nis files
group:  nis files

Это заставляет команду входа в систему, и всех ее друзей сначала   сделать запрос NIS maps, когда пользователь пробует log in, и если этот   поиск терпит неудачу - обратно обращается к локальным файлам. Обычно, Вы   удалите почти всех пользователей из Вашего локального файла, и только   оставите записи для root и generic accounts подобно почте. Это потому, что   некоторые насущные задачи системы могут требовать к map uids имя   пользователя или наоборот. Например, административный cron job может   выполнить команду su, для того чтобы временно стать новостями, или UUCP   подсистема может отправлять по почте отчет состояния. Если новости и   uucp не имеют вход в локальный файл passwd, то эти jobs будут, к сожалению,   терпеть неудачу в течение&NIS"brownout.   

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

  При выполнении длинной распечатки, ls выделит символические имена для   пользователя и группу владельцев файла; то есть для каждого uid и gid это   представляет собой целую схватку, это должно сделать запрос на NIS сервер,   только один раз. Это ужасно замедлит выполнение, если ваша локальная сеть -   clogged, или,  еще хуже, когда NIS сервер не на той же самой сети, для
этого датаграммы должны пройти через программу маршрутизации.   
Но пока это еще не вся история. Вообразите, что случится если   пользователь захочет изменить свой пароль. Обычно, она вызовет passwd,   который считает новый пароль и модифицирует локальный файл passwd. Это   невозможно сделать с NIS, так как с тех пор файл локально больше не   доступен, но если пользователи подсоединились к NIS серверу, и вдруг   захотели изменить пароль, то дляч этого, к сожалению нет опции. Поэтому,   NIS обеспечивает отпуск в замене для passwd, называемого yppasswd, который   делает аналогичную вещь в присутствии NIS. Для изменения пароля на хост   сервере, но в контакт с yppasswdd daemon на том же самом хосте через RPC, и   обеспечивает его модифицируемой информацией пароля. Обычно, Вы
устанавливаете yppasswd для нормальной программы,  делая что - нибудь вроде   этого:

# cd /bin
# mv passwd passwd.old
# ln yppasswd passwd

В то же самое время Вы должны установить rpc.yppasswdd на сервер и   запустить его из rc.inet2. Это эффективно слроет любые искожения NIS от   ваших пользователей.