This chapter presents information to consider before you set up the NIS service on your network. It explains how to set up multiple NIS domains (if you decide they are needed) and identifies the files that should be up-to-date before NIS setup begins. It suggests how to name a domain and how to select master and slave servers. Finally, this chapter provides general recommendations to help you make planning decisions.
This chapter contains these main sections:
Before you set up NIS, determine the number of domains you need. Establishing more than one domain is advisable if your network is very complex or requires a very large database. You might also consider using multiple domains if your network contains a large number of systems (say, in excess of 1000 systems).
If you decide to establish multiple domains and require interdomain communication, your planning involves additional network considerations. Those considerations are addressed in the remainder of this section.
 | Note: If you plan to establish a single domain or multiple isolated domains, you can skip ahead to “Verifying ASCII File Contents” to proceed with your planning. |
NIS is not hierarchical in nature; it cannot resolve issues that extend beyond domain boundaries. For example, suppose you set up two domains as shown in Figure 3-1: shapes, which includes system client1; and colors, which includes system client2. Without NIS, communication between client1 and client2 relies on entries in their local /etc/hosts file that provide a host name-to-address mapping.
With NIS, host name and address information is in the hosts database on the NIS servers for a domain. However, this name and address information is limited to domain members. The colors database has no entry for client1 in the shapes domain, and the shapes database has no entry for client2 in the colors domain. Consequently, when client1 tries to contact client2, host name resolution fails and a connection cannot be established. Although there may be a physical connection between client1 and client2, there is no logical connection to support the communication process.
When multiple NIS domains are used, you must form a logical bridge between domains to allow systems in different domains to communicate as shown in Figure 3-2. The logical bridge must contain or be able to access system information for all systems on a given network, regardless of domain. There are two ways to achieve this logical bridge: using the Domain Name System (DNS) or using a customized update procedure.
DNS, sometimes referred to as BIND (Berkeley Internet Name Daemon) or named, is a service that maps host names to IP addresses and vice-versa. DNS is concerned mainly with host name-address and address-host name resolution. It was developed to support very large scale environments and provides an accurate network depiction; it is hierarchical in nature. When correctly set up, DNS resolves host names and addresses throughout an entire network. For NIS to use DNS, DNS must be set up to know about all systems. The IRIX Admin: Networking and Mail book provides detailed information on setting up DNS.
By default, host name resolution is done by first checking NIS. If NIS is not running, then DNS is checked. If DNS is not running, then the local /etc/hosts file is checked. To redefine the host resolution order, change the /etc/nsswitch.conf file as described in the next section.
The lookup order for resolving a system's identity can be configured in a variety of ways using /etc/nsswitch.conf. For example, a network application could resolve host name lookup by accessing files or databases in this order: NIS, DNS, and finally the local file. It can be configured to check only the first service running, or to check services until a match is found. Whatever order is specified, it becomes the default lookup order used by routines in the standard C library, such as gethostbyname(3N), for resolving host names.
If you want applications to resolve host names via the DNS database only, put this line in the /etc/nsswitch.conf file:
hosts: dns |
If applications are to search only DNS and /etc/hosts, put this line in the /etc/nsswitch.conf file:
hosts: dns files |
To specify that NIS should be checked first, then if no match is found check DNS, and if no match is found, check /etc/hosts and put this line in the /etc/nsswitch.conf file:
hosts: nis dns files |
See the nsswitch.conf(1) man page for more detailed information.
An alternative to using DNS is to establish a procedure for updating the hosts file on all master servers. For example, designate one system at your site to be the repository for new system addresses and limit administration of this system to a few select people. Set up a script and crontab entry on the designated system to copy its /etc/hosts file to the NIS master servers on each domain at regular intervals. When each NIS master server performs a ypmake, the host database is updated with the names and addresses for all systems on the network, regardless of the domain. This scheme distributes an updated list of all network systems to NIS servers, allowing clients in different domains to communicate successfully.
While DNS is mainly for host name resolution, NIS supports multiple database maps in addition to the hosts map. This method of setting up your own customized update procedure is also useful if you need the same information for other maps distributed between domains (for example, /etc/aliases).
NIS databases are built on the NIS master server from a set of ASCII files the master server contains. A key preparation step is to ensure that the information contained in the ASCII files is correct and up-to-date.
Table 3-1 lists the maps that make up the NIS database, the input files that create these maps, and the purpose of each map in the NIS environment.
Table 3-1. Maps, ASCII Files, and Descriptions
Map Name | ASCII File | Description |
|---|---|---|
bootparams | /etc/bootparams | Contains pathnames of files diskless clients need during booting: root, swap, share, possibly others. |
capability.byname | /etc/capability | Contains information about the capability each user may have when logging onto the system. |
clearance.byname | /etc/clearance | Contains mandatory access control labels to allow user access to the system. |
ethers.byaddr | /etc/ethers | Contains host names and Ethernet addresses. The Ethernet address is the key in the map. |
ethers.byname | /etc/ethers | Same as ethers.byaddr, except the key is the host name instead of Ethernet address. |
group.bygid | /etc/group | Contains group security information with the group ID as key. |
group.byname | /etc/group | Contains group security information with the group name as key. |
group.bymember | /etc/group | Contains all groups of which a login is a member. |
hosts.byaddr | /etc/hosts | Contains host names and IP addresses, with the IP address as key. |
hosts.byname | /etc/hosts | Contains host names and IP addresses, with the host name as key. |
mac.byname | /etc/mac | Contains mandatory access control information, with the name as key. |
mac.byvalue | /etc/mac | Same as mac.byname, except that the key is numeric value. |
mail.aliases | /etc/aliases | Contains aliases and mail addresses, with aliases as key. |
mail.byaddr | /etc/aliases | Contains mail addresses and aliases, with the mail address as key. |
netgroup.byhost | /etc/netgroup | Contains group names, user names, and host names, with the host name as key. |
netgroup.byuser | /etc/netgroup | Same as netgroup.byhost, except that the key is the user name. |
netgroup | /etc/netgroup | Same as netgroup.byhost, except that the key is the group name. |
netid.byname | /etc/group, /etc/hosts, /etc/netid | Contains user, group, and host information, with the user name as the key. |
networks.byaddr | /etc/networks | Contains names of networks known to your system and their IP addresses, with the address as the key. |
networks.byname | /etc/networks | Same as networks.byaddr, except the key is the name of network. |
passwd.byname | /etc/passwd | Contains password information with the user name as the key. |
passwd.byuid | /etc/passwd | Same as passwd.byname, except that the key is the user ID. |
protocols.byname | /etc/protocols | Contains network protocols known to your network, with the protocol name as the key. |
protocols.bynumber | /etc/protocols | Same as protocols.byname, except that the key is the protocol number. |
rpc.byname | /etc/rpc | Contains the program number and name of RPCs known to your system. The key is the RPC program name. |
rpc.bynumber | /etc/rpc | Same as rpc.byname except that the key is the RPC program number. |
services | /etc/services | Same as services.byname, but key is the service name and protocol. |
services.byname | /etc/services | Lists Internet services known to your network. Key is the port or protocol. |
shadow | /etc/shadow | An access-restricted shadow password file. |
ypservers | /var/yp/ypservers | Lists NIS servers known to your network. Initially created by ypinit when the master server was built. |
The name you choose for your NIS domain is at your discretion; however, it should reflect some characteristics of the network it is serving, such as its location, function, or types of systems it contains. You can use a simple domain name, such as marketing; or, if you are a member of the Internet and you choose to do so, you can use your Internet domain name (such as finance.company.com) as your NIS domain name.
The domainname command sets a domain name on an NIS system. The NIS domain name is assigned at system startup. Enter it in the domain file, /var/yp/ypdomain. Be aware that domain names are case sensitive: marketing and Marketing are different domains. See Chapter 4, “Setting Up and Testing NIS”, for complete instructions on setting domain names, and the domainname (1) man page for details of the domainname command.
Determine the system to be the NIS master server for the domain; there is only one NIS master server per domain. The NIS master server houses the original NIS database maps for the domain and is the only server on which changes are made to the NIS database. For this reason, the master server should be a very reliable and stable system. It must be accessible via the network to both NIS clients and NIS slave servers. The master server need not be a dedicated system; it can be responsible for other functions as well.
This is also a good time to determine the name of the NIS password file to be used. By default, NIS derives the database file from the ASCII version of /etc/passwd. This can be a security hole as all system password files require a root account.
To ensure security, create a separate NIS password file that contains no root or superuser-equivalent accounts (no UID=0). A good generic NIS password filename is /etc/passwd.nis. If you plan to use a password file other than the default /etc/passwd, you must tell NIS about the new filename. To do so, you must create the /etc/config/rpc.passwd.options and /etc/config/ypmaster.options files to support /etc/passwd.nis, the NIS password file. The contents of these files should look like the following examples:
# cat /etc/config/rpc.passwd.options PWFILE=/etc/passwd.nis # cat /etc/config/ypmaster.options PWFILE=/etc/passwd.nis |
Slave servers contain copies of the NIS database. The number of NIS slave servers you assign per domain depends upon the size of the domain and the number of networks over which your domain extends. NIS slave servers must be accessible to both NIS clients and the NIS master server by means of the network. NIS slave servers should be reliable systems; the degree of reliability of these systems depends on the availability of backup slave servers.
By default, NIS clients broadcast an NIS bind request when they boot. Since broadcast requests cannot go through gateways, you must have at least one NIS slave server on any network where there are NIS clients. For reliability, there should be more than one NIS slave server on any network where there are NIS clients.
Broadcasting bind requests is the default setting, but clients can specify the server they wish to bind to at boot time. For instance, say you have a domain that encompasses many subnets, one of which contains only one client. To avoid making that client a server, you can specify a list of servers the client can bind to at boot time.
To specify an NIS server at client startup, modify the /etc/config/NSD.options file or the /etc/nsswitch.conf file. These files contain the resolve order and identify the address of any NIS server. Add the following line to the /etc/config/NSD.options file:
nis_servers=nnn.nn.nnn |
As an alternative, add the following line to the /etc/nsswitch.conf file:
ypservers: xx.xx.xx.xx. yy.yy.yy.yy |
where nnn.nn.nnn and xx.xx.xx.xx. yy.yy.yy.yy are the IP addresses or host names of specified servers, but IP addresses are preferred.
Below are some general recommendations for setting up NIS. Because these are only general recommendations, you may need to tailor them to fit your specific site requirements.
During the planning phase, sketch the NIS implementation for your network. Identify the master server, slave servers, and client systems. If you have multiple domains, include them in your drawing.
If your domain spreads over several networks, ensure that there are at least two slave servers per network in case of system or network failures.
Create an alternate password file to be used by NIS only, that does not have any root user IDs. For example, specify /etc/passwd.nis as the NIS password file.
To simplify administration and troubleshooting, maintain only one master server for all maps within a single domain.
Plan to do all database creation and modification on the master server.