 |  |
9.4. Network Information Service
The Network Information Service (NIS)[105] 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:
[105]NIS was formerly called the "Yellow Pages," or yp. Although the name has changed, the abbreviation yp is still used.
- /etc/ethers
-
Creates the NIS maps ethers.byaddr and ethers.byname. The /etc/ethers file is used by RARP (see Chapter 2, "Delivering the Data").
- /etc/hosts
-
Creates the maps hosts.byname and hosts.byaddr (see Chapter 3, "Network Services").
- /etc/networks
-
Creates the maps networks.byname and networks.byaddr (see Chapter 3, "Network Services").
- /etc/protocols
-
Creates the maps protocols.byname and protocols.byaddr (see Chapter 2, "Delivering the Data").
- /etc/services
-
Creates a single map called services.byname (see Chapter 2, "Delivering the Data").
- /etc/aliases
-
Defines electronic mail aliases and creates the maps mail.aliases and mail.byaddr (see Chapter 10, "sendmail ").
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 a Linux system:
% ypcat -x Use "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"
NIS allows these important administrative files to be maintained on a central server yet remain 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 wrotethebook.com, so we also use this as our NIS domain name. NIS creates a directory named /var/yp/wrotethebook.com and stores the NIS maps in it.
While the NIS protocols and commands were originally defined by Sun icrosystems, 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 wrotethebook.com the NIS domain name by entering:
# domainname wrotethebook.com
The NIS domain name is normally configured at startup by placing the domainname command in one of the startup files. On many systems, the NIS domain name that is used as input to a domainname command is placed in a second file. For example, on Solaris systems, the value for the NIS domain name is taken from the /etc/defaultdomain file. As shown here, defaultdomain contains only the name of the NIS domain:
% cat /etc/defaultdomain wrotethebook.com
On Red Hat Linux systems, the NIS domain name is just one of the values in the /etc/sysconfig/network file:
$ cat /etc/sysconfig/network NETWORKING=yes HOSTNAME=jerboas.wrotethebook.com NISDOMAIN=wrotethebook.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 wrotethebook.com # cd /var/yp # make make[1]: Entering directory '/var/yp/wrotethebook.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/wrotethebook.com'
After initializing the maps, start the NIS server process ypserv and the NIS binder process ypbind:[106]
[106]If, during the initial build of the NIS maps, make complains that ypserv is not registered, run ypserv before running make.
# 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. Use ypcat or ypmatch to test that you can retrieve data from the server. We use ypcat in the following example:
# ypwhich localhost # ypcat hosts 172.16.55.105 cow cow.wrotethebook.com 172.16.55.106 pig pig.wrotethebook.com 172.16.26.36 island.wrotethebook.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 wrotethebook.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 binds. 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 appropriate startup file so that the NIS setup survives the boot. The ypbind and ypserv commands are probably already in a startup file. On a Red Hat Linux NIS system, ypbind and ypserv have their own scripts in the /etc/init.d directory. In addition to putting a value for NISDOMAIN in /etc/sysconfig/network, use the chkconfig command to make sure the ypbind and the ypserv scripts run at boot time.
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.
9.4.1. 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.
9.4.2. NIS+
Before leaving the topic of NIS, I should say a word about NIS+. It will be a short discussion, because I do not use NIS+ and 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 the functionality of NIS and some new features. The new features are:
-
Improved security. NIS does not authenticate servers (as noted in the ypbind discussion) 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. And finally, other directory services, such as LDAP, that provide similar services and are more widely available have overtaken 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 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.3. Using Samba to Share Resources with Windows |  | 9.5. DHCP |
Copyright © 2002 O'Reilly & Associates. All rights reserved.