Page 275
The first column indicates the file in question. In the first line, this is passwd. The next column indicates the source for the file. This can be one of six options:
| Option | Description |
| nis | Uses NIS to determine this information. |
| yp | Uses NIS to determine this information (alias for nis). |
| dns | Uses DNS to determine this information (applicable only to hosts). |
| files | Uses the file on the local machine to determine this information (for example, /etc/passwd). |
| [NOTFOUND=return] | Stops searching if the information has not been found yet. |
| nis+ | Uses NIS+. (You won't use this because of the incomplete support for NIS+ under Linux.) |
The order these are placed in the /etc/nsswitch.conf file determines the search order used by the system. For example, in the hosts line, the order of the entries are files nis dns, indicating that hostnames are first searched for in the /etc/hosts file, then via NIS in the map hosts.byname, and finally by DNS via the DNS server specified in /etc/resolv.conf.
In almost all instances, you want to search the local file before searching through NIS or DNS. This allows a machine to have local characteristics (such as a special user listed in /etc/passwd) while still using the network services being offered. The notable exception to this is the netgroup file that by its very nature should come from NIS.
Modify the order of your searches to suit your site's needs and save the configuration file.
| NOTE |
If you are familiar with NIS from an older version of Linux or another UNIX altogether, you might be wondering why I haven't mentioned the ypbind daemon. |
Because of the way NIS works under Red Hat, you do not need to reboot in order to start NIS client functions. By simply running
domainname `cat /etc/domainname'
you can establish a connection to the NIS server and test your client software without having to reboot.
Page 276
As a precautionary measure, you should schedule a reboot while you are with the machine to ensure that it does come up and configure the NIS information correctly. After all, your users will not be very happy if after a power failure, your machine does not come back up correctly without assistance.
With the NIS client and server configured, you are ready to test your work. Try the following:
ypcat passwd
If your configuration is working, you should see the contents of your NIS server's /etc/passwd.yp file displayed on your screen. (Assuming, of course, that you chose that file to be shared via NIS for your passwd file.) If you received a message such as
No such map passwd.byname. Reason: can't bind to a server which serves domain
you need to go back and double-check that your files have been properly configured.
| TIP |
A difference between the NIS that comes with Red Hat and other UNIXes' NIS packages is that Red Hat does not need the /etc/passwd file to have the string +:*:0:0::: appended to it. You might, however, want to add that anyway because the finger daemon, fingerd, does need that line in order to check NIS maps for user information. |
After you've decided to configure a machine to be an NIS secondary server, you need to start by configuring it as an NIS client machine. Verify that you can access the server maps via the ypcat command.
Begin configuring the secondary server by installing the ypserv RPM from either http://www.redhat.com or from the CD-ROM (filename ypserv-1.1.7-1.i386.rpm).
When you have the ypserv program installed, go ahead and start it up by running /etc/rc.d/init.d/ypserv.init start. It isn't doing anything useful yet, but you will need to have it running shortly.
Next, either download ypbind-3.0-1.src.rpm from http://www.redhat.com or copy it from the CD-ROM. After it's installed, you will need to compile it as follows:
Page 277
If you remember the details on NIS clients, you might remember not needing ypbind because it is built into the resolver library under Red Hat Linux. However, the ypinit program that you'll be using soon requires it in order to communicate with the master server. ypbind will not become part of the startup sequence.
Now you are ready to tell the master server that a slave server exists. To do this, edit the /var/yp/ypservers file so that the slave server you are setting up is included in the list. If you configured your master server with the name of the slave server during the ypinit -m phase, you do not need to do this.
Although ypbind will not be part of startup, you do need to make a small change in the startup sequence in order to set the NIS domain name. This is done by editing the /etc/sysconfig/network file and adding the line NIS_DOMAIN=nisdomain.com where nisdomain.com is your NIS domain name. In the sample network, this would be audionet.domain.com.
In order to set the domain name without having to reboot for the purpose of installing the NIS slave server, set the NIS domain name explicitly by using the domainname command, such as
domainname nisdomain.com
where nisdomain.com is the NIS domain name of your choice.
You can now initialize the slave server by running the command
/usr/lib/yp/ypinit -s master
where master is the hostname for the NIS master server. In this example, it's vestax. The output of this should look something like the following:
We will need some minutes to copy the databases from vestax. Transferring mail.aliases... Trying ypxfrd ... not running Transferring services.byname... Trying ypxfrd ... not running Transferring rpc.bynumber... Trying ypxfrd ... not running [etc...]