Upgrading and Repairing Networks (5th Edition)

One of the main problems inherent in storing logon information on each computer on a network is managing user accounts on multiple machines. Every time a change is made for a user, the change must be propagated to other computers on the network that the user logs in to. Instead of visiting each Unix box to make changes to the appropriate files, you can use Network Information Service (NIS). This application was developed by Sun Microsystems and was originally called Yellow Pages (or YP for short). You still might see references to Yellow Pages in older documentation. However, due to trademark infringement, the application is now known as NIS.

Master and Slave NIS Servers

NIS stores important information for servers on a network in a central database. When important information is stored in a central location, management of the data becomes much easier. The network administrator can make the necessary changes to the maps on an NIS master server and let NIS take care of informing the affected slave servers on the network about the change. The NIS master server also works to authenticate users against its database. However, to provide a backup, slave servers on the network also keep copies of the same files maintained by the NIS master server. This redundancy enables users to keep working if an NIS master server is offline for a short period. The master/slave method also can be used to provide for load balancing so that the master NIS server does not become overloaded on a large network.

The kind of data that NIS can manage for Unix servers includes the standard /etc/password and /etc/group files. It also includes other important files containing data about remote file systems, other hosts on the network, and so on.

NIS Maps

When you initially set up NIS, important system files are converted into databases that are referred to as NIS maps. In addition to the typical files that we've talked about in this chapter so far, the following files also are candidates for NIS management:

• /etc/ethers This file results in two NIS maps: ethers.byaddr and ethers.byname. The Reverse Address Resolution (RARP) uses this information when resolving Ethernet hardware (MAC) addresses to IP addresses. Typically, this is used by diskless workstations that need to discover their assigned IP address (which might not be stored locally) during the boot sequence.

  Note

  The concept of a master and slave in the NIS structure does not apply to a server as a whole. For example, one NIS server might be the master server for a particular map or set of maps, while it is also the slave server for other maps controlled by other master servers. The terms master and slave relate to whether the NIS server holds the master map (where changes are made and then propagated to slave servers) or whether the server holds a duplicate copy that is regularly updated by the master map's server. Each map contains information that tells it what its master server host is.

  Note that, unless you have good reasons to distribute master copies among different servers, the whole point in using NIS is to centralize information updates. In general, it's a good idea to use one master server in a typical domain and several slave servers (if needed) to help provide for load balancing and redundancy.

• /etc/networks This file also results in the creation of two NIS maps: networks.byname and networks.byaddr. You probably can guess that these maps store information used to associate network names with IP network addresses.

• /etc/services Only one NIS map is created from this file. It contains a list of network services and the TCP and UDP ports associated with these service port numbers.

• /etc/protocols Two NIS maps result from this file. The first is called protocols.byname and the second is called protocols.byaddr. These maps work similarly to the services maps, in that they act to cross-reference protocol numbers with the names of the protocols.

• /etc/netmasks The NIS map created by this file is called netmasks.byaddr, and it is used to store the subnet masks for the network.

• /etc/hosts This field also results in two NIS maps, hosts.byname and hosts.byaddr. The standard hosts file used in TCP/IP is almost an antique today but still has a few uses. These maps can be used to translate hostnames to IP addresses for computers. The Domain Name System (DNS) servers typically perform this function on most networks today.

• /etc/aliases This file also results in two NIS maps. They are mail.aliases and mail.byaddr. These maps are used to define alias email addresses.

The ypserve daemon runs on a central server and manages the NIS maps created from the standard systems files. The ypbind daemon runs on workstations and is responsible for interacting with the ypserve daemon to satisfy user requests and information interchange.

Note

NIS works in a fashion similar to DNS. Both provide information to clients from a database that stores all kinds of network information. To help you distinguish the difference between NIS and DNS, think of NIS as a local client/server mechanism that helps keep information sorted on and made available to local clients. DNS is part of a global, hierarchical system for managing IP addresses, domain names, services, and other data used for wide area communications, as well as functioning perfectly well on a local area network to satisfy requests for the data it manages. Note that DNS and NIS do not keep identical information. For example, DNS does not store usernames and passwords. This is a local function of the LAN.

Also note that NIS uses the concept of domains, like DNS. However, although it is typical to create domains that use the same name and cover the same network territory, this does not necessarily have to be the case. So when thinking about NIS domain names, don't confuse them with DNS domain names. They might be the same for the affected portion of the network, but the administrator can choose to use different names for the different domains. For more information about DNS, see Chapter 29, "Network Name Resolution."

In addition to these files, other files that can be used on most NIS implementations include the following:

• Shadow password files As discussed earlier in this chapter, a user authorization file that is not world-readable like the /etc/passwd file. Instead, only root can manage this file.

• bootparams Specific parameters for booting computers on the network.

• netgroup Used to define networkwide groups (as opposed to the /etc/group groups). This makes managing groups of users on the network a simpler task.

The NIS Server ypserve Daemon and Maps Location

On the NIS server, the NIS maps can be found in a subdirectory that falls under the /var/yp directory. Names for the subdirectories are created by using the NIS domain name you have chosen. To use the old venerable acme.com name, the resulting file path for this domain would be /var/yp/acme.com.

The ypserve daemon is the background server process that is responsible for finding the information in its maps to satisfy client requests. When NIS is set up, you must have at least one master server that runs this daemon in order for NIS to function on the network.

Setting the NIS Domain Name Using the Command domainname

After you've decided on a name to use for the NIS domain, you'll need to issue the domainname command to set that name on the Unix system.

To set the NIS default domain name, use the following command:

# domainname acme.com

You also can place a similar command (substituting your NIS domain name in the example for acme.com, of course), in a startup file to automate the process during system boot.

You also can enter the command domainname from the command line, without any command-line parameters. This syntax of the command displays the current NIS domain name so that you can check it for accuracy when making changes or performing troubleshooting efforts.

Starting NIS: ypinit, ypserve, and ypxfrd

Installing NIS on Unix and Linux platforms is not the same for all platforms. See the usual README.TXT and installation and release notes files for your platform to install the necessary files that are used to configure NIS on the server or client system.

The ypinit command creates the /var/yp/domainname directory (where domainname is the name you've chosen for your NIS domain) and reads the files in the /etc directory and creates the NIS maps. The NIS maps are then saved in the domainname subdirectory. When the ypinit program is finished, you can use the command ypserv to start the NIS server. When the server is up and running, you'll need to start the map transfer daemon if you have configured other NIS servers in the network. Type ypxfrd at the command line. You also could add the command to the /etc/rc.local file to have it start automatically at startup.

After you've finished the initial installation, use the following commands to configure and set up NIS:

• ypinit This command is used to create the map directory and subdirectories (that is, /var/yp/acme.com) on the server. This command also runs through the various /etc files and creates the maps needed for the domain. This command also can be used to set up the /var/ypbinding/domainname/ypservers file on client computers, where domainname is the name of the NIS domain.

• ypserv After you've used ypinit to create the necessary NIS databases, use the ypserv command to start the server on the NIS server. The format for this command is ypserv -m. You can enter this at the command line or put it into a startup file if you want the server daemon to start each time the system is booted.

Note

By default, the domain name and hostname used by NIS are taken from the files /etc/nodename and /etc/defaultdomain. During the system boot process, these files are consulted and used with the appropriate NIS commands (that is, the domainname command).

To use ypinit, you should be logged in as root. Next, make edits to the /etc/hosts file and be sure that it contains all the IP addresses of each NIS server. Start the process of building the maps by using the following command:

/user/sbin/ypinit m

The command (actually a script file) prompts you for the names of other host computers that you want to make into NIS servers. Be sure to include the server you are working on as well as the names of other NIS server candidates you've created. Next, you'll be asked whether you want to terminate the operation if a nonfatal error occurs. Generally, you should enter yes to this prompt so that you can fix any problems that crop up. After fixing any problem, you can reinvoke ypinit to start over again.

Next, ypinit asks whether you want to delete any currently existing files that are in the /var/yp/domainname directories. If you are reinstalling NIS, you are prompted to delete the files created by the previous installation.

After this, ypinit uses make to process instructions contained in the makefile. The script file uses makedbm to create the maps and places the name of the master server for each map in a location in the map so that it will know its master server.

The Default Makefile Used by ypinit

When the ypinit command is invoked to begin configuring your server, it calls the make(1) command to process information in a makefile that is usually located in the /var/yp directory. You can make modifications to this file if required for your environment. The makefile is used to convert the input files discussed earlier into the ndbm(3) format, which is beyond the scope of this discussion. The makefile then creates the appropriate maps that NIS uses.

NIS Slaves

NIS slaves hold exact duplicates of NIS maps as the master server. The slave also runs the same ypserv daemon. The only difference between the two servers is that only the slave answers client requests; the slave doesn't make any changes to the NIS maps. Only the master server can update the NIS maps. When the master server makes a change to the maps, it then propagates the changes to all the slave servers in the NIS domain.

Setting Up Slaves

Creating a slave server is similar to creating the master server. First, set the NIS domain name by typing domainname at the command line. After setting the NIS domain name, start the ypbind server process by entering this:

ypbind

And then enter the following on the slave server-to-be:

ypinit -s NISmaster

The -s option specifies that you are setting up a slave server, followed by the NIS domain master server name. After the slave server is initialized, the master server transfers all the NIS domain information to the slave. During the setup of the slave server, it does not look at its local /etc files to create the NIS maps. The slave server has only the information that is stored in the maps on the master server.

Deciding when to create a slave server should be done during the initial planning phase of setting up the NIS network. Although growing networks don't exactly grow according to plan, it is possible to add slave servers later. If you add a slave server after the initial setup of the master server, you'll need to add the new slave's hostname to the ypservers map file.

Starting and Stopping the NIS Service on Slave Servers

Starting and stopping all YP processes is a simple task. These commands may be used online to start or stop the services. The following line will cause the YP processes to all stop running:

/etc/init.d/yp stop

To start all YP processes, use the following command:

/etc init.d/yp start

Now it can't be simpler than that, after all you've gone through to get this system up and running!

Changing NIS Maps

You can make changes to the normal system files (that is, /etc/passwd) on the NIS master server. After you make these kinds of changes, set your default directory to be /var/yp, and then execute the command make mapname, where mapname is the name of the map being modified.

To update the system after making changes to the makefile, you'll need to stop the YP processes, make the changes, and restart NIS. You can make changes to the makefile to add or remove maps. Use the same start/stop commands described in the preceding section for this purpose.

Pushing Modifications to NIS Slave Servers

After you've made modifications on the master NIS server, the changes must be sent to all other slave servers so that the databases can be kept in sync. The makefile utility uses the yppush command to send these map changes to the affected servers. The process is accomplished by sending a message to the ypserve daemon. The ypserve daemon that resides on the slave server then starts up another process using the ypxfr utility. This utility establishes communication with the ypsfrd daemon that runs on the master NIS server to see whether any changes need to be made. If so, the yppush program sends the map changes. If they are successfully applied to the slave server, it returns a successful status message to yppush.

Note that yppush sends only maps that have changed and that already exist on the slave servers. If you create new maps on the master NIS server that don't yet exist on the slave NIS servers, use the command ypxfr by itself on the command line to do this. For troubleshooting purposes you can check the results of the command by viewing the log file named /var/yp/ypxfr.log.

Other Useful NIS YP Commands

Although the documentation for your system contains a lot of other tasks you can perform using NIS, this chapter has only touched on the basics. However, a few other useful commands that you'll find in most implementations of NIS include the following:

• ypcat mapfilename This command lists the values stored in a map file. If you want to list the keys for the map file values, use the option -k in this syntax directly after the ypcat command.

• ypwhich m This command lists all the available maps on the server and their masters. If you want to list only the master server for a particular map, include the map name following the -m option.

NIS Clients

Starting the NIS client is simple. First, set the NIS domain on the local machine using the domainname command, and then start the ypbind service by entering ypbind at the command line. To have ypbind start every time the machine boots, ensure that the ypbind script exists in the /etc/rc.local file and that it is not commented out.

The following is a sample boot script to launch ypbind in the correct NIS domain:

domainname acme.com . . . if [ -d /var/yp ] ; then ypbind; echo -n ' ypbind' fi