 | Chapter 9 Configuring Network Servers |  |
| Chapter 9 Configuring Network Servers | |
The Network Information Service (NIS) [9] is an administrative database that provides central control and automatic dissemination of important administrative files. NIS converts several standard UNIX files into databases that can be queried over the network. The databases are called NIS maps. Some maps are created from files that you're familiar with from system administration, such as the password file (/etc/passwd) and the groups file (/etc/group). Others are derived from files related to network administration:
[9] NIS was formerly called the "Yellow Pages," or yp. Although the name has changed, the abbreviation yp is still used.
Creates the NIS maps ethers.byaddr and ethers.byname. The /etc/ethers file is used by RARP (see Chapter 2, Delivering the Data).
Produces the maps hosts.byname and hosts.byaddr (see Chapter 3, Network Services).
Produces the maps networks.byname and networks.byaddr (see Chapter 3).
Creates the two maps protocols.byname and protocols.byaddr (see Chapter 2).
Produces a single map called services.byname (see Chapter 2).
Defines electronic mail aliases and produces the maps mail.aliases and mail.byaddr (see Chapter 10).
Check the maps available on your server with the ypcat -x command. This command produced the same map list on both our Solaris and Linux sample systems. Your server may display a longer list. Here is the list from my Solaris system:
%ypcat -xUse "passwd" for map "passwd.byname" Use "group" for map "group.byname" Use "networks" for map "networks.byaddr" Use "hosts" for map "hosts.byname" Use "protocols" for map "protocols.bynumber" Use "services" for map "services.byname" Use "aliases" for map "mail.aliases" Use "ethers" for map "ethers.byname"
The advantage of using NIS is that these important administrative files can be maintained on a central server, and yet completely accessible to every workstation on the network. All of the maps are stored on a master server that runs the NIS server process ypserv. The maps are queried remotely by client systems. Clients run ypbind to locate the server.
The NIS server and its clients are a NIS domain - a term NIS shares with DNS. The NIS domain is identified by a NIS domain name. The only requirement for the name is that different NIS domains accessible through the same local network must have different names. Although NIS domains and DNS domains are distinct entities, Sun recommends using the DNS domain name as the NIS domain name to simplify administration and reduce confusion.
NIS uses its domain name to create a directory within /var/yp where the NIS maps are stored. For example, the DNS domain of our imaginary network is nuts.com, so we also use this as our NIS domain name. NIS creates a directory named /var/yp/nuts.com and stores the NIS maps in it.
While the NIS protocols and commands were originally defined by Sun Microsystems, the service is now widely implemented. To illustrate this, the majority of examples in this section come from Linux - not from Solaris. The syntax of the commands is very similar from system to system.
The command domainname checks or sets the NIS domain name. The superuser can make nuts.com the NIS domain name by entering:
#domainname nuts.com
The NIS domain name is normally configured at startup by placing the domainname command in one of the startup files. On Linux and Solaris systems, the value for the NIS domain name is taken from the /etc/defaultdomain file. This file is used as input to a domainname command in one of the startup files. As shown below, defaultdomain contains only the name of the NIS domain.
%cat /etc/defaultdomainnuts.com
Initialize the NIS server and build the initial maps with make. The /var/yp/Makefile contains the instructions needed to build the maps. As noted above, it creates a directory using the NIS domain name. The Makefile reads the files in the /etc directory and places maps created from them in the new directory. To initialize a Linux system as a NIS server:
#domainname nuts.com#cd /var/yp#makemake[1]: Entering directory '/var/yp/nuts.com' Updating hosts.byname... Updating hosts.byaddr... Updating networks.byaddr... Updating networks.byname... Updating protocols.bynumber... Updating protocols.byname... Updating rpc.byname... Updating rpc.bynumber... Updating services.byname... Updating passwd.byname... Updating passwd.byuid... Updating group.byname... Updating group.bygid... Updating netid.byname... make[1]: Leaving directory '/var/yp/nuts.com'
After initializing the maps, start the NIS server process ypserv and the NIS binder process ypbind.
#ypserv#ypbind
Our system is now running as both a NIS server and a NIS client. A quick test with ypwhich shows that we are bound to the correct server. ypcat or ypmatch test that we can retrieve data from the server.
#ypwhichlocalhost #ypcat hosts172.16.55.105 cow cow.nuts.com 172.16.55.106 pig pig.nuts.com 172.16.26.36 island.nuts.com island 127.0.0.1 localhost
The clients need only to define the correct domain name and to run the binder software ypbind:
#domainname nuts.com#ypbind
Most NIS clients use ypbind to locate the server. Using the NIS domain name, ypbind broadcasts a request for a server for that domain. The first server that responds is the server to which the client "binds." The theory is that the server that responds quickest is the server with the least workload. Generally this works well. However, it is possible for the client to bind to an inappropriate system, e.g., a system that was accidentally configured to run ypserv or one that was maliciously configured to be a false server. Because of this possibility, some systems allow you to explicitly configure the server to which the client will bind. Linux provides the /etc/yp.conf file for this purpose. The syntax of the entries in different versions of this file varies, so see your system documentation before attempting to use it.
Place the NIS domain name in the /etc/defaultdomain file and the ypserv and ypbind commands in a startup file so that the NIS setup will survive the boot. These commands may already be in your startup file. On our Linux client all we needed to do was uncomment the appropriate lines in /etc/rc.d/rc.inet2. On the Linux NIS server it was a little more complicated. In addition to uncommenting the lines for domainname and ypbind we added lines to start ypserv.
NIS is a possible alternative to DNS but most systems use both NIS and DNS. Hostnames can be converted to IP addresses by DNS, NIS, and the host file. The order in which the various sources are queried is defined in the nsswitch.conf file.
The Name Service Switch file (nsswitch.conf) defines the order in which the sources of information are searched. Despite its name, it applies to more than just name service. All of the databases handled by NIS are covered by the nsswitch.conf file, as shown in this example:
hosts: dns nis files networks: nis [NOTFOUND=return] files services: nis files protocols: nis files
The first entry in the file says that a hostname lookup is first
passed to DNS for resolution; if DNS fails to find a match, the lookup
is then passed to NIS and finally looked up in the hosts file.
The second entry says that network names are looked up through NIS.
The [NOTFOUND=return] string says to use the networks file only if
NIS fails to respond, that is, if NIS is down. In this case, if NIS answers
that it cannot find the requested network name, terminate the search.
The last two entries search for services port and protocol numbers
through NIS and then in the files in the /etc directory.
Before leaving the topic of NIS, we should say a word about NIS+. It is just a short discussion, because I do not use NIS+ and I do not know much about it.
NIS+ replaces NIS on Sun systems. It is not a new version of NIS, but a completely new software product that provides all of the functionality of NIS and some new features. The new features are:
Improved security. NIS does not authenticate servers, as we noted in the ypbind discussion above, or clients. NIS+ provides authentication of users with a secure DES-encrypted authentication scheme. NIS+ also provides various levels of access so that different users have authority to look at different levels of data. NIS can only provide the same access to everyone in the NIS domain.
A hierarchical, decentralized architecture. NIS+, like DNS, is a distributed, hierarchical database system. This allows for a very large namespace. It also allows distributed management of the information structure while maintaining consistent access to the data. NIS is a flat structure. All information about a NIS domain comes from a single master server and NIS domains are not interrelated.
Enhanced data structures. NIS converts ASCII files into simple keyed files that the NIS+ documentation calls "two-column maps." NIS+ builds multicolumn database tables. Tables can be searched in a variety of ways to retrieve information about an entry. In addition, NIS+ tables can be linked together to provide related information about an entry.
Clearly NIS+ has some excellent new features and advantages over NIS. So why don't I use it? Good question! The hierarchical architecture and enhanced data structures are important if you have a very large network and lots of data in your namespace. However, many sites evolved using NIS on local subnets and do not see the need to move the entire enterprise under NIS+. Improved security seems like a real winner, but sites with low security requirements don't see the need for additional security and sites with high security requirements may already be behind a firewall that blocks external NIS queries. Additionally, NIS+ is not available for as many operating systems as NIS. Taken together, these reasons have slowed the move to NIS+.
To learn more about NIS+ and how to install it on your system, read the NIS+ Transition Guide, the Name Service Configuration Guide, and the Name Service Administration Guide. All of these are available from Sun as part of the Solaris System and Network Administration manual set.
NIS and NIS+ provide a wide range of system configuration information to their clients. However, they cannot provide all of the information needed to configure a TCP/IP system. In the next two sections, we look at configuration servers that can do the entire job.
|  | |
| 9.2 Line Printer Daemon |  | 9.4 A BOOTP Server |