One of the chief benefits of work group computing is the ability to use the facilities and information throughout the work group network, rather than relying only on facilities and information on an individual machine. In order to make the resources of the work group available, the first step is to identify those resources, and provide a way to find them simply and easily. The optional Network Information System (NIS) provides that service.
Setting up and administering NIS is an administrative responsibility. In a work group environment, NIS is relatively transparent to users, as it simply provides services they can use as a matter of course.
NIS is a network lookup service that provides a centralized database of information about the network to systems participating in the service. The NIS database is fully replicated on selected systems and can be queried by participating systems on an as-needed basis. Maintenance of the database is performed on a central system.
The purpose of NIS is to make network administration more efficient by reducing the risk of error and the time required to perform redundant file management tasks. For example, maintaining the /etc/hosts database on a large network might require creating a script to automatically copy the /etc/hosts file from a central system to all systems on the network. It also requires setting up the appropriate access permissions on each system to enable this file transfer; this is a redundant and time-consuming process. By contrast, on networks using NIS, maintaining the /etc/hosts database requires modifying a single file, typically /etc/hosts, on a single system.
NIS can service networks with up to approximately 1000 systems. Larger networks can be organized into multiple NIS service areas, or domains.
An NIS client is a process running on a system that requests data from an NIS database. An NIS server is a process running on a system that provides data from the NIS database. The terms client and server designate both processes and systems: a system is considered a client when requesting NIS data, and it is considered a server when providing NIS data. A system can function as a client and a server simultaneously.
Sometimes client requests are handled by NIS servers running on the same system, and sometimes they are serviced by NIS servers running on a different system. If one NIS server system fails, client processes obtain NIS services from another. In this way, the NIS service remains available even when an NIS server system goes down.
Every NIS server contains a copy of the NIS database. There are two types of servers:
A master server is a server on which the NIS databases are created and maintained
A slave server contains a duplicate copy of the database.
In most work group environments, a single NIS server is sufficient. However, if slave servers are needed, automatic propagation ensures the consistency of database information between the master server and its slave servers.
The NIS database is made up of a group of files known as maps. Maps are created with NIS tools that convert input files (usually standard ASCII files) to files in database record (dbm) format. Since data in dbm format is faster to find than ASCII data, using dbm files increases NIS performance.
Maps are composed of keys and values. A key is a particular field in the map that the client must specify whenever it queries the map. Values are attributes of the key returned from the query. For example, a key might be the name of an individual system, and a value might be its Internet address.
An NIS domain is a collection of systems using the same NIS database. To participate in the NIS service, a system must belong to an NIS domain.
Figure 4-1 shows the basic layout for the systems in Building 1 and a domain called eng.
The domain eng consists of the master server, one slave server, and three clients. One system on the network does not participate in NIS at this time but may be included in the domain at a later date.
NIS domains can be organized to coincide with Internet domain names. In the Internet naming hierarchy, a domain name is comprised of a stream of names separated by dots. For example, if eng.widgets.com is an Internet domain, it could also be used as the name of the NIS domain.
Some administrators name their NIS domains with simple names and the Internet domain names separated with dots. For example, the NIS domain name might be eng, and the Internet domain name might be eng.widgets.com. Using this naming scheme, the two domains can be easily distinguished. Other administrators prefer to have the NIS and Internet domain names coincide. This is strictly a matter of choice; there is no explicit relationship between NIS and Internet domains. However, to avoid confusion, choosing one of these two naming schemes is recommended. (See the IRIX Admin: Networking and Mail for details on Internet domains.)
Setting up NIS involves setting up the NIS master server and setting up the clients. An NIS server does not need to be a dedicated system; any system on the network can function as an NIS server.
After choosing the system you want to use as the NIS master server for your work group, you must follow four overall steps to set up the NIS master server. For more information about setting up the NIS master server, see the NIS Administration Guide.
Set the master server's domain name.
Choose a domain name based on your site's configuration. It is possible, but not necessary, for the domain name to coincide with the system's Internet domain name, if any.
Build the master maps.
Building the master maps is mostly automatic. You start the process by issuing the appropriate commands to the NIS master server. The server software then proceeds to build maps of names, addresses, and other information.
Start NIS on the master server.
You can start NIS on the master server by rebooting the system, restarting the network, or manually starting the NIS software. As soon as NIS is started on the master server, it is available to clients.
Test the NIS master server.
The simplest way to check to make sure the NIS master server is functioning properly is to use its services from the same system (which is also an NIS client). One way to check is the command ypwhich from a shell window. If the NIS master server is functioning, it should return its own name:
# ypwhich localhost
There are four parts to the procedure for setting up the NIS client. You must repeat these steps for each NIS client you need to set up. You may choose to distribute instructions to work group members and request that they follow the NIS client setup procedure. For more information about NIS client setup, see the NIS Administration Guide.
Set the domain.
Setting the domain on an NIS client is the same as setting the domain for the NIS master server.
Configure NIS on the client.
In most cases, NIS should be set up to start automatically when the client system starts up.
Start NIS on the client.
Starting NIS on a client system is the same as starting NIS on the master server. To start NIS you can reboot the client, restart the network, or start the NIS client software manually. Typically, this is done by the following command:
# /usr/etc/ypbind
Test the NIS client.
To test an NIS client, you typically issue the ypwhich command from a shell window. If the client is functioning correctly, the name of the master server for that client should be returned.
Administering NIS on your work group network primarily consists of keeping the information in the NIS databases current. This involves these primary tasks, which are covered in more detail in the NIS Administration Guide:
Add new users who join the work group to the NIS database.
Make sure new users' systems are properly set up to use NIS.
Maintain NIS passwords for user accounts.
Create and propagate nonstandard maps, if desired.
NIS maps contain standard types of information. It is possible to store different types of information in NIS. You do this by creating an ASCII file (for example with a text editor) containing the information you want, then creating an NIS map for the file.
To propagate a map you created, you set up a file for the new map in the domain directory of each NIS server on your network. If you use only an NIS master server with no slave servers, you need only store your new map in the domain directory of your NIS master server.
If you experience problems with NIS in your work group, check the following:
Are all NIS clients and servers properly connected to the network?
Do the clients and servers have the same domain name?
The domain names must match exactly. For example, the domain widget.com is not the same as the domain WIDGET.com.
Are your NIS servers overloaded?
When an NIS server is overloaded, the client automatically tries to switch to a more lightly-loaded server. If one is not available, you may need to add additional NIS servers to your network.
Are your NIS servers running properly?
This will be more of an issue when, in a small work group, you have a single NIS server. In an environment with multiple NIS servers, clients automatically switch to different servers.
If you cannot isolate a problem after making these checks, or if you need additional information about these items, see the NIS Administration Guide.