This section discusses the following topics:
Network Information Service (NIS) is a distributed database that allows you to maintain consistent configuration files throughout your network. 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. NIS is the current name for the service originally known as "Yellow Pages" (YP). NIS and YP are functionally identical.
Depending on your needs, NIS can be fairly straightforward to manage, or it can be quite complex. This documentation of NIS will focus on aspects specific to this operating system. You should obtain a copy of the book Managing NFS and NIS 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.
NIS benefits users because it improves ease of use of a network. Without NIS, having a large number of systems on the network can create problems for the user. The user would need to remember a different password for every system they use, or else maintain the same password for every system themselves, and update their password on each system separately.
NIS benefits system administrators because it improves ease of administration of a network. NIS reduces the effort of maintaining a large number of systems and provides a global user ID (UID) and group ID (GID) name space. Suppose you are using NFS to make the user's directories and files available on every system. Because NFS does not try to translate UIDs or GIDs between systems, you must ensure that each user in the network has the same user ID and group ID on every system. For example, a user on a workstation whose UID is 205 and whose GID is 35 must have the same UID and GID (205 and 35) in the /etc/passwd file on every workstation that user accesses. If this is not done, a user on one system who creates a file and logs into another system may find that the file is owned by another user.
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 (every other host in the domain must obtain its 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. Some of the characteristics of the master server should be the following:
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. So, 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 fails, or the network fails and as a result the master server becomes unreachable. 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.
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.
NIS clients locate the server by broadcasting on the networks that are directly connected to the client machine. Since these broadcast messages will not be 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 retrieve is usually faster than a network retrieve, the benefits of NIS outweigh this modest 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 is moderate. 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. So, to reduce master server load, you can add slave servers to the domain, or define more than one domain. Each new domain will, of course, have 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.
Note: An NIS record has a maximum size of 1024 bytes. For example, a list of users in a group can contain a maximum of 1024 characters in single-byte character set file format.
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:
| Maps Created by Default (if file is available on master server) | ||
| Map | Nickname | File |
| passwd.byname | passwd | /etc/passwd |
| passwd.byuid | ||
| group.byname | group | /etc/group |
| group.bygid | ||
| hosts.byaddr | hosts | /etc/hosts |
| hosts.byname | ||
| ethers.byaddr | ethers | /etc/ethers |
| ethers.byname | ||
| networks.byaddr | networks | /etc/networks |
| networks.byname | ||
| rpc.bynumber | /etc/rpc | |
| services.byname | services | /etc/services |
| protocols.byname | protocols | /etc/protocols |
| protocols.bynumber | ||
| netgroup.byhost | /etc/netgroup | |
| netgroup.byuser | ||
| bootparams | /etc/bootparams | |
| mail.aliases | aliases | /etc/aliases |
| mail.byaddr | ||
| publickey.byname | /etc/publickey | |
| netid.byname | /etc/passwd | |
| /etc/group | ||
| /etc/hosts | ||
| /etc/netid | ||
| netmasks.byaddr | /etc/netmasks | |
| ypservers | ||
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. And the master server refers to it to determine the names of the slave servers that need to obtain updated copies of the NIS maps. The details of how you specify the input to the ypservers map is discussed in "Configuring the NIS Master Server" and in "Adding a New NIS Slave Server".
Notice also that 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 execution of login, remote login, remote mount, and remote shell processes.
Specifically, the programs that consult these maps are the login command, the rlogin command, the mountd daemon, and the rsh command. The login command consults the maps for user classifications if it encounters netgroup names in the /etc/passwd file. The mountd daemon consults the maps for machine classifications if it encounters netgroup names in the /etc/exports file. The rlogin command and the rsh command consult the netgroup map for both machine and user classifications if they encounter netgroup names in the /etc/hosts.equiv or /.rhosts files.
For detailed information on the format of the /etc/netgroup file, see "netgroup File for NIS" in the AIX Version 4.3 Files Reference.
NIS maps are created by the makedbm command, converting text files into DBM format files. Usually, you will not need to enter this command at the command line because doing so is rather tedious. 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 the maps listed above. If you want, you can add stanzas to the /var/yp/Makefile file to create maps in addition to the default 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 actually 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. That is, 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. Then, the client continues as usual. So, the client only obtains the information it requires when it needs it, and 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, you should 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: