Restructure some of this chapter and add more to the NFS section.
Submitted by: unfurl
This commit is contained in:
Jim Mock
parent
79ef12008a
commit
9643b8636e
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=6907
2 changed files with 614 additions and 162 deletions
|
|
@ -1,12 +1,20 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.18 2000/01/24 21:24:28 jim Exp $
|
||||
$FreeBSD: doc/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.19 2000/02/13 21:14:23 unfurl Exp $
|
||||
-->
|
||||
|
||||
<chapter id="advanced-networking">
|
||||
<title>Advanced Networking</title>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Synopsis</title>
|
||||
|
||||
<para>The following chapter will cover some of the more frequently
|
||||
used network services on UNIX systems. This, of course, will
|
||||
pertain to configuring said services on your FreeBSD system.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="routing">
|
||||
<title>Gateways and Routes</title>
|
||||
|
||||
|
|
@ -318,102 +326,320 @@ Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1)
|
|||
|
||||
<sect1 id="nfs">
|
||||
<title>NFS</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.jlind;.</emphasis></para>
|
||||
|
||||
<para>Certain Ethernet adapters for ISA PC systems have limitations which
|
||||
can lead to serious network problems, particularly with NFS. This
|
||||
difficulty is not specific to FreeBSD, but FreeBSD systems are affected
|
||||
by it.</para>
|
||||
|
||||
<para>The problem nearly always occurs when (FreeBSD) PC systems are
|
||||
networked with high-performance workstations, such as those made by
|
||||
Silicon Graphics, Inc., and Sun Microsystems, Inc. The NFS mount will
|
||||
work fine, and some operations may succeed, but suddenly the server will
|
||||
seem to become unresponsive to the client, even though requests to and
|
||||
from other systems continue to be processed. This happens to the client
|
||||
system, whether the client is the FreeBSD system or the workstation. On
|
||||
many systems, there is no way to shut down the client gracefully once
|
||||
this problem has manifested itself. The only solution is often to reset
|
||||
the client, because the NFS situation cannot be resolved.</para>
|
||||
<para>Among the many different file systems that FreeBSD supports is
|
||||
a very unique type, the Network File System or NFS. NFS allows you
|
||||
to share directories and files on one machine with one or more other
|
||||
machines via the network they are attached to. Using NFS, users and
|
||||
programs can access files on remote systems as if they were local
|
||||
files.</para>
|
||||
|
||||
<para>Though the “correct” solution is to get a higher
|
||||
performance and capacity Ethernet adapter for the FreeBSD system, there
|
||||
is a simple workaround that will allow satisfactory operation. If the
|
||||
FreeBSD system is the <emphasis>server</emphasis>, include the option
|
||||
<option>-w=1024</option> on the mount from the client. If the FreeBSD
|
||||
system is the <emphasis>client</emphasis>, then mount the NFS file
|
||||
system with the option <option>-r=1024</option>. These options may be
|
||||
specified using the fourth field of the <filename>fstab</filename> entry
|
||||
on the client for automatic mounts, or by using the <option>-o</option>
|
||||
parameter of the mount command for manual mounts.</para>
|
||||
<para>NFS has several benefits:</para>
|
||||
|
||||
<para>It should be noted that there is a different problem, sometimes
|
||||
mistaken for this one, when the NFS servers and clients are on different
|
||||
networks. If that is the case, make <emphasis>certain</emphasis> that
|
||||
your routers are routing the necessary UDP information, or you will not
|
||||
get anywhere, no matter what else you are doing.</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Local workstations dont need as much disk space because
|
||||
commonly used data can be stored on a single machine and still
|
||||
remain accessible to everyone on the network.</para>
|
||||
</listitem>
|
||||
|
||||
<para>In the following examples, <hostid>fastws</hostid> is the host
|
||||
(interface) name of a high-performance workstation, and
|
||||
<hostid>freebox</hostid> is the host (interface) name of a FreeBSD
|
||||
system with a lower-performance Ethernet adapter. Also,
|
||||
<filename>/sharedfs</filename> will be the exported NFS filesystem (see
|
||||
<command>man exports</command>), and <filename>/project</filename> will
|
||||
be the mount point on the client for the exported file system. In all
|
||||
cases, note that additional options, such as <option>hard</option> or
|
||||
<option>soft</option> and <option>bg</option> may be desirable in your
|
||||
application.</para>
|
||||
<listitem>
|
||||
<para>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.</para>
|
||||
</listitem>
|
||||
|
||||
<para>Examples for the FreeBSD system (<hostid>freebox</hostid>) as the
|
||||
client: in <filename>/etc/fstab</filename> on freebox:</para>
|
||||
<listitem>
|
||||
<para>Storage devices such as floppies and CD-ROM drives can be
|
||||
used by other machines on the network eliminating the need for
|
||||
extra hardware.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<programlisting>
|
||||
<sect2>
|
||||
<title>How It Works</title>
|
||||
|
||||
<para> NFS is composed of two sides – a client side and a
|
||||
server side. Think of it as a want/have relationship. The client
|
||||
<emphasis>wants</emphasis> the data that the server side
|
||||
<emphasis>has</emphasis>. 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 properly.</para>
|
||||
|
||||
<para>The server has to be running the following daemons:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><command>nfsd</command> - The NFS Daemon which services
|
||||
requests from NFS clients.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><command>mountd</command> - The NFS Mount Daemon which
|
||||
actually carries out requests that nfsd passes on to
|
||||
it.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>The client side only needs to run a single daemon:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><command>nfsiod</command> - The NFS async I/O Daemon which
|
||||
services requests from its NFS server.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Configuring NFS</title>
|
||||
|
||||
<para>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 modificationss to your <filename>/etc/rc.conf</filename>
|
||||
file.</para>
|
||||
|
||||
<para>On the NFS server make sure you have:</para>
|
||||
|
||||
<programlisting>
|
||||
nfs_server_enable="YES"
|
||||
nfs_server_flags="-u -t -n 4"
|
||||
mountd_flags="-r"</programlisting>
|
||||
|
||||
<para><command>mountd</command> is automatically run whenever the
|
||||
NFS server is enabled. The <option>-u</option> and
|
||||
<option>-t</option> flags to <command>nfsd</command> tell it to
|
||||
serve UDP and TCP clients. The <option>-n 4</option> flag tells
|
||||
<command>nfsd</command> to start 4 copies of itself.</para>
|
||||
|
||||
<para>On the client, make sure you have:</para>
|
||||
|
||||
<programlisting>
|
||||
nfs_client_enable="YES"
|
||||
nfs_client_flags="-n 4"</programlisting>
|
||||
|
||||
<para>Like <command>nfsd</command>, the <option>-n 4</option> tells
|
||||
<command>nfsiod</command> to start 4 copies of itself.</para>
|
||||
|
||||
<para>The last configuration step requires that you create a file
|
||||
called <filename>/etc/exports</filename>. 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 I will only touch on a few of them. You can find out
|
||||
about the rest in the &man.exports.5; man page.</para>
|
||||
|
||||
<para>Here are a few example <filename>/etc/exports</filename>
|
||||
entries:</para>
|
||||
|
||||
<para>The following line exports <filename>/cdrom</filename> to
|
||||
three silly machines that have the same domain name as the server
|
||||
(hence the lack of a domain name for each) or have entries in your
|
||||
<filename>/etc/hosts</filename> file. The <option>-ro</option>
|
||||
flag makes the shared file system read-only. With this flag, the
|
||||
remote system will not be able to make any changes to the the
|
||||
shared file system.</para>
|
||||
|
||||
<programlisting>/cdrom -ro moe larry curly</programlisting>
|
||||
|
||||
<para>The following line exports <filename>/home</filename> to three
|
||||
hosts by IP address. This is a useful setup if you have a
|
||||
private network but do not have DNS running. The
|
||||
<option>-alldirs</option> flag allows all the directories below
|
||||
the specified file system to be exported as well.</para>
|
||||
|
||||
<programlisting>/home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4</programlisting>
|
||||
|
||||
<para>The following line exports <filename>/a</filename> to two
|
||||
machines that have different domain names than the server. The
|
||||
<option>-maproot=0</option> 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 won't
|
||||
be able to modify files on the shared file system.</para>
|
||||
|
||||
<programlisting>/a -maproot=0 host.domain.com box.example.com</programlisting>
|
||||
|
||||
<para>In order for a client to share an exported file system it must
|
||||
have permission to do so. Make sure your client is listed in your
|
||||
<filename>/etc/exports</filename> file.</para>
|
||||
|
||||
<para>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:</para>
|
||||
|
||||
<para>On the NFS server:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>nfsd -u -t -n 4</userinput>
|
||||
&prompt.root; <userinput>mountd -r</userinput></screen>
|
||||
|
||||
<para>On the NFS client:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>nfsiod -n 4</userinput></screen>
|
||||
|
||||
<para>Now you 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 <literal>server</literal> and the client's
|
||||
name will be <literal>client</literal>. If you just want to
|
||||
temporarily mount a remote file system or just want to test out
|
||||
your config you can run a command like this as root on the
|
||||
client:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>mount server:/home /mnt</userinput></screen>
|
||||
|
||||
<para>This will mount <filename>/home</filename> on the server on
|
||||
<filename>/mnt</filename> 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.</para>
|
||||
|
||||
<para>If you want to permanently (each time you reboot) mount a
|
||||
remote file system you need to add it to your
|
||||
<filename>/etc/fstab</filename> file. Here is an example
|
||||
line:</para>
|
||||
|
||||
<programlisting>server:/home /mnt nfs rw 2 2</programlisting>
|
||||
|
||||
<para>Read the &man.fstab.5; man page for more options.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Practical Uses</title>
|
||||
|
||||
<para>There are many very cool uses for NFS. I use it quite a bit
|
||||
on the LAN I admin. Here are a few ways I have found it to be
|
||||
useful.</para>
|
||||
|
||||
<para>I have several machines on my network but only one of them has
|
||||
a CD-ROM drive. Why? Because I have that one CD-ROM drive shared
|
||||
with all the others via NFS. The same can be done with floppy
|
||||
drives.</para>
|
||||
|
||||
<para>With so many machines on the network it gets old having your
|
||||
personal files strewn all over the place. I 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 I login I
|
||||
have the same home directory.</para>
|
||||
|
||||
<para>When you get to reinstalling FreeBSD on one of your machines,
|
||||
NFS is the way to go. Just pop your distribution CD into your
|
||||
file server and away you go.</para>
|
||||
|
||||
<para>I have a common <filename>/usr/ports/distfiles</filename>
|
||||
directory that all my machines share. That way when I go to
|
||||
install a port that I already installed on a different machine I
|
||||
do not have to download the source all over again.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Problems integrating with other systems</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.jlind;.</emphasis></para>
|
||||
|
||||
<para>Certain Ethernet adapters for ISA PC systems have limitations
|
||||
which can lead to serious network problems, particularly with NFS.
|
||||
This difficulty is not specific to FreeBSD, but FreeBSD systems
|
||||
are affected by it.</para>
|
||||
|
||||
<para>The problem nearly always occurs when (FreeBSD) PC systems are
|
||||
networked with high-performance workstations, such as those made
|
||||
by Silicon Graphics, Inc., and Sun Microsystems, Inc. The NFS
|
||||
mount will work fine, and some operations may succeed, but
|
||||
suddenly the server will seem to become unresponsive to the
|
||||
client, even though requests to and from other systems continue to
|
||||
be processed. This happens to the client system, whether the
|
||||
client is the FreeBSD system or the workstation. On many systems,
|
||||
there is no way to shut down the client gracefully once this
|
||||
problem has manifested itself. The only solution is often to
|
||||
reset the client, because the NFS situation cannot be
|
||||
resolved.</para>
|
||||
|
||||
<para>Though the “correct” solution is to get a higher
|
||||
performance and capacity Ethernet adapter for the FreeBSD system,
|
||||
there is a simple workaround that will allow satisfactory
|
||||
operation. If the FreeBSD system is the
|
||||
<emphasis>server</emphasis>, include the option
|
||||
<option>-w=1024</option> on the mount from the client. If the
|
||||
FreeBSD system is the <emphasis>client</emphasis>, then mount the
|
||||
NFS file system with the option <option>-r=1024</option>. These
|
||||
options may be specified using the fourth field of the
|
||||
<filename>fstab</filename> entry on the client for automatic
|
||||
mounts, or by using the <option>-o</option> parameter of the mount
|
||||
command for manual mounts.</para>
|
||||
|
||||
<para>It should be noted that there is a different problem,
|
||||
sometimes mistaken for this one, when the NFS servers and clients
|
||||
are on different networks. If that is the case, make
|
||||
<emphasis>certain</emphasis> that your routers are routing the
|
||||
necessary UDP information, or you will not get anywhere, no matter
|
||||
what else you are doing.</para>
|
||||
|
||||
<para>In the following examples, <hostid>fastws</hostid> is the host
|
||||
(interface) name of a high-performance workstation, and
|
||||
<hostid>freebox</hostid> is the host (interface) name of a FreeBSD
|
||||
system with a lower-performance Ethernet adapter. Also,
|
||||
<filename>/sharedfs</filename> will be the exported NFS
|
||||
filesystem (see <command>man exports</command>), and
|
||||
<filename>/project</filename> will be the mount point on the
|
||||
client for the exported file system. In all cases, note that
|
||||
additional options, such as <option>hard</option> or
|
||||
<option>soft</option> and <option>bg</option> may be desirable in
|
||||
your application.</para>
|
||||
|
||||
<para>Examples for the FreeBSD system (<hostid>freebox</hostid>) as
|
||||
the client: in <filename>/etc/fstab</filename> on freebox:</para>
|
||||
|
||||
<programlisting>
|
||||
fastws:/sharedfs /project nfs rw,-r=1024 0 0</programlisting>
|
||||
|
||||
<para>As a manual mount command on <hostid>freebox</hostid>:</para>
|
||||
<para>As a manual mount command on <hostid>freebox</hostid>:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>mount -t nfs -o -r=1024 fastws:/sharedfs /project</userinput></screen>
|
||||
<screen>&prompt.root; <userinput>mount -t nfs -o -r=1024 fastws:/sharedfs /project</userinput></screen>
|
||||
|
||||
<para>Examples for the FreeBSD system as the server: in
|
||||
<filename>/etc/fstab</filename> on <hostid>fastws</hostid>:</para>
|
||||
<para>Examples for the FreeBSD system as the server: in
|
||||
<filename>/etc/fstab</filename> on <hostid>fastws</hostid>:</para>
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
freebox:/sharedfs /project nfs rw,-w=1024 0 0</programlisting>
|
||||
|
||||
<para>As a manual mount command on <hostid>fastws</hostid>:</para>
|
||||
<para>As a manual mount command on <hostid>fastws</hostid>:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>mount -t nfs -o -w=1024 freebox:/sharedfs /project</userinput></screen>
|
||||
<screen>&prompt.root; <userinput>mount -t nfs -o -w=1024 freebox:/sharedfs /project</userinput></screen>
|
||||
|
||||
<para>Nearly any 16-bit Ethernet adapter will allow operation without the
|
||||
above restrictions on the read or write size.</para>
|
||||
<para>Nearly any 16-bit Ethernet adapter will allow operation
|
||||
without the above restrictions on the read or write size.</para>
|
||||
|
||||
<para>For anyone who cares, here is what happens when the failure occurs,
|
||||
which also explains why it is unrecoverable. NFS typically works with a
|
||||
“block” size of 8k (though it may do fragments of smaller
|
||||
sizes). Since the maximum Ethernet packet is around 1500 bytes, the NFS
|
||||
“block” gets split into multiple Ethernet packets, even
|
||||
though it is still a single unit to the upper-level code, and must be
|
||||
received, assembled, and <emphasis>acknowledged</emphasis> as a unit.
|
||||
The high-performance workstations can pump out the packets which
|
||||
comprise the NFS unit one right after the other, just as close together
|
||||
as the standard allows. On the smaller, lower capacity cards, the later
|
||||
packets overrun the earlier packets of the same unit before they can be
|
||||
transferred to the host and the unit as a whole cannot be reconstructed
|
||||
or acknowledged. As a result, the workstation will time out and try
|
||||
again, but it will try again with the entire 8K unit, and the process
|
||||
will be repeated, ad infinitum.</para>
|
||||
|
||||
<para>By keeping the unit size below the Ethernet packet size limitation,
|
||||
we ensure that any complete Ethernet packet received can be acknowledged
|
||||
individually, avoiding the deadlock situation.</para>
|
||||
<para>For anyone who cares, here is what happens when the failure
|
||||
occurs, which also explains why it is unrecoverable. NFS
|
||||
typically works with a “block” size of 8k (though it
|
||||
may do fragments of smaller sizes). Since the maximum Ethernet
|
||||
packet is around 1500 bytes, the NFS “block” gets
|
||||
split into multiple Ethernet packets, even though it is still a
|
||||
single unit to the upper-level code, and must be received,
|
||||
assembled, and <emphasis>acknowledged</emphasis> as a unit. The
|
||||
high-performance workstations can pump out the packets which
|
||||
comprise the NFS unit one right after the other, just as close
|
||||
together as the standard allows. On the smaller, lower capacity
|
||||
cards, the later packets overrun the earlier packets of the same
|
||||
unit before they can be transferred to the host and the unit as a
|
||||
whole cannot be reconstructed or acknowledged. As a result, the
|
||||
workstation will time out and try again, but it will try again
|
||||
with the entire 8K unit, and the process will be repeated, ad
|
||||
infinitum.</para>
|
||||
|
||||
<para>Overruns may still occur when a high-performance workstations is
|
||||
slamming data out to a PC system, but with the better cards, such
|
||||
overruns are not guaranteed on NFS “units”. When an overrun
|
||||
occurs, the units affected will be retransmitted, and there will be a
|
||||
fair chance that they will be received, assembled, and
|
||||
acknowledged.</para>
|
||||
<para>By keeping the unit size below the Ethernet packet size
|
||||
limitation, we ensure that any complete Ethernet packet received
|
||||
can be acknowledged individually, avoiding the deadlock
|
||||
situation.</para>
|
||||
|
||||
<para>Overruns may still occur when a high-performance workstations
|
||||
is slamming data out to a PC system, but with the better cards,
|
||||
such overruns are not guaranteed on NFS “units”. When
|
||||
an overrun occurs, the units affected will be retransmitted, and
|
||||
there will be a fair chance that they will be received, assembled,
|
||||
and acknowledged.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="diskless">
|
||||
|
|
|
|||
|
|
@ -1,12 +1,20 @@
|
|||
<!--
|
||||
The FreeBSD Documentation Project
|
||||
|
||||
$FreeBSD: doc/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.18 2000/01/24 21:24:28 jim Exp $
|
||||
$FreeBSD: doc/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.19 2000/02/13 21:14:23 unfurl Exp $
|
||||
-->
|
||||
|
||||
<chapter id="advanced-networking">
|
||||
<title>Advanced Networking</title>
|
||||
|
||||
|
||||
<sect1>
|
||||
<title>Synopsis</title>
|
||||
|
||||
<para>The following chapter will cover some of the more frequently
|
||||
used network services on UNIX systems. This, of course, will
|
||||
pertain to configuring said services on your FreeBSD system.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="routing">
|
||||
<title>Gateways and Routes</title>
|
||||
|
||||
|
|
@ -318,102 +326,320 @@ Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1)
|
|||
|
||||
<sect1 id="nfs">
|
||||
<title>NFS</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.jlind;.</emphasis></para>
|
||||
|
||||
<para>Certain Ethernet adapters for ISA PC systems have limitations which
|
||||
can lead to serious network problems, particularly with NFS. This
|
||||
difficulty is not specific to FreeBSD, but FreeBSD systems are affected
|
||||
by it.</para>
|
||||
|
||||
<para>The problem nearly always occurs when (FreeBSD) PC systems are
|
||||
networked with high-performance workstations, such as those made by
|
||||
Silicon Graphics, Inc., and Sun Microsystems, Inc. The NFS mount will
|
||||
work fine, and some operations may succeed, but suddenly the server will
|
||||
seem to become unresponsive to the client, even though requests to and
|
||||
from other systems continue to be processed. This happens to the client
|
||||
system, whether the client is the FreeBSD system or the workstation. On
|
||||
many systems, there is no way to shut down the client gracefully once
|
||||
this problem has manifested itself. The only solution is often to reset
|
||||
the client, because the NFS situation cannot be resolved.</para>
|
||||
<para>Among the many different file systems that FreeBSD supports is
|
||||
a very unique type, the Network File System or NFS. NFS allows you
|
||||
to share directories and files on one machine with one or more other
|
||||
machines via the network they are attached to. Using NFS, users and
|
||||
programs can access files on remote systems as if they were local
|
||||
files.</para>
|
||||
|
||||
<para>Though the “correct” solution is to get a higher
|
||||
performance and capacity Ethernet adapter for the FreeBSD system, there
|
||||
is a simple workaround that will allow satisfactory operation. If the
|
||||
FreeBSD system is the <emphasis>server</emphasis>, include the option
|
||||
<option>-w=1024</option> on the mount from the client. If the FreeBSD
|
||||
system is the <emphasis>client</emphasis>, then mount the NFS file
|
||||
system with the option <option>-r=1024</option>. These options may be
|
||||
specified using the fourth field of the <filename>fstab</filename> entry
|
||||
on the client for automatic mounts, or by using the <option>-o</option>
|
||||
parameter of the mount command for manual mounts.</para>
|
||||
<para>NFS has several benefits:</para>
|
||||
|
||||
<para>It should be noted that there is a different problem, sometimes
|
||||
mistaken for this one, when the NFS servers and clients are on different
|
||||
networks. If that is the case, make <emphasis>certain</emphasis> that
|
||||
your routers are routing the necessary UDP information, or you will not
|
||||
get anywhere, no matter what else you are doing.</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Local workstations dont need as much disk space because
|
||||
commonly used data can be stored on a single machine and still
|
||||
remain accessible to everyone on the network.</para>
|
||||
</listitem>
|
||||
|
||||
<para>In the following examples, <hostid>fastws</hostid> is the host
|
||||
(interface) name of a high-performance workstation, and
|
||||
<hostid>freebox</hostid> is the host (interface) name of a FreeBSD
|
||||
system with a lower-performance Ethernet adapter. Also,
|
||||
<filename>/sharedfs</filename> will be the exported NFS filesystem (see
|
||||
<command>man exports</command>), and <filename>/project</filename> will
|
||||
be the mount point on the client for the exported file system. In all
|
||||
cases, note that additional options, such as <option>hard</option> or
|
||||
<option>soft</option> and <option>bg</option> may be desirable in your
|
||||
application.</para>
|
||||
<listitem>
|
||||
<para>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.</para>
|
||||
</listitem>
|
||||
|
||||
<para>Examples for the FreeBSD system (<hostid>freebox</hostid>) as the
|
||||
client: in <filename>/etc/fstab</filename> on freebox:</para>
|
||||
<listitem>
|
||||
<para>Storage devices such as floppies and CD-ROM drives can be
|
||||
used by other machines on the network eliminating the need for
|
||||
extra hardware.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<programlisting>
|
||||
<sect2>
|
||||
<title>How It Works</title>
|
||||
|
||||
<para> NFS is composed of two sides – a client side and a
|
||||
server side. Think of it as a want/have relationship. The client
|
||||
<emphasis>wants</emphasis> the data that the server side
|
||||
<emphasis>has</emphasis>. 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 properly.</para>
|
||||
|
||||
<para>The server has to be running the following daemons:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><command>nfsd</command> - The NFS Daemon which services
|
||||
requests from NFS clients.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><command>mountd</command> - The NFS Mount Daemon which
|
||||
actually carries out requests that nfsd passes on to
|
||||
it.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>The client side only needs to run a single daemon:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><command>nfsiod</command> - The NFS async I/O Daemon which
|
||||
services requests from its NFS server.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Configuring NFS</title>
|
||||
|
||||
<para>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 modificationss to your <filename>/etc/rc.conf</filename>
|
||||
file.</para>
|
||||
|
||||
<para>On the NFS server make sure you have:</para>
|
||||
|
||||
<programlisting>
|
||||
nfs_server_enable="YES"
|
||||
nfs_server_flags="-u -t -n 4"
|
||||
mountd_flags="-r"</programlisting>
|
||||
|
||||
<para><command>mountd</command> is automatically run whenever the
|
||||
NFS server is enabled. The <option>-u</option> and
|
||||
<option>-t</option> flags to <command>nfsd</command> tell it to
|
||||
serve UDP and TCP clients. The <option>-n 4</option> flag tells
|
||||
<command>nfsd</command> to start 4 copies of itself.</para>
|
||||
|
||||
<para>On the client, make sure you have:</para>
|
||||
|
||||
<programlisting>
|
||||
nfs_client_enable="YES"
|
||||
nfs_client_flags="-n 4"</programlisting>
|
||||
|
||||
<para>Like <command>nfsd</command>, the <option>-n 4</option> tells
|
||||
<command>nfsiod</command> to start 4 copies of itself.</para>
|
||||
|
||||
<para>The last configuration step requires that you create a file
|
||||
called <filename>/etc/exports</filename>. 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 I will only touch on a few of them. You can find out
|
||||
about the rest in the &man.exports.5; man page.</para>
|
||||
|
||||
<para>Here are a few example <filename>/etc/exports</filename>
|
||||
entries:</para>
|
||||
|
||||
<para>The following line exports <filename>/cdrom</filename> to
|
||||
three silly machines that have the same domain name as the server
|
||||
(hence the lack of a domain name for each) or have entries in your
|
||||
<filename>/etc/hosts</filename> file. The <option>-ro</option>
|
||||
flag makes the shared file system read-only. With this flag, the
|
||||
remote system will not be able to make any changes to the the
|
||||
shared file system.</para>
|
||||
|
||||
<programlisting>/cdrom -ro moe larry curly</programlisting>
|
||||
|
||||
<para>The following line exports <filename>/home</filename> to three
|
||||
hosts by IP address. This is a useful setup if you have a
|
||||
private network but do not have DNS running. The
|
||||
<option>-alldirs</option> flag allows all the directories below
|
||||
the specified file system to be exported as well.</para>
|
||||
|
||||
<programlisting>/home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4</programlisting>
|
||||
|
||||
<para>The following line exports <filename>/a</filename> to two
|
||||
machines that have different domain names than the server. The
|
||||
<option>-maproot=0</option> 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 won't
|
||||
be able to modify files on the shared file system.</para>
|
||||
|
||||
<programlisting>/a -maproot=0 host.domain.com box.example.com</programlisting>
|
||||
|
||||
<para>In order for a client to share an exported file system it must
|
||||
have permission to do so. Make sure your client is listed in your
|
||||
<filename>/etc/exports</filename> file.</para>
|
||||
|
||||
<para>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:</para>
|
||||
|
||||
<para>On the NFS server:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>nfsd -u -t -n 4</userinput>
|
||||
&prompt.root; <userinput>mountd -r</userinput></screen>
|
||||
|
||||
<para>On the NFS client:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>nfsiod -n 4</userinput></screen>
|
||||
|
||||
<para>Now you 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 <literal>server</literal> and the client's
|
||||
name will be <literal>client</literal>. If you just want to
|
||||
temporarily mount a remote file system or just want to test out
|
||||
your config you can run a command like this as root on the
|
||||
client:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>mount server:/home /mnt</userinput></screen>
|
||||
|
||||
<para>This will mount <filename>/home</filename> on the server on
|
||||
<filename>/mnt</filename> 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.</para>
|
||||
|
||||
<para>If you want to permanently (each time you reboot) mount a
|
||||
remote file system you need to add it to your
|
||||
<filename>/etc/fstab</filename> file. Here is an example
|
||||
line:</para>
|
||||
|
||||
<programlisting>server:/home /mnt nfs rw 2 2</programlisting>
|
||||
|
||||
<para>Read the &man.fstab.5; man page for more options.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Practical Uses</title>
|
||||
|
||||
<para>There are many very cool uses for NFS. I use it quite a bit
|
||||
on the LAN I admin. Here are a few ways I have found it to be
|
||||
useful.</para>
|
||||
|
||||
<para>I have several machines on my network but only one of them has
|
||||
a CD-ROM drive. Why? Because I have that one CD-ROM drive shared
|
||||
with all the others via NFS. The same can be done with floppy
|
||||
drives.</para>
|
||||
|
||||
<para>With so many machines on the network it gets old having your
|
||||
personal files strewn all over the place. I 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 I login I
|
||||
have the same home directory.</para>
|
||||
|
||||
<para>When you get to reinstalling FreeBSD on one of your machines,
|
||||
NFS is the way to go. Just pop your distribution CD into your
|
||||
file server and away you go.</para>
|
||||
|
||||
<para>I have a common <filename>/usr/ports/distfiles</filename>
|
||||
directory that all my machines share. That way when I go to
|
||||
install a port that I already installed on a different machine I
|
||||
do not have to download the source all over again.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Problems integrating with other systems</title>
|
||||
|
||||
<para><emphasis>Contributed by &a.jlind;.</emphasis></para>
|
||||
|
||||
<para>Certain Ethernet adapters for ISA PC systems have limitations
|
||||
which can lead to serious network problems, particularly with NFS.
|
||||
This difficulty is not specific to FreeBSD, but FreeBSD systems
|
||||
are affected by it.</para>
|
||||
|
||||
<para>The problem nearly always occurs when (FreeBSD) PC systems are
|
||||
networked with high-performance workstations, such as those made
|
||||
by Silicon Graphics, Inc., and Sun Microsystems, Inc. The NFS
|
||||
mount will work fine, and some operations may succeed, but
|
||||
suddenly the server will seem to become unresponsive to the
|
||||
client, even though requests to and from other systems continue to
|
||||
be processed. This happens to the client system, whether the
|
||||
client is the FreeBSD system or the workstation. On many systems,
|
||||
there is no way to shut down the client gracefully once this
|
||||
problem has manifested itself. The only solution is often to
|
||||
reset the client, because the NFS situation cannot be
|
||||
resolved.</para>
|
||||
|
||||
<para>Though the “correct” solution is to get a higher
|
||||
performance and capacity Ethernet adapter for the FreeBSD system,
|
||||
there is a simple workaround that will allow satisfactory
|
||||
operation. If the FreeBSD system is the
|
||||
<emphasis>server</emphasis>, include the option
|
||||
<option>-w=1024</option> on the mount from the client. If the
|
||||
FreeBSD system is the <emphasis>client</emphasis>, then mount the
|
||||
NFS file system with the option <option>-r=1024</option>. These
|
||||
options may be specified using the fourth field of the
|
||||
<filename>fstab</filename> entry on the client for automatic
|
||||
mounts, or by using the <option>-o</option> parameter of the mount
|
||||
command for manual mounts.</para>
|
||||
|
||||
<para>It should be noted that there is a different problem,
|
||||
sometimes mistaken for this one, when the NFS servers and clients
|
||||
are on different networks. If that is the case, make
|
||||
<emphasis>certain</emphasis> that your routers are routing the
|
||||
necessary UDP information, or you will not get anywhere, no matter
|
||||
what else you are doing.</para>
|
||||
|
||||
<para>In the following examples, <hostid>fastws</hostid> is the host
|
||||
(interface) name of a high-performance workstation, and
|
||||
<hostid>freebox</hostid> is the host (interface) name of a FreeBSD
|
||||
system with a lower-performance Ethernet adapter. Also,
|
||||
<filename>/sharedfs</filename> will be the exported NFS
|
||||
filesystem (see <command>man exports</command>), and
|
||||
<filename>/project</filename> will be the mount point on the
|
||||
client for the exported file system. In all cases, note that
|
||||
additional options, such as <option>hard</option> or
|
||||
<option>soft</option> and <option>bg</option> may be desirable in
|
||||
your application.</para>
|
||||
|
||||
<para>Examples for the FreeBSD system (<hostid>freebox</hostid>) as
|
||||
the client: in <filename>/etc/fstab</filename> on freebox:</para>
|
||||
|
||||
<programlisting>
|
||||
fastws:/sharedfs /project nfs rw,-r=1024 0 0</programlisting>
|
||||
|
||||
<para>As a manual mount command on <hostid>freebox</hostid>:</para>
|
||||
<para>As a manual mount command on <hostid>freebox</hostid>:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>mount -t nfs -o -r=1024 fastws:/sharedfs /project</userinput></screen>
|
||||
<screen>&prompt.root; <userinput>mount -t nfs -o -r=1024 fastws:/sharedfs /project</userinput></screen>
|
||||
|
||||
<para>Examples for the FreeBSD system as the server: in
|
||||
<filename>/etc/fstab</filename> on <hostid>fastws</hostid>:</para>
|
||||
<para>Examples for the FreeBSD system as the server: in
|
||||
<filename>/etc/fstab</filename> on <hostid>fastws</hostid>:</para>
|
||||
|
||||
<programlisting>
|
||||
<programlisting>
|
||||
freebox:/sharedfs /project nfs rw,-w=1024 0 0</programlisting>
|
||||
|
||||
<para>As a manual mount command on <hostid>fastws</hostid>:</para>
|
||||
<para>As a manual mount command on <hostid>fastws</hostid>:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>mount -t nfs -o -w=1024 freebox:/sharedfs /project</userinput></screen>
|
||||
<screen>&prompt.root; <userinput>mount -t nfs -o -w=1024 freebox:/sharedfs /project</userinput></screen>
|
||||
|
||||
<para>Nearly any 16-bit Ethernet adapter will allow operation without the
|
||||
above restrictions on the read or write size.</para>
|
||||
<para>Nearly any 16-bit Ethernet adapter will allow operation
|
||||
without the above restrictions on the read or write size.</para>
|
||||
|
||||
<para>For anyone who cares, here is what happens when the failure occurs,
|
||||
which also explains why it is unrecoverable. NFS typically works with a
|
||||
“block” size of 8k (though it may do fragments of smaller
|
||||
sizes). Since the maximum Ethernet packet is around 1500 bytes, the NFS
|
||||
“block” gets split into multiple Ethernet packets, even
|
||||
though it is still a single unit to the upper-level code, and must be
|
||||
received, assembled, and <emphasis>acknowledged</emphasis> as a unit.
|
||||
The high-performance workstations can pump out the packets which
|
||||
comprise the NFS unit one right after the other, just as close together
|
||||
as the standard allows. On the smaller, lower capacity cards, the later
|
||||
packets overrun the earlier packets of the same unit before they can be
|
||||
transferred to the host and the unit as a whole cannot be reconstructed
|
||||
or acknowledged. As a result, the workstation will time out and try
|
||||
again, but it will try again with the entire 8K unit, and the process
|
||||
will be repeated, ad infinitum.</para>
|
||||
|
||||
<para>By keeping the unit size below the Ethernet packet size limitation,
|
||||
we ensure that any complete Ethernet packet received can be acknowledged
|
||||
individually, avoiding the deadlock situation.</para>
|
||||
<para>For anyone who cares, here is what happens when the failure
|
||||
occurs, which also explains why it is unrecoverable. NFS
|
||||
typically works with a “block” size of 8k (though it
|
||||
may do fragments of smaller sizes). Since the maximum Ethernet
|
||||
packet is around 1500 bytes, the NFS “block” gets
|
||||
split into multiple Ethernet packets, even though it is still a
|
||||
single unit to the upper-level code, and must be received,
|
||||
assembled, and <emphasis>acknowledged</emphasis> as a unit. The
|
||||
high-performance workstations can pump out the packets which
|
||||
comprise the NFS unit one right after the other, just as close
|
||||
together as the standard allows. On the smaller, lower capacity
|
||||
cards, the later packets overrun the earlier packets of the same
|
||||
unit before they can be transferred to the host and the unit as a
|
||||
whole cannot be reconstructed or acknowledged. As a result, the
|
||||
workstation will time out and try again, but it will try again
|
||||
with the entire 8K unit, and the process will be repeated, ad
|
||||
infinitum.</para>
|
||||
|
||||
<para>Overruns may still occur when a high-performance workstations is
|
||||
slamming data out to a PC system, but with the better cards, such
|
||||
overruns are not guaranteed on NFS “units”. When an overrun
|
||||
occurs, the units affected will be retransmitted, and there will be a
|
||||
fair chance that they will be received, assembled, and
|
||||
acknowledged.</para>
|
||||
<para>By keeping the unit size below the Ethernet packet size
|
||||
limitation, we ensure that any complete Ethernet packet received
|
||||
can be acknowledged individually, avoiding the deadlock
|
||||
situation.</para>
|
||||
|
||||
<para>Overruns may still occur when a high-performance workstations
|
||||
is slamming data out to a PC system, but with the better cards,
|
||||
such overruns are not guaranteed on NFS “units”. When
|
||||
an overrun occurs, the units affected will be retransmitted, and
|
||||
there will be a fair chance that they will be received, assembled,
|
||||
and acknowledged.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="diskless">
|
||||
|
|
|
|||
Loading…
Reference in a new issue