UNIX System Administration Handbook - Evi Nemeth [304]
7. Speaking of buzzwords, one of the main ones you’ll hear in this context is “network attached storage,” also known as NAS. It’s just a fancy way of saying “file service.”
8. If your system supports only the older NFS-based automount, we’d still suggest giving it a wide berth.
9. A direct map can also be managed as an NIS database, but don’t try this at home.
10. The other side of this issue is the fact that it takes a certain amount of time to mount a filesystem. System response will be faster and smoother if filesystems aren’t being continually remounted.
17.9 RECOMMENDED READING
CALLAGHAN, BRENT. NFS Illustrated. Addison-Wesley. 1999.
PENDRY, JAN-SIMON, AND NICK WILLIAMS. “AMD: The 4.4BSD Automounter Reference Manual.” 4.4BSD System Manager’s Manual, Usenix and O’Reilly. 1994.
STERN, HAL. Managing NFS and NIS. Sebastopol: O’Reilly & Associates, 1992.
Table 17.13 lists the various RFCs for the NFS protocol and its extensions.
Table 17.13. NFS-related RFCs
RFC
Title
Author
Date
1094
Network File System Protocol Specification
Sun Microsystems
Mar 1989
1813
NFS Version 3 Protocol Specification
B. Callaghan et al.
Jun 1995
2054
WebNFS Client Specification
B. Callaghan
Oct 1996
2055
WebNFS Server Specification
B. Callaghan
Oct 1996
2224
NFS URL Scheme
B. Callaghan
Oct 1997
2623
NFS Version 2 and Version 3 Security Issues
M. Eisler
Jun 1999
2624
NFS Version 4 Design Considerations
S. Shepler
Jun 1999
18 Sharing System Files
A properly functioning system depends on tens, perhaps hundreds, of configuration files all containing the right pieces of information. When you multiply the number of configuration files on a host by the number of hosts on a network, the result can be thousands of files—too many to manage by hand.
In the real world, machines are often similar from an administrative point of view. Instead of editing text files on each machine, it’s more efficient to combine machines into groups that share configuration information. You can combine machines in several different ways.
The simplest way is to keep a master copy of each configuration file in one place and distribute it to members of the group whenever it changes. This solution has the advantages of being simple and working on every UNIX system.
Another approach is to eliminate text files altogether and have each machine obtain its configuration information from a central server. This is more complicated than copying files, but it solves some other problems as well. For example, clients can’t miss updates, even if they are down when a change is made. It may also be faster to obtain information from a server than from a file, depending on the speed of the local disk and the amount of caching performed by the server. On the other hand, the entire network can hang when the central server goes down.
Several attempts have been made to develop administrative databases for large networks, and they are all interesting systems. However, none of the current products seems exactly right in its approach. Some are simple but not secure and not scalable. Others are functional but unwieldy. Some look promising but are not yet fully baked. All the systems seem to have limitations that can prevent you from setting up the network the way you want to.
In this chapter we’ll first discuss some basic techniques for keeping files synchronized on a network. We’ll then talk about two widely used administrative database systems (NIS and NIS+) and one relatively new system that may become commonly used over the next few years (LDAP).
What to share
Of the many configuration files on a UNIX system, only a subset can be usefully shared among machines. The most commonly shared files are listed in Table 18.1.
Table 18.1. System files that are commonly shared
a. Not used on all systems.
Most server-based