Managing NFS and NIS, 2nd Edition - Mike Eisler [27]
Starting the ypserv daemon, which enables the system to act as an NIS server.
Adding new slave servers when growth of your network or NIS performance requires more server bandwidth.
Enabling NIS on a client requires two tasks:
Modifying the client's administrative files so that the client can take advantage of NIS.
Starting the ypbind daemon, which allows the client to make NIS requests.
In this section, we'll review the procedures required to initialize NIS, set up slave servers, and configure NIS clients.
Choosing NIS servers
First, a few words on how to plan your network. One of the most important decisions you will make is which systems will be your NIS servers. Because a client gets almost all of its configuration information from NIS, servers must be highly available in measures of both uptime and request handling bandwidth. If an NIS server stops responding or replies too slowly, the client tries to find another, less-loaded server. While this is an argument for at least one slave server for each master server, it supports an equally strong case for building NIS on reliable hosts. An interruption in NIS service affects all NIS clients if no other servers are available. Even if another server is available, clients will suffer periodic slowdowns as they recognize the current server is down and hunt for a new one.
Use your judgement in defining "highly available." You know what machines have troublesome hardware or are likely to be commandeered for a trade show, and would therefore make poor NIS servers. Request handling bandwidth is much harder to measure, because it is a product of network loading, CPU utilization, and disk activity. In later chapters, we'll come back to choosing the number of NIS servers and identifying signs that you have too few servers.
A second imperative for NIS servers is synchronization. Clients may get their NIS information from any server, so all servers must have copies of every map file to ensure proper NIS operation. Furthermore, the data in each map on the slave servers must agree with that on the master server, so that NIS clients cannot get out-of-date or stale data. NIS contains several mechanisms for making changes to map files and distributing these changes to all NIS servers on a regular basis.
Installing the NIS master server
We'll assume that you've already done your planning and decided that you need a single NIS domain, which will be called bedrock.[2] Before going any further, make sure you've set the NIS domain name on the master server using domainname. We'll install a server for an NIS domain named bedrock:
newmaster# domainname bedrock
A line like this will usually appear in the /etc/rc2.d/S69inet file for every host (server and client) in the domain. Setting the domain name if you aren't using NIS is harmless. Reminder: you are setting the NIS domain name here, not the DNS domain. See Section 3.3.8.1 later in this chapter.
Note that on Solaris, the domain name setting will not survive a server reboot unless it is stored in the /etc/defaultdomain file. So, you need to do:
newmaster# domainname > /etc/defaultdomain
After establishing the domain's name, you should go over all the system's administrative files with a fine-toothed comb: make sure they contain only the entries you want, no more, and no less. It is important for your network to start with correct map information. Which administrative files NIS cares about varies, but generally includes the information shown in Table 3-1.
Table 3-1. Files managed by NIS
File
Contains
/etc/auto_*
Automounter maps
/etc/bootparams
Information about diskless nodes
/etc/ethers
Ethernet numbers (MAC addresses)
/etc/group
User groups
/etc/hosts
Hostnames and IP addresses
/etc/inet/ipnodes
Hostnames, IPv4, and IPv6 addresses
/etc/mail/aliases
Aliases and mailing lists for the mail system
/etc/netgroup
Netgroup definitions (used by NIS)
/etc/netid
Netname database for RPC/dh (RPC/dh is discussed in Section 12.5.4)
/etc/netmasks
Network "masks"
/etc/networks
Network