From owner-freebsd-doc Sat Mar 2 12:25:39 2002 Delivered-To: freebsd-doc@freebsd.org Received: from blackhelicopters.org (geburah.blackhelicopters.org [209.69.178.18]) by hub.freebsd.org (Postfix) with ESMTP id 5376B37B402 for ; Sat, 2 Mar 2002 12:25:14 -0800 (PST) Received: (from mwlucas@localhost) by blackhelicopters.org (8.11.6/8.11.6) id g22KP8r83194; Sat, 2 Mar 2002 15:25:08 -0500 (EST) (envelope-from mwlucas) Date: Sat, 2 Mar 2002 15:25:07 -0500 From: Michael Lucas To: Tom Rhodes Cc: freebsd-doc@FreeBSD.ORG Subject: Re: docs/35098: [PATCH] Handbook NFS stuff Message-ID: <20020302152507.A83170@blackhelicopters.org> References: <200202262110.g1QLA2f07435@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200202262110.g1QLA2f07435@freefall.freebsd.org>; from darklogik@pittgoth.com on Tue, Feb 26, 2002 at 01:10:02PM -0800 Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Okay, I think I'm done ripping on this poor guys work. Anything left for me to say is purely stylistic. Anyone else care to comment? On Tue, Feb 26, 2002 at 01:10:02PM -0800, Tom Rhodes wrote: > The following reply was made to PR docs/35098; it has been noted by GNATS. > > From: Tom Rhodes > To: FreeBSD-gnats-submit@FreeBSD.org > Cc: > Subject: Re: docs/35098: [PATCH] Handbook NFS stuff > Date: Tue, 26 Feb 2002 16:10:17 -0500 (EST) > > Try this one now ;) Clean up of whitespace, and other little "picks" > > -- > Tom Rhodes > > diff -ru handbook.old/advanced-networking/chapter.sgml handbook/advanced-networking/chapter.sgml > --- handbook.old/advanced-networking/chapter.sgml Fri Feb 22 16:16:17 2002 > +++ handbook/advanced-networking/chapter.sgml Tue Feb 26 15:45:36 2002 > @@ -648,6 +648,13 @@ > > > > + Tom > + Rhodes > + Reorganized and enhanced by > + > + > + > + > Bill > Swingle > Written by > @@ -658,44 +665,41 @@ > > NFS > Among the many different file systems that FreeBSD supports is > - the Network File System or NFS. NFS allows you > - to share directories and files on one machine with others > - via the network they are attached to. Using NFS, users and > - programs can access files on remote systems as if they were local > + the Network File System, also known as NFS. > + NFS allows a system to share directories and files > + with others over a network. By using NFS, users and > + programs can access files on remote systems almost as if they were local > files. > > - NFS has several benefits: > + Some of the most notable benefits that NFS can provide are: > > > > - Local workstations do not need as much disk space because > + Local workstations use less disk space because > commonly used data can be stored on a single machine and still > - remain accessible to everyone on the network. > + remain accessible to others over the network. > > > > There is no need for users to have unique home directories > - on every machine on your network. Once they have an established > - directory that is available via NFS it can be accessed from > - anywhere. > + on every network machine. Home directories could be setup on the > + NFS server and made available throughout the network. > > > > - Storage devices such as floppies and CDROM drives can be > - used by other machines on the network eliminating the need for > - extra hardware. > + Storage devices such as floppy disks, CDROM drives, and ZIP drives > + can be used by other machines on the network. This may reduce the number > + of removable media drives. > > > > > - How It Works > + How <acronym>NFS</acronym> Works > > - NFS is composed of two sides – a client side and a > - server side. Think of it as a want/have relationship. The client > - wants the data that the server side > - has. The server shares its data with the > - client. In order for this system to function properly a few > - processes have to be configured and running. > + NFS consists of at least two main parts: a server > + and at least one client. The client remotely accesses the data that is stored > + on the server machine. In order for this to function properly a few > + processes have to be configured and running: > > The server has to be running the following daemons: > > @@ -723,141 +727,129 @@ > > > nfsd > - The NFS Daemon which services requests from NFS > - clients. > + The NFS daemon which services requests from > + the NFS clients. > > > mountd > - The NFS Mount Daemon which actually carries out > - requests that &man.nfsd.8; passes on to it. > + The NFS mount daemon which carries out > + the requests that &man.nfsd.8; passes on to it. > > > portmap > - The portmapper daemon which > - allows NFS clients to find out which port the NFS server > - is using. > + The portmapper daemon > + allows NFS clients to discover which port the NFS server > + is using. > > > > > > - The client side only needs to run a single daemon: > - > - NFS > - client > - > - > - nfsiod > - > - > - > - > - > - > - nfsiod > - The NFS async I/O Daemon which services requests > - from its NFS server. > - > - > - > - > + The client can also run a daemon, known as > + nfsiod. The nfsiod > + daemon services the requests from the NFS server. This > + is optional, and improves performance, but is not required for normal > + and correct operation. See the &man.nfsiod.8; man page for more information. > + > > > > - Configuring NFS > + Configuring <acronym>NFS</acronym> > > NFS > configuration > > > - Luckily for us, on a FreeBSD system this setup is a snap. The > - processes that need to be running can all be run at boot time with > + NFS configuration is relatively straightforward > + process. The processes that need to be running can all start at boot time with > a few modifications to your /etc/rc.conf > - file. > + file. > > - On the NFS server make sure you have: > + On the NFS server, make sure that the following options > + are configured in the /etc/rc.conf file: > > portmap_enable="YES" > nfs_server_enable="YES" > -nfs_server_flags="-u -t -n 4" > mountd_flags="-r" > > - mountd is automatically run whenever the > - NFS server is enabled. The and > - flags to nfsd tell it to > - serve UDP and TCP clients. The flag tells > - nfsd to start 4 copies of itself. > + mountd runs automatically whenever the > + NFS server is enabled. > > - On the client, make sure you have: > + On the client, make sure this option is present in > + /etc/rc.conf: > > nfs_client_enable="YES" > -nfs_client_flags="-n 4" > - > - Like nfsd, the tells > - nfsiod to start 4 copies of itself. > + > > - The last configuration step requires that you create a file > - called /etc/exports. The exports file > - specifies which file systems on your server will be shared > - (a.k.a., exported) and with what clients they will > - be shared. Each line in the file specifies a file system to be > - shared. There are a handful of options that can be used in this > - file but only a few will be mentioned here. You can find out > - about the rest in the &man.exports.5; manual page. > + > + The /etc/exports > + file specifies which filesystems NFS should export (sometimes > + referred to as share). > + Each line in /etc/exports specifies a filesystem to be exported and > + which machines have access to that filesystem. Along with what machines have access > + to that filesystem, access options may also be specified. There are many such options > + that can be used in this file but only a few will be mentioned here. You can easily discover > + other options by reading over the &man.exports.5; manual page. > + > > Here are a few example /etc/exports > entries: > > > NFS > - exporting filesystems > + Examples of exporting filesystems > > - The following line exports /cdrom to > - three silly machines that have the same domain name as the server > + > + The following examples give an idea of how to export filesystems, > + although the settings may be different depending on > + your environment and network configuration. > + The following line exports /cdrom to > + three example machines that have the same domain name as the server > (hence the lack of a domain name for each) or have entries in your > /etc/hosts file. The > - flag makes the shared file system read-only. With this flag, the > - remote system will not be able to make any changes to the > - shared file system. > + flag makes the exported file system read-only. With this flag, the > + remote system will not be able to write any changes to the > + exported file system. > > - /cdrom -ro moe larry curly > + /cdrom -ro host1 host2 host3 > > The following line exports /home to three > hosts by IP address. This is a useful setup if you have a > - private network but do not have DNS running. The > - flag allows all the directories below > - the specified file system to be exported as well. > + private network without a DNS server configured. > + Optionally the /etc/hosts file could be configured > + for internal hostnames; please review &man.hosts.5; for more > + information. The flag allows the directories > + below the specified filesystem to also be exported. > > /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 > > - The following line exports /a to two > - machines that have different domain names than the server. The > - flag allows > - the root user on the remote system to write to the shared > - file system as root. Without the -maproot=0 flag even if > - someone has root access on the remote system they will not > - be able to modify files on the shared file system. > + The following line exports /a so that two > + clients from different domains may access the filesystem. The > + flag allows the root > + user on the remote system to write data on the exported filesystem as > + root. If the -maproot=0 flag is not specified, then even if > + a user has root access on the remote system, they will not > + be able to modify files on the exported filesystem. > > - /a -maproot=0 host.domain.com box.example.com > + /a -maproot=0 host.example.com box.example.org > > - In order for a client to access- an exported file system it must > - have permission to do so. Make sure your client is listed in your > + In order for a client to access an exported filesystem, the client must > + have permission to do so. Make sure the client is listed in your > /etc/exports file. > > In /etc/exports, each line represents > the export information for one filesystem to one host. A > - remote host can only be specified once for each local > - filesystem, and you can only have one default entry per local > - filesystem. For example, let's assume that > - /usr is a single filesystem. The > - following /etc/exports is invalid: > + remote host can only be specified once per filesystem, and may only > + have one default entry. For example, assume that /usr > + is a single filesystem. The following /etc/exports > + would be valid: > > /usr/src client > /usr/ports client > > One filesystem, /usr, has two lines > - specifying its exports to the same host, > - client. The correct format is: > + specifying exports to the same host, client. > + The correct format for this situation is: > > /usr/src /usr/ports client > > @@ -874,40 +866,41 @@ > # client01 has root privileges on it > /usr/src /usr/ports -maproot=0 client01 > /usr/src /usr/ports client02 > -# The "client" machines have root and can mount anywhere > -# up /exports. Anyone inhe world can mount /exports/obj read-only > +# The client machines have root and can mount anywhere > +# on /exports. Anyone in the world can mount /exports/obj read-only > /exports -alldirs -maproot=0 client01 client02 > /exports/obj -ro > > You must restart > mountd whenever you modify > - /etc/exports to make changes take > - effect. This can be accomplished by sending the hangup signal > + /etc/exports so the changes can take effect. > + This can be accomplished by sending the hangup signal > to the mountd process: > > &prompt.root; kill -HUP `cat /var/run/mountd.pid` > > - Now that you have made all these changes you can just reboot > - and let FreeBSD start everything for you at boot time, or you can > - run the following commands as root: > + Alternatively, a reboot will make FreeBSD set everything > + up properly. A reboot is not necessary though. > + Executing the following commands as root, > + should start everything up. > > - On the NFS server: > + On the NFS server: > > &prompt.root; portmap > &prompt.root; nfsd -u -t -n 4 > &prompt.root; mountd -r > > - On the NFS client: > + On the NFS client: > > &prompt.root; nfsiod -n 4 > > - Now you should be ready to actually mount a remote file > - system. This can be done one of two ways. In these examples the > + Now everything should be ready to actually mount a remote file > + system. In these examples the > server's name will be server and the client's > - name will be client. If you just want to > - temporarily mount a remote file system or just want to test out > - your configuration you can run a command like this as root on the > - client: > + name will be client. If you only want to > + temporarily mount a remote file system or would rather test the > + configuration, just execute a command like this as root on the > + client: > > NFS > mounting filesystems > @@ -916,56 +909,59 @@ > > This will mount the /home directory > on the server at /mnt on the client. If > - everything is setup correctly you should be able to go into > - /mnt on the client and see all the files that are on the > - server. > - > - If you want to automatically mount a remote file system > - each time the computer boots, add the filesystem to > - /etc/fstab. Here is an example: > + everything is set up correctly you should be able to enter > + /mnt on the client and see all the files > + that are on the server. > + > + If you want to automatically mount a remote filesystem > + each time the computer boots, add the filesystem to the > + /etc/fstab file. Here is an example: > > server:/home /mnt nfs rw 0 0 > > - Read the &man.fstab.5; manual page for more options. > + The &man.fstab.5; manual page lists all the available options. > > > > Practical Uses > > - There are many very cool uses for NFS. Some of the more common > - ones are listed below. > + NFS has many practical uses. Some of the more common > + ones are listed below: > + > + The following NFS examples require > + NFS to be correctly configured before actual use, > + as previously discussed. > + > + > > NFS > uses > > > > - Have several machines on a network and share a CDROM or > - floppy drive among them. This is cheaper and often more > - convenient. > + Set several machines to share a CDROM or > + other media among them. This is cheaper and often > + more convenient. > > > > - With so many machines on a network, it gets old having your > - personal files strewn all over the place. You can have a > - central NFS server that houses all user home directories and > - shares them with the rest of the machines on the LAN, so no > - matter where you log in you will have the same home > - directory. > + On large networks, it might be more convenient to configure a > + central NFS server in which to store all the user > + home directories. These home directories can then be exported to > + the network so that users would always have the same home directory, > + regardless of which workstation they log in to. > > > > - When you get to reinstalling FreeBSD on one of your > - machines, NFS is the way to go! Just pop your distribution > - CDROM into your file server and away you go! > + You can use an exported CDROM to install > + software on multiple machines. > > > > - Have a common /usr/ports/distfiles > - directory that all your machines share. That way, when you go > - to install a port that you have already installed on a different > - machine, you do not have to download the source all over > - again! > + Several machines could have a common /usr/ports/distfiles > + directory. > + That way, when you need to install a port on several machines, you can > + quickly access the source without downloading it on each machine. > > > > @@ -992,14 +988,15 @@ > amd > automatic mounter daemon > > - &man.amd.8;, which is also known as the automatic mounter > - daemon, is a useful utility used for automatically mounting a > + &man.amd.8; (the automatic mounter daemon) > + is a useful that automatically mounts a > remote filesystem whenever a file or directory within that > filesystem is accessed. Filesystems that are inactive for a > period of time will also be automatically unmounted by > amd. Using > - amd provides a simplistic alternative > - to static mounts. > + amd provides a simple alternative > + to permanent mounts, as permanent mounts should be listed in the > + /etc/fstab. > > amd operates by attaching > itself as an NFS server to the /host and > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-doc" in the body of the message -- Michael Lucas mwlucas@FreeBSD.org, mwlucas@BlackHelicopters.org my FreeBSD column: http://www.oreillynet.com/pub/q/Big_Scary_Daemons http://www.blackhelicopters.org/~mwlucas/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message