Network Information Service:

One of the fundamental problems with standard UNIX accounts is that
they are confined to a single host.  If you have accounts on several
separate UNIX hosts, when you (for example) change your password,
that change will only be reflected on the host that you ran the "passwd"
command on.  The solution to this problem is NIS.

  Background:

  Programs like login(1) and passwd(1) don't manually parse the passwd
  file --- they instead make a library call: getpwent(3), getpwnam(3),
  getpwuid(3).  These library routines take all of the hassle out of
  each program having to know the format of the password file.  They
  each return a structure that represents the contents of the appropriate
  password file line.

Since the problem of parsing the password file is largely relegated to
the {g,s}etpw{nam,uid,ent}(3) library functions, if we wanted to change
the way that accounts were seen on a host, we would just need to change
these functions.  There have been many different implementations of ways
to do this, but the one that has caused the fewest complaints is NSS.
NSS is a way to control the library functions that read a few of the system
databases (mainly /etc/hosts, /etc/passwd, and /etc/group, but some systems
use it for more files).  It uses the configuration file /etc/nsswitch.conf.
Please see the manual page for your particular UNIX, but for example, Linux
lets you use NIS for accounts just by putting the following 2 lines in
/etc/nsswitch.conf:

   passwd: compat
   group:  compat

Once these lines are in place, Linux's {g,s}etpw{ent,nam,uid} library
calls will the following 3 special types of entries in /etc/passwd:

  +login::::::
  +@netgroup::::::
  +::::::

We will learn more about what these do.

NIS Clients and Servers:

  The client/server architecture of NIS is quite familiar: a client process
  communicates with a server process.  NIS also extends the role of server
  by allowing there to be more than one.  These servers are either the master,
  or a slave.  There can be many slaves.  The servers are indistinguishable
  to the clients, but the master server will know the list of slave servers,
  and will help them to update their databases.

  There are 4 primary NIS processes: ypserv, ypbind, ypxfer, and yppush.
  ypserv(8) is the server process, ypbind(8) is the client process, 
  yppush(8) is used with ypxfer(8) for synchronizing several servers.
  A simple network map looks like:

    Client computer:      Server Computer (master):

    ypbind                ypserv
                          ypbind
                          yppush

    Client computer:      Server Computer (slave)

    ypbind                ypserv
                          ypbind
                          ypxfer

  In this map, the client computers ypbinds communicate with the server
  computers ypservs.  The server computers also need to have a ypbind
  process running (they will also communicate with the server ypservs) if
  they are to see the NIS accounts.  The master server also runs yppush
  whenever it wants to tell a slave server that the databases have changed.

Netgroups:

  The only new idea that NIS brings is that of a netgroup.  A netgroup
  is a list of tuples of (host, user, domain) (we'll ignore the domain
  part of NIS --- it is just to distinguish between organizational units
  on a network).  These tuples *could* be used to do anything, but there
  are two main ways that they *are* used:

    1.  Netgroup of users
    2.  Netgroup of hosts

  A netgroup of users is used mainly to describe who can access a specific
  machine.  A netgroup of hosts is mainly used by services like NFS to
  describe a list of hosts that can access a specific resource.

Wrapping up:

  Earlier we described three new kinds of password fields that can be
  used in a client password file under NIS.  These are:

    +@netgroup::::::(optional shell)
    +login::::::(optional shell)
    +::::::(optional shell)

  The "+@netgroup" line will make the accounts listed in the user netgroup
  "netgroup" available on the client computer.  If a shell field is provided,
  all of the accounts will use that as their shell, otherwise they will use
  their normal shell.  The shell is a convenient way to provide informative
  messages to users:  if the shell is set to a script that prints an message,
  users can be informed that a machine isn't one that they should be using.

  The "+login" line works just as the "+@netgroup", but it only applies to
  the login "login".  The "+" line applies to *all* NIS accounts.