Page 269
192.168.42.1 IN PTR numark 192.168.42.2 IN PTR mtx 192.168.42.3 IN PTR pioneer 192.168.42.4 IN PTR denon 192.168.42.5 IN PTR atus 192.168.42.6 IN PTR technics 192.168.42.7 IN PTR vestax 192.168.42.8 IN PTR rane
Finally, Listing 13.3 contains the local.reverse file.
Listing 13.3. The local.reverse file.
; local.reverse
@ IN SOA domain.com. hostmaster.domain.com. (
1997080600 ; serial number
10800 ; refresh rate (3 hours)
1800 ; retry (30 minutes)
1209600 ; expire (2 weeks)
604800 ) ; minimum (1 week)
IN NS ns1.domain.com
IN NS ns2.domain.com
1 IN PTR localhost.domain.com.
The Network Information Service (NIS) is a simple client/server database system. The protocol itself is generic and can be used for anything. Under Linux, however, the most common uses of it are the sharing of password and group files across the network. This section covers the setup of both master and slave NIS servers as well as the configuration needed to make clients use them.
NIS, developed by Sun Microsystems as part of their SunOS operating system, was originally known as "The Yellow Pages," or YP for short. Unfortunately, the name "Yellow Pages" had already been trademarked and the resulting lawsuit forced the name to be changed to NIS. You will soon see, however, that all of the NIS commands are still prefixed with yp.
The NIS protocol was made public and implementations of it quickly spread to other variations of UNIX. Linux has had support for NIS from its onset. Because Linux follows the NIS standard, it can work with other flavors of UNIX as either the NIS server or client.
Recently, NIS has been updated in the form of NIS+. NIS+ addresses many of the concerns with NIS, most notably in the areas of security. As of this writing, however, Linux support for NIS+ through the NIS libraries has been weak. Server support is not ready, and the client software isn't complete. Because it is still developmental, NIS+ is not covered here.
Page 270
As you configure your network, you will find that some of your configuration files are not host specific, but they require frequent updating. /etc/passwd and /etc/group are two that quickly come to mind. NIS enables you to set up a master server where these files are stored and then configure each machine on your network as clients to this server. Whenever a client needs to fetch an entry from the /etc/passwd file, it consults the NIS server instead.
In order for a file to be sharable via NIS, two prerequisites must be met. First, the file must be tabular with at least one entry that is unique across the entire file. In the /etc/passwd file, this entry is either the login or UID. Second, the file in its raw form must be a straight text file.
With the criteria met, these files are converted into DBM files, a simple database format allowing for quick searches. A separate DBM needs to be created for each key to be searched. In the /etc/passwd file, for instance, you need the database to be searchable by login and by UID. The result is the DBM files passwd.byname and passwd.byuid.
The original text file, along with the DBM files created from it, are maintained at the NIS master server. Clients that connect to the server to obtain information do not cache any returned results.
NIS servers and clients must be in the same NIS domain if they want to communicate with one another. Note that the NIS domain is not the same as a DNS domain, although it is valid for them to share the same name.
| TIP |
You should maintain separate names for your NIS and DNS domains for two reasons: First, it is easier for you to differentiate what you're talking about when discussing problems with anyone else. Second, it makes it just that much more difficult for potential intruders to understand the internal workings of your machines from the outside. |
Both the clients and servers bind themselves to a domain; hence, a client can belong to only one NIS domain at a given time. Once bound, clients send a broadcast to find the NIS server for the given domain.
So far, you might have noticed that I've referenced the NIS server explicitly as the "master" server. This is because there are two kinds of NIS servers: master servers and slave servers.
Master NIS servers are the actual truthholders. They contain the text files used to generate the DBM files, and any changes to the database must be made to these files.
Page 271
Slave NIS servers are designed to supplement master NIS servers by taking some of the load off of them. When a file is updated on the server, a server push is initiated, and the slave NIS server gets an updated copy of the DBM files.
By default, the Red Hat distribution does not come with an NIS server. You can either download it from http://www.redhat.com or use the distribution on the CD-ROM that comes with this book. The filename for the NIS server on the CD-ROM is ypserv-1.1.7-1.i386.rpm.
Before you configure the server software, you need to decide whether you are going to set up any slave servers. If you are, you need to know their hostnames before continuing. Along with the names of your NIS servers, you will need to decide on a domain name at this point. Remember that this domain name is not the same as your DNS domain name and for clarity purposes should be set differently.
With this information at hand, you are ready to begin. First, you need to set the domain name. This is done with the domainname command—for example,
[root@vestax /etc]# domainname audionet.domain.com
Although this will work for the moment, you do need to change a startup configuration file so that this will be done every time your system reboots. The /etc/rc.d/init.d/ypserv.init script that was installed as part of the RPM looks for the domain name to be set in the /etc/sysconfig/network file. Simply add the following line:
NIS_DOMAIN=audionet.domain.com
With the domain name set, you can now decide what files you want to share via NIS as well as their filenames. This is done by editing /var/yp/Makefile. As the name implies, NIS maintains its maps by using the make utility. While familiarity with how this tool works is useful, it isn't mandatory to configure NIS.
Begin by loading /var/yp/Makefile into your favorite editor. Scroll down past the lines that read
# These are files from which the NIS databases are built. You may edit # these to taste in the event that you don't wish to keep your NIS source files # separate from your NIS server's actual configuration files.
Below this segment of text you will see lines that resemble the following:
GROUP = $(YPPWDDIR)/group PASSWD = $(YPPWDDIR)/passwd etc...
This section tells NIS where your database files are located. The $(YPPWDDIR) string is a variable that was set to /etc at the top of the Makefile. Although it is possible to change this to another directory, you will most likely want to keep it there for consistency. The string that comes after $(YPPWDDIR) is the name of the file in /etc that will become shared through NIS.