This chapter provides information on the Network Information Service (NIS), which is installed as part of the Network File System (NFS). This chapter includes the following sections:
See Chapter 8, NIS and NIS+ Troubleshooting for information on diagnosing and resolving NIS-related problems.
Network Information Service (NIS) is a distributed database that allows you to maintain consistent configuration files throughout your network. NIS is the current name for the service originally known as Yellow Pages (YP). NIS and YP are functionally identical.
NIS is a part of the Network File System (NFS) software package that includes commands and daemons for NFS, NIS, and other services. Although NFS and NIS are installed together as one package, each is independent and each is configured and administered individually. For information on how NFS works with the operating system see the AIX 5L Version 5.1 System Management Guide: Communications and Networks. You should obtain a copy of the book Managing NFS and NIS (see Related Publications) for a thorough treatment of the advanced features of NIS.
Note: If the file /var/yp/securenets exists, the server only provides NIS services to the hosts within the Internet Protocol (IP) range specified.
The NIS environment is composed of clients and servers logically grouped together in a domain. Each domain has a particular set of characteristics. These characteristics are defined in maps, or databases, that specify certain system information such as user names, passwords, and host names. Each of these components is discussed in detail below.
An NIS server is a host that provides configuration information to other hosts on the network. Servers retain a set of maps and run the ypserv daemon, which processes requests from clients for information contained in maps. There are two types of servers: a master server and a slave server.
A master server is the single host in a particular domain that maintains the authoritative maps. The master server runs ypupdated daemon, which prompts slave servers to update their copies of the maps (all other hosts in the domain must obtain their map information from the master server, either directly or indirectly). The master server also runs the yppasswdd daemon, which processes requests to change users' passwords. Recommended characteristics of the master server include:
For a small number of hosts, each host can access the master server directly. However, for a larger number of hosts in a domain, the master server can become overloaded. To balance the NIS processing load and provide services when the master server is unavailable, additional hosts can be designated as slave servers.
NIS slave servers act as intermediaries between clients and the master server by keeping exact replicas of the master server's maps. All changes to the maps are made on the master server. Then, the changes are propagated from the master server to the slave servers. Once a slave server is added to the domain, it is able to answer the same queries that the master is able to answer. In this way, slave servers can help with extra load on the master server without violating the authority of the master server.
Slave servers also act as a backup in case the master server or the network fails. A client requesting information waits until a server responds. This waiting time varies depending on the reason the server is unreachable. Adding slave servers increases the availability of information even if the master server is unavailable.
Normally, there should be at least one slave server for each domain. The number of slave servers in a domain should be balanced to achieve the desired level of availability and response time without adding the expense of copying data to too many systems.
NIS clients make up the majority of hosts in a NIS domain. Clients run the ypbind daemon, which enables client processes to obtain information from a server. Clients do not maintain maps themselves, but rather query servers for system and user account information. (Clients do not make a distinction between querying the master server or a slave server.) To access system information contained in an map, a client makes a Remote Procedure Call (RPC) to a server. The server searches its local database and returns the requested information to the client. (See AIX 5L Version 5.1 Communications Programming Concepts for detailed information about RPCs.)
NIS clients locate the server by broadcasting on the networks that are directly connected to the client machine. Since these broadcast messages are not forwarded by network gateways, if there is no NIS server that can be reached without using a network gateway, the client must specify a server when starting the ypbind daemon.
Note that every request for system information requires a server contact, and the speed of your network can affect the response time. Although a local retrieval is usually faster than a network retrieval, the benefits of NIS outweigh the compromise in access time.
An NIS domain is a collection of systems that are logically grouped together. A group of hosts that share the same set of NIS maps belong to the same domain. The hosts are usually grouped together in the domain for a common reason; for example, when working in the same group at a particular location. Each NIS host is assigned to a domain when the system starts. The domain name must be set on all hosts that intend to use NIS.
There is one master server per NIS domain, and the systems in the domain are typically on the same network. However, access to data served by NIS is independent of the relative locations of an NIS client and server. All systems within the NIS domain use the master server to retrieve system information, and the number of systems in a domain must be limited for the sake of efficiency. As the number of systems grows, the response time from the master server increases because of the increased workload. By design, you cannot add another master server to a domain because there would be two authoritative sources for the maps. To reduce master server load, you can add slave servers to the domain, or define more than one domain. Each new domain, of course, has its own master server.
NIS maps are databases that specify certain system information such as user names, passwords, and host names, in a database format called DBM (Database Management). Each map is constructed from a standard text file by associating an index key with a value. For example, the information in the master server's /etc/hosts file is used to create a map that uses each host name as a key, and the IP address as the value. The key and value pairs (also known as records) that are created from the entries in the/etc/hosts file comprise the hosts.byname map.
Attention: An NIS record has a maximum size of 1024 bytes. This limitation applies to all NIS map files. For example, a list of users in a group can contain a maximum of 1024 characters in single-byte character set file format. NIS cannot operate correctly with map files that exceed this maximum.
The most commonly used maps have nicknames that some commands can translate into map names. For instance, when you enter:
ypcat hosts
the output you receive is actually the contents of the hosts.byname map, because there is no map called hosts in the NIS database. (The ypcat -x command produces a list of available nicknames.)
By default, the maps listed in the
following table are created if their corresponding files are available on the
master server:
Notice that no file corresponds to the ypservers map. ypservers is a special map that contains the names of the NIS servers, both slave and master, in the domain. Clients use the ypservers map to find the nearest available server. The master server refers to it to determine the names of the slave servers that need to obtain updated copies of the NIS maps. Information about specifying the input to the ypservers map is discussed in Configuring the NIS Master Server and in Adding a New NIS Slave Server.
The /etc/netgroup file is not a standard Transmission Control Protocol/Internet Protocol (TCP/IP) file. Rather, it is strictly an NIS file that resides on the master server. NIS uses the /etc/netgroup file to generate the netgroup.byuser and netgroup.byhost maps. NIS provides these maps for authentication purposes during login, remote login, remote mount, and remote shell processes.
Specifically, the programs that consult these maps are:
For detailed information on the format of the /etc/netgroup file, see netgroup File for NIS in the AIX 5L Version 5.1 Files Reference.
NIS maps are created by the makedbm command, converting text files into DBM format files. To simplify maintaining your maps, NIS provides a makefile for use with the make command. The default makefile (/var/yp/Makefile) contains all the instructions necessary to create all the default maps. You can add stanzas to /var/yp/Makefile to create additional maps. However, the default makefile is sufficient to address the basic needs of most NIS installations.
When the makedbm command generates an NIS map, it creates two files: map.key.pag and map.key.dir. For example, the host.byname map consists of the hosts.byname.pag and hosts.byname.dir files. The file with the .pag extension contains the key and value pairs, while the file with the .dir extension is the index for the .pag file. All the maps for a domain are stored on the servers in a subdirectory of the /var/yp directory. The subdirectory has the same name as the domain. For example, maps for the literature domain are located in the /var/yp/literature subdirectory.
NIS maintains consistent system information throughout the domain by designating one system, the master server, as the sole source of information. All the other hosts, whether they are slave servers or clients, obtain their system information from the master server.
Clients obtain their information on an as-needed basis. When a client needs a piece of system information, such as an entry from the /etc/passwd file, it sends a request to a server. If the information exists, the server responds with the information. Since the client obtains the information only as needed, the system information at the client remains consistent with the server.
Slave servers, on the other hand, obtain a complete copy of the maps periodically from the master server. To ensure that the system information is consistent at the slave servers, and therefore throughout the whole domain, make all updates to the maps at the master server. Then, propagate the new maps to the slave servers. To propagate a map means to copy it from the master server to all the slave servers. Propagation eliminates the need to update each map individually. In addition, propagation ensures that all copies of the database are exactly the same; therefore, any server can respond to a client's request.
After you update a map on the master server, there are three ways to propagate the new map: