UNIX: The Complete Reference (2007)

Part IV: Network Administration

Chapter List

Chapter 15: Clients and Servers

Chapter 16: The Apache Web Server

Chapter 17: Network Administration

Chapter 18: Using UNIX and Windows Together

Chapter 15: Clients and Servers

Overview

Client/server networks have been implemented by UNIX users around the world in order to perform functions that older mainframe systems cannot do efficiently, such as sharing files and resources across a network, and accessing and updating data simultaneously by a number of users on networks using different protocols. File sharing is an important concept in a networked computing environment. When multiple users need access to common information, it is easier and more economical to create one file containing the information, and let everyone share it. While writing information into the common file requires a little coordination, reading information from it only requires that you are allowed access to the file by the machine that houses it.

UNIX plays a key role in client/server computing. In particular, UNIX has been the leading choice of operating systems for servers, and UNIX workstations and PCs are two of the different types of clients these servers serve.

This chapter describes what client/server computing is, how it evolved, and why it is important. You’ll learn the types of things that you can do with client/server computing in a UNIX environment, such as accessing and printing files, or requesting and providing web services for World Wide Web users. The concepts of a web client and a web browser are discussed later on in this chapter; you can find out more about how these two work together on the Internet by reading Chapter 10.

We will also discuss in this chapter how file sharing among users is a key enabler of client/server computing. Tools such as the Network File System (NFS) allow clients to share files with servers in a well-managed environment. The administration of these file system services, using a tool called NIS+ (Network Information Services Plus) is discussed briefly here and also in Chapter 17. NIS+ provides a secure way to ensure that authorized users can access needed f iles f rom the server. You will see some of the same concepts discussed in both this chapter and Chapter 17. This chapter’s focus is primarily on the establishment of file sharing services that are used in a client/server environment. Chapter 17 addresses file sharing as one of a number of issues that a network administrator must manage successfully.

Mid-Range Power: The Evolution of Client/Server Computing

Until the mid-1980s, almost all computing was done on a mainframe or a minicomputer that acted as a host for a number of users connected by a terminal. The advent of the PC allowed users to perform certain tasks on their PCs that did not require the resources of a host computer. Any files that needed to be transferred between the two were sent and received by file transfer routines. A typical example was the transfer of a DOS PC data file to a UNIX host for processing on the UNIX host.

The arrival of the mid-range computer allowed a wider range of services to a connected PC than the mainframe. The mid-range computer could perform some of the tasks that were considered too small for the mainframe but were, in most cases, too complex for the PC. Such a computer was called a server, because it “served” things to PCs that were connected to it, such as common files or programs. The UNIX operating system, which had previously run only on larger computers, was resized to keep all of its important features and run on much smaller systems such as mid-range computers and workstations.

Coincident with this was the introduction of the local area network, or LAN. This networking architecture allowed users in the same workgroup to share applications and data with each other, as well as to share resources such as printers and files. In addition to connecting PCs together, LANs made it possible for PCs to act as clients, or devices that ask for some type of service, from a mid-range machine acting as a server on the network. This also allowed the mid-range machines to act as communications servers for such things as faxing and access to other network services such as the Internet. The combination of these new environments led to the introduction of a new way of computing, called client/server computing.

UNIX has turned out to be a highly suitable server operating system. It has the robustness to provide services to many types of clients with different operating systems such as Windows and Macintosh. At the same time it can provide linkages to mainframes in large data centers. UNIX is also useful as a client operating system, especially on workstations. For a more detailed discussion of the range of capabilities of UNIX, refer to Chapter 1.

Principles of Client/Server Architecture

So now you know that client/server architecture allows a user on one machine, called the client (which can be either a UNIX or Windows NT/2000/XP machine), to request some type of service from a machine to which it is attached, called the server (a UNIX or Windows machine). And you know that they connect to each other over a network such as a LAN (local area network) or a WAN (wide area network). These services may be such things as requests for data in databases, information contained in files or the files themselves, or requests to print data on an attached printer. Although clients and servers are usually thought of as two separate machines, they may, in fact, be two separate areas on the same machine. Thus, a single UNIX machine may be both a client and server at the same time. Further, a client machine attached to a server may itself be a server to another client, and the server may be a client to another server on the network. It is also possible to have a client running one operating system and the server running another operating system.

Several types of client machines are common in client/server environments. One of the most popular clients is an Intel-based personal computer running in a Windows (Windows NT/2000/XP) environment. Another popular client machine is an X terminal; in fact, the X Window System follows a classic client/server model. X Window applications (clients) are separate from the software that manages the input and output (server), so that the same application can be used by X terminals with different hardware characteristics. The X Window System and its use of client/server relationships is discussed on the Companion web site.

There are also UNIX clients that run such operating system environments such as Linux and Mac OS X. You can have a server in your network that requests things from another server; in this case the first server is also a client of the server machine that it is requesting services from. Regardless of the type of client you are using in your client/server network, it is performing at least one of the basic functions described in the next section under client functions.

UNIX is an extremely popular server operating system because-as a true multitasking operating system environment-it can be used in more types of configurations on server machines than file servers and print servers. In addition to sharing applications over the network, one of the most popular uses of UNIX on servers is the file sharing capability available via NFS, which is discussed later in this chapter. In addition, UNIX servers support all distributed computing models, which is why a lot of companies run business-critical applications on UNIX servers. There are also a few different UNIX server environments. One example of a UNIX server environment is an Intel-based personal computer, a workstation, or a minicomputer running a version of UNIX such as Linux. There are also workstations running variants of the UNIX operating system environments such as Solaris, HP-UX, or Mac OS X, which are also described throughout this book. Regardless of the type of server you are using in your client/server network, it is performing at least one of the basic functions described under “Servers and Server Functions,” which follows.

Clients and Client Functions

Clients in a client/server network are the machines or processes that request information, resources, and services from an attached server. These requests may be such things as to provide database data, applications, parts of files, or complete files to the client machine. The data, applications, or files may reside on the server and just be accessed by the client, or they may be physically copied or moved to the client machine. This arrangement allows the client machine to be relatively small, such as a personal computer, and use the memory or disk storage capability on the server, which is often a workstation. A typical client request is to access file information that has been stored on a server called a file server. When a client requests some particular file information to be shared, the server must allow that client to access the requested file, usually through an internal table of which clients have access to server data. This concept is covered in detail later in this chapter in the sections on file sharing using NFS. You’ll learn more about file servers in the section “General Server Functions.”

Another typical client request is to provide some type of print service to the client from a centrally located printer on a server called a print server. This arrangement reduces the number of printers in a multiple-client environment, and it not only reduces the total cost of the network but also provides a single point of administration for all print requests.

Some other types of client requests are to provide communications services such as access to other servers or access to gateways such as the Internet, fax services, or electronic mail services using UNIX facilities such as sendmail and smtp. For each type of client environment there is usually specific software (and sometimes hardware) on the client, with some analogous software and hardware on the server.

Over the past decade, a new type of client has evolved. The web client is a machine that runs either a UNIX variant or Windows, and requests web services-such as retrieving URL and HTML information-from something called a web server (a machine that has special software to let users access web pages and other web services on the network). Chapter 10 discusses these concepts in more depth.

Servers and Server Functions

Servers in a client/server network are the resources-both hardware and software-that provide information and services to the clients on the network. When a client requests a resource such as a file, database data, access to remote applications, or centralized printing, the server provides these resources to the client. As mentioned previously, the server processes may reside on a machine that also acts as a client to another server. We will describe three of the more common UNIX server types later in this section. These are file servers, print servers, and web servers.

In addition to providing these types of services, a server may provide access to other networks, acting as a communications server that connects to other servers, or to mainframe or minicomputers acting as network hosts. It may also allow faxes or electronic mail to be sent from a client on one network to a client on another network. It may act as a security server, allowing only certain clients to gain access to other resources on the network. It may act as a network management server, controlling and reporting on various statuses of both clients and other servers on the network. It may act as a multimedia server, providing audio, video, and data files stored on CD-ROMs to clients from a centralized source, thus reducing hardware and disk storage requirements for each client. A server may also act as a directory or gateway server, whose sole function is to provide directory and routing functions to clients that wish to connect to outside networks, similar to a communications server. An example of this is a DNS (Domain Name Service), discussed in Chapter 17, whose sole function is to resolve host names that are outside of the local host table.

File Servers

File servers provide clients in a network access to files. The Network File System (NFS), developed by Sun Microsystems, is widely used by networks that want to share files in a heterogeneous environment. NFS is discussed in more detail later in this chapter.

The main feature of NFS is the capability to use RPCs (Remote Procedure Calls) to make requests for remote file services appear to the client as though they were local system requests. In other words, the user does not have to worry about where the files actually reside. The files are opened, read, written (if permitted), and closed just like local files. NFS administration takes care of which clients can access files.

The file systems containing client-requested files must be made available for users by first mounting them and then exporting them so that other users can access them. These concepts are discussed in depth later in this chapter.

Print Servers

Before networks existed, computer users printed their output on printers attached to their terminals or PCs. Because high-quality printers were expensive, most users had dot-matrix or letter-quality printers that were fine for text and simple graphics, but not for complicated graphics like those used in electronic publishing. With the advent of UNIX networks, the cost of a high-quality printer could be shared among a number of people using a server that controlled all of the printing for the network, called a print server. The print server accepts and schedules print jobs that are requested by a client machine, using a feature called remote printing. The PC or workstation requesting the printing service doesn’t know or care where the job is actually printed, and the user only cares that it prints fairly quickly and the output is easily accessible.

In a UNIX environment, in order for users to be able to print on a network printer, your network administrator must do a few things. First-if you are using a Linux system-the administrator must create an entry in the client machine’s printcap file. This is an example of a client printcap file:

lp2 | remote1:\

:lp=:rm=unixprt:\

:sd=/var/spool/lp:\

:rp=hplaser

In the entry, lp2 and remote1 are the names that the user sends print jobs to. Because there is no local printer (lp is null), the jobs are sent to the remote printer specified by rm, called unixprt. The job will be spooled to /var/spool/lp and printed on the remote printer hplaser, as designated in rp.

Second, the administrator must create an entry with your client’s machine name in the host.lpd file on the print server. Third, the network administrator must create a printcap file on the print server with corresponding entries. Chapter 17 covers network administration.

If you are using another UNIX variant, such as Solaris, the administrator must make printers available using printmgr, a graphical user interface that administers both local and remote printers on a network. It is invoked by typing

#/usr/sadm/admin/bin/printmgr

Web Servers

The evolution of the World Wide Web has created a new use for client/server architecture. Users on machines that run web clients (see previously in this chapter) depend on access to a machine that can provide services such as retrieving web information from the network, processing it, and sending it to the client to be displayed on the client’s local display This machine, called a web server, fits neatly into the client/server architecture. It is shared by all of the network users for services, just as in the traditional client/server relationship. In addition to offering simple services like file sharing and printing, it shares other types of files, among them HTML (Hypertext Markup Language) documents. Chapter 16 describes the Apache Web Server in detail. Apache is a very popular web server in the UNIX environment. It is free, and many vendors support it by developing new web server applications on top of it.

Client/Server Security

One of the important roles of the server is to determine which clients have access to the server’s resources, and which resources each client may have access to. For instance, a particular client on your network may have access to printer resources but not file sharing or transfer capabilities. Another client on your network may have access to some databases on the server, but not others. A remote client (a client on another connected network) who is attempting to use one of the clients on your server network as a server for that client’s network may be denied access to your server for various reasons. All of this information is included in tables and files that are stored on the server, the client, or both. The system and network administrators have the job of keeping these tables accurate and current.

The UNIX system must ensure that any shared files are safe from users who should not have access to them. It has several ways of restricting access to files in a networked environment. One way is to use an authentication system such as Kerberos. Kerberos was developed as part of Project Athena at MIT, for use on client/server networks, and is still used as an NFS service. You can use Kerberos to send sensitive information around a network and restrict the use of various services on your network to valid users. Kerberos includes a Ticket Granting Service to issue “tickets” allowing a user to access a network resource for a certain length of time. When the ticket expires, the user’s login and password must be authenticated again using a program called kinit in order to obtain a new ticket. Kerberos is available via anonymous FTP from ftp://athena-dist.mit.edu/pub/kerberos/dist/, or at the MIT web page at http://iveb.mit.edu/network/kerberos-form.html. Due to export restrictions, MIT will only distribute Kerberos to citizens of the United States or Canada. On Solaris machines there is a configuration file for Kerberos at /etc/krb5/krb5.conf. The Kerberos NFS servers themselves are configured by using the kadmin command. Refer to the online Solaris System Administration guide for more information at the following URL: http://docs.sun.com/app/docs/doc/816-4557/6maosrjld?a=view. NFSv4 (NFS version 4) comes with Kerberos security included.

We will discuss another way that files are secured during file sharing using secure NFS later on in this chapter. The concept of defining who has access to your files and data-and more important, how to establish security so that unauthorized users don’t have access-is also described in Chapters 12 and 17.

File Sharing

In other chapters we have discussed many UNIX system commands that allow you to use resources on remote machines. These commands include those from the UUCP system (see the Companion web Site) and those in the TCP/IP Internet package. However, when you use any of these commands, you must supply the name of the remote system that contains the resource. In other words, you treat remote resources differently from those on your own system. You cannot use them exactly as you use resources on your local machine.

UNIX uses a distributed file system environment that lets you use remote resources on a network much as you use local resources. Distributed file systems help make all the machines on a network act as if they are all one large computer, even though the computers may be in different locations. Often users and processes on a computer use resources located somewhere on the network without caring, or even knowing, that these resources are physically located on a remote computer.

The Network File System (NFS), developed by Sun Microsystems, is a distributed file system used across all of the major UNIX variants. NFS was built to share files across heterogeneous networks, containing machines running operating systems other than the UNIX System. For this chapter it is assumed that you already have a network running NFS. Chapter 17 will discuss the administration of NFS including how to start running the package on your network, how to configure the packages, and how to maintain its operation.

Distributed File System Basics

Distributed file systems are based on a client/server model. As described previously, a computer on a network that can share some or all of its file systems with one or more other computers on the network is the server. A computer that accesses file systems residing on other computers is the client. A machine in a network can share resources with other computers at the same time it accesses file systems from other machines. This means that a computer can be both a client and a server at the same time.

A computer can offer any of its directory trees for sharing by remote machines in a network. A machine becomes a client of this server when it mounts this remote file system on one of its directories, which is called the mount point, just as it would mount a local file system (see Chapters 13 and 14).

For instance, in Figure 15–1 the client machine jersey has mounted the directory tree, under the directory tools, on the server machine colorado, on the mount point utilities, which is a directory created on jerseyfor this purpose. Once this mount has taken place, a user on jersey can access the files in this directory as if they were on the local machine. However, a user on jersey has no direct access to files on coloradonot under the directory tools, such as the directory private shown in Figure 15–1.

Figure 15–1: Mounting a remote resource

For instance, a user on the client jersey runs the program scheduler, located on the server colorado in the directory /tools/factor, by typing

$ /utilities/factor/scheduler

Similarly, to list all the files in the directory sort, a user on the client jersey types

$ ls /utilities/sort

Benefits of Distributed File Systems

Distributed file systems help you use all the resources on a network in a relatively consistent, transparent, and effective way. With a distributed file system, you access and use remote resources with commands that are often identical to those needed to carry out the same operations on local resources. This means that you do not have to remember different sets of commands for local and for remote files. Also, when a distributed file system is employed, you do not have to know the actual physical location of a resource to be able to use it. You do not have to make your own copies of files to use them.

Because files can be transparently shared, you can add a new computer to a network when the computers on the network run out of storage capacity, making it unnecessary to replace computers with larger ones. Furthermore, you can keep important data files or programs on one or a few designated machines in a network when you use a distributed file system. This makes it unnecessary to keep copies of files on every machine, reducing the need for disk space and for maintaining the same versions of files on every machine.

NFS Features

The Network File System was designed to allow file sharing between computers running a variety of different operating systems. For instance, NFS can be used for file sharing between computers running different UNIX variants, as well as UNIX systems connected to non-UNIX systems (such as Windows machines).

NFS is built on top of the Remote Procedure Call (RPC) interface. RPC is implemented through a library of procedures together with a daemon running on a remote host. The daemon is the agent on the remote host that executes the procedure call made by the calling process. RPC has been designed so that it can run on a wide range of machines. When a client mounts an NFS resource shared by a server, the mounting process carries out a series of remote procedure calls to access the resource on the server. NFS data exchange between different machines is carried out using the external data representation (XDR). Currently, NFS v2 operates over the connectionless User Datagram Protocol (UDP) at the transport layer and Internet Protocol (IP) at the network layer. NFS v3 operates over TCP, and NFS v4 allows NFS over HTTP

A secondary goal in the design of NFS was easy recovery when network problems arise. An NFS server does not keep any information on the state of its local resources. That is, the server does not maintain data about which of its clients has files open at a given time. Because of this, NFS is said to be a stateless service. Servers keep no information on interactions between its clients and its resources.

Because NFS is stateless, an NFS server does not care when one of its clients crashes. The server just continues to operate as before the client crashed. When a server crashes, client processes that use server resources will wait until the server comes back up.

NIS/NIS+ Servers

Today’s typical network consists of a number of file and print servers, as well as clients of all sizes from personal computers to workstations. Users and administrators move from machine to machine to perform different tasks, but they still expect to share the same resources. Coordination of moving files from one machine to another while retaining ownership is an administrative headache, as are assignment and maintenance of user IDs on different machines, adding and tracking new hosts, and so on. UNIX provides a server environment that addresses file sharing in a heterogeneous network.

NIS (Network Information Services) is a network information service that supports distributed databases for maintaining certain administrative files for an entire network, including files containing password information, group information, and host addresses. NIS was developed by Sun Microsystems and for a long time was called Yellow Pages, or YP for short. Over the past few years, Sun has evolved the NIS architecture into a newer management system called NIS+. Although both NIS and NIS+ are used on the major UNIX variants and run pretty much the same way, NIS+ provides additional security features over NIS and is therefore becoming the preferred resource management service. We will discuss NIS+ more in Chapter 17. We will, however, discuss here a little about the way NIS and NIS+ are architected.

NIS/NIS+ itself runs in a client/server model. An NIS client is a client that runs processes that request data from the NIS servers. Applications using NIS/NIS+ do not need to know the location of the database containing information they need. Instead, NIS/NIS+ will locate the information on an NIS server and provide it in the form requested by the application.

There are two types of NIS/NIS+ servers, domain masters and slaves. Domain masters hold all of the database source files for the entire domain. Because NIS/NIS+ services are critical and need to be available even if the NIS/NIS+ server is down, the domain master periodically sends a copy of all of its source files to a backup server, called a slave.

Secure NFS Concepts

Using a distributed file system has many advantages. Client machines do not have to have their own copies of files, so resources can be kept on a single server. Different machines on your network can share files conveniently and easily However, the attributes that make file sharing so useful also make it vulnerable to security leaks.

Although NFS servers authenticate a request to share a resource by authenticating the machine making the request, the user on the machine who initiated the request is not authenticated. This can lead to security problems. For instance, a remote user on a trusted machine may be able to gain superuser privileges if superuser privileges have not been restricted when a file system was shared. This user could then impersonate the owner of this resource, changing it at will. Unauthorized users may be able to gain access to your network and may attack your network by injecting data. Or they may simply eavesdrop on network data, compromising the privacy of the data transmitted over your network.

To protect NFS networking from unauthorized users, some UNIX variants provide a service called Secure NFS that can be used to authenticate individual users on remote machines. Secure NFS is built upon Secure RPC, an authentication scheme for remote procedure calls. Secure RPC encrypts conversations using private-key encryption based on the Data Encryption Standard (DES), using a public-key encryption system for generating a common key for each conversation.

Sharing NFS Resources

You may want to share resources such as files or directories on your system with other systems on the network. For instance, you might want members of a project team to be able to use your source file of the team’s final report. Or you may have written a shell program that can index a book that you would like to make available for sharing with users on other systems. Or you might want to share your printer with users on other systems.

Technically, when you share a resource, you make it available for mounting by remote systems. You have several different ways to share resources on your machine with other systems. First, you can use one of the commands provided for sharing files, such as exportfs, share, and shareall. Second, you can automatically share resources by including lines in the /etc/exports file or the /etc/dfs/dfstab file.

The exportfs Command

Linux and HP-UX use the exportfs command to make a resource available to other users on other systems. To use this command, you must first create an entry for the file in the /etc/ exports file on your system. An example entry that allows the directory /myfiles/papers to be readable and writable by users on the machine sharlene is

/myfiles/papers -rw sharlene

You need to be root in order to share the resource. When you want to make this file sharable, you enter the command

# exportfs

The share Command

The share command is used by Solaris systems to make a resource on your system available to users on other systems. To do this, you must have root privileges. You can use this command to share an NFS resource. You indicate your choice of distributed file systems by using the –F option. You can restrict how clients may use your shared resources by using the –o option.

Suppose you wish to share the directory /usr/xerxes/scripts containing a set of shell scripts over NFS. You want to allow all clients read-only access except for the client jersey. Use the following command line:

# share -F nfs -o ro, rw=jersey /usr/xerxes/scripts

You can use the share command, with no arguments, to display all the resources on your system that are currently shared. The command

$ share -F nfs

displays all NFS resources on your system that are currently shared.

The exportfs -a Command

You may want to make multiple resources available to users at the same time. Linux and HP-UX use the exportfs command with the –a option to do this. For example, suppose you had multiple entries in the /etc/exports file such as

/myfiles/papers -rw sharlene

/myfiles/articles -rw sharlene

/myfiles/presentations -rw dodger

You could make the first two resources available to users on system sharlene and the last one to users on machine dodger by using the command

# exportfs -a

The shareall Command

You can share multiple resources simultaneously on Solaris machines with the shareall command. One way to use this command is to create an input file whose lines are share command lines for sharing particular resources. Suppose your input file is named resources and contains the following commands:

$ cat resources

share -F nfs -o ro, rw=astrid /etc/misc

share -F nfs /usr/xerxes

You can share all the resources listed in this file, as specified in the share commands in the lines of the file, by typing

# shareall resources

Automatically Sharing Resources

Sometimes you might want a resource to be available at all, or almost all, times to remote clients. You can make such a resource available automatically whenever your system starts running NFS. You do this by including a line in the /etc/exportfs file consisting of an exportfs command (Linux and HP-UX) or in the /etc/dfs/dfstab file consisting of a share command (Solaris), with the appropriate options and arguments.

For instance, if you want your directory scripts in your home directory /usr/fred to be an NFS resource on your Solaris system with read-only access to remote clients, include the following line in /etc/dfs/dfstab:

share -F nfs -o ro /usr/fred/scripts

Unsharing NFS Resources

Sometimes you may want to stop sharing, or “unshare,” a resource, making it unavailable for mounting by other systems. For instance, you may have a directory that contains the source file of a final report of a team project. When the report has been edited by all team members, you want to keep users on other systems from accessing the source file until it has been approved by management. Or you may want to make a set of shell scripts in that directory unavailable for sharing while you update them.

You can use the unshare command to make a resource unavailable for mounting, supplying it with the resource pathname. In the case of NFS, you may also give it the resource name. For instance, to unshare the Solaris mounted directory /usr/fred/, which is an NFS resource, you use this command:

# unshare -F nfs /usr/fred/

Note that on Solaris you can unshare only exported directories, not files. Other variants, such as Linux, allow you to unshare files. In the previous example, if there were a file in /usr/fred/ called sourcefiles, you could unshare it with the command

# unshare -F nfs /usr/fred/sourcefiles

The exportfs -u Command

Sometimes you may want to stop sharing all currently shared resources on your system. For instance, you may have a security problem and not want users on remote systems to access your files. Linux and HP-UX allow you to prevent this with the exportfs command with the –u option. They do this slightly differently though. In HP-UX you only need to enter the command

# exportfs -u

in order to stop sharing resources. In Linux, you must first change your current directory to /etc/exports and then issue the command, as in the following example:

# cd /etc/exports

# exportfs -u

The unshareall Command

Solaris uses the unshareall command to stop sharing all resources. Typing

# unshareall

unshares all the currently shared resources on your system.

You can also unshare all current NFS resources on your system with this command:

# unshareall -F nfs

Mounting Remote NFS Resources

Before being able to use a resource on a remote machine that is available for sharing, you need to mount this resource. You can use the mount command or mountall command to mount remote resources. Also, you can automatically mount remote resources by including lines in /etc/vfstab (or /etc/fstab in Linux and some older versions of HP-UX).

The mount Command

You can use the mount command to mount a remote resource. You must be a superuser to mount remote resources. You use the –F option to specify the distributed file system (except in Linux you use the –toption to specify the file system) and the –o option to specify options. You supply the pathname of the remote resource on remotesystem and the mount point where you want this remote resource mounted on your file system as arguments. You must have already used the mkdir command to set up the directory you are using as a mount point.

For instance, you can mount the remote NFS resource, with read-only permission, with pathname /usr/fred/reports at the mount point /usr/new.reports on a Solaris system by typing this:

# mount -F nfs -o ro remotesystem:/usr/fred/reports /usr/new.reports

If the name of the resource /usr/fred/reports is REPORTS, you can mount this resource on a Linux system in the same way by typing this:

# mount -t nfs -o ro REPORTS /usr/new.reports

When you use the mount command to mount a remote resource, it stays mounted only during your current session or until it is specifically unmounted.

The mountall Command

You can mount a combination of remote resources using the mountall command. To use mountall, you create a file containing a line for each remote resource you want to mount. This is the form of the line

special – mountp fstype – automnt mountopts

The fields contain the following information:

For instance, if you create a file called mntres with

$ cat mntres

jersey:/usr/fred/reports -/usr/reports nfs -yes rw

and run the command

# mountall mntres

you will mount all the remote resources listed in the file mntres at the mount points specified with the specified access options (in this example, only one resource).

If you run the command

# mountall -F nfs mntres

you will only mount the NFS resources listed in the file mntres, which in this case is the directory /usr/fred/reports on the server jersey.

Automatic Mounting

You do not have to use the mount command each time you want to mount a remote resource. Instead, you can automatically mount a remote file system when you start running NFS (when your system enters run level 3, as is explained in Chapter 13) by placing the appropriate entries into the /etc/vfstab file (/etc/fstab on Linux).

To have a remote resource mounted automatically, first create a mount point using the mkdir command. Then insert a line in the /etc/vfstab file of the same form as is used by the mountall command.

Suppose you want to automatically mount the NFS resource /usr/tools on the server jersey when your system starts running NFS (enters run level 3). You want to give this resource read-only permissions. Assuming that you have already created the mount point /special/bin, the line you put in the /etc/vfstab file is

jersey:/usr/tools -/special/bin nfs -yes ro

To mount resources you have just listed in the /etc/vfstab file, use this command:

# mountall

This works because the default file used by the mountall command for listing of remote resources is /etc/vfstab.

Unmounting a Remote Resource

You may want to unmount a remote resource from your file system. For example, you may be finished working on a section of a report in which the source files are kept on a remote machine.

The umount Command

You can unmount remote resources using the umount command. To unmount an NFS resource, you supply the name of the remote server, followed by a colon, followed by the pathname of the remote resource or the mount point as an argument to umount.

To unmount the NFS resource /usr/fred/scripts, shared by server jersey, with mount point /etc/scripts, use the command

# umount jersey:/usr/fred/scripts

or

# umount /etc/scripts

The umountall Command

You can unmount all the remote resources you have mounted by issuing a umountall command with the appropriate options. To unmount all NFS resources, use the command

# umountall -F nfs

Displaying Information About Shared Resources

There are several different ways to display information about shared resources, including the share command and the mount command with no options.

Using the share Command

You can use the share command to display information about the resources on your system that are currently shared by remote systems. For instance, to get information about all NFS resources on your system that are currently shared, type this:

$ share -F nfs

Using the mount Command to Display Mounted Resources

You can display a list of all resources that are currently mounted on your system, including both local and remote resources, by running the mount command with no options. For instance,

$ mount

/ on /dev/root read/write/setuid on Fri Jul 7 19:35:27 2006

/proc on /proc read/write on Fri Jul 7 19:35:29 2006

/dev/fd on /dev/fd read/write on Fri Jul 7 19:35:29 2006

/var on /dev/dsk/c1d0s8 read/write/setuid on Fri Jul 7 19:35:49 2006

/usr on /dev/dsk/c1d0s2 read/write/setuid on Mon Jul 10 08:30:27 2006

/home on /dev/dsk/c1d0s9 read/write/setuid on Mon Jul 10 08:30:35 2006

/usr/local on tools read/write/remote on Fri Jul 14 19:25:37 2006

/home/khr on /usr read/write/remote on Sat Jul 15 08:55:04 2006

The remote resources are explicitly noted (but not the machines they are mounted from). For instance, a remote resource entry for Linux would look like this:

badri:/usr/FSF on /mnt/external type nfs (rw, addr=10.8.11.14)

and a remote resource entry on a Solaris machine would look like this:

/users on kanchi:/store/home bg/soft/remote on Sat Jul 15 14:21:07 2006

Browsing Shared Resources

You may want to browse through a list of the NFS resources available to you on specific remote machines. For example, you may be looking for useful shell scripts available on the remote systems in your network. To display information on the NFS resources available to you on Solaris machines, use the dfshares commands. You can restrict the displayed resources to resources on a specific server.

For instance, the command

$ dfshares -F nfs jersey

RESOURCE SERVER ACCESS TRANSPORT

jersey:/home/khr jersey - -

jersey:/var jersey - -

displays a list of all NFS resources available for sharing by machine jersey.

Linux and HP-UX use the showmount command with the –e option to provide the same type of output display For example, to see all NFS resources available for sharing by a Linux machine called kanchi, type

# showmount -e

Export list for kanchi:

/internal/opt/man (everyone)

/internal/httpd/htdocs (everyone)

/internal/ftp/pub/unix/bash (everyone)

Monitoring the Use of Local NFS Resources

Before changing or removing one of your shared local resources, you may want to know which of your resources are mounted by clients. You can use the dfmounts command to determine this. When you use dfmounts to find which local NFS resources are shared, you can restrict the clients considered by listing as arguments the clients you are interested in. For instance, by restricting the server michigan to the clients oregon and arizona, you will find this:

# dfmounts -F nfs oregon arizona

RESOURCE SERVER PATHNAME ACCESS CLIENTS

michigan:/tools michigan /tools rw oregon

michigan:/usr/share michigan usr/share ro oregon, arizona

michigan:/notes michigan /notes ro arizona

Summary

In this chapter we discussed the client/server model and how UNIX is important in this model. We described the more important functions of clients and servers, including print and file serving. We introduced the Network File System (NFS) as part of the Distributed File System (DFS), and we described how these work in the file sharing environment under UNIX. We described the security issues that exist in a file sharing environment, and the features available under UNIX to ensure secure file access. We also discussed some of the UNIX operating system environments that are used as clients or servers in client/server networks, including the concept of a web client and a web server. We will further explore some of these issues in the next chapter.

How to Find Out More

You can learn more about client/server computing from the following books:

· Ligon, Thomas. Client/Server Communications Services: A Guide for the Applications Developer. New York: McGraw-Hill, 1997.

· Lowe, Doug, and David Helda. Client/Server Computing for Dummies. 3rd ed. Foster City, CA: IDG Books Worldwide, 1999.

· Lowe, Doug. Networking for Dummies. 7th ed. New York, NY: John Wiley & Sons, 2004.

· Orfali, Robert, Dan Harkey, and Jeri Edwards. Client/Server Survival Guide. 3rd ed. New York: John Wiley & Sons, 1999.

· Vaughn, Larry. Client/Server System Design and Implementation. New York: McGraw-Hill, 1994.

Here are some helpful books on NFS and NIS/NIS+:

· Eisler, Mike, Ricardo Labiaga, and Hal Stern. Managing NFS and NIS. 2nd ed. Sebastopol, CA: O’Reilly Media, Inc., 2001.

· Olker, David. Optimizing NFS Performance: Tuning and Troubleshooting NFS on HP-UX Systems. Upper Saddle River, NJ: Pearson Education, 2002.

· Ramsey, Rick. All About Administering NIS+. 2nd ed. Englewood Cliffs, NJ: Prentice Hall, 1994.

· Sun Microsystems. System Administration Guide: Naming and Directory Services Nis+. Lincoln, NE: iUniverse, Inc., 2005.

Usenet users can find out more information on client/server computing under the newsgroup comp.client.server. There are a number of FAQs (frequently asked questions) on the issue of client/server computing in the UNIX environment. If you want to find out more about NFS in newsgroups, try comp.protocols.nfs.

There is also a useful web site explaining client/server evolution at

· http://www.compinfo-center.com/apps/client_server.htm

and two FAQs pages at

· http://groups.google.com/group/comp.client-server

and

· http://www.faqs.org/faqs/client-server-faq/.