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 a master and slave servers. Finally, this chapter provides general recommendations to help you make planning decisions.
This chapter contains these sections:
Before you set up NIS, you need to 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 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. While there may be a physical connection between client1 and client2, there is not a 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(1M), 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 Advanced Site and Server Administration Guide provides detailed information on setting up DNS.
By default, host name resolution is done by first checking NIS, If NIS isn't running, then DNS is checked. If DNS isn't running, then the local /etc/hosts file is checked. There are two methods for specifying a host resolution order other than the default:
Use ypserv(1M) with the –i option.
Redefine the host resolution order in /etc/resolv.conf.
These methods are described in the next two sections.
ypserv can be set up to access DNS systems databases as well as NIS databases. To specify a DNS database lookup, the ypserv process on all NIS servers must be running with the –i option and all NIS servers must also be set up as DNS clients. The –i option allows ypserv to resolve nonlocal host names and addresses (systems not in the same NIS domain) with DNS servers. This option can be set automatically at ypserv startup if you specify the –i option in the /etc/config/ypserv.options file.
A sample /etc/config/ypserv.options file that supports DNS looks like this:
-i |
If the –i option is set in the /etc/config/ypserv.options file, it causes ypserv to look at the NIS host database first, then the DNS hosts database to resolve a system's identity.
The lookup order for resolving a system's identity can be configured in a variety of ways with /etc/resolv.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.
The /etc/resolv.conf file does not exist by default. To override the default system lookup order, you must create this file with the specified lookup order and nameserver list on all master servers, slave servers, and clients in all domains, and set up DNS servers as well.
If you want applications to resolve host names via the DNS database only, put this line in /etc/resolv.conf:
hostresorder bind |
If applications are to search only DNS and /etc/hosts, put this line in /etc/resolv.conf:
hostresorder bind local |
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, put this line in /etc/resolv.conf:
hostresorder nis bind local |
See the resolver(4) manual 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(1M) 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(1M), 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. |
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 key is host name instead of Ethernet address. |
group.bygid | /etc/group | Contains group security information with group ID as key. |
group.byname | /etc/group | Contains group security information with group name as key. |
hosts.byaddr | /etc/hosts | Contains host names and IP addresses, with IP address as key. |
hosts.byname | /etc/hosts | Contains host names and IP addresses, with host name as key. |
mail.aliases | /etc/aliases | Contains aliases and mail addresses, with aliases as key. |
mail.byaddr | /etc/aliases | Contains mail addresses and aliases, with mail address as key. |
netgroup.byhost | /etc/netgroup | Contains group names, user names, and host names, with host name as key. |
netgroup.byuser | /etc/netgroup | Same as netgroup.byhost, except that key is user name. |
netgroup | /etc/netgroup | Same as netgroup.byhost, except that key is group name. |
netid.byname | /etc/group, /etc/hosts, /etc/netid | Contains user, group, and host information, with user name as 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 key is name of network. |
passwd.byname | /etc/passwd | Contains password information with user name as key. |
passwd.byuid | /etc/passwd | Same as passwd.byname, except that key is user ID. |
protocols.byname | /etc/protocols | Contains network protocols known to your network, with protocol name as key. |
protocols.bynumber | /etc/protocols | Same as protocols.byname, except that key is protocol number. |
rpc.bynumber | /etc/rpc | Contains program number and name of RPCs known to your system. Key is RPC program number. |
services.byname | /etc/services | Lists Internet services known to your network. Key is service name. |
ypservers | /var/yp/ypservers | Lists NIS servers known to your network. Initially created by ypinit when 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(1) 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.
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 two files to support the NIS password file, /etc/passwd.nis: /etc/config/rpc.passwd.options and /etc/config/ypmaster.options. The contents of /etc/config/rpc.passwd.options and /etc/config/ypmaster.options should look like these examples:
# cat /etc/config/rpc.passwd.options /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 the server the client should bind to at boot time.
To specify an NIS server at client startup, modify /etc/config/ypbind.options. By default, this file contains a parameter that enables ypset(1M) on the local system (see the ypset(1M) and ypbind(1M) manual pages for more detailed information). The default file, when viewed with cat(1), contains this entry:
# cat /etc/config/ypbind.options -ypsetme |
To specify an NIS server at client startup, add the host name or IP address of the NIS server to the /etc/config/ypbind.options file. The specified server's name must be in the client's local /etc/hosts file for specific binding to work. The /etc/config/ypbind.options file on a client binding to server squares at boot time might look like this when viewed with cat:
# cat /etc/config/ypbind.options -ypsetme squares |
The example above contains the option –ypsetme. If you want additional security or do not need the ypset tool at this time, you can remove the parameter.
Below are some general recommendations for setting up NIS. As 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 for NIS use only that does not have any root UIDs. For example, specify /etc/passwd.nis as the NIS password file.
To simplify administration and troubleshooting, maintain one and only master server for all maps within a single domain.
Plan to do all database creation and modification on the master server.