Руководство администратора сети в ОС Linux

       

Использование 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

Рисунок 17. Примерный 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 # 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 от ваших пользователей.


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