4.1. How NIS
works
Within a network there must be at least one machine acting as a
NIS server. You can have multiple NIS servers, each serving
different NIS "domains" - or you can have cooperating NIS servers,
where one is the master NIS server, and all the other are so-called
slave NIS servers (for a certain NIS "domain", that is!) - or you
can have a mix of them...
Slave servers only have copies of the NIS databases and receive
these copies from the master NIS server whenever changes are made
to the master's databases. Depending on the number of machines in
your network and the reliability of your network, you might decide
to install one or more slave servers. Whenever a NIS server goes
down or is too slow in responding to requests, a NIS client
connected to that server will try to find one that is up or
faster.
NIS databases are in so-called DBM format, derived from ASCII
databases. For example, the files /etc/passwd and /etc/group can be directly converted to DBM format
using ASCII-to-DBM translation software (makedbm, included with the server software). The
master NIS server should have both, the ASCII databases and the DBM
databases.
Slave servers will be notified of any change to the NIS maps,
(via the yppush program), and automatically
retrieve the necessary changes in order to synchronize their
databases. NIS clients do not need to do this since they always
talk to the NIS server to read the information stored in it's DBM
databases.
Old ypbind versions do a broadcast to find a running NIS server.
This is insecure, due the fact that anyone may install a NIS server
and answer the broadcast queries. Newer Versions of ypbind
(ypbind-3.3 or ypbind-mt) are able to get the server from a
configuration file - thus no need to broadcast.
