Managing NFS and NIS | O'Reilly Media

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Network Information Service (NIS) and Network File System (NFS) are services that allow you to build distributed computing systems that are both consistent in their appearance and transparent in the way files and data are shared.

NIS provides a distributed database system for common configuration files. NIS servers manage copies of the database files, and NIS clients request information from the servers instead of using their own, local copies of these files. For example, the /etc/hosts file is managed by NIS. A few NIS servers manage copies of the information in the hosts file, and all NIS clients ask these servers for host address information instead of looking in their own /etc/hosts file. Once NIS is running, it is no longer necessary to manage every /etc/hosts file on every machine in the network — simply updating the NIS servers ensures that all machines will be able to retrieve the new configuraton file information.

NFS is a distributed filesystem. An NFS server has one or more filesystems that are mounted by NFS clients; to the NFS clients, the remote disks look like local disks. NFS filesystems are mounted using the standard Unix mount command, and all Unix utilities work just as well with NFS-mounted files as they do with files on local disks. NFS makes system administration easier because it eliminates the need to maintain multiple copies of files on several machines: all NFS clients share a single copy of the file on the NFS server. NFS also makes life easier for users: instead of logging on to many different systems and moving files from one system to another, a user can stay on one system and access all the files that he or she needs within one consistent file tree.

This book contains detailed descriptions of these services, including configuration information, network design and planning considerations, and debugging, tuning, and analysis tips. If you are going to be installing a new network, expanding or fixing an existing network, or looking for mechanisms to manage data in a distributed environment, you should find this book helpful.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Before discussing either NFS, or NIS, we'll provide a brief overview of network services.

NFS and NIS are high-level networking protocols, built on several lower-level protocols. In order to understand the way the high-level protocols function, you need to know how the underlying services work. The lower-level network protocols are quite complex, and several books have been written about them without even touching on NFS and NIS services. Therefore, this chapter contains only a brief outline of the network services used by NFS and NIS.

Network protocols are typically described in terms of a layered model, in which the protocols are "stacked" on top of each other. Data coming into a machine is passed from the lowest-level protocol up to the highest, and data sent to other hosts moves down the protocol stack. The layered model is a useful description because it allows network services to be defined in terms of their functions, rather than their specific implementations. New protocols can be substituted at lower levels without affecting the higher-level protocols, as long as these new protocols behave in the same manner as those that were replaced.

The standard model for networking protocols and distributed applications is the International Organization for Standardization (ISO) seven-layer model shown in Table 1-1.

Table 1-1: The ISO seven-layer model
Layer	Name	Physical Layer
7	Application	NFS and NIS
6	Presentation	XDR

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The physical and data link layers of the network protocol stack together define a machine's network interface. From a software perspective, the network interface defines how the Ethernet device driver gets packets from or to the network. The physical layer describes the way data is actually transmitted on the network medium. The data link layer defines how these streams of bits are put together into manageable chunks of data.

Ethernet is the best known implementation of the physical and data link layers. The Ethernet specification describes how bits are encoded on the cable and also how stations on the network detect the beginning and end of a transmission. We'll stick to Ethernet topics throughout this discussion, since it is the most popular network medium in networks using NFS and NIS.

Ethernet can be run over a variety of media, including thinnet, thicknet, unshielded twisted-pair (UTP) cables, and fiber optics. All Ethernet media are functionally equivalent — they differ only in terms of their convenience, cost of installation, and maintenance. Converters from one media to another operate at the physical layer, making a clean electrical connection between two different kinds of cable. Unless you have access to high-speed test equipment, the physical and data link layers are not that interesting when they are functioning normally. However, failures in them can have strange, intermittent effects on NFS and NIS operation. Some examples of these spectacular failures are given in Chapter 15.

The data link layer defines the format of data on the network. A series of bits, with a definite beginning and end, constitutes a network frame, commonly called a packet. A proper data link layer packet has checksum and network-specific addressing information in it so that each host on the network can recognize it as a valid (or invalid) frame and determine if the packet is addressed to it. The largest packet that can be sent through the data link layer defines the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

At the data link layer, things are fairly simple. Machines agree on the format of packets and a standard 48-bit host addressing scheme. However, the packet format and encoding vary with different physical layers: Ethernet has one set of characteristics, while an X.25-based satellite network has another. Because there are many physical networks, there should ideally be a standard interface scheme so that it isn't necessary to re-implement protocols on top of each physical network and its peculiar interfaces. This is where the network layer fits in. The higher-level protocols, such as TCP (at the transport layer), don't need to know any details about the physical network that is in use. As mentioned before, TCP runs over Ethernet, fiber optic network, or other media; the TCP protocols don't care about the physical connection because it is represented by a well-defined network layer interface.

The network layer protocol of primary interest to NFS and NIS is the Internet Protocol, or IP. As its name implies, IP is responsible for getting packets between hosts on one or more networks. Its job is to make a best effort to get the data from point A to point B. IP makes no guarantees about getting all of the data to the destination, or the order in which the data arrives — these details are left for higher-level protocols to worry about.

On a local area network, IP has a fairly simple job, since it just moves packets from a higher-level protocol down to the data link layer. In a set of connected networks, however, IP is responsible for determining how to get data from its source to the correct destination network. The process of directing datagrams to another network is called routing; it is one of the primary functions of the IP protocol. Appendix A contains a detailed description of how IP performs routing.

IP deals with data in chunks called datagrams. The terms packet and datagram are often used interchangeably, although a packet is a data link-layer object and a datagram is network layer object. In many cases, particularly when using IP on Ethernet, a datagram and packet refer to the same chunk of data. There's no guarantee that the physical link layer can handle a packet of the network layer's size. As previously mentioned, the largest packet that can be handled by the physical link layer is called the Maximum Transmission Unit, or MTU, of the network media. If the medium's MTU is smaller than the network's packet size, then the network layer has to break large datagrams down into packet-sized chunks that the data link and physical layers can digest. This process is called

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The transport layer has two major jobs: it must subdivide user-sized data buffers into network layer-sized datagrams, and it must enforce any desired transmission control such as reliable delivery. Two transport protocols that sit on top of IP are the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP), which offer different delivery guarantees.

TCP is best known as the first half of TCP/IP; as discussed in this and the preceding sections, the acronyms refer to two distinct services. TCP provides reliable, sequenced delivery of packets. It is ideally suited for connection-oriented communication, such as a remote login or a file transfer. Missing packets during a login session is both frustrating and dangerous — what happens if rm *.o gets truncated to rm * ? TCP-based services are generally geared toward long-lived network connections, and TCP is used in any case when ordered datagram delivery is a requirement. There is overhead in TCP for keeping track of packet delivery order and the parts of the data stream that must be resent. This is state information. It's not part of the data stream, but rather describes the state of the connection and the data transfer. Maintaining this information for each connection makes TCP an inherently stateful protocol. Because there is state, TCP can adapt its data flow rate when the network is congested.

UDP is a no-frills transport protocol: it sends large datagrams to a remote host, but it makes no assurances about their delivery or the order in which they are delivered. UDP is best for connectionless communication on local area networks in which no context is needed to send packets to a remote host and there is no concern about congestion. Broadcast-oriented services use UDP, as do those in which repeated, out of sequence, or missed requests have no harmful side effects.

Reliable and unreliable delivery is the primary distinction between TCP and UDP. TCP will always try to replace a packet that gets lost on the network, but UDP does not. UDP packets can arrive in any order. If there is a network bottleneck that drops packets, UDP packets may not arrive at all. It's up to the application built on UDP to determine that a packet was lost, and to resend it if necessary. The state maintained by TCP has a fixed cost associated with it, making UDP a faster protocol on low-latency, high-bandwidth links. The price paid for speed (in UDP) is unreliability and added complexity to the higher level applications that must handle lost packets.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The session and presentation layers define the creation and lifetime of network connections and the format of data sent over these connections. Sessions may be built on top of any supported transport protocol — login sessions use TCP, while services that broadcast information about the local host use UDP. The session protocol used by NFS and NIS is the Remote Procedure Call (RPC).

RPC provides a mechanism for one host to make a procedure call that appears to be part of the local process but is really executed on another machine on the network. Typically, the host on which the procedure call is executed has resources that are not available on the calling host. This distribution of computing services imposes a client/server relationship on the two hosts: the host owning the resource is a server for that resource, and the calling host becomes a client of the server when it needs access to the resource. The resource might be a centralized configuration file (NIS) or a shared filesystem (NFS).

Instead of executing the procedure on the local host, the RPC system bundles up the arguments passed to the procedure into a network datagram. The exact bundling method is determined by the presentation layer, described in the next section. The RPC client creates a session by locating the appropriate server and sending the datagram to a process on the server that can execute the RPC; see Figure 1-1. On the server, the arguments are unpacked, the server executes the result, packages the result (if any), and sends it back to the client. Back on the client side, the reply is converted into a return value for the procedure call, and the user application is re-entered as if a local procedure call had completed. This is the end of the "session," as defined in the ISO model.

Figure 1-1: Remote procedure call execution

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The previous chapter gave an overview of the ISO seven-layer model, describing in some detail the lower layers. In this chapter, we will discuss a class of layer 7— application protocols known as directory services. NIS is an example of such a directory service.

The purpose of a directory service is to map names of one form to names of another form. Often the names of the first form are alphanumeric strings, and the second form are numbers. Or the names of the first form are simple, whereas the names of second form are complex. In the days before computing, we used directories, but they were published on paper. The most obvious one, and perhaps the inspiration for network directory services, is the telephone book. A typical telephone book for a city in the United States consists of three directories:

The white pages of residence listings
The white pages of business listings
The yellow pages of business listings

The residence white page listings contains a list of names, last name first, and for each entry, the telephone number. In many cases, each entry contains the street address of the residence. Thus you can think of the residence white pages in a telephone book, as a way to direct you from a person's name to his telephone number and address. Hence, a telephone book's formal name is a telephone directory.

The white pages of residence listings can be thought of as a "structured set of data." If this data were stored on a computer, a lexicographer would call it a database ; a "structured set of data" is the definition of database in the Concise Oxford Dictionary. Sometimes, when you are in a hurry or don't have a telephone number, you dial a special telephone number (411 or 555-1212 in the United States) to ask an operator ("directory assistance") for the telephone number of the person you want to call. This directory assistance can be thought of as directory service. You, the caller, are a customer or client of the directory service, and the particular operator, is a server of the directory service. In the world of computer networking, the human server is replaced with a directory server of databases. Since there is a server, there has to be a client. The client-side of a directory service is typically a programming library which allows other applications to look up entries in the database.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The purpose of a directory service is to map names of one form to names of another form. Often the names of the first form are alphanumeric strings, and the second form are numbers. Or the names of the first form are simple, whereas the names of second form are complex. In the days before computing, we used directories, but they were published on paper. The most obvious one, and perhaps the inspiration for network directory services, is the telephone book. A typical telephone book for a city in the United States consists of three directories:

The white pages of residence listings
The white pages of business listings
The yellow pages of business listings

The residence white page listings contains a list of names, last name first, and for each entry, the telephone number. In many cases, each entry contains the street address of the residence. Thus you can think of the residence white pages in a telephone book, as a way to direct you from a person's name to his telephone number and address. Hence, a telephone book's formal name is a telephone directory.

The white pages of residence listings can be thought of as a "structured set of data." If this data were stored on a computer, a lexicographer would call it a database ; a "structured set of data" is the definition of database in the Concise Oxford Dictionary. Sometimes, when you are in a hurry or don't have a telephone number, you dial a special telephone number (411 or 555-1212 in the United States) to ask an operator ("directory assistance") for the telephone number of the person you want to call. This directory assistance can be thought of as directory service. You, the caller, are a customer or client of the directory service, and the particular operator, is a server of the directory service. In the world of computer networking, the human server is replaced with a directory server of databases. Since there is a server, there has to be a client. The client-side of a directory service is typically a programming library which allows other applications to look up entries in the database.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

There are numerous different directory services. Here we will discuss some of the commonly used ones.

The roots of DNS are in the early (pre-Web) days of the Internet. DNS was developed to provide hostname and address resolution. Before DNS existed, the authorities for the Internet maintained a global flat text file of the mappings from hostname to IP address in a file called hosts.txt, which was then made available for all the nodes on the Internet to download via a program called gettable. This is analogous to the telephone company giving you an updated telephone book periodically. Systems like Unix would convert the file into /etc/hosts.

This hosts.txt system worked fine for the Internet when it had only thousands of hosts. But when it reached tens of thousands of hosts, it wasn't practical, especially over the slow links available in the late 1980s. What was needed was a way to decentralize the process of looking up hostnames and addresses. The Internet was separated into domains, and each domain was left to identify its own authoritative server for hostnames and addresses within its domain. The only thing that needed to be maintained in a global database was the list of domain names, and the servers for that domain. Returning to the telephone directory analogy, when you live in one area code of the United States, and want to get directory information for another area code, you can prefix the area code to the number 555-1212 to get the appropriate directory service operator.

By assigning authority for a domain's directory information to each domain, DNS can be described as being hierarchical. Similarly, the United States telephone system assigns authority for a given area code's directory information to one pool of directory service operators that answer the 555-1212 number. DNS also lets domains within subdomains further delegate authority, and subdomains in turn. For example, in DNS there is a top-level domain called ".com" that assigns authority for administering

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

With multiple directory services available, having the ability to access different ones is handy. Solaris has an /etc/nsswitch.conf file that for each database, which lets you decide what directory you want to get the database contents from. You can even specify multiple directories. For example, nsswitch.conf might have this entry:

hosts:     files nis dns

This entry says that when gethostbyname( ) and gethostbyaddr( ) are called to look up hostnames and addresses, the interfaces will first try to find the information in the local /etc/hosts file, then check with NIS, then check with DNS. Be aware that some directory services can't be combined in nsswitch.conf. For example, you cannot have both NIS and NIS+ listed in nsswitch.conf, even for different databases.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Clearly, LDAP is the future for directory services on all operating systems, including Solaris. However, at the time this book was written, LDAP was only starting to be integrated with operating systems. Windows 2000 is the first such offering from Microsoft. Solaris 8 includes a fully integrated LDAP client, but no server. Moreover, LDAP is more complex to administer than other directory services.

NIS is perhaps the easiest to administer, but it is also the most limited. It is, however, the universal directory for Unix systems.

DNS is the standard for hostnames and addresses, and you'll find it handy for accessing hosts outside your domain.

NIS+ has gained some acceptance among other non-Solaris Unix operating systems, including HP's HP-UX, IBM, AIX, and Linux. NIS+ is much more secure than NIS.

This rest of this book ignores NIS+ and LDAP, and focuses on NIS and to some degree DNS, since those are what you are most likely to encounter. If you are concerned about security, you'll need to seriously consider deploying NIS+ until LDAP catches up. If security is not a concern, then NIS is fine.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A major problem in running a distributed computing environment is maintaining separate copies of common configuration files such as the password, group, and hosts files. Ideally, the network should be consistent in its configuration, so that users don't have to worry about where they have accounts or if they'll be able to find a new machine on the network. Preserving consistency, however, means that every change to one of these common files must be propagated to every host on the network. In a small network, this might not be a major chore, but in a computing environment with hundreds or thousands of systems, simple administrative tasks can turn into all-day projects. Furthermore, without an automated tool for making changes, the probability of making mistakes grows with the size of the network and the number of places where changes must be made.

The Network Information System (NIS) addresses these problems. It is a distributed database system that replaces copies of commonly replicated configuration files with a centralized management facility. Instead of having to manage each host's files (like /etc/hosts, /etc/passwd, /etc/group, /etc/ethers, and so on), you maintain one database for each file on one central server. Machines that are using NIS retrieve information as needed from these databases. If you add a new system to the network, you can modify one file on a central server and propagate this change to the rest of the network, rather than changing the hosts file for each individual host on the network. For a network of two or three systems, the difference may not be crucial; but for a large network with hundreds of systems, NIS is life-saving.

Because NIS enforces consistent views of files on the network, it is suited for files that have no host-specific information in them. The /etc/vfstab file of filesystems and mount points, for example, is a terrible candidate for management by NIS because it's different on just about every machine. Files that are generally the same on all hosts in a network, such as /etc/passwd

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

NIS is built on the client-server model. An NIS server is a host that contains NIS data files, called maps. Clients are hosts that request information from these maps. Servers are further divided into master and slave servers: the master server is the true single owner of the map data. Slave NIS servers handle client requests, but they do not modify the NIS maps. The master server is responsible for all map maintenance and distribution to its slave servers. Once an NIS map is built on the master to include a change, the new map file is distributed to all slave servers. NIS clients "see" these changes when they perform queries on the map file — it doesn't matter whether the clients are talking to a master or a slave server, because once the map data is distributed, all NIS servers have the same information.

Before going any further, let's take a quick and simple look at how this works. Figure 3-1 shows the relationship between masters, slaves, and clients.

Figure 3-1: NIS masters, slaves, and clients

Consider the hosts NIS map, which replaces the /etc/hosts files on individual systems. If you're familiar with Unix adminstration, you know that this file tells the system how to convert hostnames into IP (internet) addresses. When a client needs to look up the internet address of some system, it would normally read the hosts file. If NIS is running, however, the client bypasses its hosts file, and instead asks an NIS server (either a master or a slave server — it doesn't make any difference) for the information it needs.

Now the other side of the coin: you've added a system, and need to modify the hosts NIS map. You only modify the hosts file on the "master server" — remember, the master server knows the "truth" about the network. Once you've made your changes, you can rebuild the NIS database (i.e., the NIS maps) on the master server. The master server then distributes new versions of the NIS maps to the slave servers, which now provide the updated information to the NIS clients.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now that we have laid a conceptual foundation, let's look at how to set the machinery in motion. Basic NIS management involves setting up NIS servers and enabling NIS on client hosts. Server management includes three tasks:

Installing a new NIS environment, building both master and slave servers.
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.

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now that we've walked through the setup procedure, we will discuss how the NIS maps relate to the files that they replace. In particular, we'll discuss how to modify the files that are appended by NIS so they can take advantage of NIS features. We will also pay special attention to the netgroups NIS map, a confusing but nevertheless important part of the overall picture.

Table 3-2 lists the most common files managed by NIS. Not all vendors use NIS for all of these files, so it is best to check your documentation for a list of NIS-supported files.

Table 3-2: Summary of NIS maps
Map Name	Nickname	Access By	Contains	Default Integration
auto.*		Map key	/etc/auto_*	Append
bootparams		Hostname	/etc/bootparams	Append
ethers.byname	ethers	Hostname	/etc/ethers	Replace
ethers.byaddr		MAC address	/etc/ethers	Replace

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now we've seen how all of the pieces of NIS work by themselves. In reality, of course, the clients and servers must work together with a well-defined sequence of events. To fit all of the client- and server-side functionality into a time-sequenced picture, here is a walk-through the getpwuid( ) library call. The interaction of library routines and NIS daemons is shown in Figure 3-2.

A user runs ls -l, and the ls process needs to find the username corresponding to the UID of each file's owner. In this case, ls -l calls getpwuid(11461) to find the password file entry — and therefore username — for UID 11461.
The local password file looks like this:
```
root:passwd:0:1:Operator:/:/bin/csh
daemon:*:1:1::/:
sys:*:2:2::/:/bin/csh
bin:*:3:3::/bin:
uucp:*:4:8::/var/spool/uucppublic:
```
The local file is checked first, but there is no UID 11461 in it. However, /etc/nsswitch.conf has this entry:
```
passwd:     files nis
```
which effectively appends the entire NIS password map. getpwuid( ) decides it needs to go to NIS for the password file entry.
getpwuid( ) grabs the default domain name, and binds the current process to a server for this domain. The bind can be done explicitly by calling an NIS library routine, or it may be done implicitly when the first NIS lookup request is issued. In either case, ypbind provides a server binding for the named domain. If the default domain is used, ypbind returns the current binding after pinging the bound server. However, the calling process may have specified another domain, forcing ypbind to locate a server for it. The client may have bindings to several domains at any time, all of which are managed by the single ypbind process.
The client process calls the NIS lookup RPC with key=11461 and map=passwd.byuid. The request is bundled up and sent to the ypserv process on the bound server.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

We've seen how NIS operates on master servers, slave servers, and clients, and how clients get map information from the servers. Just knowing how NIS works, however, does not lead to its efficient use. NIS servers must be configured so that map information remains consistent on all servers, and the number of servers and the load on each server should be evaluated so that there is not a user-noticeable penalty for referring to the NIS maps.

Ideally, NIS streamlines system administration tasks by allowing you to update configuration files on many machines by making changes on a single host. When designing a network to use NIS, you must ensure that its performance cost, measured by all users doing "normal" activities, does not exceed its advantages. This chapter explains how to design an NIS network, update and distribute NIS map data, manage multiple NIS domains, and integrate NIS hostname services with the Domain Name Service.

At this point, you should be able to set up NIS on master and slave servers and have a good understanding of how map changes are propagated from master to slave servers. Before creating a new NIS network, you should think about the number of domains and servers you will need. NIS network design entails deciding the number of domains, the number of servers for each domain, and the domain names. Once the framework has been established, installation and ongoing maintenance of the NIS servers is fairly straightforward.

The number of NIS domains that you need depends upon the division of your computing resources. Use a separate NIS domain for each group of systems that has its own system administrator. The job of maintaining a system also includes maintaining its configuration information, wherever it may exist.

Large groups of users sharing network resources may warrant a separate NIS domain if the users may be cleanly separated into two or more groups. The degree to which users in the groups share information should determine whether you should split them into different NIS domains. These large groups of users usually correspond very closely to the organizational groups within your company, and the level of information sharing within the group and between groups is fairly well defined.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

At this point, you should be able to set up NIS on master and slave servers and have a good understanding of how map changes are propagated from master to slave servers. Before creating a new NIS network, you should think about the number of domains and servers you will need. NIS network design entails deciding the number of domains, the number of servers for each domain, and the domain names. Once the framework has been established, installation and ongoing maintenance of the NIS servers is fairly straightforward.

The number of NIS domains that you need depends upon the division of your computing resources. Use a separate NIS domain for each group of systems that has its own system administrator. The job of maintaining a system also includes maintaining its configuration information, wherever it may exist.

Large groups of users sharing network resources may warrant a separate NIS domain if the users may be cleanly separated into two or more groups. The degree to which users in the groups share information should determine whether you should split them into different NIS domains. These large groups of users usually correspond very closely to the organizational groups within your company, and the level of information sharing within the group and between groups is fairly well defined.

A good example is that of a large university, where the physics and chemistry departments have their own networked computing environments. Information sharing within each department will be common, but interdepartment sharing is minimal. The physics department isn't that interested in the machine names used by the chemistry department. The two departments will almost definitely be in two distinct NIS domains if they do not have the same system administrator (each probably gets one of its graduate students to assume this job). Assume, though, that they share an administrator — why create two NIS domains? The real motivation is to clearly mark the lines along which information is commonly shared. Setting up different NIS domains also keeps users in one department from using machines in another department.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Keeping map files updated on all servers is essential to the proper operation of NIS. There are two mechanisms for updating map files: using make and the NIS Makefile, which pushes maps from the master server to the slave servers, and the ypxfr utility, which pulls maps from the master server. This section starts with a look at how map file updates are made and how they get distributed to slave servers.

Having a single point of administration makes it easier to propagate configuration changes through the network, but it also means that you may have more than one person changing the same file. If there are several system administrators maintaining the NIS maps, they need to coordinate their efforts, or you will find that one person removes NIS map entries added by another. Using a source code control system, such as SCCS or RCS, in conjunction with NIS often solves this problem. In the second part of this section, we'll see how to use alternate map source files and source code control systems with NIS.

Master and slave servers are distinguished by their ability to effect permanent changes to NIS maps. Changes may be made to an NIS map on a slave server, but the next map transfer from the master will overlay this change. Modify maps only on the master server, and push them from the master server to its slave servers. On the NIS master server, edit the source file for the map using your favorite text editor. Source files for NIS maps are listed in Table 3-1. Then go to the NIS map directory and build the new map using make, as shown here:

# vi /etc/hosts 
# cd /var/yp 
# make 
               ...New hosts map is built and distributed...

Without any arguments, make builds all maps that are out-of-date with respect to their ASCII source files. When more than one map is built from the same ASCII file, for example the passwd.byname and passwd.byuid maps built from /etc/passwd, they are all built when

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Once NIS is installed and running, you may find that you need to remove or re arrange your NIS servers to accommodate an increased load on one server. For example, if you attach several printers to an NIS server and use it as a print server, it may no longer make a good NIS server if most of its bandwidth is used for driving the printers. If this server is your master NIS server, you may want to assign NIS master duties to another host. We'll look at these advanced administration problems in this section.

If you decommission an NIS slave server, or decide to stop running NIS on it because the machine is loaded by other functions, you need to remove it from the ypserver map and turn off NIS. If a host is listed in the ypservers map but is not running ypserv, then attempts to push maps to this host will fail. This will not cause any data corruption or NIS service failures. It will, however, significantly increase the time required to push the NIS maps because yppush times out waiting for the former server to respond before trying the next server.

There is no explicit "remove" procedure in the NIS maintenance tools, so you have to do this manually. Start by rebuilding the ypservers map on the NIS master server:

master# cd /var/yp 
master# ypcat -k ypservers | grep -v servername\ 
      | makedbm - /var/yp/`domainname`/ypservers

The ypcat command line prints the entries in the current ypservers map, then removes the entry for the desired server using grep -v. This shortened list of servers is given to makedbm, which rebuilds the ypservers map. If the decommissioned server is not being shut down permanently, make sure you remove the NIS maps in /var/yp on the former server so that the machine doesn't start ypserv on its next boot and provide out-of-date map information to the network. Many strange problems result if an NIS server is left running with old maps: the server will respond to requests, but may provide incorrect information to the client. After removing the maps and rebuilding

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A single NIS server may be a slave of more than one master server, if it is providing service to multiple domains. In addition, a server may be a master for one domain and a slave of another. Multimaster relationships are set up when NIS is installed on each of the master servers. In the course of building the ypservers map, the slave servers handling multiple domains are named in the ypservers map for each domain.

When multiple domains are used with independent NIS servers (each serving only one domain), it is sometimes necessary to keep one or more of the maps in these domains in perfect synchronization. Domains with different password and group files, for example, might still want to share global alias and host maps to simplify administration. Adding a new user to either domain would make the user's mail aliases appear in the global alias file, to be shared by both domains. Figure 4-1 shows three NIS domains that share some maps and keep private copies of others.

Figure 4-1: Map sharing in multiple domains

The hosts and aliases maps are shared between the NIS domains so that any changes to them are reflected on all NIS clients in all domains. The passwd and group files are managed on a per-domain basis so that new users or groups in one domain do not automatically appear in the other domains. This gives the system administrators fine control over user access to machines and files in each NIS domain.

A much simpler case is the argument for having a single /etc/rpc file and an /etc/services file across all domains in an organization. As locally developed or third-party software that relies on these additional services is distributed to new networks, the required configuration changes will be in place. This scenario is most common when multiple NIS domains are run on a single network with less than one system administrator per domain.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The hostname management provided by NIS can be integrated with an Internet Domain Name Service (DNS), or the DNS facilities can be used to replace the NIS host map in its entirety. We'll avoid a full-length discussion of setting up a name server. That process depends on the type of name server supported by your vendor, and it is best described by your vendor's documentation. Instead, this section concentrates on differences between the scope of the two hostname services, and support for DNS with and without NIS. Note that the implementation of Domain name services provided by your vendor may not be called DNS. If the Berkeley Internet Name Domain name service or one of its derivatives is used, the service is often called BIND.

DNS provides a hierarchical hostname management system that spans the entire Internet. Each level in the hierarchy designates authoritative name servers that contain maps of hostnames and IP addresses, similar to the NIS hosts map but on a larger scale. The DNS server for a large name service domain would have host information merged from dozens of NIS domains. First among the advantages of DNS is its ability to decentralize responsibility for the maintenance of hostname-to-IP address mappings and the resulting domain name qualification that is used to differentiate identically named hosts.

Decentralized name management means that each organization running a name service domain — whether it is a subdivision of a corporation or an entire company — can maintain its own host information without having to notify some central authority of changes in its local configuration. Host information is published through the authoritative name server for that domain, and hosts in other name service domains retrieve information from the name server when needed. Every domain knows how to reach the next highest level in the name space hierarchy, and it can generally find most of its peer name servers within the same organization. If a name server does not know how to reach the name server for another domain, it can ask the next higher level domain name server for assistance.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The hostname management provided by NIS can be integrated with an Internet Domain Name Service (DNS), or the DNS facilities can be used to replace the NIS host map in its entirety. We'll avoid a full-length discussion of setting up a name server. That process depends on the type of name server supported by your vendor, and it is best described by your vendor's documentation. Instead, this section concentrates on differences between the scope of the two hostname services, and support for DNS with and without NIS. Note that the implementation of Domain name services provided by your vendor may not be called DNS. If the Berkeley Internet Name Domain name service or one of its derivatives is used, the service is often called BIND.

DNS provides a hierarchical hostname management system that spans the entire Internet. Each level in the hierarchy designates authoritative name servers that contain maps of hostnames and IP addresses, similar to the NIS hosts map but on a larger scale. The DNS server for a large name service domain would have host information merged from dozens of NIS domains. First among the advantages of DNS is its ability to decentralize responsibility for the maintenance of hostname-to-IP address mappings and the resulting domain name qualification that is used to differentiate identically named hosts.

Decentralized name management means that each organization running a name service domain — whether it is a subdivision of a corporation or an entire company — can maintain its own host information without having to notify some central authority of changes in its local configuration. Host information is published through the authoritative name server for that domain, and hosts in other name service domains retrieve information from the name server when needed. Every domain knows how to reach the next highest level in the name space hierarchy, and it can generally find most of its peer name servers within the same organization. If a name server does not know how to reach the name server for another domain, it can ask the next higher level domain name server for assistance.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

There are four ways to integrate NIS with DNS, each of which is described in more detail in the following subsections.

This is the default for many systems, including Solaris. In this approach, the name services switch file, nsswitch.conf, is set up so that nis and files are the only directory services listed in the hosts entry of the nsswitch.conf file. The NIS server is configured (by default) to not use DNS to resolve hostnames not found in the hosts map.

Use the NIS maps first, then go to DNS for hostnames that aren't managed by NIS. This is done using a special flag in the NIS hosts map.

NIS is forced to query DNS for hostnames not found in the hosts map if the map is built with the "Inter-Domain" key. The NIS-then-DNS algorithm is embedded in the implementation of ypserv. This means that individual NIS clients don't need to know about the DNS; only the NIS servers will be calling DNS for non-local hostnames.

In the NIS Makefile, add the -b flag to the makedbm script for the hosts.byname and hosts.byaddr maps, which will cause the YP_INTERDOMAIN key to be added to the hosts maps. In Solaris, this is done by changing the following lines in /var/yp/Makefile from:

#B=-b
B=

to:

B=-b
#B=

If a hostname is not found in the NIS map, the YP_INTERDOMAIN keyinstructs NIS to look up the name with the domain name server. Instead of immediately returning an error indicating that the hostname key was not found, ypserv asks the DNS server to look up the hostname. If DNS cannot find the name, then ypserv returns an error to the client. However, if the DNS server locates the hostname, it returns the IP address information to ypserv, and ypserv returns it to the client. Integration of NIS and DNS is completely invisible to the client in terms of calling interfaces: all of the work is done by ypserv on the NIS server.

NIS servers locate DNS servers through the resolver interface, which relies on information in the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·

Table of Contents