119 lines
5.3 KiB
HTML
119 lines
5.3 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
|
|
<!--Converted with LaTeX2HTML 96.1-c (Feb 29, 1996) by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds -->
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>Using the passwd and group Maps</TITLE>
|
|
</HEAD>
|
|
<BODY LANG="EN">
|
|
<A HREF="node1.html"><IMG WIDTH=65 HEIGHT=24 ALIGN=BOTTOM ALT="contents" SRC="contents_motif.gif"></A> <BR>
|
|
<B> Next:</B> <A HREF="node138.html">Using NIS with Shadow </A>
|
|
<B>Up:</B> <A HREF="node130.html">The Network Information System</A>
|
|
<B> Previous:</B> <A HREF="node136.html">Choosing the Right Maps</A>
|
|
<BR> <P>
|
|
<H1><A NAME="SECTION0012700000">Using the passwd and group Maps</A></H1>
|
|
<P>
|
|
<A NAME="nispasswd"></A>
|
|
<A NAME="5342"></A>
|
|
<A NAME="5343"></A>
|
|
<A NAME="5344"></A>
|
|
<A NAME="5345"></A>
|
|
<A NAME="5346"></A>
|
|
<A NAME="5213"></A>
|
|
<A NAME="5214"></A>
|
|
<A NAME="5215"></A>
|
|
<P>
|
|
One of the major applications of NIS is in synchronizing user and
|
|
account information on all hosts in a NIS domain. To this end, you
|
|
usually keep only a small local /etc/passwd file, to which
|
|
the site-wide information from the NIS maps is appended. However,
|
|
simply enabling NIS lookups for this service in nsswitch.conf
|
|
is not nearly enough.
|
|
<P>
|
|
When relying on the password information distributed by NIS, you first
|
|
have to make sure that the numeric user id's of any users you have in
|
|
your local passwd file match the NIS server's idea of user id's.
|
|
You will want this for other purposes as well, like mounting NFS volumes
|
|
from other hosts in your network.
|
|
<P>
|
|
If any of the numeric ids in /etc/passwd or /etc/group
|
|
deviate from those in the maps, you have to adjust file ownerships for
|
|
all files that belong to that user. First you should change all uids and gids
|
|
in passwd and group to the new values; then find all files
|
|
that belong to the users just changed, and finally change their
|
|
ownership. Assume news used to have a user id of 9, and
|
|
okir had a user id of 103, which were changed to some other
|
|
value; you could then issue the following commands:
|
|
<P>
|
|
<P><P>
|
|
<P>
|
|
It is important that you execute these commands with the <em>new</em>
|
|
passwd file installed, and that you collect all file names before
|
|
you change the ownership of any of them. To update the group ownerships
|
|
of files, you will use a similar command.
|
|
<P>
|
|
Having done this, the numerical uid's and gid's on your system will
|
|
agree with those on all other hosts in your NIS domain. The next step
|
|
will be to add configuration lines to nsswitch.conf that enables
|
|
NIS lookups for user and group information:
|
|
<P>
|
|
<P><P>
|
|
<P>
|
|
This makes the login command and all its friends first query
|
|
the NIS maps when a user tries to log in, and if this lookup fails,
|
|
fall back to the local files. Usually, you will remove almost all
|
|
users from your local files, and only leave entries for root
|
|
and generic accounts like mail in it. This is because some
|
|
vital system tasks may require to map uids to user names or vice
|
|
versa. For example, administrative cron jobs may execute the
|
|
su command to temporarily become news, or the UUCP
|
|
subsystem may mail a status report. If news and uucp
|
|
don't have entries in the local passwd file, these jobs will
|
|
fail miserably during a NIS brownout.
|
|
<P>
|
|
There are two big caveats in order here: on one hand, the setup as
|
|
described up to here only works for login suites that don't use shadow
|
|
password, like those included in the util-linux package. The
|
|
intricacies of using shadow passwords with NIS will be covered below.
|
|
On the other hand, the login commands are not the only ones that
|
|
access the passwd file-- look at the ls command which
|
|
most people use almost constantly. Whenever doing a long listing,
|
|
ls will display the symbolic names for user and group owners of
|
|
a file; that is, for each uid and gid it encounters, it will have to
|
|
query the NIS server once. This will slow things down rather badly if
|
|
your local network is clogged, or, even worse, when the NIS server is
|
|
not on the same physical network, so that datagrams have to pass
|
|
through a router.
|
|
<P>
|
|
Still, this is not the whole story yet. Imagine what happens if a user
|
|
wants to change her password. Usually, she will invoke passwd,
|
|
which reads the new password and updates the local passwd
|
|
file. This is impossible with NIS, since that file isn't available
|
|
locally anymore, but having users log into the NIS server whenever they
|
|
want to change their password is not an option either. Therefore, NIS
|
|
provides a drop-in replacement for passwd called yppasswd,
|
|
which does the analogous thing in the presence of NIS. To change the
|
|
password on the server host, it contacts the yppasswdd daemon on
|
|
that host via RPC, and provides it with the updated password
|
|
information. Usually, you install yppasswd over the normal
|
|
program by doing something like this:
|
|
<P>
|
|
<P><P>
|
|
<P>
|
|
At the same time you have to install rpc.yppasswdd on the server
|
|
and start it from rc.inet2. This will effectively hide any of
|
|
the contortions of NIS from your users.
|
|
<P>
|
|
<A NAME="5255"></A>
|
|
<A NAME="5347"></A>
|
|
<P>
|
|
<HR><A HREF="node1.html"><IMG WIDTH=65 HEIGHT=24 ALIGN=BOTTOM ALT="contents" SRC="contents_motif.gif"></A> <BR>
|
|
<B> Next:</B> <A HREF="node138.html">Using NIS with Shadow </A>
|
|
<B>Up:</B> <A HREF="node130.html">The Network Information System</A>
|
|
<B> Previous:</B> <A HREF="node136.html">Choosing the Right Maps</A>
|
|
<P><ADDRESS>
|
|
<I>Andrew Anderson <BR>
|
|
Thu Mar 7 23:22:06 EST 1996</I>
|
|
</ADDRESS>
|
|
</BODY>
|
|
</HTML>
|