Once upon a Time

hosts: files dns bootparams: files ethers: files netmasks: files networks: files protocols: files rpc: files services: files automount: files aliases: files netgroup: nis Obviously this host is an NIS client. However NIS is not used for host name resolution. The presented configuration is very common for NIS clients and it includes a number of other configuration data.

17.4.2 Once upon a Time

It was some time before the etcnsswitch.conf file became the final solution to this search−among−many issue. In the past, UNIX flavors handled this issue differently. There were essentially three ways to integrate NIS with DNS: Run NIS without DNS, which was the default procedure. Even if DNS was running, routines that used NIS ignored DNS unless the necessary changes had been made. 1. Use the NIS maps first, then go to DNS for host names that were not managed by NIS. 2. Ignore NIS for host names and use only DNS. Using DNS without NIS required a rebuilding of the library routines that looked up host names so they no longer made NIS library calls. 3. Besides these, other specific approaches floated around. For example, in DECs ULTRIX OS, the order in which the local etchosts file, the NIS map, and the DNS name servers were queried for host information was specified in the etcsvc.conf file. SGI IRIX 4.X included the nonstandard directive hostorder in the etcresolv.conf file to specify the sequence in which the hostnameIP address data would be searched. SunOS 4.1.x required an additional intervention in the varypMakefile. For DNS to have an effect, the entries with so−called magic cookies had to be modified from their default values: B =−b became B = −b B= became B = Unfortunately, SunOS 4.1.x also carried another surprise: if NIS was not running on the host, then DNS would not operate properly, despite the fact that the etcresolv.conf file and other local DNS related data were set up correctly. The corresponding patch was released to overcome this problem. There were rumors at that time that this was an intentional bug; just to favor NIS over DNS — NIS was SunOSs invention. I never determined if it was an intentional or unintentional bug, but I remember very well it was quite painful to put everything in operation. 425

Chapter 18: Network File System NFS

18.1 NFS Overview

The Network File System NFS is one of the network services that have quickly gained a leading role in the emerging networked environment. NFS allows directories and files to be shared across a network. It is supported by virtually all UNIX flavors and many non−UNIX platforms. Through NFS, users and programs can access files residing at remote systems as if they were local files. In an ideal NFS environment, users neither know nor care where files are actually located. The benefits of such an approach are obvious: NFS reduces local disk storage requirements because a network can store a single copy of a directory accessible by everyone on the network. • NFS simplifies common support tasks, because files can be updated centrally at the single site and yet be available through the network. • NFS allows users to use familiar UNIX commands to manipulate remote files instead of learning new ones; from the user standpoint everything is fully transparent. • NFS is built on the RPC protocol remote procedure call and imposes a client−server relationship on the hosts that use NFS. An NFS server is a host that owns one or more filesystems and makes them available on the network; an NFS client mounts remote filesystems from one or more servers, and uses them in a way equivalent to local filesystems. There are two aspects related to system administration when using NFS: choosing a filesystem naming and mounting scheme, and then configuring the servers and clients to adhere to this scheme. Users themselves do not know a lot about NFS, they simply benefit from using it. Certain actions are required on both the server and client sides to configure NFS. NFS has introduced new terminology to identify the required steps in the procedure itself. On the server side, to advertise and make a filesystem available on the network is known as to export a filesystem, or to share a filesystem as in Solaris 2.x; on the client side, to implement an exported filesystem is known as to mount a remote filesystem. The two actions are complementary: nonexported filesystems cannot be mounted, and non−mounted exported filesystems cannot be used. We will discuss these issues in greater detail later.

18.1.1 NFS Daemons

NFS requires the full support of several daemons, which perform basic server and client NFS−related functions. Based on the RPC model and protocol, NFS includes a number of processes involved on both sides. The NFS related daemons are: nfsd [option] The NFS server daemon, which runs on the server side. The daemon services the clients NFS requests. The option specifies how many daemons should be started; the common value is eight. biod [option] The NFS block IO daemon handles the client side of the NFS IO. The option specifies the number of daemons to be started; the common value is eight. rpc.lockd The NFS lock daemon, which handles file lock requests on both sides; a client requests file locks and a server grants them. rpc.statd The NFS status monitor daemon, which provides monitoring services requested by the rpc.lockd daemon. More specifically, this daemon allows locks to be reset 426