mirror of
https://git.FreeBSD.org/ports.git
synced 2024-11-05 22:43:24 +00:00
7d63b5b8d6
PR: 14898 Submitted by: KATO Tsuguru <tkato@prontomail.ne.jp>
841 lines
34 KiB
Plaintext
841 lines
34 KiB
Plaintext
--- NFS-HOWTO.sgml.orig Thu Nov 18 06:51:14 1999
|
|
+++ NFS-HOWTO.sgml Thu Nov 18 06:52:16 1999
|
|
@@ -79,7 +79,7 @@
|
|
networking and the terms used. If you don't recognize the terms you
|
|
can either go back and check the networking HOWTO, wing it, or get a
|
|
book about TCP/IP network administration to familiarize yourself with
|
|
-TCP/IP. That's a good idea anyway if you're administrating UNIX/Linux
|
|
+TCP/IP. That's a good idea anyway if you're administrating UNIX
|
|
machines. A very good book on the subject is <em>TCP/IP Network
|
|
Administration</em> by Craig Hunt, published by O'Reilly &
|
|
Associates, Inc. And after you've read it and understood it you'll
|
|
@@ -89,14 +89,6 @@
|
|
<em/Mount Checklist/ and <em/FAQs/. Please refer to them if something
|
|
dosen't work as advertized.
|
|
|
|
-<p>The home-site for the Linux 2.0 nfsd is <htmlurl
|
|
-name="ftp.mathematik.th-darmstadt.de:/pub/linux/okir"
|
|
-url="ftp://ftp.mathematik.th-darmstadt.de/pub/linux/okir/">, in case
|
|
-you want/need to get it and compile it yourself.
|
|
-
|
|
-<p>For information about NFS under Linux 2.2 please see <ref
|
|
-id="linuxtwotwo" name="the Linux 2.2 section">.
|
|
-
|
|
<sect>Setting up a NFS server<label id="nfs-server">
|
|
|
|
<sect1>Prerequisites
|
|
@@ -116,7 +108,7 @@
|
|
skip ahead to <ref id="nfs-client" name="the section on setting up a
|
|
NFS client">
|
|
|
|
-<p>If you need to set up a non-Linux box as server you will have to
|
|
+<p>If you need to set up a non-FreeBSD box as server you will have to
|
|
read the system manual(s) to discover how to enable NFS serving and
|
|
export of file systems through NFS. There is a separate section in
|
|
this HOWTO on how to do it on many different systems. After you have
|
|
@@ -124,16 +116,13 @@
|
|
HOWTO. Or read more of this section since some of the things I will
|
|
say are relevant no matter what kind of machine you use as server.
|
|
|
|
-<p>If you're running please see <ref id="linuxtwotwo" name="the Linux
|
|
-2.2 section"> before you continue reading this.
|
|
-
|
|
<p>Those of you still reading will need to set up a number of
|
|
programs.
|
|
|
|
<sect1>The portmapper<label id="portmapper">
|
|
|
|
-<p>The portmapper on Linux is called either <tt/portmap/ or
|
|
-<tt/rpc.portmap/. The man page on my system says it is a "DARPA port
|
|
+<p>The portmapper on FreeBSD is called <tt/portmap/.
|
|
+The man page on my system says it is a "DARPA port
|
|
to RPC program number mapper". It is the first security hole you'll
|
|
open reading this HOWTO. Description of how to close one of the holes
|
|
is in <ref id="nfs-security" name="the security section">. Which I,
|
|
@@ -149,14 +138,7 @@
|
|
If there is a script called something like <tt/inet/ it's probably the
|
|
right script to edit. But, what to write or do is outside the scope
|
|
of this HOWTO. Start portmap, and check that it lives by running
|
|
-<tt/ps aux/ and then <tt/rpcinfo -p/. It does? Good.
|
|
-
|
|
-<p>Oh, one thing. Remote access to your portmapper is regulated by
|
|
-the contents of your <tt>/etc/hosts.allow</tt> and
|
|
-<tt>/etc/hosts.deny</tt> files. If <tt/rpcinfo -p/ fails, but your
|
|
-portmapper is running please examine these files. See <ref
|
|
-id="nfs-security" name="the security section"> for details on these
|
|
-files.
|
|
+<tt/ps aux/. It does? Good.
|
|
|
|
<sect1>Mountd and nfsd<label id="nfsd">
|
|
|
|
@@ -187,24 +169,23 @@
|
|
use./ There is a separate section in this HOWTO about other Unixes
|
|
<tt/exports/ files.
|
|
|
|
-<p>Now we're set to start mountd (or maybe it's called <tt/rpc.mountd/
|
|
-and then nfsd (which could be called <tt/rpc.nfsd/). They will both
|
|
+<p>Now we're set to start mountd
|
|
+and then nfsd. They will both
|
|
read the exports file.
|
|
|
|
<p>If you edit <tt>/etc/exports</tt> you will have to make sure nfsd
|
|
and mountd knows that the files have changed. The traditonal way is
|
|
-to run <tt/exportfs/. Many Linux distributions lack a exportfs
|
|
-program. If you're exportfs-less you can install this script on your
|
|
+to run <tt/exportfs/. FreeBSD lacks a exportfs
|
|
+program. You can install this script on your
|
|
machine:
|
|
|
|
<code>
|
|
#!/bin/sh
|
|
-killall -HUP /usr/sbin/rpc.mountd
|
|
-killall -HUP /usr/sbin/rpc.nfsd
|
|
+/bin/kill -HUP `/bin/cat /var/run/mountd.pid`
|
|
echo re-exported file systems
|
|
</code>
|
|
|
|
-<p>Save it in, say, <tt>/usr/sbin/exportfs</tt>, and don't forget to
|
|
+<p>Save it in, say, <tt>/usr/local/sbin/exportfs</tt>, and don't forget to
|
|
<tt/chmod a+rx/ it. Now, whenever you change your exports file, you
|
|
run exportfs after, as root.
|
|
|
|
@@ -225,12 +206,8 @@
|
|
mountd and nfsd.
|
|
|
|
<p>If you get <tt>rpcinfo: can't contact portmapper: RPC: Remote
|
|
-system error - Connection refused</tt>,
|
|
-<tt>RPC_PROG_NOT_REGISTERED</tt> or something similar instead then the
|
|
-portmapper isn't running. OR you might have something in
|
|
-<tt>/etc/hosts.{allow,deny}</tt> that forbids the portmapper from
|
|
-answering, please see <ref id="nfs-security" name="the security
|
|
-section"> for details on these files. If you get <tt>No remote
|
|
+system error - Connection refused</tt> or something similar instead
|
|
+then the portmapper isn't running. Fix it. If you get <tt>No remote
|
|
programs registered.</tt> then either the portmapper doesn't want to
|
|
talk to you, or something is broken. Kill nfsd, mountd, and the
|
|
portmapper and try the ignition sequence again.
|
|
@@ -255,12 +232,8 @@
|
|
<sect>Setting up a NFS client<label id="nfs-client">
|
|
|
|
<p>First you will need a kernel with the NFS file system either
|
|
-compiled in or available as a module. This is configured before you
|
|
-compile the kernel. If you have never compiled a kernel before you
|
|
-might need to check the kernel HOWTO and figure it out. If you're
|
|
-using a very cool distribution (like Red Hat) and you've never fiddled
|
|
-with the kernel or modules on it (and thus ruined it ;-), nfs is
|
|
-likely automagicaly available to you.
|
|
+compiled in or available as a module. This is configured in the GENERIC
|
|
+FreeBSD kernel for you.
|
|
|
|
<p>You can now, at a root prompt, enter a appropriate mount command
|
|
and the file system will appear. Continuing the example in the
|
|
@@ -280,8 +253,7 @@
|
|
by server: Permission denied</tt> then the exports file is wrong, or
|
|
you forgot to run exportfs after editing the exports file. If it says
|
|
<tt>mount clntudp_create: RPC: Program not registered</tt> it means
|
|
-that nfsd or mountd is not running on the server. Or you have the
|
|
-<tt/hosts.{allow,deny}/ problem mentioned earlier.
|
|
+that nfsd or mountd is not running on the server.
|
|
|
|
<p>To get rid of the file system you can say
|
|
|
|
@@ -294,7 +266,7 @@
|
|
as this is required:
|
|
|
|
<code>
|
|
-# device mountpoint fs-type options dump fsckorder
|
|
+# Device Mountpoint FStype Options Dump Pass#
|
|
...
|
|
eris:/mn/eris/local /mnt nfs rsize=1024,wsize=1024 0 0
|
|
...
|
|
@@ -332,7 +304,7 @@
|
|
<p>Picking up the previous example, this is now your fstab entry:
|
|
|
|
<code>
|
|
-# device mountpoint fs-type options dump fsckorder
|
|
+# Device Mountpoint FStype Options Dump Pass#
|
|
...
|
|
eris:/mn/eris/local /mnt nfs rsize=1024,wsize=1024,hard,intr 0 0
|
|
...
|
|
@@ -342,8 +314,8 @@
|
|
<sect1>Optimizing NFS<label id="optimizing">
|
|
|
|
<p>Normally, if no rsize and wsize options are specified NFS will read
|
|
-and write in chunks of 4096 or 8192 bytes. Some combinations of Linux
|
|
-kernels and network cards cannot handle that large blocks, and it
|
|
+and write in chunks of 4096 or 8192 bytes. Some
|
|
+network cards cannot handle that large blocks, and it
|
|
might not be optimal, anyway. So we'll want to experiment and find a
|
|
rsize and wsize that works and is as fast as possible. You can test
|
|
the speed of your options with some simple commands. Given the mount
|
|
@@ -379,7 +351,7 @@
|
|
have different optimal sizes. SunOS and Solaris is reputedly a lot
|
|
faster with 4096 byte blocks than with anything else.
|
|
|
|
-<p>Newer Linux kernels (since 1.3 sometime) perform read-ahead for
|
|
+<p>Newer FreeBSD kernels (since 3.0) perform read-ahead for
|
|
rsizes larger or equal to the machine page size. On Intel CPUs the
|
|
page size is 4096 bytes. Read ahead will <em/significantly/ increase
|
|
the NFS read performance. So on a Intel machine you will want 4096
|
|
@@ -393,13 +365,13 @@
|
|
requests shall not be considered finished before the data written is
|
|
on a non-volatile medium (normally the disk). This restricts the
|
|
write performance somewhat, asynchronous writes will speed NFS writes
|
|
-up. The Linux nfsd has never done synchronous writes since the Linux
|
|
+up. The FreeBSD nfsd has never done synchronous writes since the FreeBSD
|
|
file system implementation does not lend itself to this, but on
|
|
-non-Linux servers you can increase the performance this way with this
|
|
+non-FreeBSD servers you can increase the performance this way with this
|
|
in your exports file:
|
|
|
|
<code>
|
|
-/dir -async,access=linuxbox
|
|
+/dir -async,access=freebsdbox
|
|
</code>
|
|
|
|
<p>or something similar. Please refer to the exports man page on the
|
|
@@ -413,7 +385,9 @@
|
|
distance connections.
|
|
|
|
<p>This section is based on knowledge about the used protocols but no
|
|
-actual experiments. Please let me hear from you if try this ;-)
|
|
+actual experiments. My home computer has been down for 6 months (bad
|
|
+HD, low on cash) and so I have had no modem connection to test this
|
|
+with. Please let me hear from you if try this :-)
|
|
|
|
<p>The first thing to remember is that NFS is a slow protocol. It has
|
|
high overhead. Using NFS is almost like using kermit to transfer
|
|
@@ -623,10 +597,10 @@
|
|
servers root account. In the NFSd man page there are several other
|
|
squash options listed so that you can decide to mistrust whomever you
|
|
(don't) like on the clients. You also have options to squash any UID
|
|
-and GID range you want to. This is described in the Linux NFSd man
|
|
+and GID range you want to. This is described in the FreeBSD NFSd man
|
|
page.
|
|
|
|
-<p>root_squash is in fact the default with the Linux NFSd, to grant
|
|
+<p>root_squash is in fact the default with the FreeBSD NFSd, to grant
|
|
root access to a filesystem use <tt/no_root_squash/.
|
|
|
|
<p>Another important thing is to ensure that nfsd checks that all it's
|
|
@@ -634,7 +608,7 @@
|
|
any old port on the client a user with no special privileges can run a
|
|
program that's is easy to obtain over the Internet. It talks nfs
|
|
protocol and will claim that the user is anyone the user wants to be.
|
|
-Spooky. The Linux nfsd does this check by default, on other OSes you
|
|
+Spooky. The FreeBSD nfsd does this check by default, on other OSes you
|
|
have to enable this check yourself. This should be described in the
|
|
nfsd man page for the OS.
|
|
|
|
@@ -645,98 +619,9 @@
|
|
|
|
<p>The basic portmapper, in combination with nfsd has a design problem
|
|
that makes it possible to get to files on NFS servers without any
|
|
-privileges. Fortunately the portmapper that most Linux distributions
|
|
-use is relatively secure against this attack, and can be made more
|
|
-secure by configuring up access lists in two files.
|
|
-
|
|
-<p>Not all Linux distributions were created equal. Some seemingly
|
|
-up-to-date distributions does <em/not/ include a securable portmapper,
|
|
-even today, many years since the vulnerability became common
|
|
-knowledge. At least one distribution even contains the manpage for a
|
|
-securable portmapper but the actual portmapper is <em>not</em>
|
|
-secureable. The easy way to check if your portmapper is good
|
|
-or not is to run strings(1) and see if it reads the relevant files,
|
|
-<tt>/etc/hosts.deny</tt> and <tt>/etc/hosts.allow</tt>. Assuming your
|
|
-portmapper is <tt>/usr/sbin/portmap</tt> you can check it with this
|
|
-command: <tt>strings /usr/sbin/portmap | grep hosts</tt>. On my
|
|
-machine it comes up with this:
|
|
-
|
|
-<code>
|
|
-/etc/hosts.allow
|
|
-/etc/hosts.deny
|
|
-@(#) hosts_ctl.c 1.4 94/12/28 17:42:27
|
|
-@(#) hosts_access.c 1.20 96/02/11 17:01:27
|
|
-</code>
|
|
-
|
|
-<p>First we edit <tt>/etc/hosts.deny</tt>. It should contain the line
|
|
-
|
|
-<code>
|
|
-portmap: ALL
|
|
-</code>
|
|
-
|
|
-which will deny access to <em/everyone/. While it is closed thus run
|
|
-<tt>rpcinfo -p</tt> just to check that your portmapper really reads
|
|
-and obeys this file. rpcinfo should give no output, or possebly a
|
|
-errormessage. Restarting the portmapper should <em>not</em> be
|
|
-necessary.
|
|
-
|
|
-<p>Closing the portmapper for everyone is a bit drastic, so we open it
|
|
-again by editing <tt>/etc/hosts.allow</tt>. But first we need to
|
|
-figure out what to put in it. It should basically list all machines
|
|
-that should have access to your portmapper. On a run of the mill
|
|
-Linux system there are very few machines that need any access for any
|
|
-reason. The portmapper administrates nfsd, mountd, ypbind/ypserv,
|
|
-pcnfsd, and 'r' services like ruptime and rusers. Of these only nfsd,
|
|
-mountd, ypbind/ypserv and perhaps pcnfsd are of any consequence. All
|
|
-machines that needs to access services on your machine should be
|
|
-allowed to do that. Let's say that your machines address is
|
|
-129.240.223.254 and that it lives on the subnet 129.240.223.0 should
|
|
-have access to it (those are terms introduced by the networking HOWTO,
|
|
-go back and refresh your memory if you need to). Then we write
|
|
-
|
|
-<code>
|
|
-portmap: 129.240.223.0/255.255.255.0
|
|
-</code>
|
|
-
|
|
-in <tt/hosts.allow/. This is the same as the network address you give
|
|
-to route and the subnet mask you give to ifconfig. For the device
|
|
-<tt/eth0/ on this machine <tt/ifconfig/ should show
|
|
-
|
|
-<code>
|
|
-...
|
|
-eth0 Link encap:10Mbps Ethernet HWaddr 00:60:8C:96:D5:56
|
|
- inet addr:129.240.223.254 Bcast:129.240.223.255 Mask:255.255.255.0
|
|
- UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
|
|
- RX packets:360315 errors:0 dropped:0 overruns:0
|
|
- TX packets:179274 errors:0 dropped:0 overruns:0
|
|
- Interrupt:10 Base address:0x320
|
|
-...
|
|
-</code>
|
|
+privileges. Fortunately the portmapper FreeBSD uses is relatively
|
|
+secure against this attack.
|
|
|
|
-and <tt/netstat -rn/ should show
|
|
-
|
|
-<code>
|
|
-Kernel routing table
|
|
-Destination Gateway Genmask Flags Metric Ref Use Iface
|
|
-...
|
|
-129.240.223.0 0.0.0.0 255.255.255.0 U 0 0 174412 eth0
|
|
-...
|
|
-</code>
|
|
-
|
|
-(Network address in first column).
|
|
-
|
|
-The <tt/hosts.deny/ and <tt/hosts.allow/ files are described in the
|
|
-manual pages of the same names.
|
|
-
|
|
-<p><bf/IMPORTANT:/ Do <em/not/ put <em/anything/ but <em/IP NUMBERS/ in
|
|
-the portmap lines of these files. Host name lookups can indirectly
|
|
-cause portmap activity which will trigger host name lookups which can
|
|
-indirectly cause portmap activity which will trigger...
|
|
-
|
|
-<p>The above things should make your server tighter. The only
|
|
-remaining problem (Yeah, right!) is someone breaking root (or boot
|
|
-MS-DOS) on a trusted machine and using that privilege to send requests
|
|
-from a secure port as any user they want to be.
|
|
|
|
<sect1>NFS and firewalls<label id="security-firewalls">
|
|
|
|
@@ -752,13 +637,13 @@
|
|
|
|
<sect1>Summary<label id="security-summary">
|
|
|
|
-<p>If you use the hosts.allow/deny, root_squash, nosuid and privileged
|
|
+<p>If you use the nosuid and privileged
|
|
port features in the portmapper/nfs software you avoid many of the
|
|
presently known bugs in nfs and can almost feel secure about <em/that/
|
|
at least. But still, after all that: When an intruder has access to
|
|
your network, s/he can make strange commands appear in your
|
|
<tt/.forward/ or read your mail when <tt>/home</tt> or
|
|
-<tt>/var/spool/mail</tt> is NFS exported. For the same reason,
|
|
+<tt>/var/mail</tt> is NFS exported. For the same reason,
|
|
you should never access your PGP private key over nfs. Or at least
|
|
you should know the risk involved. And now you know a bit of it.
|
|
|
|
@@ -766,10 +651,10 @@
|
|
it's not totally unlikely that new bugs will be discovered, either in
|
|
the basic design or the implementation we use. There might even be
|
|
holes known now, which someone is abusing. But that's life. To keep
|
|
-abreast of things like this you should at least read the newsgroups
|
|
-<htmlurl url="news:comp.os.linux.announce"
|
|
-name="comp.os.linux.announce"> and <htmlurl
|
|
-url="news:comp.security.announce" name="comp.security.announce"> at a
|
|
+abreast of things like this you should at least read the mailing lists
|
|
+<htmlurl url="mailto:freebsd-security@FreeBSD.org"
|
|
+name="freebsd-security@FreeBSD.org">
|
|
+at a
|
|
absolute minimum.
|
|
|
|
<sect>Mount Checklist
|
|
@@ -780,18 +665,7 @@
|
|
refer to this list before posting your problem. Each item describes a
|
|
failure mode and the fix.
|
|
|
|
-<enum>Mount keeps saying <tt/RPC: Program not registered/
|
|
-
|
|
-<p>Is the portmapper running?
|
|
-<p><bf/Fix:/ Start it.
|
|
-<p>Is mountd running?
|
|
-<p><bf/Fix:/ Start it.
|
|
-<p>Is nfsd running?
|
|
-<p><bf/Fix:/ Start it.
|
|
-<p>Is the portmapper forbidden to answer by <tt>/etc/hosts.deny</tt>?
|
|
-<p><bf/Fix:/ Either remove the rule in <tt/hosts.deny/ or add a rule
|
|
- to <tt/hosts.allow/ such that the portmapper is allowed to talk to
|
|
- you.
|
|
+<enum>
|
|
|
|
<item>File system not exported, or not exported to the client in
|
|
question.
|
|
@@ -832,10 +706,7 @@
|
|
|
|
<p><bf/Fix:/ Get the date set right.
|
|
|
|
-<p>The HOWTO author recommends using NTP to synchronize clocks. Since
|
|
-there are export restrictions on NTP in the US you have to get NTP for
|
|
-Debian, Red Hat or Slackware from
|
|
-<tt>ftp://ftp.hacktic.nl/pub/replay/pub/linux</tt> or a mirror.
|
|
+<p>The HOWTO author recommends using NTP to synchronize clocks.
|
|
|
|
<item>The server can not accept a mount from a user that is in more
|
|
than 8 groups.
|
|
@@ -845,153 +716,10 @@
|
|
|
|
</enum>
|
|
|
|
-<sect>FAQs
|
|
-
|
|
-<p>This is the FAQ section. It is partly based on a old NFS FAQ by
|
|
-Alan Cox.
|
|
-
|
|
-<p>If you have a problem mounting a filesystem please see if your
|
|
-problem is described in the ``Mount Checklist'' section.
|
|
-
|
|
-<enum>
|
|
-
|
|
- <item>I get a lot of ``stale nfs handle'' errors when using Linux as
|
|
- a nfs server.
|
|
-
|
|
- <p>This is caused by a bug in some old nfsd versions. It is fixed
|
|
- in nfs-server2.2beta16 and later.
|
|
-
|
|
- <item>When I try to mount a file system I get
|
|
-
|
|
- <tscreen><verb>
|
|
- can't register with portmap: system error on send
|
|
- </verb></tscreen>
|
|
-
|
|
- <p>You are probably using a Caldera system. There is a bug in the
|
|
- rc scripts. Please contact Caldera to obtain a fix.
|
|
-
|
|
- <item>Why can't I execute a file after copying it to the NFS server?
|
|
-
|
|
- <p>The reason is that nfsd caches open file handles for performance
|
|
- reasons (remember, it runs in user space). While nfsd has a file
|
|
- open (as is the case after writing to it), the kernel won't allow
|
|
- you to execute it. Nfsds newer than ~spring 95 release open files
|
|
- after a few seconds, older ones would cling to them for days.
|
|
-
|
|
- <item>My NFS files are all read only
|
|
-
|
|
- <p>The Linux NFS server defaults to read only. Please read the
|
|
- section about ``Mountd and nfsd'' and ``Exporting filesystems'' in
|
|
- this HOWTO, and refer to the ``exports'' and ``nfsd'' manual
|
|
- pages. You will need to alter <tt>/etc/exports</tt>.
|
|
-
|
|
- <item>I mount from a Linux NFS server and while <tt>ls</tt> works I
|
|
- can't read or write files.
|
|
-
|
|
- <p>On older versions of Linux you must mount a NFS servers with
|
|
- <tt/rsize=1024,wsize=1024/.
|
|
-
|
|
- <item>I mount from a Linux NFS server with a block size of between
|
|
- 3500-4000 and it crashes the Linux box regularly
|
|
-
|
|
- <p>Basically don't do it then. This does not happen with 2.0 and
|
|
- 2.2 kernels. As far as I recall there is no problem with 1.2
|
|
- either.
|
|
-
|
|
- <item>Can Linux do NFS over TCP
|
|
-
|
|
- <p>No, not at present.
|
|
-
|
|
- <item>I get loads of strange errors trying to mount a machine from a
|
|
- Linux box.
|
|
-
|
|
- <p>Make sure your users are in 8 groups or less. Older servers
|
|
- require this.
|
|
-
|
|
- <item>When I reboot my machine it sometimes hangs when trying to
|
|
- unmount a hung NFS server.
|
|
-
|
|
- <p>Do <bf/not/ unmount NFS servers when rebooting or halting, just
|
|
- ignore them, it will not hurt anything if you don't unmount them.
|
|
- The command is <tt/umount -avt nonfs/.
|
|
-
|
|
- <item>Linux NFS clients are very slow when writing to Sun and BSD
|
|
- systems
|
|
-
|
|
- <p>NFS writes are normally synchronous (you can disable this if you
|
|
- don't mind risking losing data). Worse still BSD derived kernels
|
|
- tend to be unable to work in small blocks. Thus when you write 4K of
|
|
- data from a Linux box in the 1K packets it uses BSD does this
|
|
-
|
|
- <tscreen><verb>
|
|
- read 4K page
|
|
- alter 1K
|
|
- write 4K back to physical disk
|
|
- read 4K page
|
|
- alter 1K
|
|
- write 4K page back to physical disk
|
|
- etc..
|
|
- </verb></tscreen>
|
|
-
|
|
- <item>When I connect many clients to a Linux NFS server the
|
|
- performance suddenly drops.
|
|
-
|
|
- <p>The NFS protocol uses fragmented UDP packets. The kernel has a
|
|
- limit of how many fragments of incomplete packets it can have before
|
|
- it starts throwing away packets. In 2.2 this is runtime tuneable
|
|
- via the /proc filesystem:
|
|
- <tt>/proc/sys/net/ipv4/ipfrag_high_thresh</tt> and
|
|
- <tt>ipfrag_low_thresh</tt>. In 2.0 these are compile-time constants
|
|
- defined in <tt>.../linux/net/ipv4/ip_fragment.c</tt>,
|
|
- <tt>IPFRAG_HIGH_THRESH</tt> and <tt>IPFRAG_LOW_THRESH</tt>. The
|
|
- meaning of these values is that once the memory consumption of
|
|
- unassembled UDP fragments reaches the ``ipfrag_high_thresh'' in
|
|
- bytes (256K by default in 2.2.3 and 2.0.36) it is cut down to
|
|
- ``ipfrag_low_tresh'' at once. This is done by throwing away
|
|
- fragments. This will look almost like packet loss, and if the
|
|
- high threshold is reached your server performance drops a lot.
|
|
-
|
|
- <p>256K is enough for up to 30 clients. If you have 60, double it.
|
|
- And double the low threshold also.
|
|
-
|
|
- <item>I'm using Linux 2.2 (or later) with knfsd and I can't get my
|
|
- AIX, IRIX, Solaris, DEC-Unix, ... machine to mount it.
|
|
-
|
|
- <p>Knfsd announces that it implements NFS version 3. It does not.
|
|
- There is an option to stop it from announcing it. Use it. Or you
|
|
- can put "<tt/vers=2/" in the mount option list on the clients.
|
|
-
|
|
- <item>My AIX 4 machine cannot mount my Linux NFS server. It says
|
|
-
|
|
- <tscreen><verb>
|
|
- mount: 1831-011 access denied for server:/dir
|
|
- mount: 1831-008 giving up on:
|
|
- server:/dir
|
|
- The file access permissions do not allow the specified action.
|
|
- </verb></tscreen>
|
|
-
|
|
- or something like that instead.
|
|
-
|
|
- <p>AIX 4.2 used reserved ports (<1024) for NFS. AIX 4.2.1 and 4.3
|
|
- are not constrained to reserved ports. Also, AIX 4.2.1 and 4.3 try
|
|
- to mount using NFS3, then NFS/TCP, then fiannly NFS/UDP.
|
|
-
|
|
- <p>Adding
|
|
-
|
|
-<code>
|
|
-nfso -o nfs_use_reserved_ports=1
|
|
-</code>
|
|
-
|
|
- <p>to the end of <tt/rc.tcpip/ will force it to use reserved ports
|
|
- again. (This tip was supplied by Brian Gorka)
|
|
-
|
|
-</enum>
|
|
-
|
|
-
|
|
<sect>Exporting filesystems
|
|
|
|
<p>The way to export filesytems with NFS is not completely consistent
|
|
-across platforms of course. In this case Linux and Solaris 2 are the
|
|
+across platforms of course. In this case FreeBSD and Solaris 2 are the
|
|
deviants. This section lists, superficially, the way to do it on most
|
|
systems. If the kind of system you have is not covered you must check
|
|
your OS man-pages. Keywords are: nfsd, system administration tool, rc
|
|
@@ -1040,291 +768,6 @@
|
|
</code>
|
|
|
|
After editing run the program <tt/shareall/ to export the filesystems.
|
|
-
|
|
-<sect>NFS under Linux 2.2
|
|
-<label id="linuxtwotwo">
|
|
-
|
|
-<p>As I write this Linux 2.2.12 is the current kernel version and to
|
|
-use NFS under it can be a bit of a chore. Or not.
|
|
-
|
|
-<p>What the status of NFS in Linux 2.4 will be i unknown.
|
|
-
|
|
-<p>The new big thing in Linux 2.2 is support for a in-kernel nfs
|
|
-server demon, called knfsd in 2.2. This way of implementing nfsd has
|
|
-some advantages, the main one is speed. A Linux 2.2 machine with
|
|
-knfsd is a respectable nfs server. You can still use the old nfsd
|
|
-with Linux 2.2 though, and there are some advantages to using this,
|
|
-mainly simplicity.
|
|
-
|
|
-<p>If you use a kernel source or binary package made by someone like
|
|
-RedHat (6.0 and later), SuSE (6.1 or later, I belive) or some other
|
|
-professional system integrator they have likely integrated full
|
|
-"knfsd" functionality in their kernel and you need not worry, it will
|
|
-work. Mostly. Until you want to compile a kernel yourself. If you
|
|
-use a stock Linux 2.2 kernel (up to 2.2.12 at least) knfsd will break.
|
|
-
|
|
-<p>To get this on the air yourself you need to get H.J. Lus knfsd
|
|
-package. This is a collection of patches, and the needed utilities
|
|
-for 2.2 that Lu is maintaining in his spare time. You can get it from
|
|
-your local kernel mirror, the master site is <htmlurl
|
|
-url="ftp://ftp.kernel.org/pub/linux/devel/gcc/"
|
|
-name="ftp.kernel.org:/pub/linux/devel/gcc/">. <bf/This is not meant
|
|
-for general consumption/. If you find this package confusing please
|
|
-don't try to do this yourself. Wait until a kernel package from your
|
|
-favourite system integrator (e.g., Red Hat, SuSE or ...) appears.
|
|
-
|
|
-<p>Also, please don't send me questions about this, I can't help you.
|
|
-I do not have any knfsd based servers running. If you find errors or
|
|
-omissions in this documentation, please write to me and I'll revise
|
|
-this HOWTO and release it again.
|
|
-
|
|
-<p>Still reading? Ok. H.J.Lu posts about new versions of this
|
|
-package on the linux-kernel mailing list. Other issues pertaining to
|
|
-NFS in 2.2 is also posted about there. Read it.
|
|
-
|
|
-<p>There is one interesting thing to note about the knfsd package. It
|
|
-announces that it supports NFS version 3. However it does not support
|
|
-it. There is an option you can give to stop it from announcing NFS3,
|
|
-or on the clients you can specify "<tt/vers=2/" in the mount option
|
|
-list.
|
|
-
|
|
-<sect1>The client
|
|
-
|
|
-<p>The client is almost simple. To get propper locking you need to
|
|
-get <tt/statd/ (from the knfsd package) compiled, installed and
|
|
-started from your boot-scripts. Do that. Statd needs a directory
|
|
-called <tt>/var/lib/nfs</tt> to function otherwise it will just abort
|
|
-with no error message, so that directory needs to be created before it
|
|
-will run.
|
|
-
|
|
-<p>Once statd is running you can use the <tt/testlk/ program (in
|
|
-<tt>tools/locktest</tt> to test if locking of a file on a NFS mounted
|
|
-filesystem works. It should. If it prints <em/No locks available/
|
|
-statd is not working.
|
|
-
|
|
-<p>Actually, you can also avoid locking entierly (not that I recomend
|
|
-this), by giving "<tt/nolock/" in the mount option list.
|
|
-
|
|
-<p>As far as I know this is all that's needed to get the client
|
|
-working.
|
|
-
|
|
-<p>Oh, if you have a Sparc or Alpha NFS server you will find that the
|
|
-nfs client in Linux 2.2 absolutely sucks. The transfer rates to and
|
|
-from the server is so bad that ... you can't imagine. It's far worse
|
|
-than under Linux 2.0. Far. But there is a fix for this of course.
|
|
-The Alan Cox series of 2.2 kernels (which are a bit more experimental
|
|
-than the normal 2.2 kernels from Linus) include a patch to make Linux
|
|
-2.2 perform when used with Alpha and Sparc servers. If you want to
|
|
-use the Alan Cox 2.2 kernels you should be reading the linux-kernel
|
|
-mailing list and if you do you know where the patch can be found.
|
|
-There home site of this patch is <url
|
|
-url="http://www.uio.no/~trondmy/src/">, in case you want to try to
|
|
-apply it to a stock 2.2 kernel. This patch will probably not be in
|
|
-Linux 2.4 either, because it requires too many changes in the kernel
|
|
-to be accepted in the current development cycle. Wait for Linux 2.5.
|
|
-
|
|
-<p><tt/trondmy/ also has patches to make Linux use NFS version 3, this
|
|
-will also enable you to use tcp as transport mechanism instead of UDP.
|
|
-NFSv3 is is very good for long-haul networks and other networks where
|
|
-the packet loss is non-zero or the latencies are high.
|
|
-
|
|
-<p>The reason you should read the linux-kernel mailing list to use
|
|
-these patches is that sometimes there are bad bugs discovered in them.
|
|
-Bugs that eat your files. So please <bf/beware/.
|
|
-
|
|
-<sect1>The server
|
|
-
|
|
-<p>The nfs server demon under Linux 2.2 and later is called
|
|
-"<tt/knfsd/". It is tricky to set it up. You have to figure this out
|
|
-all by yourself, or stick to what SuSE, Red Hat and others are
|
|
-releasing in the way of 2.2 kernel packages. Sorry. You can still use
|
|
-the old nfsd under Linux 2.2 though. It's slow but easy to set up.
|
|
-
|
|
-<sect>NFS server on a floppy
|
|
-
|
|
-<p>This section was written by Ron Peters, <htmlurl
|
|
-url="mailto:rpeters@hevanet.com" name="rpeters@hevanet.com"> It
|
|
-explains how to set up an NFS server when booting up from floppy. It
|
|
-was originally devised to be able to NFS share a cdrom from another
|
|
-non-Linux/UNIX machine to install Linux on a machine that does not
|
|
-have a cdrom.
|
|
-
|
|
-<!-- S e c t i o n - - - - - - - - - - - - - - - B r e a k e r -->
|
|
-<sect1> Introduction
|
|
-<p>
|
|
-This document is being created for those who will run into the same problem
|
|
-I had recently. I was building a Linux server on a machine that didn't have
|
|
-a cdrom and has no facility for adding one except for possibly an external
|
|
-SCSI or the like. Now that it is getting less and less likely that you will
|
|
-be installing on a machine like that, this document may not be that
|
|
-valuable. However, I would have appreciated it when I was trying to build
|
|
-my machine.
|
|
-<p>
|
|
-Since my machine didn't have a cdrom drive, I thought I would go find an NFS
|
|
-server for Win95 and share the cdrom for long enough to install the box and
|
|
-get it on my network. Of the two products I found, (I'm not mentioning names
|
|
-but one was freeware and the other was a 14 day limited license), one didn't
|
|
-work out of the box, and the other couldn't handle the Linux naming
|
|
-convention well enough to complete the install.
|
|
-<p>
|
|
-I then settled on trying to boot my Win95 machine with the boot/root set of
|
|
-disks and then use a suplimentary floppy to set up the NFS server.
|
|
-<p>
|
|
-This was remarkably simple, and the procedure is probably easier than reading
|
|
-this introduction but I believe that putting the whole procedure in one
|
|
-place will be value added.
|
|
-<p>
|
|
-
|
|
-<!-- S e c t i o n - - - - - - - - - - - - - - - B r e a k e r -->
|
|
-<sect1>Expectations
|
|
-<p>
|
|
-This document was derived using the boot/root disks from one of the current
|
|
-InfoMagic developer distributions of Slackware. I used kernel version
|
|
-2.0.34 for the boot/root disks, but the NFS server programs were taken from
|
|
-a 2.0.30 server. I have always used the Slakware installation method, not
|
|
-because it is any easier or better or worse, just that I am comfortable with
|
|
-it and I haven't taken the time to try another method.
|
|
-<p>
|
|
-I don't believe that there will be many problems using this document in
|
|
-relation to OS version. I would recommend using something relatively
|
|
-current. Since it is likely that this will be used for installation, a
|
|
-current boot/root set will likely be used.
|
|
-<p>
|
|
-Your mileage may vary.
|
|
-<p>
|
|
-
|
|
-<!-- S e c t i o n - - - - - - - - - - - - - - - B r e a k e r -->
|
|
-<sect1>Requirements
|
|
-<p>
|
|
-<itemize>
|
|
-<item>Network capable system and boot disk. The system that is to be the
|
|
-NFS server must have a network card and it must be recognized by the during
|
|
-the boot process. More information on this can be found in the Networking
|
|
-HOWTO.
|
|
-<item>Secondary floppy that contains rpc.portmap, rpc.mountd and rpc.nfsd.
|
|
-These files should be easily found from an ftpsearch off the web.
|
|
-<item>Slackware (or other) source media (assumed to be cd).
|
|
-</itemize>
|
|
-
|
|
-<!-- S e c t i o n - - - - - - - - - - - - - - - B r e a k e r -->
|
|
-<sect1> Server Setup
|
|
-<p>
|
|
-<sect2> Boot the temporary NFS server
|
|
-<p>
|
|
-Boot the NFS server system from boot floppy and make sure the network card
|
|
-is recognized. It is also necessary that the CDROM be recognized. I will
|
|
-use eth0 as the example network card.
|
|
-<p>
|
|
-<sect2> Mount the floppy and cdrom
|
|
-<p>
|
|
-Once the system is booted up, the boot/root floppies are not needed. The
|
|
-system is fully contained in RAM.
|
|
-<p>
|
|
-Replace the root floppy with the suplimentary disk. Mount the floppy:
|
|
-<p>
|
|
-<tt>mount /dev/fd0 /floppy</tt>
|
|
-<p>
|
|
-This assumes that the floppy is an ext2 file system type. I imaging that
|
|
-the suplimentary disk could be a DOS floppy with the files on it, but I
|
|
-haven't tried that yet. I imagine that this would be easier that a disk
|
|
-image. In this case, it would be a <tt>mount -t msdos ...etc</tt>. This
|
|
-should probably be put in the todo section.
|
|
-<p>
|
|
-Mount the cdrom:
|
|
-<p>
|
|
-<tt>mount -t iso9660 /dev/hdc /cdrom</tt>
|
|
-<p>
|
|
-The floppy and cdrom devices are the ones I used. These may be different
|
|
-depending on application. The mount points /floppy and /cdrom exist on the
|
|
-root floppy disk image so they can be used. If they don't, create them or
|
|
-you could use any mount points you like.
|
|
-<p>
|
|
-<sect2> Set up networking on the temporary server.
|
|
-<p>
|
|
-This is where the temporary NFS server is set up to talk on the network.
|
|
-There are only a few commands to run. There are a few items of information
|
|
-that you will need before running the commands (values are examples):
|
|
-<p>
|
|
-IPADDR:172.16.5.100 #This is the address of the temporary server.
|
|
-<p>
|
|
-NETMASK:255.255.255.0 #This is the netmask.
|
|
-<p>
|
|
-BROADCAST:172.16.5.255 #The last number (255) is significant from IPADDR.
|
|
-<p>
|
|
-ETHNETWORK:172.16.5.0 #Once again, slightly different from IPADDR.
|
|
-<p>
|
|
-GATEWAY:172.16.5.251 #Only needed if you have a gateway. You will probably
|
|
-know. Most home networks won't have a gateway.
|
|
-<p>
|
|
-The commands to get on the network. Insert values from above:
|
|
-<p>
|
|
-<tt>ifconfig eth0 inet IPADDR arp netmask NETMASK broadcast BROADCAST</tt>
|
|
-<p>
|
|
-<tt>route add -net ETHNETWORK netmask NETMASK eth0</tt>
|
|
-<p>
|
|
-Only use next command if you have a gateway and need to go through it:
|
|
-<p>
|
|
-<tt>route add default gw GATEWAY netmask 0.0.0.0 eth0</tt>
|
|
-<p>
|
|
-If all goes well, you are now on the network and should be able to ping other
|
|
-nodes.
|
|
-<p>
|
|
-<sect2> Set up the NFS share.
|
|
-<p>
|
|
-Determine the directory that you want to NFS share. In the case of the my
|
|
-example, I used the /cdrom/slakware directory. Put this directory in the
|
|
-/etc/exports file:
|
|
-<p>
|
|
-<tt>echo "/cdrom/slakware" > /etc/exports</tt>
|
|
-<p>
|
|
-<sect1> Run the NFS server
|
|
-<p>
|
|
-Go to /floppy/usr/sbin and run:
|
|
-<p>
|
|
-<tt>./rpc.portmap</tt>
|
|
-<p>
|
|
-<tt>./rpc.mountd</tt>
|
|
-<p>
|
|
-<tt>./rpc.nfsd</tt>
|
|
-<p>
|
|
-<sect2> Complete, start the install.
|
|
-<p>
|
|
-This should share the "/cdrom/slakware" directory in the /etc/exports file.
|
|
-Once this is done, you can now boot up the machine to be installed from
|
|
-boot/root floppies (I used same ones that I booted NFS server with) and start
|
|
-the installation.
|
|
-<p>
|
|
-Once you are ready to choose the media source location, choose the NFS
|
|
-server option. It will ask about the ip address of the server. Give it the
|
|
-IP address that you used as IPADDR for the server. It will also ask for the
|
|
-directory to be mounted. This is the directory you put in the /etc/exports
|
|
-on the NFS server.
|
|
-<p>
|
|
-The system will then NFS mount the server. Watch for any error messages.
|
|
-All should be complete and you can continue the installation.
|
|
-<p>
|
|
-<!-- S e c t i o n - - - - - - - - - - - - - - - B r e a k e r -->
|
|
-<sect1>Troubleshooting
|
|
-<p>
|
|
-<sect2> Nothing Here Yet.
|
|
-<p>
|
|
-I don't have any troubleshooting info yet. Perhaps as people use this
|
|
-procedure, there will be more tips and hints available.
|
|
-<p>
|
|
-<!-- S e c t i o n - - - - - - - - - - - - - - - B r e a k e r -->
|
|
-<sect1>To Do
|
|
-<p>
|
|
-<sect2>DOS Disk.
|
|
-<p>
|
|
-Check out a DOS disk for the suplimentary disk.
|
|
-<p>
|
|
-<sect2> rpc commands.
|
|
-<p>
|
|
-Check out specific order of running rpc.* commands and if all or just some
|
|
-of the command needs to be run.
|
|
-<p>
|
|
-
|
|
-<!-- S e c t i o n - - - - - - - - - - - - - - - B r e a k e r -->
|
|
|
|
<sect>PC-NFS
|
|
|