Most of the utilities associated with NIS are still named with a yp prefix because it was formerly known as "Sun Yellow Pages"; trademark issues forced the name change to NIS. NIS is used to let a network of machines share information such as users and groups (the contents of /etc/passwd and /etc/group, respectively), allowing users rights on any machine within a NIS domain.
NIS operates in a manner similar to DNS in defining domains where information is distributed and also in allowing master and slave servers to hierarchically distribute information within a domain. In fact, in principle NIS could be used in place of DNS by distributing domain name information found in /etc/hosts, but this is rarely done in practice. NIS has a certain flexibility in that any type of information can, in principle, be put into a NIS database (which is in DBM format, though the tool makedbm in the NIS server package converts flat files to this format, generally "behind the scenes").
There is also a service called NIS+ which was intended to supersede NIS and includes data encryption and authentication; however, NIS+ is not backwards compatible with NIS and is not widely used.
To run any of the NIS utilities you need to run the daemon /sbin/portmap which converts RPC program numbers into TCP/IP (or UDP/IP) protocol port numbers since NIS clients make RPC calls. Most Linux distributions launch /sbin/portmap in their startup scripts, but you should check that this daemon is running with
% ps -ax | grep portmap.
If not already running, install /sbin/portmap and include it in your system startup scripts.
A NIS client includes the tools ypbind, ypwhich, ypcat, yppoll, and ypmatch. The daemon ypbind must run as root, and is normally launched as part of system startup scripts (though it is not required to do so).
The other tools rely on the services of ypbind but run at a user level. Old version of ypbind broadcast a binding request on the local network, but this allows a malicious NIS server to answer the request and provide bad user and group information to clients. It is preferable to configure specific servers for ypbind to connect to using the /etc/yp.conf file. If multiple servers are configured (or if broadcast is used despite the danger), ypbind may switch bound servers each 15 minutes according to which is able to respond most quickly. These various servers should be arranged in master/slave configuration, but the client does not need to know or care about that detail. For example, a ypbind configuration may look like:
Listing 3. /etc/yp.conf
ypserver 192.168.2.1 ypserver 192.168.2.2 ypserver 192.168.1.100 ypserver 192.168.2.200
Before /usr/sbin/ypbind runs, you must set the NIS domainname of your network. This may be whatever name the NIS server is configured to use and should generally be chosen as something different from the DNS domainname. Set the NIS domainname using (substitute the actual name):
% ypdomainname my.nis.domain.
If you want to use NIS as part of your domain name lookup, you should modify /etc/host.conf to include NIS in the lookup order; for instance, to check a name first in /etc/hosts, then in NIS, then in DNS:
Listing 4. Modifying lookup order
% cat /etc/host.conf order hosts,nis,bind
To enable NIS distributed users, you should modify the client /etc/passwd file to include
The NIS database information acts as a template for login attempts with this "unfilled" pattern. You may fine-tune the user information if you like, for example:
Listing 5. Detailed /etc/passwd
+user1::::::: +user2::::::: +user3::::::: +@sysadmins::::::: -ftp +:*::::::/etc/NoShell
This allows login access only to
user3, and all members of the sysadmin netgroup, but provides the account data of all other users in the NIS database.
NIS sources themselves are configured in /etc/nsswitch.conf. The name might suggest this is strictly for name server lookup, but a variety of information types are described. Basically, this configuration describes the order in which information sources are searched. The name
nis in an order means information obtained from a NIS server; the name
files means to use an appropriate local configuration file. The name
dns is used for the
As well, you may specify what to do if an initial source does not contain the information desired:
return means to give up (and unless NIS was simply altogether unresponsive,
continue means to try the next source for that datum). For example:
Listing 6. /etc/nsswitch.conf
passwd: compat group: compat shadow: compat hosts: dns [!UNAVAIL=return] files networks: nis [NOTFOUND=return] files ethers: nis [NOTFOUND=continue] files protocols: nis [NOTFOUND=return] files rpc: nis [NOTFOUND=return] files services: nis [NOTFOUND=return] files
The utilities ypwhich, ypcat, yppoll, and ypmatch are used at a user level to query NIS information:
- ypwchich prints the name of a NIS server.
- ypcat prints the values of all the keys in a NIS database.
- yppoll prints the version and master server of a NIS map.
- ypmatch prints the values of one or more keys from a NIS map.
See the corresponding manpages of each utility for more usage information.
A NIS server uses the ypserv daemon to provide NIS databases to clients and is configured with the /etc/ypserv.conf file. As I mentioned, you may run both master and slave NIS servers within a domain. The set of NIS databases is initialized on a master server using (just the first time you run it; after that use
make -C /var/yp like this:
% /usr/lib/yp/ypinit -m.
A slave server is really just a NIS client that gets its databases from the master server (and runs ypserv). To copy master server information to the locally running slave server, use
% /usr/lib/yp/ypinit -s my.nist.domain.
On the master server, the NIS databases are built from information in (some of) the following familiar configuration files:
Exactly what databases are exported is configured in /var/yp/Makefile which also propagates changes when it is rebuilt.
Slave servers will be notified of any change to the NIS maps when they are rebuilt (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 continually talk to the NIS server to read the information stored in its DBM databases.