From owner-freebsd-doc Wed Feb 20 22: 0:41 2002 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id ED35E37B405 for ; Wed, 20 Feb 2002 22:00:03 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g1L603b86291; Wed, 20 Feb 2002 22:00:03 -0800 (PST) (envelope-from gnats) Date: Wed, 20 Feb 2002 22:00:03 -0800 (PST) Message-Id: <200202210600.g1L603b86291@freefall.freebsd.org> To: freebsd-doc@freebsd.org Cc: From: Tom Rhodes Subject: Re: docs/35098: [PATCH] Handbook NFS stuff Reply-To: Tom Rhodes 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 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: Thu, 21 Feb 2002 01:00:48 -0500 (EST) Here we go again! Another patch, I did various cleanups. Using many of the wonder ideas that Ceri gave me, and the few sent by others, a complete redo is here. One major note, I removed from portmapper, because I thought it looked ugly after the build, but did not do any changes in the lines. It should be easy to modify this before the patch is actually applied. Thanks to everyone who gave me their opinions! -- Tom (darklogik) Rhodes www.Pittgoth.com -The Gothic Liberation Front www.FreeBSD.org -The Power To Serve diff -ru handbook.old/advanced-networking/chapter.sgml handbook/advanced-networking/chapter.sgml --- handbook.old/advanced-networking/chapter.sgml Tue Feb 19 16:19:33 2002 +++ handbook/advanced-networking/chapter.sgml Thu Feb 21 00:55:41 2002 @@ -648,6 +648,13 @@ + Tom + Rhodes + Reorganized and enhanced by + + + + Bill Swingle Written by @@ -658,44 +665,42 @@ 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 - files. + the Network File System, also known as NFS. + NFS allows your 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 benefits for using NFS 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. + There would be no need for users to have unique home directories + on every network machine. Once they have an established a home + directory that is available on an NFS filesystem, + it can be accessed from other machines on 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 eliminate the + need for every system to have a CDROM or ZIP drive, providing a more + cost effective solution. - 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 client + and a server. 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 +728,134 @@ 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 - a few modifications to your /etc/rc.conf - file. + On FreeBSD, the setup of NFS is a 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. - 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 + mountd runs automatically whenever the + NFS server is enabled. The and + flags tell nfsd to serve UDP and TCP clients. The flag tells nfsd to start 4 copies of itself. - On the client, make sure you have: + On the client, make sure these options are present in the + /etc/rc.conf file: nfs_client_enable="YES" nfs_client_flags="-n 4" - Like nfsd, the tells + As with 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 NFS configuration requires that a file + known as exports exist in the + /etc directory. The /etc/exports + file specifies which filesystems on the server will be shared (or + exported), and with which clients. Each line in + /etc/exports specifies a filesystem to be exported and + with which this will be done. 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 + + In the following examples, an idea of how to export filesystems + is displayed, although the settings may be different depending on + your environment and network setup. + 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 but do not have a DNS server configured. + The flag allows for 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 + machines with different domain names 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 + In the /etc/exports file, 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 entry. For example, assume that /usr + is a single filesystem. The following /etc/exports + would be invalid: /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 +872,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 + You must restart mountd whenever you modify + /etc/exports to make the changes current. + This can be accomplished by either 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 should make FreeBSD set everything + up properly if the previously described options were added to + /etc/rc.conf. Although, a reboot is not necessary. + Executing the following commands, as root of course, + 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 + Now everything should be ready to actually mount a remote file system. This can be done one of two ways. 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 +915,58 @@ 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. + There are many practical uses for NFS. Some of the + more common ones are listed below: + + The following NFS examples require + NFS to be correctly configured before actual use, see + above. + + 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 up several machines on a network to share a CDROM or + floppy drive 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 may be more convenient to configure a + central NFS server in which to store all the user + home directories on. 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 one CDROM on the NFS server to install + FreeBSD over the network 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, assuming of course all the machines are FreeBSD. + 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 +993,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 utility used for automatically mounting 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 Only in handbook: imagelib To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message