Patch from Ken Reed to update and improve the NFS section. Modified
version of the patch included with PR. PR: docs/181269 Submitted by: Ken Reed <kreed002@gmail.com>
This commit is contained in:
Warren Block
parent
7b067ac76b
commit
eda432163d
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=42602
1 changed files with 185 additions and 296 deletions
|
|
@ -557,37 +557,40 @@ server-program-arguments</programlisting>
|
|||
<title>Network File System (NFS)</title>
|
||||
|
||||
<indexterm><primary>NFS</primary></indexterm>
|
||||
<para>Among the many different file systems that FreeBSD supports
|
||||
is the Network File System, also known as <acronym role="Network
|
||||
File System">NFS</acronym>. <acronym role="Network File
|
||||
System">NFS</acronym> allows a system to share directories and
|
||||
files with others over a network. By using <acronym
|
||||
role="Network File System">NFS</acronym>, users and programs can
|
||||
access files on remote systems almost as if they were local
|
||||
files.</para>
|
||||
<para>&os; supports the Network File System
|
||||
(<acronym>NFS</acronym>), which allows a server to share
|
||||
directories and files with clients over a network. With
|
||||
<acronym>NFS</acronym>, users and programs can access files
|
||||
on remote systems as if they were stored locally.</para>
|
||||
|
||||
<para>Some of the most notable benefits that
|
||||
<acronym>NFS</acronym> can provide are:</para>
|
||||
<para>The most notable benefits that
|
||||
<acronym>NFS</acronym> provides are:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Local workstations use less disk space because commonly
|
||||
used data can be stored on a single machine and still remain
|
||||
accessible to others over the network.</para>
|
||||
<para>Data that would otherwise be duplicated on each client
|
||||
can be kept in a single location and accessed by clients
|
||||
on the network.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>There is no need for users to have separate home
|
||||
directories on every network machine. Home directories
|
||||
could be set up on the <acronym>NFS</acronym> server and
|
||||
made available throughout the network.</para>
|
||||
<para>User home directories can be stored in one location
|
||||
and accessed by their owners over the network.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Storage devices such as floppy disks, CDROM drives, and
|
||||
&iomegazip; drives can be used by other machines on the
|
||||
network. This may reduce the number of removable media
|
||||
drives throughout the network.</para>
|
||||
<para>Administration of <acronym>NFS</acronym> exports is
|
||||
also simplified. For example, there is only one file
|
||||
system where security or backup policies must be
|
||||
set.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Removable media storage devices, such as floppy disks
|
||||
or <acronym>CD-ROM</acronym> drives, can be used by other
|
||||
machines on the network. This reduces the number of devices
|
||||
throughout the network and provides a centralized location
|
||||
to manage their security.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
|
|
@ -600,7 +603,7 @@ server-program-arguments</programlisting>
|
|||
order for this to function properly a few processes have to be
|
||||
configured and running.</para>
|
||||
|
||||
<para>The server has to be running the following daemons:</para>
|
||||
<para>These daemons must be running on the server:</para>
|
||||
<indexterm>
|
||||
<primary>NFS</primary>
|
||||
<secondary>server</secondary>
|
||||
|
|
@ -657,13 +660,8 @@ server-program-arguments</programlisting>
|
|||
</tgroup>
|
||||
</informaltable>
|
||||
|
||||
<para>The client can also run a daemon, known as
|
||||
<application>nfsiod</application>. The
|
||||
<application>nfsiod</application> daemon services the requests
|
||||
from the <acronym>NFS</acronym> server. This is optional, and
|
||||
improves performance, but is not required for normal and
|
||||
correct operation. See the &man.nfsiod.8; manual page for
|
||||
more information.</para>
|
||||
<para>Running &man.nfsiod.8; can improve performance on the
|
||||
client, but is not required.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="network-configuring-nfs">
|
||||
|
|
@ -674,14 +672,11 @@ server-program-arguments</programlisting>
|
|||
<secondary>configuration</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para><acronym>NFS</acronym> configuration is a relatively
|
||||
straightforward process. The processes that need to be
|
||||
running can all start at boot time with a few modifications
|
||||
to <filename>/etc/rc.conf</filename>.</para>
|
||||
|
||||
<para>On the <acronym>NFS</acronym> server, make sure that the
|
||||
following options are configured in the
|
||||
<filename>/etc/rc.conf</filename> file:</para>
|
||||
<para>Enabling the <acronym>NFS</acronym> server
|
||||
is straightforward. The required processes
|
||||
can be set to start at boot time by adding
|
||||
these options to
|
||||
<filename>/etc/rc.conf</filename>:</para>
|
||||
|
||||
<programlisting>rpcbind_enable="YES"
|
||||
nfs_server_enable="YES"
|
||||
|
|
@ -690,99 +685,101 @@ mountd_flags="-r"</programlisting>
|
|||
<para><application>mountd</application> runs automatically
|
||||
whenever the <acronym>NFS</acronym> server is enabled.</para>
|
||||
|
||||
<para>On the client, make sure this option is present in
|
||||
<para>To enable the client, set this option in
|
||||
<filename>/etc/rc.conf</filename>:</para>
|
||||
|
||||
<programlisting>nfs_client_enable="YES"</programlisting>
|
||||
|
||||
<para>The <filename>/etc/exports</filename> file specifies which
|
||||
file systems <acronym>NFS</acronym> should export (sometimes
|
||||
referred to as <quote>share</quote>). Each line in
|
||||
<para><filename>/etc/exports</filename> specifies which
|
||||
file systems the <acronym>NFS</acronym> server will
|
||||
export. Each line in
|
||||
<filename>/etc/exports</filename> specifies a file system to
|
||||
be exported and which machines have access to that file
|
||||
system. Along with what machines have access to that file
|
||||
system, 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. Other options are discussed in
|
||||
the &man.exports.5; manual page.</para>
|
||||
|
||||
<para>Here are a few example <filename>/etc/exports</filename>
|
||||
entries:</para>
|
||||
be exported and which clients have access to that file system,
|
||||
as well as any access options. There are many
|
||||
such options that can be used in this file, but only a few will
|
||||
be mentioned here. See &man.exports.5; for the full list of
|
||||
options.</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>NFS</primary>
|
||||
<secondary>export examples</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>The following examples give an idea of how to export file
|
||||
systems, although the settings may be different depending on
|
||||
the environment and network configuration. For instance, to
|
||||
export the <filename>/cdrom</filename> directory 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
|
||||
the <filename>/etc/hosts</filename> file. The
|
||||
<option>-ro</option> 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.</para>
|
||||
<para>These examples give an idea of how to export file systems.
|
||||
Minor modifications may be required for the examples to work
|
||||
on the reader's network.</para>
|
||||
|
||||
<programlisting>/cdrom -ro host1 host2 host3</programlisting>
|
||||
<para>This example shows how to export the
|
||||
<filename class="directory">/cdrom</filename> directory to
|
||||
three clients called <replaceable>alpha</replaceable>,
|
||||
<replaceable>bravo</replaceable>, and
|
||||
<replaceable>charlie</replaceable>:</para>
|
||||
|
||||
<para>The following line exports <filename>/home</filename> to
|
||||
three hosts by IP address. This is a useful setup on
|
||||
a private network without a <acronym>DNS</acronym> server
|
||||
configured. Optionally the <filename>/etc/hosts</filename>
|
||||
file could be configured for internal hostnames; please review
|
||||
&man.hosts.5; for more information. The
|
||||
<option>-alldirs</option> flag allows the subdirectories to be
|
||||
mount points. In other words, it will not mount the
|
||||
subdirectories but permit the client to mount only the
|
||||
directories that are required or needed.</para>
|
||||
<programlisting>/cdrom -ro <replaceable>alpha</replaceable> <replaceable>bravo</replaceable> <replaceable>charlie</replaceable></programlisting>
|
||||
|
||||
<para>The <literal>-ro</literal> flag makes the file systems
|
||||
read-only, preventing clients from making any changes to
|
||||
those exported file systems.</para>
|
||||
|
||||
<para>The next example exports
|
||||
<filename class="directory">/home</filename> to three clients
|
||||
by IP address. This can be useful for networks without
|
||||
<acronym>DNS</acronym>. Optionally,
|
||||
<filename>/etc/hosts</filename> could be configured for
|
||||
internal hostnames; please review &man.hosts.5; for more
|
||||
information. The <literal>-alldirs</literal> flag allows
|
||||
subdirectories to be mount points. In other words, it will
|
||||
not mount the subdirectories but permit the client to mount
|
||||
only the directories that are required or needed.</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> so that
|
||||
two clients from different domains may access the file system.
|
||||
<para>This next line exports
|
||||
<filename class="directory">/a</filename> so that two clients
|
||||
from different domains may access the file system.
|
||||
The <option>-maproot=root</option> flag allows the
|
||||
<username>root</username> user on the remote system to write
|
||||
data on the exported file system as <username>root</username>.
|
||||
If the <literal>-maproot=root</literal> flag is not specified,
|
||||
then even if a user has <username>root</username> access on
|
||||
the remote system, he will not be able to modify files on
|
||||
the exported file system.</para>
|
||||
the client's <username>root</username> user will be mapped
|
||||
to the server's <username>nobody</username> account and will
|
||||
be subject to the access limitations defined for user,
|
||||
<username>nobody</username>.</para>
|
||||
|
||||
<programlisting>/a -maproot=root host.example.com box.example.org</programlisting>
|
||||
|
||||
<para>In order for a client to access an exported file system,
|
||||
the client must have permission to do so. Make sure the
|
||||
client is listed in <filename>/etc/exports</filename>.</para>
|
||||
<para>For a client to have access to an exported file system,
|
||||
the client must be listed in
|
||||
<filename>/etc/exports</filename>.</para>
|
||||
|
||||
<para>In <filename>/etc/exports</filename>, each line represents
|
||||
the export information for one file system to one host. A
|
||||
remote host can only be specified once per file system, and
|
||||
may only have one default entry. For example, assume that
|
||||
<filename>/usr</filename> is a single file system. The
|
||||
following <filename>/etc/exports</filename> would be
|
||||
invalid:</para>
|
||||
<para>In <filename>/etc/exports</filename>, each line defines
|
||||
the export information for one file system to one or more
|
||||
clients. A remote host can only be specified once per file
|
||||
system. For example, assume that
|
||||
<filename class="directory">/usr</filename> is a single file
|
||||
system. This entry, in <filename>/etc/exports</filename>,
|
||||
would be invalid:</para>
|
||||
|
||||
<programlisting># Invalid when /usr is one file system
|
||||
/usr/src client
|
||||
/usr/ports client</programlisting>
|
||||
|
||||
<para>One file system, <filename>/usr</filename>, has two lines
|
||||
<para>The <filename class="directory">/usr</filename> file
|
||||
system has two lines
|
||||
specifying exports to the same host, <hostid>client</hostid>.
|
||||
The correct format for this situation is:</para>
|
||||
|
||||
<programlisting>/usr/src /usr/ports client</programlisting>
|
||||
|
||||
<para>The properties of one file system exported to a given host
|
||||
must all occur on one line. Lines without a client specified
|
||||
are treated as a single host. This limits how file systems
|
||||
may be exported; however, for most environments, this is not
|
||||
an issue.</para>
|
||||
<para>The exported file system, its properties, and allowed
|
||||
hosts must occur on a single line. If no clients are listed,
|
||||
then any client on the network may mount the exported file
|
||||
system.</para>
|
||||
|
||||
<para>The following is an example of a valid export list, where
|
||||
<filename>/usr</filename> and <filename>/exports</filename>
|
||||
are local file systems:</para>
|
||||
<filename class="directory">/usr</filename> and
|
||||
<filename class="directory">/exports</filename> are local
|
||||
file systems:</para>
|
||||
|
||||
<programlisting># Export src and ports to client01 and client02, but only
|
||||
# client01 has root privileges on it
|
||||
|
|
@ -793,24 +790,20 @@ mountd_flags="-r"</programlisting>
|
|||
/exports -alldirs -maproot=root client01 client02
|
||||
/exports/obj -ro</programlisting>
|
||||
|
||||
<para>The <application>mountd</application> daemon must be
|
||||
forced to recheck the <filename>/etc/exports</filename> file
|
||||
whenever it has been modified, so the changes can take effect.
|
||||
This can be accomplished either by sending a HUP signal to the
|
||||
running daemon:</para>
|
||||
<para>The <application>mountd</application> daemon reads
|
||||
<filename>/etc/exports</filename> when started. To make
|
||||
<acronym>NFS</acronym> server changes take effect immediately,
|
||||
force <application>mountd</application> to reread
|
||||
<filename>/etc/exports</filename>:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>kill -HUP `cat /var/run/mountd.pid`</userinput></screen>
|
||||
|
||||
<para>or by invoking the <command>mountd</command> &man.rc.8;
|
||||
script with the appropriate parameter:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>service mountd onereload</userinput></screen>
|
||||
<screen>&prompt.root; <userinput>service mountd reload</userinput></screen>
|
||||
|
||||
<para>Please refer to <xref linkend="configtuning-rcd"/> for
|
||||
more information about using rc scripts.</para>
|
||||
|
||||
<para>NFS services can now be started by running the following
|
||||
command, on the <acronym>NFS</acronym> server, as
|
||||
<para>On a new server being configured with
|
||||
<acronym>NFS</acronym> services, the server can be
|
||||
started by running this command as
|
||||
<username>root</username>:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>service nfsd start</userinput></screen>
|
||||
|
|
@ -819,12 +812,13 @@ mountd_flags="-r"</programlisting>
|
|||
|
||||
<screen>&prompt.root; <userinput>service nfsclient restart</userinput></screen>
|
||||
|
||||
<para>Now everything should be ready to actually mount a remote
|
||||
file system. In these examples the server's name will be
|
||||
<hostid>server</hostid> and the client's name will be
|
||||
<para>The client now has everything it needs to mount a remote
|
||||
file system. In these examples, the server's name is
|
||||
<hostid>server</hostid> and the client's name is
|
||||
<hostid>client</hostid>. For testing or to temporarily mount
|
||||
a remote file system execute a command like this as
|
||||
<username>root</username> on the client:</para>
|
||||
a remote file system, execute
|
||||
<application>mount</application> as
|
||||
<username>root</username> on <hostid>client</hostid>:</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>NFS</primary>
|
||||
|
|
@ -832,16 +826,20 @@ mountd_flags="-r"</programlisting>
|
|||
</indexterm>
|
||||
<screen>&prompt.root; <userinput>mount server:/home /mnt</userinput></screen>
|
||||
|
||||
<para>This will mount the <filename>/home</filename> directory
|
||||
on the server at <filename>/mnt</filename> on the client. If
|
||||
everything is set up correctly, the server's files should be
|
||||
visible and available in the <filename>/mnt</filename>
|
||||
directory.</para>
|
||||
<para>This mounts the
|
||||
<hostid>server</hostid>:
|
||||
<filename class="directory">/home</filename>
|
||||
file system to the
|
||||
<hostid>client</hostid>:
|
||||
<filename class="directory">/mnt</filename> mount
|
||||
point. The files and directories in the
|
||||
<hostid>server</hostid>
|
||||
<filename class="directory">/home</filename> file system will
|
||||
now be available on <hostid>client</hostid>, in the
|
||||
<filename class="directory">/mnt</filename> directory.</para>
|
||||
|
||||
<para>To permanently mount a remote file system each time the
|
||||
computer boots, add the file system to the
|
||||
<filename>/etc/fstab</filename> file. Here is an
|
||||
example:</para>
|
||||
<para>To mount a remote file system each time the client
|
||||
boots, add it to <filename>/etc/fstab</filename>:</para>
|
||||
|
||||
<programlisting>server:/home /mnt nfs rw 0 0</programlisting>
|
||||
|
||||
|
|
@ -855,32 +853,35 @@ mountd_flags="-r"</programlisting>
|
|||
<para>Some applications (e.g., <application>mutt</application>)
|
||||
require file locking to operate correctly. In the case of
|
||||
<acronym>NFS</acronym>, <application>rpc.lockd</application>
|
||||
can be used for file locking. To enable it, add the following
|
||||
to the <filename>/etc/rc.conf</filename> file on both client
|
||||
and server (it is assumed that the <acronym>NFS</acronym>
|
||||
client and server are configured already):</para>
|
||||
can be used for file locking. To enable it, add this line to
|
||||
<filename>/etc/rc.conf</filename> on both client
|
||||
and server:</para>
|
||||
|
||||
<programlisting>rpc_lockd_enable="YES"
|
||||
rpc_statd_enable="YES"</programlisting>
|
||||
|
||||
<para>Start the application by using:</para>
|
||||
<para>Please note that this assumes that both
|
||||
<acronym>NFS</acronym> client and server are already
|
||||
configured.</para>
|
||||
|
||||
<para>Start the application, as
|
||||
<username>root</username>, with:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>service lockd start</userinput>
|
||||
&prompt.root; <userinput>service statd start</userinput></screen>
|
||||
|
||||
<para>If real locking between the <acronym>NFS</acronym> clients
|
||||
and <acronym>NFS</acronym> server is not required, it is
|
||||
possible to let the <acronym>NFS</acronym> client do locking
|
||||
locally by passing <option>-L</option> to &man.mount.nfs.8;.
|
||||
Refer to the &man.mount.nfs.8; manual page for further
|
||||
details.</para>
|
||||
<para>If locking is not required on the server, the
|
||||
<acronym>NFS</acronym> client can be configured to
|
||||
lock locally by passing <option>-L</option> to
|
||||
&man.mount.nfs.8;. Refer to the &man.mount.nfs.8;
|
||||
manual page for further details.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Practical Uses</title>
|
||||
|
||||
<para><acronym>NFS</acronym> has many practical uses. Some of
|
||||
the more common ones are listed below:</para>
|
||||
the more common uses:</para>
|
||||
|
||||
<indexterm>
|
||||
<primary>NFS</primary>
|
||||
|
|
@ -888,25 +889,26 @@ rpc_statd_enable="YES"</programlisting>
|
|||
</indexterm>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Set several machines to share a CDROM or other media
|
||||
among them. This is cheaper and often a more convenient
|
||||
method to install software on multiple machines.</para>
|
||||
<para>Share a <acronym>CD-ROM</acronym> or other media
|
||||
with any number of clients. It is often more
|
||||
convenient to install software on multiple
|
||||
machines from a single location.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>On large networks, it might be more convenient to
|
||||
configure a central <acronym>NFS</acronym> 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.</para>
|
||||
<para>On large networks, it is often more convenient to
|
||||
configure a central <acronym>NFS</acronym> server on which
|
||||
all user home directories are stored. Users can log into
|
||||
a client anywhere on the network and have access to their
|
||||
home directories.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Several machines could have a common
|
||||
<filename>/usr/ports/distfiles</filename> directory. This
|
||||
allows for quick access to the source files without
|
||||
downloading them on each machine.</para>
|
||||
<para>Several clients may need access to the
|
||||
<filename class="directory">/usr/ports/distfiles</filename>
|
||||
directory. Sharing that directory allows for quick access
|
||||
to the source files without having to download them to
|
||||
each client.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
|
|
@ -940,34 +942,37 @@ rpc_statd_enable="YES"</programlisting>
|
|||
mounts a remote file system whenever a file or directory
|
||||
within that file system is accessed. Filesystems that are
|
||||
inactive for a period of time will also be automatically
|
||||
unmounted by <application>amd</application>. Using
|
||||
<application>amd</application> provides a simple alternative
|
||||
to permanent mounts, as permanent mounts are usually listed in
|
||||
<filename>/etc/fstab</filename>.</para>
|
||||
unmounted by <application>amd</application>.
|
||||
<application>amd</application> provides an alternative to
|
||||
modifying <filename>/etc/fstab</filename> to list every
|
||||
client.</para>
|
||||
|
||||
<para><application>amd</application> operates by attaching
|
||||
itself as an NFS server to the <filename>/host</filename> and
|
||||
<filename>/net</filename> directories. When a file is
|
||||
itself as an NFS server to the
|
||||
<filename class="directory">/host</filename>
|
||||
and <filename class="directory">/net</filename> directories. When a file is
|
||||
accessed within one of these directories,
|
||||
<application>amd</application> looks up the corresponding
|
||||
remote mount and automatically mounts it.
|
||||
<filename>/net</filename> is used to mount an exported file
|
||||
system from an IP address, while <filename>/host</filename> is
|
||||
<filename class="directory">/net</filename> is used to mount an exported file
|
||||
system from an IP address, while
|
||||
<filename class="directory">/host</filename> is
|
||||
used to mount an export from a remote hostname.</para>
|
||||
|
||||
<para>An access to a file within
|
||||
<filename>/host/foobar/usr</filename> would tell
|
||||
<application>amd</application> to attempt to mount the
|
||||
<filename>/usr</filename> export on the host
|
||||
<para>For instance, an attempt to access a file within
|
||||
<filename class="directory">/host/foobar/usr</filename> would tell
|
||||
<application>amd</application> to mount the
|
||||
<filename class="directory">/usr</filename> export on the host
|
||||
<hostid>foobar</hostid>.</para>
|
||||
|
||||
<example>
|
||||
<title>Mounting an Export with
|
||||
<application>amd</application></title>
|
||||
|
||||
<para>The <command>showmount</command> command shows the
|
||||
available mounts on a remote host. For example, to view the
|
||||
mounts of a host named <hostid>foobar</hostid>:</para>
|
||||
<para><command>showmount -e</command> shows the
|
||||
exported file systems that can be mounted from
|
||||
the <acronym>NFS</acronym> server,
|
||||
<hostid>foobar</hostid>:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>showmount -e foobar</userinput>
|
||||
Exports list on foobar:
|
||||
|
|
@ -976,155 +981,39 @@ Exports list on foobar:
|
|||
&prompt.user; <userinput>cd /host/foobar/usr</userinput></screen>
|
||||
</example>
|
||||
|
||||
<para>As seen in the example, the <command>showmount</command>
|
||||
shows <filename>/usr</filename> as an export. When changing
|
||||
directories to <filename>/host/foobar/usr</filename>,
|
||||
<application>amd</application> attempts to resolve the
|
||||
hostname <hostid>foobar</hostid> and automatically mount the
|
||||
desired export.</para>
|
||||
<para>The output from <command>showmount</command>
|
||||
shows <filename class="directory">/usr</filename> as an
|
||||
export. When changing directories to
|
||||
<filename class="directory">/host/foobar/usr</filename>,
|
||||
<application>amd</application> intercepts the request and
|
||||
attempts to resolve the hostname <hostid>foobar</hostid>.
|
||||
If successful, <application>amd</application> automatically
|
||||
mounts the desired export.</para>
|
||||
|
||||
<para><application>amd</application> can be started by the
|
||||
startup scripts by placing the following lines in
|
||||
<filename>/etc/rc.conf</filename>:</para>
|
||||
<para><application>amd</application> is enabled by placing
|
||||
this line in <filename>/etc/rc.conf</filename>:</para>
|
||||
|
||||
<programlisting>amd_enable="YES"</programlisting>
|
||||
|
||||
<para>Additionally, custom flags can be passed to
|
||||
<para>It can then be started using the &os; &man.rc.8; scripts
|
||||
or by using the &man.service.8; command.</para>
|
||||
|
||||
<para>Custom flags can be passed to
|
||||
<application>amd</application> from the
|
||||
<varname>amd_flags</varname> option. By default,
|
||||
<varname>amd_flags</varname> is set to:</para>
|
||||
<varname>amd_flags</varname> environment variable. By
|
||||
default, <varname>amd_flags</varname> is set to:</para>
|
||||
|
||||
<programlisting>amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map"</programlisting>
|
||||
|
||||
<para>The <filename>/etc/amd.map</filename> file defines the
|
||||
default options that exports are mounted with. The
|
||||
<filename>/etc/amd.conf</filename> file defines some of the
|
||||
<para><filename>/etc/amd.map</filename> defines the
|
||||
default options with which exports are mounted.
|
||||
<filename>/etc/amd.conf</filename> defines some of the
|
||||
more advanced features of
|
||||
<application>amd</application>.</para>
|
||||
|
||||
<para>Consult the &man.amd.8; and &man.amd.conf.5; manual pages
|
||||
for more information.</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="network-nfs-integration">
|
||||
<sect2info>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>John</firstname>
|
||||
<surname>Lind</surname>
|
||||
<contrib>Contributed by </contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
</sect2info>
|
||||
<title>Problems Integrating with Other Systems</title>
|
||||
|
||||
<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 <quote>correct</quote> 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
|
||||
&man.mount.8; 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 the routers are routing the
|
||||
necessary <acronym>UDP</acronym> information.</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
|
||||
file system (see &man.exports.5;), 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 the application.</para>
|
||||
|
||||
<para>Examples for the FreeBSD system (<hostid>freebox</hostid>)
|
||||
as the client in <filename>/etc/fstab</filename> on
|
||||
<hostid>freebox</hostid>:</para>
|
||||
|
||||
<programlisting>fastws:/sharedfs /project nfs rw,-r=1024 0 0</programlisting>
|
||||
|
||||
<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>
|
||||
|
||||
<para>Examples for the FreeBSD system as the server in
|
||||
<filename>/etc/fstab</filename> on
|
||||
<hostid>fastws</hostid>:</para>
|
||||
|
||||
<programlisting>freebox:/sharedfs /project nfs rw,-w=1024 0 0</programlisting>
|
||||
|
||||
<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>
|
||||
|
||||
<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 <quote>block</quote> size of
|
||||
8 K (though it may do fragments of smaller sizes). Since
|
||||
the maximum Ethernet packet is around 1500 bytes, the NFS
|
||||
<quote>block</quote> 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 8 K
|
||||
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>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
|
||||
<quote>units</quote>. 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="network-nis">
|
||||
|
|
|
|||
Loading…
Reference in a new issue